архитектура предприятий

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

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

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

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

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

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

Вообще говоря, современное состояние индустрии информационных технологий в области моделирования можно охарактеризовать как "время больших перемен". С одной стороны, такая некоммерческая организация как Object Management Group (OMG) находится в процессе реализации ряда инициатив, которые имеют непосредственное влияние на развитие технологий моделирования предприятия и его информационных систем. Эта организация выдвинула концепцию архитектуры, основанной на моделях (MDA – Model-Driven Architecture, см. "Технологическая архитектура, стандарты и шаблоны" ), развивает язык моделирования систем 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-сервисов и логическими серверами, на которых они будут размещены.

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

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

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

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

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