Загальні підходи до проектування програмних систем Стандартизований підхід.

Тривалий час в Україні та СРСР розроблення програмних систем (що називалися також автоматизованими системами — АС) виконувалась на основі стандарту ГОСТ 34.601–90, що регламентує стадії й етапи процесу розробки АС. Підставою для розроблення АС є договір між розробником системи та її замовником. Згідно з даним стандартом процес розроблення поділяється на такі етапи: формування вимог, розроблення концепції системи, ескізного, технічного і Розділ 4 91 робочого проекту.

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

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

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

Даний стандарт регламентує:

– концептуальне проектування, тобто побудову концептуальної моделі, уточнення рішень і узгодження вимог;

– архітектурне проектування – визначення головних структурних компонентів і особливостей системи;

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

– детальне робоче проектування – специфікація алгоритмів розв’язків задач МП, побудова БД і ПЗ системи. Розглянемо ці види проектування більш докладно.

При концептуальному проектуванні визначаються:

– джерела надходження даних від замовника, що несе відповідальність за їхню достовірність;

– об’єкти системи та їхні атрибути;

– способи подання зв’язків між об’єктами і види організації даних;

– цілі і функції системи й інтерфейси з її користувачами;

– методи взаємодії користувачів із системою.

Організація інтерфейсів зв’язана з конкретними формами екранів і форматами обміну даними, а також з визначенням:

1) термінів і понять, що мають значення для користувача і самої системи;

2) моделі системи, що відбиває функції і ролі, подання даних і форми видачі результатів;

3) візуальних прийомів відображення на екрані результатів роботи у наочній і звичній для користувачів формах;

4) методів взаємодії підсистем.

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

Перенесення виготовленої ПС на іншу платформу вимагає зміни параметрів, настроювання сервісів на нові умови середовища й адаптації використовуваних БД.

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

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

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

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

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

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

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

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