第二章-UML建模基础知识

第2章UML建模基础知识本章要点：UML的基本元素视图和图的概念基础内容：理解静态视图和动态视图重点掌握：各种图的表示和作用一般了解：UML发公共机制2.1UML语言的构成

UML由视图(views)、图(Diagrams)、模型元素(Modelelements)和通用机制(generalmechanism)等几个部分构成。视图用来表示被建模系统的各个方面（从不同目的出发建立，为系统建立多个模型，这些模型都反映同一个系统，且具有一致性）。视图由多个图构成，是在某一个抽象层次上对系统的抽象表示。图由各种图片构成，用来描述一个视图的内容。UML语言定义了9种不同的图的类型，把它们有机结合起来就可以描述系统的所有视图模型元素代表面向对象中的类、对象、消息和关系等概念，是构成图的最基本的常用概念。通用机制用于表示其他信息，比如注释、模型元素的语义等。另外，它还提供扩展机制，使UML语言能够适应一个特殊的方法（或过程）、或扩充至一个组织或用户。2.2UML的基本元素

事物是UML模型中面向对象的基本元素和模块，它们在模型中属于静态部分。事物是模型中最具有代表性的成分的抽象。在UML中定义了4种基本的面向对象的事物：结构、行为、分组和注释。2.2.1结构一、类(Class)UML中的类完全对应于面向对象分析中的类，它具有自己的属性和操作。一个类可以实现一个或多个接口。类的可视化如图2-1所示。二、接口(Interface)接口由一组对操作的定义组成，但它不包括对操作的实现进行详细的描述。接口用于描述一个类或构件的一个服务的操作集。接口描述了元素的外部可见的操作。接口很少单独存在，往往依赖于实现接口的类或构件。接口的图形表示如图2-2所示。三、协作(Collaboration)协作是对一个交互过程的定义，它是由一组共同工作以提供协作行为的角色和其他元素构成的一个整体。协作行为大于所有元素行为的总和。一个类可以参与到多个协作中，协作表现了系统构成模式的实现。协作的符号如图2-3所示。四、用例(UseCase)用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统发生的一段对话。用例的符号如图2-4所示。五、主动类(ActiveClass)

主动类能够有自动的启动控制活动，每个主动类的对象都由它自己的事件驱动控制线程，控制线程与其他主动类对象并行执行。被主动对象所调用的对象是被动对象。它们只在被调用时接受控制，而当它们返回时将放弃控制。被动对象被动地等待其他对象向它发送请求，这些对象所描述的元素行为与其他元素的行为并发。主动类的可视化表示和一般类的表示很相似，特殊的地方在于其外框为粗线。六、构件(Component))构件是系统中物理的、可替代的部件，它遵循且提供一组接口的实现。七、节点(Node)节点是系统在运行时切实存在的物理对象，表示某种可计算资源。这些资源往往具有一定的存储能力和处理能力。一个节点可以代表一台物理机器，或代表一个虚拟机器节点。2.2.2行为行为是指UML模型的相关动态行为，是UML模型的动态部分。行为在模型中通常用动词来表示，如“注册”、“销毁”等。可把行为划分为两类，分别是交互和状态机。一、交互(Interaction)交互是指一组对象为共同完成一定任务而进行的一系列消息交换而组成的动作以及消息交换过程中形成的消息机制。交互的可视化表示主要是通过消息来表示。消息的表示方法如图2-7.二、状态机状态机是一个类的对象所有可能的生命历程的模型，因此状态机可用于描述一个对象或一个交互在其生命周期内响应时间所经历的状态序列。当对象探测到一个外部事件后，它依照当前的状态做出反应，这种反应包括执行一个相关动作或转换到一个新的状态中去。

状态机的可视化表示如图2-8所示。2.2.3分组UML通过包这种分组来实现对整个模型的组织。包在概念上是一种对UML模型中各个组成部分进行分组的机制，它只存在于系统的开发阶段。在包中可以包含结构、行为和分组。包的表示方法如图2-9所示。2.2.4注释

注释是UML模型的解释部分，用于进一步说明UML模型中的其他任何组成部分。可以用注释来描述模型中的任何元素。注释是依附于某个元素或一组建模元素之上，对这个或这一组建模元素进行约束或解释的简单注释符号。注释的一般形式是简单的文本说明。注释的符号表示如图2-10所示，在方框内填写需要注释的内容。2.3UML中的关系

UML模型是由各种事物以及这些事物之间的各种关系构成的。关系是指支配、协调各种模型元素存在并相互使用的规则。

