NEFU系统分析与设计

系统分析与设计概述

用户故事

用来描述用户希望得到的功能
三要素：角色、活动、商业价值
举例：作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。

系统特性

• 整体性：一般来说，系统的整体功能大于组成系统的各部分的功能之和
• 目的性：任何系统都有某种目的，都要实现一定的功能，多个目标可能不一致甚至矛盾，需要平衡求整体最优
•  相关性：各部分相互依赖、制约，某部分变化会影响其他部分
• 环境适应性：适应环境变化，保持原有功能
• 层次性：可以分解为一些列子系统，具有层次，各层次有独立的功能，通过相互联系、作用共同完成系统功能

系统分析：理解问题域

系统设计：求可行解

DevOps

开发运维一体化，人 + 流程 + 平台

五要素

• 文化：开发和运维结合
• 自动化：自动化一切可以自动化的
• 精益：小步快跑，持续改善
• 度量
• 分享

系统规划

系统规划是制定长期系统方案，决定系统在整个生命周期内的发展方向、规模和发展进程，是系统生命周期的第一阶段

系统规划步骤

1. 对当前系统进行初步调查

2. 分析确定系统目标

3. 分析子系统组成和功能

4. 拟定系统实施方案

5. 进行可行性研究

系统分析模型

诺兰模型

• 初级阶段（计算机时代）：初装，蔓延
• 中级阶段（信息资源规划时代）：控制，集成
• 高级阶段（信息时代）：数据管理，成熟

CMM 模型

• 三要素：能力、成熟度、模型
• 五个开发等级
  • 初始级 Initial
  • 可重复级 Repeatable
  • 已定义级 Defined
  • 已管理级 Managed
  • 优化级 Optimizing
• 意义
  • 对软件公司：提高软件公司软件开发的管理能力、软件生产率、软件质量、公司的国内和国际竞争力
  • 对软件项目发包单位和软件用户：提供了对开发商管理水平的评估手段，有助于风险识别

系统规划方法

战略集合转换法 SST

MIS的战略规划过程是把组织的战略目标转化为管理信息系统战略目标的方法

步骤

• 识别组织的战略集
  • 描绘出组织各类人员或实体结构
  • 对于每类人员或实体识别系统相应的使命及战略
• 将组织战略集转化为信息系统战略
  • 根据组织目标确定信息系统目标
  • 对应组织战略集的元素识别相应信息系统战略的约束
  • 根据信息系统目标和约束提出信息系统战略

关键成功因素法 CSF

通过分析找出使得企业成功的关键因素，然后再围绕这些关键因素来确定系统的需求，并进行规划

步骤：

• 了解企业或MIS的战略目标

• 识别所有的成功因素

• 确定关键成功因素

• 明确各关键成功因素的性能指标和评估标准

方法：头脑风暴法

表示方法：鱼骨图（因果图）

企业资源规划法 BSP

为指导企业管理信息系统的开发而建立的规范方法。用于企业内部系统开发。
先自上而下识别系统目标、识别企业的过程、识别数据，然后再自下而上地设计系统目标，最后把企业目标转为信息系统规划的全过程。

核心步骤：定义企业目标→定义企业过程→定义数据类→定义信息系统总体结构

准备工作

成立规划领导小组
提出工作计划
开动员会

调查研究

为后续完成的任务内容有必须的了解

访谈、问卷、现场记录、文献研究、实验、头脑风暴

定义业务过程（核心过程）

管理中必要且逻辑上相关的、为了完成某种管理功能的一组活动

企业活动一般由三个方面组成：计划和控制、产品和服务、支持资源

计划和控制

企业计划和控制有关的业务过程一般分为战略规划和管理控制两大类

产品与服务

按产品/服务的生命周期的各个阶段识别过程
画出产品/服务过程的总流程图，写出每个过程的说明

支持资源

业务过程重组

哪些业务过程是正确的
哪些业务过程低效，需要在信息技术支持下实现优化
哪些业务过程无效，或不适合于计算机处理，应当在业务中予以取消

定义数据类

实体法、功能法

实体法

实体分类：指企业实施管理的对象，一般可按人、地点、物体、概念和事件进行分类，如企业员工、设备、产品和材料等。

• 计划型：反映目标的计划值

• 统计型：反映企业的综合状况

• 文档型：反映实体的现状

• 业务型：反映生命周期各阶段相关文档型数据的变化、

功能法

定义系统总体结构（U/C矩阵）

划分子系统。BSP方法将过程和数据类两者作为定义企业信息系统总体结构的基础，用过程／数据矩阵(也称U／C矩阵)表达两者之间的关系。

U/C 矩阵

• 过程/数据矩阵（U/C）行表示数据类，列表示过程，字母U(use)和C(create)来表示过程对数据类的使用和产生

• 主要功能

  • 正确性校验：及时发现前段分析和调查工作的疏漏和错误，分析数据的正确性和完整性
  • 对 U/C 求解过程得到子系统的划分
  • 通过子系统之间的联系U 可以确定子系统间共享的数据

• 可能的问题

  • 多功能生成同一数据类：功能合并或分解数据类
  • 数据类无 C/U：对功能核对
  • C/U 分布无规律：调顺序

• 正确性校验

  • 完备性检验：每个数据类必须有一个产生者（C）和至少一个使用者（U），每个功能则必须有产生或使用（U或C）数据类型。
  • 一致性检验：每个数据类型必有且仅有一个产生者（C）
  • 无冗余性检验：指 U／C矩阵中不允许有空行和空列

