В рамках UML-моделі всі уявлення про систему фіксуються у вигляді спеціальних графічних

Лекція 3

Огляд видів діаграм UML

Навіщо будувати діаграми

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

Моделі складних систем будуються тому, що неможливо описати їх повністю, окинути одним поглядом. Тому необхідно виділити лише суттєві для конкретної задачі властивості системи та будуємо її модель, що відображає ці властивості.Метод об'єктно-орієнтованого аналізу дозволяє описувати реальні складні системи найбільш адекватним чином. Але зі збільшенням складності систем виникає потреба у хорошій технології моделювання. Як така "стандартна" технологія використовується уніфікована мова моделювання (Unified Modeling Language, UML), яка є графічною мовою для специфікації, візуалізації, проектування та документування систем. За допомогою UML можна розробити докладну модель створюваної системи, яка відображатиме не лише її концепцію, а й конкретні особливості реалізації.

У рамках UML-моделі всі уявлення про систему фіксуються у вигляді спеціальних графічних конструкцій, що дістали назву діаграм

Лише набір діаграм становить модель системи і найповніше її описує, але не одна діаграма, вирвана з контексту.

Види діаграм

UML 1.5 визначав дванадцять типів діаграм, розділених на три групи:

чотири типи діаграм представляютьстатичну структуру докладання ;
п'ять представляютьповедінкові аспекти системи ;
три представляютьфізичні аспекти функціонування системи (діаграми реалізації).

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

Будуть розглянуті деякі з них, оскільки кількість типів діаграм для конкретної моделі конкретної програми не є суворо фіксованою. Для простих програм немає необхідності будувати все без винятку діаграми. Наприклад, длялокального докладання не обов'язково будувати діаграму розгортання.

Важливо розуміти, що перелік діаграм залежить від специфіки проекту, що розробляється, і визначається самим розробником. Стандарт UML описує всі види діаграм: (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML ).

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

Отже, ми коротко розглянемо такі види діаграм, як:

діаграма прецедентів;
діаграма класів;
діаграма об'єктів;
діаграма послідовностей;
діаграма взаємодії;
діаграма станів;
діаграма активності;
діаграма розгортання.

Основне завдання – сприймати та розрізняти діаграми візуально.

Висновок - ООП та послідовностіпобудови діаграм

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

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

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

Діаграми, як уже говорилося вище, можна і потрібно будувати у певній логічній послідовності. Але як створити цю послідовність, якщо у вас немає досвіду моделювання? Як навчитися цьому? Ось кілька найпростіших прийомів, які допоможуть вам (або вашій команді) виробити свій стиль проектування.

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

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

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

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

Все вищезгадане відноситься, перш за все, саме до об'єктно-орієнтованих систем.

Тому, підсумовуючи все сказане раніше, можна запропонувати таку послідовність побудови діаграм:

діаграма прецедентів,
діаграма класів,
діаграма об'єктів,
діаграма послідовностей,
діаграма кооперації,
діаграма станів,
діаграма активності,
діаграма розгортання.

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

Ще кілька порад щодо використання UML:

§ Хороша і корисна вправа - будувати моделі класів та відносин між ними для вже написаного вами коду на С++ чи Java.

§ Застосовуйте UML для того, щоб прояснити неявні деталі реалізації існуючої системи або використані в ній "хитрі механізми програмування".

§ Будуйте UML-моделі, перш ніж розпочати новий проект. Тільки коли ви будете абсолютно задоволені отриманим результатом, починайте використовувати їх як основу для кодування.

§ Зверніть особливу увагу на засоби UML для моделювання компонентів, паралельності, розподіленості,патернів проектування. Більшість із цих питань ми розглянемо далі.

§ Крім іншого, важливим моментом тут є вибірпакета UML моделювання (CASE-засоби), що також може вплинути на ваш індивідуальний стиль проектування. Більш докладно ми поговоримо про це в одній з наступних лекцій, поки що зазначимо, що всі діаграми, які ви бачили в цій лекції, побудовані за допомогою TAU G2 від Telelogic.

Остаточні висновки:

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

Контрольні питання

Чому потрібно будувати різні діаграми під час моделювання системи?

Які діаграми відповідають статичному уявленню про систему?
Ви розробляєте комп'ютерну програму для гри у шахи. Яка діаграма UML була б корисною у цьому випадку? Чому?
Складіть список запитань потенційному користувачеві такої програми. Поясніть, чому ви хотіли б поставити саме їх.

Лекція 3

Огляд видів діаграм UML

Навіщо будувати діаграми