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

 

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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

 

Правильность проектирования и планирование изменений

 

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

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

Хотя проверка правильности каждого отдельного этапа проектиро­вания проводится по разным методикам, можно сформулировать общую систему правил проверки в виде правила «n плюс-минус один». Вопросом пер­востепенной важности при проверке правильности проекта является при­влечение к этому делу «подходящих» людей. Наиболее «подходящие» люди – это те, в чьих интересах обнаружить все ошибки. Пусть, например, мы закончили n -й этап проектирования архитектуры системы. Проектиров­щики этапа n –1 – это авторы исходных внешних спецификаций, а проекти­ровщики этапа n +1 – это разработчики структуры программы. Именно им и следует доверить тестирование архитектуры системы.

Правило «n плюс-минус один» состоит в следующем: проверка пра­вильности этапа проекта должна осуществляться проектировщиками эта­пов n +1 и n –1. Это правило – еще один пример того, что интуитивно оче­видно, но редко применяется на практике. В случае необходимости должны быть установлены формальные процедуры, обеспечивающие ее применение.

 

Рис. 3.3. Основания для раннего обнаружения ошибок проектирования

 

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

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

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

Третье правило работы с изменениями – проверять правильность всякого изменения в такой же степени, в какой проверялось исходное ре­шение.

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