• 7、确定总体结构中的优先顺序

• 8、完成BSP研究报告，提出建议书和开发计划

定义系统总体结构（U/C矩阵）

三法结合

价值链分析法

系统分析

系统分析概述

系统分析将一个系统分解成各个组成部分，目的是研究各部分如何工作，如何交互，以实现系统的目标。是问题解决技术

目的：将需求及解决方法确定下来，建立逻辑模型

需求工程阶段

• 可行性分析
• 需求开发
  • 需求获取
  • 需求分析
  • 需求规格说明
  • 需求验证
• 需求管理

需求三层次

• 业务需求
• 用户需求
• 系统需求

需求分类

• 功能
• 非功能：性能、质量属性、接口、约束、可靠性、安全性、保密性

结构化的系统分析

业务流程图

业务流程图用一些规定的符号及连线来表示某个具体业务处理过程。是一种系统分析人员都懂的共同语言, 用来描述系统组织结构、业务流程

可以用泳道划分

系统流程图

又叫事务流程图，反应主体框架。是在计算机事务处理应用进行系统分析时常用的一种描述方法，描述事务处理中从数据输入开始到获得输出为止各个处理工序过程

描绘系统物理模型的工具。基本思想是用图形符号以黑盒子的形式描绘系统理念的每个部件包括程序，文件，数据库，表格，人工过程等，表达信息在各个部件之间流动的情况，而不是表示对信息进行加工处理的控制过程

 基本处理工序

• 变换：把输入单据变换成磁盘文件，或把磁盘文件变换成输出单据，或把某一磁盘文件的内容由一个介质文件传送到另一介质文件
• 合并：把多个文件合并为一个文件
• 划分：是合并的逆操作，将合并工序的输入文件与输出文件对调即可
• 分类（排序）：按指定的键（关键字）以升序或降序改变原文件的记录排列顺序。例如，将如下记录排列的旧文件，按关键字升序，依次进行分类，得到新文件
• 更新：将多个文件作为输入根据关键项目进行对照，对文件进行内容修正、删除、增加等改写工作，一般更新的内容先要写入一个临时文件

变换

划分

 分类

更新 

面向对象系统分析

分层类图

分析管理

需求确认：考虑需求风险和优先级（查文档看是否合格）
需求评审：主要内容

需求管理
（1）需求标识，分类，组织需求并建立文档
（2）需求变更（委员会，步骤）
（3）需求跟踪
（4）版本控制

系统分析说明书

系统设计

系统设计内容

• 功能
• 性能
• 过程设计（处理流程）
• 运行环境
• 用户界面设计
• 关键技术和算法
• 数据库，数据结构
• 安全性，保密性
• 为响应需求做出的其他系统级的设计决策
• 系统架构设计：总体，层次结构，部件，接口，动态交互
• 输入输出（I/O）：对输入或条件进行响应的系统行为的设计决策
• 硬件
• 代码设计
• 系统配置项设计，人工处理等
• 运行设计
• 出错处理设计
• 系统维护设计

系统设计原则

• 组件化
• 抽象化
  • 设计一个类时，不让该类面向具体的类，而是面向抽象类或接口，即所设计类中的重要数据是抽象类或接口声明的变量，而不是具体类声明的变量
    • 在较低的抽象层次上，则采用过程化的方法
    • 在最高的抽象层次上，可以使用问题所处环境的语言概括地描述问题的解法。
    • 软件系统进行模块设计时，可有不同的抽象层次。
  • 过程的抽象
  • 数据的抽象

内聚和耦合

• 内聚
  • 低内聚
    • 偶然内聚：模块内各个操作之间基本无联系或只有很松散的联系
    • 逻辑内聚：模块内各个操作功能类似，通过判断参数决定某功能的执行，又称控制内聚
    • 时间内聚：模块内的操作基本无关联，仅因为执行时间相同而组合在一起
  • 中内聚
    • 过程内聚：模块内的操作必须按照特定顺序执行
    • 通信内聚：模块内的操作有相同的输入或输出数据
  • 高内聚
    • 信息内聚（顺序）：模块多种功能在同一个数据结构上操作，各功能有唯一入口点
    • 功能内聚：模块内的操作是完成某一功能必不可少的部分
• 耦合
  • 内容耦合(Content Coupling)
    • 一个组件访问另一组件内部数据
    • 一个组件不通过正常入口转到另一组件内部
    • 两个组件有一部分程序代码重叠(只可能出现在汇编语言中);
    • 一个组件有多个入口
  • 公共耦合 Common Coupling
    • 多个模块引用同一个全局数据区
    • 两种情况：松散公共耦、紧密公共耦合
    • 问题：公共部分的改动将影响所有调用它的模块；公共部分的数据存取无法控制；复杂程度随耦合模块的个数增加而增加
  • 外部耦合 External Coupling：一组模块都访问同一全局简单变量而不是同一全局数据结构，且不是通过参数表传递该全局变量的信息，则称之为外部耦合
  • 控制耦合Control Coupling
    • 传递的信息中有控制信息(尽管有时这种控制信息以数据的形式出现) 。
    • 它增加了系统的复杂程度。控制耦合常是多余的，在把模块适当分解后通常可用数据耦合代替
  • 标记耦合，特征耦合(Stamp Coupling)：一个数据结构的一部分借助于模块接口被传递
  • 数据耦合(Data Coupling)低耦合
    • 两模块彼此间通过简单数据参数交换信息，且交换的信息仅是数(不是控制参数、公共数据结构或外部变量)来交换输入、输出信息的
    • 系统中至少必须存在这种耦合，因为只有当某些模块的输出数据作为另一些模块的输入数据时，系统才能完成有价值的功能。一般，一个系统内可以只包含数据耦合
  • 非直接耦合(Nondirect Coupling)
    • 两模块间没直接关系，它们间的联系完全是通过主模块的控制和调用来实现的
    • 模块独立性最强
  • 原则：实际上，模块之间是混合式的耦合；尽量使用数据耦合，少用控制耦合，限制公共耦合的范围，完全不用内容耦合。

