[论文笔记] SHARK10: Using Rationale to Support Pattern-Based Architectural Design –by- Wei Wang, Janet E. Burge

[题目] Using Rationale to Support Pattern-Based Architectural Design

Wei Wang    Miami University Benton Hall, Oxford Ohio 45056 USA +1-513-529-0347 [email protected]

Janet E. Burge    Miami University Department of English Benton Hall, Oxford Ohio 45056 USA +1-513-529-0347 [email protected]

[摘要]

设计理由（Rationale）描述了 所做的决策、考虑过的可选解、对每个解支持或反对的原因。

至少，一些原因应该考虑非功能需求（NFR）。

SEURAT_Architecture 系统采用预定义的模式库，以及系统的NFR来指导选择体系结构模式。

每一个被推荐的模式都作为决策的一个可选解，并且附带着raitonale，为什么这个模式是有用的。

SEURAT_Architecture有若干个目的：

1. 在决策过程中指引架构师，
2. 在做早期关键决策的时候，保证NFRs能够被考虑进去；
3. 捕获rationale，作为工具支持的选择过程的一个副产品(byproduct)。

Architectural design rationale describes the decisions made, alternatives considered, and reasons for and against each alternative considered when defining a software architecture.

At least some of these reasons should reference the non-functional requirements (NFRs) for the system.

The SEURAT_Architecture system uses a pre-defined pattern library and the NFRs for a software system to guide the selection of architectural patterns.

Each pattern recommended by the system serves as an alternative to the architectural decision made and comes with rationale for why this pattern is considered useful.

This system serves several purposes—

1. to guide the architect through the decision-making process,
2. to ensure that NFRs are considered when making these critical early decisions, and
3. to capture the rationale for the architecture as a byproduct of the tool-supported selection process.

Introduction

Software architecture

 

Decision的缺失

    证明SA的设计，在维护时起作用

        Tang A., Han J., Vasa R. 2009. Software Architecture Design Reasoning: A Case for Improved Methodology Support, IEEE Software, vol. Mar/Apr 2009: pp. 43-49, 2009

    帮助验证质量属性等NFRs,

        为了满足NFRs，应该在早期去考虑，但实际很晚才考虑，缺少早期SA阶段支持NFRs的工具

 

现在对architecture knowledge 逐渐重视， 被称之为design rationale

Rationale记录了 背景信息、推理过程（需求、协商过程、权衡、可选解）

Rationale被认为是重要的SA组成部分，可以在设计和维护活动中帮助设计者、架构师。

 

本为提出了一个 利用NFRs驱动的SA设计过程，并且用architectural pattern辅助选取体系结构。

这个方法，集成在了SEURAT Rationale Management System

[8] Burge, J., Brown, D.C. 2004. An Integrated Approach for Software Design Checking Using Rationale, In Proc. Of Design Computing and Cognition '04, J. Gero (Ed.), Kluwer Academic Publishers, Netherlands, 557-576

[10] Burge, J. E. and Brown, D. C. 2008. SEURAT: integrated rationale management. In Proceedings of the 30^th international Conference on Software Engineering (Leipzig, Germany, May 10 - 18, 2008). ICSE '08. ACM, New York, NY, 835-838.

Background

Rationale

    它捕获了背景信息、SA设计的推理过程。
    最早在1988年就有研究过了。

Potts, C., Bruns, G., 1988. Recording the reasons for design decisions. In: Proceedings of the 10th International Conference on Software Engineering, pp. 418–427.

    
    然而2006年[26]给出有效捕捉、使用rationale的内在限制。
    记录推理过程是一个非常费时费力的过程。
    已经有很多的方法、模型用来捕获rationale。
        Issue-based information system (IBIS)
        Procedural Hierarchy of Issues (PHI)
        Questions, Options, and Criteria (QOC)
        Decision Representation Language (DRL)
        RATSpeak
        Winwin approach

    Rationale可以有多种用途

    Rationale的重要性被SA圈子所认识。

        缺少好的记录推理过程的方法学

        架构师 是决策者，而非仅仅的建模者。

        结果的SA，是一组设计决策的结果，包括结构性决策、部署决策[44]。

    系统要满足非功能性

        有些框架framework被提出，用来指定NFR和设计决策之间的关系

        也有的提出用NFRs作为支持SA设计的驱动力

    Architectural Pattern

        给出了那些在特定语境下、反复出现的问题的解。

        

