Об расширение ISO 24744
Метамодель ISO 24744 дана в атрибутной нотации (UML). Известные следующие возражения против такой нотации (принципы EPISTLE, которые обосновывают факт-ориентированную запись):
а) атрибуты должны быть определены как сущности, на которые ссылаются через отношения
б) на атрибуты сами по себе нельзя сослаться, и они очень негибки к изменениям
-- атрибуты не позволяют строить их историю
-- информацию про атрибуты попросту негде держать (например, единицы измерения, или язык описания)
-- атрибуты не позволяют иметь различные значения (много описаний, много имен, изменяющиеся значения)
-- атрибуцию (attribution) нельзя описать
в) что является сущностью в одной модели, является атрибутом в другой модели
-- что является сущностью, а что атрибутом зависит от выбранной группы описаний
-- это совсем не поддерживает интеграцию моделей
Для меня существенным является пункт в), про плохую интеграцию моделей в атрибутной записи.
Поэтому я серьезно задумываюсь, стоит ли продолжать расширение ISO 24744 в UML, как это первоначально предполагалось (см. http://community.livejournal.com/praxos/6777.html -- расширение для стратегирования/обоснований).
Не будет ли правильней сначала честно отразить ISO 24744 в безатрибутную запись ISO 15926, и только затем делать расширения?
Как всегда, при этом сразу появляются новые проблемы:
а) моделирование ISO 24744 само по себе представляет собой приключение (и чем больше я знакомлюсь с проблемой моделирования, тем бОльше пугаюсь).
Насколько я понимаю, требуется примерно год full time, чтобы научиться сносно "программировать по сути" (pun intended) на ISO 15926 -- по оценкам тех людей, которые начинали этим заниматься в промышленных корпорациях.
б) не решена задача с шаблонами. Для проекта EqHub было создано 140 шаблонов (сигнатур, представляющих из себя таблички). Непонятно, какие шаблоны нужно будет создать для ISO 24744 и его расширений, а какие можно использовать из других проектов (шаблоны создают в EqHub, в Bechtel, Emmerson, Bentley, как минимум).
Все усугубляется тем, что в головах у нынешнего комьюнити шаблоны и таблички -- одно и то же. У меня почему-то ISO 24744 не представляется табличками (а, может, инженеры правы? Может, как раз табличками и нужно, и люди будут радоваться? Программистов ведь немного, а в экселе вон какие сложные навороты люди привыкли делать! Есть, кстати, класс "спредшитных языков", их очень Алан Кей любит упоминать. Может, именно такое и сделать?)
в) по-прежнему отсутствие инструментария. Текущий инструментарий (обнаружено два работоспособных редактора справочных данных: iRING 2.0 и Bentley Class Editor), похоже, подходит для какого-то моделирования Насосов и Датчиков через калейдоскоп почти хаотично выскакивающих табличек и кусочков деревьев, но мне не кажется это хоть как-то удобным для Методов с их обширными текстовыми описаниями и многочисленными торчащими из них в разные стороны отношениями, а не легко помещающимися в табличку числами. Хотя, может, мир спасёт какая-нибудь "нашлёпка к Excel", делающая из этой платформы спредшитный онтологический язык с контролем типов и прочим -- и взамен "понятности интерфейса" полной недокументируемостью и неотлаживаемостью.
В любом случае, инструментарий держит, и держит сильно: побеждают не идеи, а инструменты. Либо из dot15926 в praxos поступит какой-то инструментарий, либо praxos так и будет заниматься содержательным поиском разрозненных методов, но не их формализацией, обобщением, складированием и совместным развитием. То есть методы будут, но не поставленные под контроль конфигурации, непонятно как публикуемые, с непонятной терминологией и т.д.
Проблема еще в том, что praxos требует не просто "редактора классов" из dot15926, а настроенный Method composer, запрограммированный как DSL на платформе из dot15926. То есть нужен инструмент-2, написанный на инструменте-1.
г) для того, чтобы результаты такого моделирования не пропали, требуется сделать формальное комьюнити, которое будет просматривать результаты моделирования и далее подавать на регистрацию в JORD. Более того, за подачу в JORD еще и деньги придется платить (от имени комьюнити), а без подачи в JORD эти игры с ISO 24744+15926 будут любительством и детским садом.
а) атрибуты должны быть определены как сущности, на которые ссылаются через отношения
б) на атрибуты сами по себе нельзя сослаться, и они очень негибки к изменениям
-- атрибуты не позволяют строить их историю
-- информацию про атрибуты попросту негде держать (например, единицы измерения, или язык описания)
-- атрибуты не позволяют иметь различные значения (много описаний, много имен, изменяющиеся значения)
-- атрибуцию (attribution) нельзя описать
в) что является сущностью в одной модели, является атрибутом в другой модели
-- что является сущностью, а что атрибутом зависит от выбранной группы описаний
-- это совсем не поддерживает интеграцию моделей
Для меня существенным является пункт в), про плохую интеграцию моделей в атрибутной записи.
Поэтому я серьезно задумываюсь, стоит ли продолжать расширение ISO 24744 в UML, как это первоначально предполагалось (см. http://community.livejournal.com/praxos/6777.html -- расширение для стратегирования/обоснований).
Не будет ли правильней сначала честно отразить ISO 24744 в безатрибутную запись ISO 15926, и только затем делать расширения?
Как всегда, при этом сразу появляются новые проблемы:
а) моделирование ISO 24744 само по себе представляет собой приключение (и чем больше я знакомлюсь с проблемой моделирования, тем бОльше пугаюсь).
Насколько я понимаю, требуется примерно год full time, чтобы научиться сносно "программировать по сути" (pun intended) на ISO 15926 -- по оценкам тех людей, которые начинали этим заниматься в промышленных корпорациях.
б) не решена задача с шаблонами. Для проекта EqHub было создано 140 шаблонов (сигнатур, представляющих из себя таблички). Непонятно, какие шаблоны нужно будет создать для ISO 24744 и его расширений, а какие можно использовать из других проектов (шаблоны создают в EqHub, в Bechtel, Emmerson, Bentley, как минимум).
Все усугубляется тем, что в головах у нынешнего комьюнити шаблоны и таблички -- одно и то же. У меня почему-то ISO 24744 не представляется табличками (а, может, инженеры правы? Может, как раз табличками и нужно, и люди будут радоваться? Программистов ведь немного, а в экселе вон какие сложные навороты люди привыкли делать! Есть, кстати, класс "спредшитных языков", их очень Алан Кей любит упоминать. Может, именно такое и сделать?)
в) по-прежнему отсутствие инструментария. Текущий инструментарий (обнаружено два работоспособных редактора справочных данных: iRING 2.0 и Bentley Class Editor), похоже, подходит для какого-то моделирования Насосов и Датчиков через калейдоскоп почти хаотично выскакивающих табличек и кусочков деревьев, но мне не кажется это хоть как-то удобным для Методов с их обширными текстовыми описаниями и многочисленными торчащими из них в разные стороны отношениями, а не легко помещающимися в табличку числами. Хотя, может, мир спасёт какая-нибудь "нашлёпка к Excel", делающая из этой платформы спредшитный онтологический язык с контролем типов и прочим -- и взамен "понятности интерфейса" полной недокументируемостью и неотлаживаемостью.
В любом случае, инструментарий держит, и держит сильно: побеждают не идеи, а инструменты. Либо из dot15926 в praxos поступит какой-то инструментарий, либо praxos так и будет заниматься содержательным поиском разрозненных методов, но не их формализацией, обобщением, складированием и совместным развитием. То есть методы будут, но не поставленные под контроль конфигурации, непонятно как публикуемые, с непонятной терминологией и т.д.
Проблема еще в том, что praxos требует не просто "редактора классов" из dot15926, а настроенный Method composer, запрограммированный как DSL на платформе из dot15926. То есть нужен инструмент-2, написанный на инструменте-1.
г) для того, чтобы результаты такого моделирования не пропали, требуется сделать формальное комьюнити, которое будет просматривать результаты моделирования и далее подавать на регистрацию в JORD. Более того, за подачу в JORD еще и деньги придется платить (от имени комьюнити), а без подачи в JORD эти игры с ISO 24744+15926 будут любительством и детским садом.