一. 系统规划

1.1 项目的提出与选择

该步骤生成” 产品/项目建议书”.

1、 计划阶段， 在计划阶段， 要进行现有系统的调查整理， 从移植技术、 系统内容（是
否进行系统提炼等）、 系统运行三个方面， 探讨如何转换成新系统， 决定移植方法， 确立移
植工作体制及移植日程。
2、 准备阶段， 在准备阶段要进行移植方面的研究， 准备转换所需的资料。 该阶段的作
业质量将对以后的生产效率产生很大的影响。
3、 转换阶段， 这一阶段是将程序设计和数据转换成新机器能根据需要工作的阶段。 提
高转换工作的精度， 减轻下一阶段的测试负担是提高移植工作效率的基本内容。
4、 测试阶段， 这一阶段是进行程序单元、 工作单元测试的阶段。 在本阶段要核实程序
能否在新系统中准确地工作。 所以， 当有不能准确工作的程序时， 就要回到转换阶段重新工
作。
5、 验证阶段， 这是测试完的程序使新系统工作， 最后核实系统， 准备正式运行的阶段。

二. 系统分析与设计

2.1 定义问题与归结模型

目录

一. 系统规划

1.1 项目的提出与选择

1.2 可行性研究与效益分析

1.3 方案的制订和改进

1.4 新旧系统分析和比较

二. 系统分析与设计

2.1 定义问题与归结模型

2.2 需求

2.2.1 需求工程

2.2.2 需求分析

2.3 系统设计(软件设计)

2.4 结构化分析与设计

2.4.1 分析步骤

2.4.2 分析工具

2.4.3 结构化设计

2.4.4 数据流图、 流程图

2.5 面向对象分析与设计

 2.5.1 基本概念

2.5.2 UML(统一建模语言)

2.5.3 用例模型

2.5.4 分析模型

2.5.5 设计模型

2.6 用户界面设计

2.7 工作流设计

2.8 简单分布式计算机应用系统设计

2.8.1 分布式系统开发

 2.8.2 分布式计算架构

2.9 系统运行环境的集成与设计

2.10 系统过渡设计

---

2.2 需求

2.2.1 需求工程

        需求工程包括需求管理和需求开发。
        需求开发： 包括需求捕获、 需求分析、 编写规格说明书和需求验证 4 个阶段。 需求开
发是努力更清晰、 更明确地掌握客户对系统的需求。
        需求管理： 通常包括定义需求基线、 处理需求变更、 需求跟踪等方面的工作。 而需求管
理则是对需求的变化进行管理的过程。

2.2.2 需求分析

• 包括内容

1. 问题识别： 用于发现需求、 描述需求。 预先估计以后系统可能达到的目标。
2. 分析与综合： 对问题进行分析， 然后在此基础上整合出解决方案。
3. 编制需求分析文档： 对已经确定的需求进行文档化描述， 该文档通常称为“需求规格说明书” 
4. 需求分析与评审： 对功能的正确性、 完整性和清晰性， 以及其他需求给予评价。

• 需求分类 1

1. 功能需求
2. 非功能需求
3. 设计约束

• 需求分类 2

1. 业务需求
2. 用户需求
3. 系统需求： 包括 功能需求/质量属性/非功能需求/设计约束

• 需求获取方式

1. 收集资料
2. 联合需求计划: 召集多部门开会
3. 用户访谈: 结构化, 准备好了问题; 非结构化, 随机应变问问题.
4. 明确访谈目的/ 确：书面(问卷)调查/情节串联板/现场观摩/参加业务实践/阅读历史文档/ 抽样调查

2.3 系统设计(软件设计)

 步骤: 概要设计(高层设计)/详细设计(低层设计)
 设计方法: 结构化设计/面向对象设计

2.4 结构化分析与设计

2.4.1 分析步骤

研究物质环境/建立系统逻辑模型/划清人机界限

2.4.2 分析工具

数据流图/数据字典/结构化语言/判定表/判定树
一个数据流图里面有数据流、 加工、 外部实体、 数据存储.因此在描述完数据流图之后,
可紧接着描述数据字典(数据流名称、 来源、 去向、 结构、 组织等)和处理(加工).

2.4.3 结构化设计

