1、8.8 类图,面向对象方法的三个最重要的技术是用例图、类图和交互模型。 无论是面向对象的分析还是面向对象的设计和实现，类图都是最核心技术。它不仅能够表现信息的结构，还能够反映系统的行为。,事实上，软件开发不同时期的类图反映了不同层次上的抽象。 在需求分析阶段，类图用于研究领域的概念，主要反映实体类和界面类； 在设计阶段，类图描述类与类之间的接口和控制； 在实现阶段，类图描述系统中类的具体实现。,8.8.1 类的表示和获取,类是包含信息和影响信息行为的逻辑元素。类的符号是由三个格子的长方形组成，有时下面两个格子可以省略。 最顶部的格子包含类的名字，类的命名应尽量用应用领域中的术语，有明确的含义，
2、以利于开发人员与用户的理解和交流。中间的格子说明类的属性。最下面的格子是类的操作行为。,类图,类的获取是一个依赖于人的创造力的过程。 实践中，寻找类有两种办法：一种是从用例的描述开始，检查用况描述中的每个名词。 另一种是检查顺序图中的对象，研究对象具有的共同属性和操作来发现类。 注意，并不是所有的类都能够从工作流和交互图中找到。,8.8.2 类的属性,属性是与类相关联的信息，描述该类对象的共同特点。例如，“客户”类有“客户名”、“地址”、“电话”等属性。 属性的来源： 通过查找用例文档寻找名词； 通过查看需求文档发现系统要收集的信息，这些信息就是类的属性 如果已经定义了数据库结构，则字段就是属
3、性。,属性的选取应考虑以下因素:,原则上来说,类的属性应能描述并区分每个特定的对象; 只有系统感兴趣的特征才包含在类的属性中; 系统建模的目的也会影响到属性的选取。 每条属性都能回溯到用户的需求； 类的属性不宜太多了。,属性的语法,UML规定类的属性的语法为: 可见性 属性名 : 类型 = 缺省值 约束特性 图1“客户“类中,“客户名“属性描述为“- 客户名 : 字符串 = 缺省客户名“。 可见性 “-“表示它是私有数据成员,其属性名为“客户名“,类型为“字符串“类型,缺省值为“缺省客 户名“,此处没有约束特性。 不同属性具有不同可见性。常用的可见性有Public、Private和Protec
4、ted三种,在U ML中分别表示为“+“、“-“和“#“。,属性的类型,属性的类型可以是基本数据类型，例如整数、实数、布尔型、字符串型等，也可以是用户自定义的类型。一般它由所使用的程序设计语言确定。 约束特性则是用户对该属性性质一个约束的说明。例如“只读”说明该属性是只读属性。,8.8.3 类的操作,操作是与类相关的行为，用于修改、检索类的属性或执行某些动作。 操作通常也被称为功能，但是它们被约束在类的内部实现，只能作用到该类的对象上。,寻找类的操作,寻找类的操作比较简单，实际上，在创建交互图时，就在寻找类的操作。 在识别类的操作时，下面几个问题有助于寻找类的操作：,识别类的操作,1)有哪些类
5、会与该类交互，包括该类本身？ 2)该类接收哪些类（包括自己）发送的消息，收到消息之后进行什么处理？ 3)该类向哪些类发送消息，消息的内容是什么，在发送消息之前该类需要做什么处理？ 4)该类中需要哪些操作来维持自身属性的一致性、完整性，以及自身属性的更新？ 5)系统是否需要该类具有另外一些职责？,类的操作类型,实现功能的操作，称为实现者操作。用于实现功能，对应于顺序图的每个消息。 管理对象创建和删除的操作 访问属性的操作 辅助一个类完成自身任务的操作,描述类的操作,在类图中，描述类的操作分三个部分：操作名、返回类型和参数表。 在UML中描述操作的信息有五个部分:可见性 操作名 (参数表) : 返
6、回类型 约束特性。 常见的操作可见性有Public、Private和Protected三种，在UML类图中分别表示为“+”、“-”和“#”。,描述类的操作,“客户”类中有“取客户地址”的操作，它在UML中表现形式如下： +GetAddr（CustomerNo：String）：String 其中“+” 表示该操作是公有操作，GetAddr是操作名，调用时需要参数“CustomerNo”，操作的返回类型也为字符串，约束特征被省略了。,8.8.4 类的关系,类之间的关系有关联关系、组成关系、泛化关系。 要寻找关系，可以检查交互图，大多数关系信息已经在交互图中列出，重温这些图，获得类之间的关系。,寻找
7、关系的具体方法,首先检查交互图，如果一个类向另一个类发出消息，则他们必有关系，通常是关联或依赖关系； 检查类的整体和部分关系。 检查类的泛化关系，寻找相似对象的不同点，将不同点的部分下降为特殊类，将共同的部分上升为基础类，二者为泛化关系。 检查其它类，发现不同类中的共同点，将共同点放入另一个类，二者为泛化关系。,.关联关系,关联关系是类(也可以说是对象)之间特定的对应关系。描述类之间的一种语义联系，是对具有共同结构特征，行为特性，关系和语义的描述； 按照对象的数量对比，可以分为：A 一对一 比如公民和公民身份卡之间的对应关系。,关联关系,B 一对多 一个部门对应0或者多位员工，一般而言一位员工
8、只能属于某一个部门。,关联关系,C 多对多用户和服务是多对多的关系，一个用户可以注册0个或多个服务，一个服务则可以被0个或者多个用户复用。比如Windows Live用户可以激活邮件服务、Space服务等，而这些服务不是被一个用户所专有的。,关联关系,关联类即是关联也是类，它不仅像关联那样连接两个类，而且还可以定义一组属于关系本身的特性 ,2.聚集和组成,聚集：一种特殊的关联，表示类之间整体与部分之间的关系聚集 用空心菱形表示。 组成：表示的也是整体与部分的关系，但组合关系中的整体与部分存在同样的生存期。组成 用实心菱形表示。,举例,Polygon,Point,1,3*,points,Cont
9、ains,Polygon,Window,Slider,1,2,Scrollbar,Header,1,Title,1,1,Panel,1,Body,聚集,组合,关系,3.泛化关系,泛化就是一般化、概括或总结。父类是对子类的泛化，另一方面看，子类是对父类的继承。 泛化关系是类之间的一种比较提倡的关系，可以提高系统开发效率，增加系统的可理解性和可维护性。 设计泛化关系时，如果上层类具有不同类型的下层类，可以从上向下建立继承结构。,4.依赖关系,依赖是一种弱关联，只要一个类用到另一个类，但是和另一个类的关系不是太明显的时候（可以说是“uses”了那个类），就可以把这种关系看成是依赖，依赖也可说是一种偶
10、然的关系，而不是必然的关系，就是“我在某个方法中偶然用到了它，但在现实中我和它并没多大关系”。,8.8.5 类的版型,类的版型可以将类进行分类，并且有助于理解每个类的责任，例如，Form版型的类负责向用户显示信息和接收用户信息，不同版型的类具有不同的职责。 分析过程中，可以根据功能将类分为实体类、边界类和控制类。,类的版型,边界类位于系统于外界的交界处，包括所有的窗体、报表、系统硬件接口、与其它系统的接口。,类的版型,实体类实体类保存要存入永久存储体的信息。 实体类通常在事件流或交互图中，是对用户最有意义的类。,类的版型,控制类控制类负责协调其它类的工作。每个用例中至少应该有一个控制类，它控制
11、用况中的事件顺序。 一般地，控制类接收的消息并不多，而发出的消息比较多，因为它更多地是向其它类委托责任。,8.8.6 使用类图的几个建议,不要试图使用所有的符号。从简单的开始，例如，类、关联、属性和继承等概念。在UML中，有些符号仅适用于特殊的场合，只有当需要时才使用。 根据项目所处的开发阶段，用正确的观点来画类图。如果处于分析阶段，应画概念层类图；在设计阶段，应画说明层类图；当考察某个特定的实现技术时，则应画实现层类图。,使用类图的几个建议,把精力放在关键的环节，最好只画几张较为关键的图，并且不断更新细化。使用类图的最大危险是过早地陷入实现细节。,8.9 配置图,配置图表示该软件系统如何部署
12、到硬件环境中。 它的用途是显示该系统不同的组件将在何处物理地运行，以及它们将如何彼此通信。 因为配置（部署图）是对物理运行情况进行建模，系统的生产人员就可以很好地利用这种图。,部署图中的符号包括组件图中所使用的符号元素，另外还增加了几个符号，包括节点的概念。 一个节点可以代表一台物理机器，或代表一个虚拟机器节点(例如，一个大型机节点)。用三维立方体来表示节点，节点的名称位于立方体的顶部。 所使用的命名约定与序列图中相同：实例名称 : 实例类型 (例如，“ : Application Server“)。,8.10 组件图,在 UML 2 中，组件被认为是独立的，在一个系统或子系统中的封装单位，提
13、供一个或多个接口。 虽然 UML 2 规范没有严格地声明它，但是组件是呈现事物的更大的设计单元，这些事物一般将使用可更换的组件来实现。 现在，组件必须有严格的逻辑，设计时构造。主要思想是，能容易地在设计中重用或替换一个不同的组件实现，因为一个组件封装了行为，实现了特定接口。,在以组件为基础的开发（CBD）中，组件图为架构师提供一个开始为解决方案建模的自然形式。组件图允许一个架构师验证系统的必需功能是由组件实现的，这样确保了最终系统将会被接受。 除此之外，组件图对于不同的小组是有用的交流工具。图可以呈现给关键项目发起人及实现人员。 通常，当组件图将系统的实现人员连接起来的时候，组件图通常可以使项
14、目发起人感到轻松，因为图展示了对将要被建立的整个系统的早期理解。,举例,组件可以用UML 2规范中的三种不同方法表示。,依赖关系,组件图用依赖关系表示各组件之间存在的关系类型。组件图中的依赖关系是由客户指向提供者的虚线箭头。客户组件依赖于提供者组件，提供者组件只在开发时存在，运行时则不存在。 图8-33 显示两个组件之间的关系：一个使用了库存组件的订单组件 ，二者是依赖关系。,组件提供和要求的接口,一个典型的组件图包括更多的信息。一个组件元素可以在名字区下面附加额外的区。一个组件是提供一个或更多公共接口的独立单元。提供的接口代表了组件提供给它的用户/客户的服务的正式契约，用来表示Order组件
15、提供和要求的接口,显示组件提供并要求的接口,UML 2 也引入另外一种方法来显示组件提供并要求的接口。这个方法是建立一个里面有组件名的大长方形，并在长方形的外面放置在 UML 2 规范中称为接口符号的东西。,接口,接口和组件之间的关系分为两种：实现关系(Realization)和依赖关系(Dependency)。接口和组件之间用实线连接表示实现关系，用虚线连接表示依赖关系。,组件如何依赖于其他组件,显示Order系统组件如何依赖于其他组件的组件图 下图 显示，Order系统组件依赖于客户资源库和库存系统组件。注意在图 中复制出的接口名 CustomerLookup 和 ProductAcces
16、sor。,组件图展示发布组件及其关系,参见 p248 图8-36,8.11 对象图,对象图(Object Diagram) 是显示了一组对象和他们之间的关系。使用对象图来说明数据结构，类图中的类或组件等的实例的静态快照。 对象图和类图一样反映系统的静态过程，但它是从实际的或原型化的情景来表达的。 对象图显示某时刻对象和对象之间的关系。一个对象图可看成一个类图的特殊用例，实例和类可在其中显示。,面向对象方法都支持三种基本的活动：识别对象和类，描述对象和类之间的关系，以及通过描述每个类的功能定义对象的行为。 为了发现对象和类，开发人员要在系统需求和系统分析的文档中查找名词和名词短语，包括可感知的事
17、物（汽车、压力、传感器）；角色（母亲、教师、政治家）；事件（着陆、中断、请求）；互相作用（借贷、开会、交叉）；人员；场所；组织；设备；和地点。 通过浏览使用系统的脚本发现重要的对象和其责任，是面向对象分析和设计过程的初期重要的技术。,当重要的对象被发现后，通过一组互相关联的模型详细表示类之间的关系和对象的行为，这些模型从四个不同的侧面表示了软件的体系结构：静态逻辑、动态逻辑、静态物理和动态物理。 静态逻辑模型描述实例化（类成员关系）、关联、聚集（整体/部分）、和一般化（继承）等关系。这被称为对象模型。 一般化关系表示属性和方法的继承关系。 定义对象模型的图形符号体系通常是从用于数据建模的实体关
18、系图导出的。 对设计十分重要的约束，如基数（一对一、一对多、多对多），也在对象模型中表示,对象图,对象图是类图的实例，几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例，而不是实际的类。一个对象图是类图的一个实例。 由于对象存在生命周期，因此对象图只能在系统某一时间段存在。 对象也和合作图相联系，合作图显示处于语境中的对象原型（类元角色）。,对象图的用途,捕获实例和连接 在分析和设计阶段创建 捕获交互的静态部分 举例说明数据/对象结构 详细描述瞬态图 由分析人员、设计人员和代码实现人员开发,8.12 包图,当系统的规模比较大时，分析模型也会比较大，这会使得模型很复杂，难于
19、理解和实现。 人们将一个复杂的大功能分解为几个彼此独立而又相互联系的子功能。实现这些功能的函数或过程被放置在一个功能模块中，便于理解和复用。 在UML中，提供了包的概念，它是一种分组机制，它把UML模型元素中那些相关的部分放置在同一个包中。,使用类的包图从逻辑上对设计进行组织 可以使用以下启发性准则来将类组织为包。 一个框架内的类属于一个包。 一般位于同一继承层次上的类也属于同一个包。 通过聚合或者组合关系相关联的类往往属于同一个包。 相互之间协作很多的类通常属于同一个包。,8.12.1 包的表示,包有两种表示方法： 当不需要显示包的内容时，包的名字放入主方框内 否则包的名字放入左上角的小方框
20、中，而将内容放入主方框内，包的内容可以是一系列类，也可以是一系列包。,8.12.2 包的继承与依赖,包使得系统模型的内聚提高，耦合度降低，但是，如果包划分的太细就会增加包之间联系的复杂度。 包之间的联系通常表现为依赖关系、泛化关系和细化关系。 如果一个包中的类A依赖于另一个包中的类B，那么，当类B修改时就会影响类A的修改。 下面图中“用户界面”包依赖于“订单处理”包，“订单处理”包依赖于“数据实体”包。,8.13 需求分析阶段的主要活动,面向对象分析的具体任务是捕获和分析需求，细化用例模型中的用例，确定系统中的对象、对象的静态特征和动态特征、对象间的关系及对象的行为约束。 其目的是确定系统的分
21、析模型，建立一个易于维护的、稳定的、满足用户需求的系统框架结构。,8.13.1 活动1：建立业务模型,业务模型是研究项目所涉及的业务范围和工作流程。 在建立业务模型的过程中要了解用户企业的机构设置、角色分配，弄清楚业务流程，同时要了解与企业有交互活动的外部实体是如何参与活动的。 为此应该创建机构组织结构及角色职能图、业务用况图、业务活动图、业务实体图。,建立业务模型,第1步：创建机构组织结构及角色职能图 这个图不是UML建模的内容，但是，这个图对于了解机构的角色和角色的职责很有帮助。 画这个图时是将组织机构按层次展开，以图书管理信息系统为例，它所涉及的机构组织结构及角色职能图如下：,建立业务模
22、型,第二步：建立业务用况图 业务用况图中应该包括下面的元素： 1) 外部业务角色（Business Actor）。他们是与企业发生联系的外部实体，每个角色都与企业的活动有关。例如：客户、投资人、供应商、读者等。 在业务模型中，主要描述外部业务角色向系统提供哪些服务和请求，系统如何响应外部业务角色的请求。,建立业务模型,2) 内部业务角色（Business Worker） 内部业务角色是企业中的角色。通过描述每个内部业务角色的职责和相关的其他细节，使系统分析员能够尽快了解企业当前的工作流程、每个角色的职责、角色之间的关系等信息。,建立业务模型,3) 业务用况（Buiness Use Case ）
23、 业务用况是企业具体业务的描述。例如，图书馆的主要业务有“图书采购”、“编目”、“借书”、“还书”等业务。 一个业务用况的描述可以使用自然语言，但是对于复杂的业务处理流程描述，最好使用活动图描述。,建立业务模型,4)业务实体（Buiness Entity） 业务实体是企业经营业务期间产生和使用的对象。例如，图书馆中的业务实体有“图书证”、“索书单”、“缺书记录”、“借还书记录”等等。 注意，在获取用户需求时，应该对业务实体进行细化，为实体添加属性信息，例如，图书证的属性信息包括：证件编号、姓名、所属部门、职称等。这时不要涉及太多的属性细节，因为这时的主要目的是了解业务流程，不是设计数据库，所描
24、述的属性应该只包含有助于理解业务流程的属性。,建立业务模型,5）业务用况图 业务用况图描述的是企业的业务用况、外部业务角色和内部业务角色及其关系。从业务用况图可以清楚地了解系统的工作范围、涉及的角色。 业务用况图通常比较概括，不涉及具体的处理细节。,建立业务模型,第三步：描述业务流程。 可以用活动图描述业务处理流程。活动图的上面是业务活动中相关的角色，泳道中是每个角色要完成的任务，各个任务执行过程中需要与其他角色通信角色通信，或要求输入或输出信息等都可以在活动图中表示出来。 参见本章第5节给出的图书管理信息系统“借书”用况的业务流程活动图和相应的描述。,建立业务模型,第四步：描述业务实体。 在
25、需求分析的初期，可以不涉及业务实体之间的关系，而只是陈述实体内容。因此，可将所有的业务实体一一罗列，说明它们的名称、用途、具体的内容和格式要求。 例如，图书管理信息系统中的业务实体目前可以整理出：读者信息、图书信息、借还书记录、到书通知单、处罚单、缺书登记单、预订图书单、采购计划单、购书发票、购书付款单。,8.13.2 活动2：构造用况模型,这项工作是根据业务模型或用户的补充说明确定系统的用况模型。 这项活动包括6个步骤：,构造用况模型,1) 确定角色系统分析人员与用户一起确定与系统发生交互活动的所有角色。 角色是启动事件流的外部激励，为了寻找角色，需要研究事件流和过程由谁来启动，启动的环境是
26、什么。,构造用况模型,2) 确定用况确定角色之后，就可以对每个角色提出问题以获取用况。 以下问题可供参考: 角色要求系统提供哪些功能(执行者需要做什么)？ 角色需要了解和处理的信息有哪些类型。 必须提醒角色的系统事件有哪些？ 必须提醒系统的事件有哪些？ 怎样把这些事件表示成用况中的功能？为了完整地描述用况，还需要知道角色的某些典型功能是否能够被系统自动实现？ 系统需要的输入输出是什么？输入从何处来？输出到何处？ 当前运行系统(也许是一些手工操作而不是计算机系统)的主要问题？,构造用况模型,3）确定用况模型使用用况图展示系统的用况模型。,构造用况模型,4）用况模型说明包括角色说明；用况总览和详述
27、。 见教材254页角色说明表和用况总览表及用例详细说明表。,构造用况模型,5)用况模型评价在初步建立了用况模型后，应该邀请领域专家和其他相关的用户一起对模型进行评审，回答下面的问题： 是否已将所有必须的功能性需求都捕获为用况。 每个用况的动作系列是否正确、完善、易于理解。 是否已经确定了一些价值很小或根本没有价值的用况，如果又将它们删除。,构造用况模型,6)优化用况模型系统分析员检查模型中的每个用况，提炼出公共部分，创建抽象用况，并用使用关系与之连接；确定补充功能或可选功能； 检查每个用况，如果发现一个用况比较大，并且其中既包含了一般处理又包含了特殊处理，那么则应该将特殊处理的部分提取出来，创
28、建单独的用况，并且用扩展关系连接相关的用况。 这样做可以减小用况规模，简化用况的处理。,8.12.3活动3：构造用户界面的原型,系统分析员已经确定了用况与角色之间的对应关系，现在要确定角色如何启动用况，以及用况以什么形式向角色提供信息。这项活动的结果是用户界面原型。 这个活动有两个步骤实现：,构造用户界面的原型,（1）逻辑用户界面设计。用户界面设计人员逐一检查用况，为每个用况确定适当的用户界面元素。常用的界面元素有图标、列表、文件夹、菜单等。 通过回答下列问题可以寻找界面元素：,回答下列问题,需要哪些界面元素来启动用例？ 用户界面元素之间如何相关？ 用户界面看起来应该是什么样的？ 应该如何处理
29、这些用户界面元素？ 针对所涉及的业务领域，对用户界面元素有何特殊要求？ 角色可以激发哪些动作？在激发这些动作前需要哪些指南？ 角色向系统提供什么信息？ 系统向角色提供什么信息？ 每项输入/输出的长度和类型是什么？,（2）构造用户界面原型。 用户界面设计人员应该画出主要用户界面的简图，然后，描绘需要附加的用户界面元素，例如容器、窗口、工具和控件等。 接着，为那些最重要的用户界面元素构造可执行的原型，通过对原型和简图进行评审可以避免许多错误和疏漏。,8.13.4 活动4：分析模型,分析用况模型的每个用况，确定实现用况的类，分析每个类的职责、属性和关联。将参与用况实现的类收集到一个类图中。分析模型中
30、使用了三种类： 边界类描述系统与角色之间的接口。 控制类在分析模型内表示协调、顺序、事物处理以及控制其他对象的类。 实体型为需要长久保存的信息进行建模的类。,创建类图时应该注意：,1.首先为以人充当的角色建立一个主要边界类。这个类通常实现一个交互主窗口。 2.为每个由外部系统充当的角色定义一个主要边界类，用于通信接口。 3.为每个初期确定的实体创建一个基本边界类。 这里要与前面两点统一考虑，减少重复的边界类信息。,分析模型,4.确定控制类，负责处理用况实现的控制和协调关系。有时，一些控制信息是由角色与系统进行交互时处理的，这种情况下可以将控制封装在边界类中。当一个控制类很复杂时，最好将它拆分成两个控制类，但是不要破坏处理逻辑，降低类的可重用性。 5.仔细研究用况说明和已有的业务模型确定实体类。,图书馆信息管理系统借书用况的类图,参见教材 p258 图8-48,8.14 面向对象的需求规格说明书,面向对象的需求分析使用的方法和工具与结构化方法有很大的区别，本小节给出一个基于面向对象方法的需求规格说明书的文档模板。 见模板,
