Об'єктно-орієнтоване проектування: визначення, принципи та приклади

Об`єктно-орієнтоване проектування-це процес планування системи взаємодіючих об`єктів з метою вирішення програмної задачі. Це один з підходів до розробки забезпечення.

Предмет містить інкапсульовані дані та процедури, згруповані разом, щоб представляти об`єкт. Інтерфейс визначає, як він може співіснувати, а програма описує взаємодію множин. Об`єктно-орієнтоване проектування - це дисципліна визначення предметів і їх процеси для вирішення проблеми, яка була виявлена і задокументована в ході аналізу.

Далі йде опис підмножини на основі класів, яка не включає підходи на основі прототипів об`єктів, коли вони зазвичай не отримуються шляхом створення екземплярів класів, а шляхом клонування інших. Дизайн - це методологія об`єктно-орієнтованого проектування. Вона охоплює процес декомпозиції і позначення для зображення як логічних, так і фізичних станів, а також динамічних моделей проектованої системи.

Теми дизайну

Вхід для об`єктно-орієнтованого проектування забезпечується виходом аналізу. Необхідно зрозуміти, що артефакт не повинен бути повністю розроблений, щоб служити опорною точкою. Аналіз і проектування можуть відбуватися паралельно. На практиці результати однієї дії можуть підживлювати іншу в короткому циклі зворотного зв`язку через ітеративний процес. Як перша, так і друга дія може виконуватися поетапно, артефакти можна постійно нарощувати, а не розробляти повністю за один раз.

Деякі типові предмети

Розглянемо найважливіші.

1. Концептуальна модель.

Результати об`єктно-орієнтованого аналізу та проектування охоплюються концепцією в предметній області. Концептуальна модель явно обрана, щоб бути незалежною від деталей реалізації, таких як паралельність або зберігання даних.

2. Варіант використання.

Опис послідовностей подій, які в сукупності призводять до того, що система робить щось корисне. Кожен варіант використання надає один або кілька сценаріїв, які передають об`єктно-орієнтоване проектування систем. Саме воно повинно взаємодіяти з користувачами, званими акторами, для досягнення конкретної бізнес-мети або функції.

Виконавцями прецедентів можуть бути кінцеві користувачі або інші системи. У багатьох випадках варіанти застосування даного методу додатково розробляються у вигляді діаграм. Схеми прецедентів використовуються для визначення дійової особи та процесів, які вони виконують. Детальніше можна прочитати в книзі Граді Буча «Об`єктно-орієнтоване проектування».

3. Діаграма послідовності системи.

Вона являє собою зображення, що показує для конкретного сценарію варіанти використання події, які генерують зовнішні учасники, їх порядок і можливі міжсистемні дії.

4. Документація по інтерфейсу.

Папір, який показує та описує зовнішній вигляд кінцевого продукту. Цей пункт є не обов`язковим, але він допомагає візуалізувати, що полегшує дизайнеру завдання.

Реляційна модель даних

Це абстрактний прототип, який описує, як інформація подається та споживається. Якщо об`єктна база не використовується, реляційну модель даних зазвичай слід створювати перед дією, оскільки стратегія, обрана для прийняття об`єктно-орієнтованого проектування, є результатом процесу.

Однак можна паралельно розробляти реляційну модель даних, а зростання артефакту може стимулювати уточнення інших компонентів. Детальніше про це також написано в книзі Буча "Об`єктно-орієнтований аналіз та проектування". Відзначимо, що в цьому новому виданні Граді Буча ви знайдете безліч практичних порад, що стосуються аналізу, реалізації, проектування та управління проектами.

Концепція

П`ять основ об`єктно-орієнтованого проектування - це функції рівня реалізації, вбудовані в мова програмування. Вони часто називаються такими загальними іменами:

