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

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

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

3.4.1 Інформаційна модель або онтологія домену. Пошук об’єктів

Як ми вже зазначили в п. 3.2.2, завданням першого етапу є виявлення суттєвих об’єктів і встановлення зв’язків (відношень) між ними. Для цього ми маємо, по-перше, знайти такі об’єкти, а по-друге, дати їм унікальні та значущі назви. Ці дії суто суб’єктивні, єдина рекомендація щодо цього, яку надали автори методу, полягає в переліку категорій, серед яких доцільно проводити пошук. Це такі категорії:

 реальні предмети світу, котрі фізично втілені, наприклад, Іван Іванович, стілець у кабінеті, Дніпро;

 абстракції фізичних предметів світу, наприклад, людина, тварина, літак, кабель, дім, сад;

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

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

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

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

Для класів об’єктів вибираються значущі імена, унікальні в межах домену.

Атрибути об’єктів. Склавши список виявлених об’єктів, для кожного з них потрібно визначити його характерні ознаки або властивості,

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

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

Для кожного з визначених атрибутів задаються його можливі значення (типи значень). Способи опису можливих значень можуть бути такі:

 числовий діапазон;

 перелік можливих значень;

 посилання на документ, у якому визначено можливі значення;

 правила генерації значень.

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

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

Подання інформаційної моделі в цьому методі базується на відомій реляційній моделі даних. Атрибути об’єктів подаються як атрибути відношень за такими правилами:

 кожний екземпляр об’єкта одночасно обов’язково має одне значення (тобто значення не може бути відсутнім або невизначеним);

 атрибут є одновимірним і не має внутрішньої структури або кількох значень одночасно;

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

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

Рисунок 3.1 - Зображення об’єктів з атрибутами

Зв’язки об’єктів. Визначивши склад класів об’єктів домену та властиві їм атрибути, розглянемо зв’язки (відношення) між об’єктами домену.

Об’єкти одного класу можуть брати участь у бінарних, тобто попарних зв’язках з об’єктами іншого або того самого класу.

Розглянемо кілька прикладів зв’язку:

 власник авто має авто, а авто належить власнику;

 прибиральник прибирає кімнату, а кімната прибирається ним;

 проект ведеться керівником, керівник веде проект;

 керівник займає кімнату, кімната належить керівнику;

 літак займає доріжку аеродрому, доріжка зайнята літаком;

 проект має виконавців, виконавці зайняті в проекті;

 керівник керує виконавцем, виконавець підпорядкований керівнику;

 виконавець займає кімнату, кімната містить виконавця. Кожна фраза фіксує можливість екземпляра певного класу об’єктів бути у певному відношенні (або зв’язку) з екземпляром іншого класу (приклади 1-5) або того самого класу (приклад 6). Суттєвою рисою наведених зв’язків є число екземплярів об’єктів, які можуть одночасно брати в ньому участь.

Розрізняються три фундаментальних види зв’язку:

 один до одного (1 : 1), коли у зв’язку беруть участь по одному екземпляру з кожного боку (приклад 5). Одночасно на одній злітній смузі може бути тільки один літак, і один літак може займати тільки одну смугу. Приклади 3 та 4 можуть також бути прикладами зв’язку 1:1, якщо в організації керівник займає окремий кабінет і керує одноосібно тільки одним проектом;

 один до багатьох (1 : n), коли один екземпляр об’єкта певного класу може підтримувати відношення одночасно з декількома екземплярами об’єктів іншого або того самого класу. Приклад 1. Якщо виключається спільне користування авто, але можна мати кілька авто. Інший приклад - 6, коли керівник може мати декілька підлеглих, але в кожного з них один шеф. Якщо керівник може керувати кількома проектами, то приклад 4 також належить до такого виду зв’язку;

 багато до багатьох (m : n), коли у зв’язку можуть брати участь по декілька екземплярів об’єктів з кожного боку. Це ілюструють приклади 1, якщо тими самими кількома автомашинами дозволяється користуватись декільком особам, та 2, коли декілька прибиральників прибирають по черзі кілька кімнат.

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

Подання інформаційної моделі проводиться в такий спосіб.

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

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

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

Рисунок 3.2 - Приклади фрагментів інформаційної моделі

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

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

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

Рисунок 3.3 - Приклади діаграм класів

3.4.2 Модель станів

Модель, яку буде розглянуто нижче, має відображати динаміку змін, котрі відбуваються в стані кожного з визначених у п. 3.4.1 класів об’єктів, або, як кажуть, динаміку їхньої поведінки. Зазначимо, що всі екземпляри одного класу об’єкта, за визначенням поняття клас, мають однакову поведінку. Нагадаємо наведені у п. 3.2.3 базові поняття моделі динаміки поведінки об’єктів:

 стан об’єкта визначається поточними значеннями окремих його атрибутів, а стан домену - сукупністю станів його об’єктів;

 стан об’єкта змінюється внаслідок того, що відбулися певні події або з’явилися певні стимули;

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

