Об’єктно-орієнтований підхід до розробки вимог

1.Візуальний підхід представлення вимог до ПС

2.Текстове представлення вимог до ПС

3.Аналіз вимог до ПС

 

В об’єктно-орієнтованих підходах і методах розробки програмних систем головним є об'єкт. Для нього задаються вимоги за допомогою варіантів використання (use case), сценаріїв або прецедентів. Наведені сценаріями або прецедентами вимоги до системи в UML послідовно трансформуються до інших сценаріїв, що наближають до логічної та виконуваної структури системи. Головні їх елементи – сценарії і актори, що задають дії щодо виконання сценаріїв системи.

1.Візуальний підхід

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

Термін сценарій позначає деякий варіант подання моделі виконання системи [1, 5, 6]. При застосуванні сценарного підходу загальна метасистема декомпозується на окремі підцілі, для яких визначаються функціональні або нефункціональні вимоги і проектні рішення.

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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

Відношення між сценаріями.

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

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

 

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

 

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.Текстове представлення вимог до ПС

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

Головною умовою задання вимог прецедентами є повнота системних вимог до інтерфейсу користувача, до протоколів і форматів ведення [2,5].

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

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

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

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

Змістовна сторона системних вимог – опис функцій, даних і умов функціонування. Методологія формування вимог за допомогою прецедентів реалізована в середовищі Rational Rose (www.rational.com.uml) і передбачає побудову ряду моделей на їхній основі.

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

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

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

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

– використовуваних термінів (глосарія) предметної області;

– головних діючих осіб і їхніх цілей;

– використовуваних технологій і принципів взаємодії з іншими системами;

– вимог до форматів і протоколів взаємодії;

– вимог до тестування і до процедури розгортання системи у замовника;

– організації керування процесом розробки системи.

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

Із синтаксичної точки зору ця модель має такий вигляд.

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

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

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

3.Аналіз вимог до ПС

До основних понять методів об’єктно-орієнтованого аналізу предметної області – ПрО належать наступні [1–6].

Об’єкт – це абстрактний елемент, що має поведінку, обумовлену його характеристиками і відношеннями з іншими об’єктами предметної області.

Відповідно до теорії Фреге [14] специфікацію об’єкта можна трактувати як трійку: <ім’я об’єкта > <денотат > <концепт>, де <ім’я об’єкта> – ідентифікатор, рядок з літер і чисел; <денотат> – сутність реальної ПрО, що позначається цим ідентифікатором; <концепт > – семантика (зміст) денотата ПрО.

Схематично це можна подати за допомогою трикутника Фреге (рис 4.4).

 

 

Рис. 4.4. Подання об’єктів ПрО за трикутником Фреге

 

В ньому містяться елементи реального світу, які мають такі властивості і характеристики:

знак – ідентифікатор, який позначає денотат;

денотат – сутність знаку,позначеного цим ідентифікатором;

концепт – семантика денотату.

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

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

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

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

Сутність – це семантично важливий об’єкт або значення об’єкта, що існує в ПрО і є абстрактним поняттям, інформацію про яке необхідно знати і/або зберігати [10–13]. Ім’я сутності повинно бути унікальним в межах ПрО і може зображати тип або клас об’єктів. Сутність може мати синоніми (наприклад, аеропорт/аеродром).

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

Атрибут – це сутність концепту, що позначається ім’ям, унікальним у межах опису цього концепту.

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

Клас – це множина об’єктів, що мають однакові властивості, зв’язки і методи.

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

На множині цих понять визначається простір проблем (problem space) і простір рішень (solution space) [13].

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

Об’єкт ПрО, як абстракція реального світу і понятійна структура, має поведінку, обумовлену властивостями даного об’єкта і його зв’язками з іншими об’єктами.

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

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