第6章 系统分析 6.1 概述 6.2 逻辑模型 6.3 逻辑结构分析 6.4 用例分析 6.5 概念类分析

6.1 概 述 6.1.1 系统分析的含义及特点 系统分析(System Analysis)是信息系统开发的第三项工作。该项工作是在业务分析和需求分析的基础上，从抽象的概念层次上确定信息系统的要素、构成和结构，得出信息系统的分析模型，并为系统设计提供依据。

系统分析工作的特点如下： (1) 内在性。系统分析是站在信息系统内部的角度，分析信息系统的要素、构成和结构。它与需求分析的区别是，需求分析是站在信息系统用户的角度，确定信息系统的功能和性能。 (2) 概念性。所谓概念性，是指系统分析工作是站在较抽象的概念层次上讨论信息系统的内在要素和构成。 (3) 一致性。系统分析所确定逻辑模型应该具有逻辑一致性，它要纠正需求模型中存在的冗余及错误。

6.1.2 系统分析的主要工作 1．逻辑结构分析 逻辑结构分析(Logic Structure Analysis)要经过确定初步逻辑结构、分解并确定分析包、确定分析包关系等步骤。 2．用例分析 用例分析(UseCase Analysis)是从概念层次上对分析包中的用例进行的分析。 3．概念类分析 概念类分析(Conception Class Analysis)是对所提取的各概念类的职责、属性、关系和特殊需求所进行的分析。

6.2 逻辑模型 6.2.1 逻辑模型的含义 逻辑模型(Logic Model)是对信息系统要素、构成和结构的抽象描述，它是系统分析的结果，因此也被称为分析模型，其构成见图6.1。逻辑模型由逻辑系统构成，逻辑系统是顶层分析包。逻辑系统又被分解为多个分析包、概念类以及用例分析，允许分析包嵌套。

图6.1 逻辑模型

6.2.2 概念类 1．概念类的含义和特征 概念类(Conception Class)是在概念层次上，对信息系统的抽象要素的一种称谓。 概念类主要来源于业务领域中的客观实体、系统与外界的交互处理和对系统要素的控制三个方面。 概念类面向功能需求，一般不考虑性能要求，具有突出业务领域、突出概念性及大粒度的特征。

2．概念类的内容 概念类的内容包括类的职责、属性、关系和特殊需求。 1) 职责 职责是概念类在信息系统中的作用和责任。主要从应用需求角度描述概念类的职责，一般不细化到操作和接口级别。 2) 属性 属性是概念类的性质和特征，应从概念层次描述该概念类的主要性质，不需要指定属性的类型、可见性等。

3) 关系 关系是指概念类相互之间存在的关联、聚合、泛化等关系。 4) 特殊需求 特殊需求是指在后续阶段细化或实现该类的某些特殊的性能需求。

3．概念类的类型 UML把概念类分为实体类、边界类和控制类三种类型，并表示成为图6.2所示的两种形式。 图6.2 概念类的表示

1) 实体类 实体类(Entity Class)是信息系统表示客观实体的抽象要素。像书店信息系统中的“书目”、“架存图书”、“售出图书”，“书单”、“书款”等都属于实体类。实体类一般对应着在业务领域中的客观事物，或者是具有较稳定信息内容的系统元素。实体类来源于业务分析中所确定的实体，实体字典是确定实体类的依据。

2) 边界类 边界类(Boundary Class)是描述系统与参与者之间交互的抽象要素。边界类只是对信息系统与参与者之间交互的抽象建模，并不表示交互的具体内容及交互界面的具体形式。例如，“售书界面”用来抽象地描述售书员与书店信息系统的交互处理，见图6.3。 应该为每一个参与者至少设置一个边界类，以表示这个参与者与信息系统的交互处理。但若某一个参与者与系统存在较频繁的交互内容，并且各交互内容之间也不存在较密切的关系时，便需要为这个参与者的一种交互内容设置一个边界类。

图6.3 “售书界面”边界类

3) 控制类 控制类(Control Class)是表示信息系统对其它对象实施协调处理、逻辑运算的抽象要素。例如，在书店信息系统中，“出售图书”就属于控制类，见图6.4。