Integrating patterns and rationale

目的：帮助架构师做决策，并且记录rationale

做法：

1. 统一的方法描述architectural pattern

    不仅描述pattern本身，
同时展示与其他pattern的关系以及可能用到的能帮助选择pattern决策的rationale

2. 一个方法：能够组织、分类这些pattern，是的可以快速的识别哪一个、哪些pattern可以帮助设计

3. 指导 如何应用或者实现这些pattern

4. 演化机制：对现存的、新增的pattern的变化支持

本文实现的系统 支持以下的功能：

1. 建立一个基本的设计过程，帮助架构师识别关键的需要做的决策；
2. 给出候选的pattern帮助决策。后面的pattern会受到前面已做出的决策的影响
3. 记录已做出的决策、原因。 预存的 常用rationale 可以帮助选取一个自动生成的特定的pattern

本文是通过扩展现有的SEURAT系统，创建了SEURAT_Architecture

SEURAT

SEURAT是一个eclipse的插件。用于捕获、显示、维护design rationale

他用RATSpeak 表示语言，这是基于DRL的。

他用FR以及NFR作为arguments，并且使用Ontology来给出常用的arguments

Ontology包含了277种做决策的原因。包括各种常见的 –ility，并构成了一个hierarchy，让原因越来越具体。

这些Ontology 出现在多处，他们连接了NFRs，claims，known design tradeoff。

SERUAT系统展示rationale在rationale explorer这样的视图，如下所示：

用户可以输入决策问题，可行替代解，支持、反对的arguments。

SEURAT还支持 评估每一个可行替代解，并能通过rationale推测，可行解是最佳的解。

SEURAT是设计支持系统维护的。展示相关的design rationale

 

SEEURAT_Architecture

给出了一个视图： pattern library

描述了每一个pattern和其rationale

Pattern Library

Pattern可以辅助，搭建一个满足QA的系统。

Pattern捕获了已经证明的设计解决方案以及关于特定语境下反复出现的问题的知识。

它是基于成功的设计经验和专家设计者 为基础的。

其他的设计可以 通过学习专家使用过的那些解决方案，来获益。

 

在library里面，如果仅仅是分类是不够的。

1. Pattern非常多
2. Pattern之间的依赖关系
3. 决策、rationale很容易就无意识的丢掉了

在本方法里面，library首先分了类。

然后，library显示的表示了每一个pattern对QA的影响。

这些QA可以被用来作为rationale，在推理过程中。

此外，pattern与相关的pattern是关联的

 

在library里面有四个关键的构件：

• Pattern Categories
• Design Problem Categories
• Affected Quality Attributes
• Decisions required to adopt a pattern and their Candidate (alternative) Patterns

分类采用了[12]的做法。分为了三类：

[12] Buschmann F., Meunier R., Rohnert H., Sommerlad P., Stal M. 1996, Pattern-Oriented software architecture, Volume 1: A System of Patterns. Wiley.

Architectural Pattern

解决系统的基础结构，在设计的最开始。 指定了系统的分解、子系统的责任、管理他们之间关系的规则和指引

Design Pattern

当精化系统架构或者一些局部的子系统设计问题时，用于更加具体的设计。Design pattern解决相对小的设计问题，但是又比下面的idiom更加通用一些，idiom更加与编程语言相关

Idioms

是低层次的模式，用于解决特定语言的实现相关的问题，比如说：C++中的内存管理问题。

每一个pattern都是目标解决一个特定的问题，问题的分类把模式分为若干组。

从[12]文中，可以采纳这样的10种分类：

• From Mud to Structure

patterns that support decomposing a system task into subtasks;

• Distributed Systems

patterns for systems where patterns are distributed across different processes or in several subsystems;

• Interactive Systems

patterns for systems that interact with humans;

• Adaptable Systems

patterns that provide infrastructures to support extension and adaptation;