1. Клас об`єкта.

Що це таке? Класом називається тісний зв`язок або торкання структур даних з методами або функціями, які впливають на них (об`єкт створюється на його основі). Кожен предмет виконує якусь функцію. Він визначається своїми властивостями. Об`єкт може бути частиною класу, який є набором подібних предметів.

2. Приховування об`єктно-орієнтованого проектування інформаційних систем, це здатність захищати деякі компоненти від зовнішніх впливів.

3. Успадкування.

Це можливість для класу розширити або замінити функціональність іншої групи. Так званий підклас має цілий розділ, який є похідним (успадкованим) від суперкласу, а також має власний набір функцій та даних.

4. Інтерфейс (серед прийомів об`єктно-орієнтованого проектування існують так звані патерни. Інтерфейс abstract factory-один з них).

Здатність відкладати реалізацію методу, а також можливість визначення функцій без їх здійснення.

5. Поліморфізм ( зокрема, підтип) - здатність замінити об`єкт його підоб`єктами. А також можливість об`єкта-змінної містити не тільки цей предмет, але і всі його складові.

Розробка концепцій

Визначення об`єктів, створення діаграми класів з концептуальної форми зазвичай відображають сутність.

Ідентифікація атрибутів.

Необхідно використовувати шаблони гами прийому об`єктно-орієнтованого проектування. Це не готовий продукт, а опис рішення загальної проблеми в контексті. Основний перевага використання шаблону проектування полягає в тому, що його можна застосовувати повторно в декількох додатках. Його також розглядають для вирішення проблем, які можуть виникнути в багатьох різних ситуаціях. Шаблони об`єктно-орієнтованого проектування гами зазвичай показують взаємозв`язки та взаємодії між класами або об`єктами, не вказуючи кінцевих систем додатків або об`єктів, які в них беруть участь.

Визначення структури.

Це зазвичай набір бібліотек або класів, які використовуються для реалізації стандартного будови програми для конкретної операційна система. Поєднуючи велику кількість повторно використовуваного коду в платформу, Розробник економить багато часу, оскільки вирішує проблему Переписування великої кількості стандартного коду для кожного нового додатка, що розробляється.

Висновок (результати) об`єктно-орієнтованого проектування

Діаграму послідовності потрібно вирішити, щоб додати конкретні об`єкти, які обробляють системні події. Вона показує у вигляді паралельних вертикальних ліній різні процеси, які живуть одночасно, а у вигляді горизонтальних стрілок-обмін повідомленнями між ними в порядку їх появи.

Діаграма КЛАСІВ - це тип статичної структури UML, який описує системи, показуючи їх атрибути і відносини між ними. Повідомлення та класи, ідентифіковані за допомогою розробки діаграм послідовності, можуть служити вхідними даними для автоматичної генерації глобальної системи.

Деякі принципи та стратегії дизайну

Часто використовують впровадження залежностей. В чому полягає основна ідея? Якщо предмет залежить від наявності будь-якого іншого примірника, то необхідний впроваджується в залежний. Приклад об`єктно-орієнтованого проектування: передайте підключення до бази даних як аргумент конструктору, а не створюйте його внутрішньо. Ще один приклад з використанням патерну bridge: відокремлюють абстракцію від її реалізації, щоб обидва предмети можна було змінювати незалежно.

Розглянемо принципи об`єктно-орієнтованого проектування ациклічних залежностей. Відзначимо, що граф компонентів (ступінь деталізації залежить від обсягу робіт) не повинен мати циклів. Це також називається спрямованим ациклічним графом. Приклад об`єктно-орієнтованого аналізу та проектування: скажімо, C залежить від B, який підпорядковується предмету A. Якщо останній також має відношення до C, то буде цикл.

Який принцип складеного повторного використання? Перевага віддається поліморфної композиції успадкування. Після фази аналізу концептуальна модель надалі розвивається в об`єктно-орієнтоване проектування ІС. Тут технологічно незалежні концепції аналізу відображаються на реалізують класи, ідентифікуються обмеження і розробляються інтерфейси, в результаті чого виходить модель для області рішення.

Етапи для об`єктно-орієнтованого проектування ІС можуть бути визначені так:

• Пошук контексту системи.
• Проектування її архітектури.
• Ідентифікація об`єктів в системі.
• Побудова дизайнерських макетів.
• Специфікація об`єктних інтерфейсів.
• Дизайн.

Об`єктно-орієнтоване проектування системи включає в себе визначення контексту з подальшим створенням архітектури.

Перше поняття

Контекст системи має статичну та динамічну частини. Перший створений завдяки об`єктно-орієнтованому проектуванню c використанням простої блок-схеми, яка Розширена в ієрархію підсистем. Дана модель представлена UML-пакетами. Динамічний контекст описує, як система взаємодіє зі своїм середовищем. Він моделюється із застосуванням діаграм варіантів використання.

Архітектура системи розроблена на основі контексту і відповідно до принципів проектування, а також з урахуванням предметної області. Як правило, система розбивається на шари, а вони розкладаються для формування підсистем.

Що таке об`єктно-орієнтована декомпозиція? Розкладання означає поділ великої складної системи на ієрархію менших компонентів з меншою складністю. Кожна основна частина називається підсистемою. Об`єктно-орієнтована декомпозиція ідентифікує окремі автономні об`єкти в системі та зв`язок між ними.

Переваги розкладання:

• Окремі компоненти мають меншу складність і тому більш зрозумілі та керовані.
• Відбувається поділ робочої сили, що має спеціалізовані навички.
• Це дозволяє замінювати або модифікувати підсистеми, не впливаючи на інші частини.

Виявлення паралелізму

Це дозволяє декільком об`єктам отримувати події та виконувати кілька дій одночасно. Паралелізм ідентифікований і представлений в динамічній моделі.

Щоб увімкнути його, кожному паралельному елементу призначається окремий потік управління. Якщо паралелізм знаходиться на рівні об`єкта, тоді двом симетричним предметам призначаються два різних потоку управління. Якщо дві операції одного з них є паралельними за своєю природою, то він розподіляється між різними потоками.

Паралельність пов`язана з проблемами цілісності даних і взаємоблокувань. Тобто чітка стратегія повинна бути розроблена щоразу, коли потрібен паралелізм. Крім того, він повинен ідентифікуватися на самій стадії розробки і не може бути залишений на етапі реалізації.

Прийоми об`єктно-орієнтованого проектування, патерни проектування

При розробці додатків приймаються деякі загальноприйняті рішення для окремих категорій проблем. Це, наприклад, шаблони дизайну. Він може бути визначений в якості документованого набору будівельних блоків, які можуть використовуватися в певних типах завдань розробки додатків.

Деякі часті прийоми об`єктно-орієнтованого проектування (патерни проектування) можна знайти в шаблонах дизайну:

• Фасадний малюнок.
• Модель поділу виду.
• Зразок спостерігача.
• Модель контролера виду моделі.
• Проксі-шаблон.
• Управління подіями.

Під час проектування моделі об`єктно-орієнтованої системи події, які можуть відбуватися в предметах, повинні бути ідентифіковані та належним чином оброблені.

Подія - це специфікація значущої події, яка має місце розташування у час і простір. Існує чотири типи, які можна змоделювати, а саме:

• Сигнальний-іменований об`єкт, кинутий одним і захоплений іншим.
• Подія виклику-Синхронний захід, що представляє відправку операції.
• Процес часу представляється протягом часу.
• Подія зміни-заходи, що представляє модифікування стану.

Обробка граничних умов

Етап проектування повинен враховувати ініціалізацію і завершення системи в цілому, а також кожної підсистеми. Різні аспекти:

• Запуск, т. е. перехід з неініціалізованого стану в стійкий.
• Завершення роботи системи, т. е. закриття всіх запущених потоків, очищення ресурсів та надсилання повідомлень.
• Початкова конфігурація та реконфігурація при необхідності.
• Передбачення збоїв або небажаного завершення роботи системи.
• Граничні умови моделюються з використанням схожих варіантів вживання.

Об`єктний дизайн

