系统分析与设计

第一章：系统概述

• 系统是一组为实现某些结果相互联系、相互作用的部件的集合体
• 系统具有整体性、目的性、相关性、环境适应性和层次性
• 系统分析员：研究组织中存在的问题和需求，决定人员、数据、过程和信息技术如何最大化地为企业做出贡献。主要分为：
  • 程序员/分析员：既有计算机程序员的职责，也有系统分析员的责任
  • 业务分析员：专注于系统分析与设计中的非技术方面
• 在需要基于计算机的业务解决方案的人和那些懂得信息技术的人之间存在交流障碍，系统分析员要沟通这个障碍。
• 系统分析员所需要的技能：
  • 有效的信息技术知识
  • 计算机编程经验和专长
  • 一般的商务知识
  • 解决问题的技能
  • 与人沟通的能力
  • 处理人际关系的能力
  • 韧性和适应性
  • 人格与道德规范
  • 系统分析和设计能力

第二章：系统规划

1.信息系统生命周期各阶段的任务

• 系统规划
• 系统分析
• 系统设计
• 系统实施
• 系统维护

2.系统规划的定义

• 信息系统的系统规划又称为信息系统的战略计划，是信息系统生命周期的第一阶段，是对组织总的信息系统目标、战略、信息系统资源和开发工作的一种综合性计划，属于组织对信息系统最高层次管理的范畴，是一个组织的战略规划的重要组成部分，是关于信息系统长远发展的规划，是信息系统的概念形成期。
• 系统规划要解决的是面向长远的、未来的、全局性和关键性的问题，而不是要解决项目开发中的具体业务问题。

3.系统规划的作用

• 确保信息系统的正确目标和任务，降低系统建设风险
• 合理分配和利用信息资源（信息、信息技术和信息生产者），以节省信息系统投资
• 指导信息系统开发，用规划作为将来考核系统开发工作的标准

4.系统规划的五阶段模型

• 信息系统战略规划
• 组织业务流程规划
• 系统总体结构规划
  • 组织的信息需求分析
  • 系统数据规划
  • 功能规划与子系统划分
  • 信息资源配置规划
• 项目实施与资源分配规划
• 系统的可行性研究

5.可行性研究

• 技术可行性
• 经济可行性
• 社会可行性
• 可行性分析报告 — 系统规划的最后文档（包括总体方案和可行性论证两个方面）

第三章：系统的开发方法

1.经典的生命周期法

• 瀑布模型
  • 运用系统有序的步骤去开发软件，从系统观念进行分析、设计、编码、测试和维护。把软件生存的周期一次划分为若干个阶段，每个阶段有相对独立的任务和标志性的成果，然后逐步完成各个阶段的任务，上一阶段的任务没有完成，不能进行下一阶段的任务。
  • 要求用户一开始就清楚地提出所有请求，很难适应项目开始阶段存在的不确定性。越是生命周期的后面阶段，由于需求变化造成的损失越大。
  • 实际项目很少完全遵循该模式提出的工作顺序，即明确的一个阶段一个阶段去完成，往往重复迭代。
  • 开发过程复杂，开发周期长。
  • 可运行的程序一直要到项目的最后阶段才可能得到。因疏忽而导致的错误要到检测运行时才能发现，造成经济、时间的损失。
• 增量模型
  • 要开发一个大的软件系统，先开发其中的一个核心模块（或子系统），然后再开发其他模块（或子系统）。
  • 在每增加一个模块之前，要先对该模块进行模块测试，然后再将此模块加入到系统中，然后要进行系统集成测试。
  • 任务或功能模块驱动，可以分阶段提交产品。
  • 将一个大系统分解为多个小系统，将一个大风险分解为多个小风险，从而降低了开发难度。
  • 人员分配灵活
  • 如果软件系统的组装和拆卸性不强，或开发人员全局把握水平不高，或客户不同意分阶段提交产品，或者开发人员过剩，就不宜采用这种模型。
