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

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

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

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

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

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

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

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

Майерс пропонує для оцінки прийнятності програмного модуля використовувати більш конструктивні його характеристики:

· розмір модуля,

· міцність модуля,

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

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

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

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

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

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

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

Зчеплення модуля - це міра його залежності за даними від інших модулів. Характеризується способом передачі даних. Чим слабкіше зчеплення модуля з іншими модулями, тим сильніше його незалежність від інших модулів. Для оцінки ступеня зчеплення Майерс пропонує упорядкований набір з шести видів зчеплення модулів. Гіршим видом зчеплення модулів є зчеплення по вмісту. Таким є зчеплення двох модулів, коли один з них має прямі посилання на вміст іншого модуля (наприклад, на константу, що міститься в іншому модулі). Таке зчеплення модулів недопустимо. Не рекомендується використовувати також зчеплення по загальній області - це таке зчеплення модулів, коли кілька модулів використовують одну і ту ж область пам'яті. Такий вид зчеплення модулів реалізується, наприклад, при програмуванні на мові ФОРТРАН з використанням блоків COMMON. Єдиним видом зчеплення модулів, який рекомендується для використання сучасною технологією програмування, є параметричне зчеплення (зчеплення за даними) - це випадок, коли дані передаються модулю або при звертанні до нього як значення його параметрів, або як результат його звертання до іншого модуля для обчислення деякої функції. Такий вид зчеплення модулів реалізується на мовах програмування при використанні звертань до процедур (функцій).

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

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

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

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

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