阅读下列说明以及图4－4和图4－5,回答问题1、问题2和问题3,将解答填入答题纸的对应栏内。 [说明] 某

Question

阅读下列说明以及图4-4和图4-5，回答问题1、问题2和问题3，将解答填入答题纸的对应栏内。

[说明]

某电话公司决定开发一个管理所有客户信息的交互式网络系统。系统的功能如下。

1．浏览客户信息：任何使用因特网的用户都可以浏览电话公司所有的客户信息(包括姓名、住址、电话号码等)。

2．登录：电话公司授予每个客户一个账号。拥有授权账号的客户，可以使用系统提供的页面设置个人密码，并使用该账号和密码向系统注册。

3．修改个人信息：客户向系统注册后，可以发送电子邮件或者使用系统提供的页面，对个人信息进行修改。

4．删除客户信息：只有公司的管理人员才能删除不再接受公司服务的客户的信息。系统采用面向对象方法进行开发，在开发过程中确定的类如表4-3所示。

表4-3 开发过程中确定的类

在需求分析阶段，采用UML的用例图(use case diagram)描述系统功能需求，如图4-4所示。指出图中的A,B,C和D分别是哪个用例?

Answer 1

正确答案：A：浏览客户信息；B：修改个人信息；C：登录；D：删除客户信息。
A：浏览客户信息；B：修改个人信息；C：登录；D：删除客户信息。 解析：图4-4是一个UML的用例图。在工程的分析阶段，例图被用来鉴别和划分系统功能，它们把系统分成动作者(actor)和用例。
动作者(actor)表示系统用户能扮演的角色(role)。这些用户可能是人，可能是其他的计算机、一些硬件或者是其他软件系统。惟一的标准是它们必须要在被划分到用例的系统部分以外。它们必须能刺激系统部分，并接收返回。
用例描述了当某个动作者给系统特定的刺激时系统的活动。这些活动被文本描述。它描述了触发用例的刺激的本质，输入和输出到其他活动者，转换输入到输出的活动。用例文本通常也描述每个活动在特殊的活动线时可能的错误，以及系统应采取的补救措施。
了解用例图、动作者、用例的基本概念后，题目就迎刃而解了。图中的网络用户、公司客户、管理人员都是动作者。题目说明中提到了系统有4个功能：浏览客户信息、登录、修改个人信息、删除客户信息。这也就是4个用例。现在只需把他们对号入座即可。根据题目说明，可以知道任何使用Internet的网络用户都可以浏览电话公司所有的客户信息，在图中符合这一条件的只有A，所以A应填浏览客户信息。。因为只有公司的管理人员才能删除不再接受公司服务的客户的信息。所以D应填删除客户信息。
剩下只有登录和修改个人信息2个用例了，那么究竟是B填登录还是修改呢?先介绍包含和扩展的概念。
2个用例之间的关系可以主要概括为2种情况：一种是用于重用的包含关系，用构造型《include》表示；另一种是用于分离出不同的行为，用构造型《extend》表示。
(1)包含关系：如果可以从2个或2个以上的原始用例中提取公共行为，或者发现能够使用一个构件来实现某一个用例的部分功能时，应该使用包含关系来表示它们。示意图如图4-6所示。
(2)扩展关系：如果一个用例明显地混合了2种或2种以上的不同场景，即根据情况可能发生多种事情。可以断定将这个用例分为一个主用例和一个或多个辅用例描述可能更加清晰。示意图如图4-7所示。
因为要先登录才能修改信息，显然B应填修改个人信息，C应填登录。

在UML中重复度(multiplicity)又称多重性，多重性表示为一个整数范围n...m，整数n定义所连接的最少对象的数目，而m则为最多对象数(当不知道确切的最大数时，最大数用*号表示)。最常见的多重性有0...1，0...*，1...1，1...*。
因为1个CustomerList的实例可以与0个或多个Customer的实例相关联；而1个 Customer的实例只能与1个CustomerList的实例相关。所以(1)空应填1，(2)空应填 0...*。因为Customer是CompanyCustomer的相应的详细信息，所以(3)空和(4)空都应该填写0...1。
用UMI建立业务模型时，可以把业务人员看作是系统中的角色或者类。在建立抽象模型时，很少有类会单独存在，大多数都将会以某种方式彼此通信，因此还需要描述这些类之间的关系。关系是事物间的连接，在UML中，有几个很重要的关系。
(1)依赖关系
有2个元素A和B，如果元素A的变化会引起元素B的变化，则称元素B依赖(depend ency)于元素A。
在类中，依赖关系有多种表现形式，例如，一个类向另一个类发消息；一个类是另一个类的成员；一个类是另一个类的某个操作参数等。
(2)概括关系
概括关系(generalization)，也称为泛化关系，描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说子类是从父类中继承的，而父类则是子类的泛化。在UML中，对泛化关系有3个要求：
①子类应与父类完全一致，父类所具有的关联、属性和操作，子类都应具有。
②子类中除了与父类一致的信息外，还包括额外的信息。
③可以使用子父类实例的地方，也可以使用子类实例。
(3)关联关系
关联(association)表示2个类的实例之间存在的某种语义上的联系。例如，一个老师为某个学校工作，一个学校有多间教室。可以认为老师和学校、学校和教室之间存在着关联关系。
关联关系为类之间的通信提供了一种方式，它是所有关系中最通用、语义最弱的。关联关系通常可以再细分成以下几种。
①聚集关系：聚集关系(aggregation)是关联关系的特例。它表示一种整体和部分的关系。如一个电话机包含一个话筒，一个计算机包含显示器，键盘和主机等都是聚合关系的例子。
②组合关系：如果聚集关系中的表示“部分”的类的存在与表示“整体”的类有着紧密的关系，例如，“公司”与“部门”之间的关系，那么就应该使用组合关系来表示。