《软件工程-理论、方法与实践》课件第5章

第5章面向对象的分析5.1面向对象分析的概念5.2基于UML的需求分析5.3案例本章小结习题

5.1面向对象分析的概念

在面向对象的软件工程方法中，将软件系统问题看作是现实世界应用域问题的映射。客观世界中的系统依赖于实体和它们之间的协作，面向对象的软件系统则依赖于类和对象之间的协作。因此面向对象的分析方法的目标是将客观世界的实体转换为软件系统中的类和对象以及对象之间的协作模型。

面向对象的分析过程是找出分析类、分析包，构建它们之间的静态关系和动态协作模型的过程。5.1.1分析类

在对象分析模型中，分析类是概念层次上的内容，用于描述系统中较高层次的对象。在分析阶段，分析类直接与应用逻辑相关，而不关注纯粹的技术实现问题。分析类代表了系统设计中的一个或几个类或若干个子系统的抽象。这种抽象具有如下特点：

(1)分析类侧重于处理功能性需求，而把非功能性需求推迟到后续的设计与实现活动中再实现。这使得分析类在问题域语境中更加突出、更加“概念化”，而且与其对应的设计与实现类相比具有更大的粒度。

(2)分析类很少根据操作及其特征标记来定义或提供接口，而是通过较高的、非形式化层次的职责来定义其行为。职责是对由类定义行为的内聚子集的文本描述。

(3)分析类定义属性，但这些属性还处于较高的层次。通常这些属性的类型是概念性的，而且应从问题领域来考虑；而设计和实现类的属性类型通常就是程序设计语言的类型。而且分析期间定义的各种属性通常在设计和实现阶段对应各种类。

(4)分析类涉及到关系，这些关系和设计与实现阶段的对应部分相比更加概念化。例如，关联的导航性在分析中并不十分重要，但在设计时却是必需的。又如，可以在分析中使用泛化，但在设计阶段如果得不到程序设计语言的支持就无法使用泛化。

(5)从软件的功能需求来看，分析类可以划分成实体类、边界类和控制类三种类型。

●实体类：表示系统存储和管理的永久信息。

●边界类：表示参与者与系统之间的交互。

●控制类：表示系统在运行过程中的业务控制逻辑。

分析类在UML中可以用一般的类符号来表示，也可以用简化的形式。在UML语言中，使用构造型<<entity>>、<<boundary>>和<<control>>分别表示实体类、边界类和控制类。图5.1给出了UML构造型表示的三种分析类。这三种构造型在UML中已经标准化，并已用来帮助开发人员区别对待不同的类。每种构造型都有自己的符号。图5.1三种分析类在图5.2中，ATMCard是一个实体类，表示用户的ATM卡信息；DisplayScreen，表示ATM的界面显示类；CardScanner是一个控制类，表示控制银行卡操作的业务逻辑类。图5.2实体类、边界类和控制类实例

1．边界类

图5.3为“取款用户界面”的边界类，用于支持“银行客户”参与者和“现金取款”用例的交互。

“取款用户界面”允许银行客户输入取款的金额，验证金额数目是否大于银行客户账户的当前金额数目，然后由系统向用户支付现金。图5.3“取款用户界面”边界类

2．控制类

图5.4引入一个ATM系统中“打印调度程序”的控制类，它负责控制和协调“取款账单打印用户界面”边界类和“取款账单”实体类之间的打印。

“打印调度程序”接受打印请求和要打印的当前账单，然后完成打印任务。图5.4“打印调度程序”控制类及它与边界类、实体类的关系

3．实体类

实体类用于对长效且持久的信息建模。实体类主要是对客观世界中的个体、实际对象、实际事件的某些现象或概念的信息及相关行为进行建模。

大多数情况下，实体类可以直接从问题域中客观世界存在的业务实体得到，例如可以将账单、银行账户、学生等实体抽象为实体类Bill、Account和Student。实体类的属性通常是表征该实体的一些特征信息，如对于一个银行Account类来说，银行账号、持有人、密码、联系地址、账户类型等现实世界的账户信息可以被抽取为Account类的属性，而对该账户的相关操作，如刷卡、更改密码等，则可抽象为Account操作/方法。5.1.2用例实现

用例实现可以用静态的结构和动态的协作模型来描述。可以是以文本的形式描述事件流的脚本、描述用例实现所涉及的分析类的类图、描述实现用例的对象间的交互协作的顺序图或协作图。如我们在3.5节中给出的关于在线下载的用例实现采用了顺序图。图5.5试图用UML模型给出用例、用例实现之间的关系。图5.5用例与用例实现5.1.3分析包

