кожен сценарій може запускати тільки один актор;

 кожен актор може запускати кілька сценаріїв;

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

 актор не визначає сценарію, він лише ініціює ланцюжок подій, який визначить сценарій;

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

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

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

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

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

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

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

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

Для моделі сценаріїв пропонується спеціальна графічна нотація, основні правила якої наведено нижче:

- актор позначається іконкою людини, під якою вказується його назва;

- сценарій зображається овалом, всередині якого вказується його назва (що, зазвичай, відображає складові мети, які реалізуються сценарієм);

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

Приклад 1. На рис. 3.7 наведено приклад діаграми сценаріїв для клієнта банку.

Рисунок 3.7 - Приклад діаграми сценаріїв для клієнта банку

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

Приклад 2. Нехай нам замовлено побудувати автоматизовану бібліотечну систему. Сформулюємо кілька складових мети її побудови:

 автоматична реєстрація читача;

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

 фіксація книг, які замовляє читач;

 фіксація факту видачі замовлень, які виконано;

 фіксація повернення книжок та журналів;

 організація черги відкладених замовлень, які не можна виконати через зайнятість їх іншими читачами;

 повідомлення читачеві про можливість виконання відкладених раніше замовлень;

 виявлення боржників і надсилання їм попереджувальних повідомлень;

На рис. 3.8 показано діаграму сценаріїв, що відповідає одному з варіантів вимог до бібліотечної системи. Розглянемо цей варіант.

Рисунок 3.8 - Діаграма сценаріїв бібліотеки

Цілі 1-8 визначають ті бібліотечні процеси, які ми бажаємо автоматизувати. Вимогу до автоматизації певного процесу в системі, яку ми будуємо, буде подано одним або кількома сценаріями.

Визначимо, які актори будуть запускати сценарії.

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

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

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

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

Першим актором нашої системи визначимо адміністратора бібліотечного фонду, а другим - члена бібліотечної ради.

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

Рисунок 3.9 - Діаграма сценаріїв погодження замовлень

Адміністратор викликає сценарії:

 узагальнення поданих замовлень (вилучення однакових замовлень, поданих членами ради, впорядковування узагальненого списку поданих замовлень);

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

 оброблення результатів голосування і сортування замовлень за отриманими рейтингами;

 визначення частини списку замовлень, що вкладається в наданий бюджет;

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

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

Для сценаріїв визначено два типи відношень:

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

Наведемо типові приклади (рис. 3.10), коли доцільне застосування відношення розширення:

1) для моделювання необов’язкових фрагментів сценаріїв (див. рис. 3.10, а);

2) для моделювання альтернативного перебігу подій у сценарії, що рідко відбувається (див. рис. 3.10, б);

3) для подання ситуації, коли кілька окремих сценаріїв організовуються як акції в спеціальний сценарій типу меню (див. рис. 3.10, в).

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

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

Рисунок 3.10 - Приклади розширення сценаріїв

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

На рис. 3.11 показано, що сценарій "сортувати" пов’язаний відношенням "використовує" з кількома сценаріями.

Рисунок 3.11 - Приклад відношення "використовує"

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

- онтологія домену;

- модель сценаріїв, яка називається діаграмою сценаріїв;

- опис інтерфейсів сценаріїв.

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

Модель сценаріїв супроводжується неформальним описом кожного із сценаріїв, нотація якого не регламентується. Як один із варіантів, опис сценарію може бути подано як послідовність таких елементів:

 назва, яка позначає сценарій на діаграмах моделі вимог і яка є засобом посилання на сценарій;

 анотація (короткий зміст у неформальному поданні);

 актори, які можуть запускати сценарій;

 визначення всіх аспектів взаємодії системи з акторами: можливих дій актора та їхніх можливих наслідків; заборонених дій актора, якщо такі є, та їхніх можливих наслідків;

 передумови, які визначають початковий стан, тобто стан на момент запуску сценарію, необхідний для його успішного виконання, наприклад, наявність даних, яких він потребує;

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

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

 дії, котрі є реакцією на передбачувані нестандартні ситуації;

 умови завершення сценарію;

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

На подальших стадіях осмислення проблеми сценарій використання трансформується в сценарій поведінки системи — до наведених елементів додаються ті, що пов’язані з конструюванням рішення цільової проблеми та нефункціональними вимогами, наприклад:

- механізми запуску сценарію ( наприклад, позиції меню);

- механізми введення даних;

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

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

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

3.5.2 Модель аналізу вимог. Визначення об’єктів

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

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

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

- зміна вимог неминуча;

- об’єкт має модифікуватися тільки внаслідок зміни відповідних вимог до системи;

- об’єкт має бути стійким до модифікації і сприяти розумінню системи;

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

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

- інформація, яку обробляє система (її внутрішній стан);

