Е.1. Объектно-ориентированное моделирование

 

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

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

Рис. 78. Инструменты моделирования

Рис. 79. Диаграмма действий и потоков объектов

При моделировании структуры первая и главная цель состоит в формировании классов. К сторонникам этой концепции относятся Коуд, Йордон, Рамбо, Шлаэр, Меллор.

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

При согласовании моделей процессов с поведением реальной системы ключевым моментом являются операции. Сторонники этой концепции — Мейер, Вирфс-Брок и Джекоб-сен. Хотелось бы особо отметить метод Use Case, разработанный Джекоб-сеном и группой других специалистов. Этот метод примечателен использованием концепции UML.

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

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

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

Заказ — это информационный объект. С другой стороны, это также показатель выхода, поэтому в данном случае представлен и поток информационных услуг. Хотя в целом подобная диаграмма охватывает все типы моделей (представлений) ARIS, здесь отсутствуют средства для классификации описательных элементов и расширения возможностей описания в рамках отдельных моделей. Для дополнительного сравнения на рис. 80 показана диаграмма действий и потоков объектов применительно к исходному примеру обработки заказа, приведенному на (рис. 3).

Неоспоримым достоинством объектно-ориентированного моделирования является тесная связь моделей с реализацией. Это предельно облегчает, например, создание прототипов.

Рис. 80. Представление процесса «обработка заказа» (см. рис. 3) в виде диаграммы действий и потоков объектов

Рис. 81. Архитектура моделирования CIMOSA (куб CIMOSA)

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

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

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

Мы ни в какой мере не хотим противопоставлять ARIS объектно-ориентированному моделированию. Напротив, при разработке специальных систем методом объектно-ориентированного моделирования целесообразно использовать и различные типы представлений ARIS — хотя бы в силу того, что архитектура ARIS больше сфокусирована на аспектах бизнеса, а ее представления (модели) более понятны.

 

Е.2. Архитектура CIMOSA

 

В рамках программы ESPRIT, финансируемой Европейским Союзом (ЕС), осуществлено несколько исследовательских проектов по разработке архитектуры открытых систем (CIMOSA) для компьютеризованных систем управления производством (CIM). Первоначально в проекте CIMOSA участвовало 30 организаций, среди которых были производственники в качестве пользователей, разработчики ИТ и исследовательские институты. Хотя в прикладном отношении проект был ориентирован на системы CIM, его стратегическая задача заключалась в получении результатов для общего моделирования предприятий. Одной из целей CIMOSA была разработка архитектуры и методологии для создания систем, ориентированных на конкретного потребителя, путем «стыковки» стандартизованных модулей CIM независимо от их производителей (принцип «Plug and Play»).

Инфраструктура моделирования CIMOSA представляется в форме куба (см. рис. 81).

Архитектура CIMOSA — трехмерная. Каждое из трех измерений представлено одной из осей куба. На вертикальной оси («ступенчатая деривация») представлены три уровня описания фазовой концепции: определение требований, спецификация проекта и описание реализации. Эти уровни в значительной мере идентичны фазам жизненного цикла ARIS.

Горизонтальная ось («поэтапная конкретизация») описывает последовательную индивидуализацию понятий. На первом этапе определяются базовые требования (общие требования, стандартные блоки), которые на следующем, втором этапе конкретизируются с учетом специфики отрасли (частные требования), а на третьем этапе дифференцируются применительно к специфике предприятия (конкретные требования).

Рис. 82. Типы моделей в архитектуре IFIP

Эта «проекция» наглядно показывает, что, согласно концепции CIMOSA, общие стандартные блоки следует использовать для определения стандартов, после чего блоки группируются в модели-прототипы для конкретных отраслей. На последнем этапе они используются для выработки решений, предназначенных для конкретных организаций. В инфраструктуре ARIS степень детализации информационной модели определяется при решении вопросов структурирования.

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

Третья ось («поэтапная генерация») описывает различные типы моделей информационной системы. Цели этой «проекции» аналогичны целям ARIS: речь здесь тоже идет о создании типов описаний, хотя результаты не во всем тождественны. В архитектуре CIMOSA типы описания подразделяются на «модель функций», «информационную модель», «модель ресурсов» и «организационную модель». «Модель функций» представляет собой описание событий, хотя она также охватывает другие элементы, такие как события и процессы, включая выполнение и обработку исключений. «Информационная модель» относится к представлению данных или описанию объектов. «Модель ресурсов» описывает ИТ и производственные ресурсы, а «организационная модель» — организационную иерархию.

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

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

Несмотря на внушительные затраты финансовых и интеллектуальных ресурсов, практическая отдача CIMOSA пока минимальна. Судя по сообщениям пользователей из реального бизнеса, участвующих в проекте, число специальных приложений, разработанных при помощи этой архитектуры, еще крайне незначительно. Исключение составляют автомобильная компания Renault, внедрившая прикладную систему для ремонтного обслуживания производственных установок, и компания TRAUB AG, внедрившая прикладную систему для оптимизации индивидуальной разработки инструментов. На сегодняшний день инструментальные средства моделирования на базе CIMOSA не нашли широкого практического применения.

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