UML用例图

1. UML用例图

UML(Unified Modeling Language)，统一建模语言,又称标准建模语言，是为软件系统建立可视化模型。主要包括用例图、时序图、协作图、活动图、部署图、构件图、类图、状态图等等。
  
 之前有写过UML时序图： 产品经理必备之UML时序图 
  
 用例图（Use Case Diagrame）是UML的一种，主要用来描述用户、需求、系统功能之间的关系，能够充分展示一个外部用户能够观察的系统功能模型图，以一种可视化的直观方式理解系统的功能需求，以便使系统用户更容易理解这些元素的用途，也便于开发人员最终实现这些元素。
  
 用例图是跳出当前系统，站在用户的角度去看系统，思考系统功能，这样我们能更加理解业务，表达清楚需求。从用户的视角，我们不会使用专业术语去进行业务的沟通，可以做到真正以用户为中心去获取需求，转化为产品服务。
  
 用例图可以帮助我们更全面的考虑系统内事物之间的互相影响，关注整体的运行规律，而不是只考虑个别事物的情况。
                                                                                  
  1、参与者 ：是系统外部的一个实体，它以某种方式参与了用例的执行过程。参与者不一定是人，也可以是部门，也可以是外部系统，也可以是其他事物。通常用人形图标表示。
  
  2、用例 ：是对系统的用户需求（主要是功能需求）的描述，用例表达了系统的功能和所提供的服务，说明了系统是如何与最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。通常用椭圆表示。
  
 用例注意事项：
  
       用例粒度的确定，没有标准，只能根据实际情况分析。一个大型系统，可能会有上百个用例，一个小产品，也许只有几个用例。
  
       一个用例是一个完整的使用场景，不是零散的动作步骤。比如，拿起手机打电话是个完整的场景，拿起手机只是一个步骤。
  
       一个用例有一个明确、独立的目标，如果一个用例包括多个目标，则可再逐层细化出子用例。
  
  3、系统边界 ：将系统内外分开，参与者在外面，用例在里面。边界内的用例，就是系统要实现的事情。通常用矩形框表示。
  
  4、关系： 
  
 （1）关联关系：用一条实线表示，这条实线一般有三种形式：无箭头、有指向用例的箭头、有指向执行者的箭头。箭头的方向代表了数据流向或谁启动谁。
  
 （2）归纳（泛化）关系：表示参与者与参与者之间、用例与用例之间的关系。一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化。
  
         用带空心箭头的实线表示，箭头指向被泛化的用例，即子用例指向父用例，泛化是从下到上的过程。（子用例继承父用例所有的结构、行为和关系，是父用例的一种特殊形式。）
  
 （3）包含关系：表示用例与用例之间的关系，其中一个用例（父用例）的行为包含了另一个用例（子用例）的行为。
  
      用虚线箭头+表示，箭头指向被包含的用例。一般是父用例包含很大的范围，专门抽出子用例来着重表达，又或者是复用用例。
  
 （4）扩展关系：表示用例与用例之间的关系，是在特定条件下，由扩展用例指向被扩展用例。
  
       用虚线箭头+>字样，箭头指向被扩展的用例。拓展用例是在特定条件出现时，才会被执行的用例。
  
 1、不是每个需求都要画用例图，要视情况而定，简单的需求完全可以不用画。
  
 2、画图是为了表达、传递信息，当我们画用例图时，不管画的多么酷炫，本质都是在分析业务场景、系统功能性需求，并描述出来。
  
  阅读原文 
  
 对产品经理感兴趣的朋友，可以移步“ 需求管理 ”，期待共同交流。

2. 画UML用例图

下面是我的答案：

3. 一文读懂 UML 用例图

