Системная медитация
Подумайте о том, чем вы занимаетесь. Но попробуйте подумать об этом культурно, а не "как обычно". В определенных кругах думание не абы как, а определенным способом и по определенному сценарию называют медитацией. Давайте помедитируем над тем, чем вы занимаетесь.
1. Представьте себе то, что вы создаёте. Если вы не бездельничаете, то вы что-то создаёте. Даже если вы создаёте "сервис", то вы создаете не столько сам этот сервис, сколько то, что потом этот сервис оказывает.
2. Обзовите то, что вы создаёте, "целевой системой". Обзовите себя и тех, кто трудится над целевой системой вместе с вами (людей, инструменты, помещения) "обеспечивающей системой".
3. Если вы создаёте много чего разного, то наверняка это либо какой-то повторяющийся цикл создания чего-то однотипного, либо разные части одного большого целого -- подумайте, может это большое целое вы тоже создаете регулярно (раз в жизнь -- это ведь тоже регулярно, не так ли? Впрочем, и ежедневный цикл, и даже ежечасный вполне возможны). Представьте себе "типовую целевую систему" -- воплощающую основные черты того, что вы обычно создаёте.
4. А теперь ключевое усилие: представьте себе вашу типовую целевую систему от момента ее рождения до исчезновения в небытии. Ничего страшного в представлении системы, находящейся одновременно в разных местах и временах нет:
а) представьте ее линией времени, проходящей слева направо графиком. Слева зарождение системы, справо ее славная или бесславная кончина. Не держите это представление в голове, нарисуйте перед собой на бумажке.
б) Все изменения состояния системы должны уместиться в этот график, моменты ключевых смен состояний (их легко вычислить не по тому, что делает сама система -- она ведь значительную часть времени ничего не делает, например, на стадии замысла или стадии изготовления -- а по тому, что меняется то, что делают с системой).
Важно: ваша целевая система -- это не точка, кружочек, картинка, прямоугольничек или даже короткий фильм в ваших мозгах (кортексе), а стрелочка со штрихами перед вами на бумажке (экзокортексе). Все состояния, части системы и т.д. -- это одна система (так, яйцо, гусеница и бабочка -- это одна система, а не три разных). И обозначается одной стрелочкой. Теперь подумайте, и добавьте штришок для отделения стадии пренатального развития яйца. И штришок до оплодотворения. И штришок для сгнивания тушки. Ну, вы поняли уже, в чем фишка.
Не важно: то, что все это переход к 4D-онтологии, и вы мыслите у вашей системы темпоральные части, которые появляются и исчезают (как гусеница в системе бабочки), а система при этом остается сама собой. Думайте не в этих сложных терминах, а в терминах стрелочки-жизненного цикла и отрезков между штришками на этой стрелочке -- стадиях.
Важный вывод из неважного замечания: система -- это не набор фотографий системы в какие-то понравившиеся вам моменты ее времени. Если при слове "яблоко" у вас в голове возникает яблоко, то на бумажке у вас должна быть стрелочка с штришками для переходов от бутончика к цветочку, от цветочка к завязи, от зеленого яблочка к спелому, от спелого -- вот тут подумайте сами, тут самое интересное.
5. Подумайте, где вы обычно начинаете принимать участие в судьбе целевой системы (или система начинает принимать участие в вашей судьбе обеспечивающей системы), и где вы эту систему покидаете. Отметьте это на стрелочке.
6. Нарисуйте рядом похожую стрелочку обеспечивающей системы (для "мы", или для "я" -- на ваш вкус) -- выполните пункт 4 для неё. Можете поупражняться, нарисовать и для этой системы обеспечивающую ее систему (кто делает вас?). Вполне может быть вариант, в котором вы сами себя делаете -- ну что же, и так может быть. Или не так. Подумайте над этим.
7. Теперь можно подумать, как называть вашу целевую типовую систему (ту, первую). Собственно, тут волнует не столько название, сколько определение. Определение делается по следующему образцу:
[название типовой системы] -- это [название ее родовой системы] [описание специализации]. Рама -- это крепление для стекла. Рама -- это набор покрашенных деревяшек. Напишите десяток таких определений, которые могли бы дать разные люди, которым система нужна для разных целей.
8. Какое из этих десяти определений сущностное? Какое из этих определений касается назначения системы? Кому нужна эта система, чтобы ее потреблять (или потреблять оказываемый этой системой сервис)? Сколько этих ролей (система-то у нас типовая, и поэтому я пишу не "людей", а "ролей"), как они называются? Нарисуйте маленькие фигурки вокруг стрелочки там, где они максимально связаны с системой. Обратите внимание, захотелось ли вам нарисовать эти фигурки как человечков или как стрелочки со штришками. Подумайте над этим вопросом некоторое время.
9. Помните, что вы себя как "обеспечивающую систему" уже нарисовали стрелочкой. Что делает эта ваша стрелочка со стрелочкой системы? Как называется та типовая работа, которую вы делаете с целевой системой? Какая ваша роль? Запишите это на бумажку: [моя роль] [что делаю] [целевая система]. Мама моет раму.
10. Каким методом вы делаете то, что делаете? Осознаёте ли вы, что вы делаете (другая формулировка: смогли ли вы ответить на предыдущий вопрос, назвав при этом несколько альтернативных методов, осознанно вами отброшенных)? Впрочем, это тема отдельной и специальной другой медитации.
Теперь вы знаете, что делаете. Или знаете, что этого не знаете.
The most interesting posts in Englis and Russian selected from ~200 feeds on BI, DW, AI and System Engineering Theory. Save your time :)
 |
 |
