请简要说明建模的意义和建模的原则。

参考答案：B

正确答案：用例建模描述各种参与者(人和其他系统)和系统之间的主要交互。用例建模可以描述利益相关者(例如用户和维护人员)所看到的系统行为。 组件建模确定系统的子系统、模块和组件结构为子系统、模块分配需求和职责每个组件元素作为一个自包含的单元用于开发、部署和执行。服务建模提供了通用的应用程序并将应用程序定义为一组抽象服务接口。 性能建模是对系统的性能进行度量为每个组件确定性能指标。包括执行时间、资源使用、开发复杂性和维护复杂性等质量属性。
用例建模描述各种参与者(人和其他系统)和系统之间的主要交互。用例建模可以描述利益相关者(例如，用户和维护人员)所看到的系统行为。 组件建模确定系统的子系统、模块和组件结构，为子系统、模块分配需求和职责，每个组件元素作为一个自包含的单元，用于开发、部署和执行。服务建模提供了通用的应用程序，并将应用程序定义为一组抽象服务接口。 性能建模是对系统的性能进行度量，为每个组件确定性能指标。包括执行时间、资源使用、开发复杂性和维护复杂性等质量属性。

正确答案:B

答案：C

解析：

答案：C

解析：

正确答案：C
解析：用例图用于对系统的静态用例视图进行建模。这个视图主要支持系统的行为，即该系统在它的周边环境的语境中所提供的外部可见服务。当对系统的静态用例视图建模时，可以用下列两种方式来使用用例图。(1)对系统的语境建模对一个系统的语境进行建模包括围绕整个系统画一条线，并声明有哪些参与者位于系统之外并与系统进行交互。在这里，用例图说明了参与者及其所扮演的角色的含义。(2)对系统的需求建模对一个系统的需求进行建模，包括说明这个系统应该做什么(从系统外部的一个视点出发)，而不考虑系统应该怎样做。在这里，用例图说明了系统想要的行为，通过这种方式，用例图使我们能够把整个系统看作一个黑盒子。你可以观察到系统外部有什么，系统怎样与那些外部事物相互作用，但却看不到系统内部是如何工作的。

正确答案：D
解析：活动图(ActivityDiagram)是一种特殊的状态图，它展现了在系统内从一个活动到男一个活动的流程。活动图专注于系统的动态视图，它对于系统的功能建模特别重要，并强调对象间的控制流程。活动图一般包括：活动状态和动作状态、转换和对象。当对一个系统的动态方面建模时，通常有两种使用活动图的方式。(1)对工作流建模此时所关注的是与系统进行协作的参与者所观察到的活动。工作流常常位于软件系统的边缘，用于可视化、详述、构造和文档化开发系统所涉及的业务过程。在活动图的这种用法中，对对象流的建模是特别重要的。(2)对操作建模。此时是把活动图作为流程图使用，对一个计算的细节部分建模。在活动图的这种用法中，对分支、分叉和汇合状态的建模是特别重要的。用于这种方式的活动图语境包括该操作的参数和它的局部对象。

正确答案：依赖关系：有两个元素A、B如果元素A的变化会引起元素B的变化则称元素B依赖于元素A。 概括关系：描述一般事物与该事物中的特殊种类之间的关系也就是父类与子类之间的关系。 关联关系：表示两个类的实例之间存在的某种语义上的联系。 聚集关系：表示一种整体和部分的关系。 聚集关系是关联关系的特例它是传递和反对称的。
依赖关系：有两个元素A、B，如果元素A的变化会引起元素B的变化，则称元素B依赖于元素A。 概括关系：描述一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。 关联关系：表示两个类的实例之间存在的某种语义上的联系。 聚集关系：表示一种整体和部分的关系。 聚集关系是关联关系的特例，它是传递和反对称的。 解析：图13-8是一个UML的用例图。在工程的分析阶段，用例图被用来鉴别和划分系统功能，它们把系统分成动作者(actor)和用例。
动作者(actor)表示系统用户能扮演的角色(role)。这些用户可能是人，可能是其他的计算机、一些硬件或者是其他软件系统。判断它们的唯一标准是它们必须要在被划分进用例的系统部分以外。它们必须能刺激系统部分，并接收返回。
用例描述了当动作者之一被系统特定地刺激时系统的活动。这些活动用文本来描述，即描述了触发用例的刺激的本质，输入和输出到其他活动者，以及转换输入到输出的活动。用例文本通常也描述每一个活动在特殊的活动线时可能的错误和系统应采取的补救措施。
图中的网络用户、公司客户、管理人员都是动作者。题目说明中提到了系统有4个功能：浏览客户信息、登录、修改个人信息、删除客户信息。这也就是4个用例，我们现在只需把它们对号入座即可。根据题目说明，我们可以知道任何使用Internet的网络用户都可以浏览电话公司所有的客户信息，在图中符合这一条件的只有A了，所以A应填浏览客户信息。又因为只有公司的管理人员才能删除不再接受公司服务的客户的信息，所以D应填删除客户信息。
剩下就只有登录和修改个人信息两个用例了，那么B究竟是填登录还是修改呢?我们先来看包含和扩展的概念。
两个用例之间的关系可以主要概括为两种情况：一种是用于重用的包含关系，用构造型include＞＞表示；另一种是用于分离出不同行为的扩展关系，用构造型extend＞＞表示。
包含关系：如果可以从两个或两个以上的原始用例中提取公共行为，或者发现能够使用一个构件来实现某一个用例的部分功能是很重要的事，则应该使用包含关系来表示它们，如图13-35所示。

扩展关系：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种事情，我们将这个用例分为一个主用例和一个或多个辅用例来描述可能更加清晰，如图13-36所示。

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

答案：

解析：

答案：C

解析：