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

   1. Архітектура програмного забезпечення. Проектування архітектури.

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

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

• Стандартизований підхід

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

• Об’єктний підхід

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

• Загальносистемний підхід

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

2. Модель процесу проектування програмного забезпечення.

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

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

1. Модель потоків даних, де система моделюється у вигляді потоку даних, що проходять в цій системі.

2. Модель "сутність-зв'язок", яка застосовується для опису сутностей (об'єктів програмної системи) і зв'язків між ними. Ця модель часто використовується при проектуванні структур баз даних.

3. Структурна модель, призначена для документування системних компонентів і їх взаємозв'язків.

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

1. Архітектурні моделі програмного забезпечення.

1. Статична структурна модель (у якій представлені підсистеми або компоненти розроблюються надалі незалежно);

2. Динамічна модель процесів (представляє організацію процесів під час роботи системи);

3. Інтерфейсна модель (визначає сервіси, надавані кожною підсистемою через загальний інтерфейс);

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

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

4. Структурні моделі архітектури програмного забезпечення.

Мають 3 стандартні моделі:

• Модель репозиторія

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

• Модель клієнт-сервер (модель розподіленої системи)

Заснована на взаємодії 3 компонентів:

1. Сервери – надають послуги;

2. Клієнти – викликають сервіси;

3. Мережа – за допомогою якої клієнт отримує доступ до сервісів.

• Модель абстрактної машини

Організує систему у вигляді набору рівнів, кожен з яких надає свої сервіси. Кожен рівень визначає абстрактну машину та мову

5. Архітектурна модель репозиторія.

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

Плюси:

• Ефективність;

• Централізація засобів управління даними;

• Прозорість моделі спільного використання;

• Багатозадачність.

Мінуси:

• Всі підсистеми повинні бути узгоджені з моделлю сховища даних;

• Проблема розподіленого зберігання сховища;

• Складність перекладу вже існуючих систем на цю модель;

• Однакові вимоги безпеки до всіх підсистем.