信息隐藏和局部化
模块独立性

理由：
1、有效的模块化(即具有独立的模块)的软件较容易开发。因能分割功能且接口可简化，多人分工合作开发，该优点很重要。
2、独立的模块较易测试和维护。因修改设计和程序需要的工作量较小，错误传播范围小，要扩充功能时能够“插入”模块。

启发式规则

• 深度，宽度，扇出，扇入
• 作用域和控制域
• 可预测性
• 争取低耦合、高内聚（增加内聚 > 减少耦合

模块独立性

• 模块三个基本属性
  • 功能：描述该模块实现什么功能
  • 逻辑：描述模块内部怎么做
  • 状态：该模块使用时的环境和条件
• 重要性
  • 有效的模块化(即具有独立的模块)的软件较容易开发。因能分割功能且接口可简化，多人分工合作开发，该优点很重要
  • 独立的模块较易测试和维护。因修改设计和程序需要的工作量较小，错误传播范围小，要扩充功能时能够“插入”模块

结构化设计

结构化设计工具

层次图

HPO图

HPO图以模块分解的层次性以及模块内部输入、处理、输出三大基本部分为基础建立的。（可带编号）

 IPO图

描述输入数据、对数据的处理和输出数据之间的关系。

NS图（盒图）

 PAD图（问题分析法）

处理流程图

 判定表与判定树

软件结构图

面向对象设计

静态建模

UML可描述三个主要的类

• 边界类：系统及其参与者的边界
• 控制类：系统的控制逻辑
• 实体类：系统使用的信息

• 种类：类图、对象图、包图
• 步骤：
  • 寻找确定对象类
  • 定义类的接口
  • 定义类之间的关系
  • 建立对象类图
  • 建立系统包图

类图

类之间的关系（4-6种）

• 关联（拥有， ASSOSATION，使用实例连接/单，双，自，弱）
  • 关联和聚合的区别：语义上，关联的两个对象之间一般是平等的
  • 关联和泛化（类之间的语义关系）
• 聚合 HAS A
  • 整体和部分关系
  • 比关联强，比组合弱
• 组合 contains-a
  • 整体和部分关系，合成关系
  • 部分不能离开整体，同生共死
  • 整体的重数必须是0或1
• 泛化(继承， GENERALIZATION )
  • 一般和特殊的区别
  • 受限泛化（高级）：多重、不相交、完全和不完全
• 实现：拥有，类和接口的关系
• 依赖（DEPENDENCY）
  • 一个是独立的模型元素，另一个是依赖的，独立元素的变化会影响依赖的元素
  • 暗示如果没有依赖类的支持会不完整

对象图

• 对象图中包含对象和链，对象是类的特定实例，链式类之间的关系的实例，表示对象之间的特定关系
• 对象图用来描述特定时刻各个对象之间的关系，是类图在某个特定时刻的实例
• 一个系统可以有多个对象图
• 对象图描述系统内某个时刻的静态结构

包图

包：展现模块和模块之间的依赖关系

包拥有的元素：类、接口、组件、节点、协作、用例、图以及其他包

特点：一个模型元素不能被一个以上的包所拥有；如果一个包被撤销，其中元素也被撤销

一个包形成了一个命名空间，和其他的区分：简单名、路径名

可见性：private、protected、public

包的嵌套

包之间的关系：依赖、继承

动态建模 

消息

组成部分：发送者、接收者、活动

• 消息分类：
  • 同步系统：都是同步消息
  • 并发系统：：同步消息、异步消息
• 接受者是否唯一
  • 定向消息
  • 广播消息

顺序图 

概念

• 用来描述对象间的交互行为。表现用例中的行为顺序，描述了如何一步步完成系统的某项功能
• 注重消息的时间顺序，即对象间消息的发送和 接收的顺序，并将交互建模成对象之间消息交换的图形
• 顺序图还揭示了一个特定场景的交互，即系统执行期间发生在某个时间点的对象之间的特定交互，它适合于描述实时系统中的时间特性和时间约束
• 序列图将交互关系表示为一个二维图。其中，纵轴是时间轴，时间沿竖线向下延伸。横轴代表了在交互中各独立的对象

组成

• 对象：顺序图中所包含的每个对象用一个对象框（短式）表示，对象名需带下划线
• 生存线：对象框下画的一条垂直虚线，称为该对象的生存线，表示对象的生存时间
• 激活期：对象生存线上的一个细长方形框，表示该对象的激活时间段，即活动期间
• 消息：对象之间消息的发送和接收用两个对象生存线（激活期）之间的消息箭头线

 条件分支

约束

循环

对象的消亡

合作图

概念

