1.3. Модель процесів

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

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

Як джерела даних допускаються:

• атрибути об'єктів (зберігаються у файлах або базах даних);

• системні годинники й таймери;

• дані подій і повідомлення.

Правила побудови ДПДД

Кожному стану з ДПС може відповідати тільки одна ДПДД. Процес на ДПДД зображується у вигляді овалу (усередині дається назва), потоки даних зображуються стрілками (на котрих вказуються ідентифікатори даних, напрямок до овалу - вхідні, а від овалу - вихідні дані), джерела даних зображуються прямокутниками або рамками з відкритими сторонами (рис.5).

Потоки даних від таймера маркуються номером таймера.

Рис.5. Приклад діаграми потоків даних дій (ДПДД) для стану “Отримання коштів”

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

• ідентифікатор процесу;

• тип процесу (аксесор – доступ до архівів даних, генератор подій, процес-обчислення, перевірка умов);

• повна назва процесу;

• назва стану, у якому визначений процес;

• назва дії стану;

За допомогою цієї таблиці перевіряється:

1. несуперечність назв та ідентифікаторів процесів;

2. повнота подій та процесів;

3. можливість виявити спільні процеси для різних дій чи станів.

До ДПДД додаються неформальні описи функцій всіх процесів.

1.4. Продукти інженерії вимог за методом Шлеєр і Меллора

Відповідно до методу, результатами аналізу вимог до створення ПС є наступні продукти:

1. Інформаційна модель системи (онтологія) у формі:

   • діаграми сутність-зв’язок;

   • опису об’єктів та їхніх атрибутів;

   • опису зв’язків між об’єктами.

2. Модель поведінки об’єктів системи у формі:

   • ДПС і ТПС;

   • опису дій для ДПС;

   • опису подій для ДПС та ТПС.

3. Модель процесів для станів об’єктів у вигляді:

   • ДПДД;

   • таблиці процесів станів;

   • опису процесів (природною мовою).

Сукупність перерахованих продуктів вважається достатньою для переходу до проектування ПС.

Метод інженерії вимог і.Джекобсона

2. Теоретичні відомості

Метод Джекобсона – це єдиний метод, що вказує послідовний достатньо формалізований підхід до виявлення об’єктів, суттєвих для даної предметної області.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• назви;

• анотації;

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

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

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

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

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

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

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