Рисунок 1. Фрагмент модели моста

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

• Отличие свойств фактических материалов от проектных
• Погрешности методов конструирования
• Эффекты масштабирования и т.д.

Да, в конце концов, и "эффект понедельника" пока никто не отменял!

Рисунок 2. Семантический промежуток между моделью технической системы и ее реализацией

Наличие этого семантического промежутка может привести к серьезным ошибкам в реализации.

Замечательное свойство моделей в области программного обеспечения

Вернемся к началу этой главы: что же это за таинственное "Но…"?

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

Управляемая моделью архитектура

Осознание "замечательного свойства моделей ПО" и современный опыт использования моделирования не могли не натолкнуть специалистов индустрии на идею управляемой моделью архитектуры (Model Driven Architecture – MDA).

MDA – это набор открытых стандартов OMG. В основе представления OMG на MDA лежат, в частности, следующиее принципы:

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

OMG идентифицировала четыре типа моделей для MDA:

Рисунок 3. Типы моделей для MDA

Интегрированное моделирование предприятия как расширение концепции MDA

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

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

Без "ложки дегтя" не обойтись. Серебряную пулю MDA тоже не предлагает.

1. Множество моделей ПО (в интересующем нас случае – предприятия) должны уметь "разговаривать" между собой (имеются ввиду преобразования "модель-модель") на общем языке.
2. Реальная жизнь многообразна! Невозможно представить, что поставщики инструментов и технологий разработают и поставят структуры моделей и преобразования "модель-модель", пригодные всегда для всех случаев жизни.
3. Существующие инструменты, обеспечивающие возможности MDA (а при соответствующей доработке – и интегрированного моделирования и управления) сегодня дороги.

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

Ну, и что же делать?

А я решил попробовать!

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

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

Некоторые технические детали:

Базовые методы и технологии

В качестве главного методологического источника, который будет направлять мою работу, избран TOGAF, версия 9.1.

Причин несколько:

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

Другие методические источники включают RUP, библиотеки лучших практик в формате SPEM 2 от IBM и EPF, доступные статьи из интернета.

Рабочие инструменты

Главный рабочий инструмент – IBM Rational Software Architect (RSA).

На RSA можно делать почти все, по крайней мере, пока команду разработчиков представляю я один: создавать профили UML, шаблоны, мастера, преобразования и даже управлять процессом разработки, если уметь. К сожалению, невозможно настоящее управление активами предприятия, для этого нужен IBM Rational Asset Manager (RAM). Но моделировать управление активами можно. А когда понадобится управлять активами, может быть и спонсор найдется&

Другие инструменты – генератор отчетов BIRT и инструмент описания процессов RMC.

Все перечисленные инструменты интегрированы.

Языки разработки

Принимается единственный язык моделирования – UML.

В RSA включено большое число профилей UML для моделирования в специфических прикладных областях.
Некоторые профили придется разрабатывать. В основном, для экзотических диаграмм, перечисленных в спецификации TOGAF.

Основную разработку инструментальных средств (профилей, мастеров, преобразований) можно выполнять в графическом режиме. Для программирования всяких тонкостей, не предусмотренных мастерами RSA, используется Java.

Заключение

Убежден, что создание технологии интегрированного моделирования и управления предприятием на основе "оконтуренных" принципов реально.

А кому это может быть нужно?

1. Крупным софтверным компаниям, которые смогут стать "фабриками" с отлаженным процессом и складами полуфабрикатов (справочными библиотеками)
2. Крупным производственным и торговым компаниям, которые несут потери из-за неповоротливости их IT служб
3. Специализированным консалтинговым компаниям, которые смогут сдавать в аренду ресурсы своих экземпляров реализации технологии, размещенных на доступных платформах ("в облаках"?)

Что касается меня, то для меня это почти мечта человечества – коммунизм – "свободный труд свободного человека".

Ближайшие планы – обеспечить полное моделирование для фазы "Подготовка". Правда, я не считаю это фазой. Я называю это "Определением предприятия". И следующая статья будет посвящена достаточно сложной концепции "Предприятие" и связанным концепциям.

Приглашаю к сотрудничеству всех желающих. Критикуйте. Предлагайте.

Серьезность моих намерений подтверждается, хотя бы, публикацией спецификации TOGAF на русском языке.

А сегодня я публикую модель профиля UML для архитектурного содержания TOGAF (см. часть 4, главу. 34 Спецификации). По индивидуальному заказу могу выслать профиль в формате обмена UML2. Он должен пониматься всеми инструментами UML, поддерживающими этот стандарт от OMG.

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

Спасибо всем, кто дочитал до этого места!

Л. Новиков
lnew@yandex.ru