• 合作图可以用来描述系统对象之间的交互,表现对象协作关系的图，动态视图的另一种表现形式
• 强调这组对象之间的关系，强调发送和接受消息的对象之间的结构组织的交互图，显示对象、对象之间的链接以及对象之间的消息
• 它表示了协作中作为各种类元角色的对象所处的位置，在图中主要显示了类元角色（Classifier Roles）和关联角色（Association Roles）

组成

• 对象
• 链接：表示参与协作执行的关联的描述多重性、角色；当协作被实例化时，对象受限于类元角色，连接受限于关联角色；链是对象间的发送消息的路径
• 消息
  • 嵌套消息：整数指定顺序号，如1.1是消息1的第一个嵌套消息
  • 并发消息：并行的控制线程，如1. 2a和1. 2b
  • 循环消息：*[循环执行条件]
  • 条件发送消息：[执行条件]
  • 异步消息
  • 回调消息
• 约束
  • 全局性：角色是全局的
  • 局部性：角色是一个操作中的局部变量
  • 参数性：角色是一个操作中的参数
  • 自我性：对象可以向自身发送消息
  • 表决性：用于通过约束（通过对回送值的表决）回送消息
  • 广播性：一组消息的约束（系统中每个对象都是潜在的目标对象）
     
• 对象的创建与消亡
  • 创建{new}
  • 消亡{destroyed}
  • 创建并消亡{transient}

对象创建：{new}
对象消亡：{destroyed}
对象创建并消亡：{transient}

系统体系结构模型

软件系统体系结构模型

概念：是系统的逻辑体系结构模型,刻画系统功能在逻辑组成部分上的分配,以及各部分间如何协调工作

作用

• 指出系统应该具有的功能；
• 为完成这些功能，涉及到哪些类，这些类之间如何相互联系；
• 类和它们的对象如何协作才能实现这些功能；
• 指明系统中各功能实现的先后时间顺序；
• 根据软件系统体系结构模型，制定出相应的开发进度计划。

通用的描述方法

• 通用接口界面层
• 系统业务对象层
• 系统数据库（持久对象和数据）层

硬件系统体系结构模型

• 概念：是系统的逻辑体系结构模型,刻画系统功能在逻辑组成部分上的分配,以及各部分间如何协调工作
• 作用
  • 标明系统中配置的计算机和其他硬件设备；
  • 并指明系统中各种计算机和硬件设备如何进行相互连接；
  • 指出系统中的类和对象涉及的具体程序或进程；
  • 这些程序和进程的执行依赖具体计算机；
  • 明确不同的代码文件之间相互的依赖关系；
  • 如果修改某个代码文件，标明哪些相关（与之有依赖关系）的代码文件需要重新进行编译

 构件图

构件图：物理方面建模时要用的两种图之一，说明构件之间的逻辑关系

简单构件图案例（也可以嵌套）

构件

构件：逻辑体系结构中定义的概念和功能在物理体系结构中的实现

作用

• 对源代码建模

• 对可执行体的建模

• 从整体了解物理部件，显示构件间关系

• 可调整的系统建模

 表示：组件，接口，关系（实现、依赖、关联、继承）

与类的相同点

• 都有名称
• 都可实现一组接口
• 都可参与依赖、继承、关联等关系和交互
• 都可被嵌套
• 都可有实例

与类的不同点

• 抽象方式不同
• 抽象级别不同
• 访问方式不同
• 与包的关系

构件的组织

• 用包来组织构件
• 用构件之间的交互关系来组织构件(依赖、继承、关联、实现)

部署图

部署（配置）图：描述处理器、设备和软件构件运行时的体系结构

基本元素：结点、组件、对象、连接、依赖

应用范围：网络环境下的分布式、嵌入式系统

每一个模型中仅包含一个部署图结点之间的通信关联：连接硬件时通常关心节点之间是如何连接的(如以太网、并行、TCP或USB等)。

依赖

• 支持依赖：一个结点和其内部构件
• 成为依赖：不同结点内部构件或对象之间

设计模式

组成

• 名
• 问题
• 解决方案
• 效果

设计原则

单一职责原则

降低一个类的复杂度，一个类只负责一项职责

开闭原则（最核心）

对象对于扩展时开放的，但是对于修改是封闭的
一个实体不允许在改变源码的情况下变更它的行为

Liskov原则——里氏代换原则（实现开闭原则的方法）

子类可以扩展父类的功能，但是不能改变父类原有的功能

在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象

• 子类可以实现父类的抽象方法，但是不能覆盖父类的非抽象方法
• 子类中可以增加自己特有的方法
• 当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松

依赖倒置原则

依赖倒置的中心思想是面向接口

高层模块不依赖于低层模块，二者要分别依赖于其抽象
接口不依赖于细节，而是细节依赖于接口

接口隔离原则

一个类对另一个类的依赖应建立在最小的接口上
接口里面的方法越少越好

优先组合而非继承

优先使用组合而不是继承
继承是强耦合关系，如果基类出现变动，字类必须变动
组合就不会有这样的问题

迪米特原则

最少知道原则，一个对象对其他对象知道的越少越好，不和陌生人说话

如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用

设计模式

• 创建型模式主要用于创建对象。
• 结构型模式主要用于处理类或对象的组合。
• 行为型模式主要用于描述对类或对象怎样交互和怎样分配职责

4个基本元素：名，问题，解决方案，效果

设计模式具有的优点  适应需求变化

