Обсуждение

Спасибо за ISO 81346, очень интересно! Жаль, что их система классов, кажется, не очень применима к софтверу. Надо будет аккуратно продумать, как концепция трех аспектов (функция, локация, часть продукта) может быть использована для идентификации в софтверной инженерии.

А где "время" ?

В каждом перечисленном стандарте (кроме, пожалуй, ISO 42010) оговаривается работа со временем и жизненный цикл системы.

Мне как-то подгоняли в комментариях 81346, сильно непонравилась игры с пунктуацией ("+-=") и уход от пространственно-временных принципов идентификации (part2:Location, part2:Event, ...) в натуральную китайскую классификацию животных. Идентификации можно поучиться у Tokyo Metro и Toei Metro, например, https://en.wikipedia.org/wiki/Tokyo_Metro_Ginza_Line G-09 Ginza, и всё понятно. На том же JR (ещё одно токийское "метро") подобной идентификации нет, приходится ориентироваться по кандзи, так как названия в ромадзи там тоже не всегда указаны.

Понятное дело, что все эти стандарты нужно друг с другом гармонизировать и чистить рашпилем. В ISO 81346, например, отнюдь не синтаксис обозначений интересен, а идея о том, что сами эти обозначения -- не главное. Мы, конечно, будем гармонизировать его с ISO 15926 во многих аспектах. Идентификация метро плоха тем, что это идентификация по сути одного объекта. Попробуйте проидентифицировать так ракету в её разнообразии железяк и контроллеров, да ещё и придумать такую систему идентификации, чтобы прошивала независимых подрядчиков с их независимыми системами идентификации на два-три уровня композиции.

Локальная идентификация в рамках системы легко поднимается за её рамки. Вообще, для хорошей глобальной идентификации требуется: 1. Соглашение об используемых символах в локальной идентификации. 2. Единое обозначение композиции. 3. Отсутствие смущающих классификаций, которые добавляют ложные знания и спустя время приводят к подсчётам овса на прокорм паровоза. Учитывая необходимость подключения к существующим локальным идентификациям, в качестве первого придётся ставить _все_печатные_символы_, с возможностью заключения идентификации в (какие-либо) кавычки. Композиция - традиционная точка. Проявление классификаций в используемых именах - не часть стандарта, а good practices соответствующей предметной области. Получается что-то вроде: URI."http://ailev.livejournal.com/1088630.html" Tokyo.transportation_system.G_09 Tokyo.transportation_system."Ginza, Ginza Line" rocket_r1."some-complex-ISO-81346-identification"

Использование вместо точки разных символов -- это попытка типизации. FunctionalPhysicalObject против InanimatePhysicalObject против места (с этим location я ещё не разбирался толком). И странный тезис, что трёх (точнее -- четырёх) типов хватит для практически всех случаев. Тут ещё много рассуждений о том, URI это (нечитаемые по определению), labels (читемые короткие уникальные) или names (неформальные длинные неуникальные имена на разных языках) и как их все связывать друг с другом, если все нужны. То есть в этом стандарте инженерные онтологические интуиции переплетены с интуициями по поводу обозначений. С этим нужно разбираться. Опять же, в реальные производства идти всё одно нужно на базе какого-то стандарта, а не выдумывая по ходу дела всё из головы. Так что опираться на стандарт нужно, хотя бы для обозначения его номером темы разговора.

Вот это самое - коды, читаемые метки, или (и) неформальные имена возможны в данном пространстве идентификации - должно определяться по good practices (или, в переходный период, по not so good practices), так как иначе всё утонет ещё до того как начнёт работать. Существующие стандарты - вполне себе подпадают под good (or not so good).

ISO 81346 в девичестве назывался IEC 61346, который основан на Kraftwerks-Kennzeichen-System (KKS), который адаптирован как РД 153-34.1-35.144-2002, который стандарт де-факто по системе обозначений в АСУТП российской энергетики.

Там много сложней отношения, и ISO 81346 самый современный из всех этих стандартов, плюс он внеотраслевой. А RDS-PP (наследник KKS) отраслевой, со всеми вытекающими нюансами и дополнительными ограничениями. И он тоже будет перерабатываться потихоньку в направлении более полной реализации принципов ISO 81346, этот процесс идёт под немецким контролем. Мы начинаем работать с ISO 81346, переписываемся с авторами стандарта по ряду принципиальных вопросов.

Если я правильно понял, то кодификация 81346 нужна для быстрого понимания что делает эта фиговина, где лежит, из чего состоит. Поскольку стандарт инженерный, то фиговины из атомов. В софте фиговины из битов. То есть получается что в софте это правила именования объектов ? intretMaxCount, intGetMaxCount(). Или зачем это в софт совать ? Разработчики стандарта решали же какую-то проблему.

Рабочие продукты софтверной инженерии не обязательно биты. Требования могут быть вполне себе напечатанными атомами (или подразумевать печать, как это делает любой вордовый документ). Вот я как раз думал в направлении идентификации рабочих продуктов альфы "описание целевой системы". Например, идентификация "тесткейс, исторический драфт номер N, функция M", то есть функция, локация в жизненном цикле, часть продукта] может быть полезной. Но это все еще сыро, конечно.

Ещё один стандарт введён в зону внимания. :-) http://www.youtube.com/watch?v=W4A1Dnlv8h0 эта ссылка в самом конце статьи - какое видео должно быть по этой ссылке? - за давностью лет видео недоступно.

Увы, не помню.