Тема 5 Структурный подход к разработке ПО

1. Структурный подход к разработке программного обеспечения

1
Тема 5
Структурный подход к
разработке программного
обеспечения

2.

Содержание
1. «Хаотическое» и структурное программирование
2. Принципы структурного проектирования
3. Типовая структура программного комплекса
4. Сцепление и связность модулей программного
средства
5. Восходящее и нисходящее проектирование ПО
2

3.

3
1. «Хаотическое»
и структурное программирование

4.

“Хаотическое” программирование
Для начального периода развития технологии
программирования, когда программы были штучным
продуктом, характерен стиль программирования,
который впоследствии получил название
“хаотическое” программирование.
Суть его состоит в том, чтобы из операторов языка
программирования сконструировать программу,
выполняющую некоторое (заданное) преобразование
данных.
Ни набор операторов, ни порядок их применения
никак не регламентировался.
В общем случае для такого программирования, чем
больше операторов в языке программирования, тем
лучше.
4

5.

“Хаотическое” программирование
Главный недостаток разработанного таким образом ПО –
большие трудности его сопровождения.
Программы, написанные без регламентации
применения операторов языка программирования,
имеют структуру “итальянского спагетти” из-за
частого применения в таких программах оператора
перехода goto.
Как правило, в таких программах может разобраться
только автор.
Они плохо пригодны для тиражирования и
превращения в товар.
5

6.

“Хаотическое” программирование
В конце 60-х начале 70-х годов в сфере ПО обозначились
трудности, порожденные расширением области
применения компьютеров.
Возросшая мощность вычислительной техники
и появление языков высокого уровня
позволили приступить к автоматизации процессов,
с которыми люди перестали справляться или
к которым еще не приступали из-за их высокой
вычислительной сложности.
Примерами таких задач могут служить
автоматизированные системы управления
безопасностью полетов
или управления движением по железнодорожным
магистралям.
6

7.

“Хаотическое” программирование
Такие системы разрабатывались в течение месяцев и
лет.
Стоимость ПО доходила до 80% всех затрат.
Однако обеспечить требуемый уровень их надежности
не всегда удавалось.
7

8.

“Хаотическое” программирование
Знаменательной датой в истории программирования стал
1968 год.
Тогда создавшееся в программировании положение
обсуждалось на международной конференции,
получившей название “Кризис программного
обеспечения”.
В этом году Чарльз Хоар и Николаус Вирт впервые
указали на необходимость придания языку
программирования свойств, которые превратили бы
его в “инструмент надежного создания сложных
программ”. Однако настоять на этом им не удалось.
8

9.

Структурное программирование
Несколько позже автор структурного программирования
голландский ученый Дейкстра выпустил работу под
названием “Заметки по структурному
программированию”, в которой доказывал, что
большинство программ сложны и неуправляемы из-за
отсутствия в них четкой математической структуры.
Интуитивному и бессознательному (“хаотическому”)
программированию он последовательно
противопоставлял логически строгую методологию,
предполагавшую ко всему прочему личную
дисциплинированность и ответственность
программиста.
Одним из его кардинальных предложений было
признание оператора перехода goto недопустимым
в программировании.
9

10.

Структурное программирование
Сначала это предложение смутило и удивило почти всех
программистов, но затем они убедились в том, что
доводы Дейкстры весьма основательны.
Способствовало этому то обстоятельство, что Якопини и
Ципнер доказали теорему о том, что теоретически
любую программу можно написать без goto.
Чтобы изложить эту историю о революции в
программировании до конца, следует упомянуть, что в
1974 году на защиту оператора goto выступил
американец Д.Кнут и показал, что в некоторых случаях
использование этого оператора желательно.
10

11.

11
2. Принципы структурного
проектирования

12.

Разделяй и властвуй
12
Проблема сложности является главной проблемой,
которую приходится решать при создании больших и
сложных систем любой природы.
Ни один разработчик не в состоянии выйти за
пределы человеческих возможностей и понять всю
систему в целом.
Единственный эффективный подход к решению этой
проблемы, который выработало человечество за всю
свою историю, заключается
в построении сложной системы из небольшого
количества крупных частей,
каждая из которых, в свою очередь, строится из
частей меньшего размера
и т.д., до тех пор, пока самые небольшие части
можно будет строить из имеющегося материала.

