4.4.5 Система управления
Представляет совокупность взаимосвязанных структурных моделей подсистем, осуществляющих следующие функции:
планирование (стратегическое, тактическое, оперативное);
учет отображает состояние объекта управления в результате выполнения производственных процессов;
контроль определяет отклонение учетных данных от плановых целей и нормативов;
оперативное управление осуществляет регулирование всех процессов с целью исключения возникающих отклонений от плановых и учетных данных;
анализ определяет тенденцию в работе системы и резервы, которые учитываются при планировании на следующий временной период.
Использование моделей в составе информационных систем началось с применения статистических методов и методов финансового анализа, которые реализовывались командами обычных алгоритмических языков. Позже были созданы специальные языки, позволяющие моделировать различные ситуации. Такие языки дают возможность построения моделей определенного типа, обеспечивающих нахождение решения при гибком изменении переменных.
5.4.6 Моделирование информационных процессов
Любое ПО имеет свой жизненный цикл период от начала проектирования и до его модернизации или замены более современной версией. Для инженерного подхода к проектированию ПО были предложены модели процесса его разработки. Первым по времени и наиболее популярным можно считать метод «водопада». Эта модель идеализирует процесс проектирования, предполагая, что каждый этап проекта (анализ предметной области, разработка требований и спецификаций к ИС, архитектурное проектирование, детальное проектирование, кодирование, тестирование) завершается до начала следующего и не осуществляется возврата к предыдущему этапу. Учитывая важность для дальнейшей разработки первых этапов проектирования, а стоимость исправления допущенных на этих этапах ошибок наиболее высокой, метод «водопада» был улучшен введением временных прототипов (рисунок 5.7).
Рисунок 5.7 – Метод «водопада» с введением временных прототипов
Еще одна модель жизненного цикла спиральная модель управления рисками (рисунок 5.8). В этой модели жизненный цикл ПО не заканчивается, а продолжается его модернизация, на что и указывает спираль. Анализ рисков состоит в определении затрат, в случае ошибок, допущенных на первом этапе. Для снижения рисков предлагаются дополнительные работы, например создание временных прототипов.
|
Рисунок 5.8 – Спиральная модель |
Следующий метод модульное проектирование, предполагающий разбиение исходной функции обработки данных на ряд программных модулей, которые характеризуются следующими параметрами:
один входной и один выходной поток данных;
все операции, необходимые для преобразования входного потока в выходной, выполняются внутри модуля;
результат работы модуля зависит только от входного потока и не зависит от работы других модулей.
Состав и вид программных модулей в значительной мере определяется инструментальными средствами разработки, например, для Access набор модулей может быть таким: экранные формы, отчеты, меню и т.д.
Оба эти метода относятся к стратегии проектирования ПО, получившей название структурное проектирование или проектирование на основе потоков данных, В этой стратегии не учитывались сущность и связи объектов предметной области. Для нее характерно преобразование входной информации в выходную способами, не учитывающими физическую сущность модели предметной области.
В начале 80-х гг. появился новый подход, который был основан на моделировании реального мира изнутри наружу, т.е., моделируя все элементы системы и связи между ними, получаем модель предметной области, преобразование информации в которой происходит так же, как и в реальной моделируемой системе. Этот подход был назван методом объектно-ориентированного проектирования (ООП). При ООП на первом этапе выявляются объекты реального мира, их свойства и действия, на следующих эти объекты и их поведение отображаются на объекты программы.
Для любого метода проектирования ПО очень важным являются документирование и нотация, т.е. запись операций условным стандартизованным способом. Для структурного проектирования наиболее часто использовалась нотация схем алгоритмов. Для ООП в настоящее время используется нотация UML (Unified Modeling Language) унифицированный язык моделирования, используя который в качестве нотации, можно моделировать информационные системы с помощью современных средств автоматизации программирования.
В начале 90-х гг. из всего множества языков объектно-ориентированного анализа и проектирования выделились три, наиболее часто используемых при разработке систем: Booch, созданный Грейди Бучем, OOSE (Object-Oriented Software Engineering), разработанный Айваром Джекобсоном, и ОМТ (Object Modeling Technique), автором которого является Джеймс Рамбо. Каждый из этих методов является вполне законченным языком ООП, однако метод ВООСН особенно удобен на этапах проектирования модели, OOSE — на этапе анализа и формулирования требований, а ОМТ — удобен при проектировании СУБД. Создание языка, объединяющего достоинства этих трех методов, началось в начале 1995 г., когда эти три автора объединили свои методы для создания унифицированного языка для фирмы Rational Software. В 1997 г. была принята версия UML 1.1, взятая на вооружение всеми компаниями — производителями систем автоматизированного проектирования. В 2001 г. появилась версия 2.0. В настоящее время идет утверждение UML в качестве стандарта ISO.
Многие продукты, реализующие CASE-технологии (Computer Aided Software Engineering — автоматизированное проектирование и создание программ), в настоящее время поддерживают нотацию UML. Такие пакеты, как Paradigm Plus, System Architect, Microsoft Visual Modeler, Delphi и др., поддерживают нотацию UML. Наиболее мощный пакет проектирования, разработанный компанией Rational Software — Rational Rose (RR), позволяет использовать при разработке все возможности языка UML.