Обсуждение

>Ваши действия? Делегирование - почитайте Сунь-Цзы.

Глупо. Речь идёт сугубо об инженерных сущностях, никак не о философских. Именование sub-entities иерархии - сложнейшая задача, если entities, входящие в условия задачи - участвуют в различных иерархиях и требуются их однозначное определение, вне зависимости от корня иерархии.

идеал недостижим.

Ага. Два технических паспорта: на техническую платформу и заводской паспорт на винтик (ибо винтик был куплен на заводе, который снабжает эти винтики техническими паспортами). И namespaces оказывается много разных (штуки четыре основных), и проще их называть кодировками ("по RDS PP", "номенклатурная кодировка" и т.д.), нежели по-программистски "пространствами имен".

Ага, так и учат наизусть: даже с учетом того, что кодировки учитывают сразу три иерархии (выполняемой функции, оборудования, месторасположения). Вы познакомьтесь с какими-нибудь системами промышленного кодирования на практике, очень пользительно. Это совсем не то, что делают программисты: ибо оборудование не так легко "переоборудовать", как переименовать или перепрограммировать текст программ ;)

Схему заучивают наизусть не в результате целенаправленного заучивания, а самопроизвольно. После пятого ремонта сопротивления R5 вы будете наизусть его знать. Другое дело, что маркировка R5 в проигрывателях редко ставится, а на заводах -- обычное дело (а сейчас еще и RFID или штрих-код, чтобы всю необходимую информацию можно было подтянуть из САПР). Проблема с заучиванием кодировки стоит, когда бригаду с одной атомной станции переводят на другую: все, вроде, по деталям то же самое, а кодировка оборудования может быть разная -- тут и наступают проблемы у ремонтных бригад... С int var1 -- фигня вопрос, особенно если на заморачиваться, что при "смене кодировки" язык программирования может оказаться другой, и там int вообще может отсутствовать как класс :) Вопросы именования весьма сложны (про "имя имени" я вообще промолчу тут), и нельзя их недооценивать.

Интересно, как вы на тему трофейного оборудования перешли, а затем вообще на бомбы. Это у вас поток свободных ассоциаций по слову "атомная станция"? Эти станции не трофейные, а отечественные, и смена кодировки связана с тем, что внедряются новые САПРы и технологии строительства, а новые блоки (почти копии старых) ставятся на площадки рядом со старыми блоками -- и у ремонтных бригад появляется путаница. В основном постинге приведена ссылка, по ней есть видео -- поглядите его, там как раз про проблемы кодирования на примере для атомных станций.

В софте не столько кодировка, сколько полноценное именование -- в которое кодировка разве что подмешивается. И я еще раз повторю: не в любом софте имена у переменных и классов. Не любое программирование объект-ориентированное. Как раз эти случаи и интересны: "не-объекты, а имена имеют" ;)

Это все понятно. Очень близкая к этому традиция -- entity-relationships модели. Но уже с ними маленькие проблемы, ибо там (после некоторой разборки) возникают уже не столько объекты, сколько "роли". Но это я просто к тому, что в мире железок все устроено одним образом, а в мире не-железок совсем другим образом, и поэтому не любые придумки переносятся между этими мирами. Не любую геометрию можно использовать для постройки табуретки, лучше бы выбирать эвклидову. И наоборот: для теоретической работы необязательно использовать только эвклидову геометрию. Меня очень интересуют системы кодировки, в которых я мог бы кодировать какую-нибудь атомную электростанцию (включая ее софт -- причем неизвестно, на каких языках этот софт будет писаться, и какие базы данных и репозитории включать), проектные процессы ее создания, а также организационные процессы и оргструктуру. В этом направлении и копаем. Поэтому "чисто софтовый" выбор имен мне, увы, неинтересен. В софте можно по-всякому.

