Модели и моделирование

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

В общем, модели можно классифицировать по различным критериям, например:

· формальные (использующие общепринятые правила, нотации и средства) и неформальные;

· количественные – позволяющие производить численные оценки и проверки, и качественные, предназначенные для понимания поведения и структуры системы;

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

Примерами качественных и описательных моделей являются:

· текстовые, использующие либо одну из формальных грамматик (пример – так называемые формы Бэкуса), либо обычный текст;

· визуальные модели, представляемые в виде диаграмм с определенной нотацией. Наиболее популярным языком для описания таких моделей программных систем в последнее время стал UML. Заметим, что, вообще говоря, даже эскизное изображение структуры или хода процесса, не обязательно соответствующее какому-либо стандарту, также может рассматриваться как модель – лишь бы оно могло быть использовано в нужном контексте для анализа или обсуждения проблемы.

Примерами количественных моделей могут служить:

· математические модели, которые могут быть описаны системами уравнений. Решение уравнений может быть в простейшем случае найдено в аналитической форме, в более сложных случаях применяются различные численные методы. Достаточно часто применяются электронные таблицы, с помощью которых могут быть проведены исследования типа " что – если". В зависимости от используемых средств эти модели могут быть исполняемыми или чисто описательными;

· динамические исполняемые модели, которые строятся с использованием специализированных программных или программно-технических средств и позволяют исследовать поведение описываемых ими объектов в различных внешних условиях. Модели последнего типа относятся к числу наиболее сложных и часто применяются на этапе выбора архитектуры сложных систем со многими элементами и связями, особенно когда поведение элементов описывается нелинейной или случайной функцией. Хотя разработка такой модели и проведение исследований требуют определенных затрат времени и ресурсов, во многих случаях применение таких моделей оказывается экономически обоснованным (см 6.7), а в отдельных областях, связанных с военными, космическими, ядерными и другими объектами такого рода – единственно возможным.

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

Предметом нашего анализа является архитектура предприятия в целом, которая представляет собой сложную систему взаимодействующих ИТ-ресурсов – их структурных компонент и взаимодействий между ними. Архитектура включает в себя стандарты, которые задают границы и направление работы разработчиков при создании и модификации систем. Как и во всех сложных системах, изменения в одной области могут приводить к изменениям во многих других областях.

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

Первым шагом в плане создания высокоуровневых моделей предприятия является создание моделей бизнес-процессов. Мы более подробно рассмотрим этот аспект в разделе, посвященном бизнес-архитектуре.

Разработка моделей для различных доменов (предметных областей) архитектуры является итерационным процессом, который связан с рассмотрением различных перспектив (уровней абстракции), а также связей между моделями отдельных доменов архитектуры. Например, на самом верхнем уровне описания контекста архитектуры для описания архитектуры информации могут использоваться списки бизнес-сущностей, таких как " счет", " клиент" и т.д., для архитектуры прикладных систем будет достаточно иметь список основных бизнес-процессов, а для технологической архитектуры – информации о местах расположения бизнеса.

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

Эти модели описывают архитектуру предприятия на различных уровнях абстракции, которые соответствуют " взглядам" на предприятие различных категорий людей. Процесс условно отображен в виде следующей таблицы, в которой в качестве иллюстрации приведены примеры возможных моделей для каждого домена архитектуры и каждого уровня абстракции [4.7]. Во-первых, заметим, что, по сути, это соответствует модели архитектуры Захмана, которая описана в 5.2. А во-вторых, с одной стороны, это список не является исчерпывающим, а с другой, на уровне описания архитектуры предприятия в целом, могут отсутствовать модели " нижних" уровней абстракции.

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

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

