《UML设计技术》PPT课件.ppt

统一建模语言（Unified Modeling Language,UML）是一种整合多种模型的语言，由Rumbaugh、Booch和Jacobson三位大师提出。是第三代用来 为面向对象开发系统的产品进行说明、可视化和编制文档的方法。,UML(统一建模语言)设计技术,UML得发展历程,什么是UML,UML是一种标准的图形化建模语言，它是面向对象分析与设计的一种标准表示。它：不是一种可视化的程序设计语言，而是一种可视化的建模语言；不是工具或知识库的规格说明，而是一种建模语言规格说明，是一种表示的标准；不是过程，也不是方法，但允许任何一种过程和方法使用它；,UML的目标,易于使用、表达能力强，进行可视化建模；与具体的实现无关，可应用于任何语言平台和工具平台；与具体的过程无关，可应用于任何软件开发的过程；简单并且可扩展，具有扩展和专有化机制，便于扩展，无需对核心概念进行修改；为面向对象的设计与开发中涌现出的高级概念（例如协作、框架、模式和组件）提供支持，强调在软件开发中，对架构、框架、模式和组件的重用；与最好的软件工程实践经验集成；可升级、具有广阔的适用性和可用性；有利于面对对象工具的市场成长。,UML的架构,UML是由图和元模型组成的。图是UML的语法，而元模型则给出的图的意思，是UML的语义。UML的语义是定义在一个四层（或四个抽象级）建模概念框架中的，这四层分别是：元元模型（meta-metamodel）层，组成UML最基本的元素“事物（Thing）”，代表要定义的所有事物；元模型（metamodel）层，组成了UML的基本元素，包括面向对象和面向组件的 概念。这一层的每个概念都是元元模型中“事物”概念的实例（通过版类化）；,UML的架构,模型（model）层，组成了UML的模型，这一层中的每个概念都是元模型层中概念的一个实例（通过版类化），这一层的模型通常叫做类模型（class model）或类型模型（type model）；用户模型（user model）层，这层中的所有元素都是UML模型的例子。这一层中 的每个概念都是模型层的一个实例（通过分类），也是元模型层的一个实例通（过版类化）。这一层的模型通常叫做对象模型（object model）或实例模型（instance model）。,UML的模型、视图、图与系统架构建模,UML是用来描述模型的，它用模型来描述系统的结构或静态特征、以及行为或动态特征。它从不同的视角为系统的架构建模形成系统的不同视图view包括：用例视图（use case view）,强调从用户的角度看到的或需要的系统功能，这种视图也叫做用户模型视图（user model view）或想定视图（scenario view）；逻辑视图（logical view）,展现系统的静态或结构组成及特征,也称为结构模型视图（structural model view）或静态视图（static view）；,UML的模型、视图、图与系统架构建模,并发视图（concurrent view），体现了系统的动态或行为特征，也称为行为模型视图（behavioral model view）、过程视图（process view）协作视图（collaborative）、动态视图（dynamic view）；组件视图（component view），体现了系统实现的结构和行为特征，也称为实现模型视图（implementation model view）和开发视图（development view）；展开视图（deployment view），体现了系统实现环境的结构和行为特征，也称为环境模型视图（implementation model view）或物理视图（physical view）；,UML与面向对象的软件分析与设计（OOA&D）,标准的表示方法 UML是一种建模语言，是一种标准的表示，而不是一种方法（或方法学）。方法是一种把人的思考和行动结构化的明确方式，方法需要定义软件开发的步骤、告诉人们做什么，如何做，什么时候做，以及为什么要这么做。而UML只定义了一些图以及它们的意义，它的思想是与方法无关。因此，我们会看到人们将用各种方法来使用UML，而无论方法如何变化，它们的基础是UML的图，这就是UML的最终用途-为不同领域的人们提供统一的交流标准。,与软件开发的成功经验集成,在众多成功的软件设计与实现的经验中，最突出的两条:一是注重系统架构的开发，一是注重过程的迭代和递增性。尽管UML本身没有对过程有任何定义，但UML对任何使用它的方法（或过程）提出的要求是：支持用例驱动（use-case driven）、以架构为中（architecture-centric）以及递增（incremental）和迭代（iterative）地开发。,与软件开发的成功经验集成,注重架构意味着不仅要编写出大量的类和算法，还要设计出这些类和算法之间简单而有效地协作。所有高质量的软件中似乎大量是这类的协作，而近年出现的软件设计模式也正在为这些协作起名和分类，使它们更易于重用。最好的架构就是“概念集成（conceptual integration）”，它驱动整个项目注重开发模式并力图使它们简单。迭代和递增的开发过程反映了项目开发的节奏。,UML的应用领域,在不同类型系统中的应用：UML的目标是用面向对象的方式描述任何类型的系统。最直接的是用UML为软件系统创建模型，但UML也可用来描述其它非计算机软件的系统或者是商业机构或过程。以下是UML常见的应用：信息系统（Information System）：向用户提供信息的储存、检索、转换和提交。处理存放在关系或对象数据库中大量具有复杂关系的数据；技术系统（Technical System）：处理和控制技术设备，如电信设备、军事系统或工业过程。它们必须处理设计的特殊接口，标准软件很少。技术系统通常是实时系统；,嵌入式实时系统（Embedded Real-Time System）：在嵌入到其它设备如移动电话、汽车、家电上的硬件上执行的系统。通常是通过低级程序设计进行的，需要实时支持；分布式系统（Distributed System）：分布在一组机器上运行的系统，数据很容易从一个机器传送到另一台机器上。需要同步通信机制来确保数据完整性，通常是建立在对象机制上的，如CORBA，COM/DCOM，或Java Beans/RMI上；,系统软件（System Software）：定义了其它软件使用的技术基础设施。操作系统、数据库和在硬件上完成底层操作的用户接口等，同时提供一般接口供其它软件使用；商业系统（Business System）：描述目标、资源（人，计算机等），规则（法规、商业策略、政策等）和商业中的实际工作（商业过程）。要强调的是，通常大多数系统都不是单纯属于上面的某一种系统，而是一种或多种的结合。例如，现在许多信息系统都有分布式和实时的需要。,在软件开发的不同阶段中的应用,UML的应用贯穿在系统开发的五个阶段，它们是：需求分析。UML的用例视图可以表示客户的需求。通过用例建模，可以对外部的角色以及它们所需要的系统功能建模。角色和用例是用它们之间的关系、通信建模的。每个用例都指定了客户的需求：他或她需求系统干什么。不仅要对软件系统，对商业过程也要进行需求分析；分析。分析阶段主要考虑所要解决的问题，可用 UML的逻辑视图和动态视图来描述：类图描述系统的静态结构，协作图、状态图、序列图、活动图和状态图描述系统的动态特征。在分析阶段，只为问题领域的类建模-不定义软件系统的解决方案的细节（如用户接口的类、数据库等）；,设计。在设计阶段，把分析阶段的结果扩展成技术解决方案。加入新的类来提供技术基础结构-用户接口，数据库操作等。分析阶段的领域问题类被嵌入在这个技术基础结构中。设计阶段的结果是构造阶段的详细的规格说明；构造。在构造（或程序设计阶段），把设计阶段的类转换成某种面向对象程序设计语言的代码。在对 UML表示的分析和设计模型进行转换时，最好不要直接把模型转化成代码。因为在早期阶段，模型是理解系统并对系统进行结构化的手段。测试。对系统的测试通常分为单元测试、集成测试、系统测试和接受测试几个不同级别。单元测试是对几个类或一组类的测试，通常由程序员进行；集成测试集成组件和类，确认它们之间是否恰当地协作；系统测试把系统当作一个“黑箱”，验证系统是否具有用户所要求的所有功能；接受测试由客户完成，与系统测试类似，验证系统是否满足所有的需求。,UML设计技术Prof.Guifa Teng,UML语言概述,UML由视图(Views)、图（Diagrams)、模型元素(Model Elements)和通用机制(General Mechanism)等几个部分构成,UML语言概述,视图用来表示被建模系统的各个方面（从不同的目的出发建立，为系统建立多个模型，这些模型都反映同一个系统，且具有一致性）。视图由多个图（Diagrams）构成，它不是 一个图片（graph），而是在某一个抽象层上，对系统的抽象表示。如果要为系统建立一个完整的模型图，只需定义一定数量的视图，每个视图表示系统的一个特殊的方面就可以了。另外，视图还把建模语言和系统开发时选择的方法或过程连接起来。UML中的视图包括：用例视图（Use-case view）、逻辑视图（Logical view）、组件视 图（coopponent view）、并发视图（Concurrency view）展开视图（Deployment view）、等五种。能够使用的其他视图还有静态-动态视图、逻辑-物理视图工作流程（workflow）等视图 但UML语言中并不使用这些视图 它们是UML语言的设计者意 识中的视图 因此在未来的大多数CASE工具中有可能包含这些视图。,图由各种图片（graph）构成，用来描述一个视图的内容。UML语言定义了9种不同的图的类型，把它们有机地结合起来就可以描述系统的所有视图。模型元素代表面向对象中的类、对象、消息和关系等概念，是构成图的最基本的常用概念。一个模型元素可以用在多个不同的图中，无论怎样使用，它总是具有相同的含义和相同的符号表示。通用机制用于表示其他信息，比如注释、模型元素的语义 等。另外，它还提供扩展机制，使UML语言能够适应一个特殊的方法（或过程）或扩充至一个组织或用户。,用例视图,用例视图（Use-case view）用于描述系统应该具有的功能集。它是从系统的外部用户角度出发，对系统的抽象表示。用例视图中可以包含若干个用例（use-case）。用例用来表示系统能够提供的功能（系统用法），一个用例是系统用法（功能请求）的一个通用描 述。用例视图主要为用户、设计人员、开发人员和测试人员而设置。用例视图静态地描述系统功能，为了动态地观察系统功能，偶尔也用活动图（activity diagram）描述。,逻辑视图,逻辑视图（Logical view）用来显示系统内部的功能是怎样设计的，它利用系统的静态结构和动态行为来刻画系统功能。静态结构描述类、对象和它们之间的关系等。动态行为主要描述对象之间的动态协作，当对象之间彼此发送消息给给定的函数时产生动态协作，一致性（persistence）和并发性（concurrency）等性质，以及接口和类的内部结构都 要在逻辑视图中定义。,组件视图,组件视图（Component view）用来显示代码组件的组织方式它描述了实现模块（implementation module）和它们之间的依赖关系。组件视图由组件图构成。组件是代码模块，不同类型的代码模块形成不同的组件，组件按照一定的结构和依赖关系呈现。组件的附加信息（比如，为组件分配资源）或其他管理信息（比如，进展工作的进展报告）也可以加入到组件视图中。组件视图主要供开发者使用。,并发视图,并发视图（Concurrency View）用来显示系统的并发工作状况。并发视图将系统划分为进程和处理机方式，通过划分引入并发机制，利用并发高效地使用资源、并行执行和处理异步事件。除了划分系统为并发执行的控制线程外，并发视图还必须处理通信和这些线程之间的同步问题。并发视图所描述的方面属于系统中的非功能性质方面。并发视图供系统开发者和集成者（integrator）使用它由动态图（状态图、序列图、协作图、活动图）和执行图（组件图、展开图）构成。,展开视图,展开视图（Deployment View）用来显示系统的物理架构，即系统的物理展开。比如，计算机和设备以及它们之间的联接方式。其中计算机和设备称为结点（node）。它由展开图表示。展开视图还包括一个映射，该映射显示在物理架构中组件是怎样展开的。比如，在每台独立的计算机上哪一个程序或对象在运行。展开视图提供给开发者、集成者和测试者。,图,图（diagram）由图片（graph）组成，图片是模型元素的符号化。把这些符号有机地组织起来形成的图表示了系统的一个特殊部分或某个方面。一个典型的系统模型应有多个各种类型的图。图是一个具体视图的组成部分，在画一个图时，就相当于把这个图分配给某个视图了。依据图本身的内容，有些图可能是多个视图的一部分。UML中包含用例图、类图、对象图、状态图、序列图、协作图、活动图、组件图、展开图共九 种。,用例图,用例图（use-case diagram）用于显示若干角色（actor）以及这些角色与系统提供的用例之间的连接关系，如下图所示。用例是系统提供的功能（即系统的具体用法）的描述。通常一个实际的用例采用普通的文字描述，作为用例符号的文档性质。当然，实际的用例图也可以用活动图描述。用例图仅仅从角色（触发系统功能的用户等)使用系统的角度描述系统中的信息，也就是站在系统外部察看系统功能，它并不描述系统内部对该功能的具体操作方式。用例图定义的是系统的功能需求。以后对用例图的图示方法、含义将进一步介绍。,用例图示例,签定保险单,销售统计资料,客户数据资料,客户,销售保险员,cases,actors,actors,用例图示例,类图,类图（class diagram）用来表示系统中的类和类与类之间的关系，它是对系统静态结构的描述，如下图所示。类用来表示系统中需要处理的事物。类与类之间有多种连接方式（关系），比如：关联（彼此间的连接)、依赖（一个类使用另一个类）、通用化（一个类是另一个类的特殊化）或打包（packaged）（多个类聚合成一个基本元素）。类与类之间的这些关系都体现在类图的内部结构之中，通过类的属性（attribute）和操作（operation）这些术语反映出来。在系统的生命周期中，类图所描述的静态结构在任何情况下都是有效的。后面再详细讨论。,类图示例,客户,1 拥有,1.*,有价证券,1.*,处理 1,交易员,仪器工具,含有,0.*,0.*,债券,股票,股票选择,金融贸易类图示例,对象图,对象图是类图的变体。两者之间的差别在于对象图表示的是类的对象实例，而不是真实的类。对象图是类图的一个范例（example），它及时具体地反映了系统执行到某处时，系统的工作状况。对象图中使用的图示符号与类图几乎完全相同，只不过对象图中的对象名加了下划线，而且类与类之间关系的所有实例也都画了出来，如下图所示。图（a）的类图抽象 地显示各个类及它们之间的关系，图（b）的对象图则是图（a）类图的一个实例表示。,对象图与类图示例,对象图没有类图重要，对象图通常用来示例一个复杂的类图，通过对象图反映真正的 实例是什么，它们之间可能具有什么样的关系，帮助对类图的理解。对象图也可以用在协作图中作为其一个组成部分，用来反映一组对象之间的动态协作关系。,1.*,作家,姓名:string,年龄:integer,计算机,名称:string,内存:integer,丁一：作家,（a）类图,0.1 使用,姓名=丁一年龄=30,丁一办公室中的pc:,计算机,名称=Dell 466,内存=64,丁一家里的pc:,计算机,名称=长城 p II MMX内存=64,（b）对象图,状态图,状态图是对类所描述事物的补充说明，它显示了类的所有对象可能具有的状态，以及引起状态变化的事件，如下图所示，事件可以是给它发送消息的另一个对象 或者某个任务执行完毕（比如，指定时间到）。状态的变化称作转移（transition）。一个转移可以有一个与之相连的动作（action），这个动作指明了状态转移时应该做些什么。并不是所有的类都有相应的状态图。状态图仅用于具有下列特点的类：具有若干个确定的状态，类的行为在这些状态下会受到影响且被不同的状态改变。另外，也可以为系统描绘整体状态图。关于状态图将进一步的讨论。,状态图示例,大楼的一层,上升楼层,向上升,到达一层,移到一层,向下升,到达楼层,下降楼层,超时,空闲,上升楼层,电梯的状态图示例,序列图,序列图用来反映若干个对象之间的动态协作关系，也就是随着时间的流逝，对象之间是如何交互的，如下图所示。序列图主要反映对象之间已发送消息的先后次序，说明对象之间的交互过程，以及系统执行过程中，在某一具体位置将会有什么事件发生。序列图由若干个对象组成，每个对象用一个垂直的虚线表示（线上方是对象名），每个对象的正下方有一个矩形条，它与垂直的虚线相叠，矩形条表示该对象随时间流逝的过程（从上至下），对象之间传递的消息用消息箭头表示，它们位于表示对象的垂直线条之间。时间说明和其他的注释作为脚本放在图的边缘。对序列图的讨论将在以后介绍。,序列图示例,打印（文件）,计算机,打印服务器,打印机,打印（文件）,打印机空闲打印（文件）,打印机忙存储（文件）,队列,序列图示例,协作图,协作图和序列图的作用一样，反映的也是动态协作。除了显示消息变化（称为交互）外，协作图还显示了对象和它们之间的关系（称为上下文有关）。由于协作图或序列图都反映对象之间的交互，所以建模者可以任意选择一种反映对象间的协作。如果需要强调时间和序列，最好选择序列图；如果需要强调上下文相关；最好选择协作图。协作图与对象图的画法一样，图中含有若干个对象及它们之间的关系（使用对象图或 类图中的符号），对象之间流动的消息用消息箭头表示，箭头中间用标签标识消息被发送的序号、条件、迭代（iteration）方式、返回值等等。通过识别消息标签的语法，开发者可以看出对象间的协作，也可以跟踪执行流程和消息的变化情况。,协作图中也能包含活动对象，多个活动对象可以并发执行。如图所示。以后将详细讨论协作图。,：计算机,：打印服务器,：队列,：打印机,1,1,1：打印（文件）,打印机忙1.2：存储（文件）,打印机空闲1.1：打印（文件）,协作图示例,协作图示例,活动图,活动图（activity diagram）反映一个连续的活动流，如下图所示。相对于描述活动流（比如，用例或交互）来说，活动图更常用于描述某个操作执行时的活动状况。活动图由各种动作状态（action state）构成，每个动作状态包含可执行动作的规范说明。当某个动作执行完毕，该动作的状态就会随着改变。这样动作状态的控制就从一个状态流向另一个与之相连的状态。,活动图中还可以显示决策、条件、动作状态的并行执行、消息（被动作发送或接收）的规范说明等内容。,活动图示例,活动图示例,组件图,组件图（component diagram）用来反映代码的物理结构。代码的物理结构用代码组件表示。组件可以是源代码、二进制文件或可执行文件组件。组件包含了逻辑类或逻辑类的实现信息，因此逻辑视图与组件视图之间存在着映射关系。组件之间也存在依赖关系，利用这种依赖关系可以方便地很容易地分析一个组件的变 化会给其他的组件带来怎样的影响。组件可以与公开的任何接口（比如 OLE/COM接口），一起显示，也可以把它们组合起来形成一个包（package），在组件图中显示这种组合包。实际编程工作中经常使用组件图（如下图所示）。后面将进一步详述组件图。,窗口控制（whnd.cpp）,通信控制（comhnd.cpp）,主控模块（main.cpp）,窗口控制（whnd.obj）,通信控制（comhnd.obj）,主控模块（main.obj）,图形库（graphic.dll）,客户程序（client.exe）,组件图示例,组件图示例,展开图,展开图（deployment diagram）用来显示系统中软件和硬件的物理架构。通常展开图中显示实际的计算机和设备（用结点表示），以及各个结点之间的关系（还可以显示关系的类型）。每个结点内部显示的可执行的组件和对象清晰地反映出哪个软件运行在哪个结点上。组件之间的依赖关系也可以显示在展开图中。展开图用来表示展开视图，描述系统的实际物理结构。用例视图是对系统应具有的功能的描述，它们二者看上去差别很大，似乎没有什么联系。然而，如果对系统的模型定义明确，那么从物理架构的结点出发，找到它含有的组件，再通过组件到达它实现的类，再到达类的对象参与的交互，直至最终到达一个用例也是可能的。从整体来说，系统的不同视图给系统的描述应当是一致的。,客户A：,Compaq Pro Pc,“Tcp/Ip”,应用服务器：,Silicon Graphics O2,数据库服务器：,“DecNet”,VAX,客户B：,Compaq proPc,“Tcp/Ip”,展开图示例,展开图示例,静态建模用例和用例图,用例模型是把应满足用户需求的基本功能（集）聚合起来表示的强大工具。对于正在构造的新系统，用例描述系统应该作什么；对于已构造完毕的系统，用例则反映了系统能够完成什么样的功能。构建用例模型是通过开发者与客户（或最终使用者）共同协商完成的，他们要反复讨论需求的规格说明，达成共识，明确系统的基本功能，为后阶段的工作打下基础。,用例模型的基本组成部件是用例、角色和系统。用例用于描述系统的功能，也就是从 外部用户的角度观察，系统应支持哪些功能，帮助分析人员理解系统的行为，它是对系统功能的宏观描述。一个完整的系统中通常包含若干个用例，每个用例具体说明应完成的功能，代表系统的所有基本功能（集）。角色是与系统进行交互的外部实体，它可以是系统用户，也可以是其它系统或硬件设备，总之，凡是需要与系统交互的任何东西都可以称作角色。,系统的边界线以内的区域（即用例的活动区域）则抽象表示系统能够实现的所有基本功能。在一个基本功能（集）已经实现的系统中，系统运转的大致过程是：外部角色先初始化用例，然后用例执行其所代表的功能，执行完后用例便给角色返回一些值，这个值可以是角色需要的来自系统中的任何东西。,在用例模型中，系统仿佛是实现各种用例的“黑盒子”，我们只关心该系统实现了哪些功能，并不关心内部的具体实现细节（比如系统是如何做的？用例是如何实现的？）。用例模型主要应用在工程开发的初期，进行系统需求分析时使用。通过分析描述使开发者在头脑中明确需要开发的系统功能有哪些。,用例模型由用例图构成。用例图中显示角色、用例和用例之间的关系。用例图在宏观上给出模型的总体轮廓，而用例的真正实现细节描述则以文本的方式书写。用例图所表示的图形化的用例模型（可视化模型）本身并不能提供用例模型必需的所有信息。也就是说，从可视化的模型只能看出系统应具有哪些功能，每个功能的含义和具体实现步骤必须使用用例图和文本描述（它记录着实现步骤）。在进行定义系统，发现角色和用例、描述用例、定义用例之间的关系，验证最终模型的有效性等工作时，需要建立用例模型。,用例模型也就是系统的用例视图。用例视图在建模过程中居于非常重要的位置，影响着系统中其它视图（比如，逻辑和物理架构）的构建和解决方案（满足基本功能需求)的实现,因为它是客户和开发者共同协商反复讨论确定的系统基本功能(集).开发者既可以把用例视图用于构建一个新系统的功能视图，还可以把已有的用例视图修改或扩充后产生新的版本，也就是在现有的视图上加入新功能（即在视图中加入新的角色和用例）。,用 例 图,用例模型（也就是用例视图）是用例图描述的。用例模型可以由若干个用例图组成。用例图中包含系统、角色和用例等三种模型元素。图示用例图时，既要画出三种模型元素，同时还要画出元素之间的各种关系（通用化、关联、依赖），如图所示：,用 例 图,用例内容（即该用例所代表功能的具体实现过程）通常用普通的文字书写。在UML语言中，用例内容被看作用例元素的文档性质。,系统,系统是用例模型的一个组成部分，代表的是一部机器或一个商务活动等等，而并不是真正实现的软件系统。系统的边界用来说明构建的用例模型的应用范围。系统最初的规模应有多大也应该考虑。一般的作法是，先识别出系统的基本功能（集），然后以此为基础定义一个稳定的、精确定义的系统架构，以后再不断地扩充系统功能，逐步完善。这样作的好处在于避免了一开始系统太大，需求分析不易明确，从而导致浪费大量的开发时间。用例图中的系统用一个长方框表示，系统的名字写在方框上或方框里面，方框内部还可以包含该系统中的用符号表示的用例。比如，上图中的保险商务系统。表示该系统的方框内还包含了三个用例（签订保险单、销售统计资料、客户数据资料）。,角色,角色（actor）是与系统交互的人或事。所谓“与系统交互”指的是角色向系统发送消息，从系统中接收消息，或是在系统中交换信息。只要使用用例，与系统互相交流的任何人或事都是角色。比如，某人使用系统中提供的用例，则该人就是角色；与系统进行通信（通过用例）的某种硬件设备也是角色 角色是一个群体概念，代表的是一类能使用某个功能的人或事，角色不是指某个个体。角色也可以分成主动角色和被动角色。主动角色可以初始化用例，而被动角色则不行，仅仅参与一个或多个用例，在某个时刻与用例通信。,角色,发现角色 通过回答下列的一些问题，可以帮助建模者发现角色。使用系统主要功能的人是谁（即主要角色）？需要借助于系统完成日常工作的人中谁？谁来维护、管理系统（次要角色）保证系统正常工作？系统控制的硬件设备有哪些？系统需要与哪些其它系统交互？其它系统包括计算机系统，也包括该系统将要使用的计算机中的其它应用软件。其它系统也分成二类，一类是启动该系统的系统，另一类是该系统要使用的系统。对系统产生的结果感兴趣的人或事是哪些？,角色,UML中的角色 UML中的角色是具有版类角色的类，该类的名字用角色的名字命名，用以反映角色的行为。角色类包含有属性、行为和描述角色的文档性质。UML中用一个小人形图形表示角色类，小人的下方书写角色名字，如图所示。图左侧的矩形是具有版类角色的类（即角色类）的另一种图示方式，右侧的标准图示图标一般用在用例图中。,角色,角色之间的关系 由于角色是类，所以它拥有与类相同的关系描述。在用例图中，只用通用化关系描述若干个角色之间的行为。通用化关系的含义是：把某些角色的共同行为（原角色中的部分行为），抽取出来表示成通用行为，且把它们描述成为超类（superclass）。这样，在定义某一具体的角色时，仅仅把具体的角色所特有的那部分行为定义一下就行了，具体角色的通用行为则不必重新定义，只要继承超类中相应的行为即可。角色之间的通用化关系用带空心三角形（作为箭头）的直线表示，箭头端指向超类。,角色,电话申请客户类与个人登记客户类的基本行为与客户类一致，这两个类的差别仅仅在于申请的方式不同，于是，在定义这两个类的行为时，基本行为可以从客户类中继承得到（从而不必重复定义），与客户类不同的行为则定义在各自的角色类中。,用例,什么是用例 用例代表的是一个完整的功能。UML中的用例是动作步骤的集合。动作（action）是系统的一次执行（能够给某个角色输出结果值）。与角色通信，或进行计算，或在系统内工作都可以称作动作。用例具有以下的特征 用例总由角色初始化 用例为角色提供值 用例具有完全性不管用例内部的小用例是如何通信工作的，只有最终产生了返回给角色的结果值，才能说用例执行完毕。,用例,用例和角色之间也有连接关系，用例和角色之间的关系属于关联（association），又称作通信关联（communication association）。这种关联表明哪种角色能与该用例通信。关联关系是双向的一对一关系，即角色可以与用例通信，用例也可以与角色通信。用例的命名方式与角色相似，通常用用例实际执行功能的名字命名，比如：签定保险单、修改注册人等。,用例,发现用例实际上，从识别角色起，发现用例的过程就已经已开始了。对于已识别的角色，通过询问下列问题就可发现用例：角色需要从系统中获得哪种功能?角色需要做什么？角色需要读取、产生、删除、修改或存储系统中的某种信息吗？系统中发生的事件需要通知角色吗？或者角色需要通知系统某件事吗？这些事件（功能）能干些什么？如果用系统的新功能处理角色的日常工作是简单化了，还是提高了工作效率？还有一些与当前角色可能无关的问题，也能帮助建模者发现用例，例如：系统需要的输入/输出是什么信息？这些输入/输出信息从哪儿来到哪儿去？系统当前的这种实现方法要解决的问题是什么?（也许是用自动系统代替手工操作）,用例,UML中的用例 UML中的用例用椭圆形表示，用例的名字写在椭圆的内部或下方。用例位于系统边界的内部。角色与用例之间的关联关系（或通信关联关系）用一条直线表示，如图所示。,用例,下图给出的是某自动售货系统的用例图。,用例,用例之间的关系 用例之间有扩展、使用、组合三种关系。扩展和使用是继承关系（即通用化关系）的另一种体现形式。组合则是把相关的用例打成包（package），当作一个整体看待。扩展关系 一个用例中加入一些新的动作后则构成了另一个用例，这两个用例之间的关系就是通用化关系，又称扩展关系。后者通过继承前者的一些行为得来，前者通常称为通用化用例。后者常称为扩展用例。扩展用例可以根据需要有选择地继承通用化用例的部分行为。扩展 用例也一定具有完全性。扩展用例的好处在于：便于处理通用化用例中不易描述的某些具体情况；便于扩展系统，提高系统性能，减少不必要的重复工作。用例之间的扩展关系可图示为带版类扩展的通用化关系，如下图所示。,用例,用例,使用关系 一个用例使用另一个用例时，这两个用例之间就构成了使用关系。一般情况下，如果若干个用例的某些行为都是相同的，则可以把这些相同的行为提取出来单独作成一个用例，这个用例称为抽象用例。这样，当某个用例使用该抽象用例时，就好象这个用例包含了抽象用例的所有行为。,用例,用例之间的使用关系被图示为带版类使用的通 用化关系，如图所示：,用例,比如，自动售货系统中，供货和提取销售款这两个用例的开始动作都是去掉机器保险并打开它，最后的动作一定是关闭机器并加保险，于是可以从这两个用例中把开始的动作抽象成“打开机器”用例，把最后的动作抽象成“关闭机器”用例，那么“供货”和“提取销售款”用例在执行时一定要使用上述的两个抽象用例，它们之间便构成了使用关系。使用关系用带版类使用的通用化关系表示，如下图所示,用例,描述用例,图形化表示的用例本身不能提供该用例所具有的全部信息，因此还必需描述用例不可能反映在图形上的信息。通常用文字描述用例的这些信息。用例的描述其实是一个关于角色与系统如何交互的规格说明，该规格说明要清晰明了，没有二义性。描述用例时，应着重描述系统从外界看来会有什么样的行为，而不管该行为在系统内部是如何具体实现的，即只管外部能力，不管内部细节。,描述用例,用例的描述应包括下面几个方面 用例的目标 用例是怎样被启动的 角色和用例之间的消息流 用例的多种执行方案 用例怎样才算完成并把值传给了角色,描述用例,需要强调的是，描述用例仅仅是为了站在外部用户的角度识别系统能完成什么样的工作，至于系统内部是如何实现该用例的（用什么算法等）则不用考虑，描述用例的文字一定要清楚，前后一致，避免使用复杂的易引起误解的句子，方便用户理解用例和验证用例。用例也可以用活动图描述，即描述角色和用例之间的交互（如下图所示）。活动图中显示各个活动的顺序和导致下一个活动执行的决策（decision）。对用户来说，用例视图更易于使用。,描述用例,送出饮料,图：活动图示例,描述用例,对某个用例的描述完成之后，可以用一个具体的活动跟踪一下，检查用例中描述的关系能否被识别。在执行这个活动时，可以通过回答下列问题找出不足之处。用例中的所有角色与该用例都有关联关系吗？若干个角色的通用行为与基类角色（从若干个角色的行为中抽象出的最普通的那部分）的行为是否相似？表示同一个活动流的多个用例之间是否存在相似性，它们是否能用使用关系描述为一个用例。用例扩展关系中描述的特殊情况存在吗？有没有存在无任何通信关联的角色或用例？如果有，那么用例一定存在问题，否则为什么还要这个角色。有没有遗漏与需求的功能相对应的用例？如果有，那么就要新建一个用例。注意，不要把所有的用例建好之后，再去识别用例中的关系是否正确。这种做法有时会导致错误。,测试用例,用例可用于测试系统的正确性和有效性。正确性表明系统的实现符合规格说明。有效性保证开发的系统是用户真正需要的系统。正确性测试保证系统的工作符合规格说明。常用的测试方法有二种，一种是用具体的用例测试系统的行为，又称“漫游用例”；另一种是用用例描述本身测试，或称定义测试。这两种方法相比，第一种方法更好一些。,测试用例,第一种测试方法的基本思想是用人模拟系统的行为。大致过程如下：指定一个人扮演具体用例中的角色，另一个人扮演系统。扮演角色的人首先说出角色应传给系统的消息，然后系统接收消息开始执行，在系统执行过程中，扮演系统的人说出他正在做的工作是什么。通过角色模拟，开发者可以从扮演者那里得知用例的不足之处。比如，发现哪些情况 漏掉了，哪些动作描述得还不够详细。扮演系统行为的人洞察力越强，用例测试的效果就越好。因此 可以让每个人分别多次扮演各个角色或系统，从而为建模者提供更多的信息，减少用例描述的遗漏和含糊不清。当所有的角色都被扮演，且所有的用例都以此方式执行过了，那么对用例模型的测试就算完成了。,实现用例,用例用来描述系统应能实现的独立功能，实现用例就是在系统内部实现用例中所描述 的动作，通过把用例描述的动作转化为对象之间的相互协作，完成用例的实现。UML中实现用例的基本思想是用协作表示用例，而协作又被细化为用若干个图。协作的实现用脚本描述。具体内容是：用例实现为协作协作是实现用例内部依赖关系的解决方案.通过使用类、对象、类（或对象）之间的关系（协作中的关系称为上下文）和它们之间的交互实现需要的功能（协作实现的功能又称交互）。协作的图示符号为椭圆，椭圆内部或下方标识协作的名字。,实现用例,协作用若干个图表示 表示协作的图有协作图、序列图和活动图。这些图用于表示协作中的类（或对象）与类（或对象）之间的关系和交互。在有些场合，一张协作图就完全能够反映出实际用例的协作画面，而在另一些场合，只有把三种不同的图结合起来，才能反映协作状况。协作的实例脚本脚本是用例的一次具体执行过程，它代表了用例的一种使用方法。当把脚本看作用例的实例时，对角色而言，只需描述脚本的外部行为，也就是能够完成什么样的功能，而忽略完成该角本的具体细节，从而达到帮助用户理解用例含义的目的：当把 脚本看作协作的实例时，则要描述脚本的具体实现细节（利用类、操作和它们之间的通信）。,实现用例,实现用例的主要任务是把用例描述中的各个步骤和动作变换为协作中的类、类的操作和类之间的关系。具体说来，就是把用例中每个步骤所完成的工作交给协作中的类来完成。实质上，每个步骤转换成类的操作，一个类中可以有多个操作。注意，一个类可以用来实现多个用例，也就是，一个类可以集成多种角色。比如，自动售货系统中，负责“供货”和“提取货款”的角色就可以定义为同一个类(当然,从安全角度讲,最好不要定义为同 一个类)。,实现用例,用例和它的实现（即协作）之间的关系可以用精化关系表示（图示为带箭头的点画线）也可以用CASE工具中的不可见的超链实现。使用CASE工具中的超链，能方便地将用例视图转换为协作或脚本。下图表示一个用例的实现，从图中可以看出若干个类加到了协作中。为了实现用例，用例描述中的每个步骤的职责还需转换为类与类之间的协作（用关系和操作描述）。,实现用例,实现用例,若想成功地利用类表示用例描述，需要借助开发者的经验。通常，开发者必须反反复复地多次试验各种不同的可能情况，逐步完善解决方案，使该方案能够实现用例描述且灵活易扩展。如果将