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

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

На рис. 3.2 представлены этапы проектирования типичной программной системы. Отметим, что приведенные этапы не зависят от методологии.

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

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

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

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

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

На этом этапе определяется взаимодействие с пользователем, но не рассматриваются многие его детали, такие как, например, форматы ввода-вывода.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проектировщики этапа n–1 – это авторы исходных внешних спецификаций, а проектировщики этапа n+1 – это разработчики структуры программы. Именно им и следует доверить тестирование архитектуры системы.

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

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

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

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

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

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

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

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

Рандомно подобранные статьи с сайта:

Видео 22. Жизненный цикл ПО. Этапы разработки ПО. Классическая модель разработки ПО


Похожие статьи:

admin