Сводная заказная спецификация на АЭС содержит порядка 300-400тыс. позиций (каждая их которых укрупненная и в ней довольно много составляющих). Коды для всех этих позиций поддерживаются специальным закупочным софтом, САПРами и т.д. Не понимаю, как могли бы тут помочь UML-редакторы. UML-редакторы даже программисты сейчас не все используют (есть и любители ORM-модели, как раз для ролевого моделирования). Также не понимаю, зачем для кодирования организационных процессов (например, в BPMN 2) применять UML-редакторы. К вопросу об UML-редакторах: у меня на компе стоит Objecteering и даже Artisan Studio (а может, и какие-нибудь еще). Они никак не позволяют мне ответить на вопрос о принципах объединенной кодировки железных, софтовых, объектов, чертежей, документации, репозиториев САПР (которые весьма сложно устроены внутри), оргпроцессов, организационных подразделений и т.д. Тем более, что есть куча всякого софта, и эта куча софта будет готова поддержать любые стандарты кодировки, буде выяснится, какие они. Решение по параллельной кодировке регулярно обсуждается, но трудоемкость параллельной кодировки зашкаливает: кто будет делать высокоинтеллектуальную работу по мэппингу кодировок? Ведь это совмещение двух разных картин мира: делать такую работу должен прикладной философ -- таких людей я знаю, но их крайне мало и они крайне загружены. И этот философ должен быть не программист, а инженер: предметом ведь являются не столько программы, сколько вентили, задвижки, детали корпуса, трубопроводы, системы пожаротушения и т.д. Конечно, там и программы где-то могут встретиться, но это будут какие-нибудь АСУ ТП (например, программы для ЦАП) -- ну, и как их кодировать так, чтобы кодировка самих ЦАП и программ к ним была хоть сколько-нибудь согласованной? А ведь ЦАПы будут такой крошечной частью системы, что и представить трудно.

"Разъяснить системе" -- это и есть самое трудное. Почитайте, например, про эскимосов у меня в http://ailev.livejournal.com/573343.html (а более длинно -- https://www.posccaesar.org/wiki/ISO15926Primer, это как раз промышленный вариант для работы с "иерархиями иерархий" оборудования).

"контекст" - вполне литературный жаргон. Можно присоввокупить с прилагательным, тот же самый "номенклатурный контекст". Таким образом можно для одного изделия оперировать более коротким понятием, если идет обсуждение в рамках более узко-определенного контекста, и громоздким, если обсуждение вырвано из контеста - "мы просрочили выпуск изделия X потому что недостает деталей JHABNBX.AKJSJJDN.KAS".

промахнулся с постом - пример оторванности от контекста :) А вообще начал комментирование в связи с появившимся вопросом по именованию изделия (детали) в рамках не одного, а нескольких проектов. Например если брать деталь стандартизированную под межотраслевой ISO/ГОСТ (винт и шайба на 8), тут вопроса не возникнет. Как будет обстоять дело, если взять деталь или компоненту специализированную для определеного круга изделий? Уши от слона - например. К кенгуру они не подойдут, но вот африканский и индийские слоны ими оснащены. Переходя от этой аналогии к нефтяной платформе - некоторые детали уже будут оснащены специализированными именами, и из десяти миллионов половина деталей (как минимум) уже будут иметь собственные именования, которые надо будет "втиснуть" в перечень вновь создаваемой номенклатуры. Зачем это делать? Есть предположение: что на самом деле количество деталей может быть значительно меньше, чем их именований. Крепежные элементы в своем большинстве могут быть стандартизированны. Это касается и коммуникаций (провода и трубы). Из чего проистекает другая гипотеза, что из перечня в десятки миллионы деталей можно было бы сформировать перечень всего в один миллион - произведя оптимизацию набора исходных деталей по принципу их взаимозаменяемости. Однако такой подход требовал бы большей гибкости от централизированного управления. Собственно сам вопрос: что несет в себе эта система обозначения обозначения всего и вся, если на самом деле она допускает дублирование понятий? Каков практический смысл этого? Мне кажется, или реально, система обозначений может привести ситуации из анекдота: "это половинка таблетки - от живота, а эта - от головы. Смотри, не перепутай!" ?

Да, спецы по кодировкам занимаются ровно ответами на эти вопросы ("вот на складе лежат десять одинаковых деталей, одна из них с дефектом. Выдайте мне ее, пожалуйста. -- Какую из десяти?!". Имен много, одно имя присвоено заводом, другое имя соответствует месту в проекте. Запчасти с разными заводскими именами в разное время стоят на одном и том же месте в конструкции и называют их уже не по заводским номерам, а по тому месту, куда они поставлены (например "заднее левое колесо", а не "шина с заводским номером XYZ, натянутая позавчера на диски с заводским номером 123"). Я думаю, что для рассуждений об этой сфере нужно таки иметь какую-то практику в данной области. А чтобы иметь практику, нужно понимать важность и проблемность данной сферы -- и затем выделить время, чтобы позаниматься этим специально.