Моделювання uml - студопедія

Уніфікована мова моделювання UML [18] (Unified Modeling Language) являє собою мову для визначення, уявлення, проектування та документування програмних систем, організаційно-економічних систем, технічних систем та інших систем різної природи. UML містить стандартний набір діаграм і нотацій найрізноманітніших видів.

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

· Передбачити механізми розширюваності і спеціалізації для розширення базових концепцій;

· Забезпечити незалежність від конкретних мов програмування і процесів розробки;

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

· Стимулювати зростання ринку об'єктно-орієнтованих інструментальних засобів;

· Інтегрувати кращий практичний досвід.

UML знаходиться в процесі стандартизації, проведеному OMG (Object Management Group) - організацією зі стандартизації в області об'єктно-орієнтованих методів і технологій, в даний час прийнятий в якості стандартного мови моделювання і отримав широку підтримку в індустрії ПЗ. UML прийнятий на озброєння багатьма найбільшими компаніями - виробниками ПО (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase та ін.). Крім того, майже всі світові виробники CASE-засобів, крім IBM Rational

· Структурні (structural) моделі:

Діаграма класів (class diagrams) - для моделювання статичної структури класів системи і зв'язків між ними; діаграми компонентів (component diagrams) - для моделювання ієрархії компонентів (підсистем) системи;

діаграми розміщення (deployment diagrams) - для моделювання фізичної архітектури системи.

· Моделі поведінки (behavioral):

діаграми варіантів використання (use case diagrams) - для моделювання бізнес-процесів і функціональних вимог до створюваної системи; діаграми взаємодії (interaction diagrams):

діаграми послідовності (sequence diagrams) і кооперативні діаграми (collaboration diagrams) - для моделювання процесу обміну повідомленнями між об'єктами;

діаграми станів (statechart diagrams) - для моделювання поведінки об'єктів системи при переході з одного стану в інший;

діаграми діяльності (activity diagrams) - для моделювання поведінки системи в рамках різних варіантів використання, або потоків управління.

Діаграми ВАРІАНТІВ ВИКОРИСТАННЯ

Ідея опису функціональних вимог у вигляді варіантів використання (use case) була сформульована в 1986 р Іваром Якобсоном. Ця ідея була визнана конструктивною і отримала широке схвалення. Згодом найбільш значний внесок у вирішення проблеми визначення сутності варіантів використання і способів їх опису вніс Алістер Коберн [19].

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

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

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

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

Для наочного уявлення варіантів використання застосовуються діаграми варіантів використання. На рис. 2.47 показаний приклад такої діаграми для банківської системи.

Мал. 2.47. Приклад діаграми варіантів використання

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

Дійові особи можуть грати різні ролі по відношенню до варіанту використання. Вони можуть користуватися його результатами самі безпосередньо в ньому брати участь. Значимість різних ролей дійової особи залежить від того, яким чином використовуються його зв'язку.

Мета побудови діаграм варіантів використання - документування функціональних вимог до системи в найзагальнішому вигляді, тому вони повинні бути гранично простими. При побудові діаграм варіантів використання потрібно дотримуватися наступних правил:

· Чи не моделюйте зв'язку між діючими особами. За визначенням дійові особи знаходяться поза сферою дії системи. Це означає, що зв'язки між ними також не належать до її компетенції.

· Чи не поєднуйте стрілкою два варіанти використання безпосередньо. Діаграми даного типу описують тільки самі варіанти використання, а не порядок їх виконання. Для відображення порядку виконання варіантів використання застосовують діаграми діяльності.

· Кожен варіант використання повинен бути ініційований дійовою особою. Це означає, що завжди повинна бути стрілка, що починається на діючу особу, яка закінчується на варіанті використання.

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

Діаграма варіантів використання є найбільш загальним поданням функціональних вимог до системи. Однак моделювання варіантів використання не зводиться тільки до малювання діаграм. Для подальшого проектування системи потрібні більш конкретні деталі. Ці деталі описуються в документі, званому «сценарій варіанта використання» або «потік подій» (flow of events). Метою потоку подій є докладний документування процесу взаємодії дійової особи з системою, що реалізується в рамках варіанту використання. У потоці подій має бути описано все, що служить задоволенню запитів дійових осіб.

Хоча потік подій і описується докладно, він також не повинен залежати від реалізації. Мета - описати, щобуде робити система, а не какони робитиме це. Зазвичай опис потоку подій включає наступні розділи:

· Основний потік подій;

· Альтернативні потоки подій;

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

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

Варіант використання «Переказати гроші» дозволяє клієнту або службовцю банку переводити гроші з одного рахунку на вимогу або ощадного рахунку на інший.

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

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

