В любом случае, мне крайне импонирует идея работать с концептами по номерам, а не по названиям -- так или иначе добрая половина споров превращается в спор о терминах, вот и легче было бы такие споры решать. Тем более, что в Gellish все эти activity, acting, act и т.д. считаются синонимами -- в зачет идет только суть, концепт. Зато у слова function в зависимости от контекста в Gellish пять разных значений. Слово одно, а суть разная -- омонимы честно отрабатываются, как омонимы.
Еще одна беда в том, что ISO 15288, ISO 15289, да и сам Gellish в его Smart Dictionary части -- абсолютно документоцентричны. Набор терминов для работы с бумажными документами обширен, консистентен, хорошо развит, но никак не продвигает. Даже ISO 42010 с его "архитектурным описанием" документоцентричен. Поэтому нужно разобраться, в каких терминах обсуждать создание и использование датацентрических систем, что такое "информационная модель объекта".
Разберемся с model, view, viewpoint, presentation и representation -- что с этим делать в недокументоцентричном мире. Совершенно очевидно, что все эти слова -- омонимы, в разных предметных областях (контекстах Gellish, микротеориях CYC) эти слова означают разное.
Для начала совершим путешествие в страну Программирование, где документов нет, а проблемы решаются те же самые. Создателям пользовательских интерфейсов приходится мучиться именно с датацентрикой, на которую пользователи хотят смотреть (и которую хотят редактировать) по-разному.
У интерфейсостроителей есть несколько общепринятых вьюпойнтов (на их языке -- архитектурных или дизайн-паттернов), из которых и попробуем извлечь нужную нам онтологию датацентрики:
1. Model-view-controller (http://en.wikipedia.org/wiki/Model-view-controller). Модель -- это данные во внутреннем формате оперирования (например, в базе данных), вью -- данные в формате читаемого человеком "документа" (например, HTML), для модели может быть множество разных вью.
2. Passive view (результат доработки Model-view-presenter, http://en.wikipedia.org/wiki/Model-view-presenter), http://www.martinfowler.com/eaaDev/PassiveScreen.html, а также presentation model (она же application model для смоллтоковцев) http://www.martinfowler.com/eaaDev/PresentationModel.html. Насколько я смог разобраться в этом месиве, тут модель -- тоже родное предметное представление, в терминах которого идет манипулирование, но затем вводится понятие "презентации", как абстрагированного от конкретного изображения со всеми его "скинами, жирностями и курсивами" представления.
3. Presentation-abctraction-control (http://www.martinfowler.com/eaaDev/PresentationModel.html). Presentations is the visual representation of a particular abstraction. Abstraction -- это как раз внутреннее представление.
4. Morphic (http://wiki.squeak.org/squeak/30). Все внимание на вью/презентации модель даже не упоминается.
5. Players and Costumes из Tweak (http://tweakproject.org/TECHNOLOGY/Whitepapers/PlayersandCostumes/), где взято лучшее от Morphic и MVC -- используется так же легко, как Morphic, но так же гибка, как MVC. Модель при этом называется Player, а вью называется Costume. Идея в том, что "актеры ведут костюмы", а "костюмы уведомляют актеров", ежели что-то происходит во внешнем мире. И тут вдруг идет очень знакомое замечание, что The breakthrough here was simply to realize that being a "player" or a"costume" are roles rather than types. In other words, the above definition of costume and player can be applied to any kind of object if it just fullfills the requirements. Это означает, что каждый актер может сам действовать как костюм, а костюм -- как актер. Для одного актера также может быть много костюмов, и он может вести хоть все из них. А дальше рассуждение еще интереснее: актеры и костюмы играют роли, которые находятся в общей онтологии (авторы tweak называют как раз это "моделью").
Акцент во всех этих интерфейсных обсуждениях делается на процессы, поэтому участвующие типы информации -- роли в этих процессах. Важно, что процессы эти двусторонни: интерфейс меняет модель, модель меняет интерфейс. Самое старинное (и поэтому общепринятое) разделение ролей: модель -- однозначно целостна, "внутреннее представление" в удобном для хранения и обработки формате. Вью -- могут быть разные для модели, это то, что показывается в интерфейсе. Более современные представления вводят дополнительные сущности: "презентация" как переформатированный для показа в интерфейсе кусок модели, "костюм" как способ показа в интерфейсе куска модели. И никакого обсуждения conсerns и stakeholders, необходимость множества view просто постулируется. Никакого обсуждения многообразия моделей, она одна, показы ее многообразны, все показы объединяются в интерфейсе.
Итак, у софтовиков:
-- модель -- это единообразно представленные факты об объекте,
-- эти факты могут быть показаны абсолютно разным способом, который называется view
-- вью и факты связаны: редактируя вью, получаешь изменения в фактах, а если поменялись факты в модели, то изменится и вью.
-- самые разные вью объединяются в интерфейс (который и соответствует модели, ибо вью соответствует каким-то частям модели).
В Gellish -- контекст presentation, концепт 4270 view is a specialisation of relator by being visible from a defined perspective (полное определение: view is a relator by being visible from a defined perspective). Рядом 4271 invisible in view is a specialization of related by being not included in the view. Слово point of view не используется, используется perspective. Далее идут разборки с encoded information, которая is a specialization of inanimate physical object intended to appear on an information carrier. Typically as ink or toner on a drawing or other document on paper or as a light in a pattern displayed on a screen or a bit pattern on a machine readable device (специализации по этой линии - annotation element -- symbol -- text и так далее). Явно не то, что нужно (хотя это и на пути к descriptions, в том числе architectural descriptions, в ISO 42010 определяемых как collection of artifacts that document an architecture).
В Enterpise Architecture Frameworks view и viewpoint в большинстве текстов не разделяются (хотя слова model и view используется в полный рост). Заметим, что и в других архитектурных фреймворках (например, софтовых) со словом viewpoint тоже были проблемы. Но во все эти сферы, рассматривающие архитектуры и вью, начинает проникать стандарт ISO 42010, дающий основные определения:
- Architectural Description -- A set of views and additional architectural information.
- Stakeholder -- An individual, group or organization that has at least one concern relating to the system.
- Concern -- A functional or non-functional requirement.
- View -- A set of models representing a system from the perspective of a related set of concerns.
- Viewpoint -- The conventions for creating, depicting and analyzing a view.
- Model -- A particular diagram or description constructed following the method defined in a viewpoint. These provide the specific description of the system, which can include identifiable sub-systems and elements.
Другими словами: модель -- это конкретное описание, созданное по методике и нотации из "библиотечного" вьюпойнта ("документ"), а вью -- это множество моделей, которые можно породить одним вьюпойнтом. Архитектурное описание -- это множество вью (и, тем самым, множество моделей), которое порождается библиотечным набором вьюпойнтов. Архитектурный фреймворк (набор методик и нотаций, которые могут породить архитектурное описание, то бишь набор вью, то бишь набор связанных моделей) -- это набор вьюпойнтов.
Безусловно, это замаскированный документоцентрический взгляд. Как говаривал это другими словами и по другому поводу Лев Григорьев, "ARIS -- это софт для поддержки множества независимых друг от друга картинок, а вовсе не софт организационного моделирования". Но зато ARIS в этом пункте вполне соответствует ISO 42010.
Итак, есть два совершенно разных понимания модели
1. конкретный "отчет", получаемый приложением вьюпойнтного метода к объекту (результат отдельного акта моделирования, "исследования"),
2. общая коллекция фактов, полученная в ходе всех действий по моделированию, независимо от конкретной нотации (правил удобного отображения), предпочитаемой конкретным вьюпойнтом (исходные факты).
ОК, тогда так и назовем: "отчет" и модель (сразу оторвавшись от терминологии ISO 42010 -- а что делать?!). В этой постановке вопроса модель -- одна, а вью построены из "отчетов по модели" (для которых, например, в ОргМастере был сделан даже "мастер отчетов"). Менеджеры не привыкли работать с "моделями", но они отличненько работают с "отчетами", т.е. документами. В Gellish это подтверждается: report is a specialisation of document that record findings of an investigation or study. Typically of longer term relevance. Определение, конечно, работает для обоих определений:
1. investigation or study может быть как моделированием с использованием viewpoint, в результате которого получается модель=документ=отчет.
2. investigation or study может быть запросом к уже имеющимся результатам моделирования, в результате которого получается документ-отчет-по-модели.
Чтобы выйти из документоцентрического тупика, обратимся к треугольнику моделирования (http://ailev.livejournal.com/609062.html). Ибо в деле участвуют не объект и его модель, а объект и целых две его разные модели! Правы и программисты, и "архитекторы" -- просто каждый из них имеет ввиду свою модель!
Неожиданно выясняется, что Gellish-модель (или аналогично устроенная -- SmartPlant Foundation Schema и т.д.) -- это conceptual system. Это, конечно, сильное утверждение, ибо про "концепты" говорится только как о том, что существует "в мире идей". Я бы это объяснял так: в Gellish (и аналогичных системах, опирающихся, например, на ISO 15926, типа Bentley OpenPlant, Intergraph SmartPlant, AVEVA VNet и т.д.) мы работаем не с именами и нотациями, а "по номерам" концептов. И такой набор фактов-во-внутреннем-компьютерном-языке можно приравнять к концептуальной системе. Ага, я хладнокровно приравниваю память компьютера к голове человека. Более того, я даже готов обсуждать ситуацию, когда концепты находятся не "в голове", а "промеж голов" (иначе не могла бы существовать коммуникация). Эти "концепты как номера" тоже вполне могут существовать независимо от конкретных хранилищ данных, в которых ведется их обработка (скажем, Gellish-таблицы, задающие номера примерно 40000 концептов) лежат на sourcefourge, а не только в оперативной или внешней памяти компьютера, который мы "отождествляем" с головой. Аналогия абсолютно намеренная.
Именно концептуальная модель -- модель в программистских model-view-controller и прочих представлениях. А view там относится к символьной модели (презентации концептуальной модели).
Я понимаю, что именно в этом месте (отождествление концептуальной модели и модели в компьютере) можно заработать жесткую критику. Модель в оперативной памяти кажется критикам тоже символьной, а за концептуальной моделью критики резервируют "понимание" в головах людей. Поэтому я очень кратко упомяну основания для принятия такого решения:
1. Ван Ренссен в своей книжке про Gellish очень подробно разжевывает, чем "чистые концепты" (данные как "уникальные номера") отличаются от именованных сущностей -- фактически он описывает технологический механизм отвязки символьной модели от концептуальной модели. В памяти компьютера мы можем оперировать "чистыми концептами", свободными от их символьного выражения -- по крайней мере, пока обсуждение идет инфологически. А у нас исключительно инфологическое обсуждение (то есть не рассматриваем операции передачи данных, конкретных кодировок, распределенного хранения, форматов данных, типов носителей и т.д. -- не рассматриваем даталогию).
2. Конечно, есть автоматические преобразования самих символьных моделей друг в друга (трансформации, трансляции и т.д.) и даже мэппинг концептов, полученных в ходе выделения элементарных фактов, извлеченных из этих символьных моделей. Но работа по подготовке автоматического отождествления концептов делается людьми (а не компьютерами) на основе общей для всех контекстов онтологии (ага, это описано в архитектуре ISO 18876, разжевано в ISO 15926, улучшено в Gellish Modeling Method и т.д.). Кстати, этих отождествляющих концепты людей (модельеры данных, "прикладные онтологи") необходимо тем самым включать в число stakeholders, они имеют свои concerns в отношении управления информацией жизненного цикла системной инженерии и требуют своих собственных символических моделей и средств, их порождающих (view и viewpoints).
Приведу еще одну версию (вдобавок к картинке http://ailev.livejournal.com/609062.html, выдранной из книжки Dietz) треугольника моделирования (из книжки Information Modeling in the new millenium, глава IV The Conceptual Modeling Process and the Notion of a Concept, написанной австралийцами Pramila Gupta и James A.Sykes):
Символы, кстати, онтологически в Gellish находятся довольно высоко -- выше текстов (anything -- concept -- individual object-- whole individual -- physical object -- inanimate physical object -- annotation element -- symbol -- text). Интересно, что binary encoded object находится много выше текста: на том же уровне, что inanimate physical object (а также matter, route, lifeform). Но тут нужно четко понимать, что сама начинка Gellish насквозь документоцентрична -- вот вам определение для binary encoded object, чтобы не было иллюзий: is a physical object that has aspects that has a role as encoded information whereas the encoding conforms with the American Standard Code for Information Interchange (ASCII).
Огрубляя все эти нюансы, мы можем говорить о целевой системе, ее концептуальной модели и ее символьной модели, отражающих (моделирующих) существенные (для стейкхолдеров!) аспекты друг друга, причем в обе стороны, что принципиально.
Теперь мы делаем следующие утверждения по поводу информационного моделирования в системной инженерии:
1. Моделируемая система у нас одна, а не несколько. Все, что интересно стейкхолдерам в реальном мире, мы помещаем в состав системы.
2. Концептуальных моделей (систем в роли моделей) у нас несколько. Но мы их приводим к одной путем отождествления одинаковых концептов разных концептуальных систем (mapping одной системы в другую), при этом имена концептов игнорируются (считается, что даже эти имена принадлежат к символьной модели -- привет локализаторам как языковым, так предметной области). Это полностью соответствует архитектуре ISO 15876, к которой относятся и ISO 15926, и насколько я могу судить, Gellish, а также все остальные "интеграторы данных" на базе онтологического подхода. И эта концептуальная модель называется "данные", "модель данных" и т.д! Получается, что "датацентрический" подход -- это концептуальномоделецентрический!
3. Символьных моделей (систем в роли моделей) у нас несколько, при этом каждая из них моделирует только существенные для того или иного стейкхолдера или их группы черты (интегрированной) концептуальной модели. Символьные модели -- это "отчеты", отражающие запросы стейкхолдеров к концептуальной модели (или попросту -- "запросы к данным"). Символьные модели -- это "выписки", отражающие состояние учета фактов концептуальной модели, или заполненные "шаблоны", отражающие желаемое состояние фактов концептуальной модели (если речь идет о редактировании концептуальной модели, редактировании данных). И на экранах редакторов, и в бумажных документах -- именно символьные модели.
Проблема в том, что отнюдь не все бумажные документы представляют из себя "выписки". Некоторые из них как раз -- "первичка", и проблемы возникают по добавлению содержащихся в них фактов в концептуальную модель (это требует не только "интерпретации", но и "мэппинга"). Основные стандарты архитектурных описаний (например, проекты ревизий ISO 42010) подразумевают именно такой подход, в явном виде требуя появления view correspondence rules, имеющих дело с мэппингом концептов. На наш взгляд, это альтернативный способ описания того, что рутинно делается в промышленности моделирования данных (data modelling industry, самоназвание людей вокруг архитектуры интеграции данных ISO 15876, стандарта ISO 15926, Gellish и других онтологических стандартов).
* * *
Теперь самое время вернуться к Симултреку -- System Engineering Enterprise Architecture Framework (и тут мы неодиноки, этим в мире сейчас только ленивый не занимается, поищите на эту фразу в Гугле). Наша задача при этом -- вписаться в общекультурный контекст, привязаться к общепринятой терминологии. Симултрек должен соответствовать стандарту на архитектурный фреймворк (а это -- новая версия ISO 42010), иначе его шансы на жизнь минимальны.
Продолжение следует.