Поняття модуля

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

Модульне програмування основане на понятті модуля – програми чи функціонально завершеного фрагменту програми.

Модуль характеризують:

– один вхід і один вихід. На вході програмний модуль отримує визначений набір початкових даних, виконує їх обробку і повертає один набір вихідних даних;

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

– логічна незалежність. Результат роботи даного фрагменту програми не залежить від роботи інших модулів;

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

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

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

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

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

Як розробити хороший модуль, який дійсно буде сприяти спрощенню програми?

У літературі наводяться різні критерії оцінки пригодності (приемлемости) модуля. Були запропоновані наступні критерії:

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

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

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

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

Надійність модуля – це міра його внутрішніх зв’язків. Чим вища надійність модуля, тим більше зв’язків скрито від зовнішньої по відношенню до нього частини програми і, відповідно, тим простіша сама програма. Самою слабкою ступінню надійності володіє модуль, надійний по співпаданню. У даному випадку в програмний модуль оформлюються послідовність операторів які повторюються в декількох місцях програми. Якщо виникне необхідність зміни цієї послідовності в одному з контекстів, прийдеться змінювати сам модуль, що може зробити його використання в інших контекстах помилковим. Такий клас програмних модулів не рекомендується для використання.

Функціонально надійний модуль – це модуль, який реалізує одну будь-яку визначену функцію. При цьому він може використовувати і інші модулі. Такий вид надійності модулів рекомендується для використання.

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

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

– даним;

– зразку;

– управлінню;

– зовнішнім зсилкам;

– загальної області даних;

– вмістимому.

Найгіршим видом зчеплення модулів є зчеплення по вмістимому. Таким є зчеплення двох модулів, коли один із них має прямі зсилки на вмістиме іншого модуля (наприклад, на константу, яка знаходиться в іншому модулі). Таке зчеплення модулів недопустиме.

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

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

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

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

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

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

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

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

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

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

Розрізняють наступні види зв’язності (в порядку зменшення рівня) [1]:

– функціональна;

– послідовна;

– інформаційна (комунікативна);

– процедурна;

– часова;

– логічна;

– випадкова.

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

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

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

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

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

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

Модуль, елементи якого мають випадкову зв’язність, має самі низькі показники технологічності, так як його елементи взагалі не зв’язані.

У табл. 3.1 наведені характеристики різних видів зв’язності по експертним оцінкам.

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

3.4.3. Модульна структура програмних модулів

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

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

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

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

2) прийняття основних рішень в алгоритмі виноситься на максимально високий по ієрархії рівень;

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

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

Наприклад, при розробці СУБД використовуються наступні програмні модулі:

1) екранні форми вводу і/чи редагування інформації бази даних;

2) звіти;

3) макроси;

4) стандартні засоби для обробки інформації;

5) меню для вибору функції обробки та ін.

3.4.4. Методи розробки при модульному програмуванні

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

Існують різні методи розробки модульної структури програми, в залежності від яких визначаються порядок програмування і налаштування модулів, вказаних в цій структурі. Зазвичай в літературі обговорюються два методи [42,46]: метод висхідної і метод низхідної розробки.

Метод висхідної розробки

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

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

– для висхідного тестування всіх модулів, крім головного, який є модулем самого верхнього рівня, приходиться створювати викликаючи програми, що призводить до створення великої кількості налаштовувального матеріалу, але не гарантує, що результати тестування вірні;

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

Метод низхідної розробки

