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

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

Итог описанным сцеплениям подведём при помощи следующей таблицы (табл. 2.2.):

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

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

31

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

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

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

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

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

2.Хороший модуль снаружи проще, чем внутри.

32

3. Хороший модуль проще использовать, чем построить. Кроме внутренней (по виду) связности и внешней (по виду сцепления) связности степень независимости модуля оп-

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

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

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

33

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

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

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

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

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

•применяются стандартные правила организации связей с другими модулями по управлению и информации;

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

иправила работы отдельных частей ПИ в целом;

•должен отсутствовать эффект последействия очередного исполнения программного модуля на последующие исполнения.

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

34

пами организации модулей, полноты декомпозиции и минимизации доступа к данным.

2.4. Проектирование и программирование модулей

Этапы проектирования и программирования модулей являются завершающими в общем цикле проектирования ПИ. На этих этапах выполняются процессы внешнего проектирования модулей» а также проектирование и кодирование логики модулей. Рассмотрим содержание этих процессов.

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

Внешние спецификации модуля должны содержать перечисленную ниже информацию.

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

2.Функция. Определяется, что делает, модуль, когда он вызван, а также его назначение. Этот элемент спецификации не должен содержать сведения о том, как функция реализуется.

3.Список параметров. Определяются число и порядок параметров, передаваемых модулю.

4.Входные параметры. Подробно описываются все входные параметры (указываются атрибуты, формат, размер, единицы измерения, а также допустимые диапазоны возможных значений всех входных параметров).

35

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

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

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

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

1.Выбор языка программирования. Выбор языка про-

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

Выбор языка программирования обычно осуществляется на более ранних стадиях разработки ПИ; однако, если язык не определен, то программист выполняет выбор на этом шаге. Существенное влияние на выбор языка оказывают его возмож-

36

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

2.Проектирование внешних спецификаций модуля.

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

3.Проверка правильности внешних спецификаций мо-

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

4.Выбор алгоритма и структуры данных. К на-

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

Если же поиск не приводит к желаемому результату, то алгоритм и структуры данных необходимо разработать.

5.Оформление начала и конца будущего модуля. Преду-

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

6.Объявление всех данных, используемых в качестве па-

раметров. Записываются соответствующие операторы объявления.

7.Объявление оставшихся данных. Записываются опе-

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

8.Детализация текста программы. В результате не-

скольких итераций осуществляется последовательная де-

37

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

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

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

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

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

1)проектирование сверху-вниз;

2)модульное программирование;

3)структурное кодирование.

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

38

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

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

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

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

39

9.Окончательное оформление текста программы. Текст модуля проверяется еще раз. При этом вставляются дополнительные комментарии, поясняющие текст программы.

10.Проверка правильности программы. Вручную про-

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

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

После компиляции на основе полученной информации проверяется правильность интерпретации компилятором намерений программиста по объявленным данным.

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

мирование.

Этап проектирования и программирования модулей оказывает влияние на стиль программирования, надёжность, эффективность, отладку, тестирование и сопровождение.

2.5. Стандарты на разработку ПО

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

40