• Structural Decomposition

patterns that support decomposition of complex systems;

• Organization of Work

patterns that define how components work together;

• Access Control

patterns that guard and control access to other services or components;

• Management

patterns to control collections of objects, services and components;

• Communication

patterns for organizing communication between services or components;

• Resource Handling

patterns to manage shared objects or components.

分类并不一定 完全、正交，但是分类还是有好处的

对于每一个pattern，为了应用这个pattern，需要做出一系列的决策。这些决策、决策问题被显式的表示在pattern library。

一旦一个Pattern被采用了，相关的需要确定的决策将被SEURAT引入。

用户可以选择一个alternative去应用这个pattern。

在某些情况下，这些alternative是其他的pattern。如果是这样，这些pattern就能够被引入SEURAT，作为一个新的alternative.

举例而言，若应用三层结构 Three-Layer Pattern，需要考虑"What is the structure of business logic layer?"

    有若干的pattern可以被选择解决这个问题，比如Transaction Script pattern, Domain Model pattern, and the Table Module pattern.

    这些patterns作为business logic layer的一个alternative，并且每一个都含有rationale为什么它应该被选择。

    这些patterns可以被连接为 Candidate pattern。如果架构师选择了Three Layer pattern，那么SEURAT将会应用那些相关的decision.

系统架构师可以增加或者编辑pattern library中的模式。

 

Architectural Rationale Generation

 

SEURAT 利用NFRs指引体系结构设计过程。

每一个NFR都会被连接到Ontology 中的一个Entry。

比如说，一个NFR是，"这个软件每个月不能多于一次的失败"。

这个NFR就被连接到了"Availability"。

NFR和Ontology之间的链接用通用的QA词汇表，标准化了NFR。

 

NFR和pattern通过这样的方式match，基础是他们都连结到ontology entry

如果他们match了，我们可以说NFR可以实现，by 采用对用的pattern

 

有两类match的方法。（1）exact matching和（2）contribution matching

Exact matching

如果一个NFR被链接到一个ontology entry，他连结到了一个pattern，我们说这个pattern match了。

 

 

 

 

 

 

比如说，一个NFR被描述为"The main components of the software must be reusable"被链接到了 ontology中的reusability，

三层结构Three-Layer pattern对于reusability的影响为证，positively.

我们说，Three-Layer pattern匹配了这个NFR。

如果采用Three-Layer pattern的话，我们可以支持这个NFR.

 

Contribution matching

一个NFR连接到了一个ontology entry，而这个entry链接到了一个pattern，

或者是一个entry的子entry，连接到了那个pattern，

则我们称其为匹配。

    （在SEURAT里面，Argument ontology包含有一个arguments的hierarchy，不同层次的抽象）

 

 

 

 

 

 

 

 

 

比如说，一个NFR"主构件必须是可重用的"，并且连接到了 ontology entry Reusability。

那么Three-Layer pattern被链接到了 Adaptability Criteria，并且影响为正。

因为在argument ontology里面，Adaptability Criteria和 Reusability 有一个父子关系，

因此，我们说Three-layer pattern是和NFR匹配的。

 

当架构师 选择一个pattern作为一个candidate，则这个pattern被加入rationale作为一个alternative solution

然后，rationale，以支持、或反对的arguments的形式，从library里面被创建。

这种rationale的自动生成办法有两种：

1. 如果一个被连接的ontology entry在一个pattern对一个NFR 匹配match
   则产生一个requirement 类型的argument。并且这个新的argument将会被连接到那个NFR.
2. 如果一个ontology entry没有被匹配到任何一个NFR，那么Claim类型的argument将会产生。并且这个ontology entry将被连接到这个claim。

Argument的方向，到底是for还是against，将通过ontology entry如果影响pattern的，来确定。

 

1. Using SEURAT_ARCHITECTURE

Figure 2显示了 SEURAT_Architecture 以及初始的NFRs，根决策 root decision，以及Pattern Library。

Rationale，给出了NFRs 和相应的决策，展示在了Rationale Explorer view.

Pattern Lib展示在右侧。

 

架构师 建立一个新的project

