Інженерія програмного забезпечення. Лабораторний практикум.
Лабораторна робота № 2. Розробка ескізного проекту. Створення діаграми варіантів використання (прецедентів).
UML (Unified Modeling Language – Уніфікована мова моделювання) – один з найбільш поширених засобів візуального моделювання, тобто подання моделі програмного продукту за допомогою деякого стандартного набору графічних позначень.
Rational Rose – це потужний інструмент аналізу та проектування об’єктно-орієнтованих програмних систем. Дане середовище дозволяє моделювати систему до написання коду, аби з самого початку забезпечити адекватність її архітектури. За допомогою готової моделі недоліки проекту легко виявити ще на тих стадіях, на яких виправлення не потребують значних витрат.
Типи діаграм uml
Графічні зображення моделей системи в UML називають діаграмами. В термінах мови UML визначено такі їх типи:
діаграма варіантів використання або прецедентів (use case diagram)
діаграма класів (class diagram)
діаграми поведінки (behavior diagrams)
діаграма станів (statechart diagram)
діаграма діяльності (activity diagram)
діаграма взаємодії (interaction diagrams)
діаграма послідовностей (sequence diagram)
діаграма співпраці (collaboration diagram)
діаграми реалізації (implementation diagrams)
діаграма компонентів (component diagram)
діграма розгортання (deployment diagram)
Середовище Rational Rose дозволяє проектувати варіанти використання системи та їх діаграми для відображення функціональних можливостей системи. Діаграма Взаємодії зображає як об’єкти співпрацюють, використовуючи надані функціональні можливості Для відображення об’єктів системи та їх відношень використовуються діаграми Класів. Діаграма компонент відображає як класи співвідносяться з готовими фізичними компонентами системи. І, нарешті, діаграми Розміщення застосовують для візуалізації проекту розподілених систем.
Модель Rose – це картина системи. Вона містить всі діаграми UML, дійових осіб, варіанти використання, об’єкти, класи, компоненти і вузли системи. Вона детально описує що містить система і як вона функціонує, тому розробники можуть використовувати її як ескіз або креслення системи, яка створюється.
Діаграма Варіантів Використання або Прецедентів (Use Case Diagram)
Діаграми варіантів використання зображають функціональне призначення системи або те, що система повинна робити. Розробка діаграми має на меті:
визначити загальні границі і контекст предметної області, яка моделюється;
сформулювати загальні вимоги до функціональної поведінки системи, яка проектується;
розробити вихідну концептуальну модель системи для її подальшої деталізації у формі логічних і фізичних моделей;
підготувати вихідну документацію для взаємодії розробників програми з її замовниками і користувачами.
Рис. 2.1. Приклад діаграми варіантів використання банківської системи обслуговування користувачів.
Діаграма варіантів містить деякі варіанти використання системи, деяких дійових осіб та зв’язки між ними. Дійова особа або актор (actor) – це все, що може взаємодіяти з системою ззовні. Це може бути людина, технічний пристрій, і або будь-яка інша система, яка може впливати на систему так, як визначить сам розробоник за вимогами замовниками. Варіанти використання (use case) – це опис функціональності системи на «високому рівні», тобто з точки зору користувача. Варіант використання служить для опису сервісів, які система надає акторові.
Правила розробки діаграми варіантів використання (прецедентів):
Не моделюйте зв’язки між акторами. За визначенням, актор, тобто дійова особа, знаходиться поза сфери дії системи, а отже зв’язки між ними не належать до її компетенції.
Не з’єднуйте безпосередньо два варіанти використання (крім зв’язків використання і розширення, які розглядатимуться нижче). Діаграми даного типу подають лише які варіанти використання доступні в системі, а не порядок їх виконання.
Кожен варіант використання повинен ініціюватися актором, тобто зв’язок завжди повинен починатися з актора і закінчуватися на варіанті використання. Виключенням є зв’язки використання і розширення.
За допомогою одного варіанта завдання можна вводити дані, а отримувати їх – за допомогою іншого. Для зображення потоків інформації не потрібно малювати стрілки від одного варіанта використання до іншого.