КНИГА |
16.08.01
|
ГЛАВА 7
СРЕДСТВА СТРУКТУРНОГО ПРОЕКТИРОВАНИЯ
Техника структурных карт Джексона основана на методологии структурного программирования Джексона и заключается в продуцировании диаграмм (структурных карт) для графического иллюстрирования внутримодульных (а иногда и межмодульных) связей и документирования проекта архитектуры системы ПО. При этом техника позволяет осуществлять проектирование нижнего уровня структуры ПО и на этом этапе является близкой к традиционным блок-схемам.
По аналогии со структурными картами Константайна диаграмма Джексона может включать объекты следующих типов:
Для взаимоувязывания блоков используются связи следующих типов:
Пример структурной карты Джексона приведен на рис. 7.7.
7.3. Характеристики хорошей модели реализации
Структурные карты сами по себе ничего не говорят о качестве модели (проекта) реализации, так как являются всего лишь инструментом для демонстрации структуры системы и составляющих ее модулей, а также их связей друг с другом.
Один из фундаментальных принципов структурного проектирования заключается в том, что большая система должна быть расчленена на обозримые модули. При этом существенным является то, что это расчленение должно быть выполнено таким образом, чтобы модули были как можно более независимы (критерий сцепления - coupling), и чтобы каждый модуль выполнял единственную (связанную с общей задачей) функцию (критерий связности - cohesion). Кроме этих двух взаимно дополняющих друг друга критериев в структурном проектировании существуют целый ряд других руководящих принципов, которые могут применяться для оценки и улучшения качества проекта на основании структурных карт.
Рис 7.7. Структурная карта Джексона
7.3.1. Сцепление
Одним из способов оценки качества проекта является анализ сцепления модулей. Сцепление является мерой взаимозависимости модулей. В хорошем проекте сцепления должны быть минимизированы, т.е. модули должны быть слабозависимыми (независимыми) настолько, насколько это возможно. Слабое сцепление между модулями служит признаком хорошо спроектированной системы по следующим причинам:
Слабое сцепление может быть достигнуто за счет комбинирования трех следующих способов действий:
Специалистами предлагаются следующие практические рекомендации для ослабления сцепления модулей:
На практике существуют три основных типа сцепления, использумых системными проектировщиками для связи модулей: нормальное сцепление, сцепление по общей области и сцепление по содержимому. С позиций структурного проектирования эти типы являются, соответственно, приемлемым, неприемлемым и запрещенным.
Два модуля А и В являются нормально сцепленными, если
Существует три типа нормального сцепления: сцепление по данным, сцепление по образцу, сцепление по управлению. На практике наиболее часто используемым типом сцепления является сцепление по данным (data coupling). Два модуля сцеплены по данным, если они взаимодействуют через передачу параметров и при этом каждый параметр является элементарным информационным объектом. В случае небольшого количества передаваемых параметров сцепление по данным обладает наилучшими характеристиками в соответствии с п.п.1-5.
Два модуля сцеплены по образцу (stamp coupling), если один посылает другому составной информационный объект, т.е. объект, имеющий внутреннюю структуру. Примером составного объекта может быть объект Данные о клиенте, включающий в себе поля: Название организации, Почтовый адрес, Номер счета и т.п.
Два модуля сцеплены по управлению (control coupling), если один посылает другому информационный объект - флаг, предназначенный для управления его внутренней логикой. Существует два типа флагов - описательный и управляющий. Описательный флаг обычно описывает ситуацию, которая произошла, и именуются с использованием существительных и прилагательных: Конец файла, Введенная кредитная карта. Управляющий флаг используется для декларирования определенных действий в вызываемом модуле и именуется с использованием глаголов: Читать следующую запись, Установить в начало. В общем случае управляющие флаги усиливают сцепление и, следовательно, ухудшают качество проекта.
Как уже отмечалось, вышеперечисленные три типа нормального сцепления в разной степени поддерживают суть модульности и являются приемлемыми в структурном проектировании. Ниже определяются два вида сцепления, которые выходят за пределы хорошей модульности.
Два модуля являются сцепленными по общей области (common coupling), если они ссылаются к одной и той же области глобальных данных. Сцепление по общей области является плохим по следующим причинам. Во-первых, ошибка в любом модуле, использующем глобальную область, может неожиданно проявить себя в любом другом модуле, также использующем эту глобальную область, поскольку эти глобальные данные не находятся “под защитой” модуля. Во-вторых, модули, ссылающиеся к глобальным данным, обычно используют точные имена (в отличие от модулей, которые вызываются с использованием параметров). Следовательно, гибкость модулей, сцепленных глобально, намного хуже, чем гибкость нормально сцепленных модулей. В-третьих, программы с большим количеством глобальных данных чрезвычайно трудны для понимания сопровождающим программистом, поскольку трудно определить, какие данные используются отдельным модулем.
Два модуля являются сцепленными по содержимому (content coupling), если один ссылается внутрь другого любым способом, например, если один модуль передает управление или выполняет переход в другой модуль, если один модуль ссылается (или изменяет) значения информационных объектов в другом модуле или если один модуль изменяет код другого модуля. Такое сцепление делает абсурдной концепцию модулей как черных ящиков, поскольку оно вынуждает один модуль знать о точном содержании и реализации другого модуля. Вообще говоря, только ассемблер позволяет проектировщикам применять данный вид сцепления.
Таблица 7.1
Тип сцепления |
Устойчивость к волновому эффекту |
Модифи-цируемость |
Понят-ность |
Используемость в других системах |
data coupling |
* |
хорошая |
хорошая |
хорошая |
stamp coupling |
* |
средняя |
средняя |
средняя |
control coupling |
средняя |
плохая |
плохая |
плохая |
common coupling |
плохая |
средняя |
плохая |
плохая |
content coupling |
плохая |
плохая |
плохая |
плохая |
* Зависит от количества параметров интерфейса.
Необходимо отметить, что любые два модуля могут быть сцеплены более чем одним способом. В этом случае тип их сцепления определяется худшим типом сцепления. Например, если два модуля сцеплены по образцу и общей области, то они характеризуются как сцепленные по общей области. Они по-прежнему сцеплены по образцу, но это сцепление выше, чем сцепление по общей области.
В таблице 7.1 приведены конкретные характеристики каждого типа сцепления.
7.3.2. Связность
Сцепление является лишь одним из критериев оценки качества разбиения системы на части: он оценивает, насколько хорошо модули отделены друг от друга. Другим критерием оценки качества расчленения системы является критерий связности, контролирующий, как действия в одном модуле связаны друг с другом. Фактически сцепление и связность являются двумя взаимозависимыми способами измерения расчленения системы на части: связность модуля часто определяет качество его сцепления с другими модулями.
Связность - это мера прочности соединения функциональных и информационных объектов внутри одного модуля. Размещение сильно связанных объектов в одном и том же модуле уменьшает межмодульные взаимосвязи и взаимовлияния. Специалисты выделяют следующие уровни связности: функциональная, последовательная, информационная, процедурная, временная, логическая и случайная. Рассмотрим эти уровни более подробно.
Функционально связный модуль содержит объекты, предназначенные для выполнения одной и только задачи, например: Расчет заработанной платы, Считывание данных кредитной карты. Каждый из этих модулей имеет одну четко определенную цель, при его вызове выполняется только одна задача (при этом она выполняется полностью без исполнения любого другого дополнительного действия).
Модуль имеет последовательную связность, если его объекты охватывают подзадачи, для которых выходные данные одной из подзадач служат входными данными для следующей, например: Открыть файл - Прочитать запись - Закрыть файл.
Информационно связный модуль содержит объекты, использующие одни и те же входные или выходные данные. Предположим, что мы хотим выяснить некоторые сведения о книге, зная ее ISBN: название книги, ее автора и цену. Эти три подзадачи являются связанными потому, что все они работают с одним и тем же входным информационным объектом - ISBN, который и делает этот модуль информационно связным.
Процедурно связный модуль является модулем, объекты которого включены в различные (и возможно несвязные) подзадачи, в которых управление переходит от каждой подзадачи к последующей (отметим, что в последовательно связном модуле данные, а не управление, переходили от одной подзадачи к последующей). В качестве примера приведем следующий перечень шагов в некотором процедурно связном модуле:
1. Сделать зарядку
2. Принять душ
3. Сварить кофе
4. Одеться
5. Отправиться на службу
Отправиться на службу - это последний шаг, внесенный в список этого "модуля". Но, например, действия Прочитать газету или Сходить в магазин могут быть в равной степени пригодными кандидатами для шага 5, поскольку шаги в этом списке связаны только тем, что они происходят в данном порядке в течение конкретного дня.
Временно связным является модуль, объекты которого включены в подзадачи, связанные временем исполнения. Представим себе картину позднего вечера:
1. Почистить зубы
2. Выключить телевизор
3. Выгнать кота в коридор
Эти действия никак не связаны друг с другом, за исключением конкретного времени их выполнения. Все они - часть установившегося режима в конце дня.
Модулем с логической связностью является модуль, объекты которого содействуют решению одной общей подзадачи, для которой эти объекты отобраны во внешнем по отношению к модулю мире. Например, собираясь в поездку, можно составить себе следующий список:
Что связывает эти действия? Все они являются способами перемещения. Но решающий момент заключается в том, что для любой поездки человек должен выбрать конкретный способ перемещения, т.к. маловероятно, что кто-нибудь будет использовать их все для отдельной поездки.
Таким образом логически связный модуль содержит некоторое количество подзадач (действий) одного и того же общего вида. Для того, чтобы его использовать, необходимо выбрать именно ту часть (части), которые требуются. Эти различные подзадачи должны обладать одним и только одним интерфейсом с внешним миром. При этом семантика каждого параметра зависит от используемой подзадачи.
Случайно связным является модуль, объекты которого соответствуют подзадачам, незначительно связанным друг с другом:
Случайно связный модуль подобен логически связному модулю, его объекты не связаны ни потоками данных, ни потоками управления. Однако, подзадачи в логически связном модуле являются по крайней мере одной категории; для случайно связного модуля даже это неверно.
В таблице 7.2 приведены конкретные характеристики каждого уровня связности.
Таблица 7.2
Уровень связности |
Сцепление |
Модифици-руемость |
Понятность |
Сопровож-даемость |
функциональная |
хорошее |
хорошая |
хорошая |
хорошая |
последовательная |
хорошее |
хорошая |
близкая к хорошей |
хорошая |
информационная |
среднее |
средняя |
средняя |
средняя |
процедурная |
переменная |
переменная |
переменная |
плохая |
временная |
плохое |
средняя |
средняя |
плохая |
логическая |
плохое |
плохая |
плохая |
плохая |
случайная |
плохое |
плохая |
плохая |
плохая |
Таким образом, связность является мерой функциональной зависимости объектов (исполняемых операторов, областей данных и т.д.) внутри одного модуля. В хорошем проекте связность каждого модуля является высокой (последовательность введенных выше определений уровней связности соответствует направлению от лучшей связности к худшей). Вместе со сцеплением, связность является одним из лучших критериев оценки качества проекта.
Дополнительную информацию Вы можете получить в компании Interface Ltd.
Отправить ссылку на страницу по e-mail
Обсудить на форуме
Interface Ltd. Отправить E-Mail http://www.interface.ru |
|
Ваши
замечания и предложения отправляйте
вебмастеру Документ опубликован: 16.08.01 |