第一个问题就是："What is the basic architecture for the system?"

架构师 输入NFRs

 

右键点击root decision，然后"generate candidate patterns"

将会给出一个窗口，选择匹配方法，模式范围，问题分类

根据这些criteria，工具可以帮助找到最佳的pattern，以及一个列表pattern，以及他们的评估分数。

下面的图显示了 返回的四个pattern以及对应的得分

架构师可以选择一个或多个pattern作为候选。

然后，他们就会出现在rationale，作为alternative，并存在于对应的位置。

上例是root decision.

工具将使用arguments，支持或者反对某一个alternative(pattern)，去计算一个值，采用的是加权求和，

考虑了QA的优先级 以及 NFR

这些信息可以帮助架构师决策选择哪一个alternative。

当决策后，也即选择了某一个模式，工具将会产生基于这个模式，接下来需要作出的决策，（定义在Pattern Lib）

比如说 Three-Layer Model选择了之后，架构师需要分别的设计 business logic , data source, presentation三个层次的设计。，

每一个，都有一组alternative和rationale 从pattern lib里面自动的引入。

 

随着设计的继续，架构师可以完善rationale，

最终将得到一个 对最终系统架构的，完全描述的rationale 。

 

Conclusion and future work

 

本文提供了选择 arch pattern, design pattern 以及 idiom的方法

它用NFRs捕获了每一个pattern的rationale.

初始的决策是利用NFRs指引的特定的决策，

后续的决策将有模式库里的信息继续指引。

未来希望做成 像第一步一样的，自动产生候选pattern。

 

系统目前正在 评估

 

架构设计中所作出的决策时至关重要的

而架构师并不能够总是保证所有的pattern都考虑到了，

并且考虑清到底哪个比哪个好

这些 实现了、修改了SA的模式，可能不能被完全的理解，

一个Pattern到底用在了哪里，为什么要这样选择。

SEURAT_Architecture，辅助解决这两个问题：

支持pattern的选取，以及支持捕获rationale.

 

6. ACKNOWLEDGMENTS

This work is supported by NSF CAREER Award CCF-0844638 (Burge).

 

Bibliography

 

7. REFERENCES

[1] Ali-Babar M.A., Gorton I., Jeffery R., 2005. Capturing and

Using Software Architecture Knowledge for Architecture-

Based Software Development, Proceedings of the Fifth

International Conference on Quality Software, p.169-176

[2] Ali-Babar, Wang X., Gorton I. (2005), PAKME: A Tool for

Capturing and Using Architecture Design Knowledge. 9th

International Multitopic Conference, IEEE INMIC 2005

[3] Avgeriou P., Zdun U. 2005. Architectural patterns

revisited: a pattern language. 10th European Conference on

Pattern Languages of Programs (EuroPlop 2005), Irsee,

Germany, July.

[4] Bass L., Clements P., Kazman R., 2003. Software

architecture in practice, 2nd edition, Addison-Wesley,

Reading, MA;

[5] Bass, L., Clements, P., Nord, R.L., Stafford, J. 2006.

Capturing and using rationale for a software architecture.

In: Dutoit, A.H., McCall, R., Mistrik, I., Paech, B. (Eds.),

Rationale Management in Software Engineering. Springer,

pp. 275–292.

[6] Beck K., Johnson R., 1994. Patterns Generate

Architectures, Proceedings of the 8th European

Conference, ECOOP '94, Lecture Notes in Computer

Science, Volume 821.

[7] Boehm, B., & Kitapci, H. 2006. The WinWin approach:

using a requirements negotiation tool for rationale capture

and use. In Rationale Management in Software Engineering

(Dutoit, A., McCall, R., Mistrik, I., & and Paech B., Eds.),

pp. 173-190. Heidelberg: Springer-Verlag.

[8] Burge, J., Brown, D.C. 2004. An Integrated Approach for

Software Design Checking Using Rationale, In Proc. of

Design Computing and Cognition '04, J. Gero (Ed.),

Kluwer Academic Publishers, Netherlands, 557-576

[9] Burge, J., Brown, D.C., 2006. Rationale-Based support for

