Лекція 5. Основи проектування програмних систем.

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

1. Особливості процесу синтезу програмних систем

Відомо, що технологічний цикл конструювання програмної системи (ПС) включає три процеси — аналіз, синтез і супровід.

Вході аналізу шукається відповідь на питання: «Що повинна робити майбутня система?». Саме на цій стадії закладається фундамент успіху всього проекту. Відома безліч невдалих реалізацій із-за неповноти і неточностей у визначенні вимог до системи.

Впроцесі синтезу формується відповідь на питання: «Яким чином система реалізовуватиме вимоги, що пред'являються до неї?». Виділяють три етапи синтезу: проектування ПС, кодування ПС, тестування ПС (мал. 5.1).

Розглянемо інформаційні потоки процесу синтезу.

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

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

Мал. 5.1. Інформаційні потоки процесу синтезу ПС

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

зміст.

Далі створюються тексти програмних модулів, проводиться тестування для об'єднання і перевірки ПС. На проектування, кодування і тестування доводиться більше 75% вартості конструювання ПС. Ухвалені тут рішення надають вирішальну дію на успіх реалізації ПС і легкість, з якою ПС супроводжуватиметься.

Слід зазначити, що рішення, що приймаються в ході проектування, роблять його стрижньовим етапом процесу синтезу. Важливість проектування можна визначити одним словом — якість. Проектування — етап, на якому «вирощується» якість розробки ПС. Справедлива наступна аксіома розробки: може бути погана ПС при хорошому проектуванні, але не може бути хорошою ПС при поганому проектуванні. Проектування забезпечує нас такими представленнями ПС, якість яких

43

Лекція 5. Основи проектування програмних систем.

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

2. Особливості етапу проектування

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

Зазвичай в проектуванні виділяють два ступені: попереднє проектування і детальне проектування. Попереднє проектування формує абстракції архітектурного рівня, детальне проектування уточнює ці абстракції, додає подробиці алгоритмічного рівня. Крім того, у багатьох випадках виділяють інтерфейсне проектування, мета якого — сформувати графічний інтерфейс користувача (GUI). Схема інформаційних зв'язків процесу проектування приведена на мал. 5.2.

Мал. 5.2. Інформаційні зв'язки процесу проектування

Попереднє проектування забезпечує: ідентифікацію підсистем;

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

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

2.Моделювання управління. Визначається модель зв'язків управління між частинами системи.

3.Декомпозиція підсистем на модулі. Кожна підсистема розбивається на модулі. Визначаються типи модулів і міжмодульні з'єднання.

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

3. Структуризація системи

Відомо чотири моделі системної структуризації: модель сховища даних; модель клієнт-сервер; трирівнева модель; модель абстрактної машини.

У моделі сховища даних (мал. 5.3) підсистеми розділяють дані, що знаходяться в загальній пам'яті. Як правило, дані утворюють БД. Передбачається система управління цією базою.

44

Лекція 5. Основи проектування програмних систем.

Мал. 5.3. Модель сховища даних

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

Мал. 5.4. Модель клієнт-сервер

Трирівнева модель є розвитком моделі клієнт-сервер (мал. 5.5).

Мал.5.5. Трирівнева модель

Рівень графічного інтерфейсу користувача запускається на машині клієнта. Бізнес-логіку утворюють модулі, що здійснюють функціональні обов'язки системи. Цей рівень запускається на сервері застосування. Реляційна СУБД зберігає дані, потрібні рівню бизнес-логики. Цей рівень запускається на другому сервері — сервері бази даних.

Переваги трирівневої моделі:

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

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

45

Лекція 5. Основи проектування програмних систем.

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

4. Моделювання управління

Відомо два типи моделей управління:

•модель централізованого управління;

•модель подієвого управління.

Умоделі централізованого управління одна підсистема виділяється як системний контроллер. Її обов'язки — керувати роботою інших підсистем. Розрізняють два різновиди моделей централізованого управління: модель виклик-повернення (мал. 4.7) і Модель менеджера (мал. 5.8),

яка використовується в системах паралельної обробки.

Мал. 4.5. Модель виклик-повернення

У моделі подієвого управління системою управляють зовнішні події. Використовуються два різновиди моделі подієвого управління: широкомовна модель і модель, керована перериваннями.

Мал. 5.8. Модель менеджера

У широкомовній моделі (мал. 5.9) кожна підсистема повідомляє обробника про свій інтерес до конкретних подій. Коли подія відбувається, обробник пересилає його підсистемі, яка може обробити цю подію. Функції управління в обробник не вбудовуються.

46