当你脑子里有一个商业案例时，你该怎么向老板介绍呢？一大段文字，或是动手写个 Demo？老板很忙，老板也不见得懂你所说的“高大上”技术，有没有那种实现成本较低但又包含较多信息的表现方式呢？有，画张图呗！
  
 今天起再开个专题，谈谈我们开发中常用到的一些图形建模手段。前言结束，我们从 UML 视图启航。
  
 UML——Unified Modeling Language——统一建模语言，是业务建模阶段最常用和最重要的一种视图。由于它简单易懂，常常用于跨组织的文档或演示的说明中；这里所谓的跨组织指的不仅仅是开发部门间，而是指跨产品、设计、测试、运维等等部门的业务交流中。UML 设计中，第一张图一般都是用例图：是的，就是那个有“小人”的图。
  
 用例图主要有三个部分组成：用例（Use Case）、参与者（Actor），以及它们互相间的关系（Relationship）；形式上就是用椭圆、小人，以及箭头的连线组合。
                                          
 我们先不细说椭圆或是箭头的具体含义。我觉得讲用例图最好还是从具体的 Use case 入手为好。我们试着设计一款简单的银行 APP，它包含注册、登陆、交易等等操作。我们一步步拆解挥着用例图的过程。
  
 画用例图的第一步通常是拖出一个巨大的矩形块，并将其命名为我们的目标系统——Banking App。一个用例图一般只会有一个 System，之后我们会把所有该系统相关的是功能（“用例”）放置在系统内部，系统的相关方（“参与者”）放置在系统的左右两侧。
                                          
 第二个绘制元素就是参与者，即系统相关方，可以是人、组织、外部设备，或是其他系统。在我们这个银行案例里，该 App 的相关方有两个：就是客户（Customer）和银行（Bank）。
                                          
 通常来说，一个用例图中会有两三个参与者，我们会把主要参与者放在系统左侧，次要参与者（主要参与者的回应方）放在右侧；显然我们的 App 主要是面向客户的，所以把客户放在了左边。
  
 第三步就是在系统内添加具体的用例，也就是该系统所提供的功能或是业务块。我们的银行 APP 比较简单，只提供如下业务：
                                          
 第四步，我们再把参与者与用例串联起来，就是我们所说的关系（Relationships）。用例图中，关系还可以继续细分：
                                                                                                                          
 最后，所有 UML 视图事实上都可以加注释，专业术语叫延伸（Extension points）和批注（Note）；这两种注释性质形同，都是起说明作用：
                                          
 好了，UML 用例图大体就讲完了。我们再回顾一下用例图的使用场景，在产品设计阶段，我们可以使用用例图为用户、系统和功能服务建立起抽象关系，以便描述产品所呈现的外部动态特征。在一些大厂中，通常由产品经理或是设计师来首先绘制 UML 用例图，再交于开发团队实现。
  
 我们举了一个银行 App 的例子，事实上有点大了；现实开发中，一个 Use Case 图通常只对应的一个简单的业务流而已。我们自己在写用例图时，也要注意在宏观层面将联系紧密的功能模块抽象为一个简单的 Case，然后逐步地为这些较大的功能模块画出细分 Case 的用例图。

4. UML类图的介绍

在UML的静态机制中类图是一个重点，它不但是设计人员关心的核心，更是实现人员关注的核心。建模工具也主要根据类图来产生代码。类图在UML的9个图中占据了一个相当重要的地位。James Rumbaugh对类的定义是：类是具有相似结构、行为和关系的一组对象的描述符。类是面向对象系统中最重要的构造块。类图显示了一组类、接口、协作以及他们之间的关系。在UML中问题域最终要被逐步转化，通过类来建模，通过编程语言构建这些类从而实现系统。类加上他们之间的关系就构成了类图，类图中还可以包含接口、包等元素，也可以包括对象、链等实例。接口在类图中通过版型来表示>，下面的介绍将主要介绍类，接口和类类似。

5. 如何绘制UML类图？