Після того як ієрархія підсистем була розроблена, предмети в системі ідентифікуються, а їх деталі проектуються. На цьому етапі працює дизайнер. Акцент зміщується з предметної області на комп`ютерні концепції. Об`єкти, ідентифіковані в період аналізу, витісняються для реалізації з метою мінімізації часу виконання, споживання пам`яті та загальних витрат.

Проектування об`єкта включає в себе наступні етапи:

• Ідентифікація.
• Уявлення. Побудова проектних моделей.
• Класифікація операцій.
• Алгоритм проектування.
• Дизайн відносин.
• Здійснення контролю зовнішніх взаємодій.
• Пакетні класи та асоціації в модулі.

Ідентифікація об`єкта

Саме це є першим етапом проектування. Об`єкти, ідентифіковані на періодах об`єктно-орієнтованого аналізу, групуються в класи і уточнюються таким чином, щоб вони підходили для фактичної реалізації.

Функції цього етапу:

• Виявлення та уточнення класів у кожній підсистемі чи пакеті.
• Визначення зв`язків та асоціацій між наборами.
• Розробка ієрархії (Узагальнення, спеціалізація та успадкування).
• Проектування агрегатів.

Представлення об`єкта

Після ідентифікації КЛАСІВ вони повинні бути показані за допомогою методів моделювання. Цей етап, по суті, включає в себе побудову UML-діаграм.

Існує два типи дизайнерських моделей, які повинні бути виготовлені:

Статичний. Для її опису використовуються діаграми класів і об`єктів.

Динамічна модель. Щоб її описати і показати відносини між класами, використовуються діаграми взаємодії і станів.

Класифікація операцій

На цьому етапі завдання, що виконуються над предметами, визначаються шляхом об`єднання трьох моделей: об`єктної, динамічної та функціональної. Операція визначає, що повинно бути зроблено, а не як.

В даному відношенні повинні бути виконані наступні завдання:

• Розроблено діаграму переходу станів кожного об`єкта в системі.
• Операції визначені для подій, отриманих предметами.
• Ідентифіковані випадки, коли один захід викликає інші в тому ж або іншому об`єкті.
• Підоперації в діях визначені.
• Основні вчинки розширені до діаграм потоків даних.

Розробка алгоритму

Операції в об`єктах визначаються за допомогою послідовності. Алгоритм-це покрокова процедура, яка вирішує проблему, викладену в операції. Вони зосереджені на тому, як це має бути зроблено.

Може бути більше одного алгоритму, що відповідає операції. Як тільки альтернативні послідовності визначені, оптимальний вибирається для проблемної області. Метрики для вибору алгоритму:

• Складність підрахунків. Вона визначає ефективність алгоритму, з точки зору, часу обчислень і вимог до пам`яті.
• Гнучкість. Дане поняття визначає, чи може обраний алгоритм бути реалізований належним чином і без втрати відповідності в різних середовищах.
• Зрозумілість. Показує, чи вибраний алгоритм простий для розуміння та реалізації.

Дизайн відносин

Дана стратегія повинна бути записана на етапі проектування об`єкта. Основні взаємозв`язки включають асоціації, агрегації та успадкування.

Щодо об`єднань дизайнер повинен зробити наступне:

• Визначити, чи є взаємозв`язок односпрямованим чи двонаправленим.
• Проаналізувати шляхи асоціацій і оновити їх при необхідності.

Що стосується успадкування, проектувальник повинен зробити наступне:

• Налаштуйте класи та їх асоціації.
• Визначте абстрактні системи.
• Створити умови, щоб при необхідності можна було обмінюватися поведінкою.

