6. Моделирование информационных процессов

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

Отсутствие фундаментальных инженерных принципов в практике разработки ПО можно отчасти объяснить изменчивой, хаотичной природой программ, что сильно затрудняет математическое моделирование. Тем не менее имеется немало полезных аналитических методик. Любое ПО имеет свой жизненный цикл – период от начала проектирования ПО и до его модернизации или замены более современной версией ПО. В конце 60-х появился термин software engineering (инженерное проектирования программ), которым обозначали совокупность административных и технических методов, процедур и инструментальных средств, необходимых для эффективного написания крупных программных систем. Были разработаны разные подходы для проектирования алгоритмов и программ, которые появлялись и развивались под влиянием увеличивающейся потребности в скорости и качестве разработки ПО.

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

Для инженерного подхода к проектированию ПО были предложены модели процесса разработки ПО. Первым по времени и наиболее популярным можно считать метод "водопада". Эта модель идеализирует процесс проектирования, предполагая, что каждый этап проекта завершается до начала следующего и не осуществляется возврата к предыдущему этапу (рис.5.9.). Учитывая важность для дальнейшей разработки первых этапов проектирования, а стоимость исправления допущенных на этих этапах ошибок наиболее высокой, метод "водопада" был улучшен введением временных прототипов (рис.5.10.). Например, прототипов интерфейса, анализ которых пользователем может дать дополнительные сведения до разработки основных программных конструкций следующих этапов.

Ещё одна модель жизненного цикла – спиральная модель управления рисками (рис.5.11.). В этой модели жизненный цикл ПО не заканчивается, а продолжается его модернизация, на что и указывает спираль. Анализ рисков состоит в определении затрат, в случае ошибок, допущенных на первом этапе. Для снижения рисков предлагаются дополнительные работы, например создание временных прототипов.

2. Методы проектирования программного обеспечения

Один из наиболее популярных методов проектирования ПО – метод нисходящего проектирования. Он предполагает последовательное разложение общей функции обработки данных на простые (для данного уровня) функциональные элементы. В результате получается иерархическая модель, отражающая состав и взаимоподчинённость отдельных функций. Эта схема носит название функциональной структуры алгоритма (ФСА) приложения. Недостатком ФСА является то, что каждый её уровень является единым целым и не может разрабатываться параллельно группой разработчиков.

Следующий метод – модульное проектирование. Этот метод предполагает разбиение исходной функции обработки данных на ряд программных модулей, которые характеризуются следующими параметрами:

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

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

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

Состав и вид программных модулей в значительной мере определяется инструментальными средствами разработки, например, для ACCESS набор модулей может быть таким: экранные формы, отчёты, меню и т.д.

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

В начале 80-х появился новый подход, который был основан на моделировании реального мира изнутри наружу, т.е. моделируя все элементы системы и связи между ними, получаем модель предметной области, преобразование информации в которой происходит так же как и в реальной моделируемой системе. Этот подход был назван методом объектно-ориентированного проектирования (ООП). При ООП на первом этапе выявляются объекты реального мира их свойства и действия, на следующих – эти объекты и их поведение отображаются на объекты программы.

Для любого метода проектирования ПО очень важным является документирование и нотация, т.е. запись операций условным стандартизованным способом. Для структурного проектирования наиболее часто использовалась нотация схем алгоритмов. Для ООП в настоящее время используется нотация UML (Unified Modeling Language) – унифицированный язык моделирования, используя который в качестве нотации, мы будем моделировать информационные системы с помощью современных средств автоматизации программирования.