Category: работа

Category was added automatically. Read all entries about "работа".

2021 год

Аналитическая конференция в ГУ ВШЭ.

Побывал сегодня на аналитической конференции (http://vic-gorbatov.livejournal.com/82273.html, материалы -- http://conscious-mind.ru/?page_id=642, хотя доклады часто не совпадали с материалами).

Мне было очень интересно. Как я понял, есть несколько десятков человек, которые по-русски готовы подробно обсуждать модальный реализм Льюиса, и на этой конференции присутствовала значительная доля от этих людей. Жесткие десигнаторы, возможные миры, двумерная семантика звучали практически в каждом докладе.

Обидно, что большинство докладов были устроены по принципу "вот я тут почитал книжку великого А и я согласен с его идеей Б, и идеей В, но не согласен с идеей Г и Д". Хотя и были доклады, в которых предлагались какие-то идеи Е и Ж, которые были не столько вычитаны у Великих Аналитических Логиков/Философов, сколько высказаны самостоятельно.

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

Но ежели нужно пообсуждать философские основания ISO 15926, то несколько десятков человек (которые давно знают друг друга) в самых разных городах России и близнего зарубежья -- есть. С сегодняшнего дня они также знают, что есть еще десяток человек, которые готовы пообсуждать эти же вопросы, но в применении к инженерии, экономике и прочим дисциплинам, которых ранее не было в их логико-философской повестке дня.

"Для работы" я там взял одну вещь: я тут спорил с vvagr пару недель назад, что отношения между синтаксисом и соответствующими ему предложениями языка можно, конечно, считать "классификацией", а синтаксис -- классом, но мне это активно не нравилось -- и я никак не мог сформулировать, почему. А тут меня ткнули в работы Edward Zalta http://mally.stanford.edu/zalta.html, где для абстрактных объектов предлагается говорить не о "классификации", а о "кодировании". Даже если у Zalta его "кодирование" совсем не то, что мне нужно, мне этот подход симпатичен. Вопрос об экстенсиональном задании класса или кода (определяемого, как набор аксиом, насколько я понял) -- это другой вопрос.

По хорошему, это бы с тамошними логиками/метафизиками и пообсуждать. Но у тамошних логиков/метафизиков свои проблемы, и вряд ли им такие обсуждения с прямым выходом в практику интересны. Ну, и не все тамошние логики онтологию/метафизику любят настолько, чтобы это обсуждать.

Но мне самому многое стало понятно: какие книжки читать, на что в них обращать внимание, откуда пришли те или иные термины, и какой раздрай вменяют эти термины аналитической тусовке.

Я сам на аналитических тусовках никогда раньше не был, но часто попадал в общество классических немецких философов (хотя и особого разлива -- СМДМ-методологов, которые больше "деятельностники", чем немецкой школы). Забавно было обнаружить, что я чувствую себя в аналитической тусовке вполне своим -- никакого отторжения их построения у меня не вызывают. Но вот деятельностного подхода в разговорах аналитиков мне сильно не хватает. Они как-то катастрофически оторваны от практики (в любых смыслах этого слова, в том числе и философском). И я хорошо понимаю, что это как раз идет от их школы, это не случайно.

Как я понял (может, неправильно -- но уж так показалось), российско-украинская аналитическая тусовка вполне мейнстримная, и обсуждает главным образом уже устоявшееся. К скандальным новинкам эта тусовка относится скептически, настоящих буйных мало (может, Андрей Шуман -- но он как раз не доехал, хотя и хотел).

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

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

Послезавтра схожу на Щедровицкие чтения (http://www.fondgp.ru/projects/chteniya). Что полезного в этой СМДМ-тусовке, как раз лучше понимаешь, столкнувшись с тусовкой аналитической.

Итого: читать Льюиса и Залта, обоих с недоверием.
2021 год

Карта связей в LinkedIn

Чтобы не разнесло ленту, прячу свою карту связей в LinkedIn под кат:

Collapse )

Вопрос, который задают авторы этой картинки: задумайтесь, в какие тусовки вас забрасывала жизнь. А чего тут думать? И так всё понятно...
2021 год

Дыбр

Много пишу в последние дни, сливаю свой консалтинговый опыт в praxos, опыт программистский в dot15926. Это не считая частной переписки и нескольких совещаний ежедневно.

К нам в сентябре уже едут Ian Alexander, Tyson Browning, Cesar Gonzalez-Perez, Ian Glendinning, Niemisto Hannu и, надеюсь, Donald Firesmith. Как я понимаю, это еще не весь список. Теперь нужно озаботиться отечественной частью программы. Это я про http://rise-russia.org/rusec2010

Завтра рано утром -- в Элисту. Время выбрано очень удачно: по прогнозу там ожидается +34 в тени.

Долго думал, рисовать ли слайды к выступлению на элистинской конференции, а затем догадался поглядеть на сверстанную программу (http://www.creativeforuminkalmykia.org/program/reports). Неожиданненько, более чем. Конечно, никаких слайдов! С другой стороны, это тусовка психонетиков из самых разных городов, их там много больше половины всех гостей и участников: http://www.creativeforuminkalmykia.org/list -- можно будет подробненько разузнать, что новенького в психонетическом проекте. А политический перекос (я бы даже сказал, перегиб), надеюсь, лишь дань официозной стороне мероприятия. Хотя кто его знает, приеду -- разберусь на месте.

Я там докладывать планировал "связь моих проектов друг с другом" (http://ailev.livejournal.com/843165.html) под торжественным названием «Система проектов и сообществ по развитию креативного мира». После меня John Quijada «Концептуализация идеального языка для выражения творческой мысли» (про Ифкуиль и подобные языки) -- и вот что он пишет про эту поездку в Калмыкию: http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1007A&L=CONLANG&P=R34. Слайды его тут: http://www.ithkuil.net/kalmykia_conf_01.htm, про "голую женщину, спускающуюся по лестнице".

Для любителей поразмышлять об абстрактном, безумном и прорывном: что было бы, если ISO 15926 писать на одном из языков Джона Кихады -- иткуиле или илакше (http://www.ithkuil.net/, перевод значительной части сайта на русский: http://ithkuil-russian.narod.ru/) вместо EXPRESS, FOL и OWL? И иметь голосовой интерфейс к универсальному моделеру? Both Ithkuil and Ilaksh represent a cross between an a priori philosophical language and a logical language. They are by no means intended to function as “natural” human languages. Ithkuil and Ilaksh exist as exercises in how human languages could function, not as human languages do function. (Disclaimer. Мне vvagr заметил вчера, что я стал весьма игрив в последние несколько дней, и шутки мои становятся неумеренными. То ли еще будет, исключительно заради лулзов!).

И, чтобы два раза не вставать: придумыватели языков продолжают свой упорный труд. Вот результаты самого свежего обзора от 27 апреля 2010: http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1004D&L=CONLANG&P=R9034 (Ифкуиль там занял первое место, а Toki Pona лишь четвертое). У меня физически не хватает времени поближе со всей этой лингвистической тусовкой познакомиться, хотя очень хочется (см., например, пункт 2 в http://ailev.livejournal.com/686890.html -- там я про порождающие грамматики мечтаю).
2021 год

Полуавтоматическое распознавание предметных областей

Много раз читал (и даже что-то писал) про ADOM (Application-based Domain Modeling, но только сейчас обратил внимание на самое интересное: они автоматизируют распознавание предметных областей: http://mis.hevra.haifa.ac.il/~iris/research/SDM/index.htm

Берут модели нескольких приложений, и делают из них модель предметной области (метамодель) путем полуавтоматического обобщения (Semi-Atomated Domain Modeling Approach). Тренируются главным образом на проектном управлении и системах планирования производства -- http://mis.hevra.haifa.ac.il/~iris/research/SDM/SDMrepository.htm

Как я понимаю, примерно так же действуют люди из тусовки ISO 15926: они делают конкретные мэппинги в конкретных приложениях, добавляя в RDL то, чего там для этого не хватает. В итоге предметные области будут иметь структуру, почерпнутую главным образом из приложений (а приложения имеют метамодели/онтологии, разработанные безо всякого domain-driven подхода. То есть никакие -- но в любом случае знание предметной области в них будет присутствовать, и его можно пытаться отловить).

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

PraxOS и ISO 15926

Удивительно: именно я оказался человеком, который сообщил тусовке разработчиков ISO 15926 о стандарте SBVR. Теперь я им сообщил об OMG ODM (http://levenchuk.com/2009/12/12/omg-ontology-representation-related-standards-odm-sbvr-and-iso-15926/).

А всего-то я от них хочу, чтобы они определили стандарт, в котором готовить русскоязычную версию ISO 15926, но их интересует более широкий круг вопросов.

Интересно, что наш план по разработке онтологии деятельности в принципе был одобрен -- и нам даже предложили по нему сделать рабочую группу PoscCAESAR (см. комменты к http://levenchuk.com/2009/12/10/activity-modeling-and-iso-15926/). Жаль только, что мы эту рабочую группу создать сами пока не в состоянии (мне кажется, что это все-таки не совсем по профилю деятельность для организационных консультантов -- быть лидерами методологического проекта). Но с удовольствием поучаствуем, буде она создастся -- как неосновной деятельностью заниматься методологией весьма полезно.

После чего PraxOS будет иметь стандартизованную онтологию деятельности -- причем по-русски и по-ангельски, что приятно. И софт PraxOS сможет легко и свободно стыковаться с поддерживающими ISO 15926 САПРами -- если только не окажется, что рабочая группа, когда она соберется, сделает такую "консенсусную" онтологию деятельности, которая свяжет нас по рукам и ногам и поэтому будет нами же с негодованием отвергнута. Но попытка не пытка, быть стандартизированными на международном уровне -- это все-таки правильно.
2021 год

Об выбор САПРов

Два полных дня с утра до вечера дня провел за изучением вопроса о САПР (включая слушание докладов, беседы с поставщиками, чтение документации в количестве и просмотр мнений в форумах. UPDATE: я САПРЫ и PLM системы не различаю принципиально, это все автоматизация проектирования и производства). Результаты:

1. Все ведущие "поставщики решений" нажрались "лучших продуктов" в виде закупки компаний, и теперь наперегонки пытаются переварить их в "продуктную линию, закрывающую весь спектр". Переваривание получается у кого-то плохо, у кого-то очень плохо.

2. Ситуация похожа на дорогой ресторан: сначала ты обнаруживаешь меню с 500 позиций, и (глядючи на цены) понимаешь, что за такие деньги ты как минимум должен не ошибиться в выборе -- но только салатиков находишь пятьдесят, из них "простых овощных" десяток. При обсуждении меньше всего играет роль питательность и вкус, но зато идут красивые названия типа "с синхронной муравой" (оказывается травой, по форме листа, вкусу и запаху неотличимой от обычной петрушки из соседней столовой). Затем тебя на полтора часа оставляют наслаждаться собственным аппетитом ("настройка кухни на ваш особенный салат"), затем приносят явно не то, что ты ожидал укусить -- но делают это все так торжественно, что придраться не к чему.

3. Проблемы те же, что и с внедрением больших ERP-систем: либо предприятие начинает работать так, что решение "из коробки" подкручивать не нужно, либо подкручивать будет стоить столько же, сколько заставить предприятие работать так, как требует этого программа. Беда в том, что из коробки отнюдь не все решения работают.

"Процесс решает всё" -- САПРы не слишком помогут при закупке одного модуля на одном рабочем месте. Нужно много разных модулей на разные рабочие места, и чтобы они все работали вместе. Это самое трудное.

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

Про ситуационную инженерию методов все они ничего не слышали, но в плане activity modeling -- все имеют какие-то варианты схемы для нескольких видов workflow, проектов и т.д. Почему несколько? Ну, там ведь в ядре сидят несколько продуктов разных разработчиков, у каждого из которых когда-то был свой вариант воркфлоу...

4. В ERP есть хотя бы шанс, что руководство разберется, что ему пытаются продать (другое дело, что таки не разбираются -- но это другой вопрос). В САПР этого шанса практически нет. Архитектурные и технологические решения, которые на много лет вперед определяют лидерство или отставание, не видны -- они под капотом.

5. В сотрудников российских офисов не стрелять: они продают, как умеют! Опыт показывает, что самые интересные сведения находятся в R&D отделениях фирм-поставщиков, и требуются немалые усилия, чтобы местным сейлзам добыть актуальную информацию, а не маркетинговое бла-бла-бла. Кстати, про маркетинговое бла-бла-бла: в САПРах, оказывается, этого не меньше, чем в ERP-мире. Или даже больше: материалы все под большим секретом, описания продуктов максимально неподробны, на вебсайтах ничего кроме бла-бла-бла-лучше-всех-бла-бла нет.

6. На сегодняшний день в части работ в части замысла-ТЭО-проектирования моим лидером является Dassault Systemes V6:
-- продукты, конечно существенно недопереварены (так, данные 3D-проекта и жизненного цикла инжиниринга "синхронизированы" уже, но имеют до сих пор разные называния и структуру), но уже четко видно, в какую сторону это переваривание идет -- от документоцентрики стремительно отказываются, архитектура становится SOA. Есть вижн (чего не нашел у других). А вижн вполне может быть конкурентным преимуществом.
-- системная инженерия со всеми ее свойствами (рекурсивность, инкрементальность, итеративность и т.д.) лежит в основе всей продуктной линейки, масштабируемость налицо. От фотоаппарата до небоскреба будет проектироваться одним и тем же софтом, и лежать все это будет в одной и той же базе (которая, кстати, у в ноябре 2009г. вышедшего продукта V6E2010X может находиться в облаке, чтобы ресурсов всегда было "достаточно"). V-диаграмма поддерживается программно (ага, прямая аллюзия с "аппаратно"). У многих других продуктов это требуется специально настраивать, если догадываешься о ее существовании. Тут ей обучают в порядке пользования программой. У меня есть впечатление, что курсу системной инженерии вполне можно учить с использованием этого программного обеспечения: там "жизненный цикл" у любого объекта базы данных.
-- интерфейсы не хочется лизнуть, как у Apple, но они явно поприятнее, нежели у конкурентов. Более того, коллаборативность там понимают абсолютно правильно: работа в итоге должна быть в среде, похожей на виртуальный многопользовательский мир типа Second Life.

Самое забавное, что продавцы Dassault Systemes про эти конкурентные преимущества практически не рассказывают. Такое впечатление, что они привыкли играть в помодульное сравнение с конкурентами (пуговицы на их пиджачках сравниваются с пуговицами на пиджачках конкурентов, ткань подкладки с тканью подкладки и т.д. -- общий же фасончик и удобство в носке всей конструкции мало кого интересует). Более того, значительная часть того, что делает Dassault Systemes на российских предприятиях будет вредна: более отсталые продукты будут явно лучше, ибо позволят поднять производительность на старых бумажных процессах, переведя бумагу в электронную форму. Уйти от процессов проектирования, похожих на бумажные, российским производствам будет боязно -- дураков переучиваться на старости лет нетути.

Обращу особое внимание, что все мои симпатии относятся к "совокупности модулей", ибо по каждому отдельному модулю возможна религиозная война с модулями других поставщиков -- и вовсе не факт, что отдельные модули эту войну выиграют (особенно, если рассматривать какие-нибудь узкие сегменты specialty engineering).

Недостатков у Dassault Systemes V6 тоже тьма тьмущая, начиная с самой высокой по сравнению с конкурентами цены и заканчивая "эта фича у нас есть, но вам она будет доступна только в версии 2012года".

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

В следующих сериях этой саги о САПРах бы рассказал:
-- о жути таблично-формовых мастдайных интерфейсов (или у вас абсолютно единообразный ужасный таблично-формовый интерфейс, или единообразные команды с не пойми какими ключами, или вам нужно учить десятки удобных текстовых и графических DSL -- которые вы просто не сможете все запомнить. Что делать?)
-- о ситуационной инженерии методов и "настройке" монстрообразных корпоративных приложений типа САПР, EPR и т.д.
-- о софтовых приложениях для предприятия vs приложения предприятия к софтам.
2021 год

О выборе линейки САПР

На вчерашнем заседании Русского отделения INCOSE в кулуарах произошло обсуждение того, какие критерии должны быть у хорошего САПР.

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

В кулуарах к кулуарам мы с vvagr сформулировали следующий набор вопросов, которые нужно задавать поставщикам САПР. Ответы на эти вопросы крайне разные для разных поставщиков, а у поставщиков крайне разные для разных версий их систем:

1. Поддержка специальной инженерии: все САПР хорошо поддерживают 3D-картинки или принципиальные схемы (например, P&ID). Но каждый элемент для той или иной специальной инженерии (труба, швеллер, да и сам бетон) имеют какую-то модель данных, которой для вашей специальной инженерии просто может не быть. Вопрос:
-- модели данных каких элементов наличествуют в САПР "из коробки"?
-- модели данных каких элементов можно купить?
-- модели данных какого вида можно "настроить"?
-- есть ли какие-то доступные каталоги?
Есть ли готовые "настройки" для рабочих мест специальной инженерии? (трубы, HVAC, бетон, электрика...).

2. Поддержка дисциплин системной инженерии:
-- поддерживается ли в рамках одного рабочего места (без дополнительной настройки) трассировка "по клику мышкой" между требованиями (заинтересованных сторон, требований к системе), логической архитектурой, физической архитектурой, имитационными моделями, рабочим проектом, закупками (практика соглашений), проектом-project?
-- есть ли поддержка "оценочного дела" (для требований, архитектуры, "обоснование безопасности" и т.д. -- claims, arguments, evidence).

3. Поддержка процесса системной инженерии:
-- поддерживается ли ситуационная инженерия методов? Насколько удобно описываются процессы-workflow (процесс известен и доступен "из коробки"; процесс неизвестен, ибо повторяет процесс какого-то давнего заказчика; процесс гибко настраиваем -- но без настройки ничего не работает)
-- есть ли поддержка проектной/менеджерской группы описаний (контрольные точки, пересмотры и т.д.).

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

5. Какие чертежи выдаются в производство и на стройку?
-- выдаются не чертежи, а что-то иное (тогда как это иное может быть использовано в наших краях?)
-- выдается полный комплект чертежей по ГОСТ, никаких проблем с отечественными надзорами и подрядчиками
-- выдается полный комплект чертежей по каким-то иностранным стандартам, и требуются уговоры контрагентов для их использования.
2021 год

Прописи, и сколько они стоят

Дитенка в соседней комнате вымучивает прописи. Шариковой ручкой, очертания букв совсем другие, нежели более сорока лет назад вымучивал я. Мне не разрешали в школе писать авторучкой, ибо "авторучка плохо прорабатывает нажим, учиться писать нужно обязательно с учетом важности нажима, и только пером номер 11". И мы таскали чернильницы-непроливайки с промокашками. Через несколько лет писать авторучками разрешили, а шариковыми ручками нет. Потом сдались и на шариковые ручки.

В первом классе учительница вывела меня к доске и начала ругать за плохой почерк. Я ответил: "У Карла Маркса тоже был плохой почерк -- и все в порядке". В восьмом классе я начал писать печатными буквами и разборчивость моего почерка взлетела на небеса, после окончания университета перешел на клавиатуры.

Я не понимаю, зачем моему дитятке букву О рисовать не кружочком, а кружочком с переходным хвостиком к следующей букве -- и рисовать целыми строчками. Для развития мелкой моторики?! Пусть рисует мелкие узоры, это менее нудно и более полезно для такого развития. Или играет в видеоигры, где точность попадания должна быть в один пиксель. Все равно ввод будет клавиатурный, а не перьевой -- не тому дитенка учат. Беда, гомо сапиенс попал в неандертальскую школу.

С другой стороны, авторучки и шариковые ручки в те давние годы были дорогими. Не такими дорогими, как сотовые телефоны (если к ним подключить клавиатуру и мышку), но где-то сравнимо. Проект "ноутбук каждому ребенку" в России (ru_olpc) сталкивается с тем же, с чем столкнулись бы школы в те далекие годы моего обучения: со стоимостью одного школьного рабочего места. Авторучку можно было бы разрешить, но не обязать ей пользоваться. Шариковую ручку можно было разрешить, но не обязать ей пользоваться. Сейчас в первом классе компьютер вместо бумаги еще не разрешают, и непонятно, когда будет момент такого разрешения, но уже понятно, что обязать пользоваться компьютером в первом классе станет возможно еще не скоро (но речь не идет о десятках лет, как в случае замены на авторучки и шариковые ручки. Я думаю, что десять лет -- это сегодня более чем предельный срок для такого сдвига, а то и лет семь).

Прописи двадцать первого века -- это слепой десятипальцевый метод печати (со всякими оговорками, что роль такой печати тоже сейчас преувеличивается, ибо вот-вот появится качественное распознавание голоса, и можно будет стремительно забывать об умении "каллиграфически писать", и об умении "вслепую печатать").

С другой стороны, сделаем некоторую прикидку: сколько вообще должно стоить интеллектуальное рабочее место? САПР сегодня имеет стоимость одного рабочего места порядка $100тыс. (http://ailev.livejournal.com/730206.html). Сколько должно стоить интеллектуальное рабочее место школьника первого класса? Школьника пятого класса? Дошкольника? Насколько это рабочее место может быть индивидуализировано (ведь САПР на каждом рабочем месте глубоко индивидуализирован)? Какая вообще экономика образования в части снабжения оборудованием -- дорогущие САПР ведь не от хорошей жизни работодатели покупают, значит и в школах Систему Автоматизации Обученческой Работы (САОР) должны покупать не от хорошей жизни, а только выгоды ради. Какая выгода, кто озабочен ее измерением -- и как иначе выяснить, что $1000 на дитенку будет дороговато, а вот $700 с упрощенными функциями в самый раз (примерно так ведь и происходит с интеллектуальными рабочими местами для взрослых)?

Я не делаю скидок на то, что софт может быть свободным. Толку от этой свободы не так много, если не обеспечить поддержку, а относительная стоимость поддержки сегодня очень быстро вырастает в общей стоимости владения рабочим местом. В САПР поддержка-наладка занимает 50% всей стоимости.

Так сколько еще будут мучить наших детей прописями с ненужными виньетками вокруг букв? Как использовать энергию школьного учителя, чтобы дитятку научили в школе слепой печати, а не пририсовывать хвостик к букве О? Сколько должно стоить рабочее место для осмысленных прописей? Почему с таким скрипом идет проект OLPC и другие школьные компьютерные проекты -- не по той ли причине, с какой в школы со скрипом шли сначала авторучки, а затем шариковые ручки?
2021 год

Конференция Dassault Systemes. V6 и PLM 2.0

Побывал сегодня на конференции Dassault Systemes (http://www.3ds.com/ru/), и вот что мне удалось выяснить:

1. Начиная с CATIA 5 удалось таки объединить конструкторский и проектировочный софт. Кстати, я планирую вскорости посвятить некоторое время описанию этой разницы между "конструкторами" и "проектантами". Я счастлив, что появился первый софт, который это расхождение снимает. То есть можно и криволинейные железяки из куска металла вылепливать, и трубопроводы из стандартных каталогов набирать в одном и том же софте.

2. CATIA 6 с файлов переведена на базу данных (как я понял, есть варианты выбора самой базы), и вся линейка софта V6 PLM 2.0 по факту стала датацентрической по всем атрибутам, а не только по выдергиваемым в "специальное хранилище для части информации" типа ProjectWise или SmartPlant Foundation. Поэтому логический вывод (business rules) работает "из коробки" и там, где у конкурентов его работа проблемна, ибо попадает "промеж баз данных отдельных САПР". В V6 также есть универсальный моделер данных, но на эту тему (как обычно) разговор мало кто поддерживает.

3. В линейке V6 организовано как индексирование базы данных "на лету" (стандартная конфигурация с DB2), так и что-то типа "графического AJAX", что позволило снять ограничение на скорость работы с огромными моделями. Утверждается, что грузили 4млн. индивидуальных деталей (атомная подводная лодка), и оно нормально проворачивалось. Крутое судно (с производством на борту) -- это 1млн. деталей, нефтяные платформы тоже были -- до 5млн. деталей. Навигация как "табличками" (для менеджеров), так и очаровательными "блюдечками с детальками" (для инженеров).

4. V6 уже имеет свой прайс-лист, CATIA 6 уже развернуто на одном из предприятий в России (правда, я думаю, что этому предприятию уже ничего не поможет, кроме бульдозера -- из жалости). В то же время, список предприятий в России, на которых было бы осмысленно разворачивать PLM 2.0 на сегодняшний день, пуст: никто не готов кардинально менять процессы проектирования, организацию работ и корпоративную культуру.

5. Все удачные внедрения в предписанные стандартами моменты времени выдают на бумагу и далее прямиком в архив предписанные стандартами документы в предписанном формате (какой-нибудь "эскизный проект" к указанной начальством дате), а сами живут абсолютно мимо этих стандартов и предписанных ими стадий жизненного цикла и форм выходных продуктов (т.е. мимо СПДС, ЕСКД и т.д.).

6. Внутри этой линейки есть и собственный софт управления требованиями, и софт функционального и логического архитектурного проектирования, и софт управления проектами.

7. ISO 15926 с V6 активно тестируется. Результаты: ранее были попытки экспортировать данные продуктов Dassault Systemes линейки в самых разных стандартах, но безуспешно (особые надежды были на STEP, но тоже "не смогла"), а вот с ISO 15926 наконец-то это начало получаться, и в ближайшее время ожидается штатная поддержка этого стандарта.

8. Архитектурно весь этот софт открыт, и недостающие функции всегда можно вписать самим, если умеешь программировать на Java.

9. Моделирование методом конечных элементов и на Modelica сейчас активно дорабатывается и что-то выйдет в 2010 году. Но никто не знает, что это будет. Но точно будет, ибо это магистральное направление развития (кодовое слово -- SIMULIA). В кулуарах мне посоветовали еще раз обратить особое внимание на LMS Virtual.Lab -- http://www.octava-lms.ru/solutions/virtual/modeling/intro/ (в частности, "возможность пользователям объединить модели, созданные на основе испытаний, с моделями из виртуальных элементов"). Как я понимаю, это тоже все войдет в SIMULIA.

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

Был интересный обмен мнениями: один из участников, когда я обсуждал поэтапный план добавки модулей по мере продвижения по жизненному циклу большого проекта назвал это "планом вендор-lock". Я заметил, что альтернативный план можно назвать "планом зоопарк-lock", и нужно еще доказать, что этот план лучше.
2021 год

Об порождающее моделирование

Некоторые пояснения к моей статье "Порождающее моделирование и моделеориентированная системная инженерия" (http://ailev.livejournal.com/728605.html).

1. Внутреннее и внешнее представления, датацентричность и документоцентричность
Хомский предположил наличие в языке глубинной и поверхностной структур (позднее -- логической и фонетической форм, и далее I-language и E-language -- http://en.wikipedia.org/wiki/Deep_structure, http://en.wikipedia.org/wiki/Transformational_grammar, http://en.wikipedia.org/wiki/Context-free_grammar и т.д.). Все эти слегка различающиеся идеи, выработанные при осмыслении человеческой речи, хорошо приложимы к программной инженерии, и даже шире -- к системной инженерии. Суть этих идей в том, что есть две структуры представления данных: внутренняя и внешняя. Внутренняя (глубокая, логическая) структура представления данных модели полна и целостна, в этой структуре данные модели представлены в "абстрактном синтаксисе" (http://en.wikipedia.org/wiki/Abstract_syntax), как отношения самых разных элементов данных (которые могут пониматься и как операнды, и как операции) между собой. Внутренняя структура используется для "думания" (человеческого или машинного: преобразований этой структуры в соответствии с правилами, которые зачастую хранятся тоже в самой этой внутренней структуре), а также в качестве исходного материала для порождения внешней структуры, которая представляет собой маленькие подмножества (не все элементы данных и не все между ними связи) внутренней структуры, которые представляются в "конкретном синтаксисе" и доступны внешним системам.

а) обычный "моноязыковый" компилятор, в котором входной и выходной языки имеют конкретные синтаксисы, входной язык компилируется во внутреннее представление в виде "абстрактного синтаксического дерева" (abstract syntax tree, AST), а затем над этим деревом производятся различные оптимизирующие преобразования (возможно, включая преобразования суперкомпиляции http://tunes.org/wiki/supercompilation.html). Эти преобразования можно считать также в каком-то смысле "исполнением" программы, при этом результат исполнения -- выдача преобразованного дерева во внутреннем виде, т.е. также в виде абстрактного синтаксического дерева. Далее это дерево "исполняется" еще раз, но при этом порождается (также оптимизированно по каким-то критериям) внешнее представление в "конкретном синтаксисе" (в случае текстового представления иногда говорят о "линеаризации", в случае графического или иного представления -- просто о "порождении").

б) языковые рабочие места (language workbenches) устроены так, что в них существует внутреннее представление "программы" (которая совершенно необязательно является императивной компьютерной программой, а может представлять собой набор данных, "исполнение" которого приводит просто к появлению еще какого-то другого набора данных, т.е. предназначенного для трансформации) в виде абстрактного синтаксического дерева, но это общее AST получается из нескольких входных представлений в конкретных синтаксисах (предметно-специфических языков, domain-specific languages, DSL), в этом внутреннем представлении возможны преобразования, а выходные представления также являются либо DSL, либо языками общего назначения.

Языковое рабочее место -- это тоже "компилятор" (насколько можно говорить о современной интерактивной среде разработки как о "компиляторе"), только по определению в нем несколько входных языков (и состав этих конкретных синтаксисов пополняем) и несколько выходных языков (тоже с пополняемым составом), плюс широкий набор самых разных (оптимизирующих, вычисляющих, эвристических, детализирующих и т.д.) преобразований.

в) OMG MDA следует той же логике: внутреннее представление данных модели не определяется, зато задаются два конкретных синтаксиса для внешних представлений используемых разных DSL: UML со стереотипами для "экранной работы с человеком" и XMI для обмена файлами между программами.


г) Современные САПР (например, продукты линеек SmartPlant, OpenPlant, VNET фирм Intergraph, Bentley, AVEVA) устроены таким же образом, как MDA: у них есть "конкретный синтаксис для внешнего представления для программ" (так называемая "схема"), в котором представимы все данные (и это формат взаимодействия разных программ со специализированным репозиторием хранения самой разной информации моделей промышленных установок SmartPlant Foundation, ProjectWise, Vnet Portal соответственно). В то же время, есть внешние "экранные представления в конкретном синтаксисе для человека", поддерживаемые в "конкретных синтаксисах" отдельных САПР -- P&ID для гидравлических диаграмм, 3D пространственные модели и т.д.. Отдельные САПРы действуют как "моноязыковые" компиляторы, преобразующие специфические языковые конструкции (например, P&ID диаграмм или пространственные контуры и свойства трубопроводов в 3D) в записи на языке "схемы" и укладывающие затем эти записи в репозиторий, что позволяет совместить данные разных моделей в одном хранилище и проверить целостность этих данных.

В принципе, современные САПР -- это те же языковые рабочие места, хотя и с некоторыми отличиями:
-- нет штатной процедуры языкового расширения (если она и есть, то инструментарий доступен только фирме-изготовителю, время от времени предлагающей "новый САПР в линейке")
-- данные модели в форме абстрактного синтаксиса ("внутреннего представления", согласно "схеме") хранятся в отдельной программе -- "репозитории". С другой стороны, в каждом САПР (поддерживающем небольшой тематический набор DSL: P&ID ведь представляют собой несколько разных типов диаграмм!) по необходимости возникает свой "репозиторий" и далее вместо полностью датацентрической модели возникают странные смеси из датацентрики и документоцентрики.

В принципе, внутреннее представление целостного многоязыкового набора моделей датацентрично, а внешние представления (моноязыковые) тех же моделей -- документоцентричны. Поэтому в рамках предлагаемой группы описаний датацентричность и документоцентричность тесно связаны, это две стороны одной и той же медали, и этот подход не отвергает документоцентричность, а добавляет к документоцентричности датацентричность.

2. Порождение
Для чего нужны разные языки? Прежде всего -- для выражения разных множеств операций. Определение "знаний" (порождающих моделей) дается прежде всего в терминах операций, которые с этими "знаниями" (порождающими моделями) можно делать! Нет "операций" с элементами знаний (т.е. нет "исполнения" этих "знаний" в каком-то смысле) -- значит, нет знаний.

С порождающими моделями на одном языке могут работать одни "исполнители" (понимающие операции этого языка), а с этими же моделями, выраженными в другом языке (например, путем "порождения" этого другого языка, т.е. трансформации, компиляции, интерпретации, "исполнения" и т.д.) могут работать другие "исполнители".

а) кремнивая компиляция (она же -- компиляция аппаратуры, http://en.wikipedia.org/wiki/Hardware_compilation). Начальный входной язык -- описание логики интегральной схемы. Промежуточный выходной язык -- описание минимальной логики (оптимизация). Затем эта минимальная логика преобразуется в разводку интегральной микросхемы в соответствии с применяемой технологией изготовления. И уже после этого разводка превращается в команды для управления литографической установкой.

б) абсолютно аналогично устроены средства создания (например, семислойных) печатных плат: на входе принципиальная схема устройства, на выходе (после нескольких различных преобразований/порождений/компиляций) -- команды для управления оборудованием, изготавливающим печатную плату.

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

г) выходной язык 3D-САПР (форма и свойства детали) компилируется в команды управления станками с ЧПУ и наряд-заказы для оператора станка.

3. Жизненный цикл порождающей модели: управление знаниями.
По сути, правильно говорить не столько о "языковом рабочем месте" или "компиляторе" или САПР и т.д., сколько о жизненном цикле порождающей модели и поддержке этого жизненного цикла при помощи разных инструментальных средств -- разной степени интерактивности (редакторы -- компиляторы -- интерпретаторы и т.д.), разной предметной направленности (программная инженерия, системная инженерия) и т.д.

Собственно, "управление знаниями" в некотором узком смысле -- это как раз про порождающие модели, которые проходят разные стадии своих длинных жизненных циклов в непрерывных преобразованиях/"порождениях"/трансформациях/компиляциях/интерпретациях/"исполнениях".

Знание -- это прежде всего про операции с ними. Порождающие модели -- это прежде всего про операции с ними. А там, где есть операции, есть жизненный цикл и его стадии. Правильным объектом рассмотрения является жизненный цикл порождающей модели, а не статично взятая сама по себе одна из форм "порождающей модели" из какого-то места ее жизненного цикла. Куколку бабочки и ее трансформацию в бабочку лучше всего рассматривать, понимая, что сама она произошла из гусеницы, которая в свою очередь произошла из яйца. Порождающие модели проходят такие же драматические преобразования, и нужно все время об этом помнить и управлять именно этим -- откуда они появились, и куда будут употреблены.