软件设计体系结构复习

各种性能指标及如何到达各种性能指标的方法

反应—对正常和极端用法的脚本的反应是否足够快

可伸缩性—系统的能力克根据需要增加或减少

容量/产量—处理大负荷仍有反应

安全性—系统不会社会产生危害

常用的中间件有那几种类型

（1） 常见的对象请求代理架构

（2） 面向消息的中间件

（3） Java2 Enterprise Edition（Java2的企业版）

（4） 消息代理

（5） 业务过程代理

有那些常见架构风格

1.管道和过滤器架构风格

适用于需要定义一系列的执行规则数据的独立运算。

组件在输入时读数据流，在输出时产生数据流。

组件：称为过滤器，应用于对局部的输入流的转换，经常增长的计算，因此，在输入结束前输出就开始了。

. 连接器：称为管道，给流提供管道，把一个过滤器的输出传输到另一个输入。

2.面向对象风格

适用于主要问题是识别和保护信息的相关主体。

数据代理和它们相关的操作封装在一个抽象数据类型里面。

组件：对象

连接器：功能和过程调用（方法）

3.隐式调用风格

应用于涉及到组件的松耦合集，其中的每一个都执行一些操作，还可能允许其他的操作。 尤其对必须很快重新配置的应用很有用

改变服务的供应商

可能的或是不可能的能力

不是直接的引用过程

一个组件能发表一个或多个事件

在系统中的其他组件能够在事件中注册一个兴趣通过与事件和过程结合

当一个事件被声明后，广播系统（连接器）自己引用已经注册的事件的所有过程 所有声明的事件“隐式”造成了过程在其他模块的调用

4. 客户-服务器风格

适用于涉及到分布式的数据和跨越一系列的组件的处理

组件：

服务器：标准独立的组件提供特别的服务，如打印，数据管理等。

客户端：组件调用服务器提供的服务。

连接器：网络，允许客户端访问远程服务器。

5.分层风格

适用于涉及到分布式的能够分层的组织的类的服务

每层给它的上一层提供服务，同时作为下一层的客户端

只有仔细地从内层选择选择过程，才能用于他们临近的外层。

组件：典型的过程的集合。

连接器：典型的在有限的可见性下的过程调用

6. 仓库风格

适用于主要问题是建立、增加和维护复杂信息的主体部分

信息一定要能够用很多种方式操作。经常需要长期的存在。

组件：

主要的数据结构能够表示出系统的正确状态 操作主要数据结构的独立组件的集合 连接器：典型地过程调用或是直接内存访问

7. 解释程序风格

适用于执行解决方案的最合适的语言或是机器不是直接可用的。

组件：包括一个状态机，有一个执行引擎和三个记忆状态：

当前的执行引擎的状态

程序被翻译

当前的被翻译的程序的状态

连接器：

过程调用 直接内存访问

8. 过程控制风格

适用于目的是维护特殊过程的输出属性在给定参考值的情形下

组件：

过程定义 包括操作一些过程变量的机制

控制算法 决定如何去操作过程变量

连接器：数据流关系

过程变量：

被控制的变量的值是系统能控制的

输入变量能够检测过程的输入

操纵变量的值能够被控制器改变

设置断点 是一个控制变量所需要的值

传感器 获得过程变量与控制有关的值

架构师需要的核心技能是什么

（1） 涉众之间的交流