概要设计----模块结构图/层次图/HIPO 图(层次+input process output)
详细设计----程序流程图/盒图 NS/PAD 问题分析图/PDL 程序设计语言(伪码)
模块(化)---- 指执行某一特定任务的数据结构和程序代码

外部特征: 模块的接口和功能/
内部特征: 模块的局部数据和程序代码
关键原则: 信息隐蔽/模块独立性(高内聚、 低耦合)

 

 

2.4.4 数据流图、 流程图

数据流图:作为一种图形化工具,用来说明业务处理过程、 系统边界内所包含的功能和系
统中的数据流。 (1 Context 图 / 2 DFD 0 层图)

设计原则:

• 父图与子图的平衡:子图的输入输出数据流同父图相应加工的输入输出数据流一致。
•  数据守恒: 指加工的输入、 输出数据流是否匹配， 即每一个加工既有输入数据流又有输出数据流。
• 守恒加工: 对于同一个加工， 其输入与输出的名字必须不同。
• 加工细节隐蔽: 父图内部细节留给子图去画。
• 简化加工之间的关系: 尽量减少加工间输入/输出数据流的数目.

 

 流程图:以图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程,描述处理过程的控制流。

区别	数据流图	流程图
并行性	处理过程可并行	某个时间点只能处于一个处理过程
展示流	展示数据流	展示控制流
计时标准	展示全局的处理过程,过程之 间遵循不同计时标准	遵循一致的计时标准
用途	系统分析中的逻辑建模	系统设计中的物理建模

2.5 面向对象分析与设计

 2.5.1 基本概念

类/对象; 继承/泛化; 多态/重载

2.5.2 UML(统一建模语言)

a 组成

• 构造块
  • 事物(建模元素)---结构事物/行为事物/分组事物/注释事
  • 关系---关联/依赖/泛化/实现 http://c.biancheng.net/view/1319.html
  • 图 (如下)---(结构)静态模型(类图、 对象图、 包图、 构件图、 部署图、 制品图) / (行为)动态模型（ 用例图、 顺序图、 通信图、 定时图、 状态图、 活动图、 交互概览图）
• 公共机制
  • 规格说明/修饰/公共分类/扩展机制
• 规则

b 软件架构(4+1 视图模型), (非 UML 特有)

速记: “逻进部实用” , ” 逻进物开场”
 

• 逻辑视图： 以问题域的语汇组成的类和对象集合。 (功能)
• 进程视图： 可执行线程和进程作为活动类的建模， 它是逻辑视图的一次执行实例。 (运行). 主要关注一些非功能性需求， 例如， 系统的性能和可用性等。 进程视图强调并发性、分布性、 系统集成性和容错能力。
• 实现(开发)视图： 对组成基于系统的物理代码的文件和组件进行建模。 (模块组织管理)
• 部署(物理)视图： 把组件物理地部署到一组物理的、 可计算的节点上。
• 用例(场景)视图： 最基本的需求分析模型

c 类间关系表示

• 依赖: 某个类的方法通过局部变量、 方法的参数或者对静态方法的调用来访问另一个类（被依赖类）

• 关联: (包括一般关联关系、 聚合关系和组合关系). 将一个类的对象作为另一个类的成
  员变量来实现关联关系. 关联可以是双向的， 也可以是单向的。

• 聚合: 关联关系的一种. 通过成员对象来实现的， 其中成员对象是整体对象的一部分，但是成员对象可以脱离整体对象而独立存在

 

• 组合: 关联关系的一种， 也表示类之间的整体与部分的关系, 部分对象不能脱离整体对象而存在, 即共存.

•  泛化: 父类与子类之间的关系

• 实现: 接口与实现类之间的关系

d 各种图

用例图(系统与外部的交互关系, 详见下一节): 参与者/用例/包含和扩展/通信关联

• 包图: 表示软件体系结构图
• 类图: 描述类的内部属性和行为, 以及类集合之间的交互关系;
• 对象图: 描述一组对象及它们之间的关系;
• 类关系: 依赖(箭头虚线)/泛化(空心箭头实线)/关联(实线)/聚合(空心菱形实线)
• 多重性: 如下图, 1 本书籍包含 0 个或者 1 个借阅记录, 即 1 对 0..1

•  交互图: 表示各组对象如何依某种行为进行协作。 可以用来表示用例的行为。
  • 分类: 顺序图/通信图/定时图

 

