Об’єктно-орієнтована інженерія вимог.

В об’єктно-орієнтованих підходах і методах розробки програмних систем головним є об'єкт. Для нього задаються вимоги за допомогою варіантів використання (use case), сценаріїв або прецедентів.

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

Візуальний підхід[ред. • ред. код]

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

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

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

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

проблема ® ціль ® сценарій ® об'єкт,

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

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

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

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

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

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

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

– актор позначається зображенням – іконка людини і можливо з назвою;

– сценарій подається овалом, у середині якого назва зображення іконки;

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

Приклад діаграми сценаріїв для читача бібліотеки в ролі актора подано на рис. 4.1.

· Рис. 4.1. Приклад діаграми сценаріїв для читача

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

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

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

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

· Рис. 4.2. Приклад відношення «розширює»

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

2) відношення «використовує» означають, що деякий сценарій використовується як розширення інших сценаріїв (рис. 4.3).

На рис. 4.3 показано сценарій «ведення репозитарію», що зв'язаний відносинами «використовує» з декількома сценаріями – розроблення інтерфейсу, опис компонента, створення схеми розгортання.

· Рис. 4.3. Приклад відносин «використовує»

Інженерія вимог завершується побудовою моделі вимог, що містить у собі:

1) опис вимог і основних понять ПрО;

2) модель сценаріїв;

3) інтерфейси сценаріїв.

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

– назва сценарію на діаграмі моделі вимог у вигляді посилання до іншого сценарію;

– короткий зміст сценарію в неформальному зображенні;

– список акторів, що будуть запускати в дію сценарії;

– параметри взаємодії системи з акторами, їх заборонені дії і можливі наслідки;

– передумови, що визначають початковий стан сценарію на момент його запуску і умови успішного виконання;

– функції, що реалізуються при виконанні сценарію;

– нестандартні ситуації, що можуть з'явитися при виконанні сценарію (наприклад, помилка в діях актора або системи).

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

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

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

Характеристика областей знань з інженерії програмного забезпечення – SWEBOK[ред. • ред. код]

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

Ядро знань SWEBOK – основний науково-технічний документ, що відображає знання та досвід багатьох іноземних і вітчизняних фахівців з програмної інженерії [1–10] і узгоджується з регламентованими процесами ЖЦ стандарту ISO/IEC 12207.

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

Для подання понятійного апарату областей знань SWEBOK проведемо умовне розділення областей на головні (п'ять областей для розроблення ПС, рис. 1.7) і допоміжні організаційні області (п'ять областей, що забезпечують інженерію керування розробкою ПС, рис.1.8).

У кожній області наведені ключові поняття, підходи і методи проектування різних типів ПС. Розподіл областей на основні і допоміжні відповідає структурі розподілу процесів стандарту ISO/IEC 12207 (див. розділ 2), виконання яких визначається методами і засобами, запропонованими в ядрі знань SWEBOK.

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

Супровід програмного забезпечення[ред. • ред. код]

Докладніше: Супровід програмного забезпечення

Супровід програмного забезпечення^[4] – сукупність дій із забезпечення його роботи, внесення змін при виявленні помилок, адаптації ПЗ до нового середовища функціонування, а також підвищення продуктивності або поліпшення деяких характеристик ПЗ. У зв'язку з вирішенням так званої проблеми 2000 року (пов’язаної з кодуванням дат у новому тисячолітті, зокрема, у двохсимвольному форматі) супроводження почав розглядатися, як більш важливий процес, що здійснюють розробники. Після змін система має вирішувати ті самі задачі, а також мати план перенесення інформації в інші БД. Супровід відповідно до стандартів ISO/IEC 12207 і ISO/IEC 14764 проводиться з метою виконання і модифікації програмного продукту в процесі експлуатації за умови збереження його цілісності.

Область знань «Супровід ПЗ (Software Maintenance)» складається з таких розділів:

– основні концепції (Basic Concepts),

– процес супроводження (Process Maintenance),

– ключові питання супроводу ПЗ (key Issue in Software Maintenance),

– техніки супроводу (Techniques for Maintenance).

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

Основні концепції – це базові визначення і термінологія, підходи до еволюції і супроводу ПЗ, до оцінки вартості супроводу тощо. До основних концепцій можна віднести ЖЦ ПЗ (стандарт ISO/IEC 12207) і складання документації. Головне призначення цієї області знань полягає у виконанні готової програмної системи, фіксації помилок, що виникають при виконанні, дослідженні їх причин, аналізі необхідності модифікації системи з метою усунення помилок, оцінці вартості робіт із проведення змін функцій і системи в цілому. Розглядаються проблеми, пов'язані з ускладненістю продукту при великій кількості змін, і методи її подолання.