UML中主要包含4种关系：依赖、关联、泛化和实现。一、依赖关系依赖关系指的是两个事物之间的一种语义关系，当其中一个事物（独立事物）发生变化时就会影响另一个事物（依赖事物）的语义。见图2-11。二、关联关系关联关系是指事物之间的一种结构关系，在系统开发中经常使用，系统元素之间的关系如果不能明显地由其他三类关系来表示，都可以被抽象为关联关系。关联关系可以是聚集、组成，也可以是没有方向的普通关联关系。聚集是一种特殊类型的关联，它描述了整体和部分之间的结构关系；组成也是一种关联关系，描述了整体和部分间的结构关系，只是部分是不能离开整体而独立存在的。见图2-12三、泛化关系泛化关系是指事物之间的一种特殊/一般关系，特殊元素（子元素）的对象可替代一般元素（父元素）的对象，也就是在面向对象中提及的继承。子元素具有父元素的全部结构和行为，并允许在此基础上再拥有自身特定的结构和行为。见图2-13。四、实现关系实现关系也是UML元素之间的一种语义关系，它描述了一组操作的规约和一组对操作的具体实现之间的语义关系。在系统开发中，通常在两个地方需要使用实现关系，一种是用在接口和实现接口的类或构件之间；另一种是在用例和实现用例的协作之间。见图2-14。思考练习题

假设你正在设计一个能显示公司全体成员的制表系统，公司的员工可填写这个系统中的表格。在你的设计中，有一个系统类和一个Form(表格)类。在系统类的众多操作中有一个displayForm类，系统所要显示的表格取决于用户选择的表格。这个设计的UML表示法是属于哪种关系？学生可以参加多个学生社团组织？旅客列车由火车头和若干车厢组成，车厢分为软席、硬席、软席卧铺和硬席卧铺四种？汽车类含客车与货车两个子类？冷藏车既继承货车的特性“载货”，又继承冷藏设备的特性“冷藏”？2.4UML中的视图和图UML是用模型来描述系统的结构或静态特征以及行为或动态特征的。它从不同的视角为系统的架构建模形成系统的不同视图(View)。它是表达系统某一方面特征的UML建模构件的子集。在每一类视图中使用一种或两种特定的图来可视化地表示视图中的各种概念。即视图是由一个或多个图组成的对系统某个角度的抽象。2.4.1视图视图模型按照逻辑观点对用领域中的概念建模，可以划分成三种视图域，分别是结构分类、动态行为和模型管理。一、结构分类描述了系统中的结构成员及其相互关系。类元包括类、用例、构件和节点。类元视图包括静态视图、用例视图、实现视图以及部署视图。二、动态行为描述了系统随时间变化的行为。行为用从静态视图中抽取的瞬间值的变化来描述。动态行为视图包括状态机视图、活动视图和交互视图。三、模型管理说明了模型的分层组织结构。包是模型的基本组织单元。模型管理视图跨越了其他视图并根据系统开发和配置组织这些视图。

