• Лекція 7
• Уніфікований процес розробки. Аналіз і проектування
  • 7.1 Життєвий цикл ПЗ в RUP
  • 7.2 Аналіз в RUP
  • 7.3 Мета процесу аналізу
  • 7.4 Модель аналізу (analysis model)
  • 7.5 Модель ВВ та модель аналізу
  • 7.6 Робочий процес аналізу вимог
    • 7.6.1 Порядок розробки моделі аналізу
    • 7.6.2 Діяльність: аналіз архітектури
  • 7.7 Артефакт: клас аналізу
    • 7.7.1 Граничний клас (Boundary class)
    • 7.7.2 Клас сутності (Entity class)
    • 7.7.3 Керуючий клас (Control class)
  • 7.8 Артефакт: аналіз реалізації ВВ
    • 7.8.1 Діаграма класів аналізу (ВВ Придбання квитків)
    • 7.8.2 Діаграма комунікації (ВВ Оплата замовлення)
    • 7.8.3 Діаграма послідовності (ВВ Оплата замовлення)
• Проектування в RUP
  • 7.9 Мета процесу проектування
  • 7.10 Робочий процес проектування
  • 7.11 Модель проектування (design model)
  • 7.12 Модель проектування
  • 7.13 Співставлення моделі аналізу та моделі проектування
  • 7.14 Робочий процес проектування
    • 7.14.1 Властивості моделі проектування
    • 7.14.2 Порядок розробки моделі проектування
    • 7.14.3 Артефакт: клас
    • 7.14.4 Артефакт: проект реалізації варіанту використання
    • 7.14.5 Діаграми для Проектування ВВ
    • 7.14.6 Артефакт: інтерфейс
  • 7.15 Модель розгортання (deployment model)
  • 7.16 Діаграма розгортання

Лекція 7

Уніфікований процес розробки. Аналіз і проектування

7.1        Життєвий цикл ПЗ в RUP

7.2        Аналіз в RUP

7.3        Мета процесу аналізу

• Точніше зрозуміти вимоги та структурувати їх

• Отримати зручний для реалізації опис вимог, у т.ч. для розуміння структури системи.

7.4        Модель аналізу (analysis model)

Аналіз виконується з метою уточнення та структурування вимог.

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

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

Модель аналізу (analysis model) – детальний опис усіх вимог та потрібних для реалізації ПП робіт, у т.ч. діаграми діяльності, діаграми послідовності та деталізовані сценарії ВВ.

Виділяється якомога більше повторно використовуваних компонентів.

Модель аналізу

Модель аналізу – ієрархія пакетів аналізу, класів аналізу та аналізу реалізацій ВВ

Пакети аналізу – абстракція майбутніх підсистем

7.5        Модель ВВ та модель аналізу

7.6        Робочий процес аналізу вимог

ВВ представляються як сукупність класів аналізу та їх об’єктів.

7.6.1        Порядок розробки моделі аналізу

1. Ідентифікуються класи аналізу

2. Проектуються класи аналізу

3. Проектуються реалізації ВВ як сукупність діаграм UML

4. Класи групуються за допомогою пакетів аналізу

7.6.2        Діяльність: аналіз архітектури

7.7        Артефакт: клас аналізу

Клас аналізу – абстракція одного чи кількох класів системи.

Характеристики:

буває одного із 3-х стереотипів: граничний, керуючий, сутності

зосереджений на функціональних вимогах

частіше описує поведінку у термінах відповідальностей, ніж операцій

визначає атрибути на концептуальному рівні

Артефакт: клас аналізу

Приклад 1. Онлайн-купівля квитків

7.7.1        Граничний клас (Boundary class)

Граничний клас (Boundary class) – абстракція взаємодії актора із системою (опис запитів та інформації, що передається в ході взаємодії).

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

Спеціальні вимоги документуються як додатковий опис класів.

Клас Інтерфейс редактору замовлень надає клієнтові передивлятися замовлення та редагувати його.

Клас Інтерфейс запиту на оплату дозволяє клієнтові помітити замовлення на оплату та надісліти його на виконання оплати.

Класи Інтерфейс оплати забезпечує зв’язок із платіжною системою, через яку виконується оплата замовлення поміченого на оплату.

