
- •Б. Б. Желваков
- •Моделирование систем
- •Учебное пособие
- •Санкт-Петербург
- •Составитель
- •Подготовлено на кафедре
- •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.2.4. Преимущества uml
Использование UML обеспечивает следующие преимущества:
UML ‑ объектно-ориентированный язык, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных объектно-ориентированных языках;
UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;
Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;
UML расширяем, и позволяет вводить собственные текстовые и графические стереотипы, что позволяет применять его не только в сфере программной инженерии;
UML получил широкое распространение и динамично развивается.
UML необходим:
руководителям проектов, которые управляют распределением задач и контролем за проектом;
проектировщикам информационных систем, которые разрабатывают технические задания для программистов;
бизнес-аналитикам, обследующим реальную систему и проводящим инжиниринг и реинжиниринг бизнеса компании;
программистам, которые реализуют модули информационной системы.
UML может быть применен на всех этапах жизненного цикла анализа и разработки бизнес-приложений. Различные виды диаграмм, поддерживаемые UML, и богатейший набор возможностей представления определенных аспектов системы делает UML универсальным средством описания как программных, так и деловых (бизнес-) систем.
Кроме того, UML специально создавался для оптимизации процесса разработки программных систем, что позволяет увеличить эффективность реализации ПС в несколько раз и заметно улучшить качество конечного продукта.
Несмотря на свою молодость, UML уже прекрасно зарекомендовал себя на множестве успешных программных проектов. Средства автоматической кодогенерации позволяют переводить модели на языке UML в исходный код объектно-ориентированных языков программирования, что еще более ускоряет процесс разработки.
Практически все мировые производители CASE-средств заявили о реализации поддержки UML в ближайших версиях своих продуктов. Но уже сегодня существуют множество CASE-средств, автоматизирующих процесс анализа и проектирования в UML (Rational Rose, Paradigm Plus, Select Enterprise, Microsoft Visual Modeler for Visual Basic и др.), поддерживающих множество языков программирования, таких, как C++, Java, Delphi, Power Builder, Visual Basic, Centura, Forte, Ada, Smalltalk, а также позволяющих осуществлять генерацию базы данных для большинства из существующих SQL-серверов.
7.2.5. Унифицированный Процесс разработки по компании Rational
Унифицированный Процесс разработки компании Rational (Rational Unified Process, RUP) – это сумма различных видов деятельности, необходимых для преобразования требований пользователей в программную систему, [18]. Его абстрактное и развёрнутое представление показано на рис. 7.2.
Основными понятиями RUP являются артефакт (artifact) и прецедент (precedent). Артефакты — это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным программным продуктом. Прецеденты или варианты использования (use-case) ‑ это последовательности действий, выполняемых программной системой для получения наблюдаемого результата.
Весь процесс разработки программной системы рассматривается в RUP как процесс создания артефактов. Причем то, что попадает в руки конечного пользователя, будь то программный модуль или программная документация, — это один из подклассов всех артефактов проекта.
Каждый член проектной группы создает свои артефакты и несет за них ответственность. Программист разрабатывает программу, руководитель — проектный план, а аналитик — модели системы. RUP позволяет определить, когда, кому и какой артефакт необходимо создать.
(а)
(б)
Рис. 7.2. Унифицированный процесс разработки ПО (а ‑ абстрактное представление, б – развёрнутое представление основных процессов RUP)
Однако, RUP ‑ это больше чем единичный процесс, это обобщенный каркас процесса, который может быть специализирован для широкого круга программных систем, различных областей применения, уровней компетенции и размеров проекта. RUP ‑ компонентно-ориентирован. Это означает, что создаваемая программная система строится на основе программных компонентов, связанных хорошо определенными интерфейсами.
Для разработки графических представлений (моделей) программной системы RUP использует Унифицированный Язык Моделирования (UML). Фактически UML является неотъемлемой частью RUP ‑ они и разрабатывались совместно.
Однако действительно специфичные аспекты RUP-процесса заключаются в трех словосочетаниях — управляемый вариантами использования, архитектурно-ориентированный, итеративный и инкрементный. Это то, что делает Унифицированный процесс уникальным.
Полное представление программной системы в RUP включает девять моделей, которые совместно охватывают все важнейшие решения относительно визуализации, специфицирования, конструирования и документирования программной системы (рис 7.3):
модель бизнес-процессов, которая формализует абстракцию организации (со всеми вариантами использования управляющей ПС и их связями с пользователями);
модель прецедентов - формализует функциональные требования к системе ;
модель предметной области или бизнес-модель, описывающую контекст системы.
модель анализа, которая имеет две цели — уточнить детали вариантов использования и создать первичное распределение поведения системы по набору объектов, предоставляющих различные варианты поведения;
модель процессов (необязательная) - формализует механизмы параллелизма и синхронизации в системе;
модель проектирования, которая определяет: (а) ‑ статическую структуру системы, такую, как подсистемы, классы и интерфейсы, и (b) ‑ варианты использования, реализованные в виде коопераций между подсистемами, классами и интерфейсами;
модель реализации, которая включает в себя компоненты (представленные исходным кодом) и раскладку классов по компонентам;
модель развертывания, которая определяет физические компьютеры — узлы сети и раскладку компонентов по этим узлам;
модель тестирования, которая описывает варианты тестов для проверки вариантов использования;
Рис. 7.3. Модели RUP (в форме соответствующих UML-диаграмм) и их связи, [18]
Все эти модели связаны. Вместе они полностью описывают программную систему. Элементы одной модели имеют трассировочные зависимости вперед и назад, организуемые с помощью связей с другими моделями (см. рис. 7.3). Например, вариант использования (в модели вариантов использования) может быть оттрассирован на соответствующую реализацию варианта использования (в модели проектирования) и вариант тестирования (в модели тестирования). Трассировка облегчает понимание и внесение изменений. UML-диаграммы, созданные в процессе RUP-разработки, дают полное представление о программном продукте).
Основной упор в RUP делается не на подготовку документов как таковых, а на моделирование разрабатываемой системы. Модели помогают очерчивать как проблему, так и пути ее решения, а создаются они при помощи языка UML, который давно уже стал стандартом де-факто для описания сложных систем и позволяет разработчикам определять, визуализировать, конструировать и документировать артефакты программных систем любой сложности.