Практичні рекомендації по використанню UML та Rational Rose при проектуванні ПС.
Завантажити презентаціюПрезентація по слайдам:
Практичні рекомендації по використанню UML та Rational Rose при проектуванні ПС. Діаграми взаємодій. Діаграми класів 2004 (Курс “Інформаційні технології”) Діаграми взаємодій
Окремі кроки при проектуванні ПС з використанням UML та Ratoinal Rose 0. Ділове моделювання. 1. А. Розроблення діаграм прецедентів. Визначаються кордони системи. Представляються функціональні можливості системи. Б. Деталізація прецедентів - опис потоків подій прецедентів або (як мінімум) основних сценаріїв прецедентів. 2. Розроблення діаграм послідовностей як графічних представлень сценаріїв прецедентів. Двохетапний підхід до проектування діаграм послідовностей: Перший етап - високорівневе проектування (об’єкти та послідовність повідомлень, якими об’єкти обмінюються). Другий етап - проектування з виявленням та початковою розробкою класів, співставлення об’єктів та повідомлень, виділених на першому етапі, з класами та операціями (класів). 3) Розроблення діаграм класів. 4) Використання кодогенерації. Діаграми взаємодій
Графічне представлення сценаріїв. Діаграми послідовностей. Двохетапне розроблення діаграм послідовностей. Узгодженість (цілісність) моделей Діаграми послідовностей є графічними представленнями сценаріїв прецедентів, але при цьому їх також слід розглядати як важливий крок на шляху до розроблення діаграм класів. При проектуванні діаграм послідовностей доцільно використовувати два (а то й більше) етапи. На першому етапі відбувається високорівневе проектування, коли основною задачею є виділити об’єкти та відобразити події сценаріїв у послідовність повідомлень, якими обмінюються такі об’єкти. На другому етапі не тільки уточнюються класи об’єктів та операції, що співвідносяться з повідомленнями, але й можуть з’являтись додаткові об’єкти (та класи). Діаграми взаємодій
Діаграма послідовності для сценарію “Викладач формулює тему дипломної роботи” (перший етап) Діаграми взаємодій
Характеристика класів ПС та їх виявлення 1. Класи етапу аналізу: прикордонні (boundary) класи або інтерфейсні класи; класи-сутності (entity); управляючі (control) класи (класи-менеджери). 2. Класи етапу проектування: класи, залежні від мови програмування (TForm, TDialog тощо при проектуванні інтерфейсів користувача); класи, що додаються на етапі проектування (наприклад, для таблиці паролів). Діаграми взаємодій
Діаграма послідовності для сценарію “Викладач формулює тему дипломної роботи” (другий етап) Діаграми взаємодій
Пакетування класів. Діаграми класів Пакетування класів (організація класів у пакети) дозволяє отримувати моделі більш високого рівня абстракції. Принципи організації класів у пакети: 1) виходячи з логіки, функціональності, відповідальності тощо (наприклад, класи з даними про особи, класи з даними рівня кафедри, класи з даними рівня факультету, класи звітів, класи безпеки, класи для обробки помилок); 2) виходячи зі стереотипів, зокрема трьох основних стосовно класів; 3) комбінуючи перші два на різних рівнях (наприклад, на верхньому - за логікою, на нижньому - за стереотипами). Рекомендації до розроблюваних діаграм класів: головна діаграма - на рівні пакетів; кожен пакет має власну головну діаграму (“розкривається” - DubleClick). Діаграми взаємодій
Відношення між класами, їх виявлення Типи відношень між класами: асоціація(важливі випадки - агрегація та композиція); залежність; узагальнення. Якщо є повідомлення між об'єктами двох класів (на діаграмі взаємодій), то між ними встановлюються відношення асоціації чи залежності (направленість - від “клієнта” до “постачальника” сервісу). (У випадку асоціації клас-клієнт має інформацію про знаходження постачальника сервісу). Залежність завжди є однонаправленою, асоціація може бути одно- чи двонаправленою. Агрегація представляє відношення ”ціле- частина”. Композиція - це агрегація, коли існування частини повністю залежить від існування цілого (входження за значенням - by value). Діаграми взаємодій
Проектування відношень між класами При проектуванні відношень між класами асоціації бажано створювати однонаправленими (такі асоціації легше реалізовувати та підтримувати). Іноді доцільно однонаправлені асоціації перетворити у залежності (вони ще простіші у реалізації). У такому випадку інформація про знаходження постачальника сервісу найчастіше передається як параметр відповідної операції. Деякі подальші важливі кроки проектування відношень: кратність; використання імен ролей. Діаграми взаємодій
Схожі презентації
Категорії