Neil B. Harrison, Utah Valley State College
Paris Avgeriou, University of Groningen
Uwe Zdun, Vienna University of Technology
SA设计中的决策至关重要,尤其对QA.
但是,通常架构师不会充分的记录这些决策。
他们一不看重记录的收益,二不知道怎么记录,三甚至不知道自己在做决策。
因此,缺乏完整的记录,导致系统后期的设计混乱,决策间相互冲突。
研究人员提出了很多的方法、工具帮助架构师记录决策。
不过还是很困难,还是会丢信息。
Arch Pattern 可以捕获结构、行为上的信息,可以解决这些记录的挑战,
- 可以鼓励架构师仔细思考决策,用一种自然地不会影响设计过程的方式。
- Arch Pattern易用,提供一组丰富的信息,包括rationale, consequence, related decision.
- 本质上,它提供了可复用的知识。
本文,讨论pattern和decision的关系,并且讨论如何利用pattern去捕获决策。
Problem Overview
大部分的描述SA的方式,就是一组视图。
理想情况下,决策也用视图表示。
不过,若仅仅记录决策本身意义不大,为了让记录真的有用,架构师需要捕获alternatives,expected consequences, and rationale.
目前的研究:一阶实体,显式表示。一般就是扩展现有的C&C View.
知识蒸发
记录决策的最终目的就是要 解决主要的知识蒸发问题。
由于没有记录,重要的信息随着开发、演化的过程就丢掉了。
而决策是无法被显式的从architectural models里面提取的。
此外,它们仅仅存在于架构师等人的头脑里,不可避免的就丢掉了。
"If something is not written down, it does not exist."
知识蒸发的问题,系统演化代价高,缺乏stakeholder之间的沟通,受限的资产复用,差的追踪性(需求,架构,实现)
记录的挑战
如果记录是个标准的实践,那么记录一定要简单、一定程度上自动化。
研究者给出了一些概念模型,方法,过程,工具,用来记录决策。
然后还是有很大的困难,包括:
- 记录的代价要高于收益
- 架构师有时候没有意识到自己的决策,或者没有仔细的考虑,所以也不知道该记录什么。
- 再创造的过程中,架构师习惯于拖延记录这件事;
以至于很多决策以及rationale就忘了 - 架构师不知道如何记录这些决策
很显然,这些困难是的记录决策的过程很棘手,导致丢失了很多重要知识。
模式 解决方法 The Pattern solution
Arch pattern是那些一般性的架构设计问题的解决方案,通过反复的使用、验证并且记录下来的。
Arch pattern提供了一种有效的方式去捕获一些最重要的设计决策,以及提供合适的alternative solution.
模式的记录,包括模式的使用环境——模式解决的反复出现的问题,以及模式的consequences.
模式可以帮助缓解记录的负担:
- 决策包括结构和行为信息 更加容易记录
- 记录了模式,可以促使架构师反思这些决策
- Pattern的选择是 自然设计中的重要的部分,记录代价低
- Pattern 这种形式比较易于理解
Pattern vs Decisions 一个比较
Pattern: 连接了结构和结果
Pattern: coupling structure and consequences
一个模式描述了一个问题,他的语境,以及一个通用的解。
很多开发人员用模式来记录软件问题的解。最著名的就是OO中的Design pattern.
Arch Pattern也类似于OO中的DP,提供了解的语境。
而不同的是,AP没有直接产生代码,而是,AP在arch design level,描述了
抽象的,高层的系统结构以及它的关联的行为。
AP通常在一个高层次,给出系统的模块化分解的形式。
一个AP的好处是: 能够捕获系统的一般结构(well known,并且容易识别)以及相应的结果。
这些信息在重构系统时特别有用:
系统的结构 显示了 (显式或者隐式)的AP.
这些pattern的描述,进而,给出了决策的后果(QA)
而这些后果是,在效果上,从决策中不那么明显的能推出的。
常见的AP包括:
Layers
Pipes and Filters
Blackboard
关于AP,Paris Avgeriou 和 Uwe Zdun给出了一个完整的目前已经识别出来的architecture pattern.
另外,还能够通过architectural style来描述,1988年Shaw首次提出。
一般认为,这两者是差不多的概念,我们统一称为pattern.
决策: 捕获关键信息
一个决策 影响系统的结构
Jan Bosch提出,一个决策是由 需求 以及 解,此外每一个决策解决了一些需求,而不考虑其他需求。
按照Bosch的说法,一个决策可能是:
- 增加一个构件
- 对现有的构件指定其功能
- 对构件的预期行为增加需求
- 对现有的部分或全部体系结构增加约束
他还指出一个决策可以表示很多解的结构,包括style或者pattern.
一个重要的考虑,到底decision需要收集并记录哪些信息?
Issue,decision,alternative,reasoning,
Anton Jansen和Jan Bosch把这些信息描述为problem,motivation, cause,context,potential solution,以及decision
Jeff Tyree提出一个模板去记录他们。
第二个重要问题是,decision包含哪些类?
- Existence
- Non-existence
- Property decisions
- Executive decisions
两类知识:
Application-generic knowledge
Application-specific knowledge
关键在于,记录相关的信息,而非仅仅决策本身。
Model-driven 开发方法开发了工具可以定义architectural metamodel,以及constraints,model-checking
我们可以扩展MSDS的工具去对决策进行建模,并且使用它们定义、自动化的检查约束。
不过,目前还没有看到有人有效的做好了这件事。
模式 和 决策的关系
两个互补的概念。
使用一个模式,是从一组alternative中选取一个,并且因此在目标系统的特定语境下做出决策。
比如说:要设计一个user interface ,可能考虑MVC或者PAC
二者的优缺点
架构师权衡
模式和决策的最大区别,包含信息的范围
决策,特定的,试探性的 (app-speific knowledge)
模式,通用性的,被证明的 (app-generic knowledge)
尽管模式和决策有不同的起源,比较它们记录形式,还是会相同之处。
一个决策包括了 需要决策的issue,alternative solution,最终的决策,原因;
一个模式类似,issue,决策,alternative solution提出并被证明
Table 1给出了一般的记录决策和模式的方式:
除了形式以外,另一个有趣的问题是,这两种方式如何帮助选择解。
Pattern
一个独立的模式提供了alternative solution,
不同的pattern有不同的variant , 它们可能是互补的。 比如 CS,P2P,Publish-Subcribe等等