Процес супроводження містить у собі моделі процесу супроводу і планування діяльності людей, що проводять запуск ПЗ, перевірку правильності його виконання і внесення в нього змін. Цей процес згідно з стандартом ISO/IEC 14764 проводиться шляхом:

– коригування, тобто зміни продукту для усунення виявлених помилок або нереалізованих задач;

– адаптації, тобто настроювання продукту в умовах експлуатації, що змінилися, або в новому середовищі виконання;

– поліпшення, тобто еволюційної зміни продукту для підвищення продуктивності або рівня супроводу;

– перевірки ПЗ, пошуку і виправлення помилок при експлуатації системи.

Ключові питання супроводу ПЗ – це управлінські, вимірювальні і вартісні. Суть управлінських питань – контроль ПЗ при модифікації й удосконалюванні функцій і недопущення зниження продуктивності системи. Питання вимірювання пов'язане з оцінкою характеристик системи після її модифікації, а також повторного тестування для оцінки показників якості. Вартісні питання пов'язані з оцінкою витрат на супровід залежно від його типу, кваліфікації персоналу, платформи й ін.

Техніка супроводу (цей розділ називають також еволюцією ПЗ). Відомий фахівець в області ПЗ Дж. Леман (1970 р.) запропонував розглядати супровід як еволюційну розробку програмних систем, оскільки здана в експлуатацію система не завжди цілком завершена, її треба змінювати протягом терміну експлуатації. Внаслідок змін система стає більш складною і погано керованою. У зв'язку з цим виникає проблема зменшення її складності. До технологій еволюції ПЗ відносять реінженерію, реверсну інженерію і рефакторинг.

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

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

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

Інженерія вимог[ред. • ред. код]

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

Вимоги відбивають потреби людей (замовників, користувачів, розробників), зацікавлених у створенні ПЗ. Замовник і розробник спільно виявляють вимоги, аналізують, переглядають, визначають необхідні обмеження і умови, а також описують їх. Розрізняють вимоги до продукту і до процесу, а також функціональні, не функціональні і системні вимоги. Функціональні вимоги визначають призначення і функції системи, а не функціональні – умови стосовно виконання ПЗ, його переносності і доступу до даних. Системні вимоги описують вимоги до програмної системи, яка складається з взаємозалежних програмних і апаратних підсистем і різних застосувань.

Область знань «Вимоги до ПЗ (Software Requirements)» складається з таких розділів:

· інженерія вимог (Requirement Engineering),

· виявлення вимог (Requirement Elicitation),

· аналіз вимог (Requirement Analysis),

· специфікація вимог (Requirement Specification),

· валідація вимог (Requirement validation),

· керування вимогами (Requirement Management).

Інженерія вимог до ПЗ – це дисципліна аналізу і документування вимог до ПЗ, що полягає в перетворенні запропонованих замовником вимог до системи на опис вимог до ПЗ і їх валідації.

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

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

Специфікація вимог до ПЗ – процес формалізованого опису функціональних і нефункціональних вимог, вимог до характеристик якості відповідно до стандарту якості ISO/IEC 9126, які будуть відпрацьовуватися на процесах ЖЦ ПЗ.

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

Керування вимогами – це керування процесами формування вимог на всіх процесах ЖЦ, а також змінами й атрибутами вимог, проведення моніторингу – відновлення джерела вимог.

Проектування програмного забезпечення[ред. • ред. код]

