系统分析与设计

前言

按照惯例，在这里写下我对软件体系结构的一点理解和认识
系统分析与设计这一门课主要的用处是针对与需求设计之后得到用户的需求之后，来解决如何划分子系统，回答在系统设计中如何更加合理的设计类图，使系统达到高内聚低耦合的效果

系统概述

用户故事

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

devops

DevOps 强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。
开发运维一体化
devops=人+流程+平台

系统特性

整体性：系统功能在各个状态下不能由完全相同的要素构成
目的性：系统是基于目的实现功能
相关性：系统内部之间存在关系
环境适应性：系统能够适应环境的变化
层次性：系统由多个子系统构成，子系统又可以分成多个子系统
动态性：系统活动是动态运行的

系统规划

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

系统规划步骤（记住）

1. 对当前系统进行初不调查
2. 分析确定系统目标
3. 分析子系统组成和功能
4. 拟定系统实施方案
5. 进行可行性研究

1接受委托
2理解企业的要求
3挑选适合的方法
4定义业务的范围
5复审
6确定研究范围
7研究时间进度表
8制定职能活动和实体样本
9建立研究小组（数据人员，用
户的工作人员，领导）
10选择每个职能的负责人
11选择，培训用户分析员
12定义业务活动过程
13复审业务活动过程
14业务过程分解（分解为相应的功能和活动）
15确定业务活动所需的实体图
16将活动映射在实体上
17产生功能聚集的簇，确定日常系统
18确定决策支持系统，信息系统的需求
19绘制数据处理系统
20 确定采访或合作的高级管理人员
21 绘制数据库与业务活动过程的对应关系图
22 给出规划的分布过程
23 确定分布式数据或分布式数据图
24 编写报告

系统分析模型

诺兰模型（了解）

CMM能力成熟度模型（重点）

目的和作用：

意义：

系统规划方法

战略集合转换法

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

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

关键成功因素法

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

步骤：
了解企业或MIS的战略目标
识别所有的成功因素
确定关键成功因素
明确各关键成功因素的性能指标和评估标准

企业资源规划法

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

准备工作

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

调查研究

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

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

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

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

意义
整个企业的管理活动由许多业务过程组成，识别它会对企业如何完成其目标产生深刻了解
作为信息识别和构成信息系统的基础
按照企业过程所创建的信息系统，在企业组织机构变化时可不必改变，即信息系统相对独立于组织

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

计划和控制

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

产品与服务

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

支持资源

最后得到结果

业务过程重组

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

定义数据类

实体法、功能法

实体法

功能法

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

三法结合

价值链分析法

系统分析

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

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

结构化的系统分析

业务流程图

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

系统流程图

又叫事务流程图，反应主体框架。是在计算机事务处理应用进行系统分析时常用的一种描述方法，描述事务处理中从数据输入开始到获得输出为止各个处理工序过程
描绘系统物理模型的工具。基本思想是用图形符号以黑盒子的形式描绘系统理念的每个部件包括程序，文件，数据库，表格，人工过程等，表达信息在各个部件之间流动的情况，而不是表示对信息进行加工处理的控制过程

变换

划分

分类
更新

面向对象系统分析

分层类图

分析管理

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

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

系统分析说明书

系统设计

系统设计内容

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

系统设计原则

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

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

系统设计优化

指在给定条件（或约束）下，根据系统的优化目标，采取一定的手段和方法，使系统的目标值达到最大化（或最小化）

优化意义：以最小的投入，获取系统的最佳效益或最佳功能。

考虑因素：

• 系统设计的目的与要求
• 系统各部分之间的相互联系与相互作用
• 系统设计方案的优化

系统设计要从整体出发，以系统整体功能的最优为目的。
运用系统的思想综合考虑各部分之间的关联、冲突问题，注重各部分的横向、纵向联系。

面向对象设计

静态建模（类图）

动态建模

消息

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

消息分类：
同步系统：都是同步消息
并发系统：：同步消息、异步消息

顺序图

对象、生命线、激活器、消息
条件分支

约束

循环


对象的消亡

合作图

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

自调用

异步回调

循环

设计原则

单一职责原则

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

开闭原则（最核心）

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

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

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

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

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

依赖倒置原则

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

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

接口隔离原则

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

优先组合而非继承

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

迪米特原则

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

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

设计模式

简单工厂模式

工厂模式

抽象工厂

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

建造者模式

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

优点：
客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使相同的创建过程可创建不同的产品对象。
每个具体建造者都相对独立，与其他的具体建造者无关，因此可很方便地替换具体建造者或增加新的具体建造者，用户用不同的具体建造者即可得到不同的产品对象。
更加精细地控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。
增加新的具体建造者无须修改原有类库的代码，指挥者类针对抽象建造者类编程，系统扩展方便，符合“开闭原则”。

缺点：
所创建的产品具有较多的共同点，其组成部分相似，如产品间差异很大，则不适合用建造者，使用范围有限制。
如产品的内部变化复杂，可能导致要定义很多具体建造者类来实现变化，系统变庞大。

单例模式

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

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

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

原型模式

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

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

适配器模式

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

组合模式

将对象组织到树结构中，描述整体与部分的关系，用树结构表示。使客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待


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

安全方式：
安全方式：只允许树枝构件有对象的管理方法。

透明方式：
透明方式：只允许树枝和树叶都有对象的管理方法，但树叶对象中的管理方法无实际意义

策略模式（封装算法）

定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化

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

实例：商场促销，选择不同的优惠方案

状态模式（封装状态）

一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。抽行为封装

抽象状态（State）角色：定义接口，用以封装环境（Context）对象的一个特定的状态所对应的行为
具体状态（Concrete State）：每个具体状态类都实现了环境（Context）的一个状态所对应的行为
环境（Context）角色：定义客户端感兴趣的接口，并保留一个具体状态类的实例。这个具体类的实例给出此环境对象的现有状态

适用条件：
一个对象的行为依赖于它所处的状态（如某些属性值），对象的行为必随其状态的改变而改变
对象在某个方法里依赖于一重或多重的条件转移语句，其中有大量的代码，灵活性，维护性差，增删状态不方便

命令模式——动作模式——事务模式

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

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

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

职责链

很多对象由每一个对象对其下家的引用而联接起来形成一条链。请求在这个链上传递，直到链上的某个对象决定处理此请求。发出这个请求的客户端不知道链上的哪个对象最终处理这个请求。责任链可能是一条直线、一个环链甚至一个树结构的一部分。

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

具体处理者(ConcreteHandler)：它接到请求后，可选择将请求处理掉，或将请求传给下家。由于具体处理者持有对下家的引用，如需要，它可访问下家

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

外观模式

将子系统中的各类（或结构与方法）整合成一个简明一致的界面，隐藏子系统的复杂性，使子系统更容易使用

抽象外观，基于开闭原则设计

观察者模式

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