• 迭代模型
  • 多次执行各个开发工作流程，最终交付一系列逐步完善的实施成果
  • 每次按顺序完成这一些列工作流程就叫做一次迭代，每次迭代，均以次要里程碑结束。
  • 迭代是产生可执行的产品发布的完整开发循环，所发布的产品是开发过程最终产品的子集。
  • 在开发早期或中期，用户需求可以变化；在迭代之初，不要求有一个相近的产品原型。适用范围广，几乎适用于所有项目的开发。
  • 采取循环工作方式，每次循环均使工作产品更靠近目标产品一次，要求项目组成员具有很高的水平并掌握先进的开发工具。
• 螺旋模型
  • 将瀑布模型和快速原型模型结合起来，强调风险分析。
  • 在瀑布模型的每一个开发阶段前，引入一个非常严格的风险识别、风险分析和风险控制。
  • 支持用户需求的动态变化
  • 有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标
  • 减少了过多测试或测试不足所带来的风险
  • 很难让用户确信这种演化方式的结果是可以控制的
  • 需要具有相当丰富的风险评估经验的专门知识
  • 过多的迭代次数会增加开发成本、延迟提交时间
• 喷泉模型（喷泉无间隙性模型）
  • 各个开发阶段没有特定的次序要求，而且可以交互进行，在每个开发阶段中，还可以随时补充其他任何开发阶段中的遗漏。
  • 各个阶段没有明显的界限，可同步进行开发。提高软件项目开发效率，节省开发时间。
  • 需要大量的开发人员，要求严格管理文档
• XP模型（极限编程模型）
  • 轻量级开发模型，由一组简单规则组成，既保持开发人员的自由创造性，又保持对需求变动的适应性。
  • 开发小组不仅包括开发人员，还包括管理人员和客户。
  • 强调小组内成员之间要经常进行“交流”，结对编程，在尽量保证质量的前提下力求过程和代码的“简单”化。采用“用户场景故事”的方法，代替传统模型中的需求分析。
  • 适用于中小型开发小组
  • 开发周期短、软件质量有保证、与用户关系和蔼

2.原型法

• 按照用户最基本的需求，迅速而廉价的开发出一个实验型的小型系统。不断反复修改，直至最后完成一个满足用户需求的系统。

3.结构化开发方法

• 用系统工程的思想和工程化的方法，按用户至上的原则，结构化、模块化、自顶向下的对系统进行分析和设计。

4.面向对象的开发方法

• 凡事在系统中的具体和抽象实体，都可以被称为对象。每个对象由属性和方法两个方面组成。
• 对象的特点：封装性、继承性、抽象性、动态链接性
• 降低开发成本、缩短开发周期和提高开发质量

第六章：流程建模

1.系统分析和设计阶段创建的模型

• 逻辑模型：详细定义了系统需求而独立于某一具体技术
  业务流，数据流，实体关系，数据流定义，数据元素定义，类图，用例图，用例描述，顺序图，通信图，状态图，活动图
• 物理模型：显示了如何使用具体技术来实现系统的某些方面

2.业务流程图

• 用一些规定的符号及连线表示某个具体业务处理过程
• 按照业务的实际处理步骤和过程绘制，用图形方式反映实际业务处理过程。

• 横向列出岗位（组织单元）并标记为A，B，C，D等
• 纵向按业务发生的顺序标记为1，2，3等

3.数据流程调查与分析

• 数据正确性分析
  • 数据必定有一个产生的源，而且必有一个或多个用途
  • 在U/C矩阵中：每一列只能有一个C，每一列至少有一个U，不能出现空行或空列
• 数据流程图：数据流程分析是通过分层数据流程图来实现的。
• 数据流程图具有抽象性和概括性。抽象性表现在它完全舍去了具体的物质，只剩下数据的流动、加工处理和存储；概括性表现在它可以把信息处理过程中的各种不同业务处理过程联系起来，形成一个整体。
  
• 外部实体：所研究系统外独立于系统而存在的，但又和系统有联系的实体，表示数据的外部来源和去向，是系统的数据来源或数据终点。
• 处理过程：对数据进行变换操作，把流向它的数据进行一定的变换处理，产生新的数据。
• 顶层数据流图：说明了系统的总的处理功能、输入和输出。

