ГЛАВА 7

СРЕДСТВА СТРУКТУРНОГО ПРОЕКТИРОВАНИЯ

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

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

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

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

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

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

4) Принцип отсутствия памяти. Когда вызванный модуль возвращает управление вызвавшему его модулю после выполнения своей функции, этот модуль “умирает”, оставляя после себя только результат. При повторном вызове он делает свою работу так, как будто бы он родился впервые. Модуль не помнит, что происходило в его предыдущих жизнях. Однако, существует тип модуля, который знает о своем прошлом благодаря так называемой памяти состояния. Память состояния (state memory) - это информационный объект внутри модуля, который продолжает существовать неизмененным между двумя вызовами модуля. Работа модуля с памятью состояния в общем случае непредсказуема, это означает, что хотя модуль вызывался с одинаковыми фактическими параметрами, исполняться он может по-разному, и результаты его работы при разных вызовах могут быть различными. Сопровождение такого модуля резко усложняется.

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

6) Компромисс между ограниченностью и обобщенностью. Ограниченный модуль обладает по крайней мере одной из следующих характеристик:

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

• Он выполняет нелепо обширную работу. Примером является модуль, формирующий расписание игр чемпионата по футболу как по Грегорианскому, так и по Юлианскому календарю.
• Он имеет дело с слишком избыточными типами данных, их значениями и структурами. Например, использование числа типа REAL вместо INTEGER для того, чтобы следить за количеством болтов на складе, было бы чрезмерным обощением.
• Он принимает в качестве параметров данные, которые никогда не изменятся. Так модуль, которому передается количество дней в неделе, является определенно сверхобобщенным, а также до смешного нелепым.

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

8) Нагрузка по входу и выходу. Под нагрузкой модуля по входу понимается количество непосредственных вызывающих его модулей. Соответственно, нагрузка модуля по выходу - это количество непосредственно подчиненных ему модулей. По уже упоминавшимся выше причинам нагрузка по выходу не должна превышать 6-7 модулей. Высокая нагрузка по входу требует от модуля хорошей связности.

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

• разбиение иерархии диаграмм потоков данных на относительно легко поддающиеся обработке единицы средствами транзакционного анализа;
• конвертирование каждой единицы в “хорошую” структурную карту средствами трансформационного анализа;
• обратное соединение разделенных единиц в полную модель реализации.

Определим транзакцию как объект, содержащий следующие пять компонент:

СОБЫТИЕ в системе или ее внешнем окружении

СИГНАЛ к системе

ДЕЙСТВИЕ системы

ОТКЛИК от системы

ВЛИЯНИЕ на систему или ее окружение

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

СОБЫТИЕ Диспетчер замечает, что корабль движется слишком быстро

СИГНАЛ Замедлить скорость корабля на 210 м/сек

ДЕЙСТВИЕ Определить какой из тормозных ракетных двигателей включить и на какое время

ОТКЛИК Сигнал тормозному двигателю ракеты для его включения на 4.8 сек

ВЛИЯНИЕ Корабль замедлил скорость на 210 м/сек

Следующий пример относится к компании, устанавливающей газовое отопление на дачных участках:

СОБЫТИЕ Владелец дачи Сергей Чеченин устал пилить и колоть дрова для камина и решил установить газовое отопление

СИГНАЛ Информация о г-не Чеченине и его даче, а также дата начала обслуживания

ДЕЙСТВИЕ Добавить данные о г-не Чеченине в базу данных клиентов

ОТКЛИК Разрешение на предоставление услуг

ВЛИЯНИЕ В освободившееся от дровяных работ время г-н Чеченин проектирует систему автоматизации газовой компании

Отметим, что подобные отдельные транзакции относятся к классам, определяемым как классы транзакционного типа. Например, три транзакции "ДОБАВИТЬ ЧЕЧЕНИНА", "ДОБАВИТЬ ИВАНОВА" и "ДОБАВИТЬ ПЕТРОВА" являются примерами одного транзакционного типа, который может быть назван "ДОБАВИТЬ НОВОГО КЛИЕНТА".

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

Таким образом, транзакционный анализ является методом идентификации типов транзакций системы для их дальнейшего использования в качестве единиц проектирования.

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

• выявление центрального преобразования - фрагмента DFD, который содержит концептуальные функции системы и не зависит от особенностей реализации системных входов и выходов;
• конвертирование DFD в предварительную структурную карту;
• доработка этой структурной карты средствами структурного проектирования;
• проверка окончательной структурной карты на соответствие требованиям первоначальной DFD.

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

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

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

• Добавить модули чтения и записи для доступных источников, стоков и файлов.
• Добавить модули обработки ошибок.
• Добавить детали инициализации и завершения, если требуется.
• Проконтролировать, что все модули имеют имена в соответствии с их положением в иерархии.
• Добавить все связи по данным и управлению, которые являются необходимыми на структурной схеме, но не на DFD, например, информация: "конец потока".
• Проверить все критерии структурного проектирования и улучшить проект в соответствии с этими критериями.

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

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

Продолжение