创建型模式

创建型模式（Creational Pattern）对类的实例化过程进行抽象能将软件模块中对象的创建和对象的使用分离。为使软件结构更清晰，外界对于这些对象只需知道它们共同的接口，而不清楚具体的实现细节，使整个系统的设计更符合单一职责原则

简单工厂模式（不是设计模式）

简单工厂模式（Simple Factory Pattern）是一种创建型设计模式，它提供了一个统一的接口来创建对象，但隐藏了对象的具体实现细节。

简单工厂模式由三个角色组成：

1. 工厂（Factory）角色：负责创建对象的工厂类，它根据客户端的请求创建具体的产品对象。
2. 抽象产品（Product）角色：定义了产品的共同接口，所有具体产品类都必须实现这个接口。
3. 具体产品（Concrete Product）角色：实现了抽象产品接口的具体产品类。

简单工厂模式的工作流程如下：

1. 客户端通过调用工厂类的静态方法来创建产品对象。
2. 工厂类根据客户端的请求，选择合适的具体产品类来创建对象。
3. 工厂类将创建的产品对象返回给客户端。

简单工厂模式的优点包括：

1. 客户端与具体产品类解耦：客户端只需要与工厂类进行交互，不需要直接与具体产品类进行交互，降低了客户端与具体产品类之间的耦合度。
2. 隐藏对象的创建细节：客户端只需要知道产品的接口，不需要了解具体的创建细节，简化了客户端的使用。
3. 不修改客户端代码，可加具体产品类，提高灵活性

然而，简单工厂模式也存在一些缺点：

1. 违反了开闭原则：每次新增一个具体产品类，都需要修改工厂类的代码，违反了开闭原则。
2. 工厂类职责过重：工厂类负责创建所有的产品对象，随着具体产品类的增多，工厂类的代码会变得庞大复杂。

因此，简单工厂模式适用于产品种类相对较少且不会频繁变化的场景，对于产品种类较多或经常变化的场景，建议使用工厂方法模式或抽象工厂模式。

工厂方法模式

 工厂方法模式（Factory Method Pattern）是一种创建型设计模式，它定义了一个用于创建对象的接口，但由子类决定要实例化的类是哪一个。核心： 一个抽象工厂

工厂方法模式由四个角色组成：

1. 抽象工厂（Abstract Factory）角色：定义了创建产品对象的接口，包含一个抽象的工厂方法，子类通过实现这个方法来创建具体的产品对象。
2. 具体工厂（Concrete Factory）角色：实现了抽象工厂接口，负责创建具体的产品对象。
3. 抽象产品（Abstract Product）角色：定义了产品对象的接口，是所有具体产品类的父类。
4. 具体产品（Concrete Product）角色：实现了抽象产品接口，是被创建的对象。

工厂方法模式的工作流程如下：

1. 客户端通过调用具体工厂类的工厂方法来创建产品对象。
2. 具体工厂类根据客户端的请求，创建对应的具体产品对象。
3. 具体工厂类将创建的产品对象返回给客户端。

工厂方法模式的优点包括：

1. 客户端与具体产品类解耦：客户端只需要与抽象工厂和抽象产品进行交互，不需要直接与具体产品类进行交互，降低了客户端与具体产品类之间的耦合度。
2. 符合开闭原则：新增一个具体产品类时，只需要新增一个对应的具体工厂类，不需要修改已有的代码。

然而，工厂方法模式也存在一些缺点：

1. 类的个数增多：每个具体产品类都需要对应一个具体工厂类，导致类的个数增多。
2. 增加了系统的抽象性和理解难度：工厂方法模式将对象的创建分散到多个具体工厂类中，增加了系统的抽象性和理解难度。

工厂方法模式适用于产品种类较多且需要客户端自由选择具体产品的场景，对于产品种类较少或固定的场景，建议使用简单工厂模式。

抽象工厂模式 

抽象工厂模式（Abstract Factory Pattern）是一种创建型设计模式，它提供了一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

抽象工厂模式由四个角色组成：

1. 抽象工厂（Abstract Factory）角色：定义了创建一系列产品对象的接口，包含多个抽象的工厂方法，每个工厂方法用于创建一个具体产品对象的系列。
2. 具体工厂（Concrete Factory）角色：实现了抽象工厂接口，负责创建一系列具体产品对象的系列。
3. 抽象产品（Abstract Product）角色：定义了产品对象的接口，是所有具体产品类的父类。
4. 具体产品（Concrete Product）角色：实现了抽象产品接口，是被创建的对象。

抽象工厂模式的工作流程如下：

1. 客户端通过调用具体工厂类的工厂方法来创建一系列产品对象。
2. 具体工厂类根据客户端的请求，创建对应的一系列具体产品对象。
3. 具体工厂类将创建的产品对象返回给客户端。

抽象工厂模式的优点包括：

1. 客户端与具体产品类解耦：客户端只需要与抽象工厂和抽象产品进行交互，不需要直接与具体产品类进行交互，降低了客户端与具体产品类之间的耦合度。
2. 符合开闭原则：新增一个具体产品类时，只需要新增一个对应的具体工厂类，不需要修改已有的代码。
3. 产品族的一致性：抽象工厂模式可以保证一系列相关产品的一致性，即创建的产品对象属于同一个产品族。

然而，抽象工厂模式也存在一些缺点：