在UML模型中，包是一种分类事务，分析包是需求分析阶段的另一个产出元素。分析包提供了一种方法，用管理分块的方式对分析模型进行组织。分析包可以包括分析类、用例实现及其他分析包。分析包应该具有强内聚性和弱耦合性，即它们所包含的元素应该紧密相关且彼此间的依赖性应尽可能小。利用分析包可以对较大的系统进行划分，一般分析包应基于功能性需求与问题领域来构建，并且应能被具有该领域知识的人所理解，如系统用户。如对一个ATM系统，可根据其应具有的几大功能来创建和划分分析包。用例模型也可以作为分析包产生的基础。

分析包可以为此后的体系结构设计提供基础，很可能成为体系结构设计模型中的子系统，或分布在一些子系统中。5.1.4分析模型

分析模型是需求分析阶段需要构建的模型，包括分析类、分析包及它们之间的关系模型，还包括用例实现。分析模型可以用图5.6所示的UML模型来描述。分析模型是分析制品(product)的聚合，而分析制品则是分析类、用例实现及分析包的组合；分析包也由分析类、用例分析或分析包组合而成。图5.6分析模型组成结构

5.2基于UML的需求分析

本节将结合第4章的自动取款机ATM系统对用例进行分析，讨论系统分析模型的建立。分析的主要目标是：

(1)确定分析类及其对象要执行用例的事件流。

(2)将用例的行为分配给相交互的分析对象，定义交互行为。5.2.1确定分析类

以下是确定分析类的一般性准则：

(1)为每个由人充当的参与者确定一个主要边界类，并使这个类代表与参与者相交互的用户界面中的主窗口。

(2)通过详细研究问题域和用例说明来确定实体类，主要对象是用例实现中需要涉及和处理的实体。

(3)为每个初期建立的实体类确定一个基本边界类。

(4)为每个由外部系统充当的参与者定义一个主要边界类，使其代表通信接口。

(5)确定一个控制类，负责处理用例实现中的控制和协调关系，然后按照用例实现的需求对该控制类进行精化。

(6)对分析模型中业已存在的分析类加以考虑，确定是否有可重用的分析类，确定参与多个用例实现的分析类。

(7)为参与用例实现的分析类建模类图，并使用这个类图表明用例实现中所用到的关系。

1．识别边界类

用例模型给出了参与者和用例之间的交互关系，因此可以将一个参与者与一个用例之间的交互或通信关联映射为一个边界类。如图5.7示意，用户和用例之间可以识别出一个边界类，即用户界面类已可以实现用户与系统的交互，而外部系统和用例之间可以产生一个边界类作为本系统与外部系统的接口类。图5.7边界类的识别

2．识别控制类

控制类负责协调边界类和实体类，通常在现实世界中没有对应的事物，由于一个用例表明一个系统应完成的功能和行为，需要一个控制逻辑实现用例，因此可以初步将一个用例对应一个控制类，如图5.8示意。图5.8控制类的识别

3．识别实体类

实体类通常是用例中的参与对象，对应着现实世界中的实体或事物。如物理存在的事物(汽车、报表、银行卡)，人或角色(学生、职员、教授)，机构(部门、学校、公司)，物理设备(打印机、扫描仪、刷卡机)，事件或行为(支付、订单、登录等)。

实体类的识别可以借助于需求描述中的自然语言文本，文本中的名词可以作为类和属性的候选，而动词则可以作为方法和操作的筛选对象。

综合上述原则和方法，我们可以识别出ATM系统的分析类，如表5.1、5.2所示。另外，识别边界类应当注意的问题有以下几点：

(1)边界类应关注参与者与用例之间交互的信息或者响应的事件，不要描述窗口组件等界面的组成元素。

(2)在分析阶段，力求使用用户的术语描述界面。

(3)边界类实例的生命周期并不仅限于用例的事件流，如果两个用例同时与一个参与者交互，那么他们有可能会共用一个边界类，以增加边界类的复用性。识别控制类应当注意的问题有以下几点：

(1)当用例比较复杂时，特别是产生分支事件流的情况下，一个用例可以有多个控制类。

(2)在有些情况下，用例事件流的逻辑结构十分简单，这时没有必要使用控制类，边界类可以实现用例的行为。例如ATM系统中的用例“登录”。

