2.3.3 Вимоги щодо взаємодії з зовнішнім середовищем

Опис вимог..

2.4 Вимоги предметної галузі

2.5 Верифікація вимог

Опис верифікаійних вимог……

3 Розробка архітектури програмного забезпечення

3.1 Автоматна модель ПЗ

Опис автоматної моделі….

3.2 UML-діаграми (8 видів)

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

При проектуванні вищеописаної системи були використанні такі UML-діаграми: діаграма варіантів використання, діграма слідування, діаграма класів та звісно ж концептуальна діаграма бази даних оскільки проектована програмна система буде містити базу даних (не відноситься до UML-діаграм).

3.2.1 Діаграма варіантів використання

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

Як видно з діаграми в даній системі є тільки 4 дійових особи:

• Замовник

• Диспетчер

• Водій TAXI

• Адміністратор

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

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

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

Рисунок 3.2.1 – Діаграма варіантів використання.

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

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

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