类图的属性和方法是指类本身的属性和行为，类及其属性和方法是在程序设计过程中产生的，类图只是用Visio绘制出来，用于项目团队成员间或项目干系人之间的沟通和交流。例如：如果要设计一个关于销售苹果的程序，苹果就可以看作一个实体（类），其基本属性有颜色、形状、味道、种类等，行为有开花、落果、膨大、成熟等行为。
下面给出绘制苹果类图的方法和步骤：
第一步：启动Visio2010或更高版本，如下图：

第二步：在模板类别中选择“软件和数据库”，进入选择模板窗口，如下图：

第三步：选择“UML模型图”，并用鼠标双击“UML模型图”图标，进入UML绘图窗口，如下图：

第四步：选择“UML静态结构”，如下图：

第五步：按下鼠标左键，拖动“类图标”，到工作区域窗口，如下图：

第六步：双击工作区域窗口的类框图，如下图：

第七步：在UML类属性窗口，可以修改类的名称，添加属性（特性）和操作（方法）

第八步：在UML类属性窗口，修改类名为“苹果”，如下图：

第九步：在UML类属性窗口，选择特性，分别输入苹果的颜色、形状、味道等属性，类型为数据类型，可以选择字符串、整型等，如下图：


第十步：在UML类属性窗口，选择操作，分别输入苹果的行为开花、落果、膨大、成熟方法，样例中方法名称用的中文，实际应用应该采用英文，如下图：

绘制完成的UML类图

6. UML类图的建立类图

