В об’єктно-орієнтованих підходах і методах розробки програмних систем головним є об'єкт. Для нього задаються вимоги за допомогою варіантів використання (use case), сценаріїв або прецедентів.
Наведені сценаріями або прецедентами вимоги до системи в UML послідовно трансформуються до інших сценаріїв, що наближають до логічної та виконуваної структури системи. Головні їх елементи – сценарії і актори, що задають дії щодо виконання сценаріїв системи.
Візуальний підхід
Один з методів побудови моделі системи, логічної і фізичної моделей – це use case, що використовується для візуального зображення вимог у моделі системи, яка уточнюється і доповнюється новими сценаріями для одержання остаточних логічної і фізичної моделей системи. Термін сценарій позначає деякий варіант подання моделі виконання системи.
При застосуванні сценарного підходу загальна метасистеми декомпозується на окремі підцілі, для яких визначаються функціональні або нефункціональні вимоги і проектні рішення. Мета як джерело вимог до системи дає змогу виявити протиріччя й обмеження на функції й встановити залежності між ними, усунути конфлікти між цільовими функціями, а також об'єднати деякі з них між собою.
Після виявлення цілей визначаються носії інтересів, яким відповідає кожна мета, і можливі варіанти задоволення складених цілей у видгляді сценаріїв роботи системи, що допомагають користувачу одержати уявлення про призначення і виконання функції системи. Це відповідає першій ітерації визначення вимог до системи.
Далі виробляється послідовна декомпозиція складної проблеми до вигляду сукупності цілей, кожна з яких трансформується в сукупність можливих сценаріїв використання системи, а потім у сукупність взаємодіючих об'єктів. Тобто, маємо ланцюжок трансформацій:
проблема - ціль - сценарій - об'єкт,
що характеризує ступінь концептуалізації аналізованої проблеми та її декомпозицію на сценарії з варіантів використання. Трансформація даного ланцюга виражається в термінах базових понять предметної області й активно використовується для подання і розвитку моделей системи.
Кожен сценарій ініціює актор, що виступає в ролі користувача визначеної роботи в системі, що зображена цим сценарієм. Фіксацію ролей акторів можна розглядати як визначений крок при виявленні цілей системи і постановки задач, а також рішення, що буде виконувати система.
Актор – це зовнішній чинник і його дії мають недетермінований характер. У його ролі може виступати і програмна система, якщо вона ініціює виконання деяких робіт, що задовольняють поставлені цілі системи. Ним може бути абстракція зовнішнього об'єкта, людина або зовнішня система. У моделі системи актор може бути поданий класом, а користувач – екземпляром класу, хоча це і не обов’язково. Якщо актор – це система, то він репрезентує її інтереси. При цьому одна особа може бути екземпляром декількох акторів.
Якщо актор знаходиться поза системою, то він взаємодіє з нею через зовнішній сценарій, що ініціює послідовність операцій для виконання системи. Коли користувач як екземпляр актора ініціює певну подію для старту відповідного сценарію, то це приводить до виконання ряду дій у системі, що завершуються тоді, коли екземпляр сценарію перебуває в стані очікування чергової події або завершення сценарію.
Екземпляр сценарію існує, поки він виконується і його можна вважати екземпляром класу, він має свій стан і у нього своє поводження. Взаємодія між актором і системою породжує новий сценарій або об'єкт, що змінює внутрішній стан системи. Якщо кілька сценаріїв системи мають однакове поводження, вони створюють клас сценаріїв.
При внесенні змін відбувається повторне моделювання дій акторів і сценаріїв, які запускаються ними в дію. Сценарій ініціюється актором і кожний з них обслуговує відповідну сукупність сценаріїв.
Для завдання моделі сценаріїв використовується графічна нотація UML з такими правилами:
– актор позначається зображенням – іконка людини і можливо з назвою;
– сценарій подається овалом, у середині якого назва зображення іконки;
– актор зв'язується лінейкою з кожним овалом сценарію, що запускається ним в дію.
Актор починає заданий сценарій при звертанні до автоматизованої системи обслуговування бібліотеки. Усі сценарії, що містяться у системі, обведені рамкою, яка визначає межі системи, а актор знаходиться поза рамкою як зовнішній чинник системи.
Відношення між сценаріями. Між сценаріями відношення задаються стрілками з указівкою назви типу відносин.
Для сценаріїв можна задавати два типи відношення:
1) відношення «розширює» означають, що функція одного сценарію є доповненням до функції іншого і використовується при наявності декількох варіантів одного й того самого сценарію.
Інваріантна частина сценарію зображується у вигляді головного сценарію, а окремі варіанти – як розширення. При цьому головний сценарій є стійким, не змінюється при розширенні варіантів функцій і не залежить від них;
2) відношення «використовує» означають, що деякий сценарій використовується як розширення інших сценаріїв.
Інженерія вимог завершується побудовою моделі вимог, що містить у собі:
1) опис вимог і основних понять ПрО;
2) модель сценаріїв;
3) інтерфейси сценаріїв.
Модель сценаріїв – це неформальний опис кожної з діаграм сценарію, що входять у нього і описується послідовністю таких елементів:
– назва сценарію на діаграмі моделі вимог у вигляді посилання до іншого сценарію;
– короткий зміст сценарію в неформальному зображенні;
– список акторів, що будуть запускати в дію сценарії;
– параметри взаємодії системи з акторами, їх заборонені дії і можливі наслідки;
– передумови, що визначають початковий стан сценарію на момент його запуску і умови успішного виконання;
– функції, що реалізуються при виконанні сценарію;
– нестандартні ситуації, що можуть з'явитися при виконанні сценарію (наприклад, помилка в діях актора або системи).
На наступних процесах ЖЦ сценарій актора в моделі вимог трансформується в сценарій поводження системи, до елементів моделі можуть додаватися нефункціональні вимоги, що забезпечують запуск сценарію, введення даних і відпрацювання нестандартних ситуацій.
У процесі проектування виконується трансформація сценарію в опис функціональних компонентів системи і перевірка їх за допомогою верифікації.
Вимоги користувачів до системи відбивають в описі інтерфейсів компонентів, що розміщаються в репозитарії. За допомогою сценаріїв можна побудувати прототип системи для моделювання дій акторів у процесі їхнього виконання і відпрацювання різних їхніх деталей.
