Методы разработки программного обеспечения
Подходы к разработке программного обеспечения
Согласно [1] на сегодняшний день имеются следующие подходы к проектированию программного обеспечения:
проектирование исходя из выполняемых программным обеспечением функций;
проектирование, основанное на исследовании потоков данных;
проектирование, основанное на структуре данных;
проектирование на базе абстрактных типов данных;
объектно-ориентированное проектирование.
Дадим краткую характеристику названных подходов.
Проектирование исходя из выполняемых функций. Задана выполняемая проектируемым ПО функция. Проектирование заключается в выполнении функциональной декомпозиции, т.е. разделении заданной функции на ряд подфункций; каждая подфункция рассматривается, в свою очередь, как функция и подвергается функциональной декомпозиции. Этот процесс продолжается до тех пор, пока не получатся подфункции, которым соответствуют легко реализуемые программные модули.
Каждой функции соответствуют:
перечень входных данных;
описание выполняемой функции;
перечень выходных данных.
Этот подход нашел свое выражение в методике структурного программирования. Наиболее стройно идеи структурного программирования нашли выражение в HIPO-технологии. (HIPO –Hierarchical-input-processing -output). В HIPO-технологии процесс проектирования заключается в составлении IPO-диаграмм. Каждая IPO-диаграмма соответствует одной функции. Пример IPO-диаграммы показан на рис. 1.1. IPO-диаграммы соединены между собой иерархической связью (структурой). В принципе, реализацию каждой IPO-диаграммы (т.е. написание требуемого программного модуля) можно поручить разным программистам, распараллеливая, таким образом, процесс создания ПО.
1
1.1
1.2
1.1.1
1.1.2
1.1.3
1.2.1
1.2.2
Иерархическая схема
IPO – диаграмма
Номер: 1.1 |
Имя: |
|
Вход Input |
Процесс Processing |
Выход Output |
Описание исходных данных модуля |
Описание процесса преобразование входвыход. Включая обращение к модулям более низкого уровня. |
Описание выходных данных |
Рис. 1.1. Функциональная декомпозиция
Описанный подход разработки ПО применяется при решении алгоритмически сложных задач, не связанных с обработкой больших массивов сложно организованных данных. Сюда, в первую очередь, относятся научно-технические задачи. Он подходит и для разработки простейших информационных систем. Для разработки систем реального времени и параллельных систем не применяется.
Проектирование, основанное на исследовании потоков данных.
Первым этапом проектирования по этой методике является составление диаграмм потоков данных. Пример диаграммы и применяемых обозначений приведен на рис. 1.2. Диаграмма потоков данных задает движение данных, а не передачу управления, как на традиционных схемах алгоритмов. Следующим этапом после составления диаграммы является определение структуры данных для каждого источника, потребителя, файла (базы данных). Для каждого источника и потребителя разрабатываются интерфейс пользователя.
После уточнения входа-выхода и выполняемой функции для каждого процесса обработки дальнейшее проектирование этого процесса может быть осуществлено по методике, описанной выше.
Исходя из потоков данных целесообразно проектировать системы обработки данных. На схеме легко отобразить процесс передачи и обработки данных (например, между разными подразделениями предприятия) с дальнейшим уточнением состава передаваемых данных и содержания обработки.
Обозначения
Источники данных(1,2,3)
Процесс
о бработки(5, 6) Получатель данных(4)
Поток
данных
Файл
или база данных
1
3
5
4
6
2
Рис. 1.2. Диаграмма потоков данных
Проектирование, основанное на структуре данных. Этот метод применяется, главным образом, при проектировании баз данных. Проектирование начинается с определения структур данных всех источников. Должен соблюдаться принцип: каждый элемент данных вводится один раз от первоисточника. На основе всех структур данных источников проектируется глобальная структура данных, так называемая концептуальная модель данных. Концептуальная модель данных содержит все данные, хранимые в базе (рис. 1.3).
Внешние модели Концептуальная модель Внешние модели
Данных данных
Источники
База данных Потребители
Рис. 1.3. База данных
Потребителям может быть представлено определенное подмножество данных из концептуальной модели, соответствующее информационным потребностям. Это подмножество называется внешней моделью данных. Кроме непосредственного представления данных из базы пользователям, они могут быть использованы как исходные данные для прикладных программ, а результаты выполнения программ передаются пользователям информации.
Проектирование на основе абстрактных типов данных. Тип данных характеризуется:
множеством допустимых значений;
составом операций над данными и
правилами их выполнения.
Проектирование на базе абстрактных типов данных заключается в установлении соответствия между объектами предметной области и имеющимися в среде реализации абстрактными типами данных, а также в доопределении и реализации недостающих данных и операций над ними. Названный подход применяется при разработке трансляторов языков программирования. Новым свойством этого подхода, по сравнению с рассмотренными выше, является инкапсуляция (упрятывание свойств). От пользователя скрыты детали реализации операций на абстрактных типах данных. Более подробно это рассмотрим при обсуждении объектно-ориентированного программирования.
Объектно-ориентированное проектирование. При традиционном процедурном программировании программа состоит из описательной и исполнительной частей. В описательной части задаются свойства обрабатываемых данных; весь процесс обработки определяется в исполнительной части. В объектно-ориентированном программировании вводится понятие объект, которое включает:
описание данных, характеризующих объект;
описание процедур и функций для обработки этих данных.
Описание объектов содержится в описательной части программы, в связи с этим часть обработки тоже задается в описательной части. Исполнительная часть содержит вызовы процедур и функций, заданных в объектах и может содержать другие операции, дополняющие их.
Объектно-ориентированное программирование имеет новые свойства:
инкапсуляция (упрятывание);
наследование свойств;
полиморфизм.
Инкапсуляция – это возможность закрыть часть “внутренностей” объекта от пользователей.
Наследование свойств – это возможность связать объекты отношениями подчинения и, таким образом, передать все свойства одного объекта другому.
Полиморфизм – это возможность разной реализации одних и тех же операций у разных объектов.
Модели процесса разработки программного обеспечения
В [3] различают четыре модели процесса разработки ПО:
“Водопад” (Waterfall);
Прототипирование;
Итерация;
Спираль.
Модель “Водопад” представлена на рис. 1.4. Характерная черта этой модели – полное завершение предыдущего этапа до начала следующего. В связи с этим имеются следующие ограничения:
Предполагает, что требования к разрабатываемой системе заморожены до начала проектирования.
Замораживание требований к системе обычно влечет за собой и выбор технических средств в начале разработки(они являются частью требований к системе).
При разработке новой программной системы трудно обеспечить их выполнение. Поэтому согласно этой модели можно организовать, главным образом, разработку простых систем или новых версий уже внедренных систем. В последнем случае процесс разработки, внедрения и дальнейшего усовершенствования имеет циклический характер (рис. 1.5.). Реализация включает кроме разработки программ, их тестирование и отладку разработчиками. Бета-тестирование означает передачу нескольких копий программного продукта квалифицированным пользователям для работы. С учетом их замечаний разрабатывается окончательный вариант продукта. Выпуск – это передача программного продукта для широкого использования. Естественно, разделение этапов бета-тестирования и выпуска программной продукции требуется только в случае разработки на рынок, в надежде на широкое внедрение. При разработке для конкретного заказчика бета-тестирование отсутствует. Сопровождение – это устранение замеченных в ходе эксплуатации ошибок и недостатков, незначительные улучшения, накопление предложений для разработки новых версий продукта.
Анализ
Проектирование спецификаций
Реализация
Сборка и испытание
Сопровождение
Рис. 1.4. Модель “Водопад”
Анализ
Проектирование спецификаций
Сопровождение
Реализация
Выпуск
Бета - тестирование
Рис. 1.5. Цикл создания и усовершенствание программного обеспечения
Схема прототипирования показана на рис. 1.6. Идея метода заключается в том, что сначала разрабатывается не сам программный продукт, а его прототип, содержащий решение главных проблем, стоящих перед разработчиками. После успешного завершения разработки прототипа по тем же принципам разрабатывается и настоящий программный продукт. Прототипирование позволяет устранить ограничения модели “Водопад”. Прототип позволяет лучше понимать требования к разрабатываемой программе. Используя прототип, заказчик также может точнее сформулировать свои требования. Разработчик имеет возможность с помощью прототипа предъявить заказчику предварительные результаты своей работы. Прототипирование желательно при разработке сложных и больших систем. В прототипе должны быть решены наиболее сложные проблемы, особенно те, возможность решения которых вызывает сомнения. В прототип нецелесообразно включать проблемы, решение которых заведомо не вызывает никаких трудностей.
Рис. 1.6. Прототипировние
Итерационная модель представлена на рис. 1.7. Она является сочетанием модели “Водопад” и прототипирования. Согласно этой модели процесс разработки выполняется как наращивание новых функциональных возможностей в разрабатываемую систему до тех пор, пока не реализованы все требуемые функции программного продукта. Разработку желательно начинать с решения наиболее сложных функций, при реализации которых могут возникнуть принципиальные трудности или с функций, которые внедрены до завершения всей разработки.
Преимущества данной модели:
Возможность активного участия заказчика в разработке, он имеет возможность уточнить свои требования в ходе разработки.
Возможность тестирования вновь разрабатываемых частей совместно с ранее разработанными, это уменьшит затраты на комплексную отладку.
Уже во время разработки можно начинать внедрение по частям.
Отличие прототипирования от итерационной разработки заключается в том, что прототип не обязательно войдет в окончательный вариант программного продукта, а служит лишь прообразом каких-то его частей. При итерационном процессе разработки каждый следующий шаг дополняет предыдущий.
ПРОЕКТИРОВАНИЕ
РЕАЛИЗАЦИЯ
АНАЛИЗ
ПРОЕКТИРОВАНИЕ
РЕАЛИЗАЦИЯ
АНАЛИЗ
ПРОЕКТИРОВАНИЕ
РЕАЛИЗАЦИЯ
АНАЛИЗ
1-я итерация 2-я итерация … n-я итерация
Рис. 1.7. Итерационная модель
Модель “Спираль” представлена на рис. 1.8. Каждый цикл в модели начинается с определения этого цикла, анализа разных путей ее достижения и возможных ограничений, оценивается степень неопределенности и риска. Выбирается стратегия проектирования, позволяющая их уменьшить. Далее разрабатывается первый прототип, следует анализ, уточнение требований и т.д. Круг за кругом, как показано на рисунке, программный продукт приближается к окончательному виду. Эта модель применяется для проектов с большой неопределенностью и риском.