1 多个开源产品可以拿来分析其架构，如eclipse，万维网，

2 需求并不能决定架构，架构是一种高层设计，最重要的是，架构的设计受到很多方面的影响，这些带来影响的因素（技术，商业，社会，涉众的需求，开发组织的结构或者本质—例如开发组织的商业目标和技术特点等，设计师的经验水平，等）也是我们进行架构设计时需要考虑的，同时也可以帮助我们很好的分析一个（商业产品的）架构。

要注意到，完成一个架构的设计会带给前面所提到的因素一定的反馈，得到一定的收获。

3 架构商业周期Architecture Business Cycle：软件架构是技术，商业和社会等诸多因素作用的结果，而软件架构的存在又反过来会影响技术，商业和社会环境，从而影响到未来的架构，这种互相影响的周期—从环境到架构又返回到环境—就叫做架构商业周期

4 架构活动：

1）为系统构建一个商业案例（商业目标）

2）理解系统需求（最重要的是涉众的需求，可以使用面向对象的方法-即用例分析来获取，也可以通过捕获质量属性需求，再者，参考相似系统也可以获得需求）

3）创建或选择架构

4）将架构编成文档，并与有关各方进行交流（编档要面向不同的涉众给予不同文档，便于交流）

5）对此架构进行分析和评价（ATAM或CBAM，注意一点是评估过程不能脱离实际环境）

6）根据此架构实现系统

7）保证系统实现符合架构的要求

5 分析或者设计架构时可以考虑下面的一些建议：

1） 模块化，意味着要基于信息隐藏和独立的原则来设计或者分析架构

2）避免完全依赖于第三方组件

3）数据的生产者和消费者要分开！

6 软件架构的定义：某个软件或计算机系统的软件架构是该系统的一个或多个结构，它们由软件元素，这些元素的外部可见属性和这些元素之间的关系组成。

架构模式：架构模式是对元素和关系类型以及一组对其使用方式的限制的描述。也就是对架构的一组制约条件—即对各元素类型及其交互模式的制条件。

参考模型是一种考虑数据流的功能划分，是对已知的问题的标准分解，分解所得到的各个部分相互协作，构成问题的解决方案，注意到这里重点是在基于数据流的功能划分！，参考模型实现了功能划分，而参考架构则将这种功能划分和系统分解对应起来

参考模型重在功能分解，架构模式给出系统约束。

7 架构的结构和视图

视图是架构元素的内聚集的表示，由系统涉众编写和阅读，它由一个元素集的表示和元素之间的关系组成。

架构是元素本身的集合，它们存在于软件或硬件中

架构的结构主要可以分为以下三种：

　　1） 模块结构（职责划分，静态结构，提高了系统的可修改性，再加上“使用”或者“依赖”分析方法，可以进一层的划分“层次结构”）

　　2） 组件-连接器结构（交互，通信，并发，动态结构）

　　3） 分配结构（与外部环境-硬件的关系）

从上面这三个主要结构，我们可以这样分析架构或者这样设计一个架构：

　　1） 系统如何被组织成一个代码单元集合的？考虑将系统进行模块划分，各模块有唯一的职责并且不会过多的影响其他模块

　　2） 系统如何被组织为一个具有运行时行为和交互的元素集合？考虑系统的运行时状态，考虑系统内部完成一个任务的交互情况！

　　3） 系统如何与其环境中的非软件结构相关？考虑系统部署环境！

8 关于质量：软件设计师在设计中要考虑并发性，可移植性，可修改，易用性，安全性，并做出权衡

9 使用质量属性场景来刻画质量属性

质量属性及其一般场景详细

1）可用性：与系统故障及其相关后果有关，系统不再提供规范中所说明的服务时就出现了故障。

2）可修改性：是有关变更的成本问题，关注变更什么（artifact），何时变更（environment），由谁变更（source）

3）性能：于时间有关，事件发生时，系统必须对其作出相应。

4） 安全性：衡量系统在向合法用户提供服务的同时，阻止非授权使用的能力。主要关注的是数据和服务的安全性。

5） 可测试性：通过测试揭示软件缺陷的容易程度。

6） 易用性：关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持种类。

上面所提到的6个质量属性是系统的质量属性，实际中还有商业质量属性和架构质量属性

商业质量属性：

　　1） 上市时间（缩短上市时间，减少开发时间，重用现有元素）

　　2） 成本和收益

　　3） 所希望的系统生命期的长短（可拓展性，可修改性）

　　4） 目标市场

　　5） 推出计划（可移植性）

　　6） 与老系统的集成

架构的质量属性：

　　1） 概念完整性：在各个层次上统一系统设计的根本指导思想

　　2） 正确性和完整性：架构能够满足系统的各种需求和运行时的资源要求的必要条件

　　3） 可构建性：保证能够由指导开发小组在规定的时间里即时开发系统，并允许在开发过程作些更改的架构属性

10架构是实现质量需求的软件创建中的第一阶段，它是“软件功能”到“软件结构”的映射，而“软件结构”确定了“架构对质量属性的支持”

11 针对各系统质量属性的战术

1）可用性战术

1 错误检测：

　　A）ping/echo：随机随时探测另一方交互组件情况

　　B）心跳：定期组件本身汇报目前情况

　　C）异常：抛异常，异常处理

2 错误恢复：

   A）表决

   B）主动冗余：对一个事件的到来，主组件和该组件的对应冗余组件都进行响应，错误发生时可以让冗余组件进行替换。

   C）被动冗余：主组件向其他冗余组件发出更新消息。

   D）备件

   E）shadow操作

   F）状态再同步

   G）检查点，回滚

3 错误预防：

   A）从服务中删除

   B）事务

   C）进程监视器

2）可修改性战术

1 局部化修改：

