5.6. Моделирование

инсрормаиионнын проиессоВ

В традиционных инженерных дисциплинах всегда

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

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

Основываясь на оценках, полученных с помощью математической модели,

можно достаточно уверенно приступать, например, к

конструированию здания. Однако применительно к программному обеспечению

(ПО) проектирование оказывается преимущественно неформальным

процессом, для которого зачастую нет моделей и методов

прогнозирования результата. С этой точки зрения можно сравнить эволюцию

программного и аппаратного обеспечения на протяжении

нескольких последних десятилетий. Если аппаратные устройства со

временем становились миниатюрнее, быстрее и дешевле, то программы,

напротив, оказывались все более объемными, медленными,

дорогими и менее надежными. Одна из причин такого положения состоит

в том, что в основе проектирования современной аппаратуры лежит

использование прогностических моделей.

Отсутствие фундаментальных инженерных принципов в

практике разработки ПО можно отчасти объяснить изменчивой, хаотичной

природой программ, что сильно затрудняет математическое

моделирование. Тем не менее имеется немало полезных аналитических ме-

281

тодик. Любое ПО имеет свой жизненный цикл — период от начала

проектирования и до его модернизации или замены более

современной версией. В конце 60-х гг. появился термин software engineering

(инженерное проектирования программ), которым обозначали

совокупность административных и технических методов, процедур и

инструментальных средств, необходимых для эффективного

написания крупных программных систем. Были разработаны разные

подходы для проектирования алгоритмов и программ, которые

появлялись и развивались под влиянием увеличивающейся потребности в

скорости и качестве разработки ПО.

5.6.1. Модели разработки программного обеспечения

Для инженерного подхода к проектированию ПО были

предложены модели процесса его разработки. Первым по времени и

наиболее популярным можно считать метод «водопада». Эта модель

идеализирует процесс проектирования, предполагая, что каждый этап

проекта завершается до начала следующего и не осуществляется воз-

Анализ

Требования

Спецификация

Архитектурное

проектирование

Детальное

проектирование

Кодирование

Тестирование

Рис. 5.8. Моделирование методом «водопада»

282

врата к предыдущему этапу (рис. 5.9). Учитывая важность для

дальнейшей разработки первых этапов проектирования, а стоимость

исправления допущенных на этих этапах ошибок наиболее высокой,

метод «водопада» был улучшен введением временных прототипов

(см. рис. 5.9). Например, прототипов интерфейса, анализ которых

пользователем может дать дополнительные сведения до разработки

основных программных конструкций следующих этапов.

Анализ

Требования

Спецификация

Создание

временных

прототипов

Архитектурное

проектирование

Детальное

проектирование

Кодирование

Тестирование

Рис. 5.9. Метод «водопада» с введением временных прототипов

Еще одна модель жизненного цикла — спиральная модель

управления рисками (рис. 5.10). В этой модели жизненный цикл ПО не

заканчивается, а продолжается его модернизация, на что и

указывает спираль. Анализ рисков состоит в определении затрат, в случае

ошибок, допущенных на первом этапе. Для снижения рисков

предлагаются дополнительные работы, например создание временных

прототипов.

283

I. Определение 2. Анализ риска

целей, альтернатив

и ограничений

4. Планирование 3. Разработка

следующего цикла и верификация

Рис. 5.10. Спиральная модель

5.6.2. Методы проектирования

программного обеспечения

Один из наиболее популярных методов проектирования ПО —

метод нисходящего проектирования. Он предполагает

последовательное разложение общей функции обработки данных на простые (для

данного уровня) функциональные элементы. В результате

получается иерархическая модель, отражающая состав и взаимоподчиненность

отдельных функций. Эта схема носит название функциональной

структуры алгоритма (ФСА) приложения. Недостатком ФСА является то,

что каждый ее уровень является единым целым и не может

разрабатываться параллельно группой разработчиков.

Следующий метод — модульное проектирование. Этот метод

предполагает разбиение исходной функции обработки данных на ряд

программных модулей, которые характеризуются следующими

параметрами:

• один входной и один выходной поток данных;

• все операции, необходимые для преобразования входного

потока в выходной, выполняются внутри модуля;

• результат работы модуля зависит только от входного потока и не

зависит от работы других модулей.

284

Состав и вид программных модулей в значительной мере

определяется инструментальными средствами разработки, например, для

Access набор модулей может быть таким: экранные формы, отчеты,

меню и т.д.

Оба эти метода относятся к стратегии проектирования ПО,

получившей название структурное проектирование или проектирование

на основе потоков данных, В этой стратегии не учитывались сущность

и связи объектов предметной области. Для нее характерно

преобразование входной информации в выходную способами, не

учитывающими физическую сущность модели предметной области.

В начале 80-х гг. появился новый подход, который был основан

на моделировании реального мира изнутри наружу, т.е., моделируя все

элементы системы и связи между ними, получаем модель

предметной области, преобразование информации в которой происходит так

же, как и в реальной моделируемой системе. Этот подход был назван

методом объектно-ориентированного проектирования (ООП). При

ООП на первом этапе выявляются объекты реального мира, их

свойства и действия, на следующих — эти объекты и их поведение

отображаются на объекты программы.

Для любого метода проектирования ПО очень важным

являются документирование и нотация, т.е. запись операций условным

стандартизованным способом. Для структурного проектирования

наиболее часто использовалась нотация схем алгоритмов. Для ООП в

настоящее время используется нотация UML (Unified Modeling

Language) — унифицированный язык моделирования, используя

который в качестве нотации, мы будем моделировать информационные

системы с помощью современных средств автоматизации

программирования.

5.7. Унифииированный язык

моделирования UML

В начале 90-х гг. из всего множества языков

объектно-ориентированного анализа и проектирования выделились три, наиболее

часто используемых при разработке систем: Booch, созданный Грейди

Бучем, OOSE (Object-Oriented Software Engineering), разработанный

Айваром Джекобсоном, и ОМТ (Object Modeling Technique), автором

285

которого является Джеймс Рамбо. Каждый из этих методов является

вполне законченным языком ООП, однако метод ВООСН особенно

удобен на этапах проектирования модели, OOSE — на этапе анализа

и формулирования требований, а ОМТ — удобен при

проектировании СУБД. Создание языка, объединяющего достоинства этих трех

методов, началось в начале 1995 г., когда эти три автора объединили

свои методы для создания унифицированного языка для фирмы

Rational Software. В 1997 г. была принята версия UML 1.1, взятая на

вооружение всеми компаниями — производителями систем

автоматизированного проектирования. В 2001 г. появилась версия 2.0.

В настоящее время идет утверждение UML в качестве стандарта ISO.