Архітектура та проектування програмного забезпечення 1 ТЕМА 2. МОДЕЛІ, КАРКАСИ І ЗРАЗКИ ПРОЕКТУВАННЯ Декомпозиція великого проекту на компоненти є істотним кроком, але нас ще чекає набагато більша робота із створення архітектури. Спершу нам необхідно погоджувати варіанти використання, класи, переходи станів і декомпозицію. Ці проекції називаються моделями При створенні моделі класів доцільно розробляти і використовувати вже існуюче програмне забезпечення, яке утворює базис для сімейства схожих додатків. Таке сімейство, називається каркасом Детальне проектування - це повний об'єм робіт по проектуванню, вик лючаючи архітектуру і реалізацію. Воно містить визначення класів, що зв'язують класи наочної області і класи архітектури. Замість того щоб «винаходити велосипед», ми прагнемо використовувати розробки, що вже довели свою ефективність в попередніх додатках. Зразки проектування — це шаблони взаємодіючих класів і методів, які вже продемонстрували своє значення для багатьох додатків. У якості прикладу можна взяти набір класів, що реалізовують дерево об'єктів. Зразки використовуються як на рівні архітектури, так і на рівні детального проектування. Далі як вправу буде розроблено каркас класів для гри Зустріч, загальний для всіх ролевих ігор. Грунтуючись на цьому каркасі, в цьому розділі ми представимо архітектуру гри Зустріч. Для завершення проектування даної гри класи наочної області, отримані на етапі аналізу вимог, необхідно підготувати до роботи з класами архітектури. Ми зробимо це шляхом додавання класів детального проектування. План Архітектура та проектування програмного забезпечення 2 2.1 Використання моделей 2.2 Уніфікована мова моделювання (UML) 2.3 Каркаси 2.4 Класифікація архітектури 2.5 Зразки проектування: введення 2.6 Компоненти Література: [1] – Браунде Э. Технология разработки программного обеспечения. – СПб.: Питер, 2004. – C. 359 - 366 [2] – Орлов С.А. Технологии разработки программного обеспечения. (Разработка сложных программных систем):учеб. пособие. - СПб.:Питер. - 2002. - 464с. - (ил.). - Учебник для вузов. - 5 - 94723 - 145 - Х. – C. 362 - 370 2.1. Використання моделей Зазвичай нам необхідно описати додаток з декількох точок зору. Це можна порівняти з архітектурою будинку, яка вимагає декількох проекцій, таких як план розташування ділянок землі, вертикальний і фронтальний види, план водопроводу і так далі. В світі програ мування проекції називаються моделями. За останні роки в цій області з'явилася безліч прекрасних розробок. Різні моделі проектованого застосування показані на рис. 1 і 2 Багато позначень узято з USDP (уніфікований процес розробки програмного забезпечення) . розглянутого в [64] і [75]. Архітектура та проектування програмного забезпечення 3 Модель варіантів використання є колекцією варіантів використання. Вони пояснюють, що саме має робити додаток. Початкова версія варіантів Архітектура та проектування програмного забезпечення 4 використання підходить для використання як С - вимог (іноді їх називають «ділові варіанти використання» або «варіанти використання наочної області»), В процесі реалізації проекту вони набувають властивостей діаграм послідовності спеціального вигляду. Їх реалізують у вигляді конкретних сценаріїв, які потім використовуються при тестуванні. Як приклад варіанту використання для гри Зустріч можна узяти випадо к зустрічі із зовнішнім персонажем, розглянутий в прикладі. Модель класів. Ми вже розглянули достатньо багато моделей класів (діаграм класів). Модель класів пояснює побудова блоків, з яких буде сформовано застосування. Моделі класів часто називають об'єктн ими моделями. Усередині моделі класів ми можемо показати методи і атрибути. Модель компонентів є колекцією діаграм потоків даних. Вони пояснюють, яким чином додаток працюватиме в термінах переміщення даних. Модель компонентів гри Зустріч у вправах включати ме діаграму потоків даних про характеристики між зовнішнім персонажем і персонажем гравця при їх зустрічі. Модель переходів станів є колекцією діаграм переходів станів. Модель переходів станів визначає момент часу, в який додаток здійснює свою роботу. У гр і Зустріч вже розроблено таку модель (розділ 3 авт.) . Вона показує реакцію гри на появу інших персонажів, а також на запити користувача встановити характеристики, закрити вікно, вийти з гри і так далі Усередині кожної моделі ми опрацьовуємо рівні деталізац ії, кількість яких росте. Залежно від об'ємів роботи ми можемо ітеративно застосовувати ділення на рівні деталізації усередині кожної з моделей. Архітектура застосування часто виражається в термінах однієї з моделей і підтримується рештою моделей. USDP вкл ючає модель реалізації. яка повинна бути виконана з урахуванням організації коду. У кожній архітектурі є щонайменше одна модель класів, здатна реалізувати цю архітектуру. Архітектура та проектування програмного забезпечення 5 2.2. Уніфікована мова моделювання (UML) У моделях класів, які розглядатимуться далі, ми широко використовуватимемо уніфіковану мову моделювання — UML (Unified Modeling Language) 115,95 Нотація UML також використовуються для варіантів використання і діаграм послідовності. Основи нотації UML для моделей класів показані па рис. 3 і 4 . Далі м и розглянемо ЦІ малюнки докладніше. На найвищому рівні моделі класів для компонентів архітектури в UML використовується термін пакет. Пакети — це колекції класів. Пакетами іноді називають колекції класів Java, і ці терміни досить точно відповідають один од ному. Пакети Java транслюються в каталоги, підпакети — в підкаталоги і так далі Взагалі кажучи, UML дозволяє поміщати в пакети будь - які матеріали, пов'язані із застосуванням. Зокрема код результатів проектування, документацію і ін. Архітектура та проектування програмного забезпечення 6 Абстрактні класи не мають екземплярів, тобто об'єктів (на малюнках імена таких класів виділені курсивом). Агрегація, помічена ромбом, указує на те, що об'єкти одного класу є вкладеними в інший клас. Число на полюсі агрегації означає кількість агрегованих об'єктів. Наприкла д, число 1 на Архітектура та проектування програмного забезпечення 7 полюсі відношення DerivedClass/AggregatedClass означає, що кожним об'єктом класу DerivedCiass агрегується один об'єкт класу AggregatedClass. Замість числа може бути вказаний інтервал, наприклад 3.7. Символ * означає деяке число агрегованих об 'єктів. Залежність позначається стрілкою з пунктирною лінією. Зазвичай вона означає посилання методу залежного класу на інший клас. 2.3. Каркаси Каркас — це колекція класів, використовуваних в декількох різних додатках. Часто класи усередині каркаса взаєм озв'язані. Вони можуть бути абстрактними і використовуватися через спадкоємство. Інтерфейс прикладного програмування (API), реалізований в Java, є прикладом корисних каркасних пакетів. Він показав, наскільки співтовариство розробників потребує багатої коле кції каркасів для виконання своєї роботи. Базові пакети Java API можуть бути використані у величезній кількості різноманітних додатків. Пов'язання пакетів застосувань з каркасними пакетами здійснюється за допомогою агрегації і (або) наслідування. Розглянем о, наприклад, використання пакету Java Windowing Toolkit {awt): замість того щоб модифікувати awt, ми створюємо класи графічного інтерфейсу користувача, які успадковані від awt або агрегують об'єкти awt як атрибути. Існує думка, що каркаси слід створювати тільки в тому випадку, якщо вони, так само як і Java API. використовуватимуться великою кількістю додатків. Проте розробка часткового каркаса паралельно із додатком дає безліч переваг, навіть коли немає упевненості в тому, що цей каркас буде придатний для великого числа додатків. Цей частковий каркас нерідко служить незмінним абстрактним рівнем, який успадковують класи багатьох застосувань. Архітектура та проектування програмного забезпечення 8 Як приклад створимо каркас, який можна використовувати в грі Зустріч. Виконаємо декомпозицію гри як застосування. Варі анти декомпозиції легко отримати, групуючи класи наочної області, отримані при аналізі вимог (Зона, Персонажвстречи, Ігравстреча, Контакт, Окноконтакта. Внешнійперсонаж, Персонажігрока і Окнохарактерістікигрока). Кожен з цих класів повинен підходити для па кету додатка, і кожен пакет додатка повинен використовувати один або більше за пакетів каркаса. Наприклад, згідно цього принципу, один каркасний пакет Персонаж може визначати участь героїв в грі Зустріч. Також може бути створений пакет додатка Персонажвстр ечи, використовуючий Персонаж і що містить класи для персонажів класу Ігравстреча ( рис. 5 ). Декомпозиція ролевої гри на пакети каркаса і пакети застосування Зустріч показана на рис. 6 Каркасний пакет Персонажі визначає і персонажів, що керуються гравцем і персонажів, що керуються додатками. Каркасний пакет Артефакти складається з елементів, що не належать ніяким іншим пакетам. Необхідність Архітектура та проектування програмного забезпечення 9 пакету Артефакти гри на цій стадії ще не зовсім ясна. Можливо, ще рано мі ркувати про те, чи повинні. наприклад, аксесуари розглядатися як частина рівня або щити міститися в пакеті Персонаж. Ми прагнули отримати високу зв'язність і низьке зчеплення в додатку Зустріч, групуючи логічну суть (персонажі, гра, управління і відображення). Якби ми групували класи так, як вони з'являються на моніторі (персонажі усередині зони), то пакети мали б неприйнятно низьку зв'язність, оскільки вони не є сильно зв'язаними класами. Зчепле ння в цьому випадку виявилася б дуже високою, оскільки ми повинні були б забезпечити доступ і до зони, і до персонажа (а це дуже різна суть) ззовні пакету. Шлях, який приводить нас до моделі класів, представлений на рис. 7 Класи наочної області отримані я к результат аналізу вимог. Класи каркаса Архітектура та проектування програмного забезпечення 10 отримані з розробки архітектури для застосувань, подібних тому, яке ми проектуємо. Таким чином, класи каркаса або є частиною раніше існуючого пакету, або розроблені, як в процесі аналізу архітектури. Нарешті, класи (проектні класи), що залишилися, додані для завершення проектування. Завершене проектування складається зі всіх класів наочної області, всіх класів проектування і деяких каркасних класів ( рис. 7 ). (Зазвичай ми не використовуємо всі каркасні класи.) Каркасн і класи, використані в проекті, є частиною архітектури застосування. Всі класи наочної області — це частина детального проектування, оскільки вони специфічні для кожного застосування, отримані з вимог і не відносяться до архітектури. Як приклад візьмемо кл ас Персонаж Гравця з вправи. По суті, він є окремим класом, що описує поведінку персонажа. Деякі з проектних класів створюються в процесі проектування архітектури, інші - в процесі детального проектування. Архітектура та проектування програмного забезпечення 11 2.4. Класифікація архітектури Шоу і Гарлан [34] класифікували архітектуру програмного забезпечення з погляду практики. Іншими словами, вони зібрали разом зразки програмного забезпечення для різної архітектури. Їх класифікація, трохи адаптована, показана нижче. ♦ Архітектура потоків даних − Послідовні пакети. − Канали і фільтри. ♦ Незалежні компоненти. − Паралельні взаємодіючі процеси. − Клієнт - серверні системи. − Системи, керовані подіями. ♦ Віртуальні машини. − Інтерпретатори. − Системи, засновані на правилах. ♦ Репозиторні архітектури. − Бази даних. − Гіпертекстові системи. − Дошки оголошень. Архітектура та проектування програмного забезпечення 12 ♦ Рівневі архітектури. Більшість з цих архітектур детально розглядаються в темі 3. Існує широкий спектр проблем, що вимагають програмного рішення, але існує також широкий спектр архітектур, необхідної для їх вирішення. Можливо, одна з архітектур, запропонованих Шоу і Гарланом відповідатиме вашому завданню або хоч би підкаже ідею декомпозиції. 2.5. Зразки проектування: вступ Зразок проектування - це знайдена на основі досвіду комбінація компонентів, зазвичай класів або об'єктів, яка вирішує певні загальні проектувальні завдання. Скористаємося аналогією з архітектурою будинку і розглянемо завдання проектування відокремленої будівлі на обширній території. Архітектура Ранчо (одноповерховий будинок) повністю задовольняє цим вимогам. Відмітьте, що Ранчо указує на загальну ідею проектування, що передбачає безліч реалізацій, і зовсім не є незмінним безліччю планів будинку. Гамма представив увазі співтовариства розробників зразки проектування в тепер уже класичній книзі [33]. Гам ма розглядає двадцять три зразки проектування, розділяючи їх на структурну, креационную і поведінкову категорії. Структурні зразки проектування мають справу із способами представлення об'єктів (такими, як дерева або зв'язні списки). Вони зручні у багатьох випадках оскільки дозволяють користуватися безліччю об'єктів як єдиним цілим. Креационний зразок проектування пов'язаний із способами створення складних об'єктів, таких як лабіринти і дерева. Поведінковий зразок проектування дозволяє нам стежити за поведін кою об'єктів, наприклад, видаючи звіт про колекцію об'єктів в певному порядку. Хоча існує значно більше зразків проектування, чим приведено в [33], ми все ж таки зосередимо нашу увагу на застосуванні розглянутих зразків проектування. Архітектура та проектування програмного забезпечення 13 Зразки проектування можуть бути застосовані на рівні архітектури і (або) на рівні детального проектування. Список зразків проектування, особливо корисних на рівні архітектури, представлений в табл. 5.1. Далі в цьому розділі ми поступово розкриємо їх сенс. Таблиця 5.1. Узагальнення зразків проектування архітектури Цалі проектування Зразок проектування Див. розділ Забезпечити інтерфейс для безлічі об'єктів різних класів Facade 5.3.2.1 Змусити обьект поводитися відповідно його поточному стану Slate 5.3.2.3. Інкапсулювати шляхи відвідин об'єктів в колекції так, щоб клієнтський код міг вибирати шляхи - посещения - під час виконання Iterator 5.3.4.1 Забезпечити реакцію потрібних елементів на зміни в джерелі даних Observer 5.3.2.2.1 Інтерпретувати формальної граматики виразу на мові Interpreter 5.3.4.1 Застосування кожного зразка проектування залежить від клієнта — коди, яка потребує сервісу, що надається зразком проектування. Клієнт посилається на точку входу зразка проектування (з вичайно це метод класу усередині зразка). Крім того, зазвичай мається на увазі і третій тип коди, яку можна назвати настановним кодом. Він встановлює стан зразка проектування. Настановний код не призначений для повторного використання і надає клієнтам можл ивість легко взаємодіяти із зразком Архітектура та проектування програмного забезпечення 14 проектування. Зокрема, для роботи з образному проектування клієнтові слід знати якомога менше про його структуру і внутрішню роботу. 2.6. Компоненти У другій половині 90 - х років сильно зріс інтерес до поняття «компонент ». Компонентами є повторно використовувані об'єкти, які не вимагають знання програмного забезпечення, що використовує їх. Наочним прикладом технології компонентів можуть служити об'єкти СОМ і Java Beans. Компоненти можуть бути об'єктами в звичайному розумі нні об'єктно - орієнтованого програмування, але з невеликими поправками на забезпечення їх автономності. Одні компоненти використовуються іншими за допомогою агрегації і взаємодіють в основному за допомогою подій. Узагальнення зв'язків між каркасом, архітект урою, детальним проектуванням, моделями і зразками проектування показано на рис 9 . Зразки проектування можуть бути використані і на рівні каркаса, і усередині проектних класів на рівні архітектури, і на рівні детального проектування. Зазвичай ніхто не нам агається застосувати зразки проектування усередині класів наочної області, оскільки останні розроблені індивідуально і відповідають безпосередньо безлічі вимог. Як далі буде показано, зразки проектування часто вимагають введення класів, що не є класами нао чної області, наприклад абстрактних класів. Архітектура та проектування програмного забезпечення 15