Интегрируем: целе-ориентированная инженерия требований и структурированные инженерные обоснования.
Disclaimer: чтение этого целевого обосновательного обзора требует некоторого знакомства с моими текстами по требовательной инженерии (и чуть меньше -- обоснованиям), но и в этом случае понимание не гарантируется без вчитывания в тексты по приводимым ссылкам. Еще можно вежливо указать на Гугль, в котором есть ответы на все вопросы. Царской дороги в описываемые мной тут края, похоже, нет, в эти звезды дорога лежит через высококачественные тернии и знакомство с курсом логики (знания из этого курса операций с булевыми переменными будет явно недостаточно).
Затрагиваемые мной темы практически не обсуждаются в "классической" инженерии требований (http://www.requirementsnetwork.com/ -- одно из гнезд нынешних требовательных инженеров, мыслительный горизонт их ограничен UML).
Увы, кавалерийского наскока на целеориентированные подходы у меня не получилось -- тамошнее болото стандартов/языков/нотаций оказалось слишком большим и глубоким. Придется брать связку "цели-обоснования-требования-модели" осадой. Все целевые-обосновательные подходы образуют анклавы в разных частях V-диаграммы:
-- GORE в начале,
-- assurance case в конце,
-- architecture/design rationale поближе к середине
-- наверняка найдется еще что-нибудь из этой же серии, такое же не подозревающее друг о друге, как все эти независимые направления.
Я почему-то не нашел никаких перекрестных ссылок в работах по этим направлениям -- хотя все они по большому счету про одно и то же: каким образом использовать структурированное представление логики рассуждения в инженерной практике. Мой провалившийся кавалерийский наскок главным образом был связан с надеждой, что я быстро-быстро найду работу (и софт) какой-нибудь исследовательской группы, которая уже разобралась с интеграцией идей всех этих подходах на манер того, что мы делаем в PraxOS. Увы. Либо они все провалились в разбирательстве, либо никто не озаботился -- и я пока единственный (что вряд ли, но и этому не удивлюсь).
1. Общие корни: логика.
Вся эта "целеориентированность" и "обоснованность" выражает обычный ход рассуждений (reason), доказательств (proofs) и аргументирования (argumentation). Литературы на эту тему более чем достаточно, достаточно вспомнить про дедуктивный и индуктивный метод, в совокупности составляющих "научный метод" (см., например, http://physics.suite101.com/article.cfm/induction_vs_deduction_in_science) и далее утонуть в разговоре о соотношении инженерии и исследований/науки.
Еще более правильно считать, что "это просто логика, сынок" (http://philosophy.lander.edu/logic/index.html) -- именно логика озабочена правильностью рассуждений и аргументации.
Понятно, что вариаций на эти темы более чем достаточно -- особенно, если учесть, что логика это раздел гносеологии/эпистемологии (а в гегелевско-марксистском понимании так и вообще это про одно и то же -- http://ru.wikipedia.org/wiki/%D0%93%D0%BD%D0%BE%D1%81%D0%B5%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F, поищите слово "логика" на этой странице).
Традиционно аргументирование развивалось не только в науке, но и в юридической практике -- поэтому первые работы, на которые опираются очень многие "инженерные" подходы, касаются тематики legal argument, причем в варианте case-based theory(а не rule-based, см. статью аж 1997г. -- http://logic.stanford.edu/classes/cs204/readings/mccarty1997.pdf. С тех пор в этой сфере довольно далеко ушли, и не факт, что инженеры или даже софтовые инженеры продвинулись дальше).
2. Целеориентированная инженерия требований
GORE -- goal-oriented requirements engineering -- это про "раннюю инженерию требований" (early requirement engineering), в самом начале проекта, когда еще непонятно что делать. Цели, намерения, концептуальное моделирование -- см., например, http://mis.sauder.ubc.ca/rigim2008/ и http://www.cin.ufpe.br/~rigim09/ (и там темы и работы авторов из оргкомитета).
Пересекаются два основных языка: use cases (сценарии использования, тут case переводится не так, как cases из, например, assurance case) и собственно целеориентированные языки. Я уже об этом писал неоднократно (http://ailev.livejournal.com/800769.html, или списочек нотаций для работы социотехника в инженерии требований -- http://ailev.livejournal.com/810548.html). Основная идея целеориентированности в инженерии требований: "требования возникают из-за того, что люди что-то хотят, у них есть цели. Давайте обсудим цели в сочетании со средствами их достижения. Заодно запишем, чьи эти цели -- и при разбирательстве развилок в выборе средств будет появляться много-много традиционно выглядящих требований". Сюда можно отнести:
-- URN (User requirements notation, в которой целеориентированный язык GRL, goal requirements language): список литературы http://jucmnav.softwareengineering.ca/ucm/bin/view/UCM/UCMVirtualLibraryAllPubs, хотя основной упор в литературе и делается на use case maps (подозрительно напоминающая BPMN нотация), в последние годы есть публикации и по GRL.
-- чего хотят в URN=GRL+UCM? Перехода от инженерии требований к архитектурному проектированию: http://www.cs.toronto.edu/km/GRL/from-r2a/fromr2a/straw01.pdf
-- подход агентского программирования i* (http://istar.rwth-aachen.de/tiki-index.php?page_ref_id=200), в котором тоже предложена неформальная нотация для инженерии требований (имеющая множество вариантов): список литературы http://istar.rwth-aachen.de/tiki-index.php?page=Requirements%20Engineering обрывается на 2005 году, но это далеко не конец истории.
-- NOMOS, подход к целеориентированному моделированию требований в техническом регулировании (требования+права): работы Alberto Siena https://sites.google.com/site/albertosiena/
-- OMG BMM, где дается тот же анализ "целей-средств": http://www.omg.org/spec/BMM/1.1/Beta2/PDF/
-- карты действий и результатов Голдратта (напомню, что оригинальный язык там такой: Strategy and Tactics tree, и кроме этих Strategy и Tactic указываются разные Assumptions), которые сводятся к более-менее структурированному представлению тех же means-ends (целей-средств) с их каким-то обоснованием (но про собственно обоснования -- позже, ибо карты действий и результатов Голдратта появляются не столько в начале жизненного цикла, сколько ближе к его концу -- и тем самым попадают больше в "обоснования"). Ссылки можно найти в конце страницы http://praxos.ru/index.php/%D0%9A%D0%B0%D1%80%D1%82%D0%B0_%D0%B4%D0%B5%D0%B9%D1%81%D1%82%D0%B2%D0%B8%D0%B9_%D0%B8_%D1%80%D0%B5%D0%B7%D1%83%D0%BB%D1%8C%D1%82%D0%B0%D1%82%D0%BE%D0%B2
-- Goal-oriented software engineering (http://www.cs.toronto.edu/km/goal_oriented/index.html) -- это опять про то же самое: как справиться с нефункциональными требованиями в программной инженерии (http://www.utdallas.edu/~chung/BOOK/book.html), тут же аспект-ориентированная инженерия требований (http://www.cs.toronto.edu/cser/aore.html) и так далее все про инженерию требований. В основе этого подхода -- The tradeoffs among goals, soft-goals, tasks and resources are represented in a soft-goal interdependence graph (SIG).
-- UPDATE: в ArchiMate 2.0 (вышел 31 января 2012г., http://ailev.livejournal.com/978200.html) требования к архитектуре задаются дополнением целеполагания (motivational) и полностью соответствуют подходу GORE.
3. Обоснования
Я перевожу assurance case, как "обоснование" (хотя stepanbezusov считает, что по смыслу тут лучше "уверенность", но русскоязычная инженерная практика дает для артефакта этих методов имя "обоснование" -- именно что "обоснование уверенности").
Поскольку обоснования "по традиции" близко к концу жизненного цикла (невзирая на призывы и заклинания вести обоснование с самого начала работы, а не оставлять на последний момент), то все сводится к "доказательству" того, что заявленные свойства системы наличествуют. И доказательство идет по принципу "как в суде" -- с общим наименованием подхода как assurance case (с вариантами dependability case, safety case, security case, requirement case, architectural quality case).
Не забываем, что требование обоснований заложено в ISO 15026, идущий в пару к ISO 15288.
Презентация о том, что нужно делать assurance case в структурированном (более-менее формальном) виде -- http://www.asq509.org/ht/action/GetDocumentAction/id/476. Именно в ней картинка про "пойдешь вечером учиться пахать новым методом? -- Нет, я и так пашу хуже, чем уже знаю как надо!".
Краеугольным камнем тут идут работы по GSN (Goal Structuring Notation), в которой "заявление о соответствии" называется Goal, тип аргумента -- Strategy, а очевидный факт -- Solution. Понятно, что выбор терминологии связан с акцентом на интенсиональность, а не на собственно "обоснование". Обширная литература может быть найдена тут: http://www.origin-consulting.com/gsnclub/pubs.php, но это только самые основные работы. Обратите внимание, что на авторов существенное влияние оказали работы по языкам паттернов (pattern languages).
GSN сейчас бурно развивается в самых разных направлениях:
-- автоматизация как построения, так и проверки обоснований, http://unit.aist.go.jp/cvs/tr-data/PS2009-010.pdf. Тут проводится непосредственное отождествление "обоснования"-assurance case и "доказательства"-proof, затем предлагается задействовать средства диалоговой помощи в обеспечении доказательств. Сначала говорится, что доказательство -- это функциональная программа, а потом функциональной программой объявляется весь assurance case в нотации "похожей на GSN". Заодно делается заявление, что поскольку assurance case пишется на языке программирования, то модель системы тоже может быть сделана в этом языке, что более тесно свяжет систему и доказательство ее соответствия требованиям.
Лишний раз убеждаюсь, что границы между моделированием и программированием весьма условны.
-- текстовые (не графические) языки для тех же целей "наилучшего выражения аргументации" (аж пять штук -- от обычной прозы через аутлайн к LISP-подобной): http://www.cs.virginia.edu/~cmh7p/ietss08-notations.pdf. Автор надеется, что мода на графические языки типа GSN для аргументации быстро пройдет, и народ вернется к текстам.
-- security assurance case (как ни странно, этому направлению всего несколько лет), подробнейшие обзоры https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/assurance/643-BSI.html, https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/assurance/973-BSI.html
Сверхупрощенный (безо всякой "интенсиональности", тупо "презентация логики доказательства") вариант того же самого, что в GSN -- нотация Claims-Arguments-Evidence (CAE), также известная под звучным именем ASCAD (Adelard Safety Claims Arguments Data): http://www.adelard.com/web/hnav/ASCE/choosing-asce/cae.html
-- эта же нотация (CAE) воспроизведена в виде стереотипов UML в книжке по MFESA при рассмотрении architectural quality case с использованием метода QUASAR -- http://www.freebookspot.in/Books-Method%20Framework%20for%20Engineering%20System%20Architectures.htm книжка, а про QUASAR http://www.sei.cmu.edu/reports/06hb001.pdf
-- предварительное моделирование трех стандартов разработки софта в CAE, для того, чтобы структурировать построение доказательства им соответствия (сначала делается шаблон дерева "заявлений соответствия" стандарту, чтобы потом подставить туда аргументы и факты для конкретного проекта): http://www.acq.osd.mil/sse/docs/2010-01-19-Structured-Assurance-Cases-Ankrum-Kromholz.pdf
-- попытка использовать нотацию CAE для представления результатов работы алгоритмов SAT доказательства правильности программ (как я понял, это первый пример использования SAT в атомной промышленности): http://www.vtt.fi/inf/pdf/workingpapers/2009/W115.pdf. Просто удивительно, что они не пошли по пути "assurance case -- это программа" (вероятно потому, что CAE слишком простая нотация, чтобы думать о ней так же, как думали в вышеприведенной ссылке по автоматизации доказательства с использованием GSN -- http://unit.aist.go.jp/cvs/tr-data/PS2009-010.pdf).
-- обзор целе-ориентированных методов обоснования безопасности для атомных станций (с участием Adelard, чтобы был понятен акцент на CAE): http://www.vtt.fi/inf/pdf/workingpapers/2008/W94.pdf.
4. Обоснования дизайна
Тут совсем другое слово для "обоснований", нежели "обоснования" из assurance case -- речь идет о design/architecture rationale. Возможно, более точно это было бы передать как "соображения" или "объяснение" (в смысле "объяснительной"), но я намеренно даю тот же термин, чтобы показать близость предметных областей.
На первый взгляд, литература по design/architecture rationale существенно отличается от предыдущих "целеориентированностей", но это только на первый взгляд (ибо главная проблема в этом предмете -- capture, то бишь запись возникающих при проектировании соображений по обоснованию сделанных решений. Не хотят люди документировать! Подробнее см. http://rationale.csail.mit.edu/, где пытаются дать людям возможность рисовать только эскизы инженерных решений, а все остальное поручать машине -- особенно, если голосом при этом комментировать, что рисуешь. Основная идея там проста: ежели инженер готов нарисовать и объяснить идею своего решения другому инженеру, то пусть ровно в тех же жестах и выражениях объяснит компьютеру, а дело компьютера понять его. В случае assurance case или требований -- документировать инженеры обязаны, никуда не денешься, поэтому и нет особой проблемы capture таких обоснований. Не запишешь обоснования -- уволят, и точка). Достаточно взглянуть на http://en.wikipedia.org/wiki/Design_rationale -- и тут же видно, что все эти темы "обоснований" (design rationale и assurance case) родственны. По этой ссылке приводится набор моделей аргументации, из которых Toulmin model является общепризнанным предшественником GSN/CAE, и просто удивительно, что в списке методов аргументации design rationale нет собственно GSN или CAE (ну, или URN или i*, которые тоже весьма похожи).
Ряд буквально случайных ссылок:
-- (вездесущий) IDEF6 или Integrated Definition for Design Rationale Capture -- http://en.wikipedia.org/wiki/IDEF6. Хотя этот конкретный метод и имеет больше историческое значение, тем не менее, интересно заметить, что все про то же самое: записать потребности (needs), требования, цели...
-- краткая статья про design rationale в связи с инженерией требований: http://www.edc.ncl.ac.uk/highlight/rhmay2007.php. Содержит фразу "There are currently two approaches to requirements management, these are the Argument based design rationale capture method, and Feature based design rationale capture method". Сильное утверждение, не правда ли?
-- книжка Rationale Management in Software Engineering http://gigapedia.com/items/293620/rationale-management-in-software-engineering
Сюда же я отнес бы и разные языки требований типа Planguage (http://gigapedia.com/items/186360/competitive-engineering--a-handbook-for-systems-engineering--requirements-engineering--and-software-engineering-using-planguage), http://gilb.com/FileGalleries
5. За пределами моего нынешнего рассмотрения
Пока остаются для последующего подробного анализа:
а) функциональные требования (UCM и BPMN -- насколько они похожи?)
б) связь моделирования целей-обоснований/требований и моделирования системы (хотя это рассматривается в тематике design rationale, и так или иначе задевается многими авторами). Это ход на более-менее целостный подход моделе-ориентированной системной инженерии, где строятся прежде всего модели системы, но и к ней модели требований/целей/обоснований тоже. Попробовать пройти по пути добавления всего этого целевого-обосновательного хозяйства в ModelicaML.
в) онтологическая интеграция этих почти одинаковых подходов (работа по EUML, в которой делается мэппинг GRL и i* через использование общей онтологии, тут не считается: http://hal.archives-ouvertes.fr/docs/00/40/51/42/PDF/UEML-CII2009-20.pdf). Меня, конечно, интересует моделирование в ISO 15926, ибо очень легко запутаться в том, что означают все эти assumptions и goals наряду со strategy во всех перечисленных подходах.
г) рекурсия по уровням абстрации и уровням детализации (кроме этого хорошо бы еще разобраться в разнице между уровнями абстракции и уровнями детализации -- тут потребуется хорошая разборка со словом meta, я никак не могу повторно найти статью, где приводилось 6 разных типов отношений, обозначающихся словом "meta").
д) переход с использующегося в текущей литературе по целям-обоснованиям с языков паттернов и структурных описаний в тех или иных нотациях на язык ситуационной инженерии методов. От существительных структур-языков-артефактов к тому, что нужно делать, глаголам.
Затрагиваемые мной темы практически не обсуждаются в "классической" инженерии требований (http://www.requirementsnetwork.com/ -- одно из гнезд нынешних требовательных инженеров, мыслительный горизонт их ограничен UML).
Увы, кавалерийского наскока на целеориентированные подходы у меня не получилось -- тамошнее болото стандартов/языков/нотаций оказалось слишком большим и глубоким. Придется брать связку "цели-обоснования-требования-модели" осадой. Все целевые-обосновательные подходы образуют анклавы в разных частях V-диаграммы:
-- GORE в начале,
-- assurance case в конце,
-- architecture/design rationale поближе к середине
-- наверняка найдется еще что-нибудь из этой же серии, такое же не подозревающее друг о друге, как все эти независимые направления.
Я почему-то не нашел никаких перекрестных ссылок в работах по этим направлениям -- хотя все они по большому счету про одно и то же: каким образом использовать структурированное представление логики рассуждения в инженерной практике. Мой провалившийся кавалерийский наскок главным образом был связан с надеждой, что я быстро-быстро найду работу (и софт) какой-нибудь исследовательской группы, которая уже разобралась с интеграцией идей всех этих подходах на манер того, что мы делаем в PraxOS. Увы. Либо они все провалились в разбирательстве, либо никто не озаботился -- и я пока единственный (что вряд ли, но и этому не удивлюсь).
1. Общие корни: логика.
Вся эта "целеориентированность" и "обоснованность" выражает обычный ход рассуждений (reason), доказательств (proofs) и аргументирования (argumentation). Литературы на эту тему более чем достаточно, достаточно вспомнить про дедуктивный и индуктивный метод, в совокупности составляющих "научный метод" (см., например, http://physics.suite101.com/article.cfm/induction_vs_deduction_in_science) и далее утонуть в разговоре о соотношении инженерии и исследований/науки.
Еще более правильно считать, что "это просто логика, сынок" (http://philosophy.lander.edu/logic/index.html) -- именно логика озабочена правильностью рассуждений и аргументации.
Понятно, что вариаций на эти темы более чем достаточно -- особенно, если учесть, что логика это раздел гносеологии/эпистемологии (а в гегелевско-марксистском понимании так и вообще это про одно и то же -- http://ru.wikipedia.org/wiki/%D0%93%D0%BD%D0%BE%D1%81%D0%B5%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F, поищите слово "логика" на этой странице).
Традиционно аргументирование развивалось не только в науке, но и в юридической практике -- поэтому первые работы, на которые опираются очень многие "инженерные" подходы, касаются тематики legal argument, причем в варианте case-based theory(а не rule-based, см. статью аж 1997г. -- http://logic.stanford.edu/classes/cs204/readings/mccarty1997.pdf. С тех пор в этой сфере довольно далеко ушли, и не факт, что инженеры или даже софтовые инженеры продвинулись дальше).
2. Целеориентированная инженерия требований
GORE -- goal-oriented requirements engineering -- это про "раннюю инженерию требований" (early requirement engineering), в самом начале проекта, когда еще непонятно что делать. Цели, намерения, концептуальное моделирование -- см., например, http://mis.sauder.ubc.ca/rigim2008/ и http://www.cin.ufpe.br/~rigim09/ (и там темы и работы авторов из оргкомитета).
Пересекаются два основных языка: use cases (сценарии использования, тут case переводится не так, как cases из, например, assurance case) и собственно целеориентированные языки. Я уже об этом писал неоднократно (http://ailev.livejournal.com/800769.html, или списочек нотаций для работы социотехника в инженерии требований -- http://ailev.livejournal.com/810548.html). Основная идея целеориентированности в инженерии требований: "требования возникают из-за того, что люди что-то хотят, у них есть цели. Давайте обсудим цели в сочетании со средствами их достижения. Заодно запишем, чьи эти цели -- и при разбирательстве развилок в выборе средств будет появляться много-много традиционно выглядящих требований". Сюда можно отнести:
-- URN (User requirements notation, в которой целеориентированный язык GRL, goal requirements language): список литературы http://jucmnav.softwareengineering.ca/ucm/bin/view/UCM/UCMVirtualLibraryAllPubs, хотя основной упор в литературе и делается на use case maps (подозрительно напоминающая BPMN нотация), в последние годы есть публикации и по GRL.
-- чего хотят в URN=GRL+UCM? Перехода от инженерии требований к архитектурному проектированию: http://www.cs.toronto.edu/km/GRL/from-r2a/fromr2a/straw01.pdf
-- подход агентского программирования i* (http://istar.rwth-aachen.de/tiki-index.php?page_ref_id=200), в котором тоже предложена неформальная нотация для инженерии требований (имеющая множество вариантов): список литературы http://istar.rwth-aachen.de/tiki-index.php?page=Requirements%20Engineering обрывается на 2005 году, но это далеко не конец истории.
-- NOMOS, подход к целеориентированному моделированию требований в техническом регулировании (требования+права): работы Alberto Siena https://sites.google.com/site/albertosiena/
-- OMG BMM, где дается тот же анализ "целей-средств": http://www.omg.org/spec/BMM/1.1/Beta2/PDF/
-- карты действий и результатов Голдратта (напомню, что оригинальный язык там такой: Strategy and Tactics tree, и кроме этих Strategy и Tactic указываются разные Assumptions), которые сводятся к более-менее структурированному представлению тех же means-ends (целей-средств) с их каким-то обоснованием (но про собственно обоснования -- позже, ибо карты действий и результатов Голдратта появляются не столько в начале жизненного цикла, сколько ближе к его концу -- и тем самым попадают больше в "обоснования"). Ссылки можно найти в конце страницы http://praxos.ru/index.php/%D0%9A%D0%B0%D1%80%D1%82%D0%B0_%D0%B4%D0%B5%D0%B9%D1%81%D1%82%D0%B2%D0%B8%D0%B9_%D0%B8_%D1%80%D0%B5%D0%B7%D1%83%D0%BB%D1%8C%D1%82%D0%B0%D1%82%D0%BE%D0%B2
-- Goal-oriented software engineering (http://www.cs.toronto.edu/km/goal_oriented/index.html) -- это опять про то же самое: как справиться с нефункциональными требованиями в программной инженерии (http://www.utdallas.edu/~chung/BOOK/book.html), тут же аспект-ориентированная инженерия требований (http://www.cs.toronto.edu/cser/aore.html) и так далее все про инженерию требований. В основе этого подхода -- The tradeoffs among goals, soft-goals, tasks and resources are represented in a soft-goal interdependence graph (SIG).
-- UPDATE: в ArchiMate 2.0 (вышел 31 января 2012г., http://ailev.livejournal.com/978200.html) требования к архитектуре задаются дополнением целеполагания (motivational) и полностью соответствуют подходу GORE.
3. Обоснования
Я перевожу assurance case, как "обоснование" (хотя stepanbezusov считает, что по смыслу тут лучше "уверенность", но русскоязычная инженерная практика дает для артефакта этих методов имя "обоснование" -- именно что "обоснование уверенности").
Поскольку обоснования "по традиции" близко к концу жизненного цикла (невзирая на призывы и заклинания вести обоснование с самого начала работы, а не оставлять на последний момент), то все сводится к "доказательству" того, что заявленные свойства системы наличествуют. И доказательство идет по принципу "как в суде" -- с общим наименованием подхода как assurance case (с вариантами dependability case, safety case, security case, requirement case, architectural quality case).
Не забываем, что требование обоснований заложено в ISO 15026, идущий в пару к ISO 15288.
Презентация о том, что нужно делать assurance case в структурированном (более-менее формальном) виде -- http://www.asq509.org/ht/action/GetDocumentAction/id/476. Именно в ней картинка про "пойдешь вечером учиться пахать новым методом? -- Нет, я и так пашу хуже, чем уже знаю как надо!".
Краеугольным камнем тут идут работы по GSN (Goal Structuring Notation), в которой "заявление о соответствии" называется Goal, тип аргумента -- Strategy, а очевидный факт -- Solution. Понятно, что выбор терминологии связан с акцентом на интенсиональность, а не на собственно "обоснование". Обширная литература может быть найдена тут: http://www.origin-consulting.com/gsnclub/pubs.php, но это только самые основные работы. Обратите внимание, что на авторов существенное влияние оказали работы по языкам паттернов (pattern languages).
GSN сейчас бурно развивается в самых разных направлениях:
-- автоматизация как построения, так и проверки обоснований, http://unit.aist.go.jp/cvs/tr-data/PS2009-010.pdf. Тут проводится непосредственное отождествление "обоснования"-assurance case и "доказательства"-proof, затем предлагается задействовать средства диалоговой помощи в обеспечении доказательств. Сначала говорится, что доказательство -- это функциональная программа, а потом функциональной программой объявляется весь assurance case в нотации "похожей на GSN". Заодно делается заявление, что поскольку assurance case пишется на языке программирования, то модель системы тоже может быть сделана в этом языке, что более тесно свяжет систему и доказательство ее соответствия требованиям.
Лишний раз убеждаюсь, что границы между моделированием и программированием весьма условны.
-- текстовые (не графические) языки для тех же целей "наилучшего выражения аргументации" (аж пять штук -- от обычной прозы через аутлайн к LISP-подобной): http://www.cs.virginia.edu/~cmh7p/ietss08-notations.pdf. Автор надеется, что мода на графические языки типа GSN для аргументации быстро пройдет, и народ вернется к текстам.
-- security assurance case (как ни странно, этому направлению всего несколько лет), подробнейшие обзоры https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/assurance/643-BSI.html, https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/assurance/973-BSI.html
Сверхупрощенный (безо всякой "интенсиональности", тупо "презентация логики доказательства") вариант того же самого, что в GSN -- нотация Claims-Arguments-Evidence (CAE), также известная под звучным именем ASCAD (Adelard Safety Claims Arguments Data): http://www.adelard.com/web/hnav/ASCE/choosing-asce/cae.html
-- эта же нотация (CAE) воспроизведена в виде стереотипов UML в книжке по MFESA при рассмотрении architectural quality case с использованием метода QUASAR -- http://www.freebookspot.in/Books-Method%20Framework%20for%20Engineering%20System%20Architectures.htm книжка, а про QUASAR http://www.sei.cmu.edu/reports/06hb001.pdf
-- предварительное моделирование трех стандартов разработки софта в CAE, для того, чтобы структурировать построение доказательства им соответствия (сначала делается шаблон дерева "заявлений соответствия" стандарту, чтобы потом подставить туда аргументы и факты для конкретного проекта): http://www.acq.osd.mil/sse/docs/2010-01-19-Structured-Assurance-Cases-Ankrum-Kromholz.pdf
-- попытка использовать нотацию CAE для представления результатов работы алгоритмов SAT доказательства правильности программ (как я понял, это первый пример использования SAT в атомной промышленности): http://www.vtt.fi/inf/pdf/workingpapers/2009/W115.pdf. Просто удивительно, что они не пошли по пути "assurance case -- это программа" (вероятно потому, что CAE слишком простая нотация, чтобы думать о ней так же, как думали в вышеприведенной ссылке по автоматизации доказательства с использованием GSN -- http://unit.aist.go.jp/cvs/tr-data/PS2009-010.pdf).
-- обзор целе-ориентированных методов обоснования безопасности для атомных станций (с участием Adelard, чтобы был понятен акцент на CAE): http://www.vtt.fi/inf/pdf/workingpapers/2008/W94.pdf.
4. Обоснования дизайна
Тут совсем другое слово для "обоснований", нежели "обоснования" из assurance case -- речь идет о design/architecture rationale. Возможно, более точно это было бы передать как "соображения" или "объяснение" (в смысле "объяснительной"), но я намеренно даю тот же термин, чтобы показать близость предметных областей.
На первый взгляд, литература по design/architecture rationale существенно отличается от предыдущих "целеориентированностей", но это только на первый взгляд (ибо главная проблема в этом предмете -- capture, то бишь запись возникающих при проектировании соображений по обоснованию сделанных решений. Не хотят люди документировать! Подробнее см. http://rationale.csail.mit.edu/, где пытаются дать людям возможность рисовать только эскизы инженерных решений, а все остальное поручать машине -- особенно, если голосом при этом комментировать, что рисуешь. Основная идея там проста: ежели инженер готов нарисовать и объяснить идею своего решения другому инженеру, то пусть ровно в тех же жестах и выражениях объяснит компьютеру, а дело компьютера понять его. В случае assurance case или требований -- документировать инженеры обязаны, никуда не денешься, поэтому и нет особой проблемы capture таких обоснований. Не запишешь обоснования -- уволят, и точка). Достаточно взглянуть на http://en.wikipedia.org/wiki/Design_rationale -- и тут же видно, что все эти темы "обоснований" (design rationale и assurance case) родственны. По этой ссылке приводится набор моделей аргументации, из которых Toulmin model является общепризнанным предшественником GSN/CAE, и просто удивительно, что в списке методов аргументации design rationale нет собственно GSN или CAE (ну, или URN или i*, которые тоже весьма похожи).
Ряд буквально случайных ссылок:
-- (вездесущий) IDEF6 или Integrated Definition for Design Rationale Capture -- http://en.wikipedia.org/wiki/IDEF6. Хотя этот конкретный метод и имеет больше историческое значение, тем не менее, интересно заметить, что все про то же самое: записать потребности (needs), требования, цели...
-- краткая статья про design rationale в связи с инженерией требований: http://www.edc.ncl.ac.uk/highlight/rhmay2007.php. Содержит фразу "There are currently two approaches to requirements management, these are the Argument based design rationale capture method, and Feature based design rationale capture method". Сильное утверждение, не правда ли?
-- книжка Rationale Management in Software Engineering http://gigapedia.com/items/293620/rationale-management-in-software-engineering
Сюда же я отнес бы и разные языки требований типа Planguage (http://gigapedia.com/items/186360/competitive-engineering--a-handbook-for-systems-engineering--requirements-engineering--and-software-engineering-using-planguage), http://gilb.com/FileGalleries
5. За пределами моего нынешнего рассмотрения
Пока остаются для последующего подробного анализа:
а) функциональные требования (UCM и BPMN -- насколько они похожи?)
б) связь моделирования целей-обоснований/требований и моделирования системы (хотя это рассматривается в тематике design rationale, и так или иначе задевается многими авторами). Это ход на более-менее целостный подход моделе-ориентированной системной инженерии, где строятся прежде всего модели системы, но и к ней модели требований/целей/обоснований тоже. Попробовать пройти по пути добавления всего этого целевого-обосновательного хозяйства в ModelicaML.
в) онтологическая интеграция этих почти одинаковых подходов (работа по EUML, в которой делается мэппинг GRL и i* через использование общей онтологии, тут не считается: http://hal.archives-ouvertes.fr/docs/00/40/51/42/PDF/UEML-CII2009-20.pdf). Меня, конечно, интересует моделирование в ISO 15926, ибо очень легко запутаться в том, что означают все эти assumptions и goals наряду со strategy во всех перечисленных подходах.
г) рекурсия по уровням абстрации и уровням детализации (кроме этого хорошо бы еще разобраться в разнице между уровнями абстракции и уровнями детализации -- тут потребуется хорошая разборка со словом meta, я никак не могу повторно найти статью, где приводилось 6 разных типов отношений, обозначающихся словом "meta").
д) переход с использующегося в текущей литературе по целям-обоснованиям с языков паттернов и структурных описаний в тех или иных нотациях на язык ситуационной инженерии методов. От существительных структур-языков-артефактов к тому, что нужно делать, глаголам.