1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom

Методические аспекты проектирования ПО

121

Дуги, входящие в блок и выходящие из него на диафамме верхнего уровня, являются точно теми же самыми, что и дуги, вхо­ дящие в диафамму нижнего уровня и выходящие из нее, потому что блок и диафамма изображают одну и ту же часть системы.

На последующих рис. 2.3—2.5 приведены различные вариан­ ты выполнения функций и соединения дуг с блоками.

Некоторые дуги присоединены к блокам диафаммы обоими концами, у других же один конец остается неприсоединенным. Неприсоединенные дуги соответствуют входам, управлениям и выходам родительского блока. Источник или получатель этих пофаничных дуг может быть обнаружен только на родительской диафамме. Неприсоединенные концы должны соответствовать дугам на исходной диафамме. Все фаничные дуги должны про­ должаться на родительской диафамме, чтобы она была полной и непротиворечивой.

На SADT-диафаммах не указаны явно ни последователь­ ность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т.д. (рис. 2.5).

Как было отмечено, механизмы (дуги с нижней стороны) по­ казывают средства, с помощью которых осуществляется выпол­ нение функций. Механизм может быть человеком, компьютером или любым другим устройством, которое помогает выполнять данную функцию (рис. 2.6).

Каждый блок на диафамме имеет свой номер. Блок любой диафаммы может быть далее описан диафаммой нижнего уров­ ня, которая, в свою очередь, может быть далее детализирована с помощью необходимого числа диафамм. Таким образом, форми­ руется иерархия диафамм.

Для того чтобы указать положение любой диафаммы или блока в иерархии, используются номера диафамм. Например, А21 является диафаммой, которая детализирует блок А21 на ди­ афамме А2. Аналогично, диафамма А2 детализирует блок А2 на диафамме АО, которая является самой верхней диафаммой мо­ дели. На рис. 2.7 показан пример дерева диафамм.

Стратегии декомпозиции

При построении иерархии диафамм используются следую­ щие стратегии декомпозиции:

122				Глава 2
			Родительский блок
А11			/
			Т
			А12
А1			А13
i	Эта управляющая дуга переносится с
		родительской диаграммы
А121
			^г
		>и 1 ^
		'"W	А122
	ivra
Эта входная ^,			уг
переносится
				*-
с родительской
диаграммы			А123	W
			Эта дуга продолжается
			на родительской
А12			диафамме

Рис. 2.4. Соответствие интерфейсных дуг родительской (а)

идетальной (б) диафамм

•Функциональная декомпозиция — декомпозиция в соответ­ ствии с функциями, которые выполняют люди или органи­ зация. Может оказаться полезной стратегией для создания системы описаний, фиксирующей взаимодействие между людьми в процессе их работы. Очень часто, однако, взаи­ мосвязи между функциями весьма многочисленны и слож-

Методические аспекты проектирования ПО

123

	Системные требования
		Комментарии
i	f	А
Разработка
проекта
	А1
Предварител ьная		f
специфика!4ИЯ

	Экспертиза	^-
	А2	1 ^
		V'лучшей
		проект

Рис. 2.5. Пример обратной связи

Законодательство

j Внутренние инструкции

Отчетность	\ Г	У'	Отчетность
			вышестоящим
налогоплательщиков		Работа	организациям
	с отчетностью
р-	юридических		W*
		лиц
		А1

i i

Отдел по работе с юридическими лицами

Рис. 2.6. Пример механизма

1 24

А1

Работа с физическими

лицами

А11

Работа по подоходному

налогу

Глава 2

АО

Работа Государственной налоговой инспекции

А2	A3
Работа	Работа
с юридическими	вспомогательных
лицами	подразделении

	А12	А13
		Работа
	Работа
		по налогу
	по налогу
		на землю
	на имущество

Рис. 2.7. Иерархия диафамм

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

•Декомпозиция в соответствии с известными стабильными подсистемами — приводит к созданию набора моделей, по одной модели на каждую подсистему или важный компо­ нент. Затем для описания всей системы должна быть пост­ роена составная модель, объединяющая все отдельные мо­ дели. Рекомендуется использовать разложение на подсисте­ мы, только когда разделение на основные части системы не меняется. Нестабильность границ подсистем быстро обес­ ценит как отдельные модели, так и их объединение.

•Декомпозиция по физическому процессу — выделение функциональных стадий, этапов завершения или шагов вы­ полнения. Хотя эта стратегия полезна при описании суще-

Методические аспекты проектирования ПО

125

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

Завершение моделирования (определение момента прекращения декомпозиции)

Одна из наиболее частых проблем, возникающих в процессе построения SADT-моделей, — когда же следует завершить постро­ ение конкретной модели? На этот вопрос не всегда легко ответить, хотя существуют некоторые эвристики для определения разумной степени полноты. Здесь представлены правила, которыми пользу­ ются опытные аналитики для определения момента завершения моделирования. Они носят характер рекомендаций. Только дли­ тельная практика позволит приобрести знания, необходимые для принятия правильного решения об окончании моделирования.

Прежде чем обсуждать критерии для определения заверше­ ния процесса моделирования, рассмотрим, как увеличивается размер модели. С точки зрения математики размер иерархичес­ ких моделей увеличивается со скоростью геометрической прог­ рессии. В табл. 2.1 показаны размеры полной четырехуровневой SADT-модели, каждая диаграмма которой состоит из четырех блоков, причем каждый из этих блоков декомпозируется анало­ гичной диаграммой.