1. 类的个数增多：每个具体产品类都需要对应一个具体工厂类，导致类的个数增多。
2. 增加了系统的抽象性和理解难度：抽象工厂模式将对象的创建分散到多个具体工厂类中，增加了系统的抽象性和理解难度。

抽象工厂模式适用于产品种类较多且需要一系列相关产品对象的场景，对于产品种类较少或不需要一系列相关产品对象的场景，建议使用工厂方法模式或简单工厂模式。

产品族：指位于不同产品等级结构（电冰箱，电视机）中，功能相关联的产品组成的家族。一般是位于不同的等级结构中的相同位置上。每个产品族中含有产品的数目，与产品等级结构的数目是相等的，形成一个二维的坐标系，水平坐标是产品等级结构，纵坐标是产品族。叫做相图 

区别 

 建造者模式

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

建造者模式（Builder Pattern）是一种创建型设计模式，它将一个复杂对象的构建过程与其表示分离，使得同样的构建过程可以创建不同的表示。

建造者模式由四个角色组成：

1. 产品（Product）角色：表示被构建的复杂对象。
2. 抽象建造者（Abstract Builder）角色：定义了构建产品的抽象方法，具体建造者需要实现这些方法来构建具体产品。
3. 具体建造者（Concrete Builder）角色：实现了抽象建造者接口，负责构建具体产品的各个部分。
4. 指挥者（Director）角色：负责调用具体建造者来构建产品对象，它不知道具体产品的细节，只知道建造者的接口。一方面隔离了客户与生产过程；另一方面负责控制产品的生成过程。

建造者模式的工作流程如下：

1. 客户端通过创建具体建造者对象，并将其传递给指挥者。
2. 指挥者调用具体建造者的方法来构建产品对象。
3. 客户端从指挥者处获取构建好的产品对象。

建造者模式的优点包括：

1. 将复杂对象的构建过程与其表示分离，使得同样的构建过程可以创建不同的表示。
2. 可以更加精细地控制产品的构建过程。
3. 可以更加灵活地扩展和修改构建过程。

然而，建造者模式也存在一些缺点：

1. 增加了代码的复杂性：建造者模式需要定义多个角色和接口，增加了代码的复杂性和理解难度。
2. 建造者模式适用于构建复杂对象的场景，对于构建简单对象的场景，建议使用其他创建型设计模式，如工厂方法模式或简单工厂模式。

原型模式

用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。使其有同样的初始化数据 

无须知道创建细节。通过将一个原型对象传给那个要进行创建的对象，使其通过请求原型对象拷贝原型自己来实现创建过程。

 原型模式（Prototype Pattern）是一种创建型设计模式，它通过复制现有对象来创建新的对象，而不是通过实例化类来创建。

原型模式由两个角色组成：

1. 原型（Prototype）角色：定义了一个克隆自身的方法，用于复制对象。
2. 具体原型（Concrete Prototype）角色：实现了原型接口，实现克隆自身的方法。

原型模式的工作流程如下：

1. 客户端通过调用具体原型对象的克隆方法来创建新的对象。
2. 具体原型对象调用自身的克隆方法，复制自身的属性值到新的对象中。
3. 具体原型对象将复制好的新对象返回给客户端。

原型模式的优点包括：

1. 提高性能：通过复制现有对象来创建新对象，避免了重复的对象创建过程，提高了性能。
2. 简化对象创建过程：通过复制现有对象，省去了实例化类和初始化属性的过程，简化了对象的创建过程。

然而，原型模式也存在一些缺点：

1. 克隆方法的实现比较复杂：如果对象的属性比较复杂，克隆方法的实现可能比较复杂。
2. 克隆方法的性能影响：克隆方法的性能可能会受到对象属性的影响，如果对象属性较多或属性值较大，克隆方法的性能可能较低。

原型模式适用于需要创建大量相似对象的场景，通过复制现有对象来创建新对象可以提高性能和简化代码。

单例模式

保证一个类仅有一个实例，并提供一个访问它的全局访问点。对象创建型模式。单例模式又名单件模式或单态模式。

 懒汉式：就是在类初始化的时候，创建对象。这种方式没有考虑线程安全问题，在多线程下，可能同时存在多个对象

饿汉式：懒汉式是在第一次使用时才创建对象，在多线程环境中要考虑线程安全问题

 单例模式（Singleton Pattern）是一种创建型设计模式，它确保一个类只有一个实例，并提供全局访问点。

单例模式由一个角色组成：

1. 单例（Singleton）角色：定义了一个静态方法来获取该类的唯一实例。

单例模式的工作流程如下：

1. 客户端通过调用单例类的静态方法来获取该类的唯一实例。
2. 如果该类的实例不存在，则创建一个新的实例并返回给客户端。
3. 如果该类的实例已经存在，则直接返回该实例给客户端。

单例模式的优点包括：

1. 提供全局访问点：通过单例模式，可以在任何地方访问该类的唯一实例。
2. 节省资源：由于单例模式只创建一个实例，可以节省系统资源。

然而，单例模式也存在一些缺点：

1. 不适用于多线程环境：在多线程环境下，如果多个线程同时调用单例类的静态方法，可能会创建多个实例，导致单例模式失效。
2. 不适用于动态扩展：由于单例模式只创建一个实例，无法动态扩展该类的实例。

单例模式适用于需要保证一个类只有一个实例，并且该实例需要在全局范围内访问的场景。例如，数据库连接池、日志记录器等。

 结构型模式

