САПРы и ситуативная инженерия методов
Мне кажется, что я уже неоднократно описывал эту архитектуру (см. хотя бы http://ailev.livejournal.com/757999.html), но сегодня выяснилось, что этих описаний недостаточно: нужны дополнительные группы описаний, адресующие дополнительные интересы потенциальных заинтересованных сторон. Так, приведу группу описаний, раскрывающее интересы по использованию предлагаемой архитектуры -- причем намеренно не фиксируя наименования компонент, а давая множество синонимов для пущей понятности и отвязывания от конкретной реализации.
Сегодняшние САПР (системы автоматизации ПPроектирования, ПРрограммирования, ПPроизводства, а также я сюда включаю EAM, ERP и так все корпоративные IT-системы) представляют собой распределенный набор редакторов DSL (workbenches, IDE, модули, обработчики), надстроенных над (возможно, распределенной) базой данных, хранящей модель разрабатываемой и/или изготавливаемой системы.
В некоторых САПР (например, Dassault Systemes V6, основанной на хранилище данных MatrixOne) эти модули/обработчики/редакторы_спецязыков (описания геометрии CATIA, описания коллаборации DELMIA и т.д.) основаны на SOA-архитектуре.
Подключение новых обработчиков/редакторов_верстаков по договоренности разработчиков всех этих систем происходит по ISO 15926, причем интерфейс тут вебсервисов (RDF и triple store, запросы SPARQL) -- это единственный на сегодня вариант полноценного обмена сложными данными, который позволяет передать все необходимые данные (геометрию, расчетные модели, описание workflow и т.д.) между САПР, а не только их часть.
Возьмем эту архитектуру за прототип.
То, что я все время предлагаю -- так это:
1. в явном виде иметь описание этой SOA-архитектуры. Ибо сегодня обеспечение совместной работы огромного (порядка 200) модулей современных САПР, в которых отнюдь не все модули относятся к одному поставщику, представляет собой искусство, а не инженерию. Нужно иметь отдельный артефакт: описание сервис-ориентированной архитектуры компонентов САПР, связанных друг с другом. Это описание, понятное дело, должно храниться в общей модели и использоваться для целей конфигурирования.
Для этой цели нужно иметь набор DSL для описания SOA и редактор (IDE) для редактирования этого описания. Как происходит потом использование этого описания для целей конфигурирования всей САПР-инфраструктуры -- отдельная история (но обычно САПР умеют использовать описания, данные в терминах их собственной модели).
Этот редактор (IDE) для группы описаний (view) SOA можно включить в состав модулей САПР точно так же, как включается редактор P&ID для группы описаний гидравлики в трубопроводах, редактор 3D (геометрии) для группы описаний формы деталей и их пространственной сборки, редактор описания проекта ("модуль управления проектом") для группы описаний разбиения работ и их ресурсного обеспечения, редактор требований ("модуль управления требованиями") для группы описания требований и т.д.
Согласно практики интегрирования данных жизненного цикла, это "включение в состав модулей" достигается путем
а) учета SOA-архитектуры общей IT-системы (модулей САПР различных поставщиков, хранилищ данных, модулей EAM и т.д.)
b) интегрирования данных жизненного цикла с данными, использующимися другими модулями (понимаемыми в этой группе описаний либо как сервисы, либо как обращающимися к нашему IDE как сервису) согласно стандарту ISO 15926
2. в явном виде нужно иметь описание процесса коллективной работы (как коллектива программ-модулей, так и коллектива людей-в-ролях) с этим комплексом САПР. Для этого нужно применить ситуативную инженерию методов. Это означает, что существует некоторый набор методов (коллаборативной) работы людей с модулями САПР, являющийся конкретизацией какого-то варианта описания жизненного цикла и его практик (т.е. варианта "методологии") для данной а) системы, б) стадии жизненного цикла, в) набора используемых САПР. Это традиционная постановка задачи ситуативной инженерии методов, и тут существуют развитые метамодели для этого описания (например, SPEM, ISO 24744, ADOM и т.д.).
Нужно иметь качественный редактор (IDE)для набора DSL, реализующего метамодель описания методов и поддерживающего ситуационную инженерию метода -- все эти адаптированные к ситуации "руководства", описания ролей и назначения их обязанностей, выделение отдельных методов работы и прописывание их места в развертке во времени, и т.д. и т.п., что традиционно входит в группу описаний (view) ситуационной инженерии методов.
Этот редактор (IDE) для ситуативной инженерии методов включается в общий набор сервисов различных модулей IT-системы точно так же, как и редактор (IDE) для SOA -- с использованием интеграции данных по ISO 15926.
Тем самым у нас возникает ситуация, когда мы можем использовать ситуативную инженерию методов для того, чтобы наладить процесс работы с развернутым комплексом САПР.
Сегодня эта задача описывается как "разработка workflow для данной проектной организации". Существуют отдельно редакторы workflow, которые крайне специфичны для разных САПР и никак не связаны с набором руководств, которым должны следовать люди. Существуют различные средства для инженерии методов (та же Business Studio из популярных в силу своей простоты). Существуют средства управления проектами, поддерживающими представление жизненного цикла (а не процессное, как для workflow). И никакого шанса на интеграцию всех этих средств.
Шанс появляется, если мы используем
а) понимание, что для работы со всеми этими средствами нам нужно множество групп описаний жизненного цикла (методов, самого жизненного цикла, используемой инфраструктуры-сервисов и т.д.)
б) эти группы описаний должны быть подготовлены редакторами (IDE) в общей среде моделирования
в) общность среды моделирования может быть обеспечена за счет использования SOA-архитектуры и интеграции данных с внешней библиотекой справочных данных, т.е. подхода ISO 15926.
Я понимаю, что все эти вопросы обсуждаются в рамках Enterprise Architecture, но для меня эта линия рассуждения пока не важна -- не будем сейчас умножать число сущностей без надобностей, а про EA напишем когда-нибудь отдельный пост.
Сегодняшние САПР (системы автоматизации ПPроектирования, ПРрограммирования, ПPроизводства, а также я сюда включаю EAM, ERP и так все корпоративные IT-системы) представляют собой распределенный набор редакторов DSL (workbenches, IDE, модули, обработчики), надстроенных над (возможно, распределенной) базой данных, хранящей модель разрабатываемой и/или изготавливаемой системы.
В некоторых САПР (например, Dassault Systemes V6, основанной на хранилище данных MatrixOne) эти модули/обработчики/редакторы_спецязыков (описания геометрии CATIA, описания коллаборации DELMIA и т.д.) основаны на SOA-архитектуре.
Подключение новых обработчиков/редакторов_верстаков по договоренности разработчиков всех этих систем происходит по ISO 15926, причем интерфейс тут вебсервисов (RDF и triple store, запросы SPARQL) -- это единственный на сегодня вариант полноценного обмена сложными данными, который позволяет передать все необходимые данные (геометрию, расчетные модели, описание workflow и т.д.) между САПР, а не только их часть.
Возьмем эту архитектуру за прототип.
То, что я все время предлагаю -- так это:
1. в явном виде иметь описание этой SOA-архитектуры. Ибо сегодня обеспечение совместной работы огромного (порядка 200) модулей современных САПР, в которых отнюдь не все модули относятся к одному поставщику, представляет собой искусство, а не инженерию. Нужно иметь отдельный артефакт: описание сервис-ориентированной архитектуры компонентов САПР, связанных друг с другом. Это описание, понятное дело, должно храниться в общей модели и использоваться для целей конфигурирования.
Для этой цели нужно иметь набор DSL для описания SOA и редактор (IDE) для редактирования этого описания. Как происходит потом использование этого описания для целей конфигурирования всей САПР-инфраструктуры -- отдельная история (но обычно САПР умеют использовать описания, данные в терминах их собственной модели).
Этот редактор (IDE) для группы описаний (view) SOA можно включить в состав модулей САПР точно так же, как включается редактор P&ID для группы описаний гидравлики в трубопроводах, редактор 3D (геометрии) для группы описаний формы деталей и их пространственной сборки, редактор описания проекта ("модуль управления проектом") для группы описаний разбиения работ и их ресурсного обеспечения, редактор требований ("модуль управления требованиями") для группы описания требований и т.д.
Согласно практики интегрирования данных жизненного цикла, это "включение в состав модулей" достигается путем
а) учета SOA-архитектуры общей IT-системы (модулей САПР различных поставщиков, хранилищ данных, модулей EAM и т.д.)
b) интегрирования данных жизненного цикла с данными, использующимися другими модулями (понимаемыми в этой группе описаний либо как сервисы, либо как обращающимися к нашему IDE как сервису) согласно стандарту ISO 15926
2. в явном виде нужно иметь описание процесса коллективной работы (как коллектива программ-модулей, так и коллектива людей-в-ролях) с этим комплексом САПР. Для этого нужно применить ситуативную инженерию методов. Это означает, что существует некоторый набор методов (коллаборативной) работы людей с модулями САПР, являющийся конкретизацией какого-то варианта описания жизненного цикла и его практик (т.е. варианта "методологии") для данной а) системы, б) стадии жизненного цикла, в) набора используемых САПР. Это традиционная постановка задачи ситуативной инженерии методов, и тут существуют развитые метамодели для этого описания (например, SPEM, ISO 24744, ADOM и т.д.).
Нужно иметь качественный редактор (IDE)для набора DSL, реализующего метамодель описания методов и поддерживающего ситуационную инженерию метода -- все эти адаптированные к ситуации "руководства", описания ролей и назначения их обязанностей, выделение отдельных методов работы и прописывание их места в развертке во времени, и т.д. и т.п., что традиционно входит в группу описаний (view) ситуационной инженерии методов.
Этот редактор (IDE) для ситуативной инженерии методов включается в общий набор сервисов различных модулей IT-системы точно так же, как и редактор (IDE) для SOA -- с использованием интеграции данных по ISO 15926.
Тем самым у нас возникает ситуация, когда мы можем использовать ситуативную инженерию методов для того, чтобы наладить процесс работы с развернутым комплексом САПР.
Сегодня эта задача описывается как "разработка workflow для данной проектной организации". Существуют отдельно редакторы workflow, которые крайне специфичны для разных САПР и никак не связаны с набором руководств, которым должны следовать люди. Существуют различные средства для инженерии методов (та же Business Studio из популярных в силу своей простоты). Существуют средства управления проектами, поддерживающими представление жизненного цикла (а не процессное, как для workflow). И никакого шанса на интеграцию всех этих средств.
Шанс появляется, если мы используем
а) понимание, что для работы со всеми этими средствами нам нужно множество групп описаний жизненного цикла (методов, самого жизненного цикла, используемой инфраструктуры-сервисов и т.д.)
б) эти группы описаний должны быть подготовлены редакторами (IDE) в общей среде моделирования
в) общность среды моделирования может быть обеспечена за счет использования SOA-архитектуры и интеграции данных с внешней библиотекой справочных данных, т.е. подхода ISO 15926.
Я понимаю, что все эти вопросы обсуждаются в рамках Enterprise Architecture, но для меня эта линия рассуждения пока не важна -- не будем сейчас умножать число сущностей без надобностей, а про EA напишем когда-нибудь отдельный пост.