UML语言学习教程.pptx

学习目标：l深刻理解面向对象分析方法的内涵，理解面向对象分析的基本概念，包括对象、类、消息、继承、多态和封装，掌握面向对象分析方法的任务和具体过程。l理解统一建模语言（UML）,了解其产生及特点；理解UML的构成，理解视图、图、模型元素和通用机制的作用及应用场合。l熟练掌握统一过程下UML建模的具体过程，了解UML分析建模的机制。l灵活应用UML建模工具，能熟练使用Visio和Rational Rose工具绘制分析图表。2023/4/141第五章第五章 面向对象分析与建面向对象分析与建模模第1页/共135页2023/4/1425.1 5.1 面向对象分析面向对象分析 5.1.1 面向对象方法的基本概念和过程1.面向对象的基本概念（1）对象 所谓对象，即客观世界中所存在的实体。一张桌子，一个人或一本书都可被认为是一个对象。为用计算机解决客观世界中的问题，软件系统将它们映射为程序中的部件，并继续称之为对象。第2页/共135页2023/4/1435.1 5.1 面向对象分析面向对象分析 （1）对象 对象在面向对象系统中具有双重含义。对象首先是构成程序的基本要素，即程序系统中一个模块，它包括所解决问题的数据类型（数据的属性和数据结构）和这些数据所具有的行为（对这些数据施加的操作）。对象是所求解的问题空间中某个事物的化身（即抽象），对象中的数据部分用以刻画该事物的静态属性，对象中的行为部分用以描述该事物的动态特征，即对问题的处理过程。对象的行为特征（即操作过程）在面向对象程序设计中被称作方法（Method），就像传统程序设计中的函数、过程等。通过对象，一个事物的属性和行为被封装成一个整体，形成一个构造部件。第3页/共135页2023/4/1445.1 5.1 面向对象分析面向对象分析 （1）对象 从另一层含义来看，对象是类的实例（Instance），即是一个有特定状态的具体化的类，它可以被理解为程序运行时内存空间的一个基本运行实体，即按相应定义所占用的一块内存空间，就像传统程序设计中变量被定义后在内存中占据相应的空间一样。第4页/共135页2023/4/145 （2）类 类是对象的抽象。一个类定义了大体上相似的一组对象。类是对象的定义和描述。一个类所包含的方法和数据是用来描述一组对象的共同行为和属性。通过类来抽象对象的共同特点、描述对象的相似属性，存储对象的一致行为，是面向对象技术最重要的特征。从形式和定义说明上看，类很像传统程序设计中的结构，同时包含了传统程序设计中数据定义和功能实现的构造。5.1 5.1 面向对象分析面向对象分析 第5页/共135页2023/4/146（3）消息 消息是对象之间的通信机制，是访问类中所定义的行为的手段。当一个消息发送给某一个对象时，即要求该对象产生某些行为。所要求产生的行为包含在发送的消息中。对象接收到消息后，给予解释并产生响应。这种通信过程叫消息传递（Message Passing）。5.1 5.1 面向对象分析面向对象分析 第6页/共135页2023/4/147 （4）继承性 继承性是不同类层次之间共享数据和方法的手段，是软件重用的一种机制，可使软件开发不必都从头开始。对一个新类的定义和实现，可以建立在已有类的基础上。把已经存在类中的数据和方法作为自己的内容，并加入自己特有的新内容。类的层次结构在概念分析上源于对事物不同层次的抽象，而在具体实现上却依赖继承机制。5.1 5.1 面向对象分析面向对象分析 第7页/共135页2023/4/148（4）继承性 当 两 个 类 产 生 继 承 关 系 后，原 有 的 类 被 称 为 父 类(Parent Class)，新定义的类被称作子类(Children Class)。若子类只继承一个父类，则称为“单重继承”(Single Inheritance)；若一个子类继承多个父类，则称为“多重继承”(Multiple Inheritance)。继承性是面向对象语言区别于与其它语言最主要的特点。5.1 5.1 面向对象分析面向对象分析 第8页/共135页2023/4/149 （5）多态 多态是指具有多种形式。不同对象在收到同一消息后产生不同的结果，这一现象叫多态。在使用多态时，系统发出一个通用消息，而实现的细节由收到消息的对象自行决定。这样，同一消息就可产生不同的调用方法。5.1 5.1 面向对象分析面向对象分析 第9页/共135页2023/4/1410 （5）多态 多态的实现受到继承性和动态联编的支持，利用类继承的层次关系，把具有通用功能的消息放在高层次，而不同的实现这一功能行为放在较低的层次，在这些层次上生成的对象能够给通用消息以不同的响应。5.1 5.1 面向对象分析面向对象分析 第10页/共135页2023/4/1411 （6）封装 封装是指对象可以拥有内部变量和处理，并将内部实现细节隐藏起来的能力。封装将对象封闭起来，管理着对象的内部状态。因而封装的实质是信息隐藏，它的基本单位是对象。封装和抽象是处理对象的两个相反的方面。抽象一般用来描述对象所具有的外部特征，包括对象的外部接口和外部功能等；外部接口将对象的封装与抽象联系起来；在一般的面向对象系统中，封装是通过类的定义说明来实现的。5.1 5.1 面向对象分析面向对象分析 第11页/共135页2023/4/14122、面向对象的系统开发过程面向对象的软件系统开发及生命周期与传统软件生命周期基本上一致，也可分为分析、设计、实现、测试和维护几个过程。当然，每个阶段所使用的方法和产生的结果与传统方法是不同的。各阶段的工作以类为核心，对对象、类进行分析和设计，各阶段的区别就在于对类的细化程度不同。同时，在面向对象的开发过程中，往往采用统一过程（RUP）作为过程管理的模型。5.1 5.1 面向对象分析面向对象分析 第12页/共135页2023/4/14135.1.2 5.1.2 面向对象分析的任务面向对象分析的任务 1、面向对象分析的内容 面向对象分析（Object-Oriented Analysis，OOA）是在系统开发过程中完成了系统业务调查以后，按照面向对象的思想来分析问题。面向对象的分析是面向对象的系统开发的重要环节。OOA的主要任务是：通过对问题空间的分析，识别并确定其中（问题空间）的对象和属性，建立其中对象之间的类别联系和层次关系。第13页/共135页2023/4/14145.1.2 5.1.2 面向对象分析的任务面向对象分析的任务使用面向对象的分析方法进行分析大致应完成如下五个方面的基本内容(1)确定对象和类(2)确定结构(3)确定主题(4)确定属性(5)确定方法和消息关联第14页/共135页2023/4/14152、面向对象分析的原则（P181）(1)抽象 (6)关联(2)封装(7)消息传递(3)继承(8)粒度控制(4)分类(9)行为分析(5)聚合5.1.2 5.1.2 面向对象分析的任务面向对象分析的任务第15页/共135页2023/4/14165.1.3 5.1.3 面向对象分析的方法面向对象分析的方法20世纪80年代末至90年代中期，面向对象分析和设计方法出现了一个蓬勃发展的时期，主要的面向对象分析和设计建模语言都出现在这个时期。在10年左右的时间内，其数量达到50多种，其中最引人注目的是Booch 1993、OOSE和OMT-2等。第16页/共135页2023/4/14175.1.3 5.1.3 面向对象分析的方法面向对象分析的方法Grady Booch是面向对象方法最早的倡导者之一，他提出了面向对象软件工程的概念。1993年，Booch将面向Ada的工作扩展到面向对象设计领域。Booch 1993比较适合于系统的设计和构造。第17页/共135页2023/4/14185.1.3 5.1.3 面向对象分析的方法面向对象分析的方法Jim Rumbaugh等人提出了面向对象的建模技术（OMT）方法，采用了面向对象的概念，并引入各种独立于语言的表示符。这种方法用对象模型、动态模型、功能模型和用例模型，共同完成对整个系统的建模，所定义的概念和符号可用于软件开发的分析、设计和实现的全过程，软件开发人员不必在开发过程的不同阶段进行概念和符号的转换。OMT-2特别适用于分析和描述以数据为中心的信息系统。第18页/共135页2023/4/14195.1.3 5.1.3 面向对象分析的方法面向对象分析的方法Ivar Jacobson于1994年提出了OOSE方法，其最大特点是面向用例（Use case），并在用例的描述中引入了外部角色的概念。用例的概念是精确描述需求的重要武器，但用例贯穿于整个开发过程，包括对系统的测试和验证。OOSE比较适合支持商业工程和需求分析。第19页/共135页2023/4/14205.2 5.2 统一建模语言（统一建模语言（UMLUML）5.2.1 UML的产生及特点 1、统一建模语言的产生 在面向对象方法的应用中，多种建模方法的存在带来了一些问题。用户无法区别不同语言间的差别，难于找到适合其应用特点的语言；此外，各种建模语言之间的差别妨碍了应用间的交流。因此，有必要在不同建模语言上，建立一种通用的建模语言，统一建模语言（UML，Unified Modeling Language）正是这一要求的产物。第20页/共135页2023/4/14215.2 5.2 统一建模语言（统一建模语言（UMLUML）2、UML的特点 作为基于面向对象开发的通用图形化建模语言，UML定义良好、易于表达、功能强大且普遍适用，它不仅支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。第21页/共135页2023/4/14225.2.2 UML5.2.2 UML的构成的构成1.视图2.图3.模型元素4.通用机制第22页/共135页2023/4/14231.1.视图视图一个系统可从不同的角度进行描述，从一个角度观察到的系统称为一个视图（Views）。在UML中，通过不同视图从某个角度对系统进行观察和描述，从而表达系统各个方面的特征。视图由一个或者多个图组成，它是在某一个层次上对系统的抽象表示。在建立一个系统模型时，通过定义多个反映系统不同方面的视图，从而对系统做出完整的观察和描述。第23页/共135页2.图视图由图组成，UML通常提供9种基本的图，这些图是用例图、类图、对象图、状态图、活动图、时序图、协作图、构件图和部署图。这些基本的图从不同方面描述所分析系统的细节特征。其中，状态图和活动图合称为行为图，时序图和协作图合称为交互图。为了组织以上的图，还可使用包图将以上的基本图形组成一个组，表达对尺度为一个子系统规模的问题所进行的分析和设计。2023/4/1424第24页/共135页2023/4/14253.3.模型元素模型元素在UML中，通过模型元素（Model elements）反映事物和事物之间的联系。其中，事物是指一般的面向对象概念，如类、对象、接口、消息和构件等。事物之间的关系能够把事物联系在一起，组成有意义的结构模型。常见的联系包括关联关系、依赖关系、泛化关系、实现关系和聚合关系。同一个模型元素可以在不同的UML图中使用，并在所有这些图中具有相同的意义和表示符号。第25页/共135页2023/4/14264.4.通用机制通用机制通用机制（General mechanism）可以为模型元素提供额外的注释、信息或语义。这些通用机制同时提供扩展能力，以允许用户对UML进行扩展，从而适应对某些特定的方法、过程、组织或用户建模的需要。第26页/共135页2023/4/14275.2.3 5.2.3 视图视图 1、UML 模型描述系统的角度 (1)系统的使用实例：使用实例从系统外部参与者的角度描述系统的功能。(2)系统的逻辑结构和功能：逻辑结构和功能描述系统内部的静态结构和动态行为，即从内部描述如何设计实现系统功能。(3)系统的物理结构：描述系统由哪些构件组成。(4)系统的处理过程和并发特性：描述系统执行过程中的控制机制和并发性，解决执行过程中存在的各种通信和同步问题。(5)系统的部署：描述系统的软件和硬件设备之间的部署关系。第27页/共135页2023/4/14285.2.3 5.2.3 视图视图逻辑视图实现视图过程视图部署视图用例视图图图5-1 UML中的视图中的视图第28页/共135页2023/4/1429用例视图用例视图用例视图从系统的外部参与者角度描述系统应具有的功能，即被称为参与者的外部用户所能观察到的功能。用例是系统中的一个功能单元，可以认为是参与者与系统之间的一次交互作用。参与者可以是一个用户或者是另一个系统。客户需求被作为多个用例进行描述，一个用例就是客户的一项功能需求。用例模型列出系统中的用例和参与者，并说明哪个参与者参与了哪个用例的执行。第29页/共135页2023/4/1430逻辑视图逻辑视图逻辑视图描述用例视图中提出的系统功能的逻辑实现，它在逻辑层次上（即不考虑系统具体的代码层的实现方法），通过描述系统的静态结构和动态行为说明系统应具有结构和功能细节。第30页/共135页2023/4/1431过程视图过程视图过程视图表示系统内部的控制机制，它主要考虑资源的利用、代码的执行以及系统环境中异步事件的处理，并处理线程之间的通信和间步。常用类图描述过程结构，用状态图、协作图，以及活动图描述过程行为。第31页/共135页2023/4/1432构件视图构件视图构件视图通过模块的组织结构说明系统的实现特征。构件是不同类型的代码模块，它是构造应用的软件单元。构件视图描述系统的实现模块以及它们之间的依赖关系。构件视图中也可以添加构件的其他附加的信息。第32页/共135页2023/4/1433部署视图部署视图部署是指将系统配置到由计算机和设备组成的物理结构上。部署视图显示系统的物理部署，它描述位于节点上的运行实例的部署情况。例如一个程序或对象在哪台计算机上执行，执行程序的各节点设备之间是如何连接的。第33页/共135页2023/4/14345.2.4 5.2.4 图（图（P186P186）UML通过9种图形符号来表示分析、设计的结果，这些图形符号和相应的定义性文字说明一起构成面向对象分析和设计的模型表示。1.用例图 6.时序图 2.类图 7.协作图 3.对象图 8.构件图 4.状态图 9.部署图 5.活动图第34页/共135页2023/4/14355.2.5 5.2.5 模型元素模型元素 UML中的模型元素包括事物和事物之间的联系。在UML中，事物代表任何可以定义的东西。事物之间的关系能够把事物联系在一起，组成有意义的结构模型。每一个模型元素都有一个与之相对应的图形元素。第35页/共135页2023/4/14361.1.事物事物 UML中的事物可分为结构事物、动作事物、分组事物和注释事物4类。这些事物是UML面向对象建模的基本要素，在模型中属于静态部分，代表物理上或概念上的元素。第36页/共135页2023/4/14371.事物 结构事物结构事物共有7种，它们是类、接口、协作、用例、活动类、构件和节点。第37页/共135页2023/4/14381.事物动作事物 动作事物是UML模型中的动态部分，代表某个时间和空间上的发生的动作。其中，交互和状态机是UML模型中两个最基本的动作事物元素，它们通常和其他的结构元素、主要的类、对象连接在一起。第38页/共135页2023/4/14391.1.事务事务分组事物分组表示模型中事物的组织部分，分组事物用包来表示。包是一种将有组织的元素分组的机制，结构事物、动作事物和其他的分组事物都可以放在一个包中。与构件不同，包只存在于开发阶段，不能存在于运行阶段。第39页/共135页2023/4/14401.事务注释事物注释（Note）事物是UML模型的解释部分，用于对建模元素进行附加说明。注释采用自由文本的形式，UML不对注释进行解释。第40页/共135页2023/4/14412.事物间的关系 UML中事物间的关系有关联关系、依赖关系、泛化关系、实现关系和聚合关系。第41页/共135页（1）关联关系2023/4/1442关联关系关联关系连接元素和链接实例，用连接两个模关联关系连接元素和链接实例，用连接两个模型元素的实线表示，在关联的两端可以标注关型元素的实线表示，在关联的两端可以标注关联双方的角色和多重性标记，如图联双方的角色和多重性标记，如图5-12所示。所示。图图5-12 关联关系关联关系第42页/共135页（2）依赖关系2023/4/1443依赖关系依赖关系 依赖关系描述一个元素对另一个元素的依附。依依赖关系描述一个元素对另一个元素的依附。依赖关系用源模型指向目标模型的带箭头的虚线表赖关系用源模型指向目标模型的带箭头的虚线表示，如图示，如图5-13所示。所示。图图5-13 依赖关系依赖关系第43页/共135页（3）泛化关系2023/4/1444泛化关系泛化关系 泛化关系也称为继承关系，它表示一个元素是另泛化关系也称为继承关系，它表示一个元素是另一个元素的特例。泛化用一条实线表示，该实线一个元素的特例。泛化用一条实线表示，该实线的箭头是空心的。箭头的方向由特殊性事物的模的箭头是空心的。箭头的方向由特殊性事物的模型元素指向一般性事物的模型元素，如图型元素指向一般性事物的模型元素，如图5-14所所示。示。图图5-14 泛化关系泛化关系第44页/共135页（4）实现关系2023/4/1445实现关系实现关系 实现关系表示一个元素实现另一个元素。实现关实现关系表示一个元素实现另一个元素。实现关系用一条带空心三角箭头的虚线表示，箭头从源系用一条带空心三角箭头的虚线表示，箭头从源模型指向目标模型，表示源模型元素实现目标元模型指向目标模型，表示源模型元素实现目标元素模型，如图素模型，如图5-15所示。所示。图图5-15 实现关系实现关系第45页/共135页（5）聚合关系2023/4/1446聚合关系聚合关系 聚合关系描述元素之聚合关系描述元素之间部分与整体的关系，间部分与整体的关系，即一个模型元素由几即一个模型元素由几个表示部分的模型元个表示部分的模型元素聚合而成。聚合关素聚合而成。聚合关系用一端带有空心小系用一端带有空心小菱形的直线表示，小菱形的直线表示，小菱形端连接表示整体菱形端连接表示整体事物的模型元素，另事物的模型元素，另一端连接表示部分事一端连接表示部分事物的模型元素，如图物的模型元素，如图5-16所示。所示。图图5-16 聚合聚合第46页/共135页2023/4/14475.2.6 通用机制（P191）UML中的通用机制使其变得更加简单，更易于使用。使用通用机制可以为模型元素提供额外的注释、信息或语义，还可以对UML进行扩展。通用机制可以在UML中的任何地方使用。1.修饰 2.注释 3.规格说明 4.通用划分 5.扩展机制第47页/共135页2023/4/1448 5.2.7 UML5.2.7 UML中的图在建模中的作用中的图在建模中的作用 利用UML的系统建模可对从分析到实现的整个系统开发过程给予支持。UML的系统建模从了解、熟悉用户业务的领域问题开始。用例模型建立之后，就应该进行类和对象的识别。静态建模之后，就要建立系统的动态模型。时序图显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互；协作图描述对象间的协作关系，协作图与时序图相似，显示对象间的动态合作关系。第48页/共135页2023/4/1449 5.2.7 UMLUML中的图在建模中的作用中的图在建模中的作用 下一步是对系统的代码部件的物理结构及各部件之间的依赖关系进行描述，并定义系统中软硬件的物理体系结构，这时使用构件图和部署图。在实际项目中，可能并不需要使用其中的全部模型元素。同时，由于这些模型元素本身也有内在的逻辑关系，可以根据实际需要选择所用的模型元素。第49页/共135页2023/4/14505.3 5.3 统一过程下的统一过程下的UMLUML建模（自建模（自学）学）统一过程（Rational Unified Process，RUP）是一种利用面向对象技术进行系统开发的过程模型。虽然RUP是一个通用过程框架，但它往往是和UML结合在一起，共同完成系统建模工作。RUP将建模工作分成若干工作流（Workflow），主要工作流种类有：需求捕获工作流 分析工作流 设计工作流 实现工作流 测试工作流 第50页/共135页2023/4/14515.3.1 5.3.1 需求捕获工作流需求捕获工作流 需求捕获通过对应问题的理解和分析，确立问题涉及的信息、功能和系统行为、将用户需求精确化、完全化。该工作流的重点在RUP的初始阶段和细化阶段，在细化阶段后期，需求捕获的工作量大幅下降。1.工作流需求捕获的工作流主要包括5个活动：确定参与者和用例、区分用例的优先级、详细描述一个用例、构造用户界面原型以及构造用例模型。2.阶段性成果需求捕获工作流中，主要的UML阶段性成果包括用例模型、参与者、用例、构架描述、术语表和用户界面原型。第51页/共135页2023/4/14525.3.2 5.3.2 分析工作流分析工作流在RUP中，分析的主要工作开始于初始阶段的结尾，是细化阶段的主要内容。细化阶段的另一项重要活动是捕获需求，分析工作与需求捕获在很大程度上重叠，在对系统进行需求捕获的同时往往会加入一些分析的内容。1.工作流分析工作流包括4个活动：构架分析、分析用例、分析类和分析包。2.阶段性成果该阶段主要阶段性成果包括分析模型、分析类、用例实现（分析）、分析包和构架描述。第52页/共135页2023/4/14535.3.3 5.3.3 设计工作流设计工作流 设计工作流的主要工作位于细化阶段的最后部分和构造阶段的开始部分。系统建模最初的重点是需求和分析，在分析活动逐步完善后，建模的重点开始转向设计。1.工作流设计工作流中主要包括4种活动构架设计、用例设计、类设计和子系统设计。2.阶段性成果在设计工作流期间，包括设计模型、设计类、用例实现（设计）、设计子系统、接口、构架描述（设计和实施模型）。第53页/共135页2023/4/14545.3.4 5.3.4 实现工作流实现工作流 实现是把设计模型转换成可执行代码的过程，实现工作流是构造阶段的重要内容。1.工作流实现工作流包括构架实现、系统集成、子系统实现、类实现和执行单元测试。2.阶段性成果实现工作流有6种阶段性成果，它们是实现模型、构件、实现了的子系统、接口、构架描述（实现模型）和集成构造计划。第54页/共135页2023/4/14555.3.5 5.3.5 测试工作流测试工作流 在RUP中，测试工作开始于初始阶段，而细化阶段和构造阶段是测试的主要阶段。1.工作流测试工作包括6种活动，它们是制定测试计划、设计测试、实现测试、执行集成测试、执行系统测试和评估测试。2.阶段性成果测试工作流包括7个阶段性成果，它们是测试模型、测试用例、测试规程、测试构件、测试计划、缺陷和评估测试。第55页/共135页2023/4/1456 5.4 UMLUML分析建模（自学）分析建模（自学）5.4.1 用例建模 5.4.2 静态建模 5.4.3 动态建模 第56页/共135页2023/4/14575.4.1 5.4.1 用例建模用例建模 用例模型是由软件需求分析到最终实现的第一步，它描述人们希望如何使用一个系统，进而描述系统的功能需求，在宏观上给出模型的总体轮廓，描述的是外部参与者（即系统用户）所理解的系统功能。用例视图捕获系统、子系统或类的行为，通过对典型用例的分析，它将系统功能划分成对参与者有用的需求，使开发者能够有效地了解用户的需求。第57页/共135页2023/4/14585.4.1 5.4.1 用例建模用例建模1.用例模型的组成元素用例模型由若干个用例图构成。用例图包含参与者、系统边界、用例、参与者与用例间的关联等建模元素，如图5-18所示。图图5-18 用例图用例图第58页/共135页2023/4/14595.4.1 5.4.1 用例建模用例建模 2.参与者及其识别 (1)什么是参与者 (2)参与者的类型 (3)参与者的识别 (4)参与者的描述第59页/共135页2023/4/1460参与者参与者参与者以一个人型图符来表示，参与者用的名字写人形图符的下面。参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。第60页/共135页2023/4/1461参与者的类型参与者的类型可以有三类角色充当参与者，它们是用户、与本系统有关联的其他系统以及一些可以运行的进程。其中第一类参与者是真实的人，是最常用的参与者。第二类参与者是其他的系统，如与本系统存在交互的银行系统等。这些往往在当前系统的范围之外，需要建立与这些系统的接口。第三类参与者是一些可以运行的进程，如时间。当经过一定时间触发系统中的某个事件 时，时间就成了参与者。例如，在销售系统中，到了一定时间就要启动客户付款业务。由于时间不在人的控制之内，因此它也是一个参与者。第61页/共135页2023/4/1462参与者的识别参与者的识别可以通过回答以下的问题进行识别。谁将使用该系统的主要功能？谁将需要该系统的支持以完成其工作？谁来维护、管理并保持该系统的运行？本系统需要与哪些系统交互？本系统需要控制哪些硬件设备？谁将使用本系统的输出结果？第62页/共135页2023/4/1463参与者的识别参与者的识别对于系统而言，参与者总是外部的，所以用例无法控制参与者的内部。参与者是人或事物与系统交互时的角色，而不是特定的人或事物。参与者由参与用例时所担当的角色来表示，它往往由用户来承担，但它不同于用户：第63页/共135页2023/4/1464参与者的识别参与者的识别一个用户往往可承担几种角色，而一个参与者也可能由几个不同的用户来承担。每个参与者可以参与一个或多个用例，通过交换信息与用例发生交互。参与者可以本系统交互，或使用本系统提供的服务完成某个事务。第64页/共135页2023/4/1465参与者的描述参与者的描述识别参与者角色后，从需求规格说明的要求出发，可以为每个角色给出文字描述和说 明。这时，应每一个参与者必须有简短的描述，可以用一组定义其状态的属性充分描述参与者。第65页/共135页2023/4/14663.3.参与者间的关系参与者间的关系 参与者是一个类，而不是类的实例。定义了一个参与者，实际上即定义了一个类。这样，在参与者之间可以通过使用类之间的关系来表示参与者间的关系。参与者之间的泛化关系用一个三角箭头来表示，箭头由具体参与者指向扮演抽象参与者的超类，这与UML中类之间的泛化关系符号相同。第66页/共135页图图5-20 参与者的泛化关系及其实例参与者的泛化关系及其实例第67页/共135页2023/4/14684.4.用例与用例的确定用例与用例的确定用例用来描述参与者可以感受到的完整的功能，其用途是在不揭示系统内部构造的前提下定义连贯的行为。第68页/共135页2023/4/14694.4.用例与用例的确定用例与用例的确定UML将用例定义为“由系统执行的一个动作序列，并能产生可观察的结果值给某个特定的参与者”。这里的动作可以包括与参与者间的通讯、执行计算以及系统内部的工作等。用例确定首先要弄清系统的问题域、业务流程，梳理系统的功能需求，在此基础上结合已经识别的角色，并确定和描述用例。第69页/共135页2023/4/14704.4.用例与用例的确定用例与用例的确定可以通过以下几个问题帮助进行判断：某个参与者要求系统为其提供什么功能？参与者需要创建、销毁、更新或存储系统中的某些信息吗？系统中的事件一定要告知参与者吗？参与者需要告诉系统一些什么吗？系统内部的事件从功能的角度代表什么？由于新功能的识别，参与者的日常工作被简化或效率提高了吗？上面是针对已经识别的参与者，下面的问题针对系统：系统需要什么样的输入/输出？输入来自哪里?输出去哪里？该系统的当前情况存在哪些主要问题？第70页/共135页2023/4/14715.5.用例场景用例场景用例对应并描述一个完整的功能，由一定的业务步骤组成，其中还会涉及业务的变化、出错以及异常情况，这些就是用例场景。用例场景需要以一定的方式加以描述，从而形成一个完整的用例。用例场景通常包括简要说明、前置条件、主事件流、其他事件流和后置条件。第71页/共135页2023/4/14725.5.用例场景用例场景（1）简要说明 描述该用例的作用，包括执行用例的不同类型用户和通过这个用例要达到的结果。第72页/共135页2023/4/14735.5.用例场景用例场景（2）前置条件 前置条件是用例执行之前必须满足的前提条件。例如，前置条件是另一个用例已经执行或用户具有运行当前用例的权限，但并不是所有用例都有前置条件。第73页/共135页2023/4/14745.5.用例场景用例场景（3）主事件流和其他事件流 用例的具体细节在主事件流和其他事件流中描述。事件流是从用户角度描述执行用例的具体步骤，关注系统“做什么”，而不是“怎么做”。主事件流和其他事件流包括：用例如何开始和结束、用例如何与参与者交互、用例的正常流程（主流程）、正常流程的扩展、变化和错误流（其他事件流）。第74页/共135页2023/4/14755.5.用例场景用例场景 （4）后置条件 后置条件是用例执行完毕后必须为真的条件。与前置条件一样，后置条件可以增加用例次序方面的信息，如要求一个用例执行后必须执行另一个用例，就可以在后置条件中进行说明。当然，并不是每个用例都有后置条件。第75页/共135页2023/4/14766.6.用例间的关系用例间的关系在用例图中，用例间可具有多种关联，通过这些关联，可以从系统中抽取出公共行为及其行为变化，从而简化用例图。分为：(1)包含关系 (2)扩展关系 (3)泛化关系 第76页/共135页2023/4/14776.6.用例间的关系用例间的关系（1）包含关系 很多用例可以用其他的更简单的用例来描述。一个用例可以简单地包含其他用例具有的行为，并把该行为作为自身行为的一部分，这就是包含关系（Include）。这时，新用例（包含其他用例的用例）不是初始用例（被包含的用例）的一个特殊例子，所以不能被初始用例所代替。第77页/共135页2023/4/14786.6.用例间的关系用例间的关系（1）包含关系 在UML中，包含关系表示为虚线箭头加字样，箭头指向被包含的用例，填写订单验证订单图图5-22 用例间的包含关系用例间的包含关系第78页/共135页2023/4/14796.6.用例间的关系用例间的关系（2）扩展关系 一个用例也可以被定义为基础用例（Base use case）的增量扩展，它和基础用例的关系就是扩展关系（Extend），扩展关系是把新的行为插入到己有用例中的方法。同一个基础用例的几个扩展用例可以在一起使用。基础用例的扩展增加了原有的功能，系统应用的是基础用例而不是扩展用例，在应用基础用例时，只有当某些条件成立，或某些情况发生时，才会同时就用扩展用例的功能。第79页/共135页2023/4/14806.6.用例间的关系用例间的关系（2）扩展关系 在UML中，扩展关系表示为虚线箭头加说明，箭头指向被扩展的用例（即基础用例）借书交纳罚金图图5-23 用例的扩展关系用例的扩展关系第80页/共135页2023/4/14816.6.用例间的关系用例间的关系（3）泛化关系 一个用例可以有一个或多个子用例，它们之间的关系就是用例泛化。在UML中，用例泛化与其他泛化关系的表示法相同，用一个带箭头的实线从子用例指向父用例第81页/共135页2023/4/14826.6.用例间的关系用例间的关系（3）泛化关系 销售网上销售门市销售图图5-24 用例间的泛化关系用例间的泛化关系第82页/共135页2023/4/14835.4.2 5.4.2 静态建模静态建模 1.UML的静态建模机制 静态建模反映系统的静态结构，支持系统的功能需求，也就是系统要提供给最终用户的服务。静态建模主要通过类图、对象图和包图表示。类图不仅定义系统中的类，描述类之间的联系，如关联、依赖和聚合等，还包括类的内部结构，即类的属性和操作。第83页/共135页2023/4/14845.4.2 5.4.2 静态建模静态建模类图中的组成元素类图用来描述类的结构及其相关内容，具体内容包括类、接口、协作以及它们之间关系，它是一种静态模型类型。类图不仅显示了系统内的信息结构，也描述了系统内的信息行为。第84页/共135页2023/4/14855.4.2 5.4.2 静态建模静态建模 类的属性及描述类的属性用来描述类所代表的事物的特性，这些特性是所有的对象所共有的。此外，属性值也可以用来描述对象的状态。第85页/共135页2023/4/14865.4.2 5.4.2 静态建模静态建模类的操作及可见性类的操作是对该类的对象实例所做事务的抽象，相当于一个服务的实现，且该服务可以由类的任何对象请求以影响其行为，操作表现为函数，往往需要使用属性数据。它们位于类的内部，并且只能应用于该类的对象。一个类可以有任何数量的操作，也可以没有操作。操作的可见性与属性可见性类似，但增加了一种包内公有（Package）属性，用符号“”表示。第86页/共135页2023/4/1487静态建模静态建模类的操作及可见性可见性的类型有公有（Public）、私有（Private）和受保护（Protected）3种。在UML中，公有可见性用“+”表示，说明该属性可以从该类的外部被访问，私有可见性用“”表示，说明不能从其他类中访问这个属性，受保护的可见性用“#”表示，它常常与泛化和特化一起使用。第87页/共135页2023/4/1488静态建模静态建模分析类分析模型中的所有类都是分析类，分析类展示“高层次”的对象和属性。分析类分为：(1)边界类 (2)控制类 (3)实体类第88页/共135页2023/4/1489静态建模静态建模边界类 边界类用于描述系统外部环境与内部运作之间的交互，主要负责内容翻译和形式的转换，并表达相应的结果。第89页/共135页2023/4/1490静态建模静态建模边界类 边界类主要用于描述三种类型的内容：用户界面，与外部系统的接口以及系统与设备的接口。不同类型边界的建模工作有所不同。例如，与外部系统接口建模主要关注通信协议，用户界面建模关注交互内容，即在概念上表述界面，而不是具体窗口构件。第90页/共135页2023/4/1491静态建模静态建模控制类 控制类用于描述一个用例所特有的事件流的控制行为，它自己不处理具体的任务，但它知道那些类有能力完成具体的任务。第91页/共135页2023/4/1492静态建模静态建模控制类 控制类将用例所特有的行为进行封装，具有良好的隔离作用。概念上，系统的其他部分（即边界类和实体类）将与用例的具体执行逻辑形成松散耦合。所以边界类和实体类通常具有跨越多个用例的通用性。第92页/共135页2023/4/1493静态建模静态建模实体类 实体类用于描述必须存储的信息及与信息存储相关的行为。实体类对应系统中的重要信息，这些信息通常需要长期保留。实体类主要的任务是装载信息，同时也具有行为，这些行为主要是那些和实体类自身信息直接相关的操作。第93页/共135页2023/4/1494静态建模静态建模接口接口是在没有给出对象的实现和状态的情况下对对象行为的描述。接口包含操作但不包含属性，也没有对外界可见的关联。一个类可以实现一个或多个接口，拥有良好接口的类具有清晰的边界。第94页/共135页2023/4/1495静态建模静态建模接口第95页/共135页2023/4/1496静态建模静态建模类之间的关系在UML中，类之间的关系有4种 (1)依赖关系 (2)泛化关系 (3)关联关系 (4)实现关系 第96页/共135页2023/4/1497静态建模静态建模依赖关系 在UML中，依赖用一个从客体（使用服务依赖者）指向主体（提供服务的被依赖者）的虚箭头表示，依赖又具有多种类型，UML使用构造型来区分这些类型。其中，UML定义了四种基本的构造型，他们是使用（Usage）依赖、抽象（Abstraction