系统分析与设计

CH01 软件开发

软件开发困难

• 复杂性，软件规模与构建之间依赖关系复杂
• 一致性：软硬件平台，现有系统
• 可变性： 业务需求变化
• 不可见性：多数代码不可见

软件开发的任务就是确保固有困难不会失去控制，不对项目产生较大负面影响

成功主要因素分为三类

利益相关者

软件项目中存在利益关系的人：

• 客户（用户和系统所有者）
• 开发者（分析员、设计人员、程序员）

信息系统是由人（开发者）为人（客户）开发

软件失败的主要原因可以追溯到利益相关者

• 客户
  • 客户需求被误解
  • 客户需求不切实际
  • 没有提足够资源
  • 需求更改频繁
• 开发者
  • 不胜任
  • “伟大的设计来源于伟大的设计者”

软件过程

软件过程定义完整软件生产和维护的所有活动的组织流程

软件过程模型（软件开发模型/软件生存周期模型）：

• 声明所执行活动的次序
• 详细说明要开发的是什么产品什么时候交付
• 将活动与人工制品分配给开发者
• 提供用来监控项目进展、评估结果和未来项目的标准

不易标准化，不同软件项目采用相应的软件过程模型

现代软件开发过程总是迭代与增量

迭代是短周期的，用户反馈是频繁的，规划是持续的

迭代与增量过程模型：

• 螺旋模型
• Rational统一过程(RUP)
• 模型驱动的体系结构(MDA)
• 敏捷开发过程
• 面向方面的软件开发

迭代与增量开发：

• 必须遵循特定体系结构设计框架
• 必须有计划有控制

CMM能力成熟度模型

有关软件工程和管理实践的最好的软件过程评估模型

1. 初始级，有能力的人与个人英雄主义
2. 可重复级，基本项目管理
3. 已定义级，过程标准化
4. 量化管理级，量化管理
5. 优化级，持续的过程改进

ITIL ISO9000 COBIT

ITIL（Information Technology Infrastructure Library）是被最广泛使用和接受的、用于IT服务管理的最佳实践的框架

ISO 9000系列质量标准：如果过程是正确的，那么过程的结果（产品或服务）也将是正确的

COBIT是目前国际上通用的信息系统审计的标准，定义信息及相关技术的控制目标

ITIL、CMM和ISO 9000是过程标准，COBIT则是产品标准

软件建模

软件建模是指对软件系统进行抽象描述的活动，各个阶段都可以用建模工具对软件系统进行建模描述

• 系统规划模型
• 系统需求模型
• 系统设计模型
• 软件实现模型
• 系统部署模型
• 系统测试模型

建模必须：

• 沟通（语言）
• 文档化（工具）

统一建模语言（UML）是一个通用的、可视化的建模语言

计算机辅助软件工程（CASE）工具使得在中央存储库中实
现模型的存储和检索成为可能

统一建模语言UML

UML独立于

• 任何开发过程：面向对象
• 任何实现技术：面向对象

UML模型包括

• 状态模型：描述静态数据结构
• 行为模型：描述对象协作
• 状态变化模型：描述随时间推移系统所允许的状态
• 体系结构构造：通用，无框架

软件开发策略

1. 定制开发，按照特定的需求对系统进行完整开发实现
2. 集成开发，基于现有系统和接口进行新软件系统和外部系统整合开发

系统规划

对信息系统项目进行规划：识别、分类、排序和选择

1. SWOT方法：优势、劣势、机会、威胁

以调整组织的优势、劣势、机会和威胁的方式，来进行信息系统的识
别、分类、选择和排序，从确定组织使命开始，自顶向下

1. VCM方法（价值链模型，value chain model）

通过分析组织中完整的活动链（如：从原材料到销售及运送给客户的最终产品）来评估竞争优势

1. Business Process Re-engineering，业务过程重组，过程再设计
2. ISA方法（information system architecture）

三级管理系统

• 策略级，支持组织长期目标的策略，知识，知识处理系统
• 战术级，支持短期目标和资源分配的政策，信息，分析处理系统
• 操作级，员工日常活动和生产支持，数据，事务处理系统

生命周期

结构化方法

结构化方法是以过程为中心的软件开发方法，由结构化分析方法、结构化设计方法和结构化程序设计方法组成。