在UML中主要包括的视图为静态视图、用例视图、交互视图、实现视图、状态机视图、活动视图、部署视图和模型管理视图。一、静态视图静态视图在UML中的作用：静态视图是UML的基础静态视图构造了概念对象的基本结构静态视图是建立其他动态视图的基础二、用例视图用例视图描述了系统参与者与系统进行交互的功能，是参与者所能观察和使用到的系统功能的模型图。用例模型的作用是标识出系统中用例和参与者之间的联系，并确定什么样的参与者执行了哪个用例。用例使用系统与一个或多个参与者之间的一系列消息来描述系统的交互作用。三、交互视图交互视图描述了执行系统功能的各个角色之间相互传递消息的顺序关系，是描述系统中各种角色或功能交互的模型。通过不同对象间的相互作用来描述系统的行为是通过两种方式进行的：以独立的对象为中心进行描述以相互作用的一组对象为中心进行描述四、状态机视图状态机视图是通过对象的各种状态来建立模型以描述对象随时间变化的动态行为。状态机是通过不同对象间的相互作用来描述系统行为的，不同的是它以独立的对象为中心进行描述。五、活动视图活动视图是一种特殊形式的状态机视图，用来描述执行算法的工作流程中涉及的活动。通常活动视图用于对计算流程和工作流程建模。活动视图使用活动图来体现。活动图中包含了描述对象活动或动作的状态以及对这些状态的控制。活动图包含对象活动的状态。活动的状态表示命令执行过程中或工作流程中活动的运行。六、物理视图物理视图是对应有自身的实现结构建模，如系统的构件组织情况以及运行节点的配置等。包含了两种视图，分别是实现视图和部署视图。实现视图将系统中可重用的块包装成为具有可代替性的物理单元，这些单元被称为构件。实现视图用构件及构件间的接口和依赖关系来表示设计元素（如类）的具体实现。部署视图表示运行时的计算资源的物理布置。这些运行资源被称为节点。在运行时，节点包含构件和对象。实现视图使用构件图进行表示，部署视图使用部署图表示。七、模型管理视图模型管理视图是对模型自身组织进行的建模，是由自身的一系列模型元素（如类、状态机和用例）构成的包所组成的模型。模型是一种特殊的包，整个系统的静态模型实际上可看成是系统最大的包，它代表了系统的一个部分，它有清晰的接口。这个接口可作为一个单独的构件来实现。模型管理由包及包之间的依赖组成，模型管理信息通常在类图中表达。2.4.2图UML作为一种可视化的建模语言，其主要表现形式就是将模型进行图形化表示。最常用的UML图包括用例图、类图、序列图、状态图、活动图、构件图和部署图。一、用例图用例图描述了系统提供的一个功能单元。用例图的主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求，包括基于基本流程的“角色”关系，以及系统内用例之间的关系。使用用例图可表示出用例的组织关系。在用例图中画出某个用例方式是在用例图中绘制一个椭圆，然后将用例的名称放在椭圆的中心或椭圆下面的中心未知。在用例图上绘制一个角色的方式是绘制一个人形的符号。如图2-15：二、类图类图显示了系统的静态结构，表示了不同的实体是如何彼此相关联的。类图还可用于表示实现类，实现类就是程序员处理的实体。绘制类图时使用包含3个部分的矩形来描述。最上面的矩形部分显示类的名称，中间矩形部分显示了类的各种属性，下面的矩形部分显示了类的操作或方法。在类图中，需要注意的是对类与类之间关系的描述。类与类之间的关系通常有依赖、泛化和关联这3种关系。如果把接口也看成是一种类，那么还有实现关系，即类对接口的实现。如图2-16所示：三、序列图（顺序图）序列图显示了一个具体用例或者用例的一部分的详细流程。序列图不仅可以显示流程中不同对象之间的调用关系，还可以很详细地显示对不同对象的不同调用。序列图有两个维度：垂直维度（也称为时间维度，以发生的时间顺序显示或调用的序列）；水平维度（显示消息被发送到的对象实例）序列图的绘制：横跨图顶部的每个框表示每个类的实例或对象，在框中，类实例名称和类名称之间使用冒号分隔开来。如图2-17.若每个类实例向另一个类实例发送一条消息，则绘制一条具有指向接收类实例的开箭头的连线，并把消息或方法的名称放在连线上面，消息也分为不同的种类，即同步消息、异步消息、返回消息和简单消息等。四、状态图状态图表示某个类所处的不同状态以及该类在这些状态中的转换过程。状态图包括5个基本的元素：初始起点使用一个实心圆来绘制状态之间的转换使用具有开箭头的线段来绘制状态使用圆角矩形来绘制判断点使用空心圆来绘制；使用判断点可以根据不同的条件进入不同的状态。一个或多个终止点使用内部包含实心圆的圆来绘制。五、活动图活动图是用来表示两个或更多对象之间在处理某个活动时的过程控制流程。活动图更适合对较高级别的过程建模，活动图的符号集与状态图中使用的符号集非常类似，但也有差别。活动图的初始活动也是由一个实心圆开始的；结束图是由一个内部包含实心圆的圆来表示；活动图是通过圆角矩形来表示的；活动可通过活动的转换线段连接到其他活动中，或者连接到判断点，根据判断点的不同条件执行不同的动作。在活动图中，出现了“泳道”的概念，使用泳道来表示实际执行活动的对象。六、构件图构件图提供系统的物理视图，它是根据系统的代码构件显示系统代码的整个物理结构。其中构件可以是源代码组件、二进制组件或可执行组件。一般来说，构件图最经常用于实际的编程工作中，构件图为系统架构提供了一个为解决方案进行建模的自然形式，如图2-20所示。七、部署图部署图用于表示该软件系统如何部署到硬件环境中，它是显示在系统中的不同的构件在何处物理运行以及如何进行彼此的通信。部署图对系统的物理运行情况进行了建模，因此系统的生产人员能够很好地利用这种图来部署实际的系统。在部署图中显示的节点内，包含了如何在节点内部分配可执行的构建和对象，以显示这些软件单元在某个节点上的运行情况，并且部署图还可以显示各个构件之间的依赖关系。系统的部署图从系统的物理结构的节点显示了属于该节点的构件，然后使用构件图显示该构件中包含的类，接着使用交互图显示该类的对象参与的交互，最终到达某个用例。2.5UML的公共机制在UML中，规格说明、修饰、通用划分和扩展机制这4种公共机制贯穿于整个统一建模语言。2.5.1UML的规格描述模型元素实例需要附加的相关规格说明来添加模型元素的特性，实现的方法是在某个模型元素上双击，然后在弹出的关于该元素的规格说明窗口对话框，在这个窗口内显示了该元素的所有特性。2.5.2UML的修饰在UML的图形表示中，每一个模型元素都有一个基本符号，这个基本符号可视化地表达了模型元素最重要的信息。用户也可把各种修饰细节加到这个符号上以扩展其含义。例如，在用例图中可以使用如图2-13所示的圆来表达业务实体，该表示方法相对于参与者的表示发生了颜色和图形的明显变化。还有一种“注解”修饰符，是一种非常重要的并且能够单独存在的修饰符，可以将它附在模型元素或元素集上用来表示约束或注解信息。如图2-24所示。2.5.3UML的通用划分通用划分是一种保证不同抽象概念层次的机制。一般采用两种方式进行通用划分：（1）对类和对象的划分是指类是一个抽象而对象是这种抽象的一个实例化（2）对接口和实现的分离是指接口声明了一个操作接口，但却不实现其内容，而实现则表示对该操作接口的具体实现，它负责如实地实现接口地完整语义。2.5.4UML的扩展机制

为了在细节方面对模型进行准确的表达，UML设计了一种简单的、通用的扩展机制，用户可以使用扩展机制对UML进行扩展和调整，以便使其与一个特定的方法、组织或用户相一致。

U