13.

Разделяй и властвуй
13
Этот подход известен под самыми разными названиями,
среди них такие, как
разделяй и властвуй,
иерархическая декомпозиция и др.
По отношению к проектированию сложной программной
системы это означает:
ее необходимо разделять (декомпозировать) на
небольшие подсистемы, каждую из которых можно
разрабатывать независимо от других.
Это позволяет при разработке подсистемы любого уровня
держать в уме информацию только о ней, а не обо всех
остальных частях системы.

14.

Разделяй и властвуй
14
Правильная декомпозиция является главным способом
преодоления сложности разработки больших систем
ПО.
Понятие правильная по отношению к декомпозиции
означает следующее:
количество связей между отдельными подсистемами
должно быть минимальным;
связность отдельных частей внутри каждой
подсистемы должна быть максимальной.

15.

Разделяй и властвуй
15
Структура системы должна быть таковой, чтобы все
взаимодействия между ее подсистемами укладывались
в ограниченные, стандартные рамки:
каждая подсистема должна инкапсулировать свое
содержимое (скрывать его от других подсистем);
каждая подсистема должна иметь четко
определенный интерфейс с другими подсистемами.
Инкапсуляция позволяет рассматривать структуру каждой
подсистемы независимо от других подсистем.
Интерфейсы позволяют строить систему более высокого
уровня, рассматривая каждую подсистему как единое
целое и игнорируя ее внутреннее устройство.

16.

Подходы к разработке ПО
16
На сегодняшний день в программной инженерии
существуют два основных подхода к разработке ПО
АИС, принципиальное различие между которыми
обусловлено разными способами декомпозиции систем.

17.

Подходы к разработке ПО
17
Первый подход называют функциональномодульным или структурным.
В его основу положен принцип функциональной
декомпозиции, при которой структура системы
описывается в терминах иерархии ее функций и
передачи информации между отдельными
функциональными элементами.
II. Второй, объектно-ориентированный подход,
использует объектную декомпозицию.
При этом структура системы описывается в терминах
объектов и связей между ними,
а поведение системы описывается в терминах
обмена сообщениями между объектами.
I.

18.

Подходы к разработке ПО
В рамках данной лекции и нескольких последующих подробно
познакомимся со структурным подходом к разработке ПО.
Объектно-ориентированный подход подробно будет рассмотрен в
последующих лекциях.
18

19.

Сущность структурного подхода
19
Таким образом, структурный подход основан на
разделении большой системы на части («черные
ящики», подсистемы) и иерархической организации
этих частей.
Разбиение должно удовлетворять следующим критериям:
каждая подсистема должна реализовывать
единственную функцию системы;
функция каждой подсистемы должна быть легко
понимаема независимо от сложности ее реализации;
связь между подсистемами должна вводиться только
при наличии связи между соответствующими
функциями системы;
связи между подсистемами должны быть простыми,
настолько насколько это возможно, для обеспечения
независимости между ними.

20.

Сущность структурного подхода
Следовательно, сущность структурного подхода к
разработке ПО заключается
в декомпозиции (разбиении) системы на
функциональные подсистемы,
которые, в свою очередь, делятся на подфункции,
те – на задачи
и так далее до конкретных процедур.
20

21.

Принципы структурного подхода
21
Все наиболее распространенные методы структурного
подхода базируются на ряде общих принципов.
Базовыми принципами являются:
принцип «разделяй и властвуй» – принцип
решения трудных проблем путем разбиения их на
множество меньших независимых задач, легких для
понимания и решения;
принцип иерархического упорядочения – принцип
организации составных частей системы в
иерархические древовидные структуры с
добавлением новых деталей на каждом уровне.

22.

Принципы структурного подхода
22
Выделение двух базовых принципов не означает, что
остальные принципы являются второстепенными,
поскольку игнорирование любого из них может привести
к непредсказуемым последствиям (в том числе и к
провалу всего проекта).
Основными из этих принципов являются:
принцип абстрагирования – выделение
существенных аспектов системы и отвлечение от
несущественных;
принцип непротиворечивости – обоснованность
и согласованность элементов системы;
принцип структурирования данных – данные
должны быть структурированы и иерархически
организованы.