• 过程建模：数据流图（DFD）
• 数据建模：实体关系图（ERD）

优点：简单实用、技术成熟、容易应用。

缺点：

• 与现代软件工程不一致
• 顺序和转换的方法，而不是迭代和递增的
• 倾向于交付僵化的解决方案来满足已识别的业务功能集
• 假设开发从零开始，不支持已有构件的复用
• 对规模较大及处理复杂的软件系统项目不太适合，难以适应需求变更
• 难以解决软件复用，难以进行软件维护，难以提高软件生产效率等

面向对象方法

面向对象方法是一种将面向对象思想应用于软件开发过程、指导软件开发活动的方法。

数据为中心——围绕类模型演化
– 但UML中用例的日渐重要性稍微的将重点从数据转向了过程

生命周期的阶段

• 业务分析/需求分析
• 功能性和非功能性需求
• 系统设计
  • 体系结构设计
  • 详细设计
• 实现
  • 编码
• 集成和部署
• 运行和维护

跨越生命周期的活动

1. 项目规划
   • 估计项目的可交付性、代价、时间、风险、里程碑和资源需求
   • 选择开发方法、过程、工具、标准、团队组织
   • 随生命周期而改进
   • 典型的约束是时间和费用
2. 度量
   • 度量开发时间和工作量，度量软件产品的质量和复杂性
   • 在生命周期的不同阶段度量开发模型→评估过程的有效性和改进生命周期不同阶段的工作质量
   • 没有对过去项目的度量，组织就无法精确计划未来的项目
   • 测试
   • 审查：规格说明等文档（包括程序源代码）
   • 动态测试：规格说明测试（黑盒测试）、代码测试（白盒测试、玻璃盒测试）

开发模型与方法

迭代和增量开发的代表性模型

• 螺旋模型
• IBM Rational统一过程（RUP）RUP统一过程模型是一种用例驱动的、增量迭代的、以体系结构为中心的软件开发流程框架，
• 模型驱动的体系结构（MDA）使用模型完成软件的分析、设计、构建、部署、维护等各开发活动
• 敏捷软件开发,适应不断变化的需求
• 面向方面的开发,为定义、说明、设计和构建方面/Aspect提供过程和方法

CH02 需求确定

业务过程建模

BPMN业务过程图（Business Process Model andNotation，BPMN）

目的是为业务人员和IT人员提供共同的沟通语言，即是泳道图

• 流对象，事件、活动、路由

• 连接对象，序列流、消息流、关联

• 泳道，一个业务实体

• 人工制品，数据对象、组、注释

  过程是分层的，过程可能包含其他过程，过程中的原子活动叫做任务

  UML活动图

  UML活动图是一种用于描述系统行为的模型图，它可用来描述过程（业务过程、工作流、事件流等）中的活动及其迁移

1. 描述用例的行为,建模用例工作流
2. 理解工作流程，画出业务工作流活动图
3. 描复杂过程的算法

• 活动
  • 活动起点
  • 活动终点
  • 动作状态
  • 活动状态
  • 组合活动
• 转换/转移
  • 描述一个活动转向另一个活动
  • 带箭头的实线段，箭头指向转向的活动
  • 转换上可以用文字标识转换发生的条件
• 分叉与汇合
• 分支与合并
• 泳道
• 对象流

需求引导

软件需求（Software Requirement）

是一个软件系统所需具有的功能与性能要求，它描述了待开发软件系统的行为、特性、属性及其约束条件

系统服务： 功能性需求
系统约束： 非功能性需求

非功能性需求

1. 性能
   • 响应时间
   • 吞吐量
   • 并发用户数
2. 可用性
3. 可靠性
4. 效率
5. 适应性
6. 复用性

需求的来源

最基本的需求来源就是用户需求。它反映了用户对系统的功能与性能等方面的要求

需求引导的传统方法

• 面谈
• 调查表
• 观察/业务示范
• 研究文档和软件系统

需求引导的现代方法

• 原型法
• 头脑风暴
• 联合应用开发(Joint application development,JAD)
• 快速应用开发(Rapid application development,RAD)
• 基于用例的方法

需求协商与确认

需要“需求协商与确认”的原因

