Промышленные каталоги методов
По сути, стандарт ISO/TS 8000-100:2009 описывает некоторый способ организации программирования (programming-in-the-large, в стандарте прямо указывается на то, что выполнение его требований задает компьютерные языки, и естественным языком тут не обойдешься) производства. В нем вводится классификация данных, в которой различается нормативно-справочная информация (НСИ, master data, http://ru.wikipedia.org/wiki/%D0%9D%D0%A1%D0%98) и текущая информация по проводимым организацией сделкам aka экземплярам процессов (transaction data, данные специфичные для endeavour):
Конечно, master data одной организации -- это transaction data для другой организации, всё зависит от позиции деятеля и ее группы описаний.
Методы, которые лежат в PraxOS -- это master data, в части ВидовРабот больше всего похожие на service, procedure or process masters. Как пишется в стандарте, "These masters are still relatively rare except in the health care and vehicle repair industries where automated billing for services or insurance reimbursement is common. Typically a service is best described as a procedure or a process". Оставим в стороне онтологические вопросы о связи метода, сервиса, процедуры (workflow) и практики/вида жизненного цикла (process) -- http://ailev.livejournal.com/849563.html
Кроме ВидовРабот, конечно, в методах есть еще и ВидыПродуктов (item or material master, item of supply concept, asset master и т.д.), и ВидыАкторов, которые много более распространены.
По сути, мы хотим из деталек (частей, parts) создавать методы. Для описания этих деталек служат промышленные каталоги.
PraxOS, по сути, представляет собой промышленный каталог -- только вместо описаний продуктов в нем лежат описания методов. Проблема в том, что описания методов не характеризуются (т.е описываются в терминах пар "свойство-значение") в рамках упрощенных каталожных стандартов, типа ISO 22745. Но создание каталога методов в ISO 15926 вполне возможно, причем в полном соответствии с ISO 8000.
Нужно только заметить, что ISO 15926 RDL одновременно представляет собой:
-- словарь (и это явно помянуто в ISO 8000:110 в таблице словарей Annex C)
-- спецификацию данных (хотя и не формата IG из ISO 22745), ибо в нем хранятся OIM
-- собственно каталог, ибо в нем хранятся информационные объекты (методы и части методов), характеризованные по OIM и соответствующие формальному синтаксису.
Это не единственный стандарт, в котором у одного набора данных (RDL -- это data set, логически упорядоченный набор данных) есть разные (в нашем случае три) функции. Набор данных по ISO 13584 (он же -- древний формат для каталога PLIB, part library, предшественник ISO 10303 aka STEP, из которого STEPLIB после переделки стала в итоге Gellish library) также представляет собой словарь и спецификацию данных (две функции).
Совсем необязательно держать все данные в одном флаконе, в одном RDL. ISO 15926 позволяет создать федерацию RDL, и разделить словарь и OIM на его основе, а также OIM и каталог частей (продуктов, работ с продолжительностью и без, акторов и инструментов, или методов как таковых). Или не разделять, имея ввиду это соответствие лишь для общения с окружающим инженерным миром и декларации соответствия стандартам.
В любом случае, требуется в явном виде договориться о том, как использовать в явном виде словарную и каталожную часть ISO 15926: все необходимые понятия там есть, только нужно договориться об их способе употребления. А спецификационная часть там присутствует, это OIM. Хотя и тут дополнительная определенность бы не помешала.
В данной архитектуре OIM 24744 (спецификация данных, метамодель) четко отделяется от каталога методов (модели методов и их частей/продукции и комплектующих), а каталог методов четко отделяется от transactional data из endeavour.
Похоже, что для описания всего этого месива концепций нужно будет иметь разные группы описаний, для которых разные группы стандартов задают разные методы описаний. Ну, и мэппинг между основными элементами, определяемые этими методами описаний (типа "метамодель в OMG = OIM в 15926 = спецификация данных в 8000".
В любом случае, нужно как-то вписываться в текущий контекст корпоративной информатизации и по максимуму задействовать признанную на производстве (а не в науке или в программировании) терминологию там, где она нам не мешает. Ориентироваться, конечно, нужно на международные стандарты. Судя по всему, они смоют всю отечественную систему ГОСТов лет за пять-семь.
Конечно, master data одной организации -- это transaction data для другой организации, всё зависит от позиции деятеля и ее группы описаний.
Методы, которые лежат в PraxOS -- это master data, в части ВидовРабот больше всего похожие на service, procedure or process masters. Как пишется в стандарте, "These masters are still relatively rare except in the health care and vehicle repair industries where automated billing for services or insurance reimbursement is common. Typically a service is best described as a procedure or a process". Оставим в стороне онтологические вопросы о связи метода, сервиса, процедуры (workflow) и практики/вида жизненного цикла (process) -- http://ailev.livejournal.com/849563.html
Кроме ВидовРабот, конечно, в методах есть еще и ВидыПродуктов (item or material master, item of supply concept, asset master и т.д.), и ВидыАкторов, которые много более распространены.
По сути, мы хотим из деталек (частей, parts) создавать методы. Для описания этих деталек служат промышленные каталоги.
PraxOS, по сути, представляет собой промышленный каталог -- только вместо описаний продуктов в нем лежат описания методов. Проблема в том, что описания методов не характеризуются (т.е описываются в терминах пар "свойство-значение") в рамках упрощенных каталожных стандартов, типа ISO 22745. Но создание каталога методов в ISO 15926 вполне возможно, причем в полном соответствии с ISO 8000.
Нужно только заметить, что ISO 15926 RDL одновременно представляет собой:
-- словарь (и это явно помянуто в ISO 8000:110 в таблице словарей Annex C)
-- спецификацию данных (хотя и не формата IG из ISO 22745), ибо в нем хранятся OIM
-- собственно каталог, ибо в нем хранятся информационные объекты (методы и части методов), характеризованные по OIM и соответствующие формальному синтаксису.
Это не единственный стандарт, в котором у одного набора данных (RDL -- это data set, логически упорядоченный набор данных) есть разные (в нашем случае три) функции. Набор данных по ISO 13584 (он же -- древний формат для каталога PLIB, part library, предшественник ISO 10303 aka STEP, из которого STEPLIB после переделки стала в итоге Gellish library) также представляет собой словарь и спецификацию данных (две функции).
Совсем необязательно держать все данные в одном флаконе, в одном RDL. ISO 15926 позволяет создать федерацию RDL, и разделить словарь и OIM на его основе, а также OIM и каталог частей (продуктов, работ с продолжительностью и без, акторов и инструментов, или методов как таковых). Или не разделять, имея ввиду это соответствие лишь для общения с окружающим инженерным миром и декларации соответствия стандартам.
В любом случае, требуется в явном виде договориться о том, как использовать в явном виде словарную и каталожную часть ISO 15926: все необходимые понятия там есть, только нужно договориться об их способе употребления. А спецификационная часть там присутствует, это OIM. Хотя и тут дополнительная определенность бы не помешала.
В данной архитектуре OIM 24744 (спецификация данных, метамодель) четко отделяется от каталога методов (модели методов и их частей/продукции и комплектующих), а каталог методов четко отделяется от transactional data из endeavour.
Похоже, что для описания всего этого месива концепций нужно будет иметь разные группы описаний, для которых разные группы стандартов задают разные методы описаний. Ну, и мэппинг между основными элементами, определяемые этими методами описаний (типа "метамодель в OMG = OIM в 15926 = спецификация данных в 8000".
В любом случае, нужно как-то вписываться в текущий контекст корпоративной информатизации и по максимуму задействовать признанную на производстве (а не в науке или в программировании) терминологию там, где она нам не мешает. Ориентироваться, конечно, нужно на международные стандарты. Судя по всему, они смоют всю отечественную систему ГОСТов лет за пять-семь.