ВУЗ:
Составители:
Рубрика:
программирования как методологию понимания сложных проблем [13]. Обилие
“технических” трудностей в программировании возникает всякий раз при решении
конкретных практических задач, которые по Б.Мейеру связаны одновременно с
ограничениями, внутренне присущими человеческому уму, и с общей проблемой
передачи идей и разделения труда. Основной задачей методологии программирования
является сведение при помощи систематической декомпозиции
задач очень большой
сложности к комбинации простых задач, чтобы при этом синтез решений было легко
реализовать. Для того чтобы построить программу, необходима стратегия декомпозиции.
Однако остается уточнить, каким должен быть основной элемент в построении
программы, т.е. единица декомпозиции.
Наиболее простой классический ответ заключается в том, чтобы рассматривать
элемент программы, определенный
своими входами и выходами, т.е. подпрограмму.
Подобная концепция вводит понятие
модуля.
В литературе до сих пор не сложилось окончательное определение понятия модуля.
Однако отчетливо выделяются два подхода к интерпретации этого понятия.
Первое - определяет модуль как замкнутую программную единицу с набором
инициирующих входов и указателей выходов, которую можно вызывать из любого
другого модуля программы и отдельно компилировать.
Второе представление связывает понятие модуля
с данными, которыми он
оперирует. Данный подход во многом обусловлен решением сложной проблемы
распределения ответственности: какой программный модуль должен обеспечивать
управление набором данных, используемых многими программными единицами? Эта
проблема приводит к стратегии декомпозиции, основанной на понятии
модуль данных в
большей степени, чем на понятии
программный модуль [20]. С этих позиций модуль есть
структура данных, доступная извне при помощи некоторого набора программ (методов),
и только при их помощи.
В этом случае модуль превращается в активный элемент (объект), обладающий
всем множеством операций (методов) своего класса, а составление программы
происходит в терминах взаимодействующих объектов, где активные элементы именно
объекты, а не использующие их процессы. Таким образом, речь
идет о необходимости
считать программу не совокупностью процессов, обрабатывающих данные, а
совокупностью активных “машин”, взаимодействующих между собой [34]. На практике
это направление получило распространение в так называемых объектно-
ориентированных языках программирования.
В ГСП отмечают два аспекта, объединяющие разные трактовки модуля: выделение
в обособленную самостоятельную единицу каких-то действий, функций и данных;
выделение
в самом модуле его внешности (интерфейса) - той части, посредством которой
модуль связан с внешним миром (другими модулями, операционной средой и т.п.).
Будем понимать под
модулем независимую программную единицу, реализующую
определенную функцию в процессе преобразования некоторого агрегата данных.
Довольно часто по разным причинам ограничивают размеры модуля, например, по
соображениям удобства редактирования и наглядности или из соображений сокращения
времени трансляции и т.д. В технологии ГСП размеры базовых модулей ограничены
соображениями возможности проведения полного цикла тестовых испытаний.
Однако для ГСП наиболее существенным является свойство независимости
(ортогональности) базовых моделей [26]. Ортогональность
подразумевает однозначное,
исключающее дублирование, распределение функций между модулем и остальной
программой. Для строгого определения ортогональности двух модулей
B
i
и B
j
требуется
Страницы
- « первая
- ‹ предыдущая
- …
- 10
- 11
- 12
- 13
- 14
- …
- следующая ›
- последняя »
