[论文笔记]Using Patterns to Capture Architectural Decisions
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等等
