4.5.4. Проєктування сценаріїв реалізації варіантів використання на основі uml-діаграм послідовностей та комунікації

Діаграма прецедентів (або діаграма варіантів використання) (англ. Use case diagram) — в UML, діаграма, на якій зображено відношення між акторами та прецедентами в системі.

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

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

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

Актори класифікуються на первинних (тж. активних) акторів (англ. primary actors, active actors) і вторинних (тж. пасивних) акторів (англ. secondary actors, passive actors). Первинні актори ініціюють варіант використання і, отже, є дещо незалежними. Вторинні актори, з іншого боку, використовуються системою, але вони не взаємодіють з системою самостійно. Іншими словами, вторинні актори не ініціюють жодного варіанту використання. Символ актора не робить різниці між первинним і вторинним актором; різниця повинна бути виведена з описів варіантів використання (англ. use case descriptions), які також називаються розповідями про варіанти використання (англ. use case narratives).

У мові UML є кілька стандартних видів відношень між акторами і варіантами використання:

• асоціації (англ. association relationship)

• включення (англ. include relationship)

• розширення (англ. extend relationship)

• узагальнення (англ. generalization relationship)

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

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

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

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

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

Зразок схеми сценарію виконання UML із системою сертифікації арбітрів

Межа системи визначає, що вважається зовнішнім або внутрішнім для системи.

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

Асоціація ілюструє участь актора у сценарії використання.

Різновид використання, варіант використання, прецедент (англ. Use Case) — у розробці програмного забезпечення та системному проектуванні це опис поведінки системи, як вона відповідає на зовнішні запити. Іншими словами, різновид використання описує, «хто» і «що» може зробити з розглянутою системою. Методика різновидів використання застосовується для виявлення вимог до поведінки системи, відомих також як функціональні вимоги.

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

Сценарій виконання – це набір подій, які відбуваються, коли актор використовує систему для завершення процесу. Зазвичай сценарій виконання – це відносно великий процес, а не окремий крок або транзакція.

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

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

Різновид використання визначає взаємодії між зовнішніми агентами і системою, спрямовані на досягнення мети. Актор (англ. Actor) являє собою роль, яку грає людина або річ, взаємодіючи з системою. Той же самий чоловік, який використовує систему, може бути представлений як різні актори, тому що вони грають різні ролі. Наприклад, «Джек» може грати роль Клієнта, що використовує Банкомат, щоб забрати готівку гроші, або грати роль Працівника Банку, що використовує систему для поповнення банкомату купюрами.

Різновиди використання розглядають систему як «чорний ящик», і взаємодії з системою, включаючи системні відповіді, описуються з точки зору зовнішнього спостерігача. Це — навмисна політика, тому що це змушує автора зосередитися на тому, що система повинна зробити, а не, як це повинно бути зроблено, і дозволяє уникати створення припущень про те, як функціональні можливості будуть реалізовані.

Різновиди використання можуть бути описані на абстрактному рівні (діловий різновид використання, іноді званий ключовим різновидом використання), або на системному рівні (системний різновид використання). Відмінності між ними — в деталях.

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

• Системний різновид використання зазвичай описується на рівні функцій системи (наприклад, створіть ваучер), і визначає функцію або сервіс, що надаються системою для користувача. Системний різновид використання описує що актор може зробити взаємодіючи з системою. З цієї причини рекомендується, щоб системні випадки використання починалися з дієслова (наприклад, створіть ваучер, виберіть платежі, скасуйте ваучер).

різновид використання повинен:

• Описувати що саме система має зробити, щоб актор досяг своєї мети.

• Не торкатися деталей реалізації.

• Мати достатній рівень деталізації.

• Не описувати інтерфейси та екрани. Це робиться під час дизайну користувальницького інтерфейсу.

Рівень деталізації. Алістер Кокберн у книзі «Написання ефективних різновидів використання» виділив три рівні деталізації різновидів використання:

• Короткий різновид використання: Складається з декількох речень. Він може бути легко вставлений у клітинку електронної таблиці, дозволяючи записати в сусідніх стовпцях пріоритет, тривалості, технічну складність і інші параметри.

• Звичайний різновид використання: Складається з декількох параграфів тексту, підсумовує різновид використання.

• Повністю деталізований різновид використання: Формальний документ, заснований на детальному шаблоні з різними розділами. Саме цей варіант мається на увазі в більшості випадків під поняттям різновиду використання.

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

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

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

Записування різновидів використання. В уніфікованій мові моделювання відносини між усіма або частиною різновидів використання й акторами представлені у вигляді діаграми різновиду використання або діаграмах, спочатку заснованих на об'єктному запису Івара Якобсона. SysML використовує те ж саме уявлення на системному рівні.

