Кирилл Лис (kir_lis) wrote,
Кирилл Лис
kir_lis

Метод Praxeme и место СОА в нем

Praxeme – это метод инженерии систем, а именно инженерии Enterprise Systems и их составляющих. Его авторы, методологи Dominique Vauquier и Pierre Bonnet, классифицируют Praxeme как «enterprise method». Метод в открытом доступе под лицензией Creative Commons, но много интересной информации пока еще только на французском языке (я его не знаю). Хотя в созданном Praxeme Institute (http://www.praxeme.org/) осознают важность распространения и постепенно занимаются переводом на английский.

Парадигма, лежащая в основе Praxeme, опирается на моделеориентированность, ориентацию на сервисы и управление жизненным циклом. Место, отведенное СОА в Praxeme, соответствует тому, как она позиционировалась при постановке задачи исследования (http://kir-lis.livejournal.com/289.html), т.е. в качестве промежуточного звена, снимающего зависимость потребностей бизнеса от деталей реализации. Поэтому имеет смысл покопать в этом направлении.

Отправная точка метода заключена в популярном вопросе: «Что должно описываться (моделироваться) в организации для того, чтобы она была более управляема, а ее функционирование приводило к положительному эффекту?». Постулируются принципы описания:

·         Реальность (система) должна рассматриваться с разных углов, которые соответствуют аспектам (aspects)

·         Реальность (система) должна описываться несколькими моделями, каждая из которых специализируется на отдельном аспекте

·         Есть набор аспектов, определенных методом.

Легко провести аналогию с ISO 42010 (ANSI/IEEE 1471-2000), но явно указывается на различие между view (группа описаний) и aspect. Группа описаний (view), связанная с конкретным типом акторов, может быть составлена из «информации, решений и элементов из разных аспектов». Далее предлагается Enterprise System Topology, в которой описывается связь аспектов, предлагаемых Praxeme (см. иллюстрацию ниже из [3]).



Upstream aspects. Отражают базовое знание о бизнесе, что он собой представляет, как организован, каковы цели, правила и ограничения. Никаких технических деталей и архитектур конкретных систем. Соответствует CIM из MDA. Показывает, что должно быть достигнуто. Архитектура бизнеса.

  • Semantic (conceptual, business essentials, basics). Описывает объекты реального мира, их связи между собой, их жизненный цикл (состояния и переходы), правила. Не включает в себя никаких организационных деталей (роли, действия)
  • Pragmatic (organizational). Описывает то, как объекты организованы для достижения целей. Организационные единицы, роли, полномочия, жизненный цикл системы, бизнес процессы, контекст выполнения работ
  • Geographic (contextual, communicational)

Downstream aspects. Техническая архитектура, реализация того, что должно быть достигнуто.

  • Technical (technological). Описание принимаемых технических решений
  • Software (application, IT). Включая веб-сервисы.
  • Hardware (logistics)
  • Physical (deployment). Маппинг софта на железо.

Logical aspect (functional). Располагается между Upstream и Downstream аспектами. Снимает зависимость архитектуры бизнеса от технической архитектуры. Именно здесь применяется СОА, в качестве стиля архитектурного проектирования. В рамках Praxeme могут применяться и другие стили.

 

В области СОА распространенными методами проектирования являются наборы лучших практик и эвристик. При таком подходе можно создать качественные системы, но затруднительно продемонстрировать, что набор сервисов был извлечен именно из потребностей бизнеса, а не является догадкой. Сторонники Praxeme утверждают, что множество сервисов может быть чуть ли не вычислено путем применения процедур, предлагаемых в рамках их метода. Для этого создателями метода принято несколько решений. Во-первых, ключевым является разделение Semantic и Pragmatic аспектов. Во-вторых, предлагается начинать проектирование с описания объектов, а не процессов. Утверждается, что начинать СОА-проект с тщательного изучения процессов организации является ошибкой. Ниже аргументация этих положений из презентации [3].

При моделировании выполняемой работы (activities) неизбежно делаются ссылки на объекты, поэтому некоторое моделирование данных будет обеспечено, в соответствии с этими указаниями. Но такой способ раскрытия объектов смешивает объекты разных типов, и, что критично для MDA, состояния объектов не распознаются и приравниваются к набору значений атрибутов. Более того, работы очень вариативны, зависят от культурных различий между отделами, от конкретных исполнителей, от темпа изменений в организации. Такая нестабильность не позволяет брать работы за основу архитектуры.

В Praxeme разделяют два вида объектов: Pragmatic (непосредственно поддерживают работы) и Semantic (сохраняют состояние организации). Утверждается, что надо начинать описывать систему именно с Semantic объектов. А уже из описаний их ЖЦ есть возможность сгенерировать значительное число работ из Pragmatic Aspect. Об этом не раз писал JJ Dubray (последний пост -  http://www.ebpml.org/blog2/index.php/2010/05/12/resource-lifecycles-and-rest) .

Из Semantic и Pragmatic аспектов порождается Logical аспект. Он включает в себя service models, flow models, data models. Сервисы не формируются в рамках интуитивного процесса, основанного на знаниях и навыках персонала, а выводятся из результатов моделирования на предыдущем этапе, что повышает коэффициент повторного использования. Flow models выводятся из переходов между состояниями бизнес-объектов в Semantic aspect. На рисунке ниже иллюстрация этой последовательности [3].

Порождение моделей главное преимущество Praxeme. Оно реализуется в соответствии с предлагаемыми процедурами.

 


 

Описание компонентов ПО (Software Packages) находится в Software aspect. Те вопросы, которые задаются авторами метода при решении задач интеграции существующих компонентов, аналогичны исследуемой проблеме. Какие объекты, какие функции покрывает компонент? Можем ли мы использовать только требуемые части пакета или нет? На эти вопросы могут дать ответы описания из Logical Aspect. Это даст возможность привести инфраструктуру ПО в соответствие с детяельностью организации.

 

К сожалению, нет документа с какой-либо метамоделью, нет определения сервиса. Но, скорее всего, сервис из Logical aspect соответствует именно способности (capability) выполнять какую-либо работу, а уже Software Aspect описывает механизм доступа к ней. Это к дискуссии OASIS SOA-RM TC об определении сервиса (http://kir-lis.livejournal.com/1493.html)

 

Из недостатков Praxeme можно отметить привязку к UML. Во всех документах пишется именно об этом языке. Возможно, предлагаемые процедуры порождения описаний тоже заточены под него. Пока не ясно, так как все по-французски. Буду смотреть другие доступные документы.

 

Материалы:

[1] http://www.praxeme.org/EnglishPage.html - страница с документами доступными на английском

[2] http://www.praxeme.org/DocumentsEnAnglais/SLB02-wp_EN.pdf Базовый документ с описанием метода (Introducing Praxeme ("Livre Blanc"))

[3] http://www.praxeme.org/DocumentsColleges/Instructeurs/AnIntroductionToTheMethodology.BH.2009.09.16.pdf - Презентация с комментариями к слайдам с описанием позиционирования СОА

[4] sustainableit.ifrance.com/ONSOAPXMOverviewBUsers.ppt презентация о применении Praxeme в инженерии СО-систем

Subscribe

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 2 comments