3.2. Основные этапы проектирования программного обеспечения

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

На рис. 3.2 представлены этапы проектирования типичной про­граммной системы. Отметим, что приведенные этапы не зависят от мето­дологии. Все указанные действия должны выполняться в той или иной форме, независимо от того, какой язык программирования был принят, пи­сал ли пользователь исходные требования, использовалось ли «структур­ное программирование» или «объектно-ориентированное программирова­ние».

Отметим, что проектирование ПО носит итеративный характер. Если на одном из этапов проектирования обнаружена ошибка, то для ее исправ­ления иногда приходится возвращаться на один из предыдущих этапов, куда именно – зависит от типа ошибки. Этот итеративный подход отражен на рис. 3.2. наличием стрелок, по которым возможны переходы между эта­пами, как при наличии ошибок, так и при отсутствии ошибок. Рассмотрим сначала последовательность этапов проектирования в предположении, что ошибок обнаружено не было.

Рис. 3.2. Этапы проектирования надежного ПО

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

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

Если в ПО предусмотрена база данных, то наличествует этап ее про­ектирования. Это определения всех внешних для программной системы структур, например записей в файле или в базе данных.

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

В качестве примера проектирования рассмотрим ПО для системы управления «интеллектуальным зданием», реализованной по технологии Feildbus. Это распределенная система, под которой понимают совокуп­ность автономных контроллеров управления и систем, объединенных в коммуникационные подсети для накопления данных и действующих со­вместно для решения общей задачи диспетчерского управления «интеллек­туальным зданием». Посредством сети происходит координация распреде­ленных процессов и обмен информацией. В отличие от централизованных систем здесь нет единого устройства управления. Различные процессы, та­кие как обеспечение потребителей электроэнергией, газом, холодной и го­рячей водой, информационными ресурсами, охранная и аварийная сигна­лизация, не только управляются автономно, но и внутри отдельного про­цесса возможно распараллеливание задач. В системе также наличествует база данных, учитывающая потребление каждого вида ресурсов, а также все аварии и сроки их устранения.

Для некоторых программных систем не все этапы, приведенные на рис. 3.2, являются обязательными. Часто отсутствуют этапы проектирова­ния архитектуры системы и проектирования базы данных; этапы исход­ного и детального внешнего проектирования также зачастую сливаются воедино. В данном учебном пособии в качестве единого сквозного при­мера возьмем один из проектов, в которых реализуются не все этапы – раз­работку лабораторной работы для изучения циклических кодов (ЦК). ЛР содержит 4 задачи:

1. Тестирование при допуске к ЛР. Тестирование осуществляется стан­дартной программой тестирования и требует только разработки собст­венно тестов.

2. Проектирование в среде Matlab (создание проекта системы). Проек­тирование состоит в построении функциональных моделей кодера ЦК, ка­нала передачи данных и декодера ЦК с использованием библиотеки Simu­link.

3. Исследование и анализ характеристик смоделированной системы. Характеристики изучаются на базе аналитической и имитационной моделей, которые программируется на базе встроенного в Matlab языка программи­рования.

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