结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式，前者采用继承机制来组织接口和类，后者釆用组合或聚合来组合对象。由于组合关系或聚合关系比继承关系耦合度低，满足“合成复用原则”，所以对象结构型模式比类结构型模式具有更大的灵活性。

适配器模式

适配器模式是一种结构型设计模式，用于将一个类的接口转换成客户端所期望的另一个接口。适配器模式允许不兼容的类能够一起工作，通过创建一个适配器类，该适配器类将目标类的接口转换成客户端所期望的接口。

适配器模式通过定义一个中间层（适配器），将原始类（被适配者）的接口转换成客户端代码所期望的接口。这样，客户端代码就可以使用原始类的功能，而不需要修改原始类的代码。

适配器模式常见的应用场景是：将不同的数据格式或外部接口转换为统一的接口，以便客户端代码可以统一使用。

例如，一个商店系统需要集成多个支付平台，这些支付平台可能使用不同的接口。为了能够实现统一的支付接口，可以使用适配器模式来将不同的支付平台适配成统一的接口，使得客户端代码可以统一调用支付接口，而不需要关心具体的支付平台实现。

 类结构型模式

Target：目标抽象类
Adapter：适配器类
Adaptee：适配者类

实现：类适配器模式可采用多重继承方式实现，如 C++ 可定义一个适配器类来同时继承当前系统的业务接口和现有组件库中已经存在的组件接口；Java 不支持多继承，但可以定义一个适配器类来实现当前系统的业务接口，同时又继承现有组件库中已经存在的组件Adapter 类继承Adaptee （被适配类），同时实现Target 接口（因为 Java 不支持多继承，所以只能通过接口的方法来实现多继承），在 Client 类中我们可以根据需要选择并创建任一种符合需求的子类，来实现具体功能
优点：由于适配器类是适配者类的子类，因此可以在适配器类中置换一些适配者的方法，使得适配器的灵活性更强
缺点：对Java、C#等不支持多重继承的语言，一次最多只能适配一个适配者类，且目标抽象类只能为抽象类，不能为具体类，其使用有一定的局限性，不能将一个适配者类和它的子类都适配到目标接口

 对象结构型模式

 对象适配器模式是适配器模式的一种变体，它将适配器类组合到客户端类中，而不是将其继承。这种模式利用了组合和委托来实现适配器功能。这个对象适配器持有一个适配者对象，并将接口转换为目标对象所需的接口。

简而言之，对象适配器模式是将适配器类组合到客户端类中，而不是将其继承，从而实现接口转换。不使用多继承或继承的方式，而是使用直接关联，或者称为委托的方式

• 优点：一个对象适配器可以把多个不同的适配者适配到同一个目标，也就是说，同一个适配器可以把适配者类和它的子类都适配到目标接口
• 缺点：与类适配器模式相比，要想置换适配者类的方法就不容易。如一定要置换掉适配者类的一个或多个方法，就只好先做一个适配者类的子类，将适配者类的方法置换掉，然后再把适配者类的子类当做真正的适配者进行适配，实现过程复杂

扩展：适配器模式（Adapter）可扩展为双向适配器模式，双向适配器类既可以把适配者接口转换成目标接口，也可以把目标接口转换成适配者接口 

区别

• 类适配器的重点在于类，是通过构造一个继承Adaptee类来实现适配器的功能；
• 对象适配器的重点在于对象，是通过在直接包含Adaptee类来实现的，当需要调用特殊功能的时候直接使用Adapter中包含的那个Adaptee对象来调用特殊功能的方法即可

适用

• 以前开发的系统存在满足新系统功能需求的类，但其接口同新系统的接口不一致。
• 使用第三方提供的组件，但组件接口定义和自己要求的接口定义不同

组合模式(Composite)

有时又叫作部分-整体模式，它是一种将对象组合成树状的层次结构的模式，用来表示“部分-整体”的关系，使用户对单个对象和组合对象具有一致的访问性

component构件：抽象组合对象的公共行为接口
leaf构件：树叶对象，没有下级子对象
composite构件：树枝对象，树枝对象可包含一个或多个其他树枝或树叶对象

行为模式

策略模式：

定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。
角色

• 环境角色：持有一个Strategy类的引用
• 抽象策略：一个抽象角色，通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口
• 具体策略：包装了相关的算法或行为

适用

• 多个类只区别在表现行为不同，可使用Strategy模式，在运行时动态让对象选择具体要执行的一种行为
• 要在不同情况下使用不同的策略(算法)，动态的选择一种算法，或者策略还可能在未来用其它方式来实现
• 对客户隐藏具体策略(算法)的实现细节或算法使用的数据，彼此完全独立

优点

• 提供了一种替代继承的方法，保持继承的优点，比继承更灵活
• 避免程序中使用多重条件转移语句，使系统更灵活，并易于扩展。
• 提供了管理相关的算法族的方法，使这些算法可以相互替换，自由切换。
• 遵守大部分原则
• 简化了单元测试，因每个算法都有自己的类，可以通过自己的接口单独测试

缺点

• 所有的策略模式都需要对外暴露客户端必须知道所有的策略类，并自行决定使用哪一个策略类。
• 造成很多的策略类
• 只适合扁平的算法结构，不适合于处理同时嵌套多于一个算法的情形。

模板方法模式：

定义一个操作中的算法骨架，将算法的一些步骤延迟到子类中，使得子类在可以不改变该算法结构的情况下重定义该算法的某些特定步骤。是类行为模式