Таблица 5.1. Модели, используемые для различных представлений (доменов) и перспектив (уровней абстракции) описания Архитектуры предприятия
Домены	Бизнес-архитектура	Архитектура информации	Архитектура приложений	Технологическая архитектура
Перспекивы (уровни абстракции)
Контекст (" планировщик")	· Классы бизнес-процессов (группа процессов, имеющих много общих активностей) · Список бизнес-процессов	· Список бизнес-сущностей – объектов, важных для бизнеса (" клиент", счет") · Связи между сущностями (бизнес-объектами)	· Список бизнес-процессов	· Список мест расположения бизнеса
Концептуальный уровень(" владелец" предприятия)	· Сценарии использования (Use case) · Модели бизнес-процессов	· Семантические модели · Модели связей · Модели " сущность-связи"	· Разбиение процессов на сервисы	· Модели бизнес-логистики · Операционные (нефункциональные) требования · Архитектура расположения элементов центра обработки данных
Логический (" проектировщик")	· Модели процессов (потоков работ) · Модели бизнес-событий · Модель расположения процессов · Определения ролей	· Логические модели данных · Схемы данных · Спецификации документов	· Определения сервисов · Взаимосвязи между сервисами · Модели классов	· Логические типы серверов: БД, почтовые, транзакционные, … · Географическое распределение серверов · Хостируемое ПО
Физический (" разработчик")	· Спецификации процессов · Модели интеграции процессов · Описание ручных процедур · Стандарты качества	· Физические модели данных · Схемы БД · Код доступа к данным · Справочники данных	· Код программ · Описания интерфейсов (WSDL) · Расписания процессов · Код workflow	· Физические серверы · Топология фрагментов сети · Мапирование продуктов на сервисы и приложения

В качестве примера возьмем он-лайновую систему выполнения заказов некоторого гипотетического магазина. Для описания требований к системе, ее проектирования и разработки можно рассматривать динамические и статические модели на различных уровнях абстракции: уровень контекста, концептуальный, логический, физический уровни.

Рассмотрим вначале концептуальный уровень абстракции. Динамическая модель для этого уровня должна отражать взаимодействия между клиентом и магазином. При этом сама проектируемая система выступает как один из акторов процесса в качестве " черного ящика". Клиент и сотрудник(и) магазина выступают как внешние по отношению к системе акторы. Весь процесс рассматривается с точки зрения клиента и сотрудника. Клиент осуществляет заказ через Интернет. Оплата выполняется с помощью кредитной карты. Заказ посылается по указанному адресу. Уведомление о выполнении заказа посылается по электронной почте. Модель на самом высоком уровне описывает бизнес-процессы продавца и содержит простой сценарий использования (use case), описывающий взаимодействия между системой и акторами. Рисунок 5.5 иллюстрирует такую концептуальную динамическую модель и содержит простую нотацию сценария использования для этого бизнес-взаимодействия.

Рис. 5.5. Динамическая концептуальная модель процесса закупки товара

Статическая модель на этом уровне абстракции отражает структуру классов и связи между объектами, необходимость в которых становится очевидной при анализе динамической модели. Другими словами, она отвечает на вопрос " Какие объекты должен понимать клиент для того, чтобы выполнить транзакцию, связанную с покупкой? " Рисунок 5.6 показывает диаграмму классов, которая является статической концептуальной моделью.

Рис. 5.6. Статическая модель процесса закупки товара в магазине

Клиент является конкретной реализацией класса Человек. Связи между клиентом и магазином обеспечены наличием Учетной записи клиента. Все Заказы ассоциированы с Учетной записью. Заказ ассоциирован со всеми приобретаемыми Элементами заказа. Каждый элемент заказа является специфическим Продуктом, где Продукт сам по себе является классом. Наконец, каждый Платеж ассоциирован с некоторым Заказом.

Вообще говоря, современное состояние индустрии информационных технологий в области моделирования можно охарактеризовать как " время больших перемен". С одной стороны, такая некоммерческая организация как Object Management Group (OMG) находится в процессе реализации ряда инициатив, которые имеют непосредственное влияние на развитие технологий моделирования предприятия и его информационных систем. Эта организация выдвинула концепцию архитектуры, основанной на моделях (MDA – Model-Driven Architecture, см. лекции 7), развивает язык моделирования систем Unified Modelling Language (UML). При этом основная идея состоит в автоматизированном (насколько это возможно) процессе создания кода прикладных систем на основе разработанных моделей.

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

Решая более прагматичные задачи моделирования в интересах разработчиков систем, компания Microsoft, участвуя в работе OMG, в то же время выдвинула свою инициативу, связанную с моделированием информационных систем. Она основана на использовании языков DSL (Domain Specific Languages). Идея состоит в создании некоторого числа компактных, как правило, декларативных языков, предназначенных для описания различных предметных областей. Стратегия Microsoft состоит в использовании этих языков в рамках своих средств разработки (Visual Studio).

Примерами таких языков является язык описания бизнес-сущностей Business Entity DSL (например, " клиент", " заказ"), язык описания бизнес-процессов Business Process DSL (бизнес-активности, роли, зависимости), язык описания логической архитектуры систем Logical Systems Architecture DSL (описание конфигураций центров обработки данных), язык для описания web-сервисов Web Services DSL. При этом информация об одной модели может использоваться для создания другой модели. Примерами могут служить взаимодействие между моделями бизнес-сущностей и бизнес-процессов или между моделями web-сервисов и логическими серверами, на которых они будут размещены.

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

Возможным ограничением этого подхода является то, что создание таких моделей есть достаточно " техническая" работа, и вряд ли можно ожидать непосредственного участия бизнес-руководителя в их разработке. Просто этот подход ориентирован, в основном, на создание моделей системной архитектуры, т.е. на несколько иную аудиторию и круг задач.

Подводя итог этому краткому обсуждению вопросов моделирования в рамках архитектуры предприятия, можно сказать следующее:

· Нет и не стоит в ближайшее время ожидать одной, универсальной технологии создания моделей.

· Имеется достаточно большое количество методик и средств моделирования, которые могут успешно применяться для разработки моделей различных доменов Архитектуры предприятия.

·