Мета модульного програмування

Приступаючи до розробки кожної програми, слід мати на увазі, що вона, як правило, є великою системою, тому треба вжити заходів для її спрощення. Для цього таку програму розробляють вроздріб, які називаються програмними модулями [1, 2]. А сам такий метод розробки програм називають модульним програмуванням [3]. Програмний модуль - це будь-який фрагмент опису процесу, що оформляється як самостійний програмний продукт, придатний для використання в описах процесу. Це означає, що кожен програмний модуль програмується, компілюється та налагоджували окремо від інших модулів програми, і тим самим, фізично розділений з іншими модулями програми. Більш того, кожен розроблений програмний модуль може включатися до складу різних програм, якщо виконані умови його використання, декларовані в документації з цього модулю. Таким чином, програмний модуль може розглядатися і як засіб боротьби зі складністю програм, і як засіб боротьби з дублюванням в програмуванні (тобто як засіб накопичення та багаторазового використання програмістських знань).

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

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

Не всякий програмний модуль сприяє спрощенню програми [2]. Виділити хороший з цієї точки зору модуль є серйозною творчим завданням. Для оцінки прийнятності виділеного модуля використовуються деякі критерії. Так, Хольт [4] запропонував наступні два загальних таких критерії:

хороший модуль зовні простіше, ніж усередині;

хороший модуль простіше використовувати, ніж побудувати.

зчеплення з іншими модулями;

рутинність модуля (незалежність від передісторії звертань до нього).

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

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

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

У модульних мовах програмування як мінімум є засоби для завдання функціонально міцних модулів (наприклад, модуль типу FUNCTION в мові ФОРТРАН). А кошти для завдання інформаційно міцних модулів в ранніх мовах програмування були відсутні. Ці кошти з'явилися тільки в більш пізніх мовами. Так в мові програмування Ада засобом завдання інформаційно міцного модуля є пакет [6].

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

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

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