23.

Модели структурного подхода
В структурном подходе к проектированию ПО
используются различные модели, описывающие:
функциональную структуру системы;
последовательность выполняемых действий;
передачу информации между функциональными
процессами;
отношения между данными
Наиболее распространенными моделями являются:
функциональная модель (SADT, IDEF0);
моделирование процессов IDEF3;
диаграммы потоков данных (DFD);
диаграммы переходов состояний (STD);
информационно-логические модели «сущностьсвязь» (ERD);
диаграммы структуры программного приложения
(SSD).
23

24.

Модели структурного подхода
24
Конкретный вид перечисленных диаграмм и интерпретация
их конструкций зависят от стадии ЖЦ ПО.
Данные модели могут дополняться диаграммами,
отражающими
системную архитектуру ПО,
структурные схемы программ,
иерархию экранных форм и меню и др.
Перечисленные модели в совокупности дают полное
описание ПО независимо от того, является ли система
существующей
или вновь разрабатываемой.
Состав диаграмм в каждом конкретном случае зависит от
сложности системы
и необходимой полноты ее описания.

25.

25
3. Типовая структура программного
комплекса

26.

Модуль
В большей степени программные продукты не являются
монолитом и имеют определенную конструкцию
(архитектуру) построения, т.е. состав программных
модулей и их взаимосвязь.
Модуль – это самостоятельная часть программы,
имеющая определенное назначение
и обеспечивающая заданные функции обработки
автономно от других программных модулей.
Таким образом, программный продукт обладает
внутренней организацией, или же внутренней
структурой, образованной взаимосвязанными
программными модулями.
Это справедливо для сложных и многофункциональных
программных продуктов, которые часто называются
программными системами.
26

27.

Структуризация программных продуктов
Структуризация программ выполняется в первую очередь
для удобства
разработки,
программирования,
отладки
и внесения изменений в программный продукт.
Как правило, программные комплексы большой
алгоритмической сложности разрабатываются
коллективом разработчиков (2-15 и более человек).
Управлять разработкой программ в условиях применения
промышленных технологий изготовления программ
можно лишь на научной основе.
27

28.

Структуризация программных продуктов
28
Таким образом, структуризация ПС преследует
основные цели:
распределить работы по исполнителям, обеспечив
приемлемую их загрузку
и требуемые сроки разработки программных
продуктов;
построить календарные графики проектных работ и
осуществлять их координацию в процессе создания
программных изделий;
контролировать трудозатраты и стоимость проектных
работ и др.

29.

Структуризация программных продуктов
29
Структурное «разбиение» программ на отдельные
составляющие служит основой
для выбора инструментальных средств их создания,
хотя имеет место и обратное влияние – выбор
инструментальных средств разработчика ПО
определяет типы программных модулей.

30.

Модульность
30
Два типа моделей декомпозиции подсистем на модули:
модель потока данных;
модель объектов.
Модуль – фрагмент программного текста, являющийся
строительным блоком для физической структуры
системы.
Модульность – свойство системы, которая может
подвергаться
декомпозиции
на ряд
внутренне
связанных и слабо зависящих друг от друга модулей.

31.

Модульность
31
Пусть
C(x) – функция сложности решения проблемы,
T(x) – функция затрат времени на решение проблемы.
Для двух проблем p1 и p2 из соотношения
C(p1) > C(p2)
следует, что
T(p1) > T(p2).
Из практики решения проблем человеком следует:
C(p1+p2) > C(p1) + C(p2).
Учитывая ранее сказанное:
T(p1+p2) > T(p1) + T(p2).
Это и есть принцип «разделяй и властвуй».

32.

32
Стоимость
Модульность
Общая стоимость
Стоимость
интерфейса
Стоимость модуля
Область
минимальной
стоимости
Количество
модулей

33.

Модульность
Оптимальный модуль должен удовлетворять двум
критериям:
снаружи он проще чем внутри,
его проще использовать, чем построить.
33

34.

Виды модулей
34
При создании программных продуктов:
выделяются многократно используемые модули,
проводится их типизация и унификация, за счет чего
сокращаются сроки и трудозатраты на разработку
программного продукта в целом.
Некоторые программные продукты используют модули из
готовых библиотек
стандартных подпрограмм,
процедур,
функций,
объектов,
методов обработки данных.

