Концепція моделі сценаріїв для збору вимог

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

Функціональні вимоги – це вимоги до функцій системи.

Нефункціональні вимоги – це вимоги, наприклад, до надійності, безпеки, тестованості тощо.

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

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

1. складні проблеми трансформуються в сукупність складових мети;

2. кожна із складових мети трансформується в сукупність можливих прикладів використання системи;

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

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

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

Сценарій складається з ряду операцій і має стани й поведінку.

Сценарій – це повний ланцюжок подій, ініційованих актором, і специфікація реакції на них.

Сукупність сценаріїв визначає всі можливі шляхи використання системи. Для моделі сценаріїв визначається спеціальна графічна нотація: актор – іконка людини, під якою вказується назва актора; сценарій – овал (усередені овалу – назва сценарію); зв’язки між ними – стрілки. Кожного актора обслуговує своя сукупність сценаріїв (див. рис.7).

 

 

Рис.7. Діаграма сценаріїв АТ

 

 

 

Рис.8. Приклади розширення сценаріїв

 

 

 

Рис.9. Приклад відношення “використовує”

 

 

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

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

· онтології домену;

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

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

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

· назви;

· анотації;

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

· опису всіх аспектів дій акторів по взаємодії з системою;

· передумови;

· функції, які виконуються в сценарії;

· нестандартні ситуації й реакція на них;

· умови завершення сценарію і постумови.

 

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

 

Модель аналізу вимог

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

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

Аксіома. Всяка працююча ПС згодом вимагає змін.

Тому стратегія вибору об’єктів заснована на таких постулатах:

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

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

3. об’єкт повинен бути стійким до модифікації;

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

 

Вищенаведені принципи приводять до того, що простір, у якому функціонує система, потрібно структурувати в трьох вимірах:

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

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

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

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

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

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

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

· керуючий об’єкт.

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

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

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

Модель аналізу вимог має відповідну графічну нотацію:

 

 

 

 

Діаграма взаємодїї об’єктів в рамках сценарія будується на основі аналізу вимог до сценарію. Приклад такої діаграми показано для сценарію обробки замовлень на рис.5.

 

Таким чином, послідовний підхід до виявлення об’єктів, суттєвих для даної предметної області, складається з таких кроків:

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

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

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