Уточнення вимог та адекватного розуміння їх замовником проводиться в кількох напрямах. Зупинимося на головних з них, котрі відповідають вимірам простору визначення завдань системи, наведеним у п. 3.5.2.

4.2.1 Уточнення даних

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

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

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

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

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

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

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

б) при зв’язку 1 : n додатковий атрибут надається об’єкту, N екземплярів якого можуть брати участь у зв’язку. Наприклад, якщо працівник має кілька станків, то такий зв’язок є шляхом надання об’єкту "станок" додаткового атрибута "власник";

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

Приклади зображення зв’язків а, б, в наведено на рис. 4.1.

Рисунок 4.1 - Приклади зображення зв’язків об’єктів

Для певних завдань зв’язки між об’єктами можуть еволюціонувати із часом, і фаза еволюції може суттєво впливати на хід виконання відповідного завдання. Для таких видів зв’язку обов’язково будується асоціативний об’єкт, для якого визначається модель станів (див. п. 3.4.2). Для подання стану асоціативного об’єкта до складу його атрибутів додається атрибут, який фіксує його поточний стан. Нехай для прикладу на рис. 4.1, в замовлення може перебувати в станах: "отримано", "готується", "чекає розрахунку", "сплачено", "готове" тощо, тоді до атрибутів асоціативного об’єкта додається, крім зазначених на рис. 4.1, в, ще й атрибут "стан виконання замовлення", який у певні моменти часу може приймати одне з наведених вище значень. Зазначимо, що серед дій, котрі супроводжують переходи в стани для моделі станів зв’язків, мають бути операції створення нового екземпляра асоціативного об’єкта (коли нова пара екземплярів вступає у зв’язок) та його знищення (коли зв’язок переривається).

4.2.2 Уточнення інтерфейсів

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

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

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

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

в) правила навігації (перегляду) даних, функцій та ролей;

г) візуальні прийоми демонстрації перед користувачем елементів, визначених у п. 1—3;

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

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

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

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

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

Зазначимо, що правила навігації мають враховувати традиції читання (зліва направо або навпаки).

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

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

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

4.2.3 Уточнення функцій оброблення даних

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

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

Взаємодія об’єктів організовується шляхом обміну повідомленнями, у відповідь на які об’єкти виконують відповідні операції і змінюють свій стан (див. п. 3.4.2) або посилають повідомлення іншим об’єктам. Для уточнення поведінки об’єктів можна рекомендувати використання моделей у вигляді діаграм, котрі відображають аспекти взаємодії об’єктів. Такі діаграми входять до складу методу UML, про який ми згадували у п. 3.3 і який детальніше обговорюється в розділі 5. Зокрема, моделі поведінки об’єктів викладено в п. 5.4.

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

4.2.4 Уточнення нефункціональних вимог

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

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

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