4.判定树

• 如果一个动作的执行不只是依赖一个条件，而是与多个条件有关，那么这项策略的表达就比较复杂，就可以使用判定树来表示。

5.判定表

• 如果条件较多、每种条件的取值情况也较多的情况下，可以使用判定表。
• 可以把各种组合情况一个不漏地表示出来，还能够帮助发现遗漏和矛盾的地方。

第七章：用例建模

• 用例是对于一组动作序列的描述，系统执行这些动作会对特定的参与者产生可观测的、有价值的结果。
• 参与者：系统之外与系统进行交互的任何事物。只有在执行系统功能与信息系统进行实时交互的人员才能被当作参与者。
• 参与者的泛化：子角色可以继承父角色的所有行为
• 用例关系
  • 包含关系：经过封装后可以在各种不同的基本用例中复用
  • 扩展关系：某些可选或只在特定条件下才执行的系统行为的用例，是对基本用例的扩展。扩展用例的缺失不影响对基本用例的理解。
  • 泛化关系：两个或更多用例在行为、结构和目的方面存在共性，可以使用泛化关系。父用例描述这些共有部分，子用例继承父用例并特殊化。

第八章：领域对象建模

1.对象的属性

• 属性是类的特征或特性
• 在类中属性名必须是唯一的
• 每一个类的实例都有为这个类定义的所有属性的值

2.类

• 对象类，简称类，是指有相同属性和服务的一组对象的抽象概念。
• 一个具体的对象就是该对象所在类的一个实例。
• 类是静态的，对象是动态的

3.抽象类和接口

• 抽象类用来表征在对问题领域进行分析、设计中得出的抽象概念。
• 接口是抽象类的变体。接口是一些方法的集合，但所有方法都是抽象的，只有生命而没有程序体。

4.封装

• 信息隐藏，保证软件部件具有较好的模块性
• 封装使对象对外仅提供接口，即可见的一些属性和操作，而具体实现不可见。

5.消息

• 向对象发出的服务请求（对象间的交互信息）

6.继承

• 特殊类的对象拥有其一般类的全部属性与服务
• 抽取很多不同类型对象的共同点形成一般类，这个过程称为泛化

7.多态

• 相同的操作（或函数，或过程）可作用于多种类型的对象并获得不同的结果。
• 覆盖（运行时多态）：子类对父类的方法进行重写，展示的是父类及其多个不同子类的多态性。
• 重载（编译时多态）：在一个类中定义多个名称相同、参数类型不同的方法

8.关系

• 类之间的联系方式
  • 继承/泛化：对象分类的层次关系
  • 实现：描述和实现。一个接口可以提供某些操作的描述，另一些类需要具体来完成这些操作，即对接口进行实现。
• 对象实例之间的联系
  • 关联：对象与对象的静态联系，是一种长期关系
  • 依赖：对象与对象的动态联系（运行时），是一种短期关系

9.对象建模

• 类图：对象及其关系，用于描述系统的静态结构
• 状态图：对象的状态及转换，用于描述基于事件响应的对象动态行为和状态之间的关系。
• 实体关系图（E-R图）：表达对象之间有一定的关联
• 整体/部分关联（聚集）：使用连接线和菱形表达，菱形一端的对象是整体对象。
• 组合聚集：有很强的归属关系，在特定时刻部分只能是一个组合对象的成员。关联路径的末端有一个实心菱形，用来表示组合关系。
• 共享聚集：部分可能同时属于多个整体对象，关联路径的末端有一个空心菱形，用来表示聚集关系。

10.类图的画法

11.对象状态建模

• 状态图（动态模型）：对象状态及变化
• 交互图（动态模型）：不同对象之间的交互协作，如顺序图，通信图

12.状态图

• 对单一的类绘制一个状态机图以表示该对象的生命期行为和状态转换。
• 对象可能存在的状态
  • 初态：状态图的起始点，初态只有一个，用实心圆表示
  • 终态：状态图的终点，一个对象完成必要操作后的最终状态。实心圆外加一个圆圈来表示终态。
  • 复合状态：一个状态中还嵌套其他多个状态（子状态）。
