Описания и методы описания, модели и мета-модели
Само (ролевое/частное/аспектное) описание/view состоит по стандарту ISO 42010 из множества отдельных моделей (models), которые можно трактовать как формальные или неформальные части описания системы, отражающие ещё более частные важные характеристики, чем собранное из этих моделей суммарное ролевое описание. Например, полное системное описание включает в себя финансовое описание предприятия::создатель, но в финансовом описании можно в свою очередь выделить разные модели, нужные для ответа на разные вопросы интересующейся финансами проектной роли: баланс, отчёт о прибылях и убытках (profit and loss, P&L) и денежный поток (cash flow). Если у вас есть только баланс, то вы не ответите на вопрос о безубыточности работы предприятия, а если у вас отчёт о прибылях и убытках и даже баланс, то вы не сможете обсудить кассовый разрыв без наличия документов по денежному потоку. Одно ролевое описание для одного предмета интереса, три разные модели для трёх подпредметов интереса (конечно, предметы интереса/важные характеристики тоже разбиваются на подпредметы/подхарактеристики!).
Каждая из моделей должна быть выполнена с использованием одной из мета-моделей/meta-models/model kinds (это подробно обсуждается в трансдисциплине онтологии), причем каждая из мета-моделей устанавливает определенные языки, правила и приёмы моделирования (соглашения), используемые при разработке модели. Так же как отдельные модели (models), отвечающие на какой-то подинтерес, объединяются в более полное тематическое/ролевое описание (view), так и мета-модели (metamodels/model kinds), определяющие язык, правила и приёмы моделирования, используемые при ролевых/тематических/частных описаниях, объединяются в ролевые/тематические/частные методы описания (viewpoints), отражающие/frame предмет интереса. Методы описания с их мета-моделями описываются часто в документе «соглашение о моделировании», для каких-то данных мета-модель называется часто «модель данных» (данные = модель системы, модель данных = мета-модель системы).
Например, для финансового описания создающей системы-предприятия нужно прежде всего выбрать один из методов описания --- РСБУ (Российские стандарты бухгалтерского учёта) или МСФО (международные стандарты финансовой отчётности). При составлении баланса (одна модель финансового описания) и отчёта о прибыли и убытках (другая модель финансового описания) нужно использовать мета-модели (соглашения по тому, как делать модели) для этих видов моделей из какого-то одного метода описаний --- либо РСБУ, либо МСФО.
И помним, что есть ещё и уровень мета-мета-модели (то, что РСБУ::viewpoint --- это как раз использование материала из нашего курса для присвоения типа, мы сказали, что РСБУ --- это метод описания, использовали тип мета-мета-модели фундаментальной дисциплины, общий тип для всех дисциплин. А РСБУ представляет собой мета-модель, метод описания предметной/прикладной дисциплины).
Проще всего считать, что метод описания --- это набор условных обозначений для многослойных карт-моделей, которые описывают территорию. Одно из следствий рассматриваемой схемы: нельзя делатьролевые/аспектные/частные описания, если в явном виде не рассматривается ролевой/аспектный/частный метод описания.Нельзя ничего описывать, если ты не осознал, как именно ты описываешь, каким способом!
Нельзя делать карты и/или давать рассматривать другим проектным ролям карты, если изготовителю карты и/или другим проектным ролям неизвестна легенда карты и методы картографирования. Карты, сделанные по разным методам описания, потом нельзя сопоставлять друг с другом. Нельзя делать карту, используя слои, подготовленные согласно разным методам картографирования --- нельзя брать подготовленную геодезистами карту водных ресурсов города и подготовленную службами метрополитена карту-схему станций метро и просто накладывать их друг на друга. Нельзя брать баланс по РСБУ, а отчёт о прибылях и убытках делать в МСФО. Все модели (models) из описания (view) должны быть подготовлены с использованием мета-моделей из одного метода описания (viewpoint). И да, метод описаний нужно согласовывать с проектной ролью, ибо в зависимости от предмета интереса и предпочтений роли в характеристиках этого предмета интереса разные проектные роли будут требовать использовать разные методы описаний! Например, финансисты из бухгалтерии будут требовать финансовые описания по МСФО (и у них важным будет описание себестоимости), а операционные менеджеры будут отказываться от таких описаний и настаивать на ведении собственного финансового учёта, потому что они будут считать «себестоимость» вредной и сбивающей с толку характеристикой, настаивая на совершенно других методах финансового расчёта, более пригодных не для целей налогообложения, а для целей операционного менеджмента. Они могли бы настаивать на использовании методов описания, принятых в учёте протока/throughput accounting из теории ограничений Голдратта[1].
Метод описания чаще всего бывает библиотечным (library), это означает, что вместо раскрытия его содержания приводят просто ссылку на литературу по этому методу. Это всё равно как вместо полного текста и картинок легенды карты можно было бы просто дать ссылку на книгу или картографический стандарт, где приведён список условных значков и подробный текст о том, как использовать эти значки для изображения деталей рельефа, флоры, фауны, полезных ископаемых, плотности населения и т.д. Но если нет ещё текста с готовым методом описания, то вам придётся описывать какой-то предмет интереса таким способом, который до сих пор не использовался. Тогда вместо этой ссылки на библиотечный метод описания вы обязаны к описанию приложить документированный вами самими метод описания: без указания метода описания сами описания делать нельзя. Метод описания --- это альфа, так что для свидетельствования состояния этой альфы потребуется артефакт/рабочий продукт/документ. И описание требует документирования, и метод описания требует документирования.
Главное --- это запомнить: любое описание --- это описание системы, любое описание системы сделано с использованием метода описания (даже если описывающий этого не осознаёт), доступно людям описание становится только после его документирования, метод описания --- это описание описания (поэтому уместны вопросы и про метод описания метода описания, и про документирование метода описания метода описания!).
Метод описания (viewpoint) оформляет (frame) целевую характеристику (concern) проектной роли. Одно из следствий рассматриваемой схемы: если у проектной роли/stakeholder нет соответствующейважной характеристики/concern, то описание/view для удовлетворения интереса к этой характеристике не делается (и, соответственно, это описание не документируется, и методописания для него тоже не нужен): описания, в которых не затрагиваются важные для каких-то ролей характеристики, не нужны, они избыточны. Даже если какой-то используемый стандарт требует какого-то описания, но никто его читать не будет (менеджеры просто проверят «для соответствия стандарту») --- такое описание не нужно делать, это бессмысленная трата ресурсов проекта. И наоборот: если упроектной роли есть важная/целевая характеристика (предмет интереса, concern) и начинается её обсуждение, то описание для такой характеристики делается иобязательно документируется. Речь никогда не идёт об устных ответах на вопросы. На бумаге, или в базе данных, или в файлах, но описание должно быть документировано.
Описания (views) согласно ISO 42010 могут быть двух видов: прожекторные (projective) и синтетические (synthetic).
Прожекторные описания --- это как в театральном прожекторе, в котором лампа белого цвета, но мы делаем цветной луч, просто отфильтровывая все цвета кроме того, который нам понравится. По факту это означает, что у нас есть большая база данных, в которой хранятся все связанные между собой разные модели разных ролевых описаний --- все вместе, в одном каком-то формате документирования. Но когда нам нужны данные одной модели (model), то просто из этой совместно хранящейся одной базы данных как документа с системным описанием отфильтровывается только то, что нужно (запрошенные ролевые описания, или даже запрошенные отдельные модели из этих описаний) и отображается в подходящих форматах документов.
Синтетические описания --- это когда наоборот: исходные ролевые описания даны в виде отдельных документов моделей, причём каждая модель документирована не просто как часть одной общей для всех моделей базы данных (как в прожекторных описаниях), а отдельный бумажный или электронный документ. Между этими автономными моделями из отдельных документов устанавливаются правила соответствия (correspondence rules, «этот объект этой модели --- это вон тот элемент вон той модели»), и общая модель системного описания тем самым получается синтетически, объединением отдельных автономных частных моделей. Рассуждения про системные/полные и ролевые/частные описания системы при этом не меняются от того, как собираются эти описания из документации моделей --- сразу в общем документе (прожекторный подход к описаниям) или после создания отдельных документов моделей (синтетический подход).
Синтетические и прожекторные описания оказываются эквивалентными в плане мышления о работе с описаниями, предложенный в ISO 42010 набор понятий работает для обоих вариантов. Просто в синтетических описаниях приходится много сил тратить на согласование независимо подготовленных описаний, «интеграцию данных жизненного цикла». А в прожекторных описаниях приходится много сил тратить ещё до начала моделирования конкретной системы на то, чтобы согласовать методы описания для документирования всех ролевых описаний в одной базе данных. В общем случае, конечно, побеждают синтетические описания, поскольку они не подразумевают предварительной огромной работы по интеграции инструментов моделирования. Но желание иметь прожекторные описания, с которыми потом удобно работать, достаточно сильно. Поэтому современные проекты имеют несколько частных прожекторных описаний, вместе составляющих синтетическое (ибо ни одно из частных прожекторных описаний не отражает все проектные предметы интереса).