• 可能是重叠与矛盾的，需要用需求依赖矩阵
• 可能是模棱两可或者不现实的
• 可能未被发现
• 可能超出范围
• “需求协商”从需求文档的草稿开始，删除错误的需求，
  增加新发现的需求
• “需求确认”正式评审文档并‘盖章’（复审会议）

需求管理

需求标识与分类

需求采用自然语言陈述，大量需求陈述

标识与分类方案

• 唯一标识符：通常是顺序号
  • 如有可能，由数据库产生（最灵活和不易出错）
  • 如有可能，包含版本号
• 在文档层次中的顺序编号：根据需求在文档中的位置
• 第2章第3节的第7条需求被编号为2.3.7 – 在需求分类中的顺序编号

需求层次

需求可按父-子关系建立层次结构

需求变更

软件开发的任何阶段，需求都可能变更

需求跟踪

需求跟踪贯穿整个开发生命周期的需求变更

需求跟踪的方式：

• 正向跟踪：检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。
• 逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。

需求业务模型

业务用例模型-UML业务用例图

业务用例图主要包含业务参与者、业务用例、以及它们之间
的关系

主要参与者和次要参与者（外部实体）

• 很多参与者对系统来说既是内部的又是外部的
• 业务用例模型中重要的关系是关联关系
• 需求分析阶段，业务用例图被转换为用例图，并完成详细
  的用例规约

需求文档

项目准备

针对目标管理者和决策制定者

• 从项目的目的和范围开始
• 业务环境：为系统作一个业务案例
• 标识利益相关者
• 为解决方案提供初始想法
  • 包含现成的解决方案
  • 现成的解决方案并不能省去需求分析与系统设计
• 包含对文档其余部分的综述

系统服务

专门讲系统服务的定义：系统必须完成什么

很可能占据整个文档的一大半

包含高层需求业务模型

• 系统范围：环境图
• 功能需求：业务用例图
• 数据需求：业务类图
• 业务词汇表放在附录

系统约束

• 界面需求：
• 性能需求：
• 安全性需求：
• 操作性需求：
• 政策和法律需求
• 其他约束：

项目其他问题

• 待解决问题
• 初步计划
• 初步预算

附录

• 词汇表
• 业务文档和表格
• 参考文献

CH03 可视化建模基础

建模

模型是系统的一种抽象表示

建模就是对系统进行抽象描述，使人们能够通过其模型去理解与
设计系统

1. 建模系统具有如下好处：
   • 通过创建系统的模型，可使人们便于理解、分析与设计系统
   • 通过模型可发现与解决系统中的问题，其成本低
   • 模型可帮助进行系统项目的计划、交流、评估和管理
2. 软件系统建模原则
   • 准确原则，模型必须准确地反映系统的真实情况
   • 分层原则，模型以不同的抽象程度反映系统
   • 分治原则，需要采用分治方法把问题分解为多个子模型来处理
   • 标准原则，模型应该是通用的和标准的，这样便于交流与重用

UML特点

1. 规范并统一了面向对象模型元素的定义和表示法，以及对模型表示的规定，使得对系统的建模有章可循。有标准的语言工具可用，有利于保证系统的建模质量。
2. 提供了简洁地达面向对象中的各种概念和模型元素的能力。UML能够在尽可能简单的同时，满足对实际开发的需要，对系统的各个方面进行建模。
3. 可视化、表示能力强。系统的逻辑模型或实现模型均可用UML模型图形清晰表示，并提供用户的扩展支持，可以处理现代软件开发中出现的所有概念。
4. 通用语言，具有庞大的标准符号体系，提供了多种模型，独立于开发过程。可支持其他面向对象开发和传统的软件开发过程。
5. 文档化语言，能够为系统体系结构和细节建立文档

利用UML进行软件开发

需求确定阶段

• 捕获用户需求，建立用例模型，描述对系统感兴趣的外部角色及对系统的功能要求
• 采用业务用例图描述系统业务，确定项目范围

系统分析阶段

• 采用用例图和文档描述系统的功能需求
• 关心问题域中的主要概念（如类和对象等）和机制，识别类以及它们相互间的关系，并用UML类图来描述
• 为实现用例，类之间需要协作，用UML动态模型描述，采用活动图、顺序图、通信图、状态机图等描述系统逻辑流程、对象间交互等
• 文档编制人员采用用例图和文档编写用户手册和培训计划