• 状态图的元素
  • 状态
  • 转换：指出由一种状态到另一种状态的运动
  • 内部活动：对象在某个状态内部执行的操作

第九章：系统设计概述

1.系统设计的任务要求

• 完成技术实现方案的制定，即信息系统的物理模型
• 可变性是衡量信息系统设计的重要指标

2.系统设计的内容

• 总体设计
  • 设计软件的体系结构
  • 设计软件结构，即具体组成元素及其关系
  • 设计系统对外接口和服务
• 详细设计
  • 各项具体细节，设计软硬件的各个方面
  • 输入输出设计
  • 人机交互设计
  • 模块处理过程详细设计/类及用例的详细设计
  • 数据库设计
  • 事务代码体系设计
  • 计算机系统和网络设计

3.基于模块封装的软件结构

• 采用强调自顶向下、逐层分解的功能模块设计，也称为结构化设计
  • 将系统划分成功能模块
  • 决定每个模块的功能
  • 决定模块的调用关系
  • 决定模块的界面，即调用时传入的信息（函数参数）以及返回的信息（返回值）
• 主要模型：模块结构图（SC），也称为功能结构图

4.基于对象封装的软件结构

• 强调面向对象的封装
  • 识别系统中的对象，设计类
  • 决定每个类的属性和操作
  • 决定对象之间的协作/通信关系
• 主要模型：类图

5.面向服务封装的软件结构

• SOA有三个主要的抽象级别元素
  • 操作：代表单个逻辑工作单元的事务。可以与面向对象中类的方法相提并论。
  • 服务：代表操作的逻辑分组。
  • 业务流程：为实现特定业务目标而执行的一组长期运行的动作或活动。业务流程可以通过编排一组服务来定义和实现。
• 主要模型：构件图（底层基于类来实现）

6.系统设计说明书

• 设计完成，提交系统设计说明书

第十章：数据库设计

1.数据库、数据库管理系统和数据库系统

• 数据库（DB）：是以一定的组织方式存储在一起的互相关联的数据的集合。
• 数据库管理系统（DBMS）：对数据库进行管理的特定软件。
• 数据库系统（DBS）：计算机系统中引入数据库之后的系统，一般由数据库、数据库管理系统（及其开发工具）、应用系统、数据库管理员和用户构成。
• 数据库管理系统的功能
  • 创建和修改数据库
  • 存储和检索数据
  • 操纵数据和生成报表
  • 保证所有存储数据的安全性
  • 数据被多个用户共享时，要避免可能产生的异常结果（并发控制）

2.数据的组织层次

• 字段：属性的特定值
• 记录：由字段组成，字段代表了实体对象的各个属性。一条记录由一个或者多个字段组成。
• 文件：多个相关记录的集合形成
• 数据库：由多个在系统执行过程中相互关联的文件组成

3.数据实体、属性和键

• 实体：必须保存信息的人、地点、事物或事件。实体是个体的集合，实体中的个体称为实例。
• 属性：对特定实体特征或性质的描述
• 键：记录中用于标识该记录的一个或多个字段

4.数据库设计

1. 实体联系模型（E—R模型）
   • 现实世界是由一组称作实体的基本对象以及这些对象间的联系构成的。
   • 实体：描述客观事物的概念。实体可以通过属性的集合来描述。
   • 属性：实体具有的某种特性。
   • 联系：事物间的相互关联。事物之间的联系可分为两类：一是实体内部的联系，而是实体之间的联系。
2. 实体之间的联系
   • 一对一联系
   • 一对多联系
   • 多对多联系
3. E—R图由以下元素构成
   • 矩形：代表实体集（具有相同属性或特征的实体集合）
   • 椭圆：代表实体属性
   • 菱形：代表实体间的联系集（同一类型的所有联系的集合）
   • 线段：将属性与实体集相连或将实体集与联系集相连

5.数据模型

• 描述计算机世界中数据及数据之间的关系及存储、处理特征的模型。
• 关系模型、网状模型和层次模型

