Відношення узагальнення
Відношення узагальнення(generalization) призначено для специфікації того факту, що один елемент моделі являється спеціальним чи частковим випадком іншого елемента моделі.
Головною особливістю відношення узагальнення являєтся те, що воно може зв’язувати між собою тільки елементи одного типу. Графічно відношення узагальнення позначається суцільною лінією зі стрілкою в формі не замальованого трикутника, яка вказує на загальний елемент моделі.
Варіант використання Б, який являється нащадком наслідує всі властивості поведінки свого батька, тобто варіанта використання А.
Стосовно до варіантів використання семантика даного відношення вказує на той факт, що варіант використання Б являється спецалізацією варіанта використання А. При цьому варіант використання А називається батьком по відношенню до варіанта використання Б, а в свою чергу Б називається нащадком чи дочірнім по відношенню до варіанта використання А. Необхідно відмітити, що нащадок наслідує всі властивості поведінки свого батька, а також може мати додаткові особливості поведінки.
Відношення узагальнення між варіантами використання використовуєтсья в тому випадку, коли необхідно відмітити, що дочірні варіанти використання мають усі особливості поведінки батьківських варіантів використання. В свою чергу, нащадки можуть бути наділеними новими властивостями поведінки, які відсутні у батьківських варіантів використання, а також уточнювати чи модифікувати успадковані від них властивості поведінки.
В мові UML 2.0 один варіант використання може мати декілька батьківських варіантів використання. В цьому випадку реалізується так назване множинне успадкування властивостей та поведінки усіх батьківских варіантів використання. З іншої сторони, один варіант використання може бути батьком для декількох дочірніх варіантів використання, що відповідає таксономічному характеру відношення узагальнення.
Між акторами також може існувати відношення узагальнення. Дане відношення являється напрямленим та вказує на факт спеціалізації одних акторів відносно інших. Наприклад, відношення узагальнення від актора Б до актора А відмічає той факт, що кожен екземпляр актора Б являється одночасно екземлпяром актора А та наділений усіма його властивостям. В цьому випадку актор А являється батьком по відношенню до актора Б, а актор Б, відповідно, нащадком актора А. При цьому актор Б має можливість відігравати таку ж множину ролей, що і актор А. Графічно дане відношення також позначається стрілкою узагальнення, яка вказує на батьківського актора.
На практиці два чи більше акторів можуть мати загальні властивості, наприклад, вони можуть взаємодіяти з однією й тією ж самою множиною варіантів використання однаковим чином. Така загальність властивостей та поведінки може бути представлена в формі відношення узагальнення з іншим, можливо, абстрактним актором, який моделює відповідну загальність ролей.
Формалізація функціональних вимог до системи за допомогою діаграм варіантів використання
Варіанти використання являються засобом для специфікації вимог до систем, тобто того, що проектуєма система передбачаємо повинна робити. Вимагаєма поведінка системи чи суб’єкта специфікується одним чи декількома варіантами використання, які визначаються у відповідності до потреби акторів. Ця поведінка, включаючи взаємодію між акторами та суб’єктом, можуть привести в результаті до зміни стану суб’єкту та його комунікації з оточенням.
Вимога(requirement) – Бажана властивість, характеристика чи умова, яку повинна задовольняти система в процесі своєї експлуатації.
На практиці при розробці програмних систем рекомендується притримуватись наступного правила – окремому варіанту використання повинні відповідати деякі вимоги до функціональної поведінки моделюємої системи.
Класифікація вимог до моделі FURPS+
Стосовно до програмних систем запропонована наступна класифікація вимог, яка отримала назву моделі FURPS+, що відповідає першим буквам відповідних категорій вимог на англійскій мові:
-функціональні вимоги(Functionality);
-вимоги зручності використання(Usability);
-вимоги до надійності(Reliability);
-вимоги до продуктивності(Performance);
-вимоги до зручності супроводу(Supportability);
При цьому символом + позначені додаткові вимоги, до яких відносяться:
-проектні обмеження;
-вимоги до управління системою;
-вимоги до графічного інтерфейсу користувача;
-фізичні вимоги;
-юридичні вимоги.
Центральне місце серед вказаних вимог займають функціональні вимоги, які в контексті моделей UML 2.0 повинні служити вихідною інформацією для побудови діаграм варіантів використання. Однак на практиці однієї графічною нотації мови UML 2.0 може виявитись недостатнім для специфікації функціональних вимог.
Побудова діаграми варіантів використання являється самим першим етапом процесу об’єктно орієнтованого аналізу та проектування, ціль якого – представити сукупність функціональних вимог до поведінки проектуємої системи. Специфікація вимог до проектуємої системи в формі діаграми варіантів використання і додаткових сценарієв може представляти собою самостійну модель, яка на мові UML отримала назву моделі варіантів використання та має своє спеціальне ім’я чи стереотип <<UseCaseModel>>.
Далі усі задані в цій моделі вимоги можуть бути представлені у вигляді загальної моделі системи, яка може бути оформлена у вигляді окремого пакету з іменем СИСТЕМА. Цей пакет в свою чергу може представляти собою ієрархію пакетів, на самому верхньому рівні якої знаходиться множина класів, що реалізують базові варіанти використання проектуємої системи. При цьому пакет системи самого верхнього рівня може бути додатково помічений стереотипом <<topLevelPackage>>. Однією з вимог самої мови UML 2.0 являється самодостатність графічних діаграм для представлення інформації о моделях проектуємих систем. Однак більшість розробників та експертів згодні з тим, що зображувальних засобів мови UML 2.0 недостатньо, для урахування на діаграмах варіантів використання особливостей функціональної поведінки достатньо складної системи. З цією ціллю рекомендується доповняти цей тип діаграм текстовими сценаріями, які уточнюють чи деталізують послідовність дій системи при реалізації своєї поведінки.
Деякі розробники, що з оптимізмом прийняли роботу А.Кокберна по написанню ефективних варіантів використання, рекомендують взагалі відмовитись від графічного зображення останніх. Судячи з усього, адепти текстових сценрієв забувають про існування в мові UML 2.0 інших типів діаграм, оскільки їх основним аргументом проти зображення діаграм варіантів використання являється перевантаженість чи надлишок візуальних елементів. Дійсно, при розробці діаграм варіантів використання потрібно вчасно зупинитися та не намагатися на етапі концептуального моделювання зображати логіку чи послідовність виконання окремих дій. Для останньої цілі в мові UML 2.0 спеціально призначені діаграми послідовності та діяльності, що будуть розглядатися далі.