图6.4 “出售图书”控制类

6.2.3 用例分析 1．概述 用例分析是指从概念层次上对一个用例的分析及分析的结果。 用例分析有两个含义： 一是从概念层次上对用例的分析工作及分析过程， 二是表示对用例分析之后所得到的结果。 用例分析用两种图来表示，一种是表示用例概念类结构的用例分析类图，另一种是反映各概念类之间动态交互信息的用例分析协作图。

图6.5 用例分析到用例的跟踪

2．用例分析类图 用例分析类图(UseCase Analysis Class Diagram)用来描述一个用例中的概念类之间的关系所呈现出的静态结构。用例分析类图从概念层次抽象地描述各概念类之间的关系，它能够概括地反映实现一个用例的各概念类所呈现的结构，不涉及过多的细节。

图6.6 “售书处理”的用例分析类图

3．用例分析协作图 用例分析协作图(UseCase Analysis Collaboration Diagram)描述为了实现用例的功能，参与者与信息系统以及信息系统中的各概念类之间所交互的消息。通过整个消息的传递来实现用例的功能。图6.7是对应于图6.6的用例分析协作图。

图6.7 “售书处理”的用例分析协作图

6.2.4 分析包 分析包(Analysis Package)是信息系统逻辑结构的结构单元，是对逻辑模型中的概念类、用例分析等要素进行组织和管理的一种中间模块。按照内容相关性，把多个聚合度强的概念类和用例分析划归到一个分析包中。

根据分析包的特征，可以把分析包分为专用包、通用包和服务包三种类型。 1) 专用包 专用包为完成某种功能而设置，一般分析包都属于专用包。 2) 通用包 能够被多个分析包所共享的分析包被称为通用包。 3) 服务包 在信息系统中，某些包的作用是专门向信息系统高层提供特定服务，这些分析包被称为服务包。

6.3 逻辑结构分析 6.3.1 概述 1．逻辑结构 信息系统逻辑结构由多个分析包按照组成关系或依赖关系构成。可以对分析包进行分解，高层分析包由多个低层分析包组成，可以层层分解，直到分析包的功能已经十分清楚，并且规模适中为止。信息系统逻辑结构的一般形式见图6.8。

图6.8 信息系统逻辑结构

2．逻辑结构分析的任务 信息系统逻辑结构分析的任务是根据信息系统的需求结构，确定出信息系统的逻辑结构。信息系统逻辑结构分析主要包括分解并确定分析包，以及确定分析包之间的相互关系两方面的工作。

6.3.2 逻辑结构分析 1．逻辑结构分析的依据 信息系统逻辑结构分析的依据是在需求分析中确定的信息系统需求结构。在逻辑结构分析的开始，可以直接把需求结构作为要对之进行分析的初步逻辑结构，把需求结构中的需求包作为逻辑结构中的分析包，包的名称和组成关系都不改变。接下来在初步逻辑结构的基础上，通过对各个分析包的分解和优化，最后确定出信息系统的逻辑结构。 例如，把图5.2所示的书店信息系统需求结构作为初步逻辑结构，见图6.9。

图6.9 书店信息系统初步逻辑结构

2．分解和确定分析包 确定逻辑结构的过程就是从顶层分析包开始，逐层对分析包进行分解，直到分解到底层分析包为止。 判断是否达到底层分析包有以下几个准则： (1) 底层分析包支持一个具体并简单的业务过程的用例。 (2) 底层分析包支持一个具体系统参与者的用例。 (3) 底层分析包应该具有较强的内聚性。如果用例之间具有泛化、关联等关系，那么这些用例要尽量地放到一个分析包中。

3．确定分析包之间的依赖关系 在确定了分析包之后，还需要确定分析包之间的依赖关系。尽管确定分析包的原则是高内聚、低耦合，但是在某些分析包之间还仍然存在着依赖关系。 依赖关系用带箭头的虚线表示。通用包和专用包之间经常会存在依赖关系。分析包之间的依赖关系见图6.10。

图6.10 分析包之间的依赖关系

