一、设计模式 design paternal
1.MVC model view controller 模型-视图-控制器
MVC把交互系统的组成分解成模型、视图、控制三种构件。
模型：独立于外在显示内容和形式，是软件所处理的问题逻辑的内在抽象，它封装了问题的核心数据、逻辑和功能的计算关系，独立于具体的界面表达和输入、输出操作。
视图：模型数据及逻辑关系和状态的信息以特定的形式展示给用户，从模型获得显示信息，对于相同的信息有不同的显示形式或试图。
控制：处理用户与软件的交互操作，职责是决定软件的控制流程，确保用户界面与模型间的对应关系，接收用户的输入，将输入反馈给模型，进而实现对模型的计算控制，是使模型和视图协调工作的部件。
2.面向对象设计原则
设计原则名称 |
设计原则简介 |
单一职责原则 (Single Responsibility Principle, SRP) |
类的职责要单一，不能将太多的职责放在一个类中 |
开闭原则 (Open-Closed Principle, OCP) |
软件实体对扩展是开放的，但对修改是关闭的，即在不修改一 个软件实体的基础上去扩展其功能 |
里氏代换原则 (Liskov Substitution Principle, LSP) |
在软件系统中，一个可以接受基类对象的地方必然可以接受一 个子类对象 |
依赖倒转原则 (Dependency Inversion Principle, DIP) |
要针对抽象层编程，而不要针对具体类编程 |
接口隔离原则 (Interface Segregation Principle, ISP) |
使用多个专门的接口来取代一个统一的接口 |
合成复用原则 (Composite Reuse Principle, CRP) |
在系统中应该尽量多使用组合和聚合关联关系，尽量少使用甚 至不使用继承关系 |
迪米特法则 (Law of Demeter, LoD) |
一个软件实体对其他实体的引用越少越好，或者说如果两个类 不必彼此直接通信，那么这两个类就不应当发生直接的相互作 用，而是通过引入一个第三者发生间接交互 |
（1）单一职责原则(Single Responsibility Principle,SRP)
一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。
（2）开闭原则(Open-Closed Principle, OCP)
一个软件实体应当对扩展开放，对修改关闭。也就是说在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展，即实现在不修改源代码的情况下改变这个模块的行为。
（3）里氏代换原则(Liskov SubstitutionPrinciple, LSP)
所有引用基类（父类）的地方必须能透明地使用其子类的对象。
（4）依赖倒转原则(Dependence InversionPrinciple, DIP)
高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。要针对接口编程，不要针对实现编程。
（5）接口隔离原则(Interface SegregationPrinciple, ISP)
客户端不应该依赖那些它不需要的接口，使用多个专门的接口，而不使用单一的总接口。每一个接口应该承担一种相对独立的角色。
（6）合成复用原则(Composite Reuse Principle,CRP)
尽量使用对象组合，而不是继承来达到复用的目的，在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用其已有功能的目的。简言之：要尽量使用组合/聚合关系，少用继承。
（7）迪米特法则(Law of Demeter, LoD)
一个软件实体应当尽可能少的与其他实体发生相互作用。
3.设计模式的定义
设计模式(Design Pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
4.设计模式的关键元素
• 模式名称 (Pattern name)
• 问题 (Problem)
• 解决方案 (Solution)
• 效果 (Consequences)
5.设计模式的分类
根据其目的（模式是用来做什么的）可分为创建型(Creational)，结构型(Structural)和行为型(Behavioral)三种：
创建型模式主要用于创建对象。
结构型模式主要用于处理类或对象的组合。
行为型模式主要用于描述对类或对象怎样交互和怎样分配职责。
根据范围，即模式主要是用于处理类之间关系还是处理对象之间的关系，可分为类模式和对象模式两种：
类模式处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，是属于静态的。
对象模式处理对象间的关系，这些关系在运行时刻变化，更具动态性。
6.设计模式的优点
设计模式融合了众多专家的经验，并以一种标准的形式供广大开发人员所用，它提供了一套通用的设计词汇和一种通用的语言以方便开发人员之间沟通和交流，使得设计方案更加通俗易懂。对于使用不同编程语言的开发和设计人员可以通过设计模式来交流系统设计方案，每一个模式都对应一个标准的解决方案，设计模式可以降低开发人员理解系统的复杂度。
设计模式使人们可以更加简单方便地复用成功的设计和体系结构，将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。设计模式使得重用成功的设计更加容易，并避免那些导致不可重用的设计方案。
设计模式使得设计方案更加灵活，且易于修改。
设计模式的使用将提高软件系统的开发效率和软件质量，且在一定程度上节约设计成本。
设计模式有助于初学者更深入地理解面向对象思想，一方面可以帮助初学者更加方便地阅读和学习现有类库与其他系统中的源代码，另一方面还可以提高软件的设计水平和代码质量。
7.简单工厂、工厂（重点掌握）、抽象工厂、建造者、原型、单例模式（元素、组成、特点、优点、缺点、适用场合详细见作业）
二、基于体系结构的设计方法 architecture-based software design ABSD
1.基本概念
设计元素：泛指软件系统、概念子系统、概念构件
视角和视图：
用例：用来捕获功能需求，给用户一个结果值的功能点
质量场景：定义特定场景来捕获质量需求
2.ABSD生命周期（知道ABSD的输入和输入分别是什么）
3.ABSD步骤
（1）分解一个设计元素的步骤
（2）定义逻辑视图
（3）整体步骤
- 功能分解
- 选择体系结构风格
- 为风格分配功能
- 细化模板
- 功能校验
- 创建并发视图
- 创建配置视图
- 创建质量场景
- 验证约束
基于体系结构的软件开发过程可以分为独立的两个阶段，这两个阶段分别是实验原型阶段和演化开发阶段。
实验原型阶段分为两个周期，第一个周期完成图形用户界面的初始设计和问题域模型，第二个周期是设计和建立一个正交软件体系结构。第二个周期分为六个阶段：
（1）标识构件
（2）提出软件体系结构模型
（3）构件映射到软件体系结构中
（4）分析构件之间的相互作用
（5）产生软件体系结构
（6）软件体系结构的正交化
演化开发阶段分为八个步骤：
（1）需求变动归类
（2）指定体系结构演化计划
（3）修改、增加或删除构件
（4）更新构件的相互作用
（5）产生演化后的体系结构
（6）迭代
（7）阶段性技术评审
（8）对所做的标记进行处理
三、基于体系结构的软件开发模型
1.ABSD与传统软件开发模型的区别（掌握）
传统软件开发过程：问题定义、需求分析、软件体系结构建立、软件设计、软件实现、软件测试。
ABSDM(基于体系结构的软件开发模型)
2.体系结构需求（以下内容了解）
3.体系结构设计
4.体系结构实现
5.体系结构演化