35.

Виды модулей
Ниже на рисунке приведена типовая структура
программного продукта, состоящего из отдельных
программных модулей и библиотек процедур,
встроенных функций, объектов и т.п.
35

36.

Виды модулей
36
Среди множества модулей различают:
головной модуль – управляет запуском
программного продукта (существует в единственном
числе);
управляющий модуль – обеспечивает вызов других
модулей на обработку;
рабочие модули – выполняют функции обработки;
сервисные модули и библиотеки, утилиты –
осуществляют обслуживающие функции.
В работе ПС активизируются необходимые программные
модули.
Управляющие модули задают последовательность вызова
на выполнение очередною модуля.
Информационная связь модулей обеспечивается за счет
использования общей базы данных либо межмодульной
передачи данных через переменные обмена.

37.

Виды модулей
Каждый модуль может оформляться как самостоятельно
хранимый файл.
Для функционирования ПС необходимо наличие
программных модулей в полном составе.
37

38.

ППП
38
Структурно-сложные программные продукты
разрабатываются как пакеты программ, и чаще всего
они имеют прикладной характер – пакеты прикладных
программ, или ППП.
ППП – это система программ, предназначенных для
решения задач определенного класса.
Компоненты ППП обладают свойствами:
объединены общими данными (базой данных),
информационно и функционально связаны между
собой
и обладают свойством системности, т.е.
объединению программ присуще новое качество,
которое отсутствует для отдельного компонента ППП.
Структура ППП, как правило, многомодульная.

39.

39
4. Сцепление и связность модулей
программного средства

40.

40
Один из фундаментальных принципов структурного
проектирования заключается в том, что
большая система должна быть расчленена на
обозримые модули.
При этом существенным является то, что это расчленение
должно быть выполнено таким образом,
чтобы модули были как можно более независимы
(критерий сцепления),
и чтобы каждый модуль выполнял единственную
(связанную с общей задачей) функцию (критерий
связности).

41.

Идеальный модуль
Идеальный модуль играет роль «черного ящика»,
содержимое которого невидимо клиентам.
Он прост в использовании – количество органов
управления им невелико,
его легко развивать и корректировать в процессе
сопровождения программной системы.
Для обеспечения таких возможностей система должна
отвечать особым требованиям.
Модули системы должны иметь:
высокую связность
и низкое сцепление.
41

42.

Сцепление модулей
42
Сцепление является мерой взаимозависимости модулей
по данным.
В хорошем проекте сцепления должны быть
минимизированы,
т.е. модули должны быть слабозависимыми
(независимыми) настолько, насколько это возможно.

43.

Сцепление модулей
43
Слабое сцепление между модулями служит признаком
хорошо спроектированной системы по следующим
причинам:
уменьшение количества соединений между двумя
модулями приводит к уменьшению вероятности
появления “волнового эффекта” (ошибка в одном
модуле влияет на работу других модулей);
минимизация риска появления “эффекта ряби”
(внесение изменений, например, при исправлении
ошибки, приводит к появлению новых ошибок), т.к.
изменение влияет на минимальное количество
модулей;
при сопровождении модуля отсутствие необходимости
беспокоиться о внутренних деталях других модулей;
упрощение системы для понимания, насколько это
возможно.

44.

Сцепление модулей
44
Специалистами предлагаются следующие практические
рекомендации для ослабления сцепления модулей:
Создавайте минимальные по количеству параметров
межмодульные связи.
Создавайте прямые (а не косвенные) межмодульные
связи,
поскольку интерфейс между двумя модулями наиболее понятен
(и, следовательно, менее сложен).
Создавайте локализованные связи.
Например, значения списка параметров вычисляйте
непосредственно перед вызовом модуля.
Создавайте явные связи.
Примером неявной связи является взаимодействие модуля А с
модулем В за счет модификации области данных из В: для того,
чтобы человек, сопровождающий модуль В понял, за счет чего
модифицируется эта область данных, он должен проделать
огромную работу.
Создавайте гибкие связи для облегчения модификаций.

45.

