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

1.

ЛЕКЦІЯ 14
Метод інженерії вимог А. Джекобсона

2.

МЕТОД ІНЖЕНЕРІЇ ВИМОГ А. ДЖЕКОБСОН
Даний метод є методом з послідовним
виявленням об'єктів, істотних для домену
проблемної області.
Всі методи аналізу предметної області в якості
першого кроку виконують виявлення об'єктів.
Правильний вибір об'єктів обумовлює зрозумілість
і точність вимог.
Розглянутий метод Джекобсон дає рекомендації
щодо того, з чого починати шлях до розуміння
проблеми і пошуку істотних для неї об'єктів.
Автор назвав свій метод як базується на варіантах
(прикладах або сценаріях - use case driven)
системи, яку потрібно побудувати.
2

3.

МЕТОД ІНЖЕНЕРІЇ ВИМОГ А. ДЖЕКОБСОН
Складність проблеми зазвичай долається шляхом
декомпозиції її на окремі компоненти з меншою
складністю.
Велика система може бути складною, щоб представити
її компоненти програмними модулями.
Тому розробка системи за допомогою даного методу
починається з осмислення того, для кого і для чого
створюється система.
Складність спільної мети виражається через окремі
підцілі, яким відповідають функціональні або
нефункціональні вимоги і проектні рішення. Цілі є
джерелами вимог до системи і способом оцінки
цих вимог, шляхом виявлення суперечностей
між вимогами і встановлення залежностей між
цілями.
3

4.

МЕТОД ІНЖЕНЕРІЇ ВИМОГ А. ДЖЕКОБСОН
Цілі можна розглядати, як точку зору окремого
користувача або замовника або середовища
функціонування системи.
Цілі можуть перебувати між собою в певних відносинах,
наприклад, конфліктувати, кооперуватися, залежати
одна від одної або бути незалежними.
Наступним кроком після виявлення цілей є визначення
носіїв інтересів, яким відповідає кожна мета, і можливі
варіанти задоволення складових цілей у вигляді
сценаріїв роботи системи.
Останні допомагають користувачеві
отримати уявлення про призначення і функції системи.
Ці дії відповідають першій ітерації визначення вимог
до розробки.
4

5.

МЕТОД ІНЖЕНЕРІЇ ВИМОГ А. ДЖЕКОБСОН
Таким чином, проводиться послідовна декомпозиція
проблема - цілі - сценарії - об'єкти, що відображає ступінь
концептуалізації в розумінні проблеми, послідовного
зниження складності її частин і підвищення рівня
формалізації моделей її подання.
Трансформація зазвичай виражається в термінах базових
понять проблемної області, активно використовується для
представлення акторів і сценаріїв, або створюється в процесі
побудови такого уявлення.
Кожен сценарій ініціюється певним користувачем, що є
носієм інтересів. Абстракція певної ролі особистості
користувача- ініціатора запуску певної роботи в системі,
представленої сценарієм, і обміну інформацією з системою називається актором.
Це абстрактне поняття узагальнює поняття дійової особи
системи. Фіксація акторів можна розглядати, як певний крок
виявлення цілей системи через ролі, які є носіями цілей і
постановниками задач, для вирішення яких створюється
система.
5

6.

АКТОРИ
Актор вважається зовнішнім фактором системи, дії якого
носять недетермінований характер. Цим підкреслюється
різниця між користувачем як конкретною особою і акторомроллю, яку може грати будь-яка особа в системі.
У ролі актора може виступати і програмна система, якщо
вона ініціює виконання певних робіт даної системи. Таким
чином, актор - це абстракція зовнішнього об'єкта, екземпляр
якого може бути людиною або зовнішньою системою. У моделі
актор представляється класом, а користувач - екземпляром
класу. Одна особа може бути екземпляром декількох
акторів.
Особа в ролі (екземпляр актора) запускає операції в системі,
співвіднесені з поведінкою послідовності транзакцій системи і
називається сценарієм. Коли користувач, як екземпляр актора,
вводить певний символ для старту примірника відповідного
сценарію, то це призводить до виконання ряду дій за допомогою
транзакцій, які закінчуються тоді, коли екземпляр сценарію 6
знаходиться в стані очікування вхідного символу.

7.

СЦЕНАРІЇ
Сценарій визначає перебіг подій в системі і має статки і
поведінкою. Кожна взаємодія між актором і системою це новий
сценарій або об'єкт. Якщо кілька сценаріїв системи мають
однакове поведінка, то їх можна розглядати як клас сценаріїв.
Виклик сценарію - це породження екземпляра класу.
Таким чином, сценарії - це транзакції з внутрішнім станом.
Модель системи за цим методом ґрунтується на сценаріях і
внесення в неї змін має здійснюватися повторним
моделюванням акторів і запускаються ними сценаріїв. Така
модель відображає вимоги користувачів і легко змінюється за їх
пропозицією.
Сценарій - це повна ланцюжок подій, ініційованих актором, і
специфікація реакції на них. Сукупність сценаріїв визначає всі
можливі варіанти використання системи. Кожного актора
обслуговує своя сукупність сценаріїв.
7

