Закон ОМа: описание [практики] постановки [метода] инженерии схемы данных жизненного цикла
Поскольку объекты мира задаются главным образом через набор операций с ними ("вот это стул -- на нём сидят, вот это стол -- за ним едят"), то каждый онтолет подразумевает какое-то "руководство по эксплуатации", то есть методы действий (каталог компонентов методов) в данной предметной области. СМДМ-методологи обсуждают этот момент как обязательное наличие "двух досок" -- одна объектно-онтологическая (предметная), другая -- оргдеятельностная. На деятельностной доске задаются функциональные свойства объектов, на онтологической доске -- "что такое" эти объекты. Единство Онтолетного и Методологического я бы назвал законом OMа. Развитие предметной области -- это когда онтология и деятельность вдруг расходятся: обнаруживается, что действия производятся (дела идут) не с обозначенными в онтолете продуктами, или (что то же самое) оказывается, что обозначенные в онтолете продукты никем не используются, и происходит что-то другое.
Связь онтолета (как онтологического описания -- и дальше я традиционно не буду различать онтологию и онтологическое описание, метод и описание метода) и описания метода проявляется очень просто: каждый объект, помянутый в методе, должен быть типизирован. Под "типизацией" я имею ввиду не только классификацию его к понятиям Части 2, но и к понятиям расширенной онтолетом Части 4.
Тут есть свои:
Плюсы:
-- если писать не "Вася", а "тигр Вася"; не "тигр", а "игрушка тигр", то это делает текст много понятней и предотвращает ошибки (как и любая работа с типизацией).
-- очевидно соответствие стандартным классам (но только в том случае, если читатель догадывается о существовании стандарта. Если не догадывается -- то беда). Легко декларировать соответствие стандартам.
-- если объект классифицирован в разных классах (или классах классов), то указание типа указывает также на ту классификацию, которая используется в данном контексте.
-- если речь идет о каких-то кодифицированных объектах, то указание типа позволяет хоть как-то обращаться к этим объектам: "табельный номер 2345" явно лучше "2345", а "артикул 2345" понятней, чем просто "2345".
Минусы:
-- тексты распухают, язык изложения стремительно превращается в канцелярит, немедленно возникает нужда в динамической/вычислимой типизации, что проблематично выразить, и т.д.
-- совершенно неочевидно соответствие стандартным классам, соответствие стандартам превращается в отдельное мероприятие, включающее демонстрацию явного мэппинга.
В ISO 15288 декларирование типа вылезает в заголовки. Так, все 25 processes этого стандарта имеют намеренное решение тип (process) включить в заголовок с именем конкретной практики, но в оглавлении это выглядит совершенно избыточным (так, я снял эту типизацию в переводе -- а сейчас вновь задумался, не вернуть ли её). Другой пример из стандартов ISO 15288 -- это рекомендация добавлять тип "система", когда подчеркивается использование системного подхода, например, вместо "самолёт" говорить "система самолёт". Я с этой рекомендацией не соглашаюсь обычно ("всё есть системы, так зачем это каждый раз говорить?"), но сегодня в очередной раз задумался над пользой принудительной типизации.
Выходом из ситуации могли бы быть технические решения: рендеринг метода как "аннотированного типами", так и "неаннотированного типами" в зависимости от желаний читателя (это будут разные группы описаний, обслуживающие разные интересы заинтересованных сторон). Беда в том, что надлежащего инструментария аннотирования сейчас нет, и приходится принимать решения в каждом конкретном случае.
Компромиссным вариантом является "декларирование типа" -- как в языках программирования, типизация показывается явно при первом употреблении объекта. В моём вчерашнем постинге я использовал такой подход к типизации, указывая "практики дисциплины" (заодно указав и отношение композиции дисцилины из практик, и тип "практики" для списка индивидуальных практик дисциплин, и указав тип "дисциплина" для индивидуальных методов типа "Инженерия схемы данных жизненного цикла"). Ежели идти дальше, то для типов нужно указать, из какого онтолета они пришли -- "практика" пришла в явном виде из ISO 24744 (там это process), а "дисциплина" -- путем обобщения разных наборов практик (что отражалось в различных "дисциплинах системной инженерии" -- "дисциплина инженерии требований", "дисциплина инженерии системной архитектуры"). Тут я просто обобщил "практику" вверх до "дисциплины" (а не только вниз до уровня "мероприятия" и "дела", как это делается в онтолете ISO 24774).
Пример с дисциплиной (вновь введенное понятие), практикой (использующейся как в ISO 24744, так и в ISO 24744), мероприятием (использующимся только в 24774 для более мелких практик) и делом (использующимся опять таки как мельчайшая единица как в ISO 24744 и ISO 24774) показывает, что нам не обойтись для моделирования метода собственным онтолетом, который должен входить в .15926O.
Но это не даёт ответа на вопрос, как рэндерить эту типизацию. В отдельном постинге (http://community.livejournal.com/dot15926/16745.html) я выполню упражнение по описанию/рендерингу/представлению практики постановки метода инженерии схемы данных жизненного цикла (которая, по идее, должна быть "специализацией" практики "постановка метода" в дисциплине "ситуационная инженерия методов" -- примерно в том же смысле, в котором мы говорим о "специализации шаблонов").
В качестве упражнения: опустим типы из ISO 24744/24774 в предыдущем предложении -- смысл ведь не изменится! "В отдельном постинге (http://community.livejournal.com/dot15926/16745.html) я выполню упражнение по описанию постановки инженерии схемы данных жизненного цикла (которая, по идее, должна быть специализацией постановки в ситуационной инженерии методов -- примерно в том же смысле, в котором мы говорим о "специализации шаблонов")". Интересно, сколько людей сочтет "более понятным" типизированный вариант, а сколько нетипизированный?
Этот пример также даст понимание, как может выглядеть описание (рендеринг) методологии в части описания практик (я, правда, не понимаю, правильно ли публиковать это в dot15926, ибо речь идет явно об организационной практике -- а тогда это должно идти в praxos. Типичный пример двойной классификации). Обратите внимание, что многие формулировки и типы в этом примере предписаны ISO 24774 (практики, мероприятия, способ нумерации и т.д.), но существенно также используется типизация по ISO 24744 (даже слово "метод" -- это тоже тип к "инженерии схемы данных", наряду с "продуктами работ") -- но не думаю, что требуется как-то специально обозначать эти пространства имён. Всякие объяснения выбранной терминологии тоже опущены (так, "инженерия схема данных" подразумевает прохождение целевой системы схемы данных по полному жизненному циклу -- от замысла и определения пользовательских потребностей до валидации и эксплуатации. "Разработка" же обычно ассоциируется с более коротким жизненным циклом проекта, заканчивающимся на проектировании -- невзирая на совпадение "проектирования" и "изготовления" для информационных продуктов). "Многоуровневые типизации" и "буквальные типизации" (типа "шаблон практики постановки..." -- чтобы показать, что тип "постановки метода инженерии" в ISO 24744 будет не "process", а "ProcessKind", или использование "метод" как обозначение того целого из практик-продуктов-организации, что подлежит постановке) я старался не использовать. Интересно было бы получить замечания, где дополнительная типизация была бы полезна и уместна (а где, наоброт, осталась лишняя). В целом, "остаточная типизация" следует ISO 24774, как ее можно обнаружить в ISO 15288, взятом за образец предлагаемого описания/рендеринга. Заодно в качестве побочного эффекта мы получаем текст "процессного стандарта", выполнение которого можно проверять по ISO 15504 (SPICE), ибо такой текст читается как "описание типового процесса" (reference process model) в смысле этого стандарта оценки соответствия.
Связь онтолета (как онтологического описания -- и дальше я традиционно не буду различать онтологию и онтологическое описание, метод и описание метода) и описания метода проявляется очень просто: каждый объект, помянутый в методе, должен быть типизирован. Под "типизацией" я имею ввиду не только классификацию его к понятиям Части 2, но и к понятиям расширенной онтолетом Части 4.
Тут есть свои:
Плюсы:
-- если писать не "Вася", а "тигр Вася"; не "тигр", а "игрушка тигр", то это делает текст много понятней и предотвращает ошибки (как и любая работа с типизацией).
-- очевидно соответствие стандартным классам (но только в том случае, если читатель догадывается о существовании стандарта. Если не догадывается -- то беда). Легко декларировать соответствие стандартам.
-- если объект классифицирован в разных классах (или классах классов), то указание типа указывает также на ту классификацию, которая используется в данном контексте.
-- если речь идет о каких-то кодифицированных объектах, то указание типа позволяет хоть как-то обращаться к этим объектам: "табельный номер 2345" явно лучше "2345", а "артикул 2345" понятней, чем просто "2345".
Минусы:
-- тексты распухают, язык изложения стремительно превращается в канцелярит, немедленно возникает нужда в динамической/вычислимой типизации, что проблематично выразить, и т.д.
-- совершенно неочевидно соответствие стандартным классам, соответствие стандартам превращается в отдельное мероприятие, включающее демонстрацию явного мэппинга.
В ISO 15288 декларирование типа вылезает в заголовки. Так, все 25 processes этого стандарта имеют намеренное решение тип (process) включить в заголовок с именем конкретной практики, но в оглавлении это выглядит совершенно избыточным (так, я снял эту типизацию в переводе -- а сейчас вновь задумался, не вернуть ли её). Другой пример из стандартов ISO 15288 -- это рекомендация добавлять тип "система", когда подчеркивается использование системного подхода, например, вместо "самолёт" говорить "система самолёт". Я с этой рекомендацией не соглашаюсь обычно ("всё есть системы, так зачем это каждый раз говорить?"), но сегодня в очередной раз задумался над пользой принудительной типизации.
Выходом из ситуации могли бы быть технические решения: рендеринг метода как "аннотированного типами", так и "неаннотированного типами" в зависимости от желаний читателя (это будут разные группы описаний, обслуживающие разные интересы заинтересованных сторон). Беда в том, что надлежащего инструментария аннотирования сейчас нет, и приходится принимать решения в каждом конкретном случае.
Компромиссным вариантом является "декларирование типа" -- как в языках программирования, типизация показывается явно при первом употреблении объекта. В моём вчерашнем постинге я использовал такой подход к типизации, указывая "практики дисциплины" (заодно указав и отношение композиции дисцилины из практик, и тип "практики" для списка индивидуальных практик дисциплин, и указав тип "дисциплина" для индивидуальных методов типа "Инженерия схемы данных жизненного цикла"). Ежели идти дальше, то для типов нужно указать, из какого онтолета они пришли -- "практика" пришла в явном виде из ISO 24744 (там это process), а "дисциплина" -- путем обобщения разных наборов практик (что отражалось в различных "дисциплинах системной инженерии" -- "дисциплина инженерии требований", "дисциплина инженерии системной архитектуры"). Тут я просто обобщил "практику" вверх до "дисциплины" (а не только вниз до уровня "мероприятия" и "дела", как это делается в онтолете ISO 24774).
Пример с дисциплиной (вновь введенное понятие), практикой (использующейся как в ISO 24744, так и в ISO 24744), мероприятием (использующимся только в 24774 для более мелких практик) и делом (использующимся опять таки как мельчайшая единица как в ISO 24744 и ISO 24774) показывает, что нам не обойтись для моделирования метода собственным онтолетом, который должен входить в .15926O.
Но это не даёт ответа на вопрос, как рэндерить эту типизацию. В отдельном постинге (http://community.livejournal.com/dot15926/16745.html) я выполню упражнение по описанию/рендерингу/представлению практики постановки метода инженерии схемы данных жизненного цикла (которая, по идее, должна быть "специализацией" практики "постановка метода" в дисциплине "ситуационная инженерия методов" -- примерно в том же смысле, в котором мы говорим о "специализации шаблонов").
В качестве упражнения: опустим типы из ISO 24744/24774 в предыдущем предложении -- смысл ведь не изменится! "В отдельном постинге (http://community.livejournal.com/dot15926/16745.html) я выполню упражнение по описанию постановки инженерии схемы данных жизненного цикла (которая, по идее, должна быть специализацией постановки в ситуационной инженерии методов -- примерно в том же смысле, в котором мы говорим о "специализации шаблонов")". Интересно, сколько людей сочтет "более понятным" типизированный вариант, а сколько нетипизированный?
Этот пример также даст понимание, как может выглядеть описание (рендеринг) методологии в части описания практик (я, правда, не понимаю, правильно ли публиковать это в dot15926, ибо речь идет явно об организационной практике -- а тогда это должно идти в praxos. Типичный пример двойной классификации). Обратите внимание, что многие формулировки и типы в этом примере предписаны ISO 24774 (практики, мероприятия, способ нумерации и т.д.), но существенно также используется типизация по ISO 24744 (даже слово "метод" -- это тоже тип к "инженерии схемы данных", наряду с "продуктами работ") -- но не думаю, что требуется как-то специально обозначать эти пространства имён. Всякие объяснения выбранной терминологии тоже опущены (так, "инженерия схема данных" подразумевает прохождение целевой системы схемы данных по полному жизненному циклу -- от замысла и определения пользовательских потребностей до валидации и эксплуатации. "Разработка" же обычно ассоциируется с более коротким жизненным циклом проекта, заканчивающимся на проектировании -- невзирая на совпадение "проектирования" и "изготовления" для информационных продуктов). "Многоуровневые типизации" и "буквальные типизации" (типа "шаблон практики постановки..." -- чтобы показать, что тип "постановки метода инженерии" в ISO 24744 будет не "process", а "ProcessKind", или использование "метод" как обозначение того целого из практик-продуктов-организации, что подлежит постановке) я старался не использовать. Интересно было бы получить замечания, где дополнительная типизация была бы полезна и уместна (а где, наоброт, осталась лишняя). В целом, "остаточная типизация" следует ISO 24774, как ее можно обнаружить в ISO 15288, взятом за образец предлагаемого описания/рендеринга. Заодно в качестве побочного эффекта мы получаем текст "процессного стандарта", выполнение которого можно проверять по ISO 15504 (SPICE), ибо такой текст читается как "описание типового процесса" (reference process model) в смысле этого стандарта оценки соответствия.