- поведінка системи;

- презентація системи (її інтерфейси з користувачами та іншими системами).

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

- впродовж життєвого циклу найбільших змін зазнають вимоги до презентації системи;

- поведінка системи суттєво більш консервативна, але зазнає змін досить часто;

- характер і структура інформації, яку обробляє система, є найстабільнішим виміром щодо попередніх двох.

Тож доцільно для кожного з вимірів функціональності системи мати свою сукупність об’єктів, яка його відображає; таким поділом ми локалізуємо в тексті подання вимог найстабільніші фрагменти, наймобільніші та проміжні. Згідно із сказаним вище, ми розглядаємо три типи об’єктів:

- об’єкти-сутності;

- об’єкти інтерфейсу;

- керуючі об’єкти.

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

Об’єкти інтерфейсу (object interface) містять у собі функціональності, залежні безпосередньо від оточення системи й визначені в сценарії. За їхньою допомогою актори взаємодіють із сценаріями системи - їхнім завданням є трансляція інформації, яку вводить актор у події, на які реагує система, та зворотна трансляція подій, які виробляє система у повідомлення для актора. Такі об’єкти визначаються шляхом аналізу описів інтерфейсів сценаріїв моделі вимог та аналізу дій акторів із запуску кожного з відповідних йому сценаріїв. Як перше наближення, один інтерфейсний об’єкт може бути визначено для однієї пари актор - сценарій. Можна побудувати ієрархію інтерфейсних об’єктів за відношенням "містить" - наприклад, панель містить кнопки, індикатори, меню тощо.

Інтерфейси можна розподілити на два види: "з людиною" та "з системою". При виявленні інтерфейсних об’єктів визначальним є передбачення змін - кожну точку можливих змін у сценарії доцільно визначати як інтерфейсний об’єкт.

Керуючі об’єкти - це об’єкти, які перетворюють інформацію, введену об’єктами інтерфейсу і подану об’єктами-сутностями, в інформацію, що виводиться інтерфейсними об’єктами (іншими словами, керуючі об’єкти відповідають функціям перероблення інформації). Часто вони є своєрідним "клеєм" для з’єднання об’єктів, формуючи ланцюжки подій і, в такий спосіб, взаємодію об’єктів.

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

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

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

Атрибути об’єктів подані прямокутниками, поєднаними прямою лінією з символом об’єкта, при цьому на лінії вказується назва атрибута, а в прямокутнику - його тип.

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

Серед асоціацій застосовуються найпоширеніші:

- "взаємодіє";

- "складається з";

- "виконує роль";

- "успадковує";

- "розширює";

- "використовує".

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

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

Рисунок 3.12 - Асоціації між об’єктами бібліотечної системи

3.5.3 Продукти інженерії вимог за методом І. Джекобсона

Продуктами стадії аналізу вимог за даним методом є:

- онтологія домену;

- модель сценаріїв;

- неформальний опис сценаріїв та акторів;

- опис інтерфейсів сценаріїв та акторів;

- діаграми взаємодії об’єктів сценаріїв.

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

Контрольні запитання і завдання

1. Як називається фаза життєвого циклу розробки програмного забезпечення, на якій формується контракт між замовником і виконавцем розробки?

2. Назвіть дійових осіб процесу формування вимог.

3. Назвіть джерела відомостей про вимоги.

4. Якою є послідовність кроків з урахування діючої системи в новій розробці?

5. Назвіть категорії класифікації вимог.

6. Складові мети і складові концептуального моделювання проблеми.

7. Що означає онтологія в концептуальному моделюванні проблеми?

8. Поясніть суть відношень, за допомогою яких будуються поняття: узагальнення /конкретизація, агрегація/, декомпозиція, абстракція, асоціація.

9. Які елементи моделювання динамічних властивостей доменів Ви можете назвати?

10. Назвіть елементи об’єктно-орієнтованого моделювання програмних систем.

11. У чому полягає принцип приховування інформації? Що дає цей принцип:

а) замовникові; б) виконавцеві?

12. Визначте операцію успадкування класів.

13. Назвіть продукти аналізу домену за методом Шлеєр і Меллора.

14. Якою є онтологія домену за методом Шлеєр і Меллора?

15. У чому суть і якою є нотація моделі станів за методом Шлеєр і Меллора?

16. У чому суть і якою є нотація моделі процесів за методом Шлеєр і Меллора?

17. У чому полягає концепція моделі сценаріїв для складання вимог? Поняття "актор".

18. Наведіть нотацію діаграми сценаріїв за методом Джекобсона.

19. Назвіть базові відношення сценаріїв методу Джекобсона і мету використання їх.

20. Які принципи і мета класифікації об’єктів за методом Джекобсона?

21. Якою є нотація взаємодії об’єктів у методі Джекобсона?