Можно было бы определить предметную область PraxOS как "то, что моделируется софтом PraxOS" (и наоборот: что является предметной областью PraxOS, то и моделируется софтом PraxOS). Ну, и что должно быть описано на ОргЛане
( Read more... )
Отмэпить ArchiMate на ISO 24744 нельзя. Если перейти в метафору программного обеспечения, то и ArchiMate, и 24744 являются (в прагматике) не описаниями структур данных, а в чистом виде API.
Некоторые форматы данных в API могут пересекаться (например, статичная геометрия) и позволять обмен между (с определённой потерей точности). Однако, нельзя выразить Maya API через 3DS Max API и наоборот. А для OpenGL и Direct3D, решающих идентичные задачи, вообще нет существенных общих паттернов.
Можно выбрать один из существующих API для данного вида задач. Или написать API PraxOS, который будет чем-то лучше существующих решений. Смесь невозможна.
Следующий вопрос - можно ли описать системоинженерные API по аналогии с обычными? Для обычных API существует группа языков http://en.wikipedia.org/wiki/Interface_description_language В которых уже заведены свои низкоуровневые примитивы - функция, метод, перечисление... В ISO 15926 ничего подобного нет, их придётся изобретать. И именно изобретать, а не драть с 24744, так как в 24744 более детальные паттерны и своя китайская классификация.
Третий вопрос - может ли это формальное описание быть потом хоть как-то использовано? Чем оно лучше человекочитаемого текста про ArchiMate со ссылками "если вас интересует похожее в 24744, то смотреть сюда"? Выполнение по одному API с последующей декомпиляцией в сущности другого даст нечитаемый кошмар. Какая-то интеграция - кусочек в одной подсистеме на ArchiMate, кусочек в другой на 24744 - но в каком виде? Например, возможна общая диаграммная нотация. И тогда соответствующий interface description language должен заранее разрабатываться под такие задачи.
Моё решение тут -- это попытаться таки от API (к какой, кстати, исполняющей машине? Мозгам специально обученных данным дисциплинам людей?) перейти к структурам данных PraxOS, единство которых поддерживается одной онтологией и терминологией.
То есть я ни в коей мере не призываю брать редактор ArchiMate и редактор ISO 24744 и как-то использовать один из них вместо другого. Тем не менее, полезно знать о том, что Passive и Active structure в одном из них примерно то же, что WorkProduct и Producer. Для многих людей знание об этой аналогии будет очень полезным.
Понятно, что для компьютера "аналогия" сегодня почти невыразима. Именно поэтому я готов долго мечтать о программах типа VivoMind и рассуждать о том, что у нас будет с понятием "паттерн".
Да, только степень обучения чуть разная - у модельеров, которые ещё и пишут на этих API одна, а у пользователей, которые их только читают (и "выполняют" в голове) другая.
Я вот тут как раз поэтому про рендеры пишу в последнем абзаце -- рендеры (генераторы отчётов и прочие "денормализаторы" всех мастей) для как раз для "читателей и выполнятелей в голове", причем самой разной степени подготовки.
Отмэпить ArchiMate на ISO 24744 нельзя. Если перейти в метафору программного обеспечения, то и ArchiMate, и 24744 являются (в прагматике) не описаниями структур данных, а в чистом виде API.
Некоторые форматы данных в API могут пересекаться (например, статичная геометрия) и позволять обмен между (с определённой потерей точности).
Однако, нельзя выразить Maya API через 3DS Max API и наоборот. А для OpenGL и Direct3D, решающих идентичные задачи, вообще нет существенных общих паттернов.
Можно выбрать один из существующих API для данного вида задач. Или написать API PraxOS, который будет чем-то лучше существующих решений. Смесь невозможна.
Следующий вопрос - можно ли описать системоинженерные API по аналогии с обычными? Для обычных API существует группа языков http://en.wikipedia.org/wiki/Interface_description_language В которых уже заведены свои низкоуровневые примитивы - функция, метод, перечисление... В ISO 15926 ничего подобного нет, их придётся изобретать. И именно изобретать, а не драть с 24744, так как в 24744 более детальные паттерны и своя китайская классификация.
Третий вопрос - может ли это формальное описание быть потом хоть как-то использовано? Чем оно лучше человекочитаемого текста про ArchiMate со ссылками "если вас интересует похожее в 24744, то смотреть сюда"? Выполнение по одному API с последующей декомпиляцией в сущности другого даст нечитаемый кошмар. Какая-то интеграция - кусочек в одной подсистеме на ArchiMate, кусочек в другой на 24744 - но в каком виде? Например, возможна общая диаграммная нотация. И тогда соответствующий interface description language должен заранее разрабатываться под такие задачи.
Reply
То есть я ни в коей мере не призываю брать редактор ArchiMate и редактор ISO 24744 и как-то использовать один из них вместо другого. Тем не менее, полезно знать о том, что Passive и Active structure в одном из них примерно то же, что WorkProduct и Producer. Для многих людей знание об этой аналогии будет очень полезным.
Понятно, что для компьютера "аналогия" сегодня почти невыразима. Именно поэтому я готов долго мечтать о программах типа VivoMind и рассуждать о том, что у нас будет с понятием "паттерн".
Reply
Reply
Reply
Leave a comment