КНИГА |
23.08.01
|
ГЛАВА 7
СРЕДСТВА СТРУКТУРНОГО ПРОЕКТИРОВАНИЯ
7.3.3. Другие принципы проектирования
Очевидно, что для оценки качества проектируемой системы критериев сцепления и связности недостаточно. Например, если бы мы осуществляли оценку только по критерию сцепления, мы бы всегда получали системы, состоящие из одного модуля. Связность этого единственного модуля также была бы вполне приемлемой. Ниже кратко рассматриваются другие принципы проектирования, позволяющие получать качественные системы.
1) Принцип факторизации. Под факторизацией понимается выделение подзадачи, реализуемой некоторым модулем, в новый самостоятельный модуль. Это может быть сделано по следующим резонам:
2) Принцип единства решения. Процесс любого решения состоит из двух частей: распознавания того, какое действие выбрать, и исполнения этого действия. Поскольку эти две составляющие решения очень различны, информационные объекты, используемые при распознавании и исполнении также могут существенно различаться и, следовательно, могут быть недоступными в одном модуле. Такая ситуация получила название расщепления решения (decision split). Сильное расщепление решения (хотя иногда расщепления не удается избежать) обычно является симптомом плохой организации модулей. Исполнительная часть решения должна располагаться как можно ближе к распознавательной части, чтобы распознанной информации не пришлось долго “блуждать” для того, чтобы быть обработанной.
3) Обработка ошибок. Сообщения об ошибках целесообразно формировать и визуализировать в модуле, который ошибку обнаруживает (и, следовательно, “знает”, что это за ошибка). Тексты сообщений рекомендуется хранить вместе по следующим резонам:
4) Принцип отсутствия памяти. Когда вызванный модуль возвращает управление вызвавшему его модулю после выполнения своей функции, этот модуль “умирает”, оставляя после себя только результат. При повторном вызове он делает свою работу так, как будто бы он родился впервые. Модуль не помнит, что происходило в его предыдущих жизнях. Однако, существует тип модуля, который знает о своем прошлом благодаря так называемой памяти состояния. Память состояния (state memory) - это информационный объект внутри модуля, который продолжает существовать неизмененным между двумя вызовами модуля. Работа модуля с памятью состояния в общем случае непредсказуема, это означает, что хотя модуль вызывался с одинаковыми фактическими параметрами, исполняться он может по-разному, и результаты его работы при разных вызовах могут быть различными. Сопровождение такого модуля резко усложняется.
5) Инициализация и завершение. Как правило, модули инициализации и завеpшения являются тpудными для сопpовождения из-за их плохой (временной) связности и сильного сцепления. Общая рекомендация по решению этой проблемы - инициализацию каждой функции желательно выполнять как можно позже, а действия по завершению каждой функции должны производиться как можно раньше. И, конечно, необходимо проводить инициализацию и завершение как можно ближе к тому, что инициализируется или завершается.
6) Компромисс между ограниченностью и обобщенностью. Ограниченный модуль обладает по крайней мере одной из следующих характеристик:
Противоположная крайность ограниченному модулю - сверхобобщенный модуль, обладающий по крайней мере одной из следующих характеристик:
7) Принцип минимизации избыточности. Если любой факт, условие или реализационное решение явно проявляются в более чем одном модуле, то усилия по сопровождению, состоящие из нахождения всех случаев этого факта и их изменения, увеличиваются. Также возникает опасность того, что человек, сопровождающий такую систему, забудет изменить один из дублей.
8) Нагрузка по входу и выходу. Под нагрузкой модуля по входу понимается количество непосредственных вызывающих его модулей. Соответственно, нагрузка модуля по выходу - это количество непосредственно подчиненных ему модулей. По уже упоминавшимся выше причинам нагрузка по выходу не должна превышать 6-7 модулей. Высокая нагрузка по входу требует от модуля хорошей связности.
7.4. Транзакционный и трансформационный анализ или как получить структурные карты из диаграмм потоков данных
В этом параграфе кратко обсуждаются три шага, регламентирующих процесс получения структурных карт из диаграмм потоков данных и, таким образом, обеспечивающих естественный переход от модели требований к модели реализации. Этими шагами являются:
Определим транзакцию как объект, содержащий следующие пять компонент:
СОБЫТИЕ в системе или ее внешнем окружении
СИГНАЛ к системе
ДЕЙСТВИЕ системы
ОТКЛИК от системы
ВЛИЯНИЕ на систему или ее окружение
Например, в системе управления космическим кораблем транзакция может быть представлена как совокупность следующих элементов:
СОБЫТИЕ Диспетчер замечает, что корабль движется слишком быстро
СИГНАЛ Замедлить скорость корабля на 210 м/сек
ДЕЙСТВИЕ Определить какой из тормозных ракетных двигателей включить и на какое время
ОТКЛИК Сигнал тормозному двигателю ракеты для его включения на 4.8 сек
ВЛИЯНИЕ Корабль замедлил скорость на 210 м/сек
Следующий пример относится к компании, устанавливающей газовое отопление на дачных участках:
СОБЫТИЕ Владелец дачи Сергей Чеченин устал пилить и колоть дрова для камина и решил установить газовое отопление
СИГНАЛ Информация о г-не Чеченине и его даче, а также дата начала обслуживания
ДЕЙСТВИЕ Добавить данные о г-не Чеченине в базу данных клиентов
ОТКЛИК Разрешение на предоставление услуг
ВЛИЯНИЕ В освободившееся от дровяных работ время г-н Чеченин проектирует систему автоматизации газовой компании
Отметим, что подобные отдельные транзакции относятся к классам, определяемым как классы транзакционного типа. Например, три транзакции "ДОБАВИТЬ ЧЕЧЕНИНА", "ДОБАВИТЬ ИВАНОВА" и "ДОБАВИТЬ ПЕТРОВА" являются примерами одного транзакционного типа, который может быть назван "ДОБАВИТЬ НОВОГО КЛИЕНТА".
Транзакционные типы могут быть идентифицированы по модели требований системы на основании типов отдельных событий, которые получает эта система. Если модель требований включает в себя событийную модель, то транзакционные типы могут быть без труда выявлены, например из иерархии диаграмм переходов состояний.
Таким образом, транзакционный анализ является методом идентификации типов транзакций системы для их дальнейшего использования в качестве единиц проектирования.
В свою очередь, трансформационный анализ или проектирование трасформационного (преобразующего) центра является методом преобразования в структурную карту каждой из частей иерархии диаграмм потоков данных, которые мы выделили при транзакционном анализе. Трансформационный анализ включает следующие четыре шага:
Один из способов нахождения центрального преобразования состоит в удалении центростремительных и центробежных потоков, которое осуществляется с помощью следующих трех шагов. Во-первых, необходимо проследить каждую центростремительную ветвь от края DFD к центру и пометить поток данных, который представляет системный вход в наиболее концептуальной форме. Другими словами, необходимо пометить стадию прохождения потока, на которой вычленены необходимые для обработки данные, которые еще не использовались в реальном процессе. Во-вторых, необходимо проследить каждую центробежную ветвь от края DFD к центру и пометить поток данных, который представляет выход в наиболее концептуальной форме. Другими словами, необходимо пометить стадию прохождения потока, на которой выходные данные были только что получены, но еще не отформатированы. В-третьих, необходимо соединить все отметки замкнутой кривой. Процессы внутри этой кривой и будут составлять центральное преобразование.
Напомним, что цель трансформационного анализа состоит в том, чтобы превратить DFD для одного типа транзакций в структурную карту. Основное различие между DFD и структурной картой состоит в том, что на структурной карте изображается главный модуль системы. В DFD нет главных модулей. Процессы DFD подобны довольным своей жизнью рабочим в идеалистической коммуне, каждый из которых беспокоится за свою собственную работу и передает свой продукт следующему рабочему на линии.
Для решения данной задачи поступают следующим образом. Один процесс в области центрального преобразования DFD может выделяться как потенциальный главный модуль. При этом признаком такого выделения может, например, являться то, что он выполняет незначительную обработку данных, но при этом координирует работу других процессов. Далее для того, чтобы улучшить схему, следует, по необходимости, выполнить следующее:
Следующий шаг трансформационного анализа является критическим. Необходимо убедиться, что структурная карта, извлеченная из DFD, корректно реализует требования системы. Для этой цели можно, например, обсудить построенную структурную карту с аналитиком - автором соответствующей DFD.
Наконец, на последнем этапе из построенного набора структурных карт необходимо составить полную картину проектируемой системы. Одним из способов решения данной задачи является связывание структурных карт путем введения общего для всех них главного модуля, координирующего работу каждой их них.
Дополнительную информацию Вы можете получить в компании Interface Ltd.
Отправить ссылку на страницу по e-mail
Обсудить на форуме
Interface Ltd. Отправить E-Mail http://www.interface.ru |
|
Ваши
замечания и предложения отправляйте
вебмастеру Документ опубликован: 23.08.01 |