Використання методу покрокової деталізації для проектування структури програмного забезпечення

Структурна схема майбутнього програмного забезпечення

ПРИ СТРУКТУРНОМУ ПІДХОДІ

Тема: ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Лекція 13.

 

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

Проектування– це фаза ЖЦ, на якій виробляється, як реалізуються вимоги користувача, які породжені і зафіксовані на фазі аналізу. На цьому етапі здійснюється побудова моделі реалізації (або фізичної моделі), що демонструє як система задовольнятиме вимоги, які до неї ставлять. Фактично структурне проектування є мостом між структурним аналізом і реалізацією [11].

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

 

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

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

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


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

 

Рисунок 13.1 – Структурна схема програмного комплексу

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

Один з можливих варіантів повної структурної схеми програми побудови графіків/таблиць функції показаний на рис. 13.3.



Рисунок 13.3 – Повна структурна схема програми побудови графіків/таблиць функції


Структурний підхід до програмування в тому вигляді, в якому він був сформульований в 70-х роках XX ст., пропонував здійснювати декомпозицію програм методом покрокової деталізації. Метод був спочатку запропонований Е.Дейкстрою [2], а потім доповнений Н.Віртом. Результатом декомпозиції є структурна схема програми, яка являє собою багаторівневу ієрархічну схему взаємодії підпрограм по керуванню. Мінімально така схема відображає два рівні ієрархії, тобто показує загальну структуру програми. Проте цей же метод дозволяє отримати структурні схеми з великою кількістю рівнів. Метод покрокової деталізації реалізує низхідний підхід і базується на основних конструкціях структурного програмування. Він припускає покрокову розробку алгоритму. Кожен крок при цьому включає розкладання функції на підфункції. Так на першому етапі описують рішення поставленої задачі, виділяючи загальні підзадачі, на наступному аналогічно описують вирішення підзадач, формулюючи при цьому підзадачі наступного рівня. Таким чином, на кожному кроці відбувається уточнення функцій майбутнього програмного забезпечення. Процес продовжують, поки не доходять до під задач алгоритми вирішення яких очевидні. При декомпозиції програми методом покрокової деталізації, слід дотримуватися основного правила структурної декомпозиції, який слідує з принципу вертикального керування: в першу чергу деталізувати керуючі процеси самого компонента декомпозиції, залишаючи уточнення операцій з даними наприкінці. Це пов'язано з тим, що пріоритетна деталізація керуючих процесів істотно спрощує структуру компонентів всіх рівнів ієрархії і дозволяє не відокремлювати процес ухвалення рішення від його виконання: так визначивши умову вибору деякої альтернативи, зразу ж викликають модуль, що її реалізовує.

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

Окрім цього, доцільно дотримуватися наступних рекомендацій:

• не відокремлювати операції ініціалізації і завершення від відповідної обробки, оскільки модулі ініціалізації і завершення мають погану зв’язаність (тимчасову) і сильне зчеплення (по управлінню);

• не проектувати дуже спеціалізованих або дуже універсальних модулів, так як проектування надмірно спеціальних модулів збільшує їх кількість, а проектування надмірно універсальних модулів підвищує їх складність;

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

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

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

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

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

Концепцію псевдокоду найлегше з'ясувати на прикладі. Хай потрібно визначити найбільше значення в деякому наборі даних і вивести ці дані, поділені на найбільше значення. Скажімо, якщо дані є послідовністю чисел: 4., 2.51, 10, -5, 7.5.

Вивід повинен виглядати таким чином:0.4, 0.251, 1, -0.5, 0.75.

Рівень 1:

1. ввести дані;

2. знайти максимум введених даних;

3. вивести результати.

Деталізація 1.1. Введення даних можна деталізувати на псевдокоді таким чином:

1. визначити кількість чисел;

2. поки не всі елементи введені, прочитати і запам'ятати значення елементу;

3. кінець циклу.

Деталізація 1.2. Відшукання максимуму можна деталізувати таким чином:

1. вибрати як максимум перший елемент даних;

2. пробігти всі введені значення, замінюючи поточний максимум

3. на чергове значення, якщо воно не перевищило його.

Деталізація 1.3. Виведення результатів можна деталізувати таким чином:

1. поки не всі результати виведені;

2. виведення значення чергового елементу, поділене на максимум;

3. кінець циклу.

Рівень 2. Він включає три деталізовані вище частини, з яких тільки деталізація 1.2 вимагає додаткової уваги. Її можна деталізувати на псевдокоді таким чином:

1. покласти М, рівне першому елементу даних;

2. поки не всі елементи проглянуто;

3. якщо М < поточнийелемент, то M = поточний елемент;

4. кінець циклу.

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

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

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