Учебное пособие 1295

При разработке внешних интерфейсов пользователя проектировщик должен решить три проблемы:

1)доведение до минимума ошибок пользователя;

2)обнаружение ошибок пользователя в случае их возникновения;

3)доведение до минимума сложности разрабатываемо-

го ПИ.

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

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

Детальный внешний проект каждой функции пользователя должен включать следующую информацию:

1. Описание входных данных. Точное описание синтак-

сиса (формат, допустимые значения, области изменения) и семантики всех данных, вводимых пользователем.

2. Описание выходных данных. Точное описание всех ре-

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

21

выходные данные, получаемые из любой комбинации входных данных, как правильной, так и неверной.

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

4.Характеристики надежности. Здесь описывается влияние всех возможных отказов функций на систему, файлы пользователя.

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

6.Замечания по программированию. Внешние специфи-

кации должны описывать функции с точки зрения пользователя

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

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

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

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

В процессе работы над проектом возникает необходимость внесения изменений, что связано с обнаружением оши-

22

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

Чтобы изменения в проекте не приводили к дополнительным ошибкам, следует внимательно относиться к работе с изменениями и соблюдать следующие правила.

1.Во время всего периода работы над проектом поддерживать документацию на уровне последних решений.

2.Фиксировать результаты каждого этапа процесса проектирования. Требования и цели фиксируются после их утверждения, внешние спецификации - после успешного завершения проверки их правильности. Изменения должны также проходить формальную процедуру утверждения.

3.Проверять каждое внесенное изменение до такой степени, до которой проверялось исходное решение.

4.Контролировать, чтобы нужные изменения были сделаны на всех уровнях разработки ПИ.

2.3. Внутреннее проектирование

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

Далее формируются структура программного изделия и общие правила взаимодействия компонентов.

Программное изделие создается на основе модульноиерархической структуры, состоящей из отдельных модулей.

23

К преимуществам разработки ПИ с использованием модулей можно отнести следующие:

•улучшается проектирование ПИ, так как сложную и большую проблему легче понять, разбив ее на отдельные функциональные части;

•улучшаются возможности оптимального использования ресурсов на разработку за счет распределения работы над модулем между программистами в соответствии с их способностями;

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

•упрощается оценка текущего состояния работ.

Модуль - отдельная функционально законченная программная единица, которая может применяться самостоятельно либо быть частью программы.

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

Существует много способов проектирования, при применении которых программа разбивается на множество модулей, их сопряжений и отношений.

В результате использования этих методов достигается минимальная сложность структуры ПИ.

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

24

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

Связность (связанность) модуля определяется как мера независимости его частей. Чем выше связность модуля, тем лучше результат проектирования. Для обозначения связности используется также понятие "сила связности модуля". В табл. 2.1 приведены типы связности модулей [1].

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

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

Модуль этого типа тесно связан с вызывающим его мо-

дулем.

25

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

Модуль, содержащий части функционально не связанные, но необходимые в один и тот же момент обработки, имеет

временную связность или связность по классу. Связность тако-

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

Процедурная связность обнаруживается в модуле, управляющие конструкции которого организованы так, как

26

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

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

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

27

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

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

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

Модуль с функциональной связностью обладает высшей степенью (силой) внутренней связности.

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

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

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

28

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

Цель проектирования - определение интерфейсов модулей таким образом, чтобы все данные, передаваемые от одного модуля к другому, передавались в форме явных и простых параметров. Чтобы понять важность этой цели, рассмотрим 7 видов сцепления, начиная с самого жесткого. Ниже приведены меры сцепления модулей.

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

Модуль сцеплен по внешним ссылкам, если у него есть доступ к данным в другом модуле через внешнюю точку входа. Таким путем осуществляется неявное управление функционированием другого модуля. Сцепление такого типа возникает при использовании Паскаля или ПЛ/1, когда внутренние процедуры оперируют с глобальными переменными.

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

29

зывающий на требующуюся функцию, вызываемый и вызывающий модули сцеплены по управлению.

Модули сцеплены по общей области, если они разделяют одну и ту же глобальную структуру данных. Модули ПЛ/1, ссылающиеся на структуру, объявленную как EXTERNAL, сцеплены друг с другом по общей области. Модули Фортрана, ссылающиеся на данные в блоке COMMON, группы модулей, ссылающиеся на абсолютные адреса памяти (включая регистры), также служат примерами сцепления по общей области.

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

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

Модули сцеплены по данным, если они имеют общие единицы, которые передаются от одного к другому как параметры, представляющие собой простые элементы данных, т.е. вызывающий модуль "знает" только имя вызываемого модуля, а также типы и значения некоторых его переменных. Вызываемый модуль ничего "не знает" о вызывающем его модуле. Изменения в структуре данных в одном из модулей не влияют на другой. Кроме того, модули с этим типом сцепления не имеют общих областей данных или неявных параметров [2].

Независимое сцепление возможно в том случае, если модули не вызывают друг друга или не обрабатывают одну и ту же информацию.

30