在软件开发不同阶段使用的类图具有不同的抽象层次，即概念层、说明层、和实现层。使用UML进行应用建模也应该是一个迭代的过程，所以我们应该建立一个类图的层次的概念。概念层类图描述应用领域中的概念，这些概念与实现它们的类有联系。通常没有直接的映射关系。画概念层类图时很少考虑或不考虑实现问题，因此概念层类图应独立于具体的编程语言。下面是一个概念层类的表示。说明层类图。此时我们考察的是类的接口部分，而不是实现部分。这个接口可能因为实现环境、运行特性等有多种不同的实现。下面是一个说明层类的表示。实现层类图才真正考虑类的实现问题，提供实现的细节。此时的类的概念才应该是真正的严格意义上的类。它揭示了软件实体的构成情况。实现层的类是最常用的，在很多的时候说明层的类更有助于人们对软件的理解。UML的最终目标是识别出所有必须的类，并分析这些类之间的关系，类的识别贯穿于整个建模过程，分析阶段主要识别问题域相关的类，在设计阶段需要加入一些反映设计思想、方法的类以及实现问题域所需要的类，在编码实现阶段，因为语言的特点，可能需要加入一些其他的类。建立类图的步骤：（1）研究分析问题领域确定系统需求。（2）确定类，明确类的含义和职责、确定属性和操作。（3）确定类之间的关系。类的识别是一个需要大量技巧的工作，寻找类的一些技巧包括：名词识别法；根据用例描述确定类；使用CRC分析法；根据边界类、控制类、实体类的划分来帮助分析系统中的类；参考设计模式确定类；对领域进行分析或利用已有领域分析结果得到类；利用RUP中如何在分析和设计中寻找类的步骤。1. 名词识别法：这种方法的关键是识别系统问题域中的实体。对系统进行描述，描述应该使用问题域中的概念和命名，从系统描述中标识名词及名词短语，其中的名词往往可以标识为对象，复数名词往往可以标识为类。2. 从用例中识别类：用例图实质上是一种系统描述的形式，自然可以根据用例描述来识别类。针对各个用例，可以提如下的问题辅助识别：用例描述中出现了那些实体？用例的完成需要哪些实体合作？用例执行过程中会产生并存储哪些信息？用例要求与之关联的每个角色的输入是什么？用例反馈与之关联的每个角色的输出是什么？用例需要操作哪些硬设备？在面向对象应用中，类之间传递的信息数据要么可以映射到发送方的某些属性，要么该信息数据本身就是一个对象。综合不同的用例识别结果，就可以得到整个系统的类，在类的基础上，我们又可以分析用例的动态特性来对用例进行动态行为建模。3. 使用CRC分析法：CRC（Class,Responsibilities,Collaboration）卡的最大价值在于把人们从思考过程模式中脱离出来，更充分的专注于对象技术。CRC卡允许整个项目组对设计做出贡献。参与系统设计的人越多，能够收集到的好主意也就越多。因为CRC会议是大家全力参与的，通常只需要很少的有类名的卡片，实际上没有写出完整的卡片。CRC会议进行中，一些人模拟系统和对象交流，把消息传给其他的对象。通过一步步处理，问题很容易地被解决。它由三部分组成：类(Class)、职责(Responsibility)、协作(Collaborator)。下面是一个CRC卡的示例：  类名  职责1职责1的协作职责2职责2的协作…………职责是类需要知道或做的任何事物。这些职责是类自身所知的知识，或类在执行时所需的知识。协作是指为获取消息，或协助执行活动的其他类。创建CRC模型需要下面的步骤。1) 建立团队，包括客户、设计人员、分析人员和一个导引者。如果没有那么多人，那么可以是客户和你自己两个人。2) 找出需求中存在的名词和名词词组，特别注意复数（通常是集合），他们对应的单数才是。把你第一次想到的所有概念都写在白板或纸上。不管看起来这些概念是如何荒谬，把他们都写下来。3) 筛选。把对象分为三类，核心对象（必须首先实现），可选的（目前不能确定），以及不需要的对象。这之前最好确定一下你的项目范围。某些不属于本项目范围的对象可以使用轻量的adapter或proxy实现。这里可以加入对分析、设计模式的考虑和应用。4) 建卡。取出CRC卡，把核心类写在每一张卡上，把可选的类和排除的类分别写在不同的纸上。5) 角色扮演。最好是一个团队执行，一个人很难做。每个人负责几个类。对每一个Use case其中的情景。导引者指定从某一个人的类开始，某一个人看一看自己能够独立完成，如果不能完成，大家看一看手中的类，谁能完成，就站起来，宣布自己能够完成，以致继续这个过程，每个人完成自己的职责就坐下。在这过程中不断修改类的责任，并写下协作者的名字。4. 根据边界类、控制类、实体类帮助分析系统中的类UML中类有三种主要的版型：边界类、控制类和实体类。引入边界类、控制类及实体类的概念有助于分析和设计人员确定系统中的类。边界类位于系统与外界的交界处，窗体、报表、以及表示通讯协议的类、直接与外部设备交互的类、直接与外部系统交互的类等都是边界类。通过用例图可以确定需要的边界类，每个Actor/Use Case对至少要一个边界类，但并非每个Actor/Use Case对要唯一的边界类。实体类保存要放进持久存储体的信息。持久存储体就是数据库、文件等可以永久存储数据的介质。实体类可以通过事件流和交互图发现。通常每个实体类在数据库中有相应的表，实体类中的属性对应数据库表中的字段。控制类是控制其他类工作的类。每个用例通常有一个控制类，控制用例中的事件顺序，控制类也可以在多个用例间共用。其他类并不向控制类发送很多消息，而是由控制类发出很多消息。5. 领域进行分析建立类图的过程就是对领域及其解决方案的分析和设计过程。类的获取是一个依赖个人创造力的过程，有时需要和领域专家合作，对研究领域进行仔细分析，抽象出领域中的概念，定义其含义及相互关系，分析出系统类，并用领域中的术语为类命名。领域分析是：通过对某一领域中的已有应用系统、理论、技术、开发历史等的研究，来标识、收集、组织、分析和表示领域模型及软件体系结构的过程，并得到结果。

7. UML中状态图在哪些方面与类图，对象图，用例

