Новини освіти і науки:

G+

Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция

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

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

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

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

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

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

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

Отже відбувається послідовна декомпозиція складності проблеми:

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

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

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

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

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

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

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

Екземпляр сценарію існує, поки він виконується. Його можна вважати екземпляром класу, описом якого є опис транзакції.

Для актора визначено такі правила:

кожен сценарій може запускати тільки один актор;

кожен актор може запускати кілька сценаріїв;

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

актор не визначає сценарію, він лише ініціює ланцюжок подій, який визначить сценарій;

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

Сценарій — це повне протікання подій у системі й, очевидно, має стан та поведінку. Кожна взаємодія між актором та системою розглядається як новий сценарій. Сценарій може розглядатися як об'єкт. Якщо багато запусків сценарію системи мають подібну поведінку, можемо розглядати їх як клас сценаріїв. Виклик сценарію є породженням екземпляра класу. Отже, сценарії — це транзакції із внутрішнім станом. Для них складаються детальні описи — вони є критичними для ідентифікації дійсних об'єктів системи.

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

Зокрема, відпрацьовується інтерфейс сценарію — за допомогою прототипу можна моделювати виконання сценарію.

Введення акторів дозволяє відповісти на запитання: для чого робиться система? Хто її головний користувач? Актори визначають зовнішнє оточення системи, а її внутрішня суть визначається сценаріями.

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

Можна виділити базову мету подій, суттєву для сценарію та його розуміння, а також альтернативні — в тому числі і при помилках користувача тощо.

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

Для моделі сценаріїв пропонується спеціальна графічна нотація, основні правила якої наведено нижче:

— актор позначається іконою людини, під якою вказується його

назва;

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

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

Приклад 1. На рис. 3.7 наведено приклад діаграми сценаріїв для клієнта банку.

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

Приклад 2. Нехай нам замовлено побудувати автоматизовану бібліотечну систему. Сформулюємо кілька складових мети її побудови:

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

На рис. 3.8 показано діаграму сценаріїв, що відповідає одному з варіантів вимог до бібліотечної системи. Розглянемо цей варіант.

Цілі 1—8 визначають ті бібліотечні процеси, які ми бажаємо автоматизувати. Вимогу до автоматизації певного процесу в системі, яку ми будуємо, буде представлено одним або кількома сценаріями.

Визначимо, які актори (користувачі) будуть запускати сценарії (виконувати доступні події) .

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

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

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

Приклад 3. Розглянемо систему, націлену на обслуговування роботи бібліотечної ради з формування фондів бібліотек.

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

Першим актором нашої системи визначимо адміністратора бібліотечного фонду, а другим — члена бібліотечної ради.

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

Рис. 3.9. Діаграма сценаріїв погодження замовлень

Адміністратор викликає сценарії:

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

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

Відношення між сценаріями. Між сценаріями можна задати певні відношення, які зображуються на діаграмі сценаріїв пунктирними стрілками, позначеними назвами відповідних відношень.

Для сценаріїв визначено два типи відношень:

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

Наведемо типові приклади (рис. 3.10), коли доцільне застосування відношення розширення:

а) для моделювання необов'язкових фрагментів сценаріїв (див. рис. 3.10, а);

б) для моделювання альтернативного перебігу подій у сценарії, що рідко відбувається (див. рис. 3.3 0, б);

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

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

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

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

На рис. 3.11 показано, що сценарій "сортувати" пов'язаний відношенням "використовує" з кількома сценаріями.

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

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

онтологія домену;
модель сценаріїв, яка називається діаграмою сценаріїв;
опис інтерфейсів сценаріїв.

Даний метод не регламентує жорстко нотацію для першої частини, тому можна скористатися нотацією моделі сутність — зв'язок, про яку йшла мова в п. 3.4.1.

Модель сценаріїв супроводжується неформальним описом кожного із сценаріїв, нотація якого не регламентується. Як один із варіантів, опис сценарію може бути подано як послідовність таких елементів:

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

На подальших стадіях осмислення проблеми сценарій використання трансформується в сценарій поведінки системи — до наведених елементів додаються ті, що пов'язані з конструюванням рішення цільової проблеми та не функціональними вимогами, як наприклад:

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

Отже, новий опис успадковує попередній і деталізує його.

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

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

Побудова прототипу системи, котра моделює реакцію цієї системи на дії актора, допоможе відпрацювати деталі й усунути взаємні непорозуміння між замовником і розробником.

<== попередня сторінка	\|	наступна сторінка ==>
	\|	Модель аналізу вимог. Визначення об'єктів

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.008 сек.