7.7.2        Клас сутності (Entity class)

Клас сутності (Entity class) – абстракція інформаційного наповнення та зв’язків об’єктів (опис логічної структури даних та залежностей системи від них).

Клас Подія є класом тривалого зберігання.

Клас Рахунок є класом, який існує протягом 15 хв., виділених на оплату замовлення.

7.7.3        Керуючий клас (Control class)

Керуючий клас (Control class) – відповідає за координацію та послідовність взаємодії об’єктів (опис динаміки системи).

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

Динаміка системи моделюється саме керуючими класами, тому що вони обробляють та координують основні дії та потоки управління та делегують роботу іншим об'єктам (граничним та об'єктам сутностей).

Класи Обробник замовлення та Запит на оплату повинні виконувати до 10 000 транзакцій/год

7.8        Артефакт: аналіз реалізації ВВ

Аналіз реалізації варіанту використання – кооперація для опису реалізації ВВ класами аналізу та їх об’єктами.

Складається із:

потоку подій (Flow of events) із діаграмами діяльності (Activity diagrams)

діаграм класів (Class diagram)

діаграм взаємодії (Interaction Diagrams):

• • • Communication diagrams

    • Sequence diagrams

    • Interaction overview diagrams

    • Timing Diagrams

спеціальних вимог

Діаграма діяльності – послідовність дій, які виконуються у ЖЦ відповідних екземплярів ВВ

Діаграма класів – визначає структуру ієрархії системи у термінах класів

Діаграма комунікації – визначає взаємодію між частинами структури системи – класами аналізу

Діаграма станів – визначає ЖЦ екземплярів ВВ в поняттях станів та переходів між станами

Діаграма послідовності – визначає взаємодію між екземпляром актора та екземпляром ВВ

7.8.1        Діаграма класів аналізу (ВВ Придбання квитків)

7.8.2        Діаграма комунікації (ВВ Оплата замовлення)

Потік подій - аналіз, що пояснює діаграму комунікації.

Клієнт переглядає рахунок через Інтерфейс запиту на оплату. Інтерфейс запиту на оплату використовує Оброблювач Замовлень, щоб перевірити рахунки за відповідними підтвердженням замовлень (3, 4, 5) перед тим, як показати їх покупцеві. як будет проводитися ця перевірка, залежить від бізнес-правил, встановлених фірмою покупця; вони можуть включати в себе порівняння цін, дати поставки та комплекту поставки за рахунком і підтвердженню замовлення. Об'єкт обробника Замовлення використовує ці бізнес-правила, щоб вирішити, які питання (на малюнку відповідають повідомленнями Взяти 4, 5) слід задати, щоб запросити Підтвердження Замовлення або Відхилити Рахунок, і як аналізувати відповіді. Передбачається, що в резуль таті рахунок буде якось позначений Інтерфейсом запиту на оплату, можливо, з використанням різнокольорового підсвічування.

Покупець вибирає рахунок через Інтерфейс запиту на оплату і позначає рахунок до оплати (6). Інтерфейс запиту на оплату запитує Планувальник Оплат на мітити оплату рахунку (7). Планувальник Оплат створює вимога на оплату (8).

Інтерфейс запиту на оплату потім змінює стан рахунку на «намічений до оплати» (9).

Запит на оплату через Інтерфейс оплати звертається до Платіжної системи, если оплата виконан, Рахунок переходити у статус оплачений.

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

7.8.3        Діаграма послідовності (ВВ Оплата замовлення)

Проектування в RUP

7.9        Мета процесу проектування

• Опис форми системи, яка забезпечує її цілісність та стійкість до змін

• Опис структурних елементів системи, у т.ч. Повторно використованих

7.10        Робочий процес проектування

7.11        Модель проектування (design model)

Модель проектування (design model) – об'єктна модель, що містить опис фізичної реалізації ВВ, та сконцентрована на тому, які функціональні та нефункціональні вимоги разом із обмеженнями середовища розробки реалізують систему.

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

Для:

• формування глибокого розуміння моментів, які відносяться до нефункціональних вимог і обмежень, пов'язаних з мовами програмування, багаторазовим використанням компонентів, операційними системами, технологіями розподіленої і паралельної обробки, технологіями баз даних, управління транзакціями і т. ін.

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