Основний потік подій

1. Варіант використання починається, коли клієнт вставляє свою картку в банкомат.

2. Банкомат виводить вітання і пропонує клієнту ввести свій персональний PIN-код.

3. Клієнт вводить PIN-код.

4. Банкомат підтверджує введений код.

5. Банкомат виводить список доступних дій: зробити внесок, зняти гроші з рахунку, перевести гроші

6. Клієнт вибирає пункт «Зняти гроші з рахунку».

7. Банкомат запитує, скільки грошей треба зняти.

8. Клієнт вводить необхідну суму.

9. Банкомат визначає, чи є на рахунку достатньо грошей.

10. Банкомат віднімає необхідну суму з рахунку клієнта.

11. Банкомат видає клієнтові необхідну суму готівкою.

12. Банкомат повертає клієнту його картку.

13. Банкомат друкує чек для клієнта.

14. Варіант використання завершується.

Альтернативний потік подій 1. Введення неправильного PIN-коду.

4А1. Банкомат інформує клієнта, що код введено неправильно.

4а2. Банкомат повертає клієнту його картку.

4аЗ. Варіант використання завершується.

Альтернативний потік подій 2. Недостатньо грошей на рахунку.

9а1. Банкомат інформує клієнта, що грошей на його рахунку недостатньо.

9а2. Банкомат повертає клієнту його картку.

9аЗ. Варіант використання завершується.

Альтернативний потік подій 3. Помилка в підтвердженні запитуваної суми.

9б2. Банкомат заносить відомості про помилку в журнал помилок. Кожен запис містить дату і час помилки, ім'я клієнта, номер його рахунку і код помилки.

9б3. Банкомат повертає клієнту його картку.

9б4. Варіант використання завершується.

· Використовувати прості речення;

· Явно вказувати в кожному пункті, хто виконує дію - дійова особа або система;

· Не показувати занадто незначні дії;

· Не показувати детальні дії користувача в процесі роботи з призначеним для користувача інтерфейсом;

· Не розглядати можливі помилкові ситуації (використовувати дії «підтвердити», а не «перевірити»).

При виявленні альтернативних потоків подій потрібно в першу чергу звернути увагу на ситуації, пов'язані з:

· Некоректними діями користувача (наприклад, введення невірного пароля);

· Бездіяльністю дійової особи (наприклад, закінченням часу очікування пароля);

· Внутрішніми помилками в розроблюваної системі, які повинні бути виявлені і оброблені в звичайному порядку (наприклад, заблокований автомат для видачі готівки);

· Критично важливими недоліками в продуктивності системи (наприклад, час реакції не вкладається в 5 секунд).

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

Розширення. Цей пункт присутній, якщо в основному пото-ке подій мають місце відносно рідко зустрічаються сі-туації (окремі випадки). Опис таких ситуацій виноситься в даний пункт.

У діаграмах варіантів використання може присутність-вать кілька типів зв'язків. Це зв'язку комунікації (commu-nication), включення (include), розширення (extend) і узагальнення (generalization).

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

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

Зв'язок розширення застосовується при наявності змін в нормальному поведінці системи (описаних в пункті «розширити-ня»), які також виносяться в окремий варіант вико-вання.

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

Мал. 2.48. Зв'язки включення та розширення

За допомогою зв'язку узагальнення показують, що у кількох дійових осіб є спільні риси і відмінності. Наприклад, у службовців організації є як загальні властивості, так і різні способи оплати праці (рис. 2.49).

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

Варіанти використання є необхідним засобом на стадії формування вимог до ПЗ. Кожен варіант використання - це по-

Мал. 2.49. Узагальнення дійової особи

соціальне вимога до системи, і поки воно не виявлено, неможливо запланувати його реалізацію.

Різні розробники підходять до опису варіантів використання з різним ступенем деталізації. Наприклад, Івар Якобсон стверджував, що для проекту з трудомісткістю 10 людино-років кількість варіантів використання може становити близько 20 (без урахування зв'язків «включення» і «розширення»). Слід віддавати перевагу невеликі та деталізовані варіанти використання, оскільки вони полегшують складання і реалізацію узгодженого плану проекту.

Переваги моделі варіантів використання полягають в тому, що вона:

· Визначає користувачів і кордони системи;

· Визначає системний інтерфейс;

· Зручна для спілкування користувачів з розробниками;

· Використовується для написання тестів;

· Є основою для написання документації користувача;

· Добре вписується в будь-які методи проектування (як об'єктно-орієнтовані, так і структурні).