Виды сцеплений модулей
На практике существуют три основных типа сцепления,
используемых системными проектировщиками для
связи модулей:
нормальное сцепление,
сцепление по общей области
сцепление по содержимому.
С позиций структурного проектирования эти типы
являются, соответственно,
приемлемым,
неприемлемым
и запрещенным.
45

46.

Виды сцеплений модулей
46
Два модуля А и Б являются нормально сцепленными,
если
А вызывает Б,
Б возвращает управление А,
вся информация, передаваемая между А и Б,
представляется значениями параметров при вызове.
Существует три типа нормального сцепления.

47.

Виды сцеплений модулей
1) Сцепление по данным. Два модуля сцеплены по
данным, если они
взаимодействуют через передачу параметров
и при этом каждый параметр является
элементарным информационным объектом.
В случае небольшого количества передаваемых
параметров сцепление по данным обладает
наилучшими характеристиками.
А
Элементы данных
Б
47

48.

48
Виды сцеплений модулей
2) Сцепление по образцу. Два модуля сцеплены по
образцу, если один посылает другому составной
информационный объект, т.е. объект, имеющий
внутреннюю структуру.
Примером составного объекта может быть объект Данные о
клиенте, включающий в себе поля:
Название организации,
Почтовый адрес,
Номер счета
и т.п.
А
Структуры данных
Б

49.

49
Виды сцеплений модулей
3) Сцепление по управлению. Два модуля сцеплены по
управлению, если один посылает другому
информационный объект – флаг, предназначенный
для управления его внутренней логикой.
Б
Флаг
А
Флаг
Б
Флаг
Конец

50.

Виды сцеплений модулей
50
Существует два типа флагов:
описательный
и управляющий.
Описательный флаг обычно описывает ситуацию,
которая произошла, и именуются с использованием
существительных и прилагательных:
Конец файла, Введенная кредитная карта.
Управляющий флаг используется для декларирования
определенных действий в вызываемом модуле и
именуется с использованием глаголов:
Читать следующую запись, Установить в начало.
В общем случае управляющие флаги усиливают
сцепление и, следовательно, ухудшают качество
проекта.

51.

Виды сцеплений модулей
51
Как уже отмечалось, вышеперечисленные три типа
нормального сцепления в разной степени
поддерживают суть модульности и являются
приемлемыми в структурном проектировании.
Ниже определяются два вида сцепления, которые выходят
за пределы хорошей модульности.

52.

52
Виды сцеплений модулей
Два модуля являются сцепленными по общей области,
если они ссылаются к одной и той же области
глобальных данных.
Общая
область
А
Б
В
Структура
данных

53.

Виды сцеплений модулей
Сцепление по общей области является плохим, поскольку:
1) Ошибка в любом модуле, использующем глобальную
область, может неожиданно проявить себя в любом
другом модуле, также использующем эту глобальную
область,
т.к. эти глобальные данные не находятся “под
защитой” модуля.
2) Модули, ссылающиеся к глобальным данным, обычно
используют точные имена (в отличие от модулей,
которые вызываются с использованием параметров).
Следовательно, гибкость модулей, сцепленных
глобально, намного хуже, чем гибкость нормально
сцепленных модулей.
53

54.

Виды сцеплений модулей
54
3) Программы с большим количеством глобальных данных
чрезвычайно трудны для понимания сопровождающим
программистом,
т.к. трудно определить, какие данные используются
отдельным модулем.

55.

55
Виды сцеплений модулей
Два модуля являются сцепленными по содержимому,
если один ссылается внутрь другого любым способом.
Например,
если один модуль передает управление или
выполняет переход в другой модуль,
если один модуль ссылается (или изменяет)
значения информационных объектов в другом
модуле
или если один модуль изменяет код другого модуля.
А
Б

56.

Виды сцеплений модулей
56
Сцепление по содержимому делает абсурдной концепцию
модулей как черных ящиков, поскольку оно вынуждает
один модуль знать о точном содержании и реализации
другого модуля.
Вообще говоря, только ассемблер позволяет
проектировщикам применять данный вид
сцепления.

57.

