?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Обоснование качества моделирования методов [05 Jan 2010|12:10am]
1. Модель качества концептуальных моделей SEQUAL (http://en.wikipedia.org/wiki/SEQUAL_framework) основана на семиотических принципах (ага: синтаксис, семантика, прагматика и т.д.). К продуктной модели качества моделей SEQUAL добавляется процессная модель качества QoMo, явно поминающая ситуационную инженерию методов (http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-365/paper12.pdf).

2. Построенная на принципах учета Руководство моделирования (Guidlines of Modeling, GoM --http://www.pim.uni-due.de/fileadmin/Publikationen/paperER98.pdf),


3. Семь руководящих указаний процессного моделирования (seven process modeling guidlines, 7PMG -- http://wwwis.win.tue.nl/~wvdaalst/publications/z7.pdf).

4. SIQ -- похож на SEQUAL, но прямо привязывает качество продукта (модели) к верификации, валидации и сертификации (а вот ссылки открытой нету). Сюда тоже есть процессная добавка (http://wwwis.win.tue.nl/~wvdaalst/BPMcenter/reports/2009/BPM-09-02.pdf).

Другие подходы включают сведение моделей к обычному софту, и далее просто применение стандартов качества софта (например, ISOшных).

Это все подходы "сверху вниз". Подходами "снизу вверх" считается использование разных сложносочиненных метрик качества, и исследование того, как эти метрики связаны с ошибками (типичное исследование такого сорта -- On the Correlation between Process Model Metrics and Errors, http://crpit.com/confpapers/CRPITV83Mendling.pdf).

Это все весьма важно, ибо создание любых артефактов требует обоснования их качества. Есть множество работ по обоснованию качества требований, обоснованию качества архитектуры, но вот по обоснованию качества моделирования (что бы ни значило тут это слово -- например, "программирование не компьютеров") пока есть некоторый дефицит.

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

Нужно бы раскопать историю, почему в инженерии изо всех методов обоснования выиграл именно assurance case, и какие методы проиграли в соревновании с этим assurance case (ибо везде говорится, что схлестнулась дюжина методов оценки качества, и assurance case у них выиграл в ходе попыток стандартизации. И тут важно понять, что там исторически произошло, чтобы второй раз не наступить на эти грабли, теперь с моделированием).

Еще один аспект, почему интересно смотреть эти работы -- это ведь попытка рефлексии того, что делают модельеры. А рефлексия -- это всегда интересно.
6 comments|post comment

Моделеориентированная системная инженерия: спецвыпуск INCOSE INSIGHT [05 Jan 2010|09:49pm]
Нашлась ссылка на свободно выложенный 4-й выпуск 12-го тома INCOSE INSIGHT -- спецвыпуск по моделе-ориентированной системной инженерии (да, этот выпуск включает и мою в нем статью!): http://www.omgsysml.org/INCOSE-INSIGHT-vol-12-issue-4-Dec_09-MBSE_Theme.pdf

Читать это нужно, сообразуясь с общим настроением, выраженным в обзоре методов системной инженерии, которые претендуют на поддержку моделеориентированности -- http://www.opcat.com/docs/MBSE_Methodology_Survey_RevB.pdf

Моя критика всех этих "найдем щастье в UML/SysML" настроений как раз и высказана в опубликованной статье, тут могу лишь добавить:

1. Путаница между собственно методологией разработки и используемыми нотациями огромная. Обсуждение примерно соответствует этапу method engineering в софте: средства собственно моделирования (нотации, паттерны моделирования) и процесс моделирования (что вообще делать и в каком порядке) дико перепутаны. В софте это было четко разведено появлением ситуационной инженерии методов (т.е. детальным разбирательством с метамоделями, в число которых, заметим, включили и модели).

2. Нечеткое определение, какого сорта модели являются признаком моделеориентированной системной инженерией, и в какой они должны быть роли, чтобы данную методологию считать "ориентированной" на модели, а не просто использующей модели в качестве какого-то дополнительного средства.

3. Игнорирование развития современных САПР, основанных на онтологической интеграции данных. Интегрирование моделирования в эти САПР происходит на основании общей онтологии (а собственно UML там если и стоит, как в Intergraph, так сбоку и не по существу) -- и поэтому не связано жестко с типом используемых моделей. В основе каждого современного САПР лежит универсальный моделер, и это явно не UML-моделер.

4. В любом случае, тезис пропихивателей UML/SysML о том, что "нотации разные нужны, нотации разные важны" и нельзя иметь "одно моделирование для всех" (это аргумент в пользу разнообразия используемых диаграмм в одном языке) будет доведен до экстремума: нотаций должно быть столько, сколько нужно для решения задачи. И это ведет к DSM (domain specific modeling) и DSL (domain specific languages) -- похоже, что "программирование некомпьютерных программ называется моделированием/проектированием" (ср. нейролингвистическое программирование, в котором главное слово -- "модель"), поэтому я не слишком разделяю предметно-ориентированное моделирование, предметно-ориентированное проектирование и предметно-ориентированные языки (по факту означающее "предметно-ориентированное программирование").
1 comment|post comment

navigation
[ viewing | January 5th, 2010 ]
[ go | previous day|next day ]