Діаграми активностей (activity diagrams)
Мал. 3.4. Приклад діаграми активностей
Програмістам корисно чітко уявляти собі всі бізнес-процеси компанії, які будуть порушені їхні новою системою. В даному випадку у компанії ще є бізнес-процес обробки заявок, який вже працює і є у замовника, і його також потрібно зрозуміти. Інакше може виявитися, що упущена якась важлива деталь, яка не дозволяє новій системі повноцінно виконувати свої функції. Наприклад, може виявитися, що підсистема обробки заявок, з якої повинна інтегруватися створювана система, реалізована ... на макросах до Word / Excel! Очевидно, інтегруватися з такою системою досить важко. На цей і подібні факти необхідно вказати замовникові якомога раніше, тому що інакше проект може закінчитися неуспішно - замовник витратить гроші і не отримає потрібних для свого бізнесу сервісів.
Отже, головною сутністю цього типу діаграм є активність (activity) - активний стан системи. в якому вона виконує деяку роботу. Після її завершення відбувається перехід в іншу активність. Можливі й більш складні випадки переходів між активностями. Наприклад, перехід за подією.
На діаграмі повинні бути присутніми символи початку (start) і кінця (finish).
Далі, на діаграмі може використовуватися паралельний розгалужувач (fork), який запускає кілька одночасно працюючих гілок. Такі гілки можуть об'єднуватися (все або тільки частина) конструкцією під назвою паралельний з'єднувач (join).
Нарешті, на діаграмі можуть використовуватися символи логічного розгалуження і логічного з'єднання (decision). На гілках, що йдуть з логічного розгалуження, позначаються умови переходу.
Діаграми розгортання (deployment diagrams)
Тепер настав час в першому наближенні визначити майбутню систему зсередини. Почнемо з діаграм розгортання. які призначені для опису апаратної частини системи.
Описовий та екземплярність види діаграм розгортання співвідносяться між собою, також, як діаграми класів і діаграми об'єктів.
Побудова інженерних креслень на сьогоднішній день також комп'ютеризовано. Найпоширенішими програмними продуктами тут є пакети AutoCAD, Microsoft Visio і ін.
Мал. 3.5. Приклади діаграми розгортання
Діаграми компонент (component diagrams)
Під час обговорення архітектури системи, в якості наступного проміжного результату, може з'явитися діаграма. наведена на рис. 3.6.
Мал. 3.6. Приклад діаграми компонент
Це - діаграма компонент UML. На цих діаграмах представляються компоненти (components) - незалежні модулі ПО. приховують свою реалізацію і взаємодіють один з одним через інтерфейси.
Незалежність компонент виражається в наступному.
- Вони реалізують істотно різну функціональність системи. Наприклад, модуль ClientGUI реалізує користувальницький інтерфейс робочого місця оператора, модулі ClientNetworkSupport і ServerNetworkSupport - підтримку мережевої взаємодії між клієнтом і сервером, модуль ServerBusinessLogic - бізнес-логіку сервера, а модуль RequestDB відповідає за взаємодію з базою даних заявок і синхронізацію з системою обробки заявок.
- Кожен такий модуль незалежний з точки зору фізичної організації - його реалізація прихована від оточення, все його взаємодія з оточенням відбувається за суворо визначеними правилами, а сам він часто виявляється незалежним бінарним файлом (наприклад, DLL-файлом).
- Можлива також незалежність періоду виконання - кожна з компонент може знаходитися або на окремому комп'ютері, або в окремому процесі операційної системи, або працювати в контексті окремої нитки (thread).
- Нарешті, розробку кожного такого модуля можна доручити окремому розробнику або команді розробників, тобто за допомогою компонент організувати поділ колективу програмістів.
В силу своєї незалежності, а також необхідності взаємодії, компоненти мають інтерфейси (interfaces), що дозволяють компонентам приховати їх внутрішній устрій і надати зовні певний спосіб звернення до своїх функцій.
Наданий інтерфейс на діаграмах UML зображується маленьким кружечком, який з'єднаний звичайної лінією зі своєю компонентою. Використання інтерфейсу показується порожній чашкою, яка з'єднана звичайної лінією з компонентою і пунктирною лінією з "споживаним" інтерфейсом.
Поняття компоненти є дуже ємним, і однозначного, точного визначення для нього не існує. Неоднозначність виникає не стільки в зв'язку з різночитаннями дослідників, скільки в зв'язку з поширенням різних технологій і засобів програмування, що використовують це поняття і по-різному його трактують.
Найпоширенішими є компонентні технології - JavaBeans, EJB, CORBA, DCOM. Net. web-сервіси та ін. Вони дозволяють створювати розподілені системи, які, в зв'язку з поширенням Інтернету, виявляються одним з основних напрямків сучасного програмування. Різні визначення поняття компоненти, дискусію і більш глибоке обговорення даного питання можна знайти в [3.8].
Інформація. представлена на діаграмі з рис. 3.6. може з часом змінюватися: інтерфейси уточнюються, додаються нові компоненти, що існують розбиваються на більш дрібні і т. д. Діаграми компонент проекту доцільно підтримувати в актуальному стані, (маючи на увазі ітеративна розробки і внесення в проект будь-яких змін), оскільки компонентне подання системи часто є ядром її архітектури. А мати коректне і компактне опис архітектури завжди корисно, за допомогою такого опису легше стежити за змінами в проекті та утримувати всю картину цілком.
Ще один важливий аспект системи, зображений на цій діаграмі - інтерфейси компонент. Їх потрібно опрацьовувати особливо ретельно і вчасно, оскільки якщо додаток розробляється різними робочими групами, розподіленими географічно, то запізніле узгодження інтерфейсів може зажадати серйозних модифікацій в уже написаному коді.
Мал. 3.7. Приклад розміщення компонентів на діаграмах розгортання
Відзначимо, що опис типів вузлів діаграм розгортання проводиться на описовому, а не на екземплярність рівні.
Зауважимо, що саме діаграма з рис. 3.6 є "кандидатом в довгожителі" в процесі розробки, оскільки лаконічна і не містить зайвої інформації. Те, які саме компоненти розташовуються на сервері, а які на клієнті - не дуже важлива деталь тут, оскільки система не дуже велика, все це і так пам'ятають. Крім того, факт розподілу компонент по апаратурі не є тут предметом змін, як в більш складній системі, де існує кілька різних серверів, клієнти різних типів і т. Д. Діаграма з рис. 3.7 є, скоріше, "разової" і корисна для будь-якого звіту, для розмов з замовником і т. Д.