Category: лытдыбр

Category was added automatically. Read all entries about "лытдыбр".

2021 год
  • ailev

Закон ОМа: описание [практики] постановки [метода] инженерии схемы данных жизненного цикла

Поскольку объекты мира задаются главным образом через набор операций с ними ("вот это стул -- на нём сидят, вот это стол -- за ним едят"), то каждый онтолет подразумевает какое-то "руководство по эксплуатации", то есть методы действий (каталог компонентов методов) в данной предметной области. СМДМ-методологи обсуждают этот момент как обязательное наличие "двух досок" -- одна объектно-онтологическая (предметная), другая -- оргдеятельностная. На деятельностной доске задаются функциональные свойства объектов, на онтологической доске -- "что такое" эти объекты. Единство Онтолетного и Методологического я бы назвал законом OMа. Развитие предметной области -- это когда онтология и деятельность вдруг расходятся: обнаруживается, что действия производятся (дела идут) не с обозначенными в онтолете продуктами, или (что то же самое) оказывается, что обозначенные в онтолете продукты никем не используются, и происходит что-то другое.

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

Тут есть свои:

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

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

В ISO 15288 декларирование типа вылезает в заголовки. Так, все 25 processes этого стандарта имеют намеренное решение тип (process) включить в заголовок с именем конкретной практики, но в оглавлении это выглядит совершенно избыточным (так, я снял эту типизацию в переводе -- а сейчас вновь задумался, не вернуть ли её). Другой пример из стандартов ISO 15288 -- это рекомендация добавлять тип "система", когда подчеркивается использование системного подхода, например, вместо "самолёт" говорить "система самолёт". Я с этой рекомендацией не соглашаюсь обычно ("всё есть системы, так зачем это каждый раз говорить?"), но сегодня в очередной раз задумался над пользой принудительной типизации.

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

Компромиссным вариантом является "декларирование типа" -- как в языках программирования, типизация показывается явно при первом употреблении объекта. В моём вчерашнем постинге я использовал такой подход к типизации, указывая "практики дисциплины" (заодно указав и отношение композиции дисцилины из практик, и тип "практики" для списка индивидуальных практик дисциплин, и указав тип "дисциплина" для индивидуальных методов типа "Инженерия схемы данных жизненного цикла"). Ежели идти дальше, то для типов нужно указать, из какого онтолета они пришли -- "практика" пришла в явном виде из ISO 24744 (там это process), а "дисциплина" -- путем обобщения разных наборов практик (что отражалось в различных "дисциплинах системной инженерии" -- "дисциплина инженерии требований", "дисциплина инженерии системной архитектуры"). Тут я просто обобщил "практику" вверх до "дисциплины" (а не только вниз до уровня "мероприятия" и "дела", как это делается в онтолете ISO 24774).

Пример с дисциплиной (вновь введенное понятие), практикой (использующейся как в ISO 24744, так и в ISO 24744), мероприятием (использующимся только в 24774 для более мелких практик) и делом (использующимся опять таки как мельчайшая единица как в ISO 24744 и ISO 24774) показывает, что нам не обойтись для моделирования метода собственным онтолетом, который должен входить в .15926O.

