Chapter 7 基于体系结构的软件开发
1. MVC解决方案：
●对于界面设计可变性的需求，MVC把交互系统的组成分解成模型、视图、控制三种构件。
（1）模型构件：独立于外在显示内容和形式，是软件所处理的问题逻辑的内在抽象，它封装了问题的核心数据、逻辑和功能的计算关系，独立于具体的界面表达和输入/输出操作。
（2）视图构件：把表现模型数据及逻辑关系和状态的信息以特定形式展示给用户，它从模型获得显示信息，对于相同的信息可以有多个不同的显示形式或视图。
（3）控制构件：处理用户与软件的交互操作，其职责是决定软件的控制流程，确保用户界面与模型间的对应关系，它接受用户的输入，将输入反馈给模型，进而实现对模型的计算控制，它是使模型和视图协调工作的部件。
2. 设计模式的定义：
●一套被反复使用、多人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码，让代码更容易被他人理解、保证代码的可靠性。
3. 设计模式的基本成分：
模式名称、问题、解决方案、后果。
4. 设计模式的分类：
（1）按照目的，分为创建型模式、结构型模式、行为型模式。
●创建型模式：对象的创建过程
●结构型模式：对象类的组合
●行为型模式：类和对象间的交互方式和任务分布
（2）按照范围，分为类模式、对象模式。
●类模式：处理类和子类之间的关系
●对象模式：处理对象之间的关系
5. 几种创建型模式：
（1）简单工厂模式
●特点：根据参数的不同返回不同类的实例。专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。
●结构：工厂角色、抽象产品角色、具体产品角色
●优点：实现对象的创建和对象的使用分离，将对象的创建交给专门的工厂类负责。
●缺点：工厂类不够灵活，增加新的具体产品需要修改工厂类的判断逻辑代码，而且产品较多时，工厂方法代码将会非常复杂。
●适用：工厂类负责创建的对象比较少；客户端只知道传入工厂类的参数，对于如何创建对象不关心。
（2）工厂方法模式
●特点：工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象，这样做的目的是将产品类的实例化操作延迟到工厂子类中完成。
●结构：抽象产品、具体产品、抽象工厂、具体工厂
●优点：增加新的产品类时无须修改现有系统，并封装了产品对象的创建细节，系统具有良好的灵活性和可扩展性。
●缺点：增加新产品的同时需要增加新的工厂，导致系统类的个数成对增加，在一定程度上增加了系统的复杂性。
●适用：一个类不知道它所需要的对象的类；一个类通过其子类来指定创建哪个对象；将创建对象的任务委托给多个工厂子类中的某一个，客户端在使用时可以无须关心是哪一个工厂子类创建产品子类，需要时再动态指定。
（3）抽象工厂模式
●特点：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。
●结构：抽象产品、具体产品、抽象工厂、具体工厂
●优点：隔离了具体类的生成，使得客户端并不需要知道什么被创建。当一个产品族中的多个对象被设计成一起工作时，它能够保证客户端始终只使用同一个产品族中的对象。增加新的产品族很方便，无须修改已有系统，符合开闭原则。
●缺点：增加新的产品等级结构麻烦，需要对原有系统进行较大的修改，甚至需要修改抽象层代码，这显然会带来较大的不便，违背了开闭原则。
●适用：一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节。系统中有多于一个的产品族，但每次只使用其中某一产品族。属于同一个产品族的产品将在一起使用，这一约束必须在系统的设计中体现出来。产品等级结构稳定，设计完成之后，不会向系统中增加新的产品等级结构或者删除已有的产品等级结构。
（4）原型模式
●特点：使用原型实例指定待创建对象的类型，并且通过复制这个原型来创建新的对象。
●结构：抽象原型类、具体原型类、客户类
●优点：简化对象的创建过程，通过复制一个已有实例可以提高新实例的创建效率。扩展性较好。提供了简化的创建结构。可以使用深克隆的方式保存对象的状态。
●缺点：需要为每一个类配备一个克隆方法，而且该克隆方法位于一个类的内部，当对已有的类进行改造时，需要修改源代码，违背了开闭原则。实现深克隆时需要编写较为复杂的代码。
●适用：创建新对象成本较大。对象的状态变化很小。避免使用分层次的工厂类来创建分层次的对象。
（5）建造者模式
●特点：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
●结构：抽象建造者、具体建造者、指挥者、产品角色
●优点：客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象，每一个具体建造者都相对独立，而与其他的具体建造者无关，因此可以很方便地替换具体建造者或增加新的具体建造者，符合“开闭原则”，还可以更加精细地控制产品的创建过程。
●缺点：由于建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，因此其使用范围受到一定的限制，如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大。
●适用：需要生成的产品对象有复杂的内部结构，这些产品对象通常包含多个成员属性；需要生成的产品对象的属性相互依赖，需要指定其生成顺序；对象的创建过程独立于创建该对象的类；隔离复杂对象的创建和使用，并使得相同的创建过程可以创建不同类型的产品。
（6）单例模式
●特点：确保一个类只有一个实例，并提供一个全局访问点来访问这个唯一实例。
●结构：单例
●优点：提供了对唯一实例的受控访问。节约系统资源，提高系统的性能。允许可变数目的实例（多例类）。
●缺点：扩展困难（缺少抽象层）。单例类的职责过重。自动垃圾回收机制，可能会导致共享的单例对象的状态丢失。
●适用：系统只需要一个实例对象，或者因为资源消耗太大而只允许创建一个对象。客户调用类的单个实例只允许使用一个公共访问点，除了该公共访问点，不能通过其他途径访问该实例。
6. 面向对象设计原则：
7. 基于体系结构的设计方法（ABSD）：
●相关术语：
（1）设计元素：泛指软件系统、概念子系统、概念构件。
（2）视角和视图：使用不同的视角观察设计元素。选定的特定视角或视图也就是逻辑视图、进程视图、实现视图和配置视图。
（3）用例和质量场景：用例用来捕获功能需求。质量场景用来捕获质量需求，质量场景捕获变更、性能、可靠性和交互性，分别称之为变更场景、性能场景、可靠性场景和交互性场景。质量场景必须包括预期的和非预期的刺激。
●ABSD方法与生命周期：
（1）ABSD方法与生命周期
（2）ABSD方法的输入：
抽象功能需求
用例
抽象的质量和商业需求
质量因素
体系结构选项
约束
●ABSD方法的步骤：
8. 体系结构的设计与演化：
●设计和演化过程：
（1）实验原型阶段
第一个开发周期：没有具体的、明确的目标。结束时形成两个版本，一个是图形用户界面的初始设计，另一个是问题域模型。
第二个开发周期：设计和建立一个正交软件体系结构。
标识构件
提出软件体系结构模型
把已标识的构件映射到软件体系结构中
分析构件之间的相互作用
产生软件体系结构
软件体系结构正交化
（2）演化开发阶段
9. 基于体系结构的软件开发模型（ABSDM）：
●传统的软件开发过程可以划分为从概念直到实现的若干个阶段，包括问题定义、需求分析、软件设计、软件实现及软件测试等。如果采用传统的软件开发模型，软件体系结构的建立应位于需求分析之后，概要设计之前。
●传统软件开发模型存在开发效率不高，不能很好地支持软件重用等缺点。ABSDM模型把基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现、演化等子过程。
●体系结构需求：
●体系结构设计过程：
●体系结构文档化：主要输出结果是体系结构需求规格说明书和测试体系结构需求的质量设计说明书这两个文档。文档的完整性和质量是软件体系结构成功的关键因素。
●体系结构复审：目的是标识潜在的风险，及早发现体系结构设计中的缺陷和错误。由外部人员进行复审的目的是保证其能共振地进行检验。
●体系结构实现过程：
●体系结构演化过程：