Як і в попередньому методі, спочатку будується модульна структура програми у вигляді дерева. Потім проектуються і реалізуються модулі програми, починаючи з модуля самого верхнього рівня – головного, потім розробляються модулі рівнем нижче і т.д. При цьому перехід до програмування будь-якого модуля виконується тільки в тому випадку, якщо вже запрограмований модуль, який до нього звертається. Потім відбувається їх почергове тестування і налагодження в такому ж низхідному порядку. При такому порядку розробки програми всі необхідна глобальна інформація формується завчасно, тобто ліквідовується досить неприємне джерело прорахунків при програмуванні модулів. Суттєво полегшується і тестування модулів, яке проводиться при низхідному тестуванні програми. Першим тестується головний модуль програми, який представляє всю програму, при цьому всі модулі, до яких може звертатись головний, замінюються їх імітаторами (так названі «заглушки» [45]). Кожен імітатор модуля є простим програмним фрагментом, який реалізовує сам факт звернення до даного модуля з необхідною для правильної роботи програми обробки значень його вхідних параметрів і з виводом, якщо це необхідно, підходящого результату. Далі проводиться тестування наступних по рівню модулів. Для цього імітатор вибраного для тестування модуля замінюється самим модулем, і додаються імітатори модулів, до яких може звертатись модуль який тестується. При такому підході кожен модуль буде тестуватись в «природних» станах інформаційного середовища, які виникають до моменту звернення до цього модуля при виконанні програми. Таким чином, великий об’єм «налаштувального» програмування замінюється достатньо простих імітаторів, які використовуються в програмі модулів.

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

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

Конструктивний підхід

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

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

По такому ж принципу проводиться програмування наступних по рівню специфікованих, але ще не запрограмованих модулів у відповідності з сформованим деревом. В результаті до дерева додаються відповідні рівні, як показано на рис. 3.13.

Архітектурний підхід

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

Низхідна реалізація

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

Ціленаправлена конструктивна реалізація

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

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

3.5. Аналіз вимог і визначення специфікацій при структурному підході

На цьому етапі необхідно побудувати моделі ПЗ у взаємодії з навколишнім середовищем. Оскільки різні моделі описують програмне забезпечення з різних сторін, рекомендується використовувати одразу декілька моделей і супроводжувати їх описаннями. Структурний підхід до проектуванню програмних продуктів припускає розробку наступних моделей [1, 53]:

– діаграм потоків даних (DFD – Data Flow Diagrams), які описують взаємодію джерел і користувачів інформації через процеси, які повинні бути реалізовані в системі;

– діаграм «сутність–зв’язок» (ERD – Entity-Relationship Diagrams), які описують бази даних розроблюваної системи;

– діаграм переходів станів (STD – State Transition Diagrams), характеризують поведінку системи у часі;

– функціональних діаграм (методологія SADT);

– специфікацій процесів;

– словника термінів.

3.5.1. Специфікації процесів

Специфікації процесів можуть бути представлені у вигляді псевдокодів, блок-схем алгоритмів, Flow-форм, діаграм Насси-Шнейдермана чи просто короткого текстового описання [1].

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

Лінійна структура – виконання операторів послідовно.

Розгалужена структура – в залежності виконання деякої умови виконується та чи інша послідовність операторів.

Циклічна структура – багатократне виконання однакової послідовності операторів.

Для зображення схем алгоритмів розроблений ГОСТ 19.701–90 (табл. 3.2).

Будь-який, наскільки завгодно складний, алгоритм модна преставити з використанням трьох основних конструкцій, які отримали назву базових [1]:

– слідування. Означає послідовне виконання дій (рис. 3.15, а);

– розгалуження. Відповідає вибору одного з двох варіантів дій (рис. 3.15, б);

– цикл-поки. Визначає повторення дій, поки не буде порушена деяка умова, виконання якого перевіряється на початку циклу (рис. 3.15, в).

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

– вибір. Означає вибір одного варіанту із багатьох в залежності від значень деякої величини (рис. 3.16, а);

– цикл-до. Означає повторення деяких дій до виконання заданої умови, перевірка якого здійснюється після виконання дій в циклі (рис. 3.16, б);

– цикл із заданим числом повторень (цикл з лічильником). Означає повторення деяких дій вказану кількість разів (рис. 3.16, в).

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

Дата добавления: 2014-01-04