4．逻辑结构分析过程 我们将以书店信息系统为例，讨论分析包的分解和确定过程。图6.9是从书店信息系统需求结构转来的初步逻辑结构。在这个图中，书店信息系统被分解为“计划订购”、“书库管理”、“图书销售”和“事务管理”四个高层抽象分析包(见图6.11)，这四个分析包分别代表书店管理四方面的功能。

图6.11 书店信息系统顶层逻辑结构

下面我们对除“事务管理”之外的三个分析包分别进行分解。 1) “计划订购”分析包的分解 图5.4所示的计划订购管理功能用例图把“计划订购”需求包分解为“计划管理”、“订单管理”、“合同管理”、“到货管理”、“书目管理”和“供书商管理”六个用例，这六个用例分别代表了计划订购管理的六方面相对独立的功能，因此，我们把图6.9中的“计划订购”分析包分解为对应的“计划管理”、“订单管理”、“合同管理”、“到货管理”、“书目管理”和“供书商管理”六个分析包。

其中，“计划管理”分析包可以分解为“计划单管理”和“计划执行统计”两个分析包，而“计划单管理”对应图5 其中，“计划管理”分析包可以分解为“计划单管理”和“计划执行统计”两个分析包，而“计划单管理”对应图5.5(a)的“编辑图书计划单”、“查询图书计划”和“输出图书计划单”三个用例，“计划执行统计”分析包对应“计划执行统计”用例；“合同管理”分解为“合同信息管理”和“合同执行统计”两个分析包，而“合同信息管理”对应图5.5(c)

中的“编辑合同”、“查询合同”和“输出合同”三个用例，“合同执行统计”对应“合同执行统计”用例;“到货管理”分解为“到货信息管理”和“到货统计”两个分析包，而“到货信息管理”对应图5.5(d)中的“登记到货图书”和“打印入库单”两个用例，“统计到货情况”对应“到货统计”用例。通过以上分解，对“计划订购”分析包分解的最后结果见图6.12。

图6.12 计划订购分析包的分解

图6.13 书库管理分析包的分解

2) “书库管理”分析包的分解 图6.9把“书库管理”分解为“入库”、“出库”、“盘库”和“报损”四个分析包(见图6.13)，这四个包已经分解得相对独立，无须再进行进一步的分解。 3) “图书销售”分析包的分解 图5.8“图书销售”需求包包括“领书”、“图书上架”、“销售图书”、“结账”、“盘架”和“资金结算”六个用例。这六个用例分别分解为图5.9的(a)～(f)六个功能用例图。因此，可以对应把图6.9中的“图书销售”分析包分解为“领书”、“图书上架”、“销售图书”、“结账”、“盘架”和“资金结算”六个分析包。

其中，“领书”分析包又分解为“编辑出库图书”、“查询出库信息”和“打印出库单”三个分析包；“图书上架”分解为“编辑上架图书”、“查询上架信息”和“打印架存报表”三个分析包；“销售图书”分解为“售书处理”、“浏览销售信息”、“打印销售报表”三个分析包，同时又从“售书处理”中分解出一个“收书款”分析包；“结账”分解为“销售汇总”和“打印销售账单”两个分析包；“盘架”分解为“编辑盘架信息”和“打印盘架单”两个分析包；“资金结算”分解为“收款汇总”和“打印结算单”两个分析包。对“图书销售”分析包分解的结果见图6.14。

图6.14 图书销售分析包的分解

信息系统的逻辑结构确定之后，每一个分析包都会对应着在需求分析中确定的一个或多个用例。例如，图6. 15列出了图6 信息系统的逻辑结构确定之后，每一个分析包都会对应着在需求分析中确定的一个或多个用例。例如，图6.15列出了图6.14的“销售图书”等分析包与图5.9中销售图书用例图中的用例之间的对应关系。

图6.15 分析包与用例的对应关系

6.4 用例分析 6.4.1 概述 确定了逻辑结构之后，接下来需要对每一个分析包中的用例进行分析。用例分析将逐一对分析包中的每一个用例进行分析，提取概念类，分析各个概念类之间的关系，确定用例分析类图和用例分析交互图。因为要对需求模型中的每一个用例进行分析，所以分析的工作量很大，分析人员需要认真对待。

