系统分析

确定出信息系统的逻辑结构。
例如，把图5.2所示的书店信息系统需求结构作为 初步逻辑结构，见图6.9。
第6章 系统分析
书店信息系统
计划订购
书库管理
图书销售
事务管理
入库
出库
盘库
报损
员工信息管理
工资管理
员工勤绩管理
日常事务管理
图6.9 书店信息系统初步逻辑结构
第6章 系统分析
2．分解和确定分析包
确定逻辑结构的过程就是从顶层分析包开始，逐 层对分析包进行分解，直到分解到底层分析包为止。 判断是否达到底层分析包有以下几个准则： (1) 底层分析包支持一个具体并简单的业务过程的
第6章 系统分析
第6章 系统分析
6.1 概述 6.2 逻辑模型 6.3 逻辑结构分析 6.4 用例分析 6.5 概念类分析
第6章 系统分析
6.1 概
6.1.1 系统分析的含义及特点
述
系统分析(System Analysis)是信息系统开发的第三 项工作。该项工作是在业务分析和需求分析的基础上， 从抽象的概念层次上确定信息系统的要素、构成和结 构，得出信息系统的分析模型，并为系统设计提供依
与者与系统存在较频繁的交互内容，并且各交互内容
之间也不存在较密切的关系时，便需要为这个参与者 的一种交互内容设置一个边界类。
第6章 系统分析
售书员
售书界面
图6.3 “售书界面”边界类
第6章 系统分析
3) 控制类
控制类(Control Class)是表示信息系统对其它对象 实施协调处理、逻辑运算的抽象要素。例如，在书店 信息系统中，“出售图书”就属于控制类，见图6.4。
中的“计划订购”分析包分解为对应的“计划管理”、
“订单管理”、“合同管理”、“到货管理”、“书 目管理”和“供书商管理”六个分析包。
第6章 系统分析
其中，“计划管理”分析包可以分解为“计划单
管理”和“计划执行统计”两个分析包，而“计划单 管理”对应图5.5(a)的“编辑图书计划单”、“查询图 书计划”和“输出图书计划单”三个用例，“计划执 行统计”分析包对应“计划执行统计”用例；“合同 管理”分解为“合同信息管理”和“合同执行统计” 两个分析包，而“合同信息管理”对应图5.5(c)
第6章 系统分析
需求模型 《跟踪》
逻辑模型
用例分析类图 用例 用例分析 用例分析协作图
图6.5 用例分析到用例的跟踪
第6章 系统分析
2．用例分析类图
用例分析类图(UseCase Analysis Class Diagram) 用来描述一个用例中的概念类之间的关系所呈现出的 静态结构。用例分析类图从概念层次抽象地描述各概 念类之间的关系，它能够概括地反映实现一个用例的 各概念类所呈现的结构，不涉及过多的细节。
第6章 系统分析
书店信息系统
计划订购
书库管理
图书销售
事务管理
图6.11 书店信息系统顶层逻辑结构
第6章 系统分析
下面我们对除“事务管理”之外的三个分析包分别
进行分解。 1) “计划订购”分析包的分解 图5.4所示的计划订购管理功能用例图把“计划订 购”需求包分解为“计划管理”、“订单管理”、 “合同管理”、“到货管理”、“书目管理”和“供 书商管理”六个用例，这六个用例分别代表了计划订 购管理的六方面相对独立的功能，因此，我们把图6.9
第6章 系统分析
6.3 逻辑结构分析
6.3.1 概述 1．逻辑结构 信息系统逻辑结构由多个分析包按照组成关系或 依赖关系构成。可以对分析包进行分解，高层分析包 由多个低层分析包组成，可以层层分解，直到分析包
的功能已经十分清楚，并且规模适中为止。信息系统
逻辑结构的一般形式见图6.8。
第6章 系统分析
用例。
(2) 底层分析包支持一个具体系统参与者的用例。 (3) 底层分析包应该具有较强的内聚性。如果用例 之间具有泛化、关联等关系，那么这些用例要尽量地 放到一个分析包中。
Baidu Nhomakorabea
第6章 系统分析
3．确定分析包之间的依赖关系
在确定了分析包之后，还需要确定分析包之间的 依赖关系。尽管确定分析包的原则是高内聚、低耦合， 但是在某些分析包之间还仍然存在着依赖关系。 依赖关系用带箭头的虚线表示。通用包和专用包 之间经常会存在依赖关系。分析包之间的依赖关系见 图6.10。
8: 待 售 图 书
1 0: 售 出 图 书
9: 减 架 存 数 量 :出 售 图 书 :架 存 图 书
:售 出 图 书
图6.7 “售书处理”的用例分析协作 图
第6章 系统分析
6.2.4 分析包
分析包(Analysis Package)是信息系统逻辑结构的 结构单元，是对逻辑模型中的概念类、用例分析等要 素进行组织和管理的一种中间模块。按照内容相关性， 把多个聚合度强的概念类和用例分析划归到一个分析 包中。
第6章 系统分析
3) 关系
关系是指概念类相互之间存在的关联、聚合、泛 化等关系。 4) 特殊需求 特殊需求是指在后续阶段细化或实现该类的某些
特殊的性能需求。
第6章 系统分析
3．概念类的类型 UML把概念类分为实体类、边界类和控制类三种 类型，并表示成为图6.2所示的两种形式。
形 式 1：
实体类 形 式 2：
第6章 系统分析
架存图书 售书 售书界面
出售图书 售出图书
图6.4 “出售图书”控制类
第6章 系统分析
6.2.3 用例分析
1．概述 用例分析是指从概念层次上对一个用例的分析及分 析的结果。 用例分析有两个含义：
一是从概念层次上对用例的分析工作及分析过程，
二是表示对用例分析之后所得到的结果。 用例分析用两种图来表示，一种是表示用例概念类 结构的用例分析类图，另一种是反映各概念类之间动态 交互信息的用例分析协作图。
逻辑系统
* 分析包 *
图6.8 信息系统逻辑结构
第6章 系统分析
2．逻辑结构分析的任务
信息系统逻辑结构分析的任务是根据信息系统的 需求结构，确定出信息系统的逻辑结构。信息系统逻 辑结构分析主要包括分解并确定分析包，以及确定分 析包之间的相互关系两方面的工作。
第6章 系统分析
6.3.2 逻辑结构分析
第6章 系统分析
计划订购
计划管理
订单管理
合同管理
书目管理
到货管理
供书商管理
计划单管理
计划执行统计
合同信息管理
合同执行统计
到货信息管理
到货统计
图6.12 计划订购分析包的分解
第6章 系统分析
书库管理
入库
出库
盘库
报损
图6.13 书库管理分析包的分解
第6章 系统分析
2) “书库管理”分析包的分解
图6.9把“书库管理”分解为“入库”、“出库”、 “盘库”和“报损”四个分析包(见图6.13)，这四个包 已经分解得相对独立，无须再进行进一步的分解。 3) “图书销售”分析包的分解 图5.8“图书销售”需求包包括“领书”、“图书 上架”、“销售图书”、“结账”、“盘架”和“资 金结算”六个用例。这六个用例分别分解为图5.9的
第6章 系统分析
“售书处理”的用例分析类图
书目
售书员
售书界面
产生待售图书
待售图书
开书单
打印进程
架存图书
出售图书
售出图书
图6.6 图
“售书处理”的用例分析类
第6章 系统分析
3．用例分析协作图
用例分析协作图(UseCase Analysis Collaboration Diagram)描述为了实现用例的功能，参与者与信息系 统以及信息系统中的各概念类之间所交互的消息。通 过整个消息的传递来实现用例的功能。图6.7是对应于 图6.6的用例分析协作图。
1．逻辑结构分析的依据 信息系统逻辑结构分析的依据是在需求分析中确 定的信息系统需求结构。在逻辑结构分析的开始，可 以直接把需求结构作为要对之进行分析的初步逻辑结
构，把需求结构中的需求包作为逻辑结构中的分析包，
包的名称和组成关系都不改变。接下来在初步逻辑结 构的基础上，通过对各个分析包的分解和优化，最后
(3) 一致性。系统分析所确定逻辑模型应该具有逻
辑一致性，它要纠正需求模型中存在的冗余及错误。
第6章 系统分析
6.1.2 系统分析的主要工作
1．逻辑结构分析 逻辑结构分析(Logic Structure Analysis)要经过确 定初步逻辑结构、分解并确定分析包、确定分析包关 系等步骤。 2．用例分析 用例分析(UseCase Analysis)是从概念层次上对分 析包中的用例进行的分析。 3．概念类分析 概念类分析(Conception Class Analysis)是对所提 取的各概念类的职责、属性、关系和特殊需求所进行 的分析。
第6章 系统分析
逻辑模型 1 逻辑系统
分析包
*
* * 概念类 用例分析
图6.1 逻辑模型
第6章 系统分析
6.2.2 概念类
1．概念类的含义和特征 概念类(Conception Class)是在概念层次上，对信 息系统的抽象要素的一种称谓。 概念类主要来源于业务领域中的客观实体、系统
与外界的交互处理和对系统要素的控制三个方面。
第6章 系统分析
分析包 B
专用包
分析包 A
分析包 B 分析包 A
通用包
图6.10 分析包之间的依赖关系
第6章 系统分析
4．逻辑结构分析过程
我们将以书店信息系统为例，讨论分析包的分解 和确定过程。图6.9是从书店信息系统需求结构转来的 初步逻辑结构。在这个图中，书店信息系统被分解为 “计划订购”、“书库管理”、“图书销售”和“事 务管理”四个高层抽象分析包(见图6.11)，这四个分析 包分别代表书店管理四方面的功能。
第6章 系统分析
2) 边界类
边界类(Boundary Class)是描述系统与参与者之间 交互的抽象要素。边界类只是对信息系统与参与者之 间交互的抽象建模，并不表示交互的具体内容及交互 界面的具体形式。例如，“售书界面”用来抽象地描 述售书员与书店信息系统的交互处理，见图6.3。 应该为每一个参与者至少设置一个边界类，以表 示这个参与者与信息系统的交互处理。但若某一个参
概念类面向功能需求，一般不考虑性能要求，具 有突出业务领域、突出概念性及大粒度的特征。
第6章 系统分析
2．概念类的内容
概念类的内容包括类的职责、属性、关系和特殊 需求。
1) 职责
职责是概念类在信息系统中的作用和责任。主要 从应用需求角度描述概念类的职责，一般不细化到操 作和接口级别。 2) 属性 属性是概念类的性质和特征，应从概念层次描述 该概念类的主要性质，不需要指定属性的类型、可见 性等。
第6章 系统分析
中的“编辑合同”、“查询合同”和“输出合同” 三个用例，“合同执行统计”对应“合同执行统计” 用例;“到货管理”分解为“到货信息管理”和“到货 统计”两个分析包，而“到货信息管理”对应图5.5(d) 中的“登记到货图书”和“打印入库单”两个用例， “统计到货情况”对应“到货统计”用例。通过以上 分解，对“计划订购”分析包分解的最后结果见图 6.12。
据。
第6章 系统分析
系统分析工作的特点如下：
(1) 内在性。系统分析是站在信息系统内部的角度， 分析信息系统的要素、构成和结构。它与需求分析的 区别是，需求分析是站在信息系统用户的角度，确定 信息系统的功能和性能。 (2) 概念性。所谓概念性，是指系统分析工作是站 在较抽象的概念层次上讨论信息系统的内在要素和构 成。
第6章 系统分析
根据分析包的特征，可以把分析包分为专用包、 通用包和服务包三种类型。
1) 专用包
专用包为完成某种功能而设置，一般分析包都属 于专用包。
2) 通用包 能够被多个分析包所共享的分析包被称为通用包。 3) 服务包 在信息系统中，某些包的作用是专门向信息系统 高层提供特定服务，这些分析包被称为服务包。
边界类
控制类
实体
边界
控制
图6.2 概念类的表示
第6章 系统分析
1) 实体类
实体类(Entity Class)是信息系统表示客观实体的 抽象要素。像书店信息系统中的“书目”、“架存图 书”、“售出图书”，“书单”、“书款”等都属于 实体类。实体类一般对应着在业务领域中的客观事物， 或者是具有较稳定信息内容的系统元素。实体类来源 于业务分析中所确定的实体，实体字典是确定实体类 的依据。
第6章 系统分析
“售书处理”的用例分析协作图
:书 目 3: 取 书 目 信 息 1: 书 号 及 册 数 2: 书 号 及 册 数 5: 待 售 图 书 6: 待 售 图 书 7: 书 单
:售 书 员
:售 书 界 面
图书信息 :产 生 待 售 图 书
:待 售 图 书
:开 书 单
:打 印 进 程
4 :图 书 信 息
第6章 系统分析
6.2 逻辑模型
6.2.1 逻辑模型的含义 逻辑模型(Logic Model)是对信息系统要素、构成 和结构的抽象描述，它是系统分析的结果，因此也被 称为分析模型，其构成见图6.1。逻辑模型由逻辑系统 构成，逻辑系统是顶层分析包。逻辑系统又被分解为
多个分析包、概念类以及用例分析，允许分析包嵌套。