15.2. Особливості об'єктного підходу до розробки зовнішнього опису програмного засобу.
При об'єктному підході етап зовнішнього опису ПС виявляється істотно більш ємким і змістовним в порівнянні з реляційним підходом [15.3, 15.4, 15.5, 15.6].
Визначення вимог полягає в неформальному описі модельного світу, який користувач збирається вивчати або просто використовувати за допомогою необхідного ПС. При цьому підвищується роль прототипирования, яке при цьому підході часто окупається зменшенням об'єму роботи на подальших етапах розробки ПС. Часто визначення вимога завершується розробкою діаграми варіантів використання, в якій фіксуються, в яких випадках використовуватиметься ПС. Це дозволяє при розробці ПС обмежитися тільки такими її функціональними можливостями, які підтримують ці випадки (варіанти) використання. По суті, діаграма варіантів використання є описом деякого контексту використання (див. лекцію 4). На мал. 15.1. приведений приклад діаграми варіантів використання [15.6].
Істотно змінюється зміст процесу специфікації вимог: замість розробки функціональної специфікації ПС створюється формальний опис модельного миру, що складається з трьох частин:
об'єктній моделі
динамічній моделі
функціональній моделі.
Призначення цих частин можна образно визначити таким чином [15.3]: об'єктна модель визначає те, з чим щось трапляється; динамічна модель визначає, коли це трапляється; функціональна модель визначає те, що трапляється.
Мал. 15.1. Діаграма варіантів використання для банкомату.
Об'єктна модель показує статичну об'єктну структуру модельного світу, який повинно представляти ПС, що розробляється (програмна система). Вона включає визначення використовуваних класів об'єктів і відносин між цими класами, а також визначення використовуваних об'єктів цих класів і відношення між цими об'єктами.
Зазвичай клас об'єктів в об'єктній моделі представляється у вигляді трійки
(Ім'я класу, Список атрибутів, Список операцій).
Кожен атрибут представляється деяким ім'ям і може приймати значення певного типу. По суті, атрибут класу виражає деяка проста властивість об'єктів цього класу. Представлення деяких простих властивостей об'єктів атрибутами вельми зручно, особливо коли по значеннях цих атрибутів здійснюється класифікація об'єктів. Операції, що указуються в представленні класу, відображають інші властивості об'єктів цього класу (як прості, так і асоціативні). Вони показують, що можна робити з об'єктами цього класу (або що можуть робити самі ці об'єкти).
У об'єктній моделі відношення між об'єктами деяких класів узагальнюються у відносини між цими класами. При цьому використовуються, як правило, тільки одномісні і двомісні відносини між об'єктами. Складніші відносини приводить до невиправданого ускладнення об'єктних моделей, а з іншого боку, такі відносини завжди можуть бути зведені до двомісних за рахунок визначення додаткових класів. Одномісні відносини називають атрибутами, причому деякі атрибути об'єкту виходять з атрибутів класу привласненням ним конкретних значень. Відношення між двома (і більш) об'єктами називають зв'язками, а їх узагальнення (відношення між класами) зазвичай називають асоціаціями. Асоціації визначають допустимі зв'язки між об'єктами. Розрізняють наступні види асоціацій:
взаємодії станів об'єктів
агрегації (структуризації) об'єктів
абстрагування (породження) класів.
Асоціація «взаємодія», по суті, означає, що об'єкти класів, що знаходяться в такому відношенні, можуть бути параметрами деяких операцій. Асоціація «агрегація» означає, що об'єкт один з класів, що знаходяться в такому відношенні, включає (або може включати) (як частина) об'єкти іншого з цих класів. Асоціація «абстрагування» означає, що один з класів, що знаходяться в такому відношенні, успадковує властивості іншого з цих класів і може володіти також і іншими (додатковими) властивостями.
Мал. 15.2. Приклад відношення між класами об'єктів.
Для представлення об'єктної моделі часто використовуються графічні мови специфікації об'єктів (наприклад, мова UML [15.5]). На таких мовах класи і об'єкти задаються прямокутниками, яких указується інформація, що специфікує їх. Для завдання відносин між двома класами відповідні ним прямокутники зв'язуються лінією, забезпеченою різними графічними значками і деякими написами. Графічні значки специфікують характер (вигляд) відношення між цими класами, а написи забезпечують повну ідентифікацію цього відношення (роблять його конкретним). Наприклад, на мал. 15.2 задане відношення між класами Країна і Місто має характер «один до одного». Конкретніше це відношення означає, що кожен об'єкт класу Країна обов'язково зв'язаний відношенням «має столицею» з одним і лише одним об'єктом класу Місто, і цей об'єкт класу Місто не зв'язане таким відношенням ні з яким іншим об'єктом класу Країна.
Для опису декомпозиції об'єктів використовується відношення виду агрегації. Наприклад, відношення «програма складається з одного або декількох модулів» представлено на мал. 15.3.
Мал. 15.3. Приклад відношення агрегації між класами об'єктів.
Слід відмітити, що об'єктна модель повністю включає опис зовнішнього інформаційного середовища при реляційному підході.
Динамічна модель показує допустимі послідовності змін станів об'єктів з об'єктної моделі модельного світу, який повинно представляти ПС, що розробляється (програмна система). Вона описує послідовності операцій у відповідь на зовнішні сигнали (взаємодії) без розгляду того, що ці операції роблять. Динамічна модель необхідна, якщо у відповідній об'єктній моделі є активні об'єкти.
Основні поняття динамічної моделі: події і стани об'єктів. Під подією тут розуміється елементарна дія одного об'єкту на іншій, що відбувається в певний момент часу. Одна подія може логічно передувати іншому або бути не пов'язаною з іншим. Іншими словами, події в динамічній моделі частково впорядковані. Під станом об'єкту тут розуміється сукупність значень атрибутів об'єкту і представлення поточних зв'язків цього об'єкту з іншими об'єктами. Стан об'єкту зв'язується з інтервалом часу між деякими двома подіями, на які реагує цей об'єкт. Об'єкт переходить з одного стану в інше в результаті реакції на деяку подію (в кінці інтервалу, пов'язаного з цим станом).
Мал. 15.4. Діаграма станів телефонної лінії.
У зв'язку з цим в динамічній моделі для кожного класу активних об'єктів будується своя діаграма станів. Вона є граф, вершинами якого є стани, а дугами – переходи між цими станами (переходи часто позначаються іменами подій). Деякі переходи можуть бути пов'язані з умовами, що вирішують ці переходи. Умова – це предикат, залежний від значень деяких атрибутів об'єкту. Кожна умова указується на дузі, переходом по якій управляє ця умова. Істотно, що в діаграмі станів з деякими станами або подіями зв'язуються певні операції. Операція, що пов'язується з подією, позначає реакцію об'єкту на цю подію і вважається, що вона виконується миттєво (у точці деякого тимчасового інтервалу). Така операція називається дією. Операція, що пов'язується із станом, виконується в рамках тимчасового інтервалу, з яким пов'язаний цей стан (тобто має тривалість, обмежену цим інтервалом). Така операція називається діяльністю. Діаграма станів визначає управління активізацією вказаних операцій. Таким чином, діаграма станів описує поведінку одного класу об'єктів. Приклад діаграми станів класу приведений на мал. 15.4.
Динамічна модель в цілому об'єднує всі діаграми станів за допомогою подій між класами.
Функціональна модель показує, як обчислюються вихідні значення з вхідних без вказівки порядку, в якому ці значення обчислюються. Вона визначає всі операції, умови і обмеження, використовувані в об'єктній і динамічній моделях (зовнішні операції). Функціональна модель відповідає визначенню зовнішніх функцій при реляційному підході до розробки ПС.
Для визначення крупних операцій у функціональній моделі використовуються потокові діаграми (діаграми потоків даних), що дозволяють виразити ці операції через простіші операції. Основними поняттями потокових діаграм є процеси, об'єкти і потоки даних. Потокова діаграма – це граф, вершинами якого є об'єкти або процеси, а дугами – потоки даних. Процеси перетворять дані, що поступають від одних об'єктів і направляються для зберігання в інші об'єкти. Ці процеси представляють внутрішні операції, через які виражається операція, що представляється даною потоковою діаграмою. Об'єкти можуть бути пасивними (сховищами даних) і активними (агентами). Пасивні об'єкти використовуються тільки для зберігання даних, а активні об'єкти використовуються як для зберігання, так і для перетворення даних. Потоки даних визначають допустимі напрями переміщення даних і типи переміщуваних даних.
Процеси можуть виражатися термінальними операціями (визначувані безпосередньо) або за допомогою інших потокових діаграм. Таким чином, потокові діаграми є ієрархічними.
Термінальні операції визначаються так само, як і при реляційному підході (див. лекції 4 і 5). Втім, і діаграми потоків даних використовуються при реляційному підході.
Таким чином, основним змістом етапу зовнішнього опису при об'єктному підході є об'єктне моделювання. При цьому широко використовуються формальні мови специфікацій, у тому числі і графічні. Одним з найбільш споживаних в даний час таких мов є мова UML [15.5].