Проектування ПЗ – це процес визначення архітектури, набору компонентів, їх інтерфейсів, інших характеристик системи і кінцевого складу програмного продукту. Область знань «Проектування ПЗ (Software Design)» складається з таких розділів: – базові концепції проектування ПЗ (Software Design Basic Concepts), – ключові питання проектування ПЗ (Key Issue in Software Design), – структура й архітектура ПЗ (Software Structure and Architecture), – аналіз і оцінка якості проектування ПЗ (Software Design Quality Analysis and Evaluation), – нотації проектування ПЗ (Software Design Notations), – стратегія і методи проектування ПЗ (Software Design Strategies and Methods). Базова концепція проектування ПЗ – це методологія проектування архітектури за допомогою різних методів (об'єктного, компонентного й ін.), процеси ЖЦ (стандарт ISO/IEC 12207) і техніки – декомпозиція, абстракція, інкапсуляція й ін. На початкових стадіях проектування предметна область декомпозується на окремі об'єкти (при об’єктно-орієнтованому проектуванні) або на компоненти (при компонентному проектуванні). Ключові питання проектування – це декомпозиція програм на функціональні компоненти для незалежного і одночасного їхнього виконання, розподіл компонентів у середовищі функціонування і їх взаємодія між собою, забезпечення якості і живучості системи й ін. Проектування архітектури ПЗ проводиться архітектурним стилем, заснованим на визначенні основних елементів структури – підсистем, компонентів, об'єктів і зв'язків між ними. Аналіз і оцінка якості проектування ПЗ – це заходи щодо аналізу сформульованих у вимогах атрибутів якості, функцій, структури ПЗ, з перевірки якості результатів проектування за допомогою метрик (функціональних, структурних і ін.) і методів моделювання і прототипування. Нотації проектування дозволяють представити опис об'єкта (елемента) ПЗ і його структуру, а також поведінку системи за цим об’єктом. Існує два типи нотацій: структурна, поведінкова, та множина їх різних представлень. Стратегія і методи проектування ПЗ. До стратегій відносять: проектування вгору, вниз, абстрагування, використання каркасів і ін.

Конструювання програмного забезпечення[ред. • ред. код]

Область знань «Конструювання ПЗ (Software Construction)» містить у собі такі розділи: – зниження складності (Reduction in Complexity), – попередження відхилень від стилю (Anticipation of Diversity), – структуризація перевірок (Structuring for Validation), – використання стандартів (Use of External Standards). Зниження складності – це мінімізація, зменшення і локалізація складності конструювання. Попередження відхилень від стилю. Для розв’язання різних задач конструювання застосовуються різні стилі конструювання (лінгвістичний, формальний, візуальний). Структуризація перевірок припускає, що побудова ПС структурована таким чином, що спрощується пошук помилок, дефектів і різних збоїв у процесі перевірок як на стадії незалежного тестування, так і в процесі експлуатації. Використання зовнішніх стандартів. Конструювання ПЗ залежить від застосовних зовнішніх стандартів, пов'язаних з мовами програмування, інструментальними засобами й інтерфейсами. Керування конструюванням – це керування процесом конструювання ПЗ, планування, оцінка виконання плану і розроблення заходів щодо внесення змін.

Тестування програмного забезпечення[ред. • ред. код]

Тестування ПЗ – це процес перевірки готової програми в статиці (перегляди, інспекції, налагодження вихідного коду) і в динаміці (прогін на наборі тестових даних) з метою перевірки різних шляхів виконання програми і порівняння отриманих результатів із заздалегідь заданими. Область знань «Тестування ПЗ (Software Testing)» містить у собі такі розділи: – основні концепції і визначення тестування (Testing Basic Concepts and definitions), – рівні тестування (Test Levels), – техніки тестування (Test Techniques), – метрики тестування (Test Related Measures), – керування процесом тестування (Managing the Test Process). Основна концепція тестування – це базові терміни, ключові проблеми і їхній зв'язок з іншими областями знань. Тестування визначається як процес перевірки правильності програми в динаміці її виконання за тестовими даними. Рівні тестування: – тестування окремих елементів – інтеграційне тестування – тестування системи Техніки тестування базуються на певних теоретичних і практичних положеннях щодо проектування (компонентного, об'єктно-орієнтованого, сервісного і т.п.). Метрики тестування. Для вимірювання результатів тестування ПЗ й оцінки якості використовуються метрики. Вимір як частина планування і розробки тестів базується на розмірі програм, їх структурі і кількості виявлених помилок і дефектів. Метрики тестування – це вимірювання процесу планування, проектування і тестування, а також результатів тестування на основі таксономії відмов і дефектів, покриття границь тестування, перевірки потоків даних і ін.

Супровід програмного забезпечення[ред. • ред. код]

Супровід ПЗ – сукупність дій із забезпечення його роботи, внесення змін при виявленні помилок, адаптації ПЗ до нового середовища функціонування, а також підвищення продуктивності або поліпшення деяких характеристик ПЗ. Область знань «Супровід ПЗ (Software Maintenance)» складається з таких розділів: – основні концепції (Basic Concepts), – процес супроводження (Process Maintenance), – ключові питання супроводу ПЗ (key Issue in Software Maintenance), – техніки супроводу (Techniques for Maintenance). Основні концепції – це базові визначення і термінологія, підходи до еволюції і супроводу ПЗ, до оцінки вартості супроводу тощо. Ключові питання супроводу ПЗ – це управлінські, вимірювальні і вартісні. Суть управлінських питань – контроль ПЗ при модифікації й удосконалюванні функцій і недопущення зниження продуктивності системи. Техніка супроводу (цей розділ називають також еволюцією ПЗ). Відомий фахівець в області ПЗ Дж. Леман (1970 р.) запропонував розглядати супровід як еволюційну розробку програмних систем, оскільки здана в експлуатацію система не завжди цілком завершена, її треба змінювати протягом терміну експлуатації. Внаслідок змін система стає більш складною і погано керованою.

Методи об'єктного аналізу і моделювання[ред. • ред. код]