ТЕМА 4
МЕТОДИ ОБ’ЄКТНОГО АНАЛІЗУ І МОДЕЛЮВАННЯ

 

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

Предметна область сама є самостійним об’єктом або може бути об’єктом у складі іншої предметної області.

Аналіз ПрО проводиться за допомогою об’єктно-орієнтованих методів і відповідних стандартів. Кінцева мета аналізу ПрО – визначення об’єктної моделі (ОМ), що містить у собі об’єкти та зв’язки (відношення) між ними. При побудові ОМ виявляються функціональні задачі, формулюються вимоги до їх проектування і подання структури системи. Об’єктна модель, вимоги і задачі − необхідні умови побудови архітектури майбутньої системи [1-13].

 

4.1. Огляд об’єктно-орієнтованих методів аналізу і побудови моделей

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

 

4.1.1. Основні поняття об’єктно-орієнтованих методів аналізу

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

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

Відповідно до теорії Фреге [14] специфікацію об’єкта можна трактувати як трійку:

<ім’я об’єкта > <денотат > <концепт>,

де <ім’я об’єкта> – ідентифікатор, рядок з літер і чисел;

 <денотат> – сутність реальної ПрО, що позначається цим ідентифікатором;

<концепт > – семантика (зміст) денотата ПрО.

Схематично це можна подати за допомогою трикутника Фреге (рис 4.1). В ньому містяться елементи реального світу, які мають такі властивості і характеристики:

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

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

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

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

 

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

 

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

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

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

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

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

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

Клас – це множина об’єктів, що мають однакові властивості, зв’язки і методи. Предметна область – це те, що аналізується з метою виділення специфічної множини понять (сутностей, об’єктів) і зв’язків між ними. На множині цих понять визначається простір проблем (problem space) і простір рішень (solution space) [13].

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

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

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

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

 

4.1.2. Метод побудови об’єктної моделі предметної області

Найбільше поширення серед методів аналізу ПрО одержав метод OOAS Шлеєра і Меллора [1], призначений для подання ПрО за допомогою таких моделей:

– інформаційна модель системи;

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

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

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

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

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

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

– абстракції реально існуючих об’єктів ПрО;

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

– взаємодії об’єктів, одержувані шляхом установлення зв’язків між ними і частинами системи;

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

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

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

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

– заданням числового діапазону;

– перерахуванням можливих значень, що може набувати атрибут;

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

– встановленням правил генерації припустимих значень.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Крім зв’язків розглянутих типів, між класами об’єктів ПрО може існувати відношення успадкування, що дозволяє визначити їх спільності та розбіжності. Коли клас B містить у собі усі атрибути й операції класу A і, можливо, має ще додаткові атрибути або операції, він (клас B) називається підкласом або нащадком, а клас A – суперкласом, або предком. Класи можуть утворювати ієрархію успадкувань довільної глибини, в яких кожний відповідає певному рівню абстракції і є узагальненням класу–нащадка та конкретизацію класу–предка. Наприклад, клас «число» має підкласи: цілі, дійсні, комплексні числа. Ці підкласи успадковують операції суперкласу, а саме, операції додавання, віднімання тощо. Але кожний підклас має свої особливості виконання цих операцій.

На діаграмі, що зображує ОМ, можуть бути показані не тільки класи, а й окремі їх екземпляри. Наприклад, на рис. 4.2. а) зображено клас дійсних чисел (х, у), а на рис. 4.1. б) – його екземпляр зі значенням атрибутів х, у.

 

Рис. 4.2. Зображення класу дійсних чисел (а) та його екземплярів (б)

 

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

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

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

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

Приклад інформаційної моделі з діаграмним відображенням зв’язків наведено на рисунку 4.3. У ньому зв’язок R3 є логічним наслідком зв’язків R1 і R2.

 

Рис. 4.3. Приклад діаграми інформаційної моделі

 

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

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

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

– станом, що змінюється внаслідок виконаних над об’єктами дій;

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

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

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

У даному методі передбачені дві нотації для подання динамічних аспектів поведінки об’єктів: діаграма переходу станів і таблиця переходу в стани.

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

1) множина станів, у яких об’єкт може перебувати;

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

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

4) дія, що виконується при переході об’єкта в новий стан.

Ця інформація подана на діаграмі переходу станів таким чином:

– кожний стан для класу об’єктів одержує назву, номер та унікальний ідентифікатор (ІD);

– стан позначається рамкою, що містить у собі номер і назву;

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

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

– заключний стан позначається штриховою лінією.

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

 

Рис. 4.4. Модель станів для обслуговування клієнтів

 

Зміна стану об’єкта відбувається при виконанні таких дій:

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

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

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

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

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

 

Таблиця 4.1. Переходи станів, що відповідають рисунку 4.3.

Номер події	Стан події А1	Стан події А2	Стан події А3
1. Чекання клієнта	2	Подія ігнорується	Не може відбутися
2. Чекання вільного клерка	Подія ігнорується	3	Не може відбутися
3. Визначення клерком клієнта	Подія ігнорується	Подія ігнорується	1

 

У цій таблиці кожен стан подано рядком, а кожна подія, що впливає на об’єкт, – стовпцем. Клітинка таблиці переходу станів – це стан об’єкта, якщо у відповідному стовпчику подія відбудеться (2, 3, 1), коли об’єкт знаходився в стані, що відповідає рядку.

