5.1 Концепція методу

Метод UML [1] (Unified Modeling Language — уніфікована мова моделювання) є рідкісним прикладом плідної кооперації групи (G. Booch, I. Jacobson, J. Rumbaugh) провідних спеціалістів з програмної інженерії і авторів відповідних методів інженерії вимог, що набули значного визнання і широко застосовуються. Дослідивши всі переваги власних пропозицій і широкий спектр конкуруючих, вони інтегрували свої зусилля, створивши новий метод моделювання, якому дали цитовану вище назву UML. UML став базовим для багатьох провідних розробників програмного забезпечення, і тепер експерти прогнозують, що він набуде статусу міжнародного стандарту як метод моделювання продуктів усіх стадій життєвого циклу розробки програмних систем.

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

В основу методу покладено парадигму об’єктного підходу, за якою концептуальне моделювання проблеми (дивись п. 3.2) відбувається в термінах взаємодії об’єктів:

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

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

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

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

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

а) діаграми класів;

б) діаграми сценаріїв;

в) діаграми поведінки об’єктів, а саме:

1) діаграми послідовності;

2) діаграми співробітництва;

3) діаграми активності;

4) діаграми станів;

г) діаграми реалізації, а саме:

1) діаграми компонент;

2) діаграми розміщення.

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

Кожний вид діаграм відображає різні перспективи бачення й розуміння моделі. У моделі може бути по кілька діаграм кожного з описаних видів.

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

Рисунок 5.1 - Коментар UML

Другий тип коментарю названо стереотипом. Стереотип (stereotype) - це засіб метакласифікації елементу в UML. Він є специфічним стандартизованим коментарем щодо категорії елементу, поданого на будь-якій діаграмі, своєрідним ярликом, який характеризує зміст елементу діаграми або його призначення.

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

Певні стереотипи є фіксованими в UML і мають стандартні назви, як-от: «актор», «система», «підсистема», «подія», «виняткова ситуація», «інтерфейс», «метаклас», «послуга» (утиліта) та ін.

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

Зупинимося на змісті окремих діаграм детальніше.