Но это не даёт ответа на вопрос, как рэндерить эту типизацию. В отдельном постинге (http://community.livejournal.com/dot15926/16745.html) я выполню упражнение по описанию/рендерингу/представлению практики постановки метода инженерии схемы данных жизненного цикла (которая, по идее, должна быть "специализацией" практики "постановка метода" в дисциплине "ситуационная инженерия методов" -- примерно в том же смысле, в котором мы говорим о "специализации шаблонов").

В качестве упражнения: опустим типы из ISO 24744/24774 в предыдущем предложении -- смысл ведь не изменится! "В отдельном постинге (http://community.livejournal.com/dot15926/16745.html) я выполню упражнение по описанию постановки инженерии схемы данных жизненного цикла (которая, по идее, должна быть специализацией постановки в ситуационной инженерии методов -- примерно в том же смысле, в котором мы говорим о "специализации шаблонов")". Интересно, сколько людей сочтет "более понятным" типизированный вариант, а сколько нетипизированный?

Этот пример также даст понимание, как может выглядеть описание (рендеринг) методологии в части описания практик (я, правда, не понимаю, правильно ли публиковать это в dot15926, ибо речь идет явно об организационной практике -- а тогда это должно идти в praxos. Типичный пример двойной классификации). Обратите внимание, что многие формулировки и типы в этом примере предписаны ISO 24774 (практики, мероприятия, способ нумерации и т.д.), но существенно также используется типизация по ISO 24744 (даже слово "метод" -- это тоже тип к "инженерии схемы данных", наряду с "продуктами работ") -- но не думаю, что требуется как-то специально обозначать эти пространства имён. Всякие объяснения выбранной терминологии тоже опущены (так, "инженерия схема данных" подразумевает прохождение целевой системы схемы данных по полному жизненному циклу -- от замысла и определения пользовательских потребностей до валидации и эксплуатации. "Разработка" же обычно ассоциируется с более коротким жизненным циклом проекта, заканчивающимся на проектировании -- невзирая на совпадение "проектирования" и "изготовления" для информационных продуктов). "Многоуровневые типизации" и "буквальные типизации" (типа "шаблон практики постановки..." -- чтобы показать, что тип "постановки метода инженерии" в ISO 24744 будет не "process", а "ProcessKind", или использование "метод" как обозначение того целого из практик-продуктов-организации, что подлежит постановке) я старался не использовать. Интересно было бы получить замечания, где дополнительная типизация была бы полезна и уместна (а где, наоброт, осталась лишняя). В целом, "остаточная типизация" следует ISO 24774, как ее можно обнаружить в ISO 15288, взятом за образец предлагаемого описания/рендеринга. Заодно в качестве побочного эффекта мы получаем текст "процессного стандарта", выполнение которого можно проверять по ISO 15504 (SPICE), ибо такой текст читается как "описание типового процесса" (reference process model) в смысле этого стандарта оценки соответствия.
2021 год
  • ailev

Семантические вики и прочий инструментарий

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

Semantic Wiki (для опытов с рендерингом ISO24744 прежде всего):



Для этого же текстовый редактор Aloha (http://www.slideshare.net/draftkraft/aloha-editor-semantic-concept), который сейчас дорабатывается в проекте IKS (http://www.iks-project.eu/launching-iks-semantic-editor-development-group). Хотя сам проект не слишком интересен, очень интересно поглядеть, что в головах у людей, которые хотят сделать "большой бесплатный инструментарий, и срочно": http://www.iks-project.eu/iks-story/approach (подробности -- http://wiki.iks-project.eu/index.php/Main_Page). Но сам подход: гранты по 5-7 тыс. евро для 40 content management systems, которые решат себе это встроить. Отдельно стоит поглядеть на собираемые сообществом мечты (user stories): http://wiki.iks-project.eu/index.php/User-stories. Мечтатели, ведь на их инструментах такого не сделаешь.

TopBraid http://www.topquadrant.com/products/TB_Composer.html -- это Eclipse плагин. Работает с AllegroGraph как triple store (но может и на Jena SDB/TDB, и на Oracle 11g сесть, не вопрос). Бесплатный есть, но без визуального редактирования и без утилит импорта-экспорта. Особо нужно обратить внимание на UISPIN и прочие расширения по сравнению со стандартной OWL-технологией (см. их кухню http://composing-the-semantic-web.blogspot.com/).
AllegroGraph (бесплатный для 50 миллионов триплов, даже для экспериментов с ISO15926 сгодится): http://www.franz.com/agraph/allegrograph/ (Allegrograph 4 для Windows будет через некоторое неизвестное время. Пока только Linux. Ну, или AllegroGraph 3.3).
Это всё Common Lisp (http://www.franz.com/products/allegrocl/). Суровые решения для суровых программистов. Заявлениям про Persistent AI Built-In, All the Way DownTM охотно верю. Искусственный интеллект, задорого, для всех сумевших сколотить команду естественных интеллектов, способную с этим хозяйством разобраться.

Тут нужно отдельно рассказать про Simantics (https://www.simantics.org), у которого сложная судьба:
-- попробовали ризонеры для OWL, которые были в 2006г. Все они оказались медленными, а проблема удаления утверждений проблематичной.
-- использовали OWL-подобный язык с семантикой закрытого мира в 2007-2008г. Эффективно для валидации данных, но недостаточно выразительно и плохо было генерировать код.
-- тогда вдохновились MOF и в 2008г. разбили язык на две части: ограниченный UML-подобный язык для генерации кода, поддержки целостности данных и достаточно выразительный для большинства ограничений и полный по Тьюрингу язык ограничений для описания сложных правил моделирования.
-- в 2005 году попробовали три разных triple store, в итоге в 2006 году начали делать своё хранилище -- и сейчас у них есть кластеры и версионирование.
Версия 1.2 сдвинута на октябрь (думаю, к декабрю выпустят ;)

В принципе, нужно погулять еще по списку 185 инструментов, который я уже приводил: http://www.mkbergman.com/904/listing-of-185-ontology-building-tools/

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

Контрольные вопросы для этих платформ:
-- смогу ли я вкачать туда схему ISO 15926 на OWL?
-- смогу ли я представить там пару-тройку классификаторов (class-of-class) в отдельных окошечках?
-- смогу ли я прикрутить туда механизм шаблонов ISO 15926?

Вообще-то требуется понять уровень замаха:
1. мы пишем Schema Editor с темплейтами. И начинаем моделирование, медленно и печально.
2. параллельно мы пишем language workbench (примерно 5 лет), базовая функциональность -- DSL IDE. Вариант: мы пишем это на каком-нибудь готовом софте language workbench, переделывая java-oriented language workbench в declarative/ontology-based language workbench (примерно год). Подробнее я об этом писал в прошлый раз (http://community.livejournal.com/dot15926/6633.html).
3. на language workbench (через год, а потом через пять лет -- вторая версия на "собственном" софте, что из предыдущей строчки) мы пишем PraxOS Composer для ISO 24744 с расширениями как первое приложение. Этот Праксос Композер будет совсем как ARIS, только диаграммки в нём будут правильные (жизненного цикла, пула продуктов и т.д. -- для начала пара десятков диаграмм организационной модели). Это займет год: графический интерфейс для намоделированного в пункте 1.
4. на Composer мы пишем методы PraxOS, и эти методы будут сразу поддержаны моделированием в тамошних DSL (т.е. оргдиаграммах). Это еще пара лет, чтобы получилось прилично. Use cases берем не только из ситуационной инженерии методов (как нам казалось раньше -- описываем методы, чтобы их можно было прочесть новичкам и делать в них запросы профессионалам), а из насущных задач оргдизайна (то есть применения методов PraxOS: рисование описанных в методах languages и notations диаграмм). То есть в методе будет сказано: "нарисуй модель жизненного цикла /language=24744-timecycle, /notation=timecycle-as-timeline", и Композер тут же поддержит построение этой диаграммы для конкретного endeavour.
5. Мы знамениты, ура. Даем интервью, раздаем автографы.

Увиденное у поставщиков САПР меня сильно опечалило, у них ничего толкового для ISO 15926 нет. Нужно недельку поглазеть по сторонам. И таки делать самим. Что именно делать (отличия от того, что мы тут обсуждали раньше) я выделил болдом. Это важно. Я просто раньше не понимал, что метамодель ISO 24744 после ее некоторого расширения дает нужные для организационных проектов диаграммы, и они-то и есть потребные DSL! То есть методы могут быть описаны примерно так, как они описываются сейчас (словами), но их применение в endeavour сводится к моделированию с использованием диаграмм, а не написанию уточненных текстов методов! Много-много связанных друг с другом типов диаграмм WYSIWYG -- это как раз и есть language workbench. А связность гарантирует типизация всех объектов из этих диаграмм в терминах Части второй. Организационный моделер нужно начинать со Схемы, состоящей из самой общей картины мира -- Части второй -- и тогда этот организационный моделер (универсальный моделер, declarative/ontology-based language workbench) пережуёт любые предметные области и не поперхнётся.