software maintenance, In: Dutoit, A., McCall, R., Mistrik,

I.,Paech, B. (Eds.), Rationale Management in Software

Engineering, Springer-Verlag, Berlin, pp. 273-296.

[10] Burge, J. E. and Brown, D. C. 2008. SEURAT: integrated

rationale management. In Proceedings of the 30th

international Conference on Software Engineering

(Leipzig, Germany, May 10 - 18, 2008). ICSE '08. ACM,

New York, NY, 835-838.

[11] Burge, J.E., Carroll, J.M, McCall, R., Mistrik, I., 2008

Rationale-Based Software Engineering, Springer.

[12] Buschmann F., Meunier R., Rohnert H., Sommerlad P., Stal

M. 1996, Pattern-Oriented software architecture, Volume 1:

A System of Patterns. Wiley.

[13] Capilla R., Nava F., Duenas J.C., 2007. Modeling and

Documenting the Evolution of Architectural Design

Decision (SHARK/ADI'07), ICSE Workshops, IEEE CS

[14] Chung, L. Representing and Using Non-Functional

Requirements: A Process-Oriented Approach, Ph.D. thesis,

Univ. of Toronto, 1993.

[15] Chung, L., Nixon, B., Yu, E., 1995, Using Non-Functional

Requirements to Systematically Select Among Alternatives

in Architectural Design. Proc. 1st Int. Workshop on

Architectures for Software Systems

[16] Chung, L., Nixon, B.A., Yu, E., Mylopoulos, J., 2000.

Non-Functional Requirements in Software Engineering,

Kluwer Academic Publishers.

[17] Cui X., Sun Y., Mei H. 2008, Towards Automated Solution

Synthesis and Rationale Capture in Decision-Centric

Architecture Design, Proceedings of the Seventh Working

IEEE/IFIP Conference on Software Architecture (WICSA

2008): pp.221-230

[18] Davis, A. 1993. Software Requirements: Objects Functions

and States. Prentice Hall

[19] Dutoit A. H., McCall R., Mistrík I. et al. 2006. Rationale

Management in Software Engineering: Concepts and

Techniques, in Dutoit, A.H.; R. McCall & I. Mistrík et al.,

Rationale Management in Software Engineering, Springer

Berlin Heidelberg, pp. 1-48

[20] Dutoit, A., McCall, R., Mistrik, I. and Paech, B. (Eds.)

Rationale Management in Software Engineering, Springer-

Verlang, Berlin, 2006

[21] Falessi D., Becker M., Cantone G. 2006. Design decision

rationale: experiences and steps ahead towards systematic

use. ACM SIGSOFT Software Engineering Notes 31(5):

(2006)

[22] Fox, C. 2006. Introduction to Software Engineering

Design: Processes, Principles, and Patterns with UML2.

Addison Wesley.

[23] Fowler M.. 2003. Patterns of Enterprise Application

Architecture. Addison-Wesley, Reading, MA

[24] Gamma E., Helm R., Johnson, R. Vlissides, J. 1994. Design

Patterns: Elements of Reusable Object-Oriented Software.

Addison-Wesley.

[25] Harrison, N. and Avgeriou, P. 2007. Pattern-Driven

Architectural Partitioning: Balancing Functional and Nonfunctional

Requirements. In Proceedings of the Second

international Conference on Digital Telecommunications

Washington, DC, 21

[26] Horner J., Attwood, M.E. 2006. Effective design rationale:

understanding the barriers. In Rationale Management in

Software Engineering (Dutoit, A., McCall, R., Mistrik, I.,

& and Paech B., Eds.), pp. 73-90. Heidelberg: Springer-

Verlag.

[27] Jan S. van der Ven, Anton G. J. Jansen J., Nijhuis A. G.,

Bosch J. 2006. Design Decisions: The Bridge between

Rationale and Architecture, in Dutoit, A.H.; R. McCall & I.

Mistrík et al., Rationale Management in Software

Engineering, Springer Berlin Heidelberg, pp. 329-346

[28] Jansen AGJ, Bosch J., 2005. Software architecture as a set

of architectural design decisions. In: 5th IEEE/IFIP

Working Conference on Software Architecture (WICSA

2005), Pittsburgh, PA

[29] Keller, S.E.; Kahn, L.G.; Panara, R.B. 1990. Specifying

Software Quality Requirements with Metrics. in Thayer,

R.H.; Dorfman. M.: System and Software Requirements

Engineering, IEEE Computer Society Press, Washington,

pp. 145-163

[30] Kim S., Kim. D-K., Lu L., Park S. 2009. Quality-driven

Architecture Development Using Architectural Tactics, J.

Syst. Softw. 82, 8 (Aug. 2009), pp. 1211-1231.

[31] Kunz, W., Rittel, H. 1970. Issues as elements of

information systems. Working Paper 131, Center for Urban

and Regional Development, University of California,

Berkeley

[32] Lee J. 1991. Extending the Potts and Bruns model for

recording design rationale, Proceedings of the 13th

International Conference on Software Engineering (ICSE

'13), IEEE Computer Society Press, Los Alamitos, CA, pp.

114-125

[33] Lee, J. & Lai, K.-Y. 1991. What's in Design Rationale?

Human-Computer Interaction special issue on design

rationale 6(3-4) pp. 251-280

[34] Lee, J. 1997. Design rationale systems: understanding the

issues. IEEE Expert: Intelligent Systems and Their

Applications, 12, 3 (May. 1997), 78-85.

[35] MacLean, A., Young, R.M., Bellotti, V., Moran, T.P.,

1996. Questions, options and criteria: elements of design

space analysis, In: Moran, T., Carroll, J. (Eds.), Design

Rationale Concepts, Techniques, and Use, Lawrence

Erlbaum Associates, NJ, 1996, pp. 201-251.

[36] MacLean, A,, Young, R. M., & Moran, T. P. 1989. Design

rationale: The argument behind the artifact. Proceedings of

the CHI '89 Conference on Human Factors in Computing

Systems, 247-252. New York: ACM.

[37] McCall, R., 1987. PHIBIS: Procedural hierarchical issuebased

information systems. In: Proceedings of the 13th

International Congress on Planning and Design Theory, pp.

17–22.

[38] Nilsson J. 2006. Applying Domain-Driven Design and

Patterns: With Examples in C# and .NET, Addison Wesley

Professional.

[39] Pena Mora F., Vadhavkar S. 1996. Augmenting Design

Patterns with Design Rationale. Artificial Intelligence for

Engineering Design, Analysis, and Manufacturing, 11(2):

pp. 93-108

[40] Potts, C., Bruns, G., 1988. Recording the reasons for design

decisions. In: Proceedings of the 10th International

Conference on Software Engineering, pp. 418–427.

[41] Tang T., Babar M.A., Gorton I., Han J. 2006. A Survey of

Architecture Design rationale. Journal of Systems and

Software, 79(12): pp. 1792-1804

[42] Tang A., Jin Y., Han J., 2007. A rationale-based

architecture model for design traceability and reasoning.

The Journal of Systems and Software 80, pp. 918-934.

Elseiver

[43] Tang A., Han J., Vasa R. 2009. Software Architecture

Design Reasoning: A Case for Improved Methodology

Support, IEEE Software, vol. Mar/Apr 2009: pp. 43-49,

2009

[44] Tyree J. and Akerman A 2005. Architecture Decisions:

Demystifying Architecture. IEEE Software, 22(2):pp. 19–

27

[45] Zhu L and Gorton I. 2007. UML Profiles for Design

Decisions and Non-Functional Requirements. in

Proceedings of the 2nd Workshop on Sharing and Reusing

Architectural Knowledge - Architecture, Rationale, and

Design Intent (SHARK-ADI), Minneapolis, MN

[46] Zdun, U., Avgeriou, P., Hentrich, C., Dustdar, S., 2008.

Architecting as decision making with patterns and

primitives. SHARK 2008: 11-18

[47] Zimmermann O., Gschwind T., Küster J. M., Leymann, F.

Schuster, N., 2007, Reusable Architectural Decision

Models for Enterprise Application Development.

(QoSA'07), Springer-Verlag LNCS 4880, 15-32