(2） 技术知识

（3） 软件工程学

（4） 风险管理

什么是软件架构

它是关于软件设计：

所有的架构是软件设计，但不是所有的设计都是软件架构。 设计过程的一个部分 简单地说，架构关注“一旦系统建立后就很难或是不可能改变的问题”： 质量属性，例如安全性，性能 非功能性需求，像开销，硬件配置 更多的是在这个部分之后的

答：软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口_(计算机科学)来实现。

什么是架构风格

也叫架构风格，描述软件的基本结构组织或纲要，提供事先定义好的子系统，制定好责任并将它们组织在一起的法则和指南。

一组原则。你可以把它看成是一组为系统家族提供抽象框架的粗粒度模式。

什么是架构视图

一个架构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了此方面无关的实体。

各种架构风格的组件和连接器是什么

组件：对象

连接器：功能和过程调用（方法）

GRASP模式的具体内容

1.创造者

分配给类B职责来创造类A的一个实例如果：

（1） B聚合A的对象 （2） B包含A的对象

（3） B记录A的对象的实例 （4） B紧密地使用A的对象

（5） B被创建时有初始化的数据传递给

2.专家

在设计对象（类）时，如果某个类能够在某方面具有完整信息，足以实现某责任，就将这个责任分配给这个类，

3.控制器

控制器是在用户接口层上的第一个对象，负责接收和处理系统的操作信息。

4.低耦合

测量存在于模块之间的依赖程度

5.高内聚

测量一个共享的模块内元素的相关性

一个单独模块执行任务的程度是功能相关的

6.多态

当相关的供选方案或行为随着类型的变化而变化时，给行为分配职责—使用多态操作—来适合行为变化的类型。

7.纯虚构

分配一系列高度聚合的职责给虚假的类或是不表现某事完成的领域问题概念的有用的类，它支持高内聚、低耦合、可重用。

8.间接

问题：如何分配职责避免直接耦合？如何减弱对象的耦合？

解决方案：分配职责给中间的调解对象来调解两个组件之间的关系。

9．防止编译

问题：如何设计对象，子系统和系统，使其内部的变化和不稳定不会对其他元素产生不良影响？

解决方案：识别设计变化或不稳定之处，分配职责用以在这些变化之外创建稳定接口

GRASP用职责设计对象："Designing Objects with Responsibilities".它包含了9个基本模式： 1.信息专家（Information expert） 2.创建者（Creator） 3.高内聚（High Cohesion） 4.低耦合（Low Coupling） 5.控制器（Controller） 6.多态性（Polymorphism） 7.纯虚构（Pure Fabrication） 8.间接性（Indirection） 9.变化预防

（Protected Variations） GRASP的主要特征： - 对象职责分配的基本原则。 - 主要应用在分析和建模上。 GRASP的核心思想的理解： 自己干自己的事（职责的分配） 自己干自己的能干的事（职责的分配） 自己只干自己的事（职责的内聚）

OO设计的五个基本原则及课件中讲述的其它软件原理

1.单一职责原则

这个原则和关注点分离紧密联系。它陈述了每个对象应该只有一个理由去改变，单一聚焦在职责上。通过依附这个原则，你避免了庞大的类的设计问题，那就像瑞士的军刀。有了精确的对象，你再次增加了系统的可读性和可维护性。

2．开闭原则

这个原则陈述了类应该对扩展开放，对修改关闭，那样你就能够添加新的特征，扩展一个类而不用改变它内部的行为。这个原则旨在避免破坏存在的类及依赖它的其他类，这使得你的整个应用程序中产生故障和错误的涟漪。

3.Liskov替换原则

Liskov替换原则要求你应该能够使用任何衍生出的类代替父类，不用修改就有同样的行为。这个原则与开闭原则一致，它保证了一个衍生出的类不影响父类的行为，或者说，衍生出的类必须能够被它们的基类替代。

4.接口分离原则

这个原则是j将一个抽象方法分裂成几组职责，给这些组分配接口来防止客户端实现一个很大的接口，这个接口容纳了很多它们不使用的方法。目的是为了让类使用相同的接口只需要实现一些具体的方法，而不是有很多方法的庞大的接口。

5.依赖反转原则

把你的类从具体的实现中隔离开，使它们依赖于抽象类或接口。它促进了对接口而不是实现的译码，这通过保证对实现的低耦合来增加系统的灵活性。

课件:

1.面向抽象原则

设计一个类时，不让该类面向具体的类，而是面向抽象类或接口

2.开-闭原则

设计应当对扩展开放，对修改关闭。

如果您的设计遵守了“开-闭原则”，那么这个设计一定是易维护的，因为在设计中增加新的模块时，不必去修改设计中的核心模块。

3.高内聚-低耦合原则

如果类中的方法是一组相关的行为，则称该类是高内聚的，反之称为低内聚的。

所谓低耦合就是尽量不要让一个类含有太多的其它类的实例的引用，以避免修改系统的其中一部分会影响到其它部分。

企业应用架构在各层有那些主要的模式

三层架构的系统：表现层实现用户界面，在领域层实现领域逻辑，在数据源层存取数据

1.表现层(Presentation)：

提供服务、显示信息（如在WINDOWS或HTML页面中，处理用户请求，HTTP请求，命令行调用，批处理API）

2.领域层(Domain)：

领域逻辑，系统中真正的核心。也称为业务逻辑，它就是应用程序必须做的所有领域相关工作：包括根据输入数据或者已有数据进行计算，对从表现层输入的数据进行验证，以及根据从表现层接收的命令来确定应该调试哪些数据源逻辑。

3.数据源层(Data Source)：

与数据库、系统消息系统、事务管理器及其他软件包通信。最主要的数据源逻辑就是数据库，主要责任是存储持久数据。

Larman的敏捷UP设计方法的具体步骤

（1） 初始：大体上的构想、业务案例、范围和模糊评估。

（2） 细化：已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数需求和范围以及进行更为实际的评估。

（3） 构造：对遗留下来的风险较低和比较简单地元素进行迭代实现，准备部署。

（4） 移交：进行beta测试和部署。

4+1视图

逻辑视图：描述架构的重要元素及它们之间的关系

过程视图：描述架构元素之间的并发和通信

物理视图：描绘主要的过程和组件是如何映像到硬件上的

开发视图：俘获软件组件内部的结构，如配置管理工具

架构用例：俘获架构的需求；和不止一种视图相关

应用的集成策略

消除单点故障

复制和故障转移

自动检测和重新启动

掌握：命令模式，状态模式，装饰模式，观察者模式，策略模式，

单例模式，工厂方法模式，抽象工厂模式，组合模式

适配器模式，外观模式，责任链模式的UML图和java代码

命令模式（别名：动作，事务）

将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。

状态模式（别名：状态对象）

允许一个对象在其内部状态改变时改变它的行为。

观察者模式（别名：依赖，发布-订阅）

定义对象间的一种一对多的依赖关系，当一个对象的状态发生变化时，所有依赖于它的对象都得到通知并被自动更新。

策略模式（别名：政策）

定义一系列算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。

单件模式

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

工厂方法模式（别名：虚拟构造）

定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。

抽象工厂模式（别名：配套）

提供一个创建一系列（相互依赖）对象的接口，而无需指定它们具体的类。

组合模式

将对象组合成数形结构以表示“部分-整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性。

适配器模式（别名：包装器）

将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容

而不能一起工作的那些类可以一起工作

外观模式

为系统中的一组接口提供一个一致的界面，Façade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

凡是课件里有关架构的具体例子（一般都有UML图或有代码）都需要仔细体会，比如显示学生成绩和全名的程序的不同架构方法，计算应收账款（Revenue Recognition）的不同设计方法，农场计算动物脚数的设计方法等等（不一一列出了）。