Использование декомпозиции при проектировании больших программных систем. Декомпозиция при алгоритмическом подходе. Декомпозиция при объектно-ориентированном подходе

Декомпозиция – это разложение на более мелкие составные части.

Алгоритмическая декомпозиция:

Один управляющий алгоритм, который вызывает всё остальное. Иерархическое управление сверху вниз. Каждый модуль имеет только одну связь наверх.

· Нисходящее проектирование - этот алгоритм предпочтителен, когда в самом начале мы не проектируем модули, а проектируем управляющий алгоритм.

· Восходящее проектирование - худший метод, хотя и чаще встречающийся. Сначала создаются модули, а потом объединяющий их главный управляющий алгоритм.

· Комбинированное проектирование - сочетание нисходящего и восходящего.

Объектная декомпозиция:

7. Требования к программным модулям при проведении декомпозиции.

1. Проблемы модулей

· модули выполняют слишком много связанных, но различных функций;

· при проектирования остались невыявленными общие функции, вследствие чего они рассредоточены и по-разному реализованы в разных модулях;

· модули взаимодействуют посредством совместно используемых или общих данных самым неожиданным образом.

2. Структурное проектирование модуля

Необходимо всегда делать так, чтобы была одна точка входа в модуль и одна точка выхода из него. Варианты:

· линейная структура;

· ветвление из входной точки ветвями в итоге в одну выходную;

· цикл - по кругу внутри можно ходить сколько угодно, но выход из цикла только в одну выходную точку модуля.

3. Характеристики модуля

Чем характеризуется модуль при попытках его изменения, отладке и поиске ошибок:

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

· информационная прочность - когда данные, используемые модулем, находятся внутри самого же модуля, внешние переменные не используются;

· сцепление по данным - передача данных из модуля в модуль должна быть управляемой. А лучше вообще не передавать данные от модуля к модулю;

· сцепление по общей области - избегать его всеми силами;

· сцепление по по управлению;

· сцепление по формату;

· сцепление по содержимому - по общим константам;

· размер модуля - исключительно для удобства человека, чтобы модуль был обозримым.

4. Хороший программный модуль

Ø Сложность взаимодействия модуля с другими модулями должна быть меньше сложности его внутренней структуры

Ø Хороший модуль снаружи проще, чем внутри

Ø Хороший модуль проще использовать, чем построить