|
|
||
 |
 |
PLed76
Recent Activity
- Связь моих проектов друг с другом Позавчера я сформулировал ведущиеся мной "дела длинной воли" (http://ailev.livejournal.com/842667.html), а сегодня попробую описать их связанность друг с другом:
1. Системная инженерия нужна, когда нас интересует стабильность успеха в создании чего-то очень большого и сложного, например, нефтяной платформы или атомной электростанции -- в них порядка 4.5млн. индивидуальных деталей, которые нужно запроектировать в одно целое, а затем собрать "в железе и бетоне" к сроку запуска в эксплуатацию от самых разных контракторов из самых разных стран в одном месте так, чтобы все это целое правильно и безопасно заработало. Мы не можем считать, что такие сверхбольшие проекты по наитию делают непонятно как и кем воспитываемые "талантливые главные конструкторы", которые "вырастают сами собой" на самых разных более мелких проектах. Наша задача -- научить любых студентов такой деятельности, как удержание целостности сверхбольших междисциплинарных и международных проектов, в которых участвуют тысячи фирм и тысячи инженеров разных специальностей из разных стран. В России такой профессиональной деятельности студентов пока не учат, и широкая инженерная публика даже не знает о существовании особой профессии и особого ее предмета. В мире же деятельность по обеспечению целостности и технической (а не менеджерской) успешности проекта давно известна под названием "системная инженерия". В США в списке всех возможных работ именно работа системного инженера сейчас является самой лучшей работой (далеко обойдя и работу фондового брокера, и университетского профессора и всех остальных традиционно считающихся "лучшими в плане трудоустройства" специальностей -- http://ailev.livejournal.com/741746.html). Расцвет системной инженерии пришелся на годы, когда компьютеры еще мало могли помочь. За последние два десятка лет почти все практики системной инженерии существенно изменились, причем это влияния компьютеров двояко: а) системные инженеры активно используют компьютерный инструментарий для своей работы, и б) само содержание рабочих практик и связанных с ними рабочих продуктов они заимствуют из программной инженерии, обобщая их на случай "железа" и "бетона".
Проект "Моделеориентированная системная инженерия" занят тем, что для известных проблем "традиционной системной инженерии" (прежде всего для случая "железных" и "бетонных" систем с активным использованием программного обеспечения) предлагает способы их решения за счет новых современных методов борьбы со сложностью (в том числе методов архитектурного, динамического мультифизического, семантического, порождающего моделирования) и сокращению за счет этого сроков и стоимости проекта (что было недостижимо в "традиционной" системной инженерии -- http://ailev.livejournal.com/832543.html). Организационные формы ведения этого проекта разнообразны (можно указать, например, на деятельность в Русском отделении INCOSE http://community.livejournal.com/incose_ru/, или чтение лекций студентам и аспирантам -- http://ailev.livejournal.com/818816.html, или разработка новых видов жизненного цикла и их практик -- http://ailev.livejournal.com/820662.html).
Для того, чтобы организовать производство, на котором практикуют самую современную -- т.е. моделеориентированную -- системную инженерию, приходится заниматься организационной инженерией: это специализация системно-инженерного подхода к организационному строительству. Разработкой методов организационной инженерии занимается отдельный проект:
2. PraxOS: праксеологическая организационная система. Проект по созданию и ведению репозитария методов моделеориентированной организационной инженерии. Существует множество методов организационной работы, один другого моднее. Книжные магазины предлагают сотни наименований "лучших" и "самых правильных" организационных практик: от реинжиниринга бизнес-процессов и проектного управления по PRINCE2 до создания управленческих (и любых других) команд путем их подбора из людей с различными, но взаимодополняющими друг друга мыслительными стилями. Беда еще и в том, что все эти книги (и еще в бОльшем количестве -- статьи в специальных журналах, не говоря уже о "специальных оргтехнологиях" отдельных оргконсультантов) называют одно и то же разными именами, одинаковыми именами разные вещи, и десятки раз изобретают один и тот же организационный велосипед в разном обличье. Беда и в том, что многие широко распространенные организационные/управленческие технологии (типа подсчета себестоимости с "разноской затрат") контрпродуктивны, а некоторые контринтуитивные методы (типа теории ограничений Голдрата) не слишком хорошо известны, но великолепно работают. Нужно разобраться во всем этом месиве управленческих мод и поветрий, и сделать постоянно обновляющийся репозиторий лучших-на-данный-момент (state-of-the-art) практик организационной инженерии, которыми смогли бы легко воспользоваться организаторы -- в том числе организаторы крупных производств, которые практикуют в том числе и принципы системной инженерии. Практики запуска организационных изменений (как массово "расконсервировать мозги" сотрудников для того, чтобы они были в состоянии перейти к новым организационным принципам и освоить методы работы) тоже попадают в репозиторий PraxOS.
Этот проект имеет свой (на данный момент уже с устаревшим содержанием) вебсайт http://praxos.ru и ЖЖ-комьюнити![[info]](http://l-stat.livejournal.com/img/community.gif)
praxos.
Увы, на сегодня в проекте немного внимания уделяется самим организационным методам, ибо для организации такого репозитория готовых к уточнению по ситуации методов требуется научиться описывать любые методы работы в каком-то единообразном и позволяющем гибко детализировать описание формате, а также сделать возможным использование этих (обычно уже находящихся в компьютере) описаний для айтишной поддержки деятельности. Этим занимается еще один проект, для которого важны не столько само содержание методов организационной работы (или работы системного инженера, для описания которой возникают те же проблемы), сколько сам "метод как предмет".
3. Методология: занимается как раз моделированием любых методов (способов работы) -- в том числе методов организационной инженерии и системной инженерии. В методологии на сегодня мы можем выделить несколько крайне интересных и нужных нам направлений:
-- нахождение формата ситуационного описания любых методов деятельности, причем этот формат должен позволять описывать сообразно конкретной ситуации (а не как в учебнике: один раз для всех возможных ситуаций) самую разную деятельность независимо от ее предметной области. Как минимум, формат должен описывать состоящий из стадий вид жизненного цикла продуктов деятельности, используемые рабочие практики, продукты (включая информационные продукты -- документы, модели), используемые знания (например, методы моделирования -- языки и нотации), акторов (в том числе людей и инструменты) и т.д.. Этим занимается методологическая дисциплина "ситуационная инженерия методов" -- http://community.livejournal.com/incose_ru/10830.html. По факту эта методологическая работа трудновыделима из проекта PraxOS, но логически она как раз в проекте "Методология".
-- для того, чтобы интегрировать все появляющиеся в ходе организации производства и самого производства модели, требуется разобраться с используемой в этих моделях онтологией. Онтология -- это разделяемое знание о мире. Тем самым при интеграции различных моделей в одну разделяемую разными заинтересованными сторонами мегамодель мы вынуждены заниматься онтологической инженерией. Но для онтологической инженерии, связанной с компьютерным мегамоделированием (т.е. моделированием с задействованием самых разнообразных моделей и описывающих их метамоделей и нотаций -- http://ailev.livejournal.com/829028.html) требуется создать адекватную программную поддержку. Этим занимается другой проект:
4. .15926 -- это проект по созданию методов языкоориентированного онтологического программирования на базе 4D-онтологии ISO 15926. Идея в том, что где-то на пересечении теории категорий (формальная семантика), онтологической инженерии (соотносимые с реальностью языковые типы) и языкоориентированной (нотации) программной инженерии (алгоритмы/действия) мы можем получить весьма нетривиальные результаты в компактификации знания. Тут недостаточно только вести теоретические разговоры. Для того, чтобы опробовать эти идеи в других проектах, нужно создать инструментальную платформу. Текущая деятельность обсуждается вdot15926.
5. Проект Опенмета предполагает разработку методов инженерной работы с психикой, понимаемой как система из пяти частей: свидетель, сознание, бессознательное, тело и экзокортекс (http://community.livejournal.com/openmeta/211234.html). Современный человек "от интеллектуального станка", даже если брать "белых воротничков" (необязательно даже "офисный планктон", речь может идти и о "креативных" профессиях), неспособен разобраться в предлагаемых новых контринтуитивных методах работы. Если студент считает в порядке вещей за неделю освоить содержание учебника толщиной с палец (а перед экзаменом бывает и быстрее, чем за неделю), то уже через три года после окончания ВУЗа эта его способность куда-то стремительно улетучивается. А ведь от бывшего студента ждут не только освоения уже написанных учебников, но и написания своих! Поэтому нужно использовать инженерный подход к психике, чтобы дать человеку способы быстрого моделирования устройства мышления людей, освоивших или даже создавших новые (чаще всего -- контринтуитивные) методы работы для последующего использования их в быстрой массовой производственной переподготовке. Связь с предыдущими проектами очевидна хотя бы в том, что разрабатываемые там информационные системы должны стать экзокортексом в предлагаемой модели психики. Кроме того, работа с новыми предметными областями требует обучения "умственному манипулированию" с задаваемыми онтологией этих предметных областей объектами (например, для онтологической работы самой по себе нужно уметь в уме представлять небольшие семантические сети с многочисленными мета-отношениями -- как это "внутри головы" делают хорошие онтологи? А как делают впервые решающие подобные задачи студенты? Какова вероятность того, что они сами по себе "переизобретут" хорошие практики работы с подобными объектами "внутри головы"?). Эпизодически в проекте также рассматриваются вопросы мотивации в освоении приемов психической инженерии при работе с собственной психикой -- как и почему люди вдруг решают заняться тренировками, как и почему они эти тренировки бросают, какая мотивация у людей "расконсервировать" возможности собственной психики, и есть ли вообще польза от таких тренировок кроме (часто сомнительного) удовольствия от них самих.
Проект живет в комьюнитиopenmeta.
~1 year on
"Theory" via Павел in Google Reader - Онтология и нотация мегамоделирования Онтология (язык, OIM, DSL) мегамоделирования и нотация к ней -- это то, в каких понятиях (язык!) мы говорим (нотация!) о моделях и их трансформациях (объектах и их морфизмах, текстах и переводах, нотациях и представлениях, сигналах и модулировании, программах и компилировании и т.д.).
Какие у нас есть первоисточники с наборами понятий для выражения этой предметной области?
Теория категорий
MDA и работы текстовиков в нем (типа http://www.eclipse.org/Xtext/)
Работы группы AtlanMod по мегамоделированию
Порождающие грамматики в лингвистике
Работы FONC/STEPS по "цепочкам смыслов"
Работы компиляторщиков вообще и суперкомпиляторщиков в частности (ибо в случае суперкомпиляции нетривиальные преобразования).
Работы по модулированию сигналов
Работы по language workbenches (языкоориентированное программирование)
Языки генерации отчетов, языки верстки и языки стилей (см. тред с![[info]](http://l-stat.livejournal.com/img/userinfo.gif)
justy_tylor в http://ailev.livejournal.com/840204.html).
Нотационный опыт в языках программирования разных парадигм (увы, тут не знаю куда ткнуть пальцем).
Мои работы по Метлану в Опенмете
Что еще пропущено из важного?
Задача: на базе картирования указанных первоисточников обобщить, расширить и доформализовать Метлан в DSL так, чтобы говорить на нем про Мегамодель. Хинт тут в том, что "внутри головы" и "внутри компьютера" -- это про одно и то же, а "вовне головы", "сериализовано" и "сверстано" -- также про одно и то же. От графических языков временно отказываемся.~1 year on
"Theory" via Павел in Google Reader - .15926 и language workbench для этой "платформы типов" Рабочая встреча по проблемам ISO 15926 Русского отделения INCOSE 4 июня 2010г. в Санкт-Петербурге (http://community.livejournal.com/incose_ru/15696.html) была более чем восхитительна (девять человек из трех городов, собравшихся очно и детально обсуждающих на русском языке особенности реализации части 2 стандарта сами по себе сильное зрелище! Хотя до конца обсуждения "дожили" только пятеро: трое "новичков" и один "профи" рассосались по дороге). Обсуждение принесло несколько интересных идей. Вот несколько, которые мне запомнились:
1. Мысль о ISO15926L несколько трансформировалась и сейчас выглядит как система типов с графовой семантикой, которая обеспечивает данные примерно так же, как платформа .NET, но с начальным наполнением этой системы типов RDL ISO 15926 независимо от использующего эту "внешнюю систему типов" языков-минус-типы (компиляторы которых, конечно же, придется немного подхакать, чтобы они вместо своих типов использовали "пришлые"). Тем самым получаем платформу онтологического программирования "дот онто" как принцип, или .15926 в качестве конкретного варианта. В качестве пробных языков в этом проекте указывались Python (эксперименты идут и были доложены), Scala (ибо тамошняя система типов "наиболее похожа"), Factor (по совокупности его заслуг), coq (логическая парадигма тоже имеет право на существование).
Вообще, "онтологическое программирование" (когда программист картирует используемые им типы к RDL -- то есть привязывается к более-менее "стандартной картине мира", а не изобретает картину мира каждый раз заново по любому малейшему поводу) стоило бы рассмотреть отдельно и специально. Это вовсе не использование библиотек или фреймворков, это имено "входные и выходные картины мира", алгоритмы приведения входных в выходные картины мира могли бы быть разными -- т.е. это "недобиблиотеки", или "недофреймворки" с одной стороны, а с другой стороны -- речь идет о моделировании внешней среды (стульев, столов, насосов, кораблей), а не "подсистемы графического вывода, как ее изнутри видят программисты" (окошек, курсора, веб-сервиса и API).
2. Наиболее вероятное первое приложение технологии -- это не развитие прототипов и экспериментов в сторону "еще одного iRING", а аналог EPF Composer со следующими характеристиками:
-- позволяет редактировать тексты, соответствующие метамодели ISO 24744, выраженные в ISO 15926 для последующего расширения. Входной текст -- текст с "разметкой", соответствующий ISO 24744 (текстовый DSL). Выходной текст -- это обычный текст с провязанными ссылками, собранным глоссарием и т.д.
-- редактор позволяет также рисовать простейшие онтологические модельки предметных областей в терминах ISO 15926 (для чего к тестовому питоновскому приложению может быть прикручен GraphVis или что-то подобное). Речь идет о редакторе, позволяющем более просто выражать модели с диаграммами классов и инстансов (включая слои Powertypes/clabjects и экземпляризацию). По факту это позволяет редактировать ModelKinds, ModelUnitKinds и т.д. из ISO 24744 в ходе ситуационной инженерии методов.
-- экспорт моделей в популярные PLM (через фасад ISO15926).
Достоинства такого выбора:
-- альтернатива EPF Composer с более "правильной" метамоделью. Таких приложений сейчас нет, если не считать закрытую и весьма ограниченную разработку zAgile.
Недостатки такого выбора:
-- много мелкой программистской работы, ибо по сути речь идет о создании language workbench (хотя поначалу речь и идет только о парочке DSL-24744 плюс DSL-классов-и-инстансов, в любом случае придется делать IDE надлежащего качества).
Замечу, что "конечная точка" для такого софта описана в пункте 3 тут: http://community.livejournal.com/praxos/1719.html
3. Поскольку пошла интенсивная работа со множеством самых разных DSL и речь идет о более чем одном "базовом языке", имеет смысл подумать об "идейном" (то есть не привязанном к конкретному языку программирования) языкостроительному инструментарию STEPS/FONC (http://www.vpri.org/html/writings.php), который может позволить иметь короткие коды. Описанные там идеи являются "паттернами программирования", а не примерами программ. Так, парсер OMeta2 уже реализован на Python (http://www.allbuttonspressed.com/projects/pymeta) и вполне возможна реализация того же подхода на Scala, Factor и т.д. (неполный список уже имеющихся реализаций на разных языках см. http://tinlizzie.org/ometa/). Про редактор-с-форматированием-по-правилам (что может быть крайне интересно для language workbench) можно сказать то же самое: http://www.vpri.org/pdf/m2010002_lobjects.pdf, http://www.vpri.org/pdf/m2010001_pobjects.pdf. Chains of meaning по факту очень близки к pointless style / теоркатегорному / компиляторщицкому описанию модельных трансформаций -- http://www.vpri.org/pdf/m2010001_pobjects.pdf.
И так далее по всему помянутому списку публикаций: если использовать сильные идеи, то код итоговой language workbench будет коротким и понятным.
4. Замыкание ISO 15926 на базе использования теории категорий. Для начала (это довольно быстро) теория категорий используется для выражения ISO 15926 наряду с FOL и OWL.
Достоинства этого действия: теория категорий по своей сути ближе к зависимым типам (см. для справки: http://community.livejournal.com/ru_deptypes/), нежели "просто FOL". Поэтому такая "перекодировка" будет приближать реализацию .15926
Недостатки: непонятно, какая математика/теория может быть использована для реализации ленивых проверок и минимизации представления семантических сеток ISO 15926 в оперативной памяти (предложения avlasov по ОПSL -- "оперативная память specific language" для представления ISO 15926-семантических сеток в оперативной памяти в ходе вычислений).
Собственно "замыкание" заключается в задании вопроса об онтологическом кодировании понятий теории категорий в терминах части 2 (возможно с жесткими вопросами к онтологическим выборам самой части 2). Тем самым мы имеем шанс получить систему типов, выраженную в собственных терминах. В качестве тестового различения для этой работы приводится неэквивалентность теории категорий теории множеств: в теории множеств объекты "копируются" и "уничтожаются", а вот в теории категорий есть и "некопируемые" и "неуничтожимые бесследно" объекты -- т.е. ведущие себя не как "информационные объекты", а как "материальные объекты".
Достоинства "замыкания" как такового представляются настолько большими и очевидными, что не требуют особого обсуждения.
5. ISO 24744 должен быть картирован в терминах не только части 2, но еще и части 4 (что означает, в частности, что все эксперименты должны вестись не с 201 понятием в оперативной памяти, а сразу с 50тыс. понятий).
Сюрприз оказывается в том, что понятия ISO 24744 в существенной мере высокоуровневы, и большие куски его метамодели таки будут картированы для языка части 2. Вот две дополнительные мысли от этого рассмотрения:
-- согласно теории деятельности, все онтологические рассмотрения имеют смысл только в контексте деятельности. Это означает, что ISO 24744 (ежели мы считаем, что этот стандарт как-то отражает описание деятельности/метода) должен быть глубоко интегрирован с частью 2, и отсутствие его там говорит о теоретической слабости самого ISO 15926.
-- системный подход является "попыткой создания светской онтологии", поэтому его понятия ("система", "жизненный цикл" и т.д.). ISO 24744 кроме "деятельностной" части содержит важнейшие понятия "системо" (если и не system, то очень близкие к lifecycle -- timecycle), а также "мысле" (понятия моделей, языков, нотаций и т.д.).
В любом случае, опыт ISO 24744 по кодированию метода заслуживает тщательного рассмотрения в контексте "правильной части 2" следующего поколения онтологической стандартизации.
6. Варианты упрощения ISO 15926 по тому же принципу, как из SGML был сделан XML: отрезав буквально чуть-чуть и потеряв в редко используемых возможностях, можно получить огромный выигрыш в простоте реализации, понятности и вычислимости. Де-факто по этому пути уже идут:
-- Gellish (где отрезали 4D-семантику со словами "4D время может не пригодиться"
-- OWL-представление (куда вошло отнюдь не всё, выразимое в изначальном EXPRESS-представлении).
7. Масштабируемость реализации крайне важна для действительно больших приложений типа САПРовских, где OIM могут быть весьма развесистыми. Поскольку iRING немасштабируем, то вполне осмысленно заниматься собственными вариантами реализации (видео и слайды докладаavlasov на эту тему тут: http://community.livejournal.com/incose_ru/15696.html).
8. Терминологии для мегамодели нет, и у присутствующих пока нет идей, как ее сделать. Затруднения вызывает даже термин для диаграммы/модели/семантической сетки и т.д., порождаемой какой-то OIM или совокупностью OIM, нарисованных друг на друге (отмеченное Онно Паапом "кодирование OIM более высокого уровня в терминах OIM менее высокого уровня")...~1 year on
"Theory" via Павел in Google Reader