В такой модели общее число блоков составляет 1365, а в четы­ рехуровневой модели, содержащей по шесть блоков на диаграм­ ме, общее число их 9331.

Хотя с математической точки зрения все верно, SADT-моде­ ли такого размера никогда не создаются по целому ряду причин. Ни одна SADT-модель не будет иметь одинаковую глубину. Обычно модель строится слоями, большинство из которых не яв­ ляются глубокими. Чаще всего ограничиваются тремя уровнями. Опыт показывает, что, как правило, создаются несколько диаг­ рамм второго и третьего уровней только для того, чтобы убедить­ ся, что для достижения цели уже первый уровень содержит доста­ точно информации.

126			Глава 2
		Таблица 2.1
	Размеры четырехуровневой SADT-модели
Уровень	Общее число блоков в модели
модели	4 блока/1 диаграмма	6 блоков/1 диафамма
Тор	1	1
0	5	7
1	21	43
2	85	259
3	341	1555
4	1365	9331	1

Если SADT-модель декомпозируется на глубину 5-6 уровней, то в этом случае на такую глубину декомпозируется обычно один из блоков диаграммы АО. Функции, которые требуют такого уровня детализации, часто очень важны, и их детальное описание дает ключ к секретам работы всей системы. Но хотя важные функции могут нуждаться в глубокой детализации, таких функ­ ций при создании одной модели насчитывается, как правило, немного. Модели, обладающие такими функциями, имеют обыч­ но форму зонтика с широким тонким куполом и длинной ручкой, на которой происходит детализация. Поэтому вторая причина, по которой размер SADT-моделей не растет в геометрической прогрессии, заключается в том, что, хотя нередко модель имеет глубину 5-6 уровней, она почти никогда не декомпозируется вся до такой степени детализации.

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

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

Методические аспекты проектирования ПО

127

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

•необходимо изменитьуровень абстракции, чтобы достичь

шей детализации блока. Блоки подвергаются декомпозиции, если они недостаточно детализированы для удовлетворения цели модели. Но иногда при декомпозиции блока выясняет­ ся, что диаграмма начинает описывать, как функционирует блок, вместо описания того, что блок делает. В этом случае происходит изменение уровня абстракции — изменение сути того, что должна представлять модель (т.е. изменение спосо­ ба описания системы). В SADT изменение уровня абстрак­ ции часто означает выход за пределы цели модели и, следова­ тельно, это указывает на прекращение декомпозиции;

•необходимо изменить точку зрения, чтобы детализиров

блок. Изменение точки зрения происходит примерно так же, как изменение уровня абстракции. Это чаще всего характер­ но для ситуаций, когда точку зрения модели нельзя исполь­ зовать для декомпозиции конкретного блока, т. е. этот блок можно декомпозировать, только если посмотреть на него с другой позиции. Об этом может свидетельствовать заметное изменение терминологии;

•блок очень похож на другой блок той же модели или на

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

•блок представляет тривиальную функцию. Тривиальная фун ция — это такая функция, понимание которой не требует ни-

128

Глава 2

каких объяснений. В этом случае очевидна целесообразность отказа от декомпозиции, потому что роль SADT заключается в превращении сложного вопроса в понятный, а не в педан­ тичной разработке очевидных деталей. В таких случаях де­ композиция определенных блоков может принести больше вреда, чем пользы. Тривиальные функции лучше всего опи­ сываются небольшим объемом текста. Следует заметить, что «тривиальный» не означает «бесполезный». Тривиальные функции выполняют очень важную роль, поясняя работу бо­ лее сложных функций, а иногда и соединяя вместе основные подсистемы. Поэтому при анализе не следует пропускать три­ виальные функции. Наоборот, их существование должно быть зафиксировано и они должны быть детализированы, как и любые другие функции. Однако следует предостеречь от больших затрат времени на анализ тривиальных функций системы. Усиленное внимание к мелочам может привести к созданию модели, которой будет недоставать абстракции, что сделает ее трудной для понимания и использования.

Ъшы связей между функциями

Одним из важных моментов при моделировании с помощью метода SADT является точная согласованность типов связей между функциями. Различают по крайней мере связи семи типов (в порядке возрастания их относительной значимости):

•случайная;

•логическая;

•временная;

•процедурная;

•коммуникационная;

•последовательная;

•функциональная.

Случайная связь показывает, что конкретная связь между функциями незначительна или полностью отсутствует. Это отно­ сится к ситуации, когда имена данных на SADT-дугах в одной диаграмме имеют слабую связь друг с другом. Крайний вариант этого случая показан на рис. 2.8.

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

Методические аспекты проектирования ПО

129

Рис. 2.8. Случайная связь

Временная связь — представляет функции, связанные во вре­ мени, когда данные используются одновременно или функции включаются параллельно, а не последовательно.

Процедурная связь (рис. 2.9) — функции сгруппированы вмес­ те благодаря тому, что они выполняются в течение одной и той же части цикла или процесса.

'ЧГ

Планировать
А	^		1 f
	А
А1
		W Согласовать
1 F		/ •	А и В
			Аз|

Планировать В £\

А2

Рис. 2.9. Процедурная связь

130

Глава 2

Коммуникационная связь — функции группируются благодаря тому, что они используют одни и те же входные данные и/или производят одни и те же выходные данные (рис. 2.10).

Рис. 2.10. Коммуникационная связь

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

^г

Ав

W			\г
	А1
		W	С
		W	W

А2

Рис. 2.11. Последовательная связь