8.

СЦЕНАРІЇ
Для завдання моделі сценаріїв використовується спеціальна
графічна нотація, з такими основними правилами:
актор позначається іконою людини, під якою вказується назва;
сценарій зображується овалом, в середині якого вказується
назва ікони;
актор зв'язується стрілкою з кожним запускаються їм сценарієм.
8

9.

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

10.

ВІДНОШЕННЯ
Відношення "використання" означає, що деякий сценарій
може бути використаний як розширення декількома іншими
сценаріями.
10

11.

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

12.

МОДЕЛЬ ВИМОГ
Модель сценаріїв супроводжується неформальним описом
кожного з сценаріїв. Нотація такого опису не регламентується.
Як один з варіантів, опис сценарію може бути представлено
послідовністю елементів:
назва, що позначає сценарій на діаграмах моделі вимог і служить засобом
посилання на сценарій;
анотація (короткий зміст в неформальному поданні);
актори, які можуть запускати сценарій;
визначення всіх аспектів взаємодії системи з акторами (можливі дії актора і їх
можливі наслідки), а також заборонених дій актора;
передумови, які визначають початковий стан на момент запуску сценарію,
необхідне для успішного виконання;
функції, які реалізуються при виконанні сценарію і визначають порядок, зміст і
альтернативу дій, які виконуються в сценарії;
виняткові або нестандартні ситуації, які можуть виникнути під час виконання
сценарію і зажадати спеціальних дій для їх усунення (наприклад, помилка в
діях актора, яку здатна розпізнати система);
реакції на передбачені нестандартні ситуації;
умови завершення сценарію;
постумови, які визначають кінцевий стан сценарію при його завершенні.
12

13.

МОДЕЛЬ ВИМОГ
На подальших стадіях сценарій трансформується в сценарій
поведінки системи, тобто до наведених елементів моделі
додаються елементи, пов'язані з конструюванням рішення
проблеми і нефункціональними вимогами:
механізми запуску сценарію (позиції меню);
механізми введення даних;
поведінка при виникненні надзвичайних ситуацій.
Наступним кроком процесу проектування є перетворення
сценарію в опис компонентів системи і перевірка їх
правильності.
Опис інтерфейсів робиться неформально, вони визначають
погляд користувача на систему, з яким необхідно погодити
вимоги, зібрані на етапі аналізу системи і визначення вимог.
Всі питання взаємодії відзначаються на панелі екрану для
кожного з акторів і їх елементи (меню, вікна введення, кнопки індикатори і т.п.).
Побудова прототипу системи, що моделює дії актора, допомагає
13
відпрацювати деталі і усунути непорозуміння між замовником і
розробником.

14.

КОНЦЕПТУАЛЬНЕ МОДЕЛЮВАННЯ ПРОБЛЕМИ
Процес побудови моделі проблеми, орієнтованої на її розуміння
людиною, назвемо концептуальним моделюванням
(conceptual modeling).
Кожна проблемна галузь - назвемо її доменом - має властиву їй
систему понять, знайому тільки відповідним професіоналам,
свою систему "замовчування" того, що має вважатися
"загальновідомим" у рамках свого домену, свої характерні
властивості (атрибути), відношення та правила поведінки.
Однак роль концептуальної моделі полягає в тому, щоб бути
посередником між професіоналами, котрі належать до різних
доменів, наприклад, як програмісти та фахівці з бухгалтерії.
Ступінь формалізації цієї моделі має бути достатнім, щоб
забезпечувати точність та однозначність трактування носіями
інтересів у розробці, і водночас не надмірним, щоб бути
доступним для розуміння не лише математикам за фахом, і
спроможним відобразити деталі фахових проблем багатьох
верств спеціалістів.
14

15.

ОНТОЛОГІЯ ДОМЕНУ
Найпершою з моделей домену може вважатися його понятійна
база, тобто система понять, за допомогою якої формулюються всі
аспекти проблеми. Понятійна база визначає не лише
термінологію, якою мають користуватися носії інтересів, котрі
беруть участь у процесі аналізу вимог, а також і суттєві
відносини між поняттями та їхньою інтерпретацією.
Сукупність термінології, понять, характерних для них відносин
і парадигми їхньої інтерпретації в межах домену прийнято
називати онтологією домену.
Зміст поняття може бути охарактеризовано сукупністю спільних
істотних ознак тих явищ та предметів, які позначаються назвою
поняття. Сукупність явищ, охоплених поняттям, називається
його обсягом. У ментальній діяльності людини застосовуються
відношення, які дозволяють будувати похідні поняття і
встановлювати між ними зв’язки.
15