结构与实现

• 抽象类：负责给出一个算法的轮廓和骨架。它由一个模板方法和若干个基本方法构成。这些方法的定义如下
  • 模板方法：定义了算法的骨架，按某种顺序调用其包含的基本方法
  • 基本方法：是整个算法中的一个步骤，包含以下几种类型
    • 抽象方法：在抽象类中申明，由具体子类实现。
    • 具体方法：在抽象类中已经实现，在具体子类中可以继承或重写它。
    • 钩子方法：在抽象类中已经实现，包括用于判断的逻辑方法和需要子类重写的空方法两种钩子方法是对于抽象方法或者接口中定义的方法的一个空实现，比如说有一个接口，这个接口中定义了很多个方法，而你想实现其中某一个方法，这个时候就可以写一个抽象类实现这个接口，在这个抽象类里将你要用的那个方法设置为abstract,其它方法进行空实现，然后再继承这个抽象类，就不需要实现其它不用的方法，这就是钩子方法的作用。
• 具体子类：实现抽象类中所定义的抽象方法和钩子方法，它们是一个顶级逻辑的一个组成步骤

优点

• 它封装了不变部分，扩展可变部分。它把认为是不变部分的算法封装到父类中实现，而把可变部分算法由子类继承实现，便于子类继续扩展。
• 它在父类中提取了公共的部分代码，便于代码复用。
• 部分方法是由子类实现的，因此子类可以通过扩展方式增加相应的功能，符合开闭原则

缺点

• 对每个不同的实现都需要定义一个子类，这会导致类的个数增加，系统更加庞大，设计也更加抽象。
• 父类中的抽象方法由子类实现，子类执行的结果会影响父类的结果，这导致一种反向的控制结构，它提高了代码阅读的难度

职责链模式：

把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。

角色

• 抽象处理者(Handler)：定义出一个处理请求的接口。如需要，接口可定义 出一个方法以设定和返回对下家的引用。通常由1个Java抽象类或接口实现。Handler类的聚合关系给出了具体子类对下家的引用，抽象方法handleRequest()规范了子类处理请求的操作。
• 具体处理者(ConcreteHandler)：它接到请求后，可选择将请求处理掉，或将请求传给下家。由于具体处理者持有对下家的引用，如需要，它可访问下家

优点

• 解耦 : 请求的 发送者 和 接收者 解耦 ; 接收者 是 请求的处理者 ;
• 动态组合 : 责任链 可以 动态组合 , 使用配置 设置责任链的 顺序及 是否出现 ; 可以随时对责任链排序 , 随时增加拆除责任链中的某个请求对象 ;

缺点

• 性能 : 如果 责任链 太长 , 或责任链中请求的 处理时间过长 , 可能会 影响性能 ;
• 个数 : 责任链 可能过多

适用

• 有多个对象可处理一个请求，哪个对象处理该请求在运行时刻自动确定。
• 在不明确指定接收者的情况下，向多个对象中的一个提交一个请求

命令模式（动作模式）：

将一个请求封装为一个对象，从而可用不同的请求对客户进行参数化；对请求 排队或 记录请求日志，以及支持可撤销的操作.是对象行为型模式，别名为动作(Action)模式或事务(Transaction)模式

角色

• Command: 抽象命令类
• ConcreteCommand: 具体命令类
• Invoker: 调用者
• Receiver: 接收者
• Client:客户类

优点

• 降低系统耦合度
• 新命令可很容易加入到系统中
• 较易设计一个命令队列和宏命令（组合命令）
• 可方便地实现对请求的Undo和Redo

缺点：导致某些系统有过多的具体命令类。因为针对每个命令都需要设计一个具体命令类，大量具体命令类，影响模式的使用

适用性

• 系统要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。
• 系统要在不同的时间指定请求、将请求排队和执行请求。
• 系统要支持命令的撤销(Undo)操作和恢复(Redo)操作。
• 系统要将一组操作组合在一起，即支持宏命令

todo

观察者模式：

多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。

中介者模式：

定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。

迭代器模式：

提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。

访问者模式：

在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。

备忘录模式：

在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。

解释器模式：

提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。是类行为模式

系统安全设计

软件安全概述

1 安全性：使损害的风险控制在可接受范围内---ISO 8402

2 软件缺陷普遍存在：

3 安全产生原因：

1）软件规模变大，功能越复杂

2）模块复用致漏洞延续

3）扩展模块带来安全问题

4）互联网的挑战，只重功能，用户也忽略安全要求

5）缺乏安全工具，安全配套管理，测试等工具

开发的安全模型 

• 可信计算安全开发生命周期（微软，SDL）
• CLASP （OWASP）综合的轻量应用安全过程
• BSI系列模型（Gary McGraw等）
• SAMM（OWASP）
• 软件保证成熟度模型 CMMI、BSIMM

SDL 

CLASP

SAMM

 BSI

安全漏洞 

概念：在硬件，软件，协议的实现过程中存在的缺陷，可使攻击者能在未授权情况下访问或破坏系统。

分类：从数据角度分 数据窃取，数据修改，输入数据执行的漏洞

 SQL注入

 身份验证漏洞

 敏感信息泄漏

功能级访问控制缺失

 安全配置错误

跨站脚本

 跨站请求伪造

使用含已知漏洞的组件

 未验证的重定向和跳转