1. 关系模型
   • 用表的集合来表示数据和数据间的联系。每个表有多个列，每列有唯一的列名。
   • 关系：一个关系对应一张二维表
   • 元祖：表中一行称为一个元祖
   • 属性：表中一列称为一个属性，它的值唯一地标识一个元祖
   • 主码：表中的某个属性组，它的值唯一地标识一个元祖
   • 域：属性的取值范围
   • 分量：元祖中的一个属性值
   • 关系模式：对关系的描述，用关系名来表示
2. 层次模型
   • 用树型结构表示实体集之间的联系。主要特征是有一棵有向树，树的节点是记录类型。一个父节点可以有多个子节点，而一个子节点有且只有一个父节点。
   • 描述的是一种一对多的逻辑关系。
3. 网状模型
   • 是层次数据模型的变形
   • 能更好的描述多对多的数据逻辑关系。父节点可以有多个子节点，子节点也可以有多个父节点。

• 层次模型的主要优点在于处理效率，数据关系比较简单。但在数据组织上缺乏灵活性，修改困难，不易安装。
• 网状模型在数据组织上较层次模型有更大的灵活性，但数据关系复杂，难以开发和使用。
• 关系数据模型数据组织直观、查询方便、能够在数据之间建立各种关系满足一些特殊的查询，并且设计、维护简单。应用广泛。

6.E—R图转换成关系模式

• 一个实体型转换为一个关系模型，实体的属性就是关系的属性，实体的键就是关系的键。
• 一个联系转换为一个关系模式，与该联系相连的每个实体型的键以及联系的属性都转换为关系的属性。
  • 若联系为1:1，则相连的每个实体型的键均是该关系模式的候选键
  • 若联系为1:n，则联系对应的关系模式的键取n端实体型的键
  • 若联系为m:n，则联系对应的关系模式的键为参加联系的诸实体型的键的组合

7.关系的规范化

• 第一范式1NF：确保每列的原子性
  • 如果每列都是不可再分的最小数据单元（也称为最小的原子单元），则满足第一范式（1NF）
  • 元祖中的每一个分量都必须是不可分割的数据项
• 第二范式2NF
  • 如果一个关系满足1NF，并且除了主键以外的其他列，都依赖于该主键，则满足第二范式
• 第三范式3NF
  • 如果一个关系满足2NF，并且除了主键以外的其他列都不传递依赖于主键列，则满足第三范式（3NF）

第十一章：系统总体设计

1.多层应用架构模式

• 分层：基于组件的软件开发，组件根据横向位置划分为多层
  • 下层组件负责对上层组件提供服务
  • 上层组件可以使用下层组件定义的服务，但下层组件对上层组件一无所知
  • 层与层之间通常是不透明的，每一层都具有独立的职责
  • 不同层的软件架构可以分布在多台机器上，也可以部署在同一台机器上
• C/S常被称为传统的两层，B/S称为三层

2.传统的C/S应用程序

• 界面窗口程序中包含所有的内容，如输入输出、界面逻辑控制、业务逻辑运算等
• 系统架构是两层，应用架构没有分层

3.经典的三层架构

• 表示层：为用户提供一种交互式操作界面
• 业务逻辑层：表示层与数据访问层之间的桥梁，负责数据处理、传递
• 数据访问层：实现对数据的保存和读取操作

4.MVC

• M是model，表示模型，主要完成系统的逻辑处理
• V是view，表示视图，主要完成与用户的交互
• C是controller，表示控制器，主要建立模型与视图之间的关联

5.结构化设计方法

• 结构化：自顶向下，逐层分解求精
• 结构化设计：软件模块化，按层次划分
• 模块具有输入和输出、逻辑功能、运行程序、内部数据四种属性
• 结构图：描述系统的模块结构及模块间的联系
  • 模块：用长方形表示
  • 调用：从一个模块指向另一个模块的箭头表示前一个模块调用后一个模块。有循环调用和条件调用。
  • 数据：用带圆圈的小箭头表示从一个模块传递给另一个模块的数据
  • 控制信息：用涂黑带圆圈的小箭头表示一个模块传递给另一个模块的控制信息。