• 状态图： 主要用于描述一个对象在其生存周期的动态行为， 表现一个对象所经历的状态序列，引起状态转移的事件， 以及因状态转移而伴随的动作。 侧重描述行为的结果。（又： 描述一个特定的复杂对象的所有可能状态及其引起状态转移的事件） 

• 活动图： 用于描述系统的工作流程和并发行为。 活动图可以看作是状态图的特殊形式。 侧重描述行为的动作。 活动图中一个活动结束后将立即进入下一个活动， 而在状态图中状态的转移可能需要事件的触发。

•  构件图: 一组源代码文件、 二进制代码文件和可执行文件(构件)之间的关系

 

•  部署图(实施图): 在构件图基础上更进一步地描述系统硬件的物理拓扑结构及在此结构上执行的软件。
  • 组成: 结点和连接 / 构件和接口

2.5.3 用例模型

用例图：用来描述系统需求, 用例图的元素包括参与者、 用例和通信关联。
建模步骤包括 4 步:

• a 识别参与者
• b 合并需求获得用例
• c 细化用例描述
  • 用例名称、简要说明、事件流、非功能需求、前置条件和后置条件、扩展点、优先级
• d 调整用例模型
  • 用例之间的关系包括 包含/扩展/泛化, 基于这些关系对用例进行调整. 

2.5.4 分析模型

        利用图: 用例图/类图/交互图
        用来描述系统的基本逻辑结构, 展示对象和类如何组成系统(静态模型),以及它们如何
保持通信,实现系统行为(动态模型). 由顶层架构图、 用例与用例图和领域概念模型构成
         步骤:

• a 定义概念类
• b 确定类之间的关系
  • 关系包括: 关联/依赖/泛化/聚合/组合/实现
  • 用类图表示
• c 为类添加职责
  • 成员变量(属性) 和 成员方法
• d 建立交互图
  • 包括顺序图/交互概览图/通信图/定时图
• e 分析模型的详细程度问题
   

2.5.5 设计模型

包含: 以包图表示的软件体系结构图; 以交互图表示的用例实现图; 完整精确的类图;
针对复杂对象的状态图; 描述流程化处理的活动图
 

2.6 用户界面设计

黄金法则：置用户于控制之下/减少用户记忆负担/保持界面一致

过程：用户、 任务和环境分析/界面设计/实现/界面确认
 

2.7 工作流设计

流程定义工具
工作流管理系统

2.8 简单分布式计算机应用系统设计

基于实例的协作:对远程实例有较大控制权,小范围内” 近连接” ,常使用代理方式.
基于服务的协作:只能调用远程对象的接口方法,无法创建销毁远程对象.跨平台” 远连
接” .

2.8.1 分布式系统开发

五个逻辑计算层：

• 表示层实现用户界面；
• 表示逻辑层为了生成数据表示而必须进行的处理任务， 如输入数据编辑等；
• 应用逻辑层包括为支持实际业务应用和规则所需的应用逻辑和处理过程， 如信用检查、 数据计算和分析等；
• 数据处理层包括存储和访问数据库中的数据所需的应用逻辑和命令， 如查询语句和存储过程等；
• 数据层是数据库中实际存储的业务数据。
   

 2.8.2 分布式计算架构

①分布式表示架构是将表示层和表示逻辑层迁移到客户机， 应用逻辑层、 数据处理层和
数据层仍保留在服务器上；
②分布式数据架构是将数据层和数据处理层放置于服务器， 应用逻辑层、 表示逻辑层和
表示层放置于客户机；
③分布式数据和应用架构是将数据层和数据处理层放置在数据服务器上， 应用逻辑层放
置在应用服务器上， 表示逻辑层和表示层放置在客户机上。

2.9 系统运行环境的集成与设计

软件运行环境: 包括 系统运行的设备/操作系统/网络配置
集中式系统: 单计算机结构/集群结构/多计算机结构
分布式系统: 基于网络
C/S 结构: 如数据库/网络打印服务系统/网络游戏
多层结构 3: 扩展了 C/S, 由存储数据的数据库服务器作为数据层、 实现商业规则的程
序作为逻辑层、 管理用户输入输出的视图层
Internet、 Intranet、 Extranet

2.10 系统过渡设计

直接过渡/并行过渡/阶段过渡