При цьому допускається, що деякі комбінації подія/стан не приведуть до зміни стану екземпляра об’єкта, тобто буде отримана вказівку – «подія ігнорується».

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

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

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

 

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

 

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

Події на стрілках схеми ініціюють діяльність згідно з моделями станів 1-5 шляхом надсилання відповідних повідомлень.

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

Як джерело даних процесів можуть бути:

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

– системний годинник;

– таймер;

– дані про події, що відбуваються;

– повідомлення від зовнішніх об’єктів.

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

– кожній діаграмі переходу станів може відповідати тільки одна діаграма дій;

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

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

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

– джерела даних зображуються прямокутниками;

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

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

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

У даній моделі розрізняються процеси загального призначення, а саме:

– доступ до архівів;

– підготовка і верифікація об’єктів ПрО;

– обробка потоків даних і генерація подій;

– накопичення об’єктів і їхніх атрибутів в архіві системи;

– організація визначення функцій системи тощо.

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

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

 

Рис. 4.6. Приклад діаграми процесу створення репозитарію

 

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

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

– тип та назва процесу;

– назва стану, для якого визначений процес;

– назва дії процесу.

Таблиця процесів дає можливість перевірити:

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

– повноту визначених подій і відповідних процесів;

– генерацію події або її обробку відповідним процесом.

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

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

Даний об’єктний метод має багато спільного з методом Буча. Він реалізований у ряді інструментів (наприклад, EaseCASE Plus 4.0) і застосовується в різних областях (банківські операції, керування літальними апаратами, оформлення кредитних карток тощо) у США, Європі і Японії.

 

4.2. Проектування архітектури програмних систем

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

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

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

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

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

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

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

 

4.2.1. Загальні підходи до проектування програмних систем

Стандартизований підхід. Тривалий час в Україні та СРСР розробка програмних систем (що називалися також автоматизованими системами − АС) виконувалась на основі стандарту ГОСТ 34.601–90, що регламентує стадії й етапи процесу розробки АС. Підставою для розробки АС є договір між розробником системи та її замовником.

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

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

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

Даний стандарт регламентує:

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

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

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

– детальне робоче проектування – специфікація алгоритмів розв’язків задач МП, побудова БД і ПЗ системи.

Розглянемо ці види проектування більш докладно.

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

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

– об’єкти системи та їхні атрибути; – способи подання зв’язків між об’єктами і види організації даних;

– цілі і функції системи й інтерфейси з її користувачами;

– методи взаємодії користувачів із системою.

Організація інтерфейсів зв’язана з конкретними формами екранів і форматами обміну даними, а також з визначенням:

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

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

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

4) методів взаємодії підсистем.

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

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

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

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

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

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

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

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

 

4.2.2. Проектування різних видів архітектур програмних систем

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

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

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

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

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

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

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

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

Архітектурна схема може бути: розподілена, клієнт-серверна і багаторівнева.

Розподілена схема реалізує взаємодію компонентів системи, розташованих на різних комп’ютерах через стандартні протоколи виклику віддалених методів RPC (Remote Procedure Calls), RMI (Remote Method Invocation), що представлені в проміжних середовищах (COM/DCOM, CORBA) [15, 16]. Взаємодіючі компоненти можуть бути неоднорідними, створеними на різних мовах програмування (С, С++, Паскаль, Java, Basic, Smalltalk і ін.), що допускається в проміжному середовищі, наприклад, CORBA (рис. 4.7).

 

Рис. 4.7. Зв’язок між мовами L1, L2, …, Ln через інтерфейси CORBA

 

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

Інтерфейси між мовами L_i, L_n містять у собі опис:

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

– атрибутів викликів в stub і skeleton, що відображаються в операції, а операції – в методи.

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

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

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

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

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

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

Як метод проектування архітектури об’єктно-орієнтованих програмних систем застосовується UML [17, 18]. Зв’язки між об’єктами сервера і клієнта задаються діаграмами взаємодії або послідовності. Схема процесу розробки в UML з використанням stub і skeleton, семантику яких розглянуто вище, наведена на рисунку 4.8.

Діаграми станів задають обмеження на операції об’єктів сервера, визначаючи способи виклику операцій і поведінку об’єктів. Сутність стилю проектування в рамках уніфікованого процесу RUP [19] полягає в описі усіх видів діяльності, виконуваних на моделях (аналізу, проектування, розробки і тестування) процесу ЖЦ.

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

 

Рис. 4.8. Процес розробки інтерфейсних об’єктів з UML

 

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

1) кожна підсистема повинна відображати вимоги і спосіб їхньої реалізації (сценарій або прецедент);

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

3) зв’язок об’єктів здійснюється через інтерфейс;

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

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

Виділені в моделі аналізу об’єкти поєднуються в систему шляхом:

– логічного об’єднання і збирання об’єктів;

– комунікативного об’єднання об’єктів через загальне джерело даних;

– процедурного об’єднання за допомогою операторів виклику;

– функціонального об’єднання об’єктів.

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

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

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

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

Висновки. Проведено аналіз різних методів проектування моделей предметних областей. Значна увага приділена методу Шлеєра і Мелора, в якому визначено три види моделей і підхід до побудови на їхній основі архітектури програмних систем. Розглянуто методи проектування систем з використанням об’єктних і стандартних структур програмних систем.