16.

ОНТОЛОГІЯ ДОМЕНУ
Серед таких відношень назвемо найпоширеніші:
узагальнення - це звуження істотних ознак поняття, при
цьому розширюється коло охоплених поняттям об’єктів, тобто
його обсяг. Приклади: свійська тварина є узагальненням
понять свиня, корова та багатьох інших;
конкретизація - це додавання істотних ознак, завдяки чому
зміст поняття розширюється, а обсяг поняття звужується.
Наприклад, студент консерваторії є конкретизацією загального
поняття студент;
агрегація (aggregation) - це об’єднання низки понять у нове
поняття, істотні ознаки нового поняття при цьому можуть бути
або сумою ознак компонентів або суттєво новими. Прикладом
першого типу є пральна машина з центрифугою, другого автомобіль як композиція колес, двигуна, корпусу, керма тощо.
Відношення агрегації часто має назву відношення частка - ціле;
асоціація (association) - це найбільш загальне відношення, що
утверджує наявність зв’язку між поняттями, не уточнюючи 16
залежності між їхнім змістом та обсягами.

17.

ОНТОЛОГІЯ ДОМЕНУ
Для окремих доменів можуть використовуватися специфічні
для них відношення.
Онтологія дозволяє втримувати користувача в максимально
можливому просторі визначених наперед можливостей, зміст
яких зафіксовано і він зрозумілий як розробникові, так і
замовникові.
Для подання онтологій використовуються спеціальні нотації.
Наприклад, діаграми сутність-зв’язок мають форму графів, у
вузлах яких лежать поняття, а дуги відповідають відношенням
між ними.
17

18.

МОДЕЛІ ДИНАМІЧНИХ ЯВИЩ ДОМЕНУ
Розглянуті онтології відображають статичні властивості явищ
домену, які не враховують їхніх змін за часом. Але більшість
проблем, котрі вирішують за допомогою комп’ютерів, мають
справу з динамічними явищами, для яких відстеження їхньої
поведінки з перебігом часу є суттєвим аспектом вимог до
системи.
Домени з такими властивостями назвали динамічними
доменами.
Для динамічних доменів суттєвими поняттями є:
стан (state) (домену, системи, об’єкта тощо) - фіксація певних
властивостей на певний момент або інтервал часу;
інтервал стабільності (stability interval) - інтервал часу,
протягом якого не змінюється стан;
подія - явище, що провокує зміну певного стану як перехід до
іншого стану (ми розглядаємо лише дискретні процеси в
18
доменах).

19.

МОДЕЛІ ДИНАМІЧНИХ ЯВИЩ ДОМЕНУ
Поведінка домену в часі розглядається як прогрес від стану до
стану.
Серед динамічних доменів визначаються такі різновиди:
1. інертні домени (inertial domain), зміна станів яких ніколи не
відбувається з ініціативи об’єктів домену, а реалізується під
керуванням зовнішніх агентів. Наприклад, оброблення
текстів реалізується як результат виконання послідовних
команд оператора;
2. реактивні домени (reagent domain), зміна стану в яких є
відповіддю на певну зовнішню подію. Наприклад, автомат,
який видає цукерку у відповідь на монетку, кинуту в щілину
монетоприймача;
3. активні домени (active domain), які можуть переходити від
стану до стану без зовнішніх стимулів, як це робиться з
людиною або атмосферою.
19

20.

МОДЕЛІ ДИНАМІЧНИХ ЯВИЩ ДОМЕНУ
Визначаючи вимоги до системи, важливо одразу вирішити чи
планується вона як інертна, реактивна, чи як активна.
Наприклад, для медичної системи принципово визначити чи
планується вона як модель пацієнта, чи як реєстратор його
стану.
Найпоширенішою моделлю поведінки динамічних явищ є так
звана модель переходів у стани, яка базується на моделі
скінченного автомата.
1. Для кожного явища або об’ єкта, котрий має динамічну
поведінку, фіксуються стани, в яких він може перебувати.
2. Дозволяється мати кінцеву множину станів, при чому перехід
з одного стану до іншого відбувається дискретно і
зумовлюється тим, що відбулася певна подія.
3. Модель поведінки визначає стани, властиві домену, події, які
впливають на зміну стану в домені, та послідовність зміни
станів залежно від послідовності подій, що відбуваються.
20

21.

МОДЕЛЬ АЛГОРИТМІВ
Моделі алгоритмів, які застосовуються для формулювання
вимог, мають визначити ті дії або процеси, котрі супроводжують
переходи з одного стану в інший.
Зазвичай такі моделі визначають потоки даних, які
передаються від стану до стану чи від об’єкта до об’єкта, та
потоки управління між ними.
21

22.

ДЯКУЮ ЗА УВАГУ!
22