系统设计阶段

• 使用构件图、部署图、包图，定义软件系统体系结构
• 采用类图、对象图等定义软件系统构件技术细节
• 使用活动图、状态机图、顺序图、通信图等描述系统的逻辑流程、

系统实现阶段

• 用面向对象编程语言将设计阶段的类转换成代码

系统测试阶段

• 单元测试使用类图和类规格说明
• 集成测试使用构件图和通信图
• 系统测试使用用例图
• 验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段
  确定的需求

CH04 需求规格说明

软件体系结构定义了系统中相互作用的软件构件及子系统的
结构和组织形式。

结构化分析方法

	建模方法	模型表示
功能建模	数据流分析方法	数据流图,层次数据流图,数据字典
	IDEF0分析方法	活动数据图
数据建模	语义数据模型方法	实体-关系图（ER图）
	IDEF1X模型方法	IDEF1X图例

面向对象分析方法

建模方法	模型表示
UML	用例图、活动图、顺序图等
OOSE	用例图、对象图、交互作用图、状态图等
Booch	对象图、状态跃迁图、交互作用图等
OMT	文本化的用例、事件跟踪图、事件流图、状态图、数据流图等
OOA/OOD	OOA图、对象状态图、服务图等

需求规格说明

需求规格说明是客户和开发小组对将要开发的系统产品达成的一致协议。这一协议综合了业务需求、用户需求和软件功能和性能需求。它将作为系统开发、验证、评审最基本的依据和最重要的文档。

建立图形化模型，描绘转换过程、系统状态变化、数据关系、逻辑流程和它们的关系。

需求规格说明书的使用对象

• 客户和营销部门：了解他们所能提供的产品
• 项目经理：制定规划并预测进度安排、工作量和资源
• 软件开发小组：理解他们将要开发的产品
• 测试小组：制定测试计划、测试用例和测试过程
• 软件维护和支持人员：了解产品的某部分是做什么的
• 产品发布组：在需求规格说明书和用户界面设计的基础上编写
  客户文档，如用户手册和帮助屏幕等。
• 培训人员：根据需求规格说明书和用户文档编写培训材料。

状态规格说明

状态规格说明提供系统的结构视图（静态视图）

主要任务是定义应用领域的类、类的属性、以及与其它类的关系

UML中使用类图（Class Diagram）和对象图（Object Diagram）进行状态规格说明

类建模

类建模不是一个确定的过程，是高度迭代增量式

发现类

1. 名词短语方法，将每一个名词或名词短语认为一个候选类，分成相关类、模糊类、无关类

2. 公共模式方法：分类理论将对象世界划分成有用的组

3. 用例驱动方法，根据用例图、用例规约、行为和交互模型来发现候选类

4. CRC方法，类-职责-协作者Classes-Responsibilities-Collaborators），分析对象之间为完成业务功能而进行的协作来识别类

   头脑风暴式的集体讨论，使用一种特殊制作的卡片，卡片包含3栏：

   • 类名：最上面的分栏
   • 类职责：左边的分栏
   • 协作者：右边的分栏

5. 混合方法发现类的实际过程，常常是以上几种方法的混合

CH05 从分析到设计

高级类建模

可见性与封装

• 私有可见性（-）
• 公共可见性（+）
• 保护可见性（#）
• 包可见性（~）

关联类与具体化类

关联类：是一个关联，也是一个类

• 如果两个类之间是多对多的关联，每个关联实例具有属性值，则使用关联类
• 关联类的约束：对于每一对链接起来的类的实例，只能存在关联类的一个实例

如果不能满足该约束，则将关联具体化，使用普通类代替关联类（具体化类）

高级泛化与继承建模

泛化是类之间的语义关系，泛化关系用来描述类的一般和具体之间的关系，表明“是一种”关系。泛化的目的是“继承”、“可替换”、“多态性”

继承是一种机制，通过继承特殊的元素可以合并一般元素中定义的结构和行为

封装与继承是正交的,通过继承，封装可以被打破

封装和查询能力是正交的– 用户依靠SQL访问数据库，直接查阅属性证明是有效的

抽象类

抽象类是对一组具有相同属性和方法的逻辑上有关系的事物的一种抽象

