Целью структурного программирования является стремление избежать ошибок при конструировании модулей и при написании программ. Использование структурного программирования с пошаговым совершенствованием проекта до уровня кодирования с использованием трех базовых структур приводит к заметному уменьшению числа ошибок кода, а также позволяет резко сократить время, затрачиваемое на тестирование и отладку программ. Структурное программирование делает код более понятным, уменьшая затраты на сопровождение программного изделия в дальнейшем.
Одновременное кодирование и документирование программ является побочным результатом пошагового совершенствования. При этом проектная информация сохраняется в самом исходном коде в виде комментариев, осрормленных по правилам структурного кодирования.
21
Детальное проектирование программного изделия связано с декомпозицией компонент нижнего уровня архитектурного проекта до модулей на выбранном языке программирования. При этом модуль рассматривается в виде программного блока, который может отдельно компилироваться и отдельно загружаться и объединяться с другими блоками.
Таким образом, процесс детального проектирования, начинаясь с компонент нижнего уровня архитектурного проекта, путем пошагового совершенствования доходит до спецификации отдельных модулей. При пошаговом совершенствовании используют следующие руководящие указания:
- начинаем с функциональной спецификации и спецификации интерфейсов;
- концентрируем внимание на потоках управления;
- откладываем объявление данных до фазы кодирования;
- шаги совершенствования делаем небольшими, чтобы была проще верифи
кация внесенных изменений;
- проводим обзор каждого шага после его выполнения.
Обзор каждого модуля может быть выполнен путем сквозного просмотра, после которого модуль утверждается для кодирования.
1.6.2. Кодирование модулей
Когда завершено проектирование каждого модуля и проведены его обзор и утверждение, можно начинать кодирование (написание программ). Должны быть установлены и документированы требования кодирования, которые определяют правила:
- представления комментариев в программах;
- наименования программ, подпрограмм, файлов, переменных;
- ограничения размеров модулей;
- использования библиотек;
- определения констант;
- использования специальных средств компилятора, которых нет в языке;
- обработки ошибок и т.п.
Каждый модуль должен иметь заголовок, оформленный стандартным образом, который включается в "шапку" модуля.
Код должен быть непротиворечивым, что уменьшает его сложность. Основой для обеспечения непротиворечивости является строгое соблюдение правил кодирования. Кроме того, непротиворечивость усиливается в результате использования одинаковых решений к одинаковым проблем. Для сохранения непротиворечивости кода все вносимые исправления и модификации должны использовать первоначальный стиль кодирования.
Код должен быть структурным, так как это уменьшает ошибки и улучшает со-провождаемость.
Процесс кодирования включает компиляцию, которая является первым шагом в верификации кода. В результате компиляции накапливается статистика, необходимая для последующего анализа модуля.
После кодирования отдельных модулей начинается их интеграция в единое работающее программное изделие. Интеграция компонент должна проводиться последовательно функция за функцией. Это позволяет раньше продемонстрировать операционные возможности программного обеспечения, повышая уверенность управленца в том, что проект удовлетворительно продвигается в изготовлении.
Для интеграции модулей применяется нисходящий подход, в котором вместо модулей нижнего уровня применяют программные "заглушки". После завершения разработки и тестирования модулей нижнего уровня "заглушки" заменяются ими. В ряде проектов необходимость правильного распределения усилий приводит к тому,
22
что на ранних этапах интеграция вначале осуществляется по восходящему принципу, который позже заменяется нисходящим. Независимо от используемого принципа главным критерием остается минимизация общего времени на тестирование программного изделия .
1.6.3. Тестирование программного изделия
Процесс тестирования включает несколько этапов: поблочное тестирование, комплексное тестирование и системное тестирование.
Тестирование блоков показывает правильность реализации всех компонент программного изделия, начиная с самого нижнего уровня, определенного в детальном проекте, вплоть до самого нижнего уровня архитектурного проекта (обычно на уровне задач). Модули, которые не вызывают другие модули - это модули нижнего уровня детального проекта.
При тестировании блоков обычно проверяется правильность не только того, что функционально выполняет модуль, но и того как он это делает. Таким образом^ при тестировании блоков используется не только функциональное тестирование (тестирование "черного ящика"), но и структурное тестирование (тестирование "белого ящика").
Стратегия структурного тестирования предполагает такой подбор тестовых данных, чтобы, во-первых, каждый оператор программы был выполнен, по крайней мере, один раз, и, во-вторых, все пути выполнения программы были охвачены соответствующими тестовыми наборами. Для проведения поблочного тестирования используются также и специальные автоматизированные средства.
Тестирование блоков обычно выполняется отдельными работниками или группой, ответственной за разработку этих компонент.
Комплексное тестирование также выполняется во время фазы детального проектирования, когда формируются основные компоненты программного изделия и объединяются с целью построения программного изделия. Комплексное тестирование должно быть направлено на верификацию того, что интерфейсы главных компонент правильны. Комплексное тестирование предшествует системному тестированию.
Комплексное тестирование должно контролировать, что все данные, передаваемые через интерфейсы, согласованы со спецификациями структур данных в архитектурном проекте. Комплексное тестирование должно также подтверждать, что потоки управления, определенные в архитектурном проекте программного изделия, :.полностью реализованы.
Системное тестирование - это процесс тестирования интегрированного программного изделия. Этот этап тестирования может быть выполнен в процессе разработки или в условиях моделирования эксплуатации. Системное тестирование должно подтверждать соответствие разработанного программного изделия целям, установленным в документе «Требования пользователя».
Системное тестирование включает такие виды деятельности:
- передача данных в систему, корректность обработки данных и вывод резуль
татов;
- прогон тестов с целью проверки выполнения требований пользователя;
- стрессовое тестирование для верификации предельных характеристик про
граммного изделия;
- предварительная оценка надежности и пригодности к сопровождению;
- проверка правильности «Руководства пользователя».
В системных тестах контролируются возможные тенденции в появлении ошибок в программном обеспечении. Изучение этих тенденций позволяет судить о возможностях последующей приемки программного изделия.
23
Для большинства программных изделий, которые предназначены для включения в более крупные программные системы, а также для систем, использующих специальную периферию, часто возникает необходимость построения имитаторов окружающей обстановки, т.е. той обстановки, в которой будет функционировать разрабатываемое изделие. Их разработку также необходимо планировать.
1.6.4. Документирование работ по проектированию программного изделия
По мере того, как проектирование продвигается к самому нижнему уровню декомпозиции происходит создание документа «Детальный проект программного изделия». Документирование должно проводиться одновременно с детальным проектированием, кодированием и тестированием. В больших проектах этот документ для удобства делают в нескольких томах.
Часть 1 документа содержит описание принятых стандартов на проектирование и кодирование используемых средств. Материал этого раздела подготавливается в качестве первого вида деятельности во время этой фазы до того, как начинается работа по детальному проектированию и кодированию.
Часть 2 документа постепенно расширяется по мере разработки проекта.
Часть 2 документа постепенно расширяется по мере разработки проекта. Структура этой части документа и идентификация разделов должна полностью соответствовать программным компонентам программного изделия.
Основным требованием, предъявляемым к содержанию документа является его завершенность, т.е. полный охват всех требований к программному изделию, изложенных в соответствующем документе. В связи с этим документ «Детальный проект» должен содержать таблицу перекрестных ссылок между отдельными требованиями к программному изделию и компонентами детального проекта.
2. Техническое задание на разработку программного изделия
2.1. Общие замечания
Структура и содержание разделов технического задания должна обеспечить программиста информацией о сущности и особенностях автоматизируемого процесса, о структурах и содержании потоков данных, характеризующих технологический процесс, об алгоритмах обработки данных, реализующих технологический процесс и о формах представления выходной информации, требуемой пользователю.
Основная цель документа собрать всю необходимую для дальнейшего проектирования информацию и представить ее в виде, понятном как пользователю-непрограммисту (работнику предметной области), так и программисту, который должен реализовать поставленную задачу и обеспечить автоматизацию всех согласованных с пользователем функций программного изделия и обеспечить выполнение всех требований и ограничений.