• 模块的联系
  • 耦合：模块和模块之间的联系程度
  • 内聚：模块内部个元素之间的联系程度
• 耦合的分类
  • 数据耦合：采用子程序调用，调用模块将需要进行处理的数据传递给被调模块。
  • 标记耦合：如果调用模块将整个数据记录传递给被调模块，而被调模块只使用了部分数据项，则称为标记耦合或特征耦合。
  • 控制耦合：一个模块将控制信息传递给另一个模块，以控制被调模块的内部处理逻辑。
  • 公共环境耦合：如果两个模块共享同一全局数据，称为公共耦合
  • 内容耦合：两个模块之间的内部属性有直接关联
• 内聚
  • 反映模块内部联系的紧密程度
  • 高内聚可以提高程序的可靠性
  • 偶然内聚：同一个子程序中的操作之间无任何联系
  • 逻辑内聚：将几个逻辑上相似的功能放在同一个模块中
  • 时间内聚：将在有限时间单元内处理的成分组合为同一模块
  • 步骤内聚：当子程序中的操作是按某一特定过程结构进行的。在时间内聚上增加了次序的约束。
  • 通信内聚：模块内的成分引用共同的数据，而不存在其他联系
  • 顺序内聚：模块中某个成分的输出是另一成分的输入，是步骤内聚和通信内聚的结合。
  • 功能内聚：一个模块包括并且仅仅包括为完成一个具体任务所需要的所有成分

6.面向对象设计方法

• 边界类：完成系统与其参与者之间的交互
  • 接收来自用户和外部系统的信息与请求
  • 将信息与请求提交给用户和外部系统
  • 根据用例图，每个参与者与一个用例交互，必定导出一个边界类
  • 仅负责数据的输入和输出，不承担和数据处理有关的业务逻辑
  • 与实体类交互，获得有关数据处理的结果
• 实体类：一个软件对象，表示了领域对象的信息，以及具有与它所表示的信息有关的操作
• 控制类：协调、排序、事务处理以及对其他对象的控制，经常用于封装与某个具体用例有关的控制流
  

7.交互图

• 多个对象的行为采用对象交互来表达
• 顺序图
  • 参与者：一个交互过程的发起者，通常放置在最左边
  • 对象：类的实例
  • 生命线：说明了对象的生命周期。如果对象被销毁，其生命线就会中断。
  • 激活框：表明交互中对象何时起作用
  • 消息：对象之间的通信
  • 控制框架
• 协作图/通信图
  • 元素和表示方法与顺序图基本相似，但不表达生命线和消息物理位置，而增加对象消息连接。

8.类的关系（耦合程度从高到低）

• 泛化：使用继承来实现，继承机制实现了子类拥有父类特性的这一过程
• 实现
• 关联：在关联的源类中声明一个属性来保存对目标类的实例的引用
• 依赖：一个类的对象实例使用了另一个类的属性和方法

9.面向服务设计方法

• 一个服务定义了一个与业务功能或业务数据相关的接口，以及约束这个接口的契约。
• 服务可以被其他服务或程序利用。
• SOA：一种架构模式，系统基于服务构件来开发，多个服务通过它们定义良好的接口和契约联系起来。
• SOA特点：可以从企业外部访问，松耦合，粗粒度，面向服务
• 可以解决以下问题
  • 企业内跨平台应用集成
  • 跨企业跨行业应用集成
  • 软件和数据的重用
  • 按需业务流程定制

10.设计原则

• 总的原则
  • 抽象与复用
  • 松耦合
• 面向功能模块
  • 设计功能内聚的模块，避免使用全局数据
  • 模块传递的参数作数据用，并且尽可能少
• 面向对象
  • 单一职责
  • 开放封闭：软件实体应该是“可扩展”的，但又是“不可修改”的
  • 里氏替换：子类行必须能够替换掉它们的基类型
  • 依赖倒置：高层模块不应该依赖于低层模块，二者都应该依赖于抽象
• 面向服务