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

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

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

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

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

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

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

· ДПС і ТПС;

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

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

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

· ДПДД;

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

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

 

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

 

 

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

Мета роботи

 

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

 

 

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

 

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

 

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

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

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

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

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

Рис. 6 Інформаційна модель системи

 

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

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

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

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

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

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

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

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

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

 

 

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

Пояснення до Рис.7

Актор “Покупець ” ініціює такі події(сценарії):

- Здійснення розрахунку. Тобто внесення грошового еквіваленту за наданий товар.

- Купівля товару. Тобто всі події які необхідно виконати для того, щоб зробити замовлення, наприклад вибрати потрібні товари й скласти коректно замовлення.

Актор “Працівник складу ” ініціює такі події(сценарії):

- Обробка замовлення. Тобто це події які ініціалізуються в разі надходження замовлення.

- Ведення обліку. Тобто події спрямовані на те, щоб знати які товари на складі є в наявності, а яких немає.

Актор “Завідувач складу ” ініціює такі події(сценарії):

- Керування роботою складу.

Актор “Товар ”ініціює такі події(сценарії):

- Зберігання.

Актор “Відділ бухгалтерії ”ініціює такі події(сценарії):

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

- Продаж товару. Тобто веде документообіг який забезпечує передачу товару у власність покупця.

- Здійснення розрахунку. Отримує кошти за проданий товар.

Актор “Відділ по роботі з клієнтами ”ініціює такі події(сценарії):

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

Актор “Склад ”ініціює такі події(сценарії):

- Зберігання товару.

 

Сценарій типу розширення “ Обробка замовлення ”: включає в себе також видачу товарів.

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

Сценарій типу розширення “ Керування роботою складу ”: Включає в себе реорганізацію структури.

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

Сценарій типу використання “ Передача замовлення ”: використовує в своєму процесі купівлю товару і продаж товару.

 

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

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

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

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

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

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

· назви;

· анотації;

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

 

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

 

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

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

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

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