6.4.2 用例分析过程 用例分析一般需要经过三个步骤。第一步提取用例的概念类。概念类有三种类型，应该先确定实体类，再确定边界类，最后确定控制类。第二步确定用例中概念类之间的关系，并绘制用例分析类图。概念类之间有关联关系、泛化关系和依赖关系，其中主要是关联关系。第三步分析参与者与用例所交互的信息，以及用例中各概念类之间所交互的信息，并得出用例分析交互图。在此以图5.9(e)“售书处理”用例为例，介绍用例分析过程。图5.9(e)中的“售书处理”用例要引用“收书款”子用例，下面我们分别对这两个用例进行分析。

1．“售书处理”用例分析 售书的处理过程是，读者把从书架上选择的图书拿到售书员面前，售书员用条码扫描仪接收读者所选图书的书号，并启动系统打印出三联书单。读者持书单到收款台交书款，收款员接收书款之后，自己留存一联书单，并在另外两联书单上盖章，交给读者，读者再持交款后的书单到售书员前领取图书。售书员见到盖章后的书单，自己留存一联，然后给图书盖章，并把图书和一联书单交给读者。

1) 提取概念类 “售书处理”用例的边界类应该是“售书界面”。其涉及到的实体类有“书目”、“架存图书”、“待售图书”和“售出图书”。“书目”类保存图书的基本信息，“架存图书”类表示目前在销售书架上所有的各种图书，“待售图书”类表示读者已经选择准备购买，并正在办理购书手续的图书，而“售出图书”类则表示已经办完售书手续的图书。本用例的控制类是“产生待售图书”、“开书单”和“出售书单”。“售书处理”的概念类见图6.16。

图6.16 “售书处理”的概念类

2) 用例分析类图 “售书处理”的用例分析类图见图6.17。 3) 用例分析交互图 “售书处理”的用例分析交互图见图6.18。首先，售书员把读者要购买图书的书号扫描到“售书界面”中。接着，由“产生待售图书”控制类从“书目”和“架存图书”实体类中取出待售图书的有关信息，放到产生的“待售图书”对象之中。然后，由“开书单”控制类控制产生书单，并把书单信息送至“打印进程”打印出书单。待读者交款之后，由“出售图书”控制类产生“售出图书”对象。

图6.17 “售书处理”的用例分析类图

图6.18 “售书处理”的用例分析交互图

2．“收书款”用例分析 1) 提取概念类 “收书款”用例的边界类是“收款界面”，实体类是“待售图书”，控制类是“核对书单”和“收书款”。“收书款”的概念类见图6.19。 2) 用例分析类图 “收书款”的用例分析类图见图6.20。

图6.19 “收书款”的概念类

图6.20 “收书款”的用例分析类图

3) 用例分析交互图 "收书款" 的用例分析交互图见图6.21。“收书款”用例的交互过程是：收款员把待售图书的书单号输入给“收款界面”，由“核对书单”控制类把接收的书单号与已产生的待售图书对象进行核对，如果核对无误就可以收款，否则将拒绝收款。接下来由“收书款”控制类在待售图书对象中登记已收款标记。

图6.21 “收书款”的用例分析交互图

6.5 概念类分析 6.5.1 职责分析 概念类的职责是概念类在信息系统中的责任和作用。分析概念类的职责应该注意四方面的问题： 6.5 概念类分析 6.5.1 职责分析 概念类的职责是概念类在信息系统中的责任和作用。分析概念类的职责应该注意四方面的问题： 第一，面向业务应用。 第二，具有概括性，不要过多陷入细节。 第三，全面分析。 第四，用自然语言描述。 下面我们分析图6.17中“书目”、“售书界面”、“产生待售图书”三个概念类的职责。

1)“书目”类 “书目”类是一个实体类，它参与多个用例。其职责是存放书店所能处理的所有图书的基本信息，并提供对图书基本信息的共性管理功能。 2)“售书界面”类 “售书界面”类是一个边界类，这个类仅出现在“售书处理”用例中。其职责是提供售书员和系统在销售图书时的交互界面。从该界面接收售书员输入的待售图书书号和册数信息，向售书员返回图书的相关信息。

