- •Б. Б. Желваков
- •Моделирование систем
- •Учебное пособие
- •Санкт-Петербург
- •Составитель
- •Подготовлено на кафедре
- •230201 – Информационные системы и технологии
- •1. Основные понятия теории моделирования систем 6
- •2. Классификация моделей и методов моделирования 21
- •3. Математические методы моделирования 35
- •4. Имитационное моделирование. 62
- •5. Моделирование организационных систем 116
- •6. Методика и стандарты функционального моделирования 140
- •7. Объектно-ориентированное моделирование 166
- •8. Моделирование бизнес-процессов 221
- •9. Моделирование систем с soa-архитектурой 226
- •10. Модели систем с «облачной» архитектурой 237
- •Введение
- •1. Основные понятия теории моделирования систем
- •1.1. Системный подход и понятие «система»
- •1.2. Системный анализ
- •1.3. Понятия «модель» и «моделирование»
- •1.4. Моделирование систем как процесс формирования знаний.
- •1.5. Моделирование больших и сложных систем.
- •2. Классификация моделей и методов моделирования
- •2.1. Основные типы системных моделей
- •2.2. Классификация методов моделирования сложных систем
- •3. Математические методы моделирования
- •3.1. Принципы и подходы к построению математических моделей
- •3.2. Этапы построения математической модели
- •3.3. Примеры математических моделей
- •3.3.1. Модель целенаправленной системы
- •3.3.2. Модель абстрактной системы с неопределённой структурой
- •3.3.3. Модель целенаправленной системы с управлением.
- •3.3.4. Модель оптимального планирования доставки товаров потребителям
- •3.3.5. Модель в контуре управления экономической системы
- •4. Имитационное моделирование.
- •4.1. Понятие имитационного моделирования
- •4.2. Автоматизация имитационного моделирования
- •4.3. Дискретно-событийное моделирование
- •4.3.1. Системы массового обслуживания
- •4.3.2. Механизмы продвижения времени
- •4.3.3. Обозначения смо-систем
- •4.3.4. Параметры систем массового обслуживания
- •4.3.5. Критерии оценки работы систем массового обслуживания
- •4.3.6. Компоненты дискретно-событийной имитационной модели и их программная организация
- •4.4 Этапы исследования системы с помощью имитационного моделирования
- •4.5. Преимущества, недостатки и ошибки имитационного моделирования
- •4.6. Моделирование по методу Монте-Карло
- •4.7. Программное обеспечение имитационного моделирования
- •4.7.1. Классификация программных средств имитационного моделирования
- •4.7.2. Общие элементы моделирования
- •4.7.3. Универсальные пакеты имитационного моделирования
- •4.7.4. Предметно-ориентированные пакеты имитационного моделирования
- •5. Моделирование организационных систем
- •5.1. Концепции и стандарты организационного моделирования
- •5.2. Метамоделирование
- •5.3. Метамодель общих хранилищ данных (cwm)
- •5.4. Моделирование организационных систем
- •6. Методика и стандарты функционального моделирования
- •6.1. Методика функционального моделирования sadt
- •6.2. Диаграммы «сущность-связь»
- •6.3.Стандарты idef
- •6.3. Система моделирования бизнес-процессов AllFusion Process Modeler
- •7. Объектно-ориентированное моделирование
- •7.1. Принципы и методология объектно-ориентированного подхода.
- •7.2. Унифицированный язык моделирования uml
- •7.2.1. Архитектура uml
- •7.2.2. Диаграммы uml
- •7.2.3. Использование uml при моделировании систем реального времени
- •7.2.4. Преимущества uml
- •7.2.5. Унифицированный Процесс разработки по компании Rational
- •7.3. Архитектура, управляемая моделями
- •7.4. Разработка, управляемая моделями (mdd)
- •7.5. Объектно-ориентированное программирование
- •7.6 Инструментальные средства поддержки оо‑технологий
- •8. Моделирование бизнес-процессов
- •9. Моделирование систем с soa-архитектурой
- •9.1. Композитная структура программ
- •9.2. Концепция soa
- •9.3. Сервис-ориентированное моделирование
- •10. Модели систем с «облачной» архитектурой
- •Заключение
- •Литература
7.4. Разработка, управляемая моделями (mdd)
Существует формализованная связь модели с соответствующей программной её реализацией через одно или несколько автоматизированных преобразований модели. Возможно, наилучшим и наиболее успешным примером этого является компилятор, который преобразует язык программирования высокого уровня в эквивалентную реализацию на машинном языке. Моделью в этом случае является программа, написанная на языке высокого уровня, которая, как и все полезные модели, скрывает несущественные детали об индивидуальных особенностях нижележащей технологии вычислений (такие как внутренний размер слова, количество аккумуляторов и индексных регистров, тип ALU и т.д.).
Потенциал, скрытый мощной комбинацией абстракции и автоматизации, ведет к появлению новых технологий моделирования и соответствующих методов разработки: ‑ Model-Driven Engineering (MDE) и Model-Driven Development (MDD), которые в переводе на русский означают одно и то же – управляемая моделями разработка.
Определяющей особенностью MDD является то, что основными артефактами этапа проектирования программы становятся модели, перемещая, таким образом, фокус с соответствующего кода программы на её модель. Они выступают в качестве своеобразных «чертежей», из которых различные автоматизированные и полуавтоматизированные процессы извлекают программы и соответствующие модели. Степень автоматизации, используемая сегодня в MDD, варьируется от извлечения простого скелетного кода до генерирования полного автоматического кода (что сравнимо с традиционной компиляцией). Очевидно, что чем выше уровни автоматизации, тем более адекватными являются модели и тем большими преимуществами обладает MDD.
Управляемые моделями методы разработки программного обеспечения не являются чем-то кардинально новым ‑ они использовались с переменным успехом и раньше. Причиной возросшего внимания к ним в настоящее время является то, что поддерживающие технологии достигли такого уровня, при котором практической автоматизации поддается значительно больше процессов, чем раньше. И не только с точки зрения эффективности, но и масштабируемости, а также способности соответствующих инструментальных средств интегрироваться с традиционными средствами и методами. Это развитие отражается в появлении MDD-стандартов, что ведет к унификации соответствующих средств и очевидным выгодам для пользователей. Одним из таких стандартов является пересмотренная версия Unified Modeling Language – UML 2.0.
В качестве примера объектно ориентированной методики моделирования рассмотрим он-лайновую систему выполнения заказов некоторого гипотетического Интернет-магазина, [25]. Для описания требований к системе, ее проектирования и разработки можно рассматривать динамические и статические модели на различных уровнях абстракции: уровне контекста, концептуальном, логическом и физическом уровнях.
Вначале строися динамическая модель для концептуального уровня абстракции. Она должна отражать взаимодействия между клиентом (объект Клиент) и магазином (объект Система). клиент и сотрудники магазина выступают как внешние по отношению к системе исполнители (Actors). Весь процесс рассматривается с точки зрения Клиента и Сотрудника. Клиент осуществляет заказ через Интернет. Оплата выполняется с помощью кредитной карты. Заказ посылается по указанному адресу. Уведомление о выполнении заказа посылается по электронной почте. Модель на самом высоком уровне описывает бизнес-процессы продавца и содержит простой сценарий использования (use case), описывающий взаимодействия между системой и исполнителями (справа на рис. 7.6).
Рис. 7.6. Динамическая концептуальная модель процесса закупки товара ,[25]
Статическая модель на этом уровне абстракции отражает структуру классов и связи между объектами, необходимость в которых становится очевидной при анализе динамической модели. Другими словами, она отвечает на вопрос: "Какие объекты должен использовать (и понимать) Клиент для того, чтобы выполнить транзакцию, связанную с покупкой?"
На рис 7.7 показана диаграмма классов, которая является статической концептуальной моделью данной системы (Интернет-магазина).
Рис. 7.7. Статическая модель процесса закупки товара в магазине (Диаграмма классов UML), [25]
Клиент является конкретной реализацией класса Человек. Связи между клиентом и магазином обеспечены наличием Учетной записи клиента. Все Заказы ассоциированы с Учетной записью. Заказ ассоциирован со всеми приобретаемыми Элементами заказа. Каждый элемент заказа является специфическим Продуктом, где Продукт сам по себе является классом. Наконец, каждый Платеж ассоциирован с некоторым Заказом.