3.3. Структура мови uml

UML дозволяє описувати систему наступними моделями:

- Модель функціонування (показує, як описується функціональність системи з точки зору користувача).

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

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

Діаграми UML призначені для візуального відображення моделей та їх компонентів.

UML 2.0 містить 13 типів діаграм. У тому числі:

- Структурні діаграми (6).

- Діаграми поведінки (3).

- Діаграми взаємодії (4).

Розглянемо кожну з груп детальніше:

Структурні діаграми:

- Діаграма класів - показує класи, їх атрибути та зв'язки між класами.

- Діаграма компонентів - показує компоненти і зв'язки між ними.

- Структурна діаграма - показує внутрішню структуру класів і зв'язки з зовнішнім світом.

- Діаграма розгортання - показує, як ПО розміщується на апаратурі (серверах, робочих станціях ...).

- Діаграма об'єктів - показує структуру системи в конкретний момент часу, об'єкти, їх атрибути ...

- Діаграма пакетів - показує, як система розкладається на великі складові частини та зв'язки між цими частинами

Діаграми поведінки:

- Діаграма дії - показує потоки інформації в системі.

- Діаграма стану - представляє собою кінцевий автомат, що показує функціонування системи.

- Діаграма варіантів використання - показує роботу системи з точки зору користувачів.

Діаграми взаємодії:

- Діаграма кооперації - показує структурну організацію беруть участь у взаємодії об'єктів.

- Діаграма взаємодії (новація UML 2.0).

- Діаграма послідовності - показує тимчасову впорядкованість подій.

- Тимчасова діаграма - діаграма пов'язана з тимчасовими рамками проекту.

3.4. Навчальний приклад. Постановка завдання

На ринок вийшла нова авіакомпанія «GlobalAvia». Менеджери компанії вирішили замовити у вашої фірми розробку системи бронювання квитків. При замовленні фірма поставила ряд умов, які обов'язково повинні бути виконані. У першій версії системи вони хочуть бачити дві частини. Робота першої частини системи пов'язана з занесенням інформації. Друга частина системи призначена для спілкування з клієнтами.

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

- Завдання є математичною. Система повинна вміти вирішувати однокрітеріальним завдання пошуку найкоротших шляхів на графах. Критерій - ціна.

- Система розподілена: оскільки в кожному аеропорту своя база напрямків польотів літаків, то знають про рейс тільки аеропорти-сусіди по рейсам.

Об'єкти системи: розподілене сховище рейсів, покупець квитків, менеджер рейсів.

- Розподілене сховище рейсів: назва рейсів, номера та ціни на квитки.

- Покупець: ПІБ, сума. Покупець задає параметри, пов'язані з сумою, яку він хоче витратити. Система повинна підібрати оптимальний маршрут. При відсутності прямих маршрутів система повинна спробувати знайти маршрути з пересадками. Якщо таких не знаходиться, система повинна сказати, що з такими обмеженнями не можна дістатися до місця призначення.

Серед причин:

- Відсутність рейсів в бажаному напрямі навіть з урахуванням пересадок.

- Брак грошей.

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

- Менеджер рейсів: повинен мати такі можливості:

• створення та видалення аеропортів в системі.

• створення та видалення рейсів в аеропортах.