2.Структура програми

Загальну структуру програми можна відобразити використавши діаграми UML. UML – уніфікована мова моделювання, яка використовується у парадигмі об'єктно-орієнтованого програмування. Є невід'ємною частиною уніфікованого процесу розробки програмного забезпечення. UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проектування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація [12], [1].

UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм. Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем [12]. Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.

2.1 Діаграма прецедентів

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

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

Рисунок 2.1 – Діаграма прецидентів

На діаграмі прецидентів (див. рис. 2.1) зображено три актора «User», «Viewer» та «Worker». Актору «User» доступні операції додавання, редагування, видалення та замовлення ремонту комп’ютера. Також для тьох акторів доступно зробити авторизацію та регістрацію [1]. Для актора «Viewer» доступно лише переглянути список комп’ютерів, але не доступно додати, видалити, редагувати та замовити так як спершу він повинен бути знайомий системі. Актору «Worker» доступні функції отримання списку замовлених на ремонт комп’ютерів, отримання списку компонентів та ремонт компонента і виконання замовлення ремонту.

2.2 Діаграма класів

Діаграма класів – статичне представлення структури моделі. Відображає статичні (декларативні) елементи, такі як: класи, типи даних, їх зміст та відношення. Діаграма класів, також, може містити позначення для пакетів та може містити позначення для вкладених пакетів. Також, діаграма класів може містити позначення деяких елементів поведінки, однак їх динаміка розкривається в інших типах діаграм [12]. Діаграма класів служить для представлення статичної структури моделі системи в термінології класів об'єктно-орієнтованого програмування. На цій діаграмі (див. рис.2.2) показують класи, інтерфейси, об'єкти й кооперації, а також їхні відносини.

Рисунок 2.2 – Діаграма класів

Загальний опис зв’язків діаграми (див. рис. 2.2) можна представити UML зв’язками які включають в себе :

• асоціацї – об'єкти однієї сутності (класу) пов'язані з об'єктами іншої сутності. Якщо між двома класами визначена асоціація, то можна переміщатися від об'єктів одного класу до об'єктів іншого;

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

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

• залежність – смисловий зв'язок між залежними та незалежними елементами моделі. Він існує між двома елементами, якщо зміни у визначенні одного елемента (сервера або цілі) можуть спричинити зміни до іншого (клієнта чи джерела) [12][1].