UML用例图的画法
UML各种图例齐全—用例图、类图、状态图、包图、协作图、顺序图详细说明画法和功能
UML各种图例面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language™），这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association（或简称通讯communication）角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线.一个用例图是角色，用例，和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.决定特征（需求）.当系统已经分析好并且设计成型时，新的用例产生新的需求∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式：Cash，Check，或者Credit.订单包括OrderDetails（line item），每个这种类都连着Item.UML类的符号是一个被划分成三块的方框：类名，属性，和操作.抽象类的名字，像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association－表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中，关联用两个类之间的连线表示.dependencies关系.如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时（特别是递归关系时）很有用.这个类图示一个大学的Department可以包括其他很多的Departments.这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚，类或实例名可以在对象图中被省略.每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴，时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色.在序列图中，对象的角色放在上面而消息则是连接线.对象角色矩形上标有类或对象名（或者都有）.类名前面有个冒号（：）.协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号，再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN，另一个则在上Getting PIN.初始状态（黑色圆圈）是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用（/动作）表示.当进入Validating状态时，对象并不等外部事件触发转移.取而代之，它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说，我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.。
UML各种图例齐全—用例图、类图、状态图、包图、协作图、顺序图详细说明书画法和功能
UML各种图例面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language ™），这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成标准文档为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association（或简称通讯communication）标准文档角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线.一个用例图是角色，用例，和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.决定特征（需求）.当系统已经分析好并且设计成型时，新的用例产生新的需求标准文档∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式：Cash，Check，或者Credit.订单包括OrderDetails（line item），每个这种类都连着Item.标准文档UML类的符号是一个被划分成三块的方框：类名，属性，和操作.抽象类的名字，像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association－表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中，关联用两个类之间的连线表示.标准文档标准文档为了简单地表示出复杂的类图，可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型.dependencies关系.如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时（特别是递归关系时）很有用.这个类图示一个大学的Department可以包括其他很多的Departments.标准文档这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚，类或实例名可以在对象图中被省略.标准文档每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴，时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.标准文档协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色.在序列图中，对象的角色放在上面而消息则是连接线.标准文档对象角色矩形上标有类或对象名（或者都有）.类名前面有个冒号（：）.协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.标准文档我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号，再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及 Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.标准文档状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN，另一个则在上Getting PIN.初始状态（黑色圆圈）是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用（/动作）表示.当进入Validating状态时，对象并不等外部事件触发转移.取而代之，它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说，我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和 Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.标准文档标准文档标准文档。
UML用例图的绘制与分析
UML用例图的绘制与分析UML（Unified Modeling Language）是一种用于软件开发的建模语言，它提供了一种标准的图形化表示方法，用于描述系统的结构和行为。
其中，用例图是UML中最常用的图之一，用于描述系统的功能需求和用户之间的交互关系。
本文将介绍UML用例图的绘制与分析。
一、概述UML用例图是一种高层次的视图，用于表示系统中的参与者（Actor）和用例（Use Case）之间的关系。
参与者可以是人、其他系统或外部设备，用例则表示系统提供的功能。
用例图可以帮助开发人员和用户理解系统的功能需求，并提供一个沟通的桥梁。
二、绘制用例图绘制用例图的第一步是确定参与者和用例。
参与者是与系统交互的实体，他们可以是用户、其他系统或外部设备。
用例是系统提供的功能，它描述了系统完成的任务或目标。
在绘制用例图时，可以使用椭圆形表示参与者，使用矩形表示用例。
接下来，需要确定参与者和用例之间的关系。
一种常见的关系是关联关系（Association），表示参与者与用例之间的关联。
关联关系可以用实线箭头表示，箭头指向用例。
另一种关系是包含关系（Include），表示一个用例包含了另一个用例。
包含关系可以用虚线箭头表示，箭头指向被包含的用例。
还有一种关系是扩展关系（Extend），表示一个用例可以在另一个用例的基础上进行扩展。
扩展关系可以用虚线箭头表示，箭头指向被扩展的用例。
最后，可以添加注释和约束条件来完善用例图。
注释可以用于解释用例的功能或描述参与者的特征。
约束条件可以用于限制用例的执行条件或前置条件。
三、分析用例图用例图不仅仅是一种图形化的表示方法，它还可以用于分析系统的功能需求和用户之间的交互关系。
通过分析用例图，可以发现系统中可能存在的问题或改进的空间。
首先，可以通过用例图来识别系统的功能需求。
每个用例代表了一个系统功能，通过分析用例图，可以清楚地了解系统需要完成哪些任务或目标。
如果用例图中缺少一些重要的用例，说明系统的功能需求可能不完整，需要进一步补充。
用Visio画UML用例图
⽤Visio画UML⽤例图1、⽤例图⽤例图描述参与者所理解的系统功能。
主要元素是⽤例和参与者。
⽤例图的4个基本组件：参与者(Actor)、⽤例(Use Case)、关系(Relationship)和系统。
下⾯以银⾏储蓄系统为例。
（1）⽤例：⽤户和计算机系统间的⼀次交互，代表系统的⼀个完整功能，是⼀组动作序列。
系统执⾏完这组动作序列后将产⽣⼀个对参与者有价值的结果。
银⾏储蓄系统的⽤例：存款、取款、输⼊存款信息、打印存单、输⼊取款信息、打印余额......⽤例图中⽤椭圆表⽰。
（2）参与者：与系统交互的⼈或物。
银⾏储蓄系统的参与者：业务员、储户。
⽤例图中⽤⼩⼈表⽰。
（3）联系参与者和⽤例：通过<<communicate>>关系进⾏通信。
communicate是⼀种关联关系，是单向关联。
⽐如：业务员（⾓⾊）->取钱（⽤例），业务员是通信的启动者，业务员启动取钱⽤例。
参与者和参与者：如果参与者和参与者之间有关联，可以认为是⼀种泛化关系。
泛化关系就是⼀般类和特殊类之间的继承关系。
⽐如汽车和轮船，与交通⼯具是泛化关系。
它们同属交通⼯具，⽤具备各⾃的特点。
⽤例和⽤例：通常有泛化、包含（使⽤）和扩展。
⽤例泛化：⼀个⽤例可以被特别列举为⼀个或多个⼦⽤例。
"电话预订"和"⽹上预订"泛化为"预订"。
包含（使⽤）和扩展的表⽰是在依赖关系上加构造型，英⽂描述为：<<include>>(<<use>>)和<<extend>>。
银⾏储蓄系统：<<include>>关系：⼀个⽤例执⾏的功能总是包括被包含⽤例的特征。
在上图中，取款的⾏为序列就包含输⼊取款信息、检查余额、验证密码等⾏为序列，因此取款⽤例“包含”取款信息⽤例。
<<extends>>关系：⼀个⽤例的执⾏可能需要其他⽤例功能来扩展，但主要⽤途是使基本⽤例的功能不依赖于扩展⽤例。
UML-2-用例图
参与者情况分析
参与者情况分析
参与者情况分析
参与者情况分析
3.2 用例
Booch等人在1999年出版的Unified Modeling Language User Guide中将用例 定义为： “若干动作序列集合的描述，包括由系统 执行并产生可观察的、对某参与者有价值 的结果的变体” Rational统一过程(Rational Unified Process，RUP)将用例定义为： “一系列包含变量的动作描述，系统由此 对特定用户产生有价值的可见结果”
非功能 需求
发现参与者
参与者来源：涉众分析、客户的岗位设臵、 客户代表访谈。。。。。。 以下问题可以帮助确定参与者：
谁负责提供、使用和删除信息？ 谁将使用此功能？ 谁对某个特定的功能感兴趣？ 在组织中的什么地方使用系统？ 谁负责支持和维护系统？ 系统有哪些外部资源？ 其它还有哪些系统与该系统进行交互？
1 基于用例的系统行为建模
我们需要对PPS的需求进行细化，即把一个大 问题分解和抽象为若干个子问题 这些子问题就是我们的用例(Use Case)，用 例描述的是系统行为，UML用用例图来为系 统行为建模
2 用例图
用例图 (Use Case Diagram) 主要用于描述 系统的行为及各种功能之间的关系，是描述 参与者(Actors)与用例以及用例与用例之间关 系的图 用例图从用户和外部系统的角度，分析和考 察系统的行为，并通过参与者与系统之间的 交互关系描述系统对外提供的功能特性
在UML2.0中，参与者的符号被表示为图2-2 的形式：
《Actor》 planner
图2-2 UML2.0表示参与者的方法
3.1 参与者
图2-2中的<<Actor>>是一个构造型 (Stereotype)，表示当前的UML元素表达的 是参与者的概念
UML用例图的绘制技巧
UML用例图的绘制技巧UML（Unified Modeling Language）是一种用于软件系统的建模语言，它提供了一套标准的图形符号和规范，用于描述系统的结构和行为。
其中，用例图是一种常用的图示工具，用于描述系统的功能需求和用户之间的交互。
在绘制UML用例图时，我们需要掌握一些技巧，以确保图示的清晰、准确和易于理解。
本文将介绍一些常用的绘制技巧，帮助读者更好地应用UML用例图。
1. 确定系统边界在绘制用例图之前，我们需要明确系统的边界。
系统边界是指系统与外部实体之间的分界线，它定义了系统的范围和界限。
确定系统边界是用例图绘制的第一步，它可以帮助我们理清系统的功能和参与者之间的关系。
2. 识别参与者参与者是指与系统进行交互的外部实体，可以是人、其他软件系统或硬件设备等。
在绘制用例图时，我们需要识别所有的参与者，并将它们表示为图中的符号。
参与者通常以人的图标或简单的图形表示，以便于理解和识别。
3. 确定用例用例是指系统的功能需求，描述了系统与参与者之间的交互过程。
在绘制用例图时，我们需要明确系统的所有用例，并将它们表示为图中的椭圆形符号。
每个用例应该具有一个简洁明确的名称，以便于理解和识别。
4. 确定参与者和用例之间的关系参与者和用例之间的关系是用例图的核心内容。
在绘制用例图时，我们需要明确参与者与用例之间的关系，并将它们表示为图中的连线。
常见的关系有：关联关系（Association）、包含关系（Include）、扩展关系（Extend）等。
这些关系可以帮助我们理清系统的功能和参与者之间的交互流程。
5. 添加扩展和包含关系扩展和包含关系是用例图中的重要概念，用于描述用例之间的依赖关系。
扩展关系表示一个用例可以在另一个用例的基础上进行扩展，而包含关系表示一个用例可以包含另一个用例。
在绘制用例图时，我们可以使用带箭头的虚线来表示扩展关系，使用带箭头的实线来表示包含关系。
6. 使用注释和说明在绘制用例图时，我们可以使用注释和说明来提供额外的信息和解释。
UML中的业务用例图的绘制方法和实例分析
UML中的业务用例图的绘制方法和实例分析UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言，它提供了一套丰富的图形符号和规则，用于描述系统的结构、行为和交互。
其中，业务用例图是UML中的一种图示工具，用于描述系统的功能需求和用户与系统之间的交互。
本文将介绍业务用例图的绘制方法，并通过一个实例分析来说明其应用。
一、业务用例图的绘制方法业务用例图主要由参与者（Actor）和用例（Use Case）两个元素组成。
参与者是系统外部的角色，可以是人、其他系统或外部设备等，用例则是描述系统功能的场景。
下面是绘制业务用例图的步骤：1. 确定参与者：首先要明确系统与外部世界的交互角色，这些角色可以是系统的用户、其他系统或外部设备等。
2. 确定用例：根据系统的功能需求，确定系统需要提供的各个功能场景，每个场景都可以作为一个用例。
3. 绘制参与者和用例：使用UML中的图形符号，将参与者和用例绘制在图中。
参与者通常用人的图标表示，用例则用椭圆形表示。
4. 连接参与者和用例：使用关联线将参与者与用例连接起来，表示参与者与用例之间的交互关系。
一般来说，参与者可以触发用例的执行，也可以接收用例的输出。
5. 添加关系：根据实际情况，可以添加其他关系，如扩展关系、包含关系等，以更准确地描述系统的功能和交互。
二、实例分析为了更好地理解业务用例图的应用，下面以一个在线购物系统为例进行分析。
在这个系统中，主要涉及的参与者有顾客和管理员。
顾客可以进行商品浏览、商品搜索、添加商品到购物车、结算购物车等操作，管理员则可以进行商品管理、订单管理等操作。
根据上述分析，我们可以绘制如下的业务用例图：（图示：一个包含顾客、管理员和相关用例的业务用例图）从图中可以看出，顾客和管理员是系统的两个主要参与者，它们与系统之间存在着不同的交互。
顾客可以通过浏览商品和搜索商品来获取所需的商品信息，然后将商品添加到购物车，并最终结算购物车。
UML的9种图例的定义、用途、画法总结
1UML 的9种图例的总结一、 用例图1、 定义用例定义：用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
（这是UML 对用例的正式定义，可以这样去理解，用例是参与者想要系统做的事情，用例在画图中用椭圆来表示，椭圆下面附上用例名称）。
用例图定义：由参与者（Actor ）、用例（Use Case ）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。
2、 用途用例图（User Case ）是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
用例图主要的作用有三个：（1）获取需求；（2）指导测试；（3）还可在整个过程中的其它工作流起到指导作用。
3、 组成元素以及元素之间的关系说明用例图由参与者（Actor ）、用例（Use Case ）、系统边界（用矩形表示—注明系统名称）、箭头组成，用画图的方法来完成。
参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。
还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
系统边界是用来表示正在建模系统的边界。
边界内表示系统的组成部分，边界外表示系统外部。
系统边界在画图中用方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。
因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。
箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。
箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。
元素之间的关系：用例图中包含的元素除了系统边界、角色和用例，另外就是关系。
关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。
角色之间的关系：角色之间的关系。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
一．UML简介
UML（统一建模语言，Unified Modeling Language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。
它融入了软件工程领域的新思想、新方法和新技术。
它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。
在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。
其实简单的理解，也是个人的理解，UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。
二．用例建模简介
用例建模是UML建模的一部分，它也是UML里最基础的部分。
用例建模的最主要功能就是用来表达系统的功能性需求或行为。
依我的理解用例建模可分为用例图和用例描述。
用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。
用例描述用来详细描述用例图中每个用例，用文本文档来完成。
1．用例图
参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。
还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。
参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。
用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
这是UML对用例的正式定义，对我们初学者可能有点难懂。
我们可以这样去理解，用例是参与者想要系统做的事情。
对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。
用例在画图中用椭圆来表示，椭圆下面附上用例的名称。
系统边界是用来表示正在建模系统的边界。
边界内表示系统的组成部分，边界外表示系统外部。
系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。
因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。
箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。
箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。
2．用例描述
用例图只是简单地用图描述了一下系统，但对于每个用例，我们还需要有详细的说明，这样就可以让别人对这个系统有一个更加详细的了解，这时我们就需要写用例描述。
对于用例描述的内容，一般没有硬性规定的格式，但一些必须或者重要的内容还是必须要写进用例描述里面的。
用例描述一般包括：简要描述（说明）、前置（前提）条件、基本事件流、其他事件流、异常事件流、后置（事后）条件等等。
下面说说各个部分的意思：
简要描述：对用例的角色、目的的简要描述；
前置条件：执行用例之前系统必须要处于的状态，或者要满足的条件；
基本事件流：描述该用例的基本流程，指每个流程都“正常”运作时所发生的事情，没有任何备选流和异常流，而只有最有可能发生的事件流；
其他事件流：表示这个行为或流程是可选的或备选的，并不是总要总要执行它们；
异常事件流：表示发生了某些非正常的事情所要执行的流程；
后置条件：用例一旦执行后系统所处的状态；
三．用例图和用例描述设计实例
这里用我开发的一个家教网站来简单的分析用例图的画法和用例描述的写法。
这个网站我用UML完整的分析一下，以下我提取了用例图和用例描述的部分。
这个家教网站分为前台客户系统和后台管理系统。
前台客户系统的用例图如下：
后台管理系统用例图如下：
对于用例描述，篇幅有限，我在这里只列了后台管理系统中的网站公告发布这个用例的描述。
用例名称：网站公告发布
用例标识号：202
参与者：负责人
简要说明：
负责人用来填写和修改家教网站首页的公告，公告最终显示在家教网站的首页上。
前置条件：
负责人已经登陆家教网站管理系统
基本事件流：
1．负责人鼠标点击“修改公告”按钮
2．系统出现一个文本框，显示着原来的公告内容
3．负责人可以在文本框上修改公告，也可以完全删除，重新写新的公告
4．负责人编辑完文本框，按“提交”按钮，首页公告就被修改
5．用例终止
其他事件流A1：
在按“提交”按钮之前，负责人随时可以按“返回”按钮，文本框的任何修改内容都不
会影响网站首页的公告
异常事件流：
四．总结
其实用例建模并不是这么简单，它涉及到的知识还有很多，这里只是简单的介绍一下。