　　A）维持语义一致性：保持模块责任一致性，保证局部化修改，防止连锁反应（这也是我们在开发过程中要十分注意的一点，模块责任的划分要十分准确，实现的时候不可以依赖于其他模块）

　　B）预期期望的变更：同样是限定为完成变更所需要修改的模块的数量，但是这里并不关系模块责任的一致性，类似于将所有容易发生变化的东西集中到一个地方，在那里发生变化

　　C）泛化该模块：保证模块的通用性

　　D）限制可能的选择：限制暴露出来的易变点

2 防止连锁反应：

   A）信息隐藏（老调重提，隔离变更）

   B）维持现有接口（重载）

   C）限制通信路径

   D）仲裁者的使用

3 推迟绑定时间

   A）运行时注册

   B）配置文件

   C）多态

   D）组件更换

   E）遵守已定义的协议

这些都是很好的实践经验！都在很多系统内用到！

3）性能战术

1 资源需求

   A）提供计算效率

   B）减少计算开销

   C）管理事件率

   D）控制采样频率

   E）限制执行时间

   F）限制队列大小

2 资源管理

   A）引入并发

   B）维持数据或计算的多个副本

   C）增加可用资源

3 资源仲裁

   A）先进先出

   B）固定优先级调度

   C）动态优先级调度

   D）静态调度

4） 安全性战术

1 抵抗攻击

   A）对用户进行身份验证

   B）对用户进行授权

　 C）维护数据的机密性

　 D）维护完整性

　 E）限制暴露的信息

　 F）限制访问

2 检测攻击

3 从攻击中恢复

5） 可测试性战术

   1 输入输出

   A）记录回放（捕获某个组件的输入和另一个组件的输出，作为测试软件的输入）

   B）将接口和实现分离（方便测试）

   C）特化访问路线/接口

2 内部监视

6） 易用性战术

1 运行时战术

　　A）维护任务的一个模型（任务模型用来确定上下文，使得系统了解用户试图做什么，提供协助）

　　B）维护用户的一个模型（维护关于用户的信息，确定用户对该系统的了解，用户在期望的响应时间方面的行为）

　　C）维护系统的一个模型（确定期望的系统行为，以便用户提供适当反馈）

2 设计时战术

　　A）将用户接口与应用的其余部分分离开来（例如有MVC，表示-抽象-控制等）

优先级最高的业务目标—》质量属性场景或用例描述—》关于功能，质量，商业需求的架构驱动因素—》选择其中对架构影响最大的---》确定的架构驱动因素---》开始ADD架构设计。

使用ADD –Attribute Driven Design的方法进行架构的设计，其输入是质量属性场景，使用对质量属性实现和架构之间关系的了解，对架构进行设计，输出则为架构的模块分解视图和其他视图，最终满足质量上和功能上的需求。

步骤：

　1 选择要分解的模块

　2 根据下面的部分对还没分解的模块求精：

　1 从质量场景和功能需求集合中选择“架构驱动因素”，也就是挖掘高优先级的质量需求和功能需求，这可以帮助我们确定对于分解的提示性信息

　2 选择满足“这些架构驱动因素”的“架构模式”，可以根据“战术”来创建这些模式，确定实现这些战术所需要的“子模块”，也就是模块类型，最终建立一个由模块类型组成的“总体架构模式”。最终确定了模块的分解结构。

　3 实例化这些模块，现在就可以开始分配功能了，然后使用模块视图（前面的内容就是），组件连接器视图（组件还是模块，连接器就是“与什么同步，开始，取消，通信”，并发视图—建立模型来反映资源争用，死锁，数据一致性问题---可以通过场景描述来得到这样的需求）分配视图来表示，使用父用例来进行功能分配（会发现必要的信息交换，记录下生产者和消费者的这些关系，帮助我们更好的把握模块间和模块内的沟通，硬件通信-虚拟线程）

　4 定义子模块的接口，其实就是编档，模块视图的编档内容（信息的生产者和消费者，要求模块提供的服务和使用它们的交互模式），并发视图的编档内容（线程间的交互，组件的活动状态，组件同步，序列化），部署视图（硬件，时间，通信需求）待模块分解中的层次稳定后，分配给小组，形成一定的团队结构

　5 验证用例和场景，然后求精，挖掘进一步的限制，

　3 对子模块子系统重复上述过程

13 完成ADD后创建骨架系统，过程：

1 实现处理架构组件的执行和交互的软件部分（比如调度程序，规则引擎，同步交互机制等---这种做法好像和我自己平常的开发方法不一样，这种方式是有利于构建一个基本可以运行的骨架系统，但是在初期进行交互部分的开发，可能会忽略一些关键因素，导致在后面增量过程中添加了功能后，发现交互有问题，这样只能推倒。）

2 使用下一个增量的元素，采用使用结构

14 ATAM （Architecture trade-off analysis method）的结果

1 一个简洁的架构表述（架构设计方法，最好使用“视图”表述架构）

2 表述清楚的业务目标（系统上下文及商业动机）

3 用场景集合捕获的质量需求（由业务目标获取需求，再用场景描述，使用效用树对质量属性目标进行阐述，使质量属性需求具体化）

4 所确定的敏感点和权衡点的集合（因为评估工作是由非架构设计人员参与，所以前面的步骤都是为了更好的理解架构师的设计和架构的主要商业，质量驱动因素，从这一步开始就开始进行评估了，敏感点-某个架构的决策影响到某个质量属性，权衡点-某个架构决策影响多个质量属性，并且是正面和负面都存在的，在前面效用树的分析中，针对每个场景进行优先级的划分，然后在这时针对高优先级场景进行架构方法的分析讨论）

5 有风险决策和无风险决策（有无风险的判断是是否可能会导致不期望有的结果）

6 风险主题的集合