接口是对一组具有相同属性和方法的逻辑上不相关的事物的一种抽象

高级聚合与委托建模

聚合表示类之间的“整体和部分”关系。整体称为“复合类”，部分称为“构件类”

• ExclusiveOwns专属聚合
• Member成员聚合
• Owns从属聚合
• Has拥有聚合

高级交互技术

• 说明基本技术
• 创建与销毁对象
• 结构化控制
• alt条件片段、opt选择片段
• loop循环片段
• 交互使用,是一个外围交互对另一个交互的引用

CH06 系统与程序设计

体系结构与模式

1. 体系结构设计是从系统的模块方面对系统进行描述
   • 定义类和包的分层组织
   • 将进程分配给计算设施
   • 复用和构件管理

软件体系结构定义了系统中相互作用的软件构件及子系统的结构和组织形式

至关重要：在详细的系统规格说明之前，选定体系结构模式和原则

1. 详细设计是对每个模块（用例）内部工作的描述
   • 设计算法和数据结构
   • 描述（实现用例的）协作模型

模式

模式阐述了一个在软件系统设计和实现中反复出现的问题，记录了软件开发领域已得到充分证明的经验和良好的设计实践

架构模式/体系结构模式

描述了在特定设计情形下反复出现的问题，并提供了已经得到充分证明的通用解决方案摘要。解决方案描述模式的组件、组件的职责和关系、以及这些组件协作的方式。

架构模式是软件架构（体系结构）的模板，描绘应用程序的系统级结构特征，并将影响子系统的架构。

MVC架构

将程序分成三部分：处理、输出、输入

• 模型组件（Model）：封装核心数据和功能，独立于输入和输出
• 视图组件（View）：向用户显示信息，一个模型可以有多个视图
• 控制器组件（Controller）：每个视图都有相关联的控制器组件，处理用户输入

设计模式

• 外观（Façade）
• 抽象工厂（Abstract Factory）
• 责任链（Chain of Responsibility）
• 观察者（Observer）发布-订阅模式
• 中介者（Mediator）
• Whole-Part（整体-部分）
• Master-Slave（主-从）
• Proxy（代理）
• Command Processor（命令处理器）
• View Handler(视图管理者)
• Forwarder-Receiver（转发者-接收者）
• Client-Dispatcher-Server（客户端-分配器-服务器）

体系结构设计

• 逻辑体系结构
  • 关注系统中相互作用的软件构件及子系统的结构和组织形式
  • 使用UML构件图和UML包图建模
• 物理体系结构
  • 关注部署方案的选择以及系统的工作负荷在多处理器上的分布
  • 将处理构件分配给计算机结点
  • 使用UML部署图建模

体系结构建模

• 构件图
• 部署图
• 包图

CH07 GUI用户图形界面

界面元素

界面元素: 窗口、菜单、 按钮、标签、 滚动条、 下拉列表、 状态栏等
界面操作机制: 导航机制 输入机制 输出机制

良好的特性

1. 易用性，操作简单方便
2. 灵活性，可灵活处理
3. 安全性，操作有效
4. 艺术性，赏心悦目

GUI设计原则

1. 方便用户控制
2. 提供定制化
3. 界面美观
4. 界面一致
5. 减少用户记忆负担

桌面GUI设计

主窗口是指桌面软件的主程序用户操作界面，它为窗口框架，其容器包含子窗口、菜单、控件等界面组件。

子窗口是指桌面软件功能子程序用户操作界面，它通常为弹出窗口、对话框、消息框

• 非模态对话框子窗口
• 标签页子窗口
• 下拉列表子窗口
• 消息框子窗口

Web GUI设计

• Web表单设计
• 菜单与链接导航设计
• 面包屑和导航面板
• 文件上传控件设计
• 选项标签页设计

用户输入设计

输入设计策略

• 控制输入变量
• 减少输入延迟
• 减少输入错误
• 避免额外步骤
• 输入过程尽量简化

输入安全性设计

输入数据阶段产生的错误，如录入员的错读、漏读、误操作等原因引起的数据错误，可以采用数据验证检查来解决。

• 顺序检查
• 存在性检查
• 数据类型检查
• 范围检查
• 合理性检查
• 有效性检查
• 组合性检查