На діаграмах різновидів використання в UML різновид відображається у вигляді еліпса. Всередині еліпса або під ним вказується ім'я елемента.

До різновиду використання в UML застосовують наступні види відносин:

• Асоціація (англ. Association) — Може вказувати на те, що актор ініціює відповідний варіант використання.

У тому числі між прецедентами:

• Розширення (англ. Extend) — Різновид відносини залежності між базовим варіантом використання та його спеціальним випадком.

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

• Узагальнення (англ. Generalization , наслідування) — моделює відповідну спільність ролей.

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

Обмеження різновидів використання

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

• Дотримання шаблонів не гарантує якість різновидів. Якість залежить тільки від навичок творця різновиду.

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

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

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

• Важливість різновидів використання може бути переоцінена. У книзі «Object Oriented Software Construction» (2-ий випуск), Бертран Мейер обговорює проблеми, такі як проектування системи тільки за різновидами використання виключаючи інші потенційно цінні методики аналізу вимог.

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

Діаграма послідовності (англ. sequence diagram) — різновид діаграми в UML. Діаграма послідовності відображає взаємодії об'єктів впорядкованих за часом. Зокрема, такі діаграми відображають задіяні об'єкти та послідовність надісланих повідомлень.

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

Визначені стандартом UML 2.0 діаграми послідовностей мають ті ж можливості, що і визначені стандартом UML 1.x, і підтримують додаткові можливості зміни стандартного порядку повідомлень.

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

Діаграма послідовності системи повинна визначати і показувати наступне:

• Зовнішні актори

• Повідомлення (методи), що викликаються цими акторами

• Значення, що повертаються (якщо такі є), пов'язані з попередніми повідомленнями

• Вказівка на будь-які цикли або області ітерацій

Системне використання діаграми послідовності. Фахівці, розробляючи проект, часто використовують діаграми послідовності роботи системи, щоб проілюструвати, як виконуються певні завдання між користувачами та системою. Ці завдання можуть включати повторювані, прості або складні завдання.

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

Для того, щоб побудувати діаграму послідовності дій системи, потрібно бути знайомим з уніфікованою мовою моделювання (UML). Ці моделі показують логіку дій акторів (людей, які впливають на систему) і системи при виконанні завдання.

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

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

Структурні блоки діаграми послідовності. Якщо лінія життя - це лінія життя об'єкта, вона демонструє роль. Якщо залишити ім'я об'єкта порожнім, можна зобразити анонімні та безіменні об'єкти.

Повідомлення, написані горизонтальними стрілками з назвою повідомлення над ними, відображають взаємодію. Суцільні стрілки позначають синхронні виклики, відкриті стрілки позначають асинхронні повідомлення, а пунктирні лінії позначають повідомлення-відповіді. Якщо абонент надсилає синхронне повідомлення, він повинен зачекати, поки повідомлення не буде виконано, наприклад, виклик підпрограми. Якщо абонент надсилає асинхронне повідомлення, він може продовжити обробку і не чекати на відповідь. Асинхронні виклики присутні у багатопотокових програмах, програмах, керованих подіями, та у проміжному програмному забезпеченні, орієнтованому на повідомлення. Поля активації або поля виклику методів - це непрозорі прямокутники, намальовані поверх ліній життя, щоб показати, що процеси виконуються у відповідь на повідомлення (ExecutionSpecifications в UML).

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

Повідомлення, надіслане ззовні діаграми, може бути представлене повідомленням, що походить від заповненого кола (знайдене повідомлення в UML; англ. found message) або від межі діаграми послідовності ("ворота" в UML; англ. gate).

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

Діаграма комунікації (англ. Communication diagram, в UML 1.x - діаграма кооперації, англ. collaboration diagram) — діаграма, на якій зображуються взаємодії між частинами композитної структури або ролями кооперації. На відміну від діаграми послідовності, на діаграмі комунікації явно вказуються відносини між об'єктами, а час як окремий вимір не використовується (застосовуються порядкові номери викликів).

В UML є чотири типи діаграм взаємодії (неточно):

• діаграма послідовності;

• діаграма комунікації;

• діаграма огляду взаємодії;

• діаграма синхронізації.

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

Комунікаційні діаграми мають вільний формат упорядкування об'єктів і зв'язків як в діаграмі об'єктів. Щоб підтримувати порядок повідомлень при такому вільному форматі, їх хронологічно нумерують. Читання діаграми комунікації починається з повідомлення 1.0 і триває по напрямку пересилання повідомлень від об'єкта до об'єкта.

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