3.5. Візуальний опис функціональної моделі засобами uml

Програмна система не функціонує сама по собі. Програмна система функціонує під впливом акторів (Actor) - користувачів, машин та інших програм. При цьому актор очікує, що система поводиться строго певним чином. Актор впливає - система видає очікуваний результат. У випадку, якщо очікуваного результату немає, вимоги користувача не задоволені з усіма витікаючими звідси результатами. Таким чином, актор в UML - людина, машина чи програма, впливає на систему, є зовнішнім по відношенню до неї. Модель того, як вплив призводить до результату, називається Варіантом використання (Use case). Актори і варіанти використання мають спеціальні позначення в UML:

Актори і варіанти використання спілкуються за допомогою посилки повідомлень. Повідомлення можуть йти в обидві сторони. Стрілка показує ініціатора спілкування (актор на малюнку) і може бути опущена.

Виділимо акторів і варіанти використання в розглянутому раніше прикладі з системою бронювання квитків (SRS). Аналіз постановки задачі показує наявність у системи двох акторів: «Користувач» і «Адміністратор». Визначимося з варіантами використання. Необхідно зазначити, що вибір акторів і варіантів використання до деякої міри умовний і може відрізнятися у різних фахівців з аналізу та проектування. Прийняті проектні рішення визначають подальший вибір архітектури системи і суттєво впливають на успіх всього процесу розробки. При цьому «хороших" варіантів може бути декілька.

Перелік Варіантів використання для нашої задачі може бути, наприклад, таким:

- Забронювати квиток.

- Підібрати рейс.

- Працювати з даними.

- Керувати рейсами.

- Працювати з БД аеропорту.

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

Наведемо деякі додаткові міркування [3]:

- При такому моделюванні звертають увагу на поведінку системи, а не на її реалізацію.

- Хороша модель описує основну поведінку системи, не будучи надто детальним.

- Подібна модель дозволяє перевірити, чи задовольнить система вимоги замовника.

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

- Варіанти використання можуть описуватися різними сценаріями.

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

Діаграма дії це блок-схема, яка відображає динаміку в поведінці системи. Зауважимо, що ця діаграма може використовуватися не тільки для опису сценаріїв Варіанта використання.

Наведемо приклад відповідної діаграми для варіанту використання Бронювання квитків в системі SRS.

3.6. Структура системи та її опис засобами UML

У даному розділі розглядаються елементи UML, призначені для опису структури проектованої програмної системи. Для стандартних понять, відомих з курсу ООП, ми наводимо тільки позначення. Для інших перш за все даємо визначення і коротку характеристику.

Класи

Позначення модифікаторів доступа:

+	public
#	protected
-	private

Шаблони класів

Об’єкти

Інтерфейси

Визначимося з тим, що ми в даному випадку розуміємо під Інтерфейсом.

Інтерфейс визначає межу між специфікацією того, що робить абстракція, і реалізацією того, як вона це робить [3].

Інтерфейс - це набір операцій, які використовуються для специфицирования послуг, що надаються класом або компонентом [3].

Сенс використання Інтерфейсу складається у відділенні деталей реалізації від функціональності. Так, клас, підсистема, компонент зазвичай надають деяку функціональність, якою можуть користуватися інші класи, підсистеми, компоненти. Опис цієї, доступною ззовні, функціональності міститься в інтерфейсі.

У багатьох мовах програмування поняття Інтерфейс включено в об'єктну модель, що відповідає відбивається на синтаксисі (Object Pascal, Java та ін.) С + +, на жаль, не містить поняття Інтерфейс, тому Інтерфейси моделюються за допомогою використання класів.

Пакети

Пакет - структурна одиниця для групування елементів моделі, зокрема, класів.

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

Підсистеми

На етапі проектування системи класи і пакети можуть об'єднуватися в підсистеми. Підсистема - структурна одиниця. Кожна підсистема мають свою область відповідальності і реалізує деяку функціональність. Підсистема реалізує Інтерфейс, який описує її поведінку. У даному навчальному прикладі SRS прикладами підсистем є: підсистема бронювання квитків; підсистема доступу до даних ...

Компоненти

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

Види компонентів:

- Вихідні файли (. cpp,. h,. java ...).

- Бінарні файли (. dll,. ocx ...).

- Виконувані файли (. exe).

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

Коментарі

UML передбачає можливість написання коментарів (нотаток). Робиться це в такий спосіб:

Відносини між елементами моделі

UML підтримує наступні види відносин між елементами моделі:

- Залежність.

- Асоціація.

- Узагальнення (успадкування).

- Реалізація (для Інтерфейсу).

Відносини показують наявність зв'язків між елементами моделі та семантику цих зв'язків.

Розглянемо кожен з цих типів відносин.

Залежність

Залежність - зв'язок між сутностями (класами, об'єктами). Залежність показує, що зміни в одній сутності можуть вплинути на іншу сутність. Залежність - не структурна зв'язок. Виникає через локальну, глобальну змінні або параметр методу.

TFirst зависит от TSecond

Асоціація

Асоціація - зв'язок між сутностями (класами, об'єктами). Асоціація показує наявність структурної зв'язку між екземплярами (об'єктами). Структурна зв'язок реалізується через поле класу. У позначеннях UML напрямок може бути не вказано (двосторонній зв'язок).

TFirst содержит поле, связанное с TSecond

Напрямок та навігація

Зауважимо, що наявність напряму пов'язано з поняттям Навігація. Навігація означає, що в напрямку стрілки один об'єкт «бачить» інший, в той час як зворотне не виконується.

TFirst бачить TSecond

Кратність

Кратність - спосіб конкретизації характеру відносини. Показує тип відносини 1:1, 1:M, N:1, N:M.

Кожному контейнеру відповідає M елементів. Кожному елементу відповідає 1 контейнер.

Вид кратности	Значення
* або 0..*	≥0
1..*	≥1
	Звичайно 0 або 1
	Дорівнює 1
3,5..6	{3,5,6}

Окремі випадки асоціацій: агрегація і композиція

Агрегація припускає, що 0 або більше об'єктів одного типу включені в 1 або більше об'єктів іншого типу.

Композиція - варіант агрегації, в якому кожен об'єкт другого типу може бути включений рівно в 1 об'єкт першого типу.

Композиція

Агрегація