3) “产生待售图书”类 “产生待售图书”类是一个控制类，也仅出现在“售书处理”用例之中。其职责是根据接收的待售图书书号，从“书目”类中取出该书号的图书信息，合成一个“待售图书”对象，放入到“待售图书”概念类中。

6.5.2 属性分析 1．属性的概念 从一般意义上讲，属性表示实体的特性或特征。在面向对象方法中，属性被定义为：属性用来表示对象的静态特性。

2．属性命名和类型 1) 属性的命名 (1) 使用名词或带定语的名词。像“姓名”，“学生姓名”，“型号”，“产品型号”，“商品条形码”等。 (2) 尽量使用问题域中规范、通用的词语，避免使用没有明确含义或自定义的词语。 2) 属性的类型 属性的类型是指属性值的类型，一般有数字型、字符型、逻辑型、日期型等。在系统分析阶段一般不需要确定属性的类型。

3．属性分析 属性分析需要分析人员与用户密切合作，认真分析业务领域和概念类的职责，确定出合适的概念类的属性。属性分析的一般途径有下述几种。 (1) 从常理上看，概念类所表示的事物有哪些静态特性。 绝大部分概念类，尤其是实体类是直接反映业务领域中具体事物的，分析人员首先可以从常理上理解该概念类所反映的事物应该有哪些静态特征，这样以便于确定概念类的属性。

(2) 在业务领域中概念类所具有的属性。 同一事物在不同的业务领域中，要求和突出事物的静态特性是不同的。例如，同一个人，在学校中作为学生时考虑其静态特征时，除了姓名、性别、出生年月、住址、电话等一般特性之外，还要考虑与学习有关的特性，如所修课程、各科成绩等。但在医院中作为病人，其特性除一般特性之外，还要反映病人的身体状况和病情状况，如血压、脉搏、体温、体重、饭量等。

(3) 信息系统要求概念类应具有的属性。 概念类的属性只有通过系统需求才能确定是否真正需要。从常理上所提出的属性和问题域的属性只能作为确定概念类属性的参考，只有通过对信息系统需求的分析，才能确定概念类所需要的属性。 (4) 概念类需要记录和保存的信息。 概念类需要记录和保存的信息应该作为概念类的属性。例如，产品的生产量是需要记录和保存的产品信息，就可以把产品生产量作为产品概念类的一个属性；学生所修课程成绩是需要保存的信息，学生所修课程成绩就可以作为学生概念类的一个属性。

(5) 不同类型概念类的属性。 ① 实体类。实体类属性的分析最为容易，可以直接根据事物本身的性质来确定。例如，对于“图书”属性，就可以通过对图书性质的分析来确定。 ② 边界类。可以根据边界类所承担的交互信息项目来确定边界类的属性。例如，对于“收款界面”边界类，输入的信息是“待售书号”和“书款信息”，输出的信息是“收款图书信息”和“已收款提示”，我们就可以把这四项信息项目作为“收款界面”的属性。与其它系统交互的边界类的属性，经常表示为通信接口的特性。

③ 控制类。控制类一般没有属性。 (6) 属性和类的转化。 如果一个类的某一属性项过于复杂，说明这个属性包容的内涵很丰富，属性本身就表示一个复杂的事物实体，可以把这个属性作为一个类来看待。如果一个类中因属性项目过多，使得类过于庞大，可以根据这些属性的相关性，把一个类分成多个类，以简化类的规模。

下面我们分析图6.20中“书目”、“售书界面”和“产生待售图书”三个概念类的属性。 ① “书目”类。根据“书目”类的职责，其属性应该有书号、书名、作者、出版社、单价、出版日期和图书类别。 ② “售书界面”类。“售书界面”类的属性有图书书号和图书信息。 ③ “产生待售图书”类。“产生待售图书”类是一个控制类，没有属性。