Виды сцеплений модулей
57
Любые два модуля могут быть сцеплены более чем одним
способом. В этом случае тип их сцепления
определяется худшим типом сцепления.
Пример.
Если два модуля сцеплены по образцу и общей
области, то они характеризуются как сцепленные по
общей области.
Они по-прежнему сцеплены по образцу, но это
сцепление выше, чем сцепление по общей области.

58.

Связность модуля
58
Связность – это мера прочности соединения
функциональных и информационных объектов внутри
одного модуля.
Размещение сильно связанных объектов в одном и том же
модуле уменьшает межмодульные взаимосвязи и
взаимовлияния.
Чем выше связность, тем лучше результат
проектирования, то есть тем «черней» его ящик, тем
меньше органов управления на нем находится и тем
они проще.

59.

Уровни связности модулей
Выделяют следующие уровни связности:
функциональная,
последовательная,
информационная,
процедурная,
временная,
логическая
случайная.
59

60.

60
Уровни связности модулей
Характеристика связности модуля:
Тип связности
Сопровождаемость
Роль модуля
Функциональная
«Черный ящик»
Информационная
Не совсем «черный
ящик»
Лучшая
Коммуникативная
«Серый ящик»
Процедурная
Временная
Логическая
По совпадению
«Просвечивающий
ящик»
Худшая
«Белый ящик»

61.

Уровни связности модулей
61
Функционально связный модуль содержит объекты,
предназначенные для выполнения одной и только одной
задачи, например:
Расчет заработанной платы,
Считывание данных кредитной карты.
Каждый из этих модулей имеет одну четко
определенную цель.
При его вызове выполняется только одна задача (при
этом она выполняется полностью без исполнения
любого другого дополнительного действия).

62.

Уровни связности модулей
62
Модуль имеет последовательную связность, если его
объекты охватывают подзадачи, для которых выходные
данные одной из подзадач служат входными данными
для следующей.
Например:
Открыть файл
Прочитать запись
Закрыть файл.

63.

Уровни связности модулей
63
Информационно связный модуль содержит объекты,
использующие одни и те же входные или выходные
данные.
Предположим, что мы хотим выяснить некоторые сведения о
книге, зная ее ISBN: название книги, ее автора и цену.
Эти три подзадачи являются связанными потому, что все
они работают с одним и тем же входным
информационным объектом – ISBN, который и делает этот
модуль информационно связным.

64.

Уровни связности модулей
64
Процедурно связный модуль является модулем, объекты
которого включены в различные (и возможно несвязные)
подзадачи, в которых управление переходит от каждой
подзадачи к последующей.
Отметим, что в последовательно связном модуле данные, а
не управление, переходили от одной подзадачи к
последующей.

65.

Уровни связности модулей
65
В качестве примера процедурно связного модуля приведем
следующий перечень шагов в некотором процедурно связном
модуле:
1. Сделать зарядку
2. Принять душ
3. Сварить кофе
4. Одеться
5. Отправиться на занятия
Отправиться на занятия – это последний шаг, внесенный в список
этого "модуля".
Но, например, действия
Прочитать газету или Сходить в магазин
могут быть в равной степени пригодными кандидатами для шага 5,
т.к. шаги в этом списке связаны только тем, что они происходят
в данном порядке в течение конкретного дня.

66.

Уровни связности модулей
Временно связным является модуль, объекты которого
включены в подзадачи, связанные временем
исполнения.
Представим себе картину позднего вечера:
1. Почистить зубы
2. Выключить телевизор
3. Выгнать кота в коридор
Эти действия никак не связаны друг с другом, за исключением
конкретного времени их выполнения.
Все они – часть установившегося режима в конце дня.
66

67.

Уровни связности модулей
67
Модулем с логической связностью является модуль,
объекты которого содействуют решению одной общей
подзадачи, для которой эти объекты отобраны во
внешнем по отношению к модулю мире.
Например, собираясь в поездку, можно составить себе следующий
список:
Поехать автомобилем
Поехать поездом
Поплыть на корабле
Полететь на самолете
Что связывает эти действия?
Все они являются способами перемещения.
Но решающий момент заключается в том, что для любой
поездки человек должен выбрать конкретный способ
перемещения, т.к. маловероятно, что кто-нибудь будет
использовать их все для отдельной поездки.

68.

