Стратегирование в ISO 24744. Первый черновик.
1. По идее, этот постинг нужно было бы писать на языке 24744, расширенном средствами стратегирования. Но поскольку этих средств сейчас нет, будем использовать bootstraping (то есть пишем уж как можем, а после создания всех необходимых продуктов -- самого DSL-24744 и описываемых в этом постинге средств расширения) переписка в "представление для
( Read more... )
WorkUnitKind и Outcome - это несомненно правильно.
Кстати, в метамодели нет способа сказать, что если какой-то *Kind декомпозирован, то он становится абстрактым классом. Видимо, не имелось в виду, что Виды будут декомпозированы на несколько уровней аж. А если на них строить деревья - придётся декомпозировать глубоко.
Вообще же я бы не пытался засунуть чужеродную для домена деятельности "риторическую" часть в атрибуты. Надо честно объявить новый класс Assumptions среди SupportClasses, с тремя подкласами: NessesaryAssumptions, ParallelAssummptions и SufficiencyAssumptions.
1. Что метамодель не позволяет на этапе разработки методологии управлять конфигурацией путём регистрации альтернатив для будущего отбрасывания - большой недостаток. Кстати, и развилки процесса на этапе предпринятия тоже придётся, видимо, моделировать через достижение разными продуктами разных стадий готовности, как обсуждается в предыдущем постинге. Вообще чем больше думаю, тем больше эта невозможность гладкого сращивания с каким-нибудь BPMN меня беспокоит :-(
2. Не понятно - в чём вопросы? Да, Outcomes никак не классифицируются, состояния мира не делятся на группы.
В моих предположениях - класс Assumptions должен связываться в WorkUnitKind отношением много к одному.
3. Это уже уровень низа КДР, выбор технологий, и не имеет отношения к верхнему уровню.
Reply
b) В метамодели 24744 много чего нельзя сказать, что нужно говорить в языке OCL (язык ограничений для UML, а на самом деле полноценный логический язык, на котором можно повторить любую диаграмму, плюс задать любую аксиоматику в пределах логической парадигмы уж не помню, какой именно логики). Так что "становится абстрактным классом" при декомпозиции, или еще какое-то "логическое поведение" пока недоступно. Не думаю, чтобы авторы задумывались глубоко над этим вопросом.
c) Суть моего постинга как раз в том, что в модели деятельности обосновательная часть важна. Есть еще один элемент этих обоснований (в assurance case вводится еще argument, который суть применяемого способа доказательства), но с этим нужно разбираться специально, я тут не большой специалист. Записал в вопросы.
d) Насчет объявления нового класса "элементы обоснования" и засовывания туда всего нового -- это полностью согласуется с правилом расширения метамодели (я добавил в постинг цитату этого правила). Тут нужно определиться: существенно усложнить модель, или соблюсти стандарт (само правило сформулировано в ОО-форме, если мы меняем язык представления на ISO15926, то там уже "никаких атрибутов", а какие-нибудь фреймы-слоты, и переусложнять модель лишними связями и сущностями не хочется "для проформы". Это, наверное, нужно для того, чтобы схемы разных композеров состыковывались, при этом у самих авторов ведь есть ОО-композер, так что им в голову не могло прийти, что люди могут не ОО-представление использовать, и не UML).
1. Я считаю, что нужно просто перекодировать метамодель в OIM, а дальше развивать эту OIM. Там и многовариантное будущее легче цеплять, и BPMN гармонизировать и много чего еще делать. Внутренним форматом должен быть полноценный ISO 15926, а не специализированная для 24744 (т.е. для UML) времянка. Переход к онтологическим хитростям наша сила, ее и нужно развивать.
2. Состояния мира обычно составные: каждый Outcome является описательным аспектом состояния мира. Заметим, что результатов (состояний мира) даже на диаграммах может быть много у одной работы. Например, "у нас много денег" и "ни один кролик не пострадал" -- и оба этих результата (состояния мира) наличествуют после какой-то работы ("отдать кролика юннатам [а не "отдать кролика в общепит]) одновременно. Это все-таки результаты, а принадлежат они как "состояниям мира". Есть всякие ЖЯ, НЖЯ (это ведь результаты! Хотя проходят по линии "явлений", "феноменов", но затем выясняется, что у них роль -- результаты каких-то действий) -- может быть, это тоже нужно как-то отразить (хотя не факт: всего Голдратта ведь не нужно втаскивать. Впрочем, нужно еще разобраться, что нужно втаскивать).
И нужно ведь потом будет это еще и в виде OIM подготовить, так что онтологические разбирательства еще будут. Может, лучше их иметь сразу, а не потом.
3.Я имею ввиду не столько "содержание", сколько "форму" с выделением особого объекта с атрибутом для связи двух других объектов -- например, у меня Обстоятельство дается как атрибут к Outcome, а тут нужно будет завести новый класс для Обстоятельства, прокинуть связь к Результату... Замечу, что по правилам расширения стандарта атрибут к Outcome нельзя делать, а можно делать только подтип этого Outcome и уже у него добавлять атрибут, или дополнительный класс. Я и думаю, как сделать правильно: попроще атрибутно, или покруче новыми классами и связями (т.е. факториентированно, да еще и с соблюдением консервативных правил расширения: порождая новые сущности без надобности).
Reply
Leave a comment