(3)如果不同用例包含的任务之间存在着比较密切的联系，则这些用例可以使用一个控制类，其目的是复用相似部分以降低复杂性。通常情况下，应该按照一个用例对应一个控制类的方法识别出多个控制类，再分析这些控制类，找出它们之间的共同之处。识别实体类应当注意的问题有以下几点：

(1)实体类的识别质量在很大程度上取决于分析人员书写文档的风格和质量。

(2)自然语言是不精确的，因此在分析自然语言描述时应该规范描述文档中的一些措辞，尽量弥补这种不足。

(3)在自然语言描述中，名词可以对应类、属性或同义词等多种类型，开发人员需要花费大量的时间进行筛选。5.2.2建模分析对象间的交互

在确定分析类后，就需要描述对应的分析类间的交互与协作，这实际是精化用例为用例实现的过程。建模一般需要描述分析类间的静态协作和动态交互关系，静态协作一般用类图描述，将在5.2.3节中讨论。动态交互关系则倾向于用顺序图和协作图来表示。顺序图聚焦对象间的交互顺序，而协作图则突出对象间的协作关系。由于在前面的章节中，已采用顺序图来说明用例实现，且分析阶段倾向于描述用例涉及对象间的协作和职责，因此这里重点关注协作图展开的用例实现。对于创建协作图应该注意以下几点：

(1)一个参与者实例向一个边界对象发送一个消息则将引入一个用例实现。

(2)每个确定的分析类至少有一个分析对象参与某个协作图。否则，由于该分析类不参加任何用例，因此它是多余的。

(3)不要将消息指定给操作，因为分析类尚未确定操作。消息应该表示出应用对象和被应用对象交互时的目标和目的，这往往是消息接收对象确立操作和方法的依据，甚至可能成为方法的名称。例如在图5.9中传给对象CS：CardScanner的消息(1.接受银行卡)，实际表明了CS：CardScanner应该具有接受银行卡的操作和方法。图5.9ATM系统对象协作图

(4)图中的链接一般应是分析类间关联的实例，应标出所有可见的关联，还应反映在与用例实现有关的类图中。

(5)图中的次序不应作为主要的关注点，并且当它难以维护或者造成图的混乱时，可以考虑将它去掉，而对象和对象间的消息应该是主要的关注点。

(6)协作图应该处理所实现的用例中的所有关系。例如，如果用例A是用例B的泛化，则实现用例A的协作图需要引用用例B的实现，即引用它协作图。下面的文本描述补充说明了图5.9中的协作图：

(1)银行客户(BankCustomer)插卡后，卡扫描器(CardScanner)读卡；

(2) ATM机的显示器(DisplayScreen)显示密码输入界面，银行客户(BankCustomer)输入密码后，由ATM机的显示器(DisplayScreen)接受密码并通知扫描器(CardScanner)对密码进行验证；

(3)卡扫描器(CardScanner)通过ATM卡(ATMCard)获取密码完成验证并读取ATM卡的账户信息；

(4)在ATM机的显示器(DisplayScreen)上显示银行客户能够对该卡进行操作的相关功能界面；

(5)银行客户(BankCustomer)选择“取款”，由ATM机的显示器(DisplayScreen)接受用户的处理选择，并由Transaction对象进行具体的处理；

(6)在ATM机的显示器(DisplayScreen)上提示银行客户输入取款数额，由Transaction对象读取账户的结算信息并通知Account对象检查取款总数(如果取款数额大于账户余额，由ATM机的显示器提示此信息，否则继续下面的操作)；

(7)由Transaction对象计算账户余额，之后Account对象对之前时间段的利息进行计算并更新账户信息；

(8)由CashDispenser对象向银行客户提供现金和取款凭证。5.2.3构建分析类图

分析类图用以描述类与类之间的静态结构关系，构建分析类图包括：

●依据分析类在用例实现中的角色来确定它的职责。

●确定分析类的属性及其关系。

●捕获该分析类实现的特殊需求。

1．确定职责

类的职责是指类应该具有的行为集合，设计阶段可依据职责定义类的方法或操作。可以通过组合一个类在不同用例实现中所充当的所有角色来整合该类的职责。通过研究它们的类图和交互图可以确定该类参与的所有用例实现。另外，类的每个用例实现的需求，有时是在用例实现的事件流分析中用文本来描述的。

2．确定属性

