Мета роботи. Ознайомлення з методологією моделювання прецедентів на основі мови UML.
Завдання. Ознайомитися з методологією моделювання прецедентів на основі мови UML, використовуючи методичні вказівки і [2]. Ознайомитися із засобами побудови діаграм прецедентів програмного продукту StarUML 5.0, використовуючи [3]. Розробити діаграму прецедентів автоматизованої системи, відповідно до варіанту індивідуального завдання, використовуючи інструментальне засіб StarUML 5.0. Описати кілька (два, три) прецедентів. Продемонструвати проект і захистити роботу викладачеві.
Короткий опис методології моделювання прецедентів в мові uml
Уніфікований Мова Моделювання (UML) є мовою, що підтримує об'єктно-орієнтоване моделювання. Об'єктно-орієнтоване моделювання грунтується на розгляді теорії систем, метою якої є виділення, пояснення і опис складних систем за допомогою однакових стандартів. Система являє сукупність компонентів, пов'язаних різноманітними відносинами.
Спрощення складної системи шляхом побудови її моделі необхідно, оскільки система не може бути розглянута як єдине ціле через свою складність.
Завдання моделювання полягає у виділенні властивостей системи, які є значущими для зацікавлених сторін, і в побудові моделі системи, орієнтованої на уявлення виділених властивостей. При моделюванні систем можна розділити опис структури системи і її поведінки.
Завдання опису структури системи полягає у виділенні набору класів, що відповідають даним сутностей предметної області. Основним поняттям в об'єктно-орієнтованому підході є об'єкт - сутність, зазвичай відповідна поняттю, взятому зі словника предметної області.
використовуючи розширену семантику, провести візуалізацію системи;
розробити моделі, які описують систему з різних точок зору;
відображати отримані опису на об'єктно-орієнтовані мови програмування і таблиці реляційних баз даних;
формулювати вимоги і визначати тести для розроблюваної системи.
Діаграма - це графічне представлення набору елементів, зображуване у вигляді графа, в вершинах якого розташовані суті, а в якості ребер виступають відносини між цими сутностями.
UML передбачає кілька типів діаграм, призначених для опису системи. Кожна з діаграм акцентує увагу на тому чи іншому важливому аспекті системи, тому діаграми доповнюють один одного і можуть використовуватися спільно для опису системи з різних точок зору.
Модель системи, яка використовується в конкретному проекті, дає уявлення про систему з різних точок зору. При цьому необхідно визначити набір уявлень, достатніх для вирішення завдання проекту. Моделювання системи з використанням різних уявлень здійснюється наступним чином:
прийняття рішення про те, які види уявлень найкраще відображають архітектуру системи і можливі ризики, пов'язані з конкретним проектом;
визначення для кожного з обраних видів набору артефактів, необхідних для відображення його найбільш важливих деталей;
визначення діаграм, які дозволять виконувати контроль розробки і здійснення проекту;
збереження копій і версій всіх діаграм, виконаних в проекті.
Можна виділити наступні характеристики, яким має відповідати добре структурована діаграма:
загострення уваги на одному аспекті деякого уявлення системи;
При графічному побудові діаграми необхідно виконання наступних правил:
ім'я діаграми по можливості повинно відповідати її призначенню;
елементи повинні бути розташовані так, щоб кількість перетинів між ними була мінімальною;
елементи, що виражають семантично близькі суті, повинні розташовуватися на діаграмі поряд;
при необхідності концентрації уваги на важливій частині діаграми допускається її виділення кольором.
Діаграми прецедентів застосовуються для моделювання виду системи з точки зору зовнішнього спостерігача. На діаграмі прецедентів графічно показана сукупність прецедентів та Суб'єктів, а також відносини між ними.
Розглянемо основні елементи діаграми прецедентів.
Суб'єкт (actor) - будь-яка сутність, що взаємодіє з системою ззовні, або безліч логічно пов'язаних ролей, виконуваних при взаємодії з прецедентами. Стандартним графічним позначенням суб'єкта на діаграмах є фігурка «чоловічка», під якою записується конкретне ім'я суб'єкта, однак суб'єктом може бути не тільки людина, але і технічний пристрій, програма або будь-яка інша система, яка може служити джерелом впливу на моделируемую систему так, як визначить сам розробник.
Прецеденти (usecase) - це опис безлічі послідовностей дій (включаючи їх варіанти), які виконуються системою для того, щоб актор отримав результат, який має для нього певне значення. При цьому нічого не говориться про те, яким чином буде реалізовано взаємодію суб'єктів з системою, це одна з найважливіших особливостей розробки прецедентів. Стандартним графічним позначенням прецеденту на діаграмах є еліпс (рис. 10), всередині якого міститься коротка назва прецеденту або ім'я у формі дієслова з пояснювальними словами.
Мал. 10. Прецедент
Сутність концепції прецедентів має на увазі кілька важливих пунктів.
Прецедент є завершений фрагмент функціональних можливостей (включаючи основний потік логіки управління, його будь-які варіації (підпотоків) і виняткові умови (альтернативні потоки)).
Фрагмент зовні спостережуваних функцій (відмінних від внутрішніх функцій).
Ортогональний фрагмент функціональних можливостей (прецеденти можуть при виконанні спільно використовувати об'єкти, але виконання кожного прецеденту незалежно від інших прецедентів).
Фрагмент функціональних можливостей, ініційований суб'єктом. Будучи ініційований, прецедент може взаємодіяти з іншими суб'єктами. При цьому можливо, що суб'єкт виявиться тільки на приймаючому кінці прецеденту, опосередковано ініційованого іншим суб'єктом.
Фрагмент функціональних можливостей, який надає суб'єкту відчутний корисний результат (і цей результат досягається в межах одного прецеденту).
Між суб'єктами і прецедентами - основними компонентами діаграми прецедентів - можуть існувати різні відносини, які описують взаємодію екземплярів одних суб'єктів і прецедентів з екземплярами інших суб'єктів і прецедентів. В UML є кілька стандартних видів відносин між суб'єктами і прецедентами.
Ставлення асоціації (association) - визначає наявність каналу зв'язку між екземплярами суб'єкта і прецеденту (або між екземплярами двох суб'єктів). Позначається суцільною лінією, можлива наявність стрілки і вказівку потужності зв'язку.
Ставлення розширення (extend) - визначає взаємозв'язок екземплярів окремого прецеденту з більш загальним прецедентом, властивості якого визначаються на основі способу спільного об'єднання даних екземплярів. Позначається пунктирною лінією зі стрілкою, спрямованої від того прецеденту, який є розширенням для вихідного прецеденту, і позначається ключовим словом «extend» ( «розширює»).
Ставлення включення (include) - вказує, що деякий заданий поведінка для одного прецеденту включає в якості складового компонента поведінку іншого прецеденту. Дане відношення є спрямованим бінарним відношенням в тому сенсі, що пара екземплярів прецедентів завжди впорядкована щодо включення. Позначається пунктирною лінією зі стрілкою, спрямованої від базового прецеденту до такого, що включається, і позначається ключовим словом «include» ( «включає»).
Ставлення узагальнення (generalization) - служить для вказівки того факту, що деякий прецедент А може бути узагальнено до прецеденту В. В цьому випадку прецедент А буде спеціалізацією прецеденту В. При цьому прецедент В називається предком або батьком по відношенню до прецеденту А, а прецедент а - нащадком по відношенню до прецеденту В. Слід підкреслити, що нащадок успадкує все властивості і поведінку свого батька, а також може бути доповнений новими властивостями і особливостями поведінки. Графічно дане відношення позначається суцільною лінією зі стрілкою в формі незафарбовані трикутника, яка вказує на батьківський прецедент.
Товари поставляються декількома постачальниками. Кожна партія товару попередньо замовляється магазином у деякого постачальника і доставляється після оплати рахунку. Знову надійшов товар маркується, заноситься в базу даних і потім розподіляється в торговий зал або прокат.
На рис. 11 приведена діаграма прецедентів для розглянутого прикладу. У цьому прикладі можна виділити наступні суб'єкти і відповідні їм прецеденти:
Постачальник - оформляє документи для оплати товару (прецедент «Оформлення замовлення»), поставляє товар (прецедент «Прийом товару»).
Останні два суб'єкта Постачальник і Клієнт не матимуть безпосереднього доступу до розроблюваної системі (другорядні суб'єкти), проте саме вони є основним джерелом подій, ініціюючих прецеденти, і одержувачами результату роботи прецедентів.
Подальший розвиток моделі поведінки системи передбачає специфікацію прецедентів. Для цього традиційно використовують два способи. Перший - опис за допомогою текстового документа. Такий документ описує, що повинна робити система, коли суб'єкт ініціював прецедент. Типове опис містить наступні розділи.
Передумови, необхідні для ініціювання прецеденту.
Потік подій (основний і, можливо, підпотоків, альтернативний).
Післяумови, що визначають стан системи, після досягнення якого прецедент завершується.