Розділ «18. Технології моделювання бізнес-процесів. Мова UML»

o варіантів використання (use case diagram);

o класів (class diagram);

o кооперації (collaboration diagram);

o послідовності (sequence diagram);

o станів (statechart diagram);

o діяльності (activity diagram);

o компонентів (component diagram);

o розгортки (deployment diagram);

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

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

Рис.18.1. Діаграми UML як складові бізнес-моделі

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

Нотація насамперед є синтаксисом мови моделювання. Наприклад, нотація діаграми класів показує, як саме визначаються такі елементи і поняття, як клас, асоціація та кратність (рис.18.2-18.5).

Рис.18.2. Асоціація у визначенні нотації діаграми класів

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

Рис.18.3. Кратність у визначенні нотації діаграми класів

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

Рис.18.4. Навігація у визначенні нотації UML

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

Рис.18.5. Поняття залежності у визначенні нотації діаграми класів