• отримання можливості розбити реалізацію на безліч керованих частин, щоб забезпечити завданнями різні команди розробників, можливо, діючі паралельно.

• визначення основних інтерфейсів між підсистемами на ранній стадії ЖЦ системи. Це допоможе пояснити архітектуру і дасть можливість використовувати ці інтерфейси як засіб синхронізації

різних команд розробників.

• формування якісної абстракції реалізації системи

7.12        Модель проектування

7.13        Співставлення моделі аналізу та моделі проектування

7.14        Робочий процес проектування

7.14.1        Властивості моделі проектування

• Має ієрархічну структуру

• Проект реалізації ВВ – стереотипи кооперації класів проектування та їх об’єктів

7.14.2        Порядок розробки моделі проектування

1. Ідентифікуються класи

2. Виділяються відповідальності

3. Проектуються класи та реалізації ВВ

4. Класи проектування збирають у підсистеми

5. Визначають інтерфейси між підсистемами

7.14.3        Артефакт: клас

Клас (class) – опис набору об'єктів, що мають однакові атрибути, операції, відношення та семантику

Операція (operation) – реалізація сервісу, який викликається будь-яким об'єктом класу для реалізації його поведінки

Атрибут (attribute) – властивість класифікатора, набір значень, що можуть приймати екземпляри класу

Артефакт: клас проектування

Клас проектування (class) – абстракція класу системи, найбільш наближена до реальної реалізації.

Характеристики:

• використовує обрану мову програмування

• визначається видимість атрибутів та операцій

• визначені відношення реалізуються в системі

7.14.4        Артефакт: проект реалізації варіанту використання

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

Складається із:

• діаграм класів (Class diagram)

• діаграм станів/автоматів (State machine diagrams)

• діаграм взаємодії (Interaction Diagrams):

  • • Communication diagrams

    • Sequence diagrams

    • Interaction overview diagrams

    • Timing Diagrams

• вимог до реалізації

7.14.5        Діаграми для Проектування ВВ

Діаграма огляду взаємодії (Interaction Overview Diagram ) показує потік управління може бути ініційований у сценаріях ВВ. Огляд потоку управління, містить вузли є взаємодією (sd) або використанням взаємодії (ref).

Діаграма синхронізації (Timing Diagram) описує поведінку як окремих класифікаторів, так і взаємодій класифікаторів, зосереджуючи увагу на часу виникнення подій.

Приклад 1. Діаграма огляду взаємодії (ВВ Придбання квитків)

Приклад 1. Діаграма синхронізації

Приклад 1. Діаграма класів (ВВ Оплата замовлення)

7.14.6        Артефакт: інтерфейс

Інтерфейс (interface) – абстракція визначення операцій класу або підсистеми.

• інтерфейси між підсистемами впливають на архітектуру

Інтерфейс надає спосіб відділення специфікації функціональності в термінах операцій від її реалізації в термінах методів.

Опис архітектури

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

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

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

Опис архітектури

На архітектуру впливають:

• декомпозиція системи на підсистеми, інтерфейси

• ключові класи проектування

• проекти реалізації критичних ВВ

Ключові класи проектування походять від ключових класів аналізу, можуть містити спільні частини кількох класів і взаємодіють із великою кількістю інших класів.

7.15        Модель розгортання (deployment model)

Модель розгортання (deployment model) – визначає фізичний розподіл системи у вузлах мережі, перевіряє чи можуть ВВ бути реалізовані у вигляді компонентів, які виконуються в цих вузлах.

Модель розгортання є вихідними даними для роботи з проектування та реалізації.

Кожен вузол являє собою обчислювальний ресурс, зазвичай процесор або інший пристрій.

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

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

• Функціональність (або процес), що виконується на вузлі, визначається компонентами, завантаженими на вузол.

• Саме модель розгортання описує відображення архітектури програм ми на архітектуру системи (обладнання).

7.16        Діаграма розгортання

Діаграма розгортання (Deployment diagram) моделює фізичне розміщення артефактів системи у вузлах мережі.

Приклад 1. Діаграма розгортання