Просмотр исходного текста страницы Обоснование архитектуры

'''Обоснование архитектуры''' (design/architecture rationale) — возможно, более точно это было бы передать как "соображения" или "объяснение" (в смысле "объяснительной").

Главная проблема в этом предмете — '''запись (capture) возникающих при проектировании соображений по обоснованию сделанных решений'''. Не хотят люди документировать! Подробнее см. [http://rationale.csail.mit.edu/ Design Rationale], где пытаются дать людям возможность рисовать только эскизы инженерных решений, а все остальное поручать машине — особенно, если голосом при этом комментировать, что рисуешь. Основная идея там проста: ежели инженер готов нарисовать и объяснить идею своего решения другому инженеру, то пусть ровно в тех же жестах и выражениях объяснит компьютеру, а дело компьютера понять его.

В случае [[Обоснование заявленных свойств|assurance case]] или [[GORE|требований]] — документировать инженеры обязаны, никуда не денешься, поэтому и нет особой проблемы capture таких обоснований. Не запишешь обоснования — уволят, и точка. Достаточно взглянуть на [http://en.wikipedia.org/wiki/Design_rationale статью в википедии] — и тут же видно, что все эти темы "обоснований" (design rationale и assurance case) родственны.

== Модели аргументации (argumentation-based models) ==
=== The Toulmin model ===
Toulmin model является общепризнанным предшественником [[Обоснование заявленных свойств#GSN|GSN]]/[[Обоснование заявленных свойств#CAE|CAE]], и просто удивительно, что в списке методов аргументации design rationale нет собственно GSN или CAE (ну, или URN или i*, которые тоже весьма похожи). 
# Claim is made;
# Supporting data are provided;
# Warrant provides evidence to the existing relations;
# Warrant can be supported by a backing;
# Model qualifiers (some, many, most, etc.) are provided;
# Possible rebuttals are also considered.

=== Issue-Based Information System (IBIS) ===
Another important approach to argumentation of design rationale is Rittel and Kunz’s IBIS (Issue-Based Information System), which is actually not a software system but an argumentative notation. It has been implemented in software form by gIBIS (graphical IBIS), itIBIS (test-based IBIS), Compendium, and other software. IBIS uses some rationale elements (denoted as nodes) such as issues, positions, arguments, resolutions and several relationships such as more general than, logical successor to, temporal successor to, replaces and similar to, to link the issue discussions.

=== Procedural Hierarchy of Issues (PHI) ===
PHI (Procedural Hierarchy of Issues)[24] extended IBIS to noncontroversial issues and redefined the relationships. PHI adds the subissue relationship which means one issue’s resolution depends on the resolution of another issue.

=== Questions, Options, and Criteria (QOC) ===
QOC (Questions, Options, and Criteria)[25] is used for design space analysis. Similar to IBIS, QOC identifies the key design problems as questions and possible answers to questions as options. In addition, QOC uses criteria to explicitly describe the methods to evaluate the options, such as the requirements to be satisfied or the properties desired. The options are linked with criteria positively or negatively and these links are defined as assessments.

=== Decision Representation Language (DRL) ===
DRL (Decision Representation Language) extends the Potts and Bruns model of DR[9] and defines the primary elements as decision problems, alternatives, goals, claims and groups. Lee (1991) has argued that DRL is more expressive than other languages. DRL focuses more on the representation of decision making and its rationale instead of on design rationale.

=== RATSpeak ===
Based on DRL, RATSpeak is developed and used as the representation language in SEURAT (Software Engineering Using RATionale). RATSpeak takes into account requirements (functional and non-functional) as part of the arguments for alternatives to the decision problems. SEURAT also includes an Argument Ontology which is a hierarchy of argument types and includes the types of claims used in the system.

=== WinWin Spiral Model ===
The WinWin Spiral Model, which is used in the WinWin approach, adds the WinWin negotiation activities, including identifying key stakeholders of the systems, and identifying the win conditions of each stakeholder and negotiation, into the front of each cycle of the spiral software development model in order to achieve a mutually satisfactory (winwin) agreement for all stakeholders of the project.
In the WinWin Spiral Model, the goals of each stakeholder are defined as Win conditions. Once there is a conflict between win conditions, it is captured as an Issue. Then the stakeholders invent Options and explore trade-offs to resolve the issue. When the issue is solved, an Agreement which satisfies the win conditions of stakeholders and captures the agreed option is achieved. Design rationale behind the decisions is captured during the process of the WinWin model and will be used by stakeholders and the designers to improve their later decision making. The WinWin Spiral model reduces the overheads of the capture of design rationale by providing stakeholders a well-defined process to negotiate. In an ontology of decision rationale is defined and their model utilizes the ontology to address the problem of supporting decision maintenance in the WinWin collaboration framework.

=== Design Recommendation and Intent Model (DRIM) ===
DRIM (Design Recommendation and Intent Model) is used in SHARED-DRIM. The main structure of DRIM is a proposal which consists of the intents of each designer, the recommendations that satisfy the intents and the justifications of the recommendations. Negotiations are also needed when conflicts exist between the intents of different designers. The recommendation accepted becomes a design decision, and the rationale of the unaccepted but proposed recommendations are also recorded during this process, which can be useful during the iterative design and/or system maintenance.

== Cсылки ==
* [http://en.wikipedia.org/wiki/IDEF6 IDEF6] (Integrated Definition for Design Rationale Capture). Хотя этот конкретный метод и имеет больше историческое значение, тем не менее, интересно заметить, что все про то же самое: записать потребности (needs), требования, цели.
* [http://www.edc.ncl.ac.uk/highlight/rhmay2007.php краткая статья про design rationale в связи с инженерией требований]. Содержит фразу "There are currently two approaches to requirements management, these are the Argument based design rationale capture method, and Feature based design rationale capture method". Сильное утверждение, не правда ли? 
* [http://gigapedia.com/items/293620/rationale-management-in-software-engineering Rationale Management in Software Engineering]
* языки требований типа [http://gigapedia.com/items/186360/competitive-engineering--a-handbook-for-systems-engineering--requirements-engineering--and-software-engineering-using-planguage Planguage]

[[Категория:Практики]]
[[Категория:Недопереведенные статьи]]