6.5.3 关系分析 概念类之间存在关联、聚合、泛化和依赖关系。对提取的各个概念类，分析并确定它们之间的相互关系。概念类之间必须是客观存在的关系，不能强加赋予。下面我们给出前面书店信息系统“售书处理”用例所提取的部分概念类之间所存在的关系，见图6.22。其中，“书目”与“架存图书”、“待售图书”和“售出图书”之间是泛化关系；“职工”与“售书员”和“收款员”之间也是泛化关系；“售书员”与“架存图书”、“待售图书”和“售出图书”之间是关联关系；“收款员”与“待售图书”之间也是关联关系。

图6.22 “售书处理”用例部分概念类之间的关系

6.5.4 确定通用概念类 有些概念类可能与多个分析包存在关联关系，这些概念类被称为通用概念类。对通用概念类有两种处理办法，一是把通用概念类放到通用分析包中，二是从分析包中分离出来，作为系统重点关注的独立概念类。通用概念类一般都是实体类。在图6.22中抽取的概念类中，“书目”应该是一个通用概念类。

6.5.5 特殊需求 提取的部分概念类可能会存在一些特殊的性能需求，在此，也需要捕捉这些特殊需求，以便在系统设计阶段进行考虑。例如，图6.23是“书目”概念类的特殊需求。

图6.23 “书目”类的性能要求 “书目”类的特殊需求： ● 范围：每个对象约100字节 ● 容量：最大为100 000 ● 容量：最大为100 000 ● 更新频率：创建/删除：50次/天, 更新：创建后一般不更新, 读取：访问50次/小时 图6.23 “书目”类的性能要求

6.5.6 概念类字典 概念类字典(Conception Class Dictionary)用来记录系统分析中提取的概念类，并对概念类进行说明。概念类字典由概念类目录和概念类条目两部分构成。在概念类目录中，按照确定顺序列出概念类名和概念类条目编号，一般按照实体名的汉语拼音字母顺序编排。概念类条目是对各概念类的详细描述，一个概念类对应一个概念类条目。在概念类条目中，应该描述概念类条目编号，概念类名，职责，属性，说明和特殊需求。下面给出书店信息系统的部分概念类字典。

1．概念类目录 书店信息系统概念类目录见表6-1。目录中列出了书店信息系统逻辑模型中的部分概念类。概念类条目编号的规则是：第1位表示该概念类的顶层分析包，用字母表示。其中，A表示计划订购，B表示书库管理，C表示图书销售，D表示事务处理，Q表示公用概念类。第2位是概念类的类型。其中，1表示实体类，2表示边界类，3表示控制类。后两位是顺序号。例如，C-2-01表示“售书界面”属于“图书销售”分析包中界面类的第一个概念类。

表6-1 书店信息系统概念类目录 概念类名 说 明 条目编号 页号 售书界面 售书员与系统的交互界面 C–2–01 产生待售图书 表6-1 书店信息系统概念类目录 概念类名 说 明 条目编号 页号 售书界面 售书员与系统的交互界面 C–2–01   产生待售图书 产生待售图书类 C–3–01 开书单 打印书单 C–3–02 出售图书 把待售图书转变为售出图书 C–3–03 书目 图书的基本信息 Q–1–01 架存图书 书架上存放的图书 C–1–01 待售图书 等待销售的图书 C–1–02 售出图书 销售出去的图书 C–1–03 …

2．概念类条目 概念类条目应该包括每一个概念类的编号，概念类名，职责，属性，说明，特殊需求等信息。在此，我们以“书目”概念类为例，说明概念类条目的编制方法，见图6.24。

图6.24 概念类字典例子 编号：Q-1-01 概念类名：书目 职责：存放书店所能处理的所有图书的基本信息 属性：书号，书名，作者，出版社，单价，出版日期，图书类别 说明：该概念类中存放所有图书类的公用信息。它是“采购图书”、“入库图 书”、“库存图书”、“出库图书”、“盘存图书”、“报损图书”，“架存 图书”、“待售图书”、“售出图书”等概念类的公共超类 特殊需求： ● 范围：每个对象约100字节； ● 容量：最大为100000； ● 更新频率：创建/删除：50次/天， 更新：创建后一般不更新， 读取：访问50次/小时 图6.24 概念类字典例子