标准建模语言UML的重要内容可以由下列五类图(共9种图形)来定义:
·第一类是用例图 
从用户角度描述系统功能,并指出各功能的操作者.
·第二类是静态图(Static diagram) 
包括类图、对象图和包图.其中类图描述系统中类的静态结构.不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作).类图描述的是一种静态关系,在系统的整个生命周期都是有效的.对象图是类图的实例,几乎使用与类图完全相同的标识.他们的不同点在于对象图显示类的多个对象实例,而不是实际的类.一个对象图是类图的一个实例.由于对象存在生命周期,因此对象图只能在系统某一时间段存在.包由包或类组成,表示包与包之间的关系.包图用于描述系统的分层结构.
·第三类是行为图(Behavior diagram) 
描述系统的动态模型和组成对象间的交互关系.其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件.通常,状态图是对类图的补充.在实用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图.而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动.
·第四类是交互图(Interactive diagram) 
描述对象间的交互关系.其中顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系.除显示信息交换外,合作图还显示对象以及它们之间的关系.如果强调时间和顺序,则使用顺序图;如果强调上下级关系,则选择合作图.这两种图合称为交互图.
·第五类是实现图( Implementation diagram ).其中 
构件图描述代码部件的物理结构及各部件之间的依赖关系.一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件.它包含逻辑类或实现类的有关信息.部件图有助于分析和理解部件之间的相互影响程度.
配置图定义系统中软硬件的物理体系结构.它可以显示实际的计算机和设备(用节点表示)以及它们之间的连接关系,也可显示连接的类型及部件之间的依赖性.在节点内部,放置可执行部件和对象以显示节点跟可执行软件单元的对应关系.
从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求;其次根据需求建立系统的静态模型,以构造系统的结构;第三步是描述系统的行为.其中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图(包含包)、对象图、组件图和配置图等五个图形,是标准建模语言UML的静态建模机制.其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系.它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言UML的动态建模机制.因此,标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类.

8. UML中状态图在哪些方面与类图，对象图，用例

标准建模语言UML的重要内容可以由下列五类图(共9种图形)来定义:
·第一类是用例图
从用户角度描述系统功能,并指出各功能的操作者.
·第二类是静态图(Static
diagram)
包括类图、对象图和包图.其中类图描述系统中类的静态结构.不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作).类图描述的是一种静态关系,在系统的整个生命周期都是有效的.对象图是类图的实例,几乎使用与类图完全相同的标识.他们的不同点在于对象图显示类的多个对象实例,而不是实际的类.一个对象图是类图的一个实例.由于对象存在生命周期,因此对象图只能在系统某一时间段存在.包由包或类组成,表示包与包之间的关系.包图用于描述系统的分层结构.
·第三类是行为图(Behavior
diagram)
描述系统的动态模型和组成对象间的交互关系.其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件.通常,状态图是对类图的补充.在实用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图.而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动.
·第四类是交互图(Interactive
diagram)
描述对象间的交互关系.其中顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系.除显示信息交换外,合作图还显示对象以及它们之间的关系.如果强调时间和顺序,则使用顺序图;如果强调上下级关系,则选择合作图.这两种图合称为交互图.
·第五类是实现图(
Implementation
diagram
).其中
构件图描述代码部件的物理结构及各部件之间的依赖关系.一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件.它包含逻辑类或实现类的有关信息.部件图有助于分析和理解部件之间的相互影响程度.
配置图定义系统中软硬件的物理体系结构.它可以显示实际的计算机和设备(用节点表示)以及它们之间的连接关系,也可显示连接的类型及部件之间的依赖性.在节点内部,放置可执行部件和对象以显示节点跟可执行软件单元的对应关系.
从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求;其次根据需求建立系统的静态模型,以构造系统的结构;第三步是描述系统的行为.其中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图(包含包)、对象图、组件图和配置图等五个图形,是标准建模语言UML的静态建模机制.其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系.它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言UML的动态建模机制.因此,标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类.