4.5. Проєктування програмного забезпечення

4.5.1. Види проєктування: структурне, обєктно-орієнтоване, архітектурне, інтерфейсне

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

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

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

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

Структурний підхід до проектування ІС (структурний аналіз/структурне проектування SA/SD — Structure Analyses & Structure Design) – метод визначення вхідних даних, процесів та вихідних даних системи і поділ систем на підсистеми або модулі, що показують логічну графічну модель потоків інформації.

Методологія SADT розроблена Дугласом Россом і отримала подальший розвиток в роботі [4]. На її основі розроблена, зокрема, відома методологія IDEF0 (розглянуто нижче).

Методологія SADT є сукупністю методів, правил і процедур, призначених для побудови функціональної моделі предметної області. Функціональна модель SADT відображує функціональну структуру об'єкту, тобто дії, що ним виконуються, і зв'язки між цими діями. Основні елементи цієї методології ґрунтуються на наступних концепціях.

• Графічне представлення блокового моделювання. Графіка блоків і дуг SADT-діаграми відображує функцію у вигляді блоку, а інтерфейси входа/выхода представляються дугами, що відповідно входять в блок і виходять з нього. Взаємодія блоків один з одним описуються за допомогою інтерфейсних дуг, що виражають "обмеження", які у свою чергу визначають, коли і яким чином функції виконуються і управляються.

• Строгість і точність. Виконання правив SADT вимагає достатньої строгості і точності, не накладаючи в той же час надмірних обмежень на дії аналітика. Правила SADT включають:

• обмеження кількості блоків на кожному рівні декомпозиції (правило 15.6 блоків);

• зв'язність діаграм (номери блоків);

• унікальність міток і назв (відсутність імен, що повторюються);

• синтаксичні правила для графіки (блоків і дуг);

• розділення входів і управлінь (правило визначення ролі даних);

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

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

Результатом методології SADT є модель, яка складається з діаграм, фрагментів текстів і глосарію, що мають посилання один на одного. Діаграми - головні компоненти моделі, усі функції ІС й інтерфейси на них представлені як блоки і дуги. Місце з'єднання дуги з блоком визначає тип інтерфейсу. Керівна інформація в блок зверху, тоді як інформація, яка піддається опрацюванню, показана з лівого боку блоку, а результати виходу показані з правого боку. Механізм (людина або автоматизована система), який здійснює операцію, представляється дугою, що входить в блок знизу.

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

Кожен компонент моделі може бути декомпозиціонований на іншій діаграмі. Кожна діаграма ілюструє "внутрішню будову" блоку на батьківській діаграмі.

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

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

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

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

Використання об'єктно-орієнтованої методології зараз нерозривно пов'язано з використанням мови UML (Unified Modeling Language - уніфікована мова моделювання), що “являє собою систему позначень, що базується на діаграмах і призначена для моделювання систем на основі об'єктно-орієнтованого підходу”.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В цілому процес створення інтерфейсу можна поділити на такі етапи:

• Аналіз

• Проєктування

• Дизайн

• Впровадження та налагодження