Варіанти використання системи

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

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

UML дозволяє також розробникам програмного забезпечення досягти угоди в графічних позначеннях для представлення загальних понять (таких як клас, компонент, узагальнення, агрегація і поведінка) і більше сконцентруватися на проектуванні та архітектурі.

Переваги UML:

· UML об'єктно-орієнтований, в результаті чого методи опису результатів аналізу і проектування семантично близькі до методів програмування на сучасних об'єктно-орієнтованих мовах;

· UML дозволяє описати систему практично з усіх можливих точок зору і різні аспекти поведінки системи;

· Діаграми UML порівняно прості для читання після досить швидкого ознайомлення з його синтаксисом;

· UML розширює і дозволяє вводити власні текстові та графічні стереотипи, що сприяє його застосування не тільки в сфері програмної інженерії;

· UML набув широкого поширення і динамічно розвивається.

Критика:

Незважаючи на те, що UML - досить широко поширений і використовуваний стандарт, його часто критикують через наступних недоліків:

· Надмірність мови. UML часто критикується як невиправдано великий і складний. Він включає багато надлишкових або практично невикористовуваних діаграм і конструкцій.

· Неточна семантика. Так як UML визначено комбінацією себе (абстрактний синтаксис), OCL (мовою опису обмежень - формальної перевірки правильності) і англійської (детальна семантика), то він позбавлений скутості, властивою мовам, точно певним техніками формального опису. У деяких випадках абстрактний синтаксис UML, OCL і англійська суперечать один одному, в інших випадках вони неповні. Неточність опису самого UML однаково відбивається на користувачів і постачальників інструментів, приводячи до несумісності інструментів через унікальне трактування специфікацій.

· Проблеми при вивченні і впровадженні. Вищеописані проблеми роблять проблематичним вивчення та впровадження UML, особливо коли керівництво насильно змушує використовувати UML інженерів за відсутності у них попередніх навичок.

· Тільки код відображає код. Ще одна думка - що важливі робочі системи, а не красиві моделі. Відповідно з цією думкою, існує потреба в кращому способі написання ПЗ; UML цінується при підходах, які компілюють моделі для генерування вихідного або здійсненного коду.

· Кумулятивна навантаження / Неузгодженість навантаження. Неузгодженість навантаження - термін з теорії системного аналізу для позначення нездатності входу однієї системи сприйняти вихід іншої. Як у будь-якій системі позначень UML може представити одні системи більш коротко і ефективно, ніж інші. Таким чином, розробник схиляється до рішень, які більш комфортно підходять до переплетення сильних сторін UML і мов програмування. Проблема стає більш очевидною, якщо мова розробки не дотримується принципів ортодоксальної об'єктно-орієнтованої доктрини (не стараються відповідати традиційним принципам ООП).

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

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

Прецедент - можливість модельованої системи (частина її функціональності), завдяки якій користувач може отримати конкретний, вимірний і потрібний йому результат. Прецедент відповідає окремому сервісу системи, визначає один з варіантів її використання і описує типовий спосіб взаємодії користувача з системою. Варіанти використання зазвичай застосовуються для специфікації зовнішніх вимог до системи.

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

При моделюванні системи за допомогою діаграми використання системний аналітик прагне:

· чітко відокремити систему від її оточення;

· визначити дійових осіб (акторів), їх взаємодія з системою і очікуваний функціонал системи;

Робота над діаграмою може початися з текстового опису, отриманого під час роботи з замовником. При цьому не функціональні вимоги (наприклад, конкретний мову або система програмування) при складанні моделі прецедентів опускаються (для них складається інший документ).

Для відображення моделі використання на діаграмі використовуються:

· рамки системи (англ. system boundary) - прямокутник з назвою у верхній частині і еліпсами (прецедентами) всередині. Часто може бути опущений без втрати корисної інформації,

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

· прецедент - еліпс з написом, що позначає виконувані системою дії (можуть включати можливі варіанти), що призводять до спостережуваних акторами результатами. Напис може бути ім'ям або описом (з точки зору акторів) того, «що» робить система (а не «як»). Ім'я прецеденту пов'язано з неперервним (атомарним) сценарієм - конкретної послідовністю дій, що ілюструє поведінку. В ході сценарію актори обмінюються з системою повідомленнями. Сценарій може бути приведений на діаграмі використання у вигляді UML-коментаря. З одним прецедентом може бути пов'язано кілька різних сценаріїв.

При роботі з варіантами використання важливо пам'ятати декілька простих правил:

· кожен прецедент відноситься як мінімум до однієї дійової особи;

· кожен прецедент має ініціатора;

· кожен прецедент призводить до відповідного результату.

Для реалізації діаграми використання в проекті медичного діагностичного центру я визначаю користувачів системи(клієнт, поставщик, бухгалтер), їх права допуску до певних даних(інформація про ліки) та допуск до певних функціональностей системи(друк, пошук, введення / виведення і редагування даних про ліки). (ДОДАТОК).