Главная страница / 29. Структурное программирование: 29.3. Модульное программи...
29.3. Модульное программирование
| ← 29.2. Структурные методы анализа и... | 29.4. Базовые управляющие структуры... → |
Навигация по разделу
- 29.3.1. HIPO-диаграмма
- 29.3.2. Метод нисходящего проектирования
- 29.3.3. Метод расширения ядра
- 29.3.4. Метод восходящего проектирования
Прикладные программы чаще всего слишком сложны, чтобы быть написанными как единое целое или разработанными одним программистом. Поэтому большие программы на этапе проектирования разбивают на логические (функциональные) модули.
Под модульным программированием (модуляризацией) понимается разделение программы на части по некоторым установленным правилам.
Эти части на этапе кодирования реализуются в виде модулей или подпрограмм в зависимости от их размера и выбранного языка программирования.
Для того чтобы логический модуль можно было закодировать, необходимо предварительно описать его поведение, т.е. специфицировать. Для спецификации функций логических модулей с точки зрения входных и выходных данных и связи между ними используют HIPO-диаграмму (от англ. hierarchy-input-processing-output – иерархическое описание вход-обработка-выход) [20].
Программы разбиваются на модули, чтобы:
- упростить их разработку и реализацию;
- облегчить чтение программ;
- упростить их настройку и модификацию;
- облегчить работу с данными, имеющими сложную структуру;
- избежать чрезмерной детализации алгоритмов;
- обеспечить более выгодное размещение программ в памяти ЭВМ.
Правильная декомпозиция – это главный способ преодоления сложности разработки больших систем ПО. Понятие «правильная» по отношению к декомпозиции означает следующее:
- количество связей между отдельными модулями должно быть минимальным (принцип «слабой связанности» - Low Coupling);
- связность отдельных частей внутри каждого модуля должна быть максимальной (принцип «сильного сцепления» — High Cohesion).
Связность модуля определяется как мера зависимости его частей.
Чем выше связность модуля, тем лучше результат проектирования. Для обозначения связности используется также понятие силы связности модуля.
Сцепление модулей представляет собой меру относительной независимости модулей, которая определяет их читабельность и сохранность.
Независимые модули могут быть модифицированы без переделки каких-либо других модулей. Слабое сцепление более желательно, так как это означает высокий уровень их независимости. Модули считаются полностью независимыми, если каждый из них не содержит о другом никакой информации. Чем больше информации о других модулях используется в них, тем менее они независимы и тем теснее сцеплены.
Методы проектирования программ, основанные на модульном принципе, делятся на три группы:
- методы нисходящего проектирования;
- методы расширения ядра;
- методы восходящего проектирования.
На практике обычно применяются различные сочетания этих методов.
Рассмотрим применение функциональной декомпозиции на следующем примере.
Пусть необходимо разработать консольное приложение для представления десятичного действительного числа в систему счисления с основанием р (основание может меняться в диапазоне от 2 до 16).
Проектирование программы начинаем с функциональной декомпозиции задачи и построения на ее основе схемы иерархии логических модулей. Схема иерархии логических модулей – это результат отображения разбиения исходной задачи на части на уровне проекта. Каждый логический модуль преобразует некоторые входные данные в определенный результат и может быть снова разделен на части. Схема иерархии логических модулей отображает связь модулей по управлению, т.е. на ней с помощью прямых линий показано, какие модули могут быть вызваны из данного модуля. Результатом разбиения нашей задачи на части может быть схема иерархии (рис. 29.1).
Рис. 29.1. Схема иерархии логических модулей.
29.3.1. HIPO-диаграмма
HIPO-диаграмма предназначена для спецификации (описания) требований к программе или функциональному (логическому) модулю.
Она является результатом анализа процесса обработки данных, выполняемого программой (или модулем), с точки зрения исходных данных и результатов работы программы.
HIPO-диаграмма имеет следующий вид:
В разделе «Вход» перечисляются имена входных данных, их типы, диапазоны возможных значений.
В разделе «Выход» перечисляются имена выходных данных, их типы, диапазоны возможных значений.
В разделе «Обработка» для каждого выхода необходимо указать, с какими входами он связана и как. В этом подразделе содержится описание того, что делает программа, а не того, как она это делает.
Таким образом, HIPO-диаграмма – это описание поведения процесса обработки данных в таких существенных признаках, как входные значения, выходные значения и связь между ними.
Рассмотрим построение HIPO-диаграммы для модуля «1. 1. Перевод десятичного целого в р-ичное целое» с рис. 29.1.
| 1. 1. Модуль Перевод 10-ичного целого в р-ичное целое, представленное строкой Ip | ||
|---|---|---|
| Вход | Обработка | Выход |
| Ip – строка, p – целое значение |
I – десятичный эквивалент р-ичной
строки Ip – строки, содержащей p- ичное представление числа. р – основание системы счисления в диапазоне 2...16. |
I – целое число |
29.3.2. Метод нисходящего проектирования
Метод нисходящего проектирования подобен методу получения детального изображения из более общего вида с помощью телескопического увеличения. На начальном шаге формируется предложение, описывающее функцию всей программы. Затем определяются ее подфункции. Эта процедура является рекурсивной, т. е., следуя ей, каждая из подфункций может расчленяться до тех пор, пока ее составные части не будут окончательно уточнены. Метод нисходящего проектирования, иногда называемый функциональной декомпозицией, основан на двух стратегиях: пошаговом уточнении, разработанном Эдсгером Дейкстрой, и анализе сообщений, базирующемся на работах Э. Йодана, Константайна Л. и Мейерса Г. Эти стратегии различаются способами определения начальных спецификаций, методами, используемыми при разбиении задачи на части, и правилами записи [20].
29.3.3. Метод расширения ядра
Метод расширения ядра отличается от способа нисходящего проектирования: в нем больше внимания вначале уделяется выявлению множества вспомогательных функций, а не определению функции всей программы в целом. Эти функции можно получить, применяя методы проектирования структур данных, которые используются при иерархическом модульном проектировании, разработанном М. Джексоном, или определяя области хранения данных с последующим анализом связанных с ними функциональных единиц (как в методе определения спецификаций модуля, разработанном Д. Парнасом) [20].
29.3.4. Метод восходящего проектирования
При использовании метода восходящего проектирования в первую очередь определяются вспомогательные функции, которые могут потребоваться для проектируемой программы. Модульная декомпозиция заключается в нахождении ключевых модулей промежуточных уровней, которые затем разрабатываются восходящим и нисходящим способами одновременно. Эти модули не являются вспомогательными в том смысле, что потребность в них возникает в нескольких точках программы. Необходимость в использовании этих модулей может возникать в других программах или системах.
Функции, определяемые как вспомогательные при восходящем проектировании, реализуются с помощью модулей самых нижних уровней [20].
| ← 29.2. Структурные методы анализа и... | 29.4. Базовые управляющие структуры... → |