属性详细说明了分析类的特性，它通常由类的职责直接或间接决定。在确定属性时，应记住以下一般性的原则：

(1)属性的名称应该是一个名词。

(2)属性的类型在分析阶段应该是概念上的，并且如果可能的话，它们不应受到实现环境的限制。例如，分析阶段中的“数量”可能是一种合适的类型，而设计阶段中它所对应的类型应该是“整型”。

(3)在选择一种属性类型时，尽量采用已存在的类型。

(4)一个简单的属性实例不能由多个分析对象共享。如果需要这样，属性要在它自己的类中进行定义。

(5)如果一个分析类由于自己的属性变得过于复杂而难于理解，可以将其中的一些属性分成它们自己的类。

(6)实体类的属性通常很明显，一般对应实体的一些自然特征，如学生实体具有姓名、性别、年龄、身高、主修专业等属性。如果一个实体类可以追踪到一个领域类或一个业务实体类，这些类的属性可作为重要的参考。

(7)如参与者是人进行交互的边界类，其属性经常表示由该参与者所操作的信息项，如带标记的文本域。

(8)如参与者是一个系统进行交互的边界类，其属性经常表示通信接口的特性。

(9)控制类由于其生命周期短暂，因此很少具有属性。然而在用例实现期间，控制类可能会有代表聚合或派生价值的属性。

(10)有时并不需要形式化的属性。相反，对由分析类处理的特性进行简单说明就足够了，并且还可将它放到该类的职责描述中。

(11)如果一个类具有很多属性或复杂属性时，可以在一个只显示属性栏的单独类图中加以说明。

3．确定关联和聚合

分析对象通过协作图中的链接彼此进行交互。这些链接通常是分析对象的相应类之间关联的实例。因此，应该研究这些用于协作图中的链接以便确定需要哪些关联。这些链接可以表明对象间所需的引用和聚合。

类之间的关系数目应尽量少，类之间的关系并非完全是现实世界中那种能作为聚合或关联关系，而是为了影响各种用例实现的需求而必须存在的那种关系。同时还有必要定义关联的多重性、角色名称、自关联、有序角色、限定角色和n元关联。当对象表示以下事物时应该使用聚合：

(1)实际中相互包容的概念，如汽车包含驾驶员和乘客。

(2)相互间存在组成关系的概念，如汽车由发动机和车轮等部件组成。

(3)构成对象的概念性集合的概念，如家庭由父亲、母亲和孩子组成。

以ATM系统为例建立实体类之间的关系，如图5.10所示。图5.10ATM系统的类图

4．确定泛化

在分析阶段，从几个不同的分析类中抽取共享和共用的行为时应该使用泛化。泛化应处于较高的概念层，其目的是使分析模型易于理解。

如图5.10所示，CurrentAccount(当前账户)和SavingsAccount(储蓄账户)具有相似的职能，二者都是更一般对象Account(账户)的特化。

在设计阶段，应该对泛化关系进行调整，以便更好地适应所选的实现环境，如程序设计语言。泛化有可能消失，而变为其他关系(如关联)来实现。

5．捕获特殊需求

进行这项活动时，要研究用例实现的特殊需求，因为它们可能包含了与分析类有关的补充(非功能性的)需求。

例如，在对用户输入的密码进行验证的时候，最多允许用户输入三次密码，如果用户输入三次密码都是错误的，用户只能用自己的开户证件通过柜台修改自己的密码。

根据以上分析，可以找出图5.10中分析类的部分重要属性，从而得到ATM系统的分析类图，如图5.11所示。图5.11ATM系统定义属性的分析类图

5.3案例

本小节针对第4章的“理财管理系统iricher”给出了面向对象分析模型。

1．确定分析类

通过对“理财系统iricher”进一步地理解分析，识别出系统的实体类如表5.3所示，控制类如表5.4所示，系统界面部分计划采用JSP技术实现，暂时不考虑边界类。

2．描述分析对象之间的交互

“理财系统iricher”中的每个功能基本相似。如“日常收支管理”，为用户提供日常收支的录入、查询、删除等功能。其他也都是相关信息的增、删、改等功能，用例流相对比较简单。此处以“预算管理”中的增加预算为例，描述该用例中的哪些对象参与交互，如图5.12所示。图5.12iricher系统“增加预算”协作图图5.12中的交互文本描述如下：

(1)注册用户登录后进入“增加预算”页面。

(2)输入新的预算信息。

(3)输入结