Уровни связности модулей
68
Т.о., характерными особенностями логически связного
модуля являются
он содержит некоторое количество подзадач
(действий) одного и того же общего вида;
для того, чтобы его использовать, необходимо
выбрать именно ту часть (части), которые требуются;
эти различные подзадачи должны обладать одним и
только одним интерфейсом с внешним миром.

69.

Уровни связности модулей
Случайно связным является модуль, объекты которого
соответствуют подзадачам, незначительно связанным
друг с другом:
Ремонтировать автомобиль
Пить пиво
Смотреть фильм
Случайно связный модуль подобен логически связному
модулю,
его объекты не связаны ни потоками данных, ни
потоками управления.
Однако, подзадачи
в логически связном модуле являются по крайней
мере одной категории;
для случайно связного модуля даже это неверно.
69

70.

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

71.

71
5. Восходящее и нисходящее
проектирование ПО

72.

72
В зависимости от порядка, в каком выполняются этапы
проектирования, различают
нисходящее
и восходящее
проектирование ПС.

73.

Нисходящее проектирование
73
Суть нисходящей стратегии:
проектировщик должен приступить к работе, имея
только концептуальный абстрактный замысел о том,
что система или программа будет делать;
затем этот замысел постепенно конкретизируется
шаг за шагом, тем самым погружаясь в подробности
окончательного программного продукта до тех пор,
пока не будет достигнуто «дно»,
т.е. программные модули, реализующие
отдельные функции или процедуры
преобразования данных (принцип декомпозиции).

74.

Нисходящее проектирование
74
С точки зрения разработки ПО проектирование сверхувниз означает, что до проработки всех деталей
можно реализовать для системы скелет верхнего
уровня
и убедиться в том, что система работоспособна.
Этот подход воплощен в методике, называемой
прототипированием, или макетированием.
Суть данной методики в том, что
разработку сложной программы необходимо начать с
ее макета, который воплощал бы в себе основные ее
конструкции,
функции
или элементы
в их взаимосвязи, но без подробной детализации;
детализация осуществляется на более поздних
этапах и по принципу “сверху-вниз”

75.

Нисходящее проектирование
75
Достоинства такого макета в следующем:
макет дает наглядное представление о будущем
программном продукте;
на макете просматриваются основные функции,
выполняемые программой;
не загроможденный деталями макет четко
характеризует программное изделие и способы
достижения поставленных целей проекта;
если макет демонстрирует недостаточное
удовлетворение требований, его легко переделать на
ранних стадиях проекта;
одобренный макет – основа документации к будущей
программной системе;
по макету проще спланировать разделение труда
исполнителей, скоординировать и проконтролировать
выполнение работы.

76.

Восходящее проектирование
76
Иногда основному проектированию сверху–вниз
сопутствует разработка компонент проекта по принципу
снизу–вверх (восходящее проектирование):
разработка начинается от компонент нижнего уровня,
далее разрабатываются компоненты следующего
уровня иерархии с использованием компонент
предыдущего уровня
и т.д.

77.

Восходящее проектирование
77
Достоинством этого принципа является то, что
при переходе к разработке компонентов более
высокого уровня иерархии компоненты проекта
нижних уровней можно считать готовыми и
подключать их к проектируемым компонентам
верхнего уровня.
Однако на практике при таком подходе отсутствие
целостного взгляда на весь проект с позиций верхнего
уровня, определяющего цели проекта, не позволяет в
ряде случаев принимать верные решения, что
приводит к повторной разработке
или значительной корректировке компонент проекта.
При разработке компонент нижнего уровня необходимо
все время помнить об общих целях проекта.

78.

Восходящее проектирование
78
Разработка ПО полностью по принципу снизу-вверх
возможна
лишь для сравнительно небольших групп программ,
ограниченных по количеству несколькими модулями,
когда разработчики способны оценивать в любое
время
структуру комплекса программ в целом
и структуру и функции отдельных модулей на всех
уровнях иерархии.

79.

79
Поэтому при разработке больших программных изделий,
содержащих сотни модулей, наиболее рациональным
принципом является
проектирование сверху–вниз.
Часто оба метода применяются одновременно:
сверху вниз – при объединении в единое целое;
снизу вверх – при разработке общих хорошо
отлаженных блоков.