Здійснення контролю

Розробник об`єкта може включити уточнення в стратегію моделі діаграми станів. При проектуванні системи визначена Базова політика динамічного предмета.

Підходи для реалізації динамічної моделі:

1. Представляти стан як місце розташування в програмі.

Це традиційний підхід, заснований на процедурах, при якому місце розташування елемента управління визначає стан. Кінцевий автомат може бути реалізований у вигляді програми. Перехід формує вхідний оператор, основний шлях управління виробляє послідовність інструкцій, гілки створюють умови, а Зворотні шляхи утворюють цикли або ітерації.

2. Механізм кінцевого автомата.

Цей підхід безпосередньо представляє термін через його клас. Він виконує кінцевий автомат за допомогою набору переходів і дій, що надаються додатком.

3. Управління-паралельні завдання.

При такому підході об`єкт реалізується як питання мовою програмування або в операційній системі. Тут подія реалізовано в якості межзадачного виклику, зберігає властивий паралелізм реальних об`єктів.

Класи упаковки

У будь-якому великому проекті важливим є ретельний розподіл реалізації на модулі або пакети. При створенні об`єктів класи групуються, що дозволяє декільком товариствам спільно працювати.

Різні аспекти упаковки:

1. Приховування внутрішньої інформації від зовнішнього вигляду. Це дозволяє розглядати клас як "чорну скриньку" та змінювати реалізацію, не вимагаючи від Клієнтів модифікації коду.

2. Узгодженість елементів. Деталь (така, як клас, операція або модуль) є пов`язаною, якщо вона організована за узгодженим планом, а всі його частини нерозривні, тобто вони служать спільній меті.

Основи побудови фізичних модулів:

1. Класи повинні представляти подібні речі або компоненти в одному і тому ж складеному об`єкті.

2. Тісно пов`язані класи повинні бути в одному модулі, а незв`язані або слабо згруповані слід розміщувати в окремих частинах.

3. Модулі повинні мати високий рівень взаємодії між їх компонентами.

Оптимізація дизайну

Модель аналізу збирає логічну інформацію про систему, а складова проекту додає деталі для підтримки ефективного доступу до неї. Перед реалізацією слід оптимізувати програму, щоб зробити вихід більш ефективним. Метою поліпшення є мінімізація витрат з точки зору часу, простору та інших показників.

Однак оптимізація дизайну не повинна бути надмірною, оскільки простота реалізації, ремонтопридатність та розширюваність також є важливими проблемами. На практиці це добре видно. Розробники знають, що ідеально оптимізований дизайн є більш ефективним, але менш придатним для повторного використання. Таким чином майстер повинен знайти баланс між ними.

Різні речі, які можна зробити для поліпшення:

• Додати надлишкові асоціації.
• Опустити невикористовувані об`єднання.
• Оптимізувати алгоритми.
• Зберегти похідні атрибути, щоб уникнути повторного обчислення складних виразів.

Розглянемо деякі пункти детальніше.

Додавання надлишкових асоціацій.

Під час оптимізації проекту перевіряється, чи може створення нових спілок знизити витрати на доступ. Хоча ці надлишкові асоціації можуть не додавати ніякої інформації, вони здатні підвищити ефективність загальної моделі.

Виключення невикористовуваних об`єднань.

Наявність занадто великої кількості асоціацій може зробити систему не піддається розшифровці і знизити загальну ефективність. Тобто під час оптимізації всі невикористовувані союзи видаляються.

Покращення алгоритмів.

В об`єктно-орієнтованих системах оптимізація структури даних здійснюється на основі співпраці. Після створення проекту класу операції та алгоритми повинні бути вдосконалені.

Оптимізація досягається шляхом:

• Перестановки порядку обчислювальних задач.
• Зміни послідовності виконання циклів.
• Видалення мертвих шляхів в алгоритмі.
• Збереження похідних атрибутів.