3.4.3. Модульна структура програмних модулів
Модульна структура програми представляє собою деревовидну структуру, у вузлах якої розміщуються програмні модулі, а направлені дуги показують статичну підлеглість модулів. Якщо в тексті модуля є зсилка на інший модуль, то їх на структурній схемі з’єднує дуга, яка виходить з першого і входить в другий модуль. Іншими словами, кожен модуль може звертатись до підлеглих йому модулів. При цьому модульна структура програмної системи, крім структурної схеми, повинна включати в себе ще і сукупність специфікацій модулів, які створюють цю систему.
Функція верхнього рівня забезпечується головним модулем; він управляє виконанням нижчестоячих функцій, яким відповідають підлеглі модулі.
При визначенні набору модулів, які реалізують функції конкретного алгоритму, необхідно враховувати наступне:
модуль викликається на виконання вищестоячим по ієрархії модулем і, завершивши роботу, повертає йому управління;
прийняття основних рішень в алгоритмі виноситься на максимально високий по ієрархії рівень;
якщо в різних містах алгоритму використовується одна і та ж функція, то вона оформлюється в окремий модуль, який буде викликатись по мірі необхідності.
Склад, призначення і характер використання програмних модулів в значній мірі визначається інструментальними засобами.
Наприклад, при розробці СУБД використовуються наступні програмні модулі:
екранні форми вводу і/чи редагування інформації бази даних;
звіти;
макроси;
стандартні засоби для обробки інформації;
меню для вибору функції обробки та ін.
3.4.4. Методи розробки при модульному програмуванні
Специфікація програмного модуля складається із функціональної специфікації модуля, яка описує семантику функцій, що виконуються цим модулем по кожному з його входів, і синтаксичної специфікації його входів, яка дозволяє побудувати мовою програмування синтаксично правильне звернення до нього. Функціональна специфікація модуля визначається тими ж принципами, що й функціональна специфікація програмної системи.
Існують різні методи розробки модульної структури програми, в залежності від яких визначаються порядок програмування і налаштування модулів, вказаних в цій структурі. Зазвичай в літературі обговорюються два методи [42,46]: метод висхідної і метод низхідної розробки.
Метод висхідної розробки
Спочатку будується деревовидна модульна структура програми. Потім почергово проектуються і розробляються модулі програми, починаючи з модулів самого нижнього рівня, потім попереднього рівня і т.д. Тобто модулі реалізуються в такому порядку, щоб для кожного програмного модуля були вже запрограмовані всі модулі, до яких він може звертатись. Після того як всі модулі програми запрограмовані, проводиться їх почергове тестування і налаштування в такому ж висхідному порядку. Переваги методу полягають в тому, що кожний модуль при програмуванні виражається через вже запрограмовані безпосередньо підлеглі модулі, а при тестуванні використовують вже налаштовані модулі. Недоліки методу висхідної розробки полягають в наступному:
на нижніх рівнях модульної структури специфікації можуть бути ще визначені не повністю, що може привести до повної переробки цих модулів після уточнення специфікацій на верхньому рівні;
для висхідного тестування всіх модулів, крім головного, який є модулем самого верхнього рівня, приходиться створювати викликаючи програми, що призводить до створення великої кількості налаштовувального матеріалу, але не гарантує, що результати тестування вірні;
головний модуль проектується і реалізується в останню чергу, що не дає продемонструвати його замовнику для уточнення специфікацій.
Метод низхідної розробки
Як і в попередньому методі, спочатку будується модульна структура програми у вигляді дерева. Потім проектуються і реалізуються модулі програми, починаючи з модуля самого верхнього рівня – головного, потім розробляються модулі рівнем нижче і т.д. При цьому перехід до програмування будь-якого модуля виконується тільки в тому випадку, якщо вже запрограмований модуль, який до нього звертається. Потім відбувається їх почергове тестування і налагодження в такому ж низхідному порядку. При такому порядку розробки програми всі необхідна глобальна інформація формується завчасно, тобто ліквідовується досить неприємне джерело прорахунків при програмуванні модулів. Суттєво полегшується і тестування модулів, яке проводиться при низхідному тестуванні програми. Першим тестується головний модуль програми, який представляє всю програму, при цьому всі модулі, до яких може звертатись головний, замінюються їх імітаторами (так названі «заглушки» [45]). Кожен імітатор модуля є простим програмним фрагментом, який реалізовує сам факт звернення до даного модуля з необхідною для правильної роботи програми обробки значень його вхідних параметрів і з виводом, якщо це необхідно, підходящого результату. Далі проводиться тестування наступних по рівню модулів. Для цього імітатор вибраного для тестування модуля замінюється самим модулем, і додаються імітатори модулів, до яких може звертатись модуль який тестується. При такому підході кожен модуль буде тестуватись в «природних» станах інформаційного середовища, які виникають до моменту звернення до цього модуля при виконанні програми. Таким чином, великий об’єм «налаштувального» програмування замінюється достатньо простих імітаторів, які використовуються в програмі модулів.
Недоліком низхідного підходу до програмування є необхідність абстрагуватись від реальних можливостей вибраної мови програмування і придумувати абстрактні операції, які пізніше будуть реалізовані з допомогою модулів. Однак здатність до таких абстракцій є необхідною умовою розробки великих програмних засобів.
Розглянуті вище методи (висхідної і низхідної розробок), які є класичними, вимагають, щоб модульна деревовидна структура була готова до початку програмування модулів. Як правило, точно і змістовно розробити структуру програми до початку програмування неможливо. При конструктивному і архітектурному підходах до розробки модульна структура формується в процесі реалізації модулів.
Конструктивний підхід
Конструктивний підхід до розробки програми представляє собою модифікацію низхідної розробки, при якій модульна деревовидна структура програми формується в процесі програмування модуля. Спочатку програмується головний модуль, виходячи із специфікації програми в цілому (специфікація програми є одночасно специфікацією головного модуля). В процесі програмування головного модуля у випадку, якщо ця програма достатньо велика, виділяються підзадачі (деякі функції) і для них створюються специфікації які реалізовують ці підзадачі фрагментів програми. В подальшому кожен з цих фрагментів буде представлений піддеревом модулів (специфікація виділеної функції є одночасно специфікацією головного модуля цього піддерева).
Таким чином, на першому кроці розробки програми (при програмуванні його головного модуля) формується верхня частина дерева, наприклад, як на рис. 3.12.
По такому ж принципу проводиться програмування наступних по рівню специфікованих, але ще не запрограмованих модулів у відповідності з сформованим деревом. В результаті до дерева додаються відповідні рівні, як показано на рис. 3.13.
Архітектурний підхід
Архітектурний підхід до розробки програми представляє собою модифікацію висхідної розробки, при якій модульна структура програми формується в процесі програмування модуля. Ціллю розробки в даному методі є підвищення рівня мови програмування, а не розробка конкретної програми. Це означає, що для заданої предметної області виділяються типові функції, специфікуються, а потім і програмуються окремі програмні модулі, які виконують ці функції. Спочатку у вигляді модулів реалізовуються більш прості функції, а потім створюються модулі, які використовують вже існуючі функції, і т.д. Це дозволяє суттєво скоротити трудозатрати на розробку конкретної приграми шляхом підключення до неї вже існуючих і перевірених на практиці модульних структур нижнього рівня, що також дозволяє боротися з дублюванням в програмуванні. У зв’язку з цим програмні модулі, які створюються в рамках архітектурного підходу, зазвичай параметризуються для того, щоб полегшити їх використання настройкою параметрів.
Низхідна реалізація
В класичному методі низхідної розробки спочатку всі модулі програми програмуються, а потім тестуються в низхідному порядку. При цьому тестування і налаштування модулів можуть привести до зміни специфікації підлеглих модулів і навіть до зміни самої модульної структури програми. В результаті може виявитись, що частина модулів взагалі непотрібна в даній структурі, а частина модулів прийдеться переписувати. Більш раціонально кожен запрограмований модуль тестувати одразу ж до переходу до програмування наступного модуля. Такий метод в літературі отримав назву метод низхідної реалізації.