У методі, який ми розглядаємо, запропоновано одразу дві альтернативні нотації для фіксації динамічних аспектів вимог як поведінки визначених об’єктів. Одна з них - графічна - називається діаграмою переходів у стани (ДПС). Друга - таблична - називається таблицею переходів у стани (ТПС). Обидві нотації базуються на автоматі Мура, відомому з теорії автоматів. Згідно з цим методом, побудову моделі станів починаємо з того, що серед визначених інформаційною моделлю класів об’єктів виділяємо ті, котрі мають динамічну поведінку, тобто змінюють свій стан з плином часу, або, як кажуть, мають життєвий цикл від створення екземпляра об’єкта через зміни його станів і до зникнення об’єкта. Для відображення поведінки таких об’єктів у вимогах до розробки потрібно:

 визначити множину станів, в яких об’єкт може перебувати, при тому кожний стан є абстракцією стану, в котрому може перебувати кожен з екземплярів класу об’єктів;

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

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

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

Графічна нотація для подання наведеної вище інформації передбачає таке:

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

- кожній визначеній події присвоюють унікальну мітку та назву;

- на діаграмі ДПС стан позначається рамкою, яка містить номер та назву стану;

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

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

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

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

Зазначимо, що при застосуванні ТПС дії, відповідні станам, позначаються окремою нотацією.

Зупинимося коротко на можливих діях при зміні станів.

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

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

 оброблення інформації, яку несе подія;

 зміна певного атрибута об’єкта;

 обчислення;

- генерація події для деякого екземпляра деякого класу (можливо, для самого себе);

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

- прийом повідомлення про події від зовнішніх об’єктів;

- взаємодія з двома специфічними об’єктами — таймером та системним годинником.

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

Атрибутами цього об’єкта є:

- унікальний ідентифікатор екземпляра таймера;

- залишок часу (інтервал часу, через який буде подано сигнал про настання певної події);

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

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

Приклад моделі станів з використанням таймера див. на рис. 3.4.

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

У табл. 3.1 наведено приклад ТПС, що відповідає ДПС, зображеній на рис. 3.4.

Таблиця 3.1- Приклад таблиці переходів

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

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

Рисунок 3.4 - ДПС автоматичної пральної машини

Все, що було сказано вище, стосується окремих об’єктів як базових складових - компонентів архітектури системи в цілому.

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

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

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

Приклад взаємодії моделей поведінки об’єктів наведено на рис. 3.5.

Рисунок 3.5 - Схема взаємодії моделей поведінки об’єктів

3.4.3 Модель процесів

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

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

 системний годинник як показник системного часу;

 таймери (див. п. 3.4.2);

 дані подій;

 повідомлення зовнішніх об’єктів (людей-операторів, приладів тощо). Правила побудови ДПДД подано нижче:

 кожному з ДПС станів може відповідати тільки одна ДПДД;

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

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

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

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

 потоки даних від таймера маркуються назвою таймера;

 потоки даних від системного годинника маркуються назвами показників часу (час, година, хвилина, день тощо);

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

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

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

Процеси розрізняються за такими типами:

 так званий аксесор, що здійснює доступ до архівів;

 генератор подій;

 перетворювач даних (обчислення);

 перевірка умов.

Потоки керування на ДПДД позначаються пунктирними стрілками.

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

Приклад ДПДД наведено на рис. 3.6.

Рисунок 3.6 - Приклад ДПДД

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

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

- ідентифікатор процесу;

- тип процесу (див. вище);

- назва процесу;

- назва стану, в якому визначено процес;

- назва дії стану.

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

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

3.4.4 Продукти інженерії вимог за методом С. Шлеєр та С. Меллора

За даним методом, результатом проведеного аналізу вимог до створюваної програмної системи є такі продукти:

1. Інформаційна модель системи (онтологія) у формі:

 діаграми сутність - зв’язок;

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

 опису зв’язків між об’єктами (подається неформально).

2. Модель поведінки об’єктів системи у формі:

 діаграми переходів у стани (ДПС) або таблиці переходів у стани (ТПС);

 опису дій ДПС (подається неформально);

 опису подій ДПС (подається неформально).

3. Модель процесів для станів об’єктів у формі:

 діаграми потоків даних дій (ДПДД);

 таблиці процесів станів;

 опису процесів (подається неформально).

Сукупність перелічених продуктів вважається достатньою для переходу до процесу проектування системи, мета і методи якого подаються в главі 4.