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 ）、系统边界（用矩形表示—注明系统名称）、箭头组成，用画图的方法来完成。
参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。
还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
系统边界是用来表示正在建模系统的边界。
边界内表示系统的组成部分，边界外表示系统外部。
系统边界在画图中用方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。
因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。
箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。
箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。
元素之间的关系：用例图中包含的元素除了系统边界、角色和用例，另外就是关系。
关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。
角色之间的关系：角色之间的关系。
UML中各种图的画法(全)
UML中各种图的画法(全)UML中各种图的画法(全)一、UML中基本的图范畴：在 UML 2 中有二种基本的图范畴：结构图和行为图。
每个 UML 图都属于这二个图范畴。
结构图的目的是显示建模系统的静态结构。
它们包括类，组件和（或）对象图。
另一方面，行为图显示系统中的对象的动态行为，包括如对象的方法，协作和活动之类的内容。
行为图的实例是活动图，用例图和序列图。
二、UML中的类图：1.类图的表示：类的 UML 表示是一个长方形，垂直地分为三个区，如图 1 所示。
顶部区域显示类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的（当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的）。
描述：顶部区域显示类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
当在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的（当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的）。
·类名：如果是抽象类，则采用斜体·类属性列表：name : attribute type 如 flightNumber : Integer，这是最常见的表达形式n ame : attribute type = default value 如balance : Dollars = 0，这是带有默认值的表达形式·类方法列表：name(parameter list) : type of value returned注意：在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的（例如，分钟，美元，等等）。
然而，用于生成代码的类图，要求类的属性类型必须限制在由程序语言提供的类型之中，或包含于在系统中实现的、模型的类型之中。
2.继承的表示：为了在一个类图上建模继承，从子类（要继承行为的类）拉出一条闭合的，单键头（或三角形）的实线指向超类。
uml建模用例图怎么画
uml建模用例图怎么画导语：UML用例图示属于UML建模中的一种特殊图形，它的正式定义对于初学者而言，似乎有些难懂。
但是其图形的绘制是有规律可寻，我们可以用专业的软件进行绘制。
免费获取免费UML建模软件：/software-diagram-tool/umldiagramsoftware/UML建模用例图用什么软件画？亿图图示软件可以设计好用的例图。
UML用例图实质上是将系统化的东西用图表可视化的方式来表达，降低读者的认知难度。
亿图软件是一款全类型的图形图表设计软件，它有一套齐全的UML绘图符号，帮助用户可以轻轻松松绘制出想要的用例图。
系统要求Windows 2000, Windows XP, Windows 2003, Windows Vista, Windows 7,Windows 8, Windows 10Mac OS X 10.10 +Linux Debian, Ubuntu, Fedora, CentOS, OpenSUSE, Mint, Knoppix, RedHat, Gentoo及更多亿图图示绘制“UML用例图”的特点1.齐全的符号：软件拥有齐全的绘图符号，帮助用户更高效率地进行绘图操作。
2.自动对齐功能：添加图框至画布时，软件会对图框进行识别，生成辅助线帮助用户对齐。
3.全屏演示：通过全屏演示，当电脑与投影设备连接时，此功能可用于会议或教学演示。
4.绘制更多图形：不仅可绘制UML用例图，还可以绘制状态图、活动图等，甚至是思维导图、组织结构图、流程图。
丰富的图形符号库助你轻松绘制UML用例图内置丰富的模板UML用例图模板UML用例图模板获取更多软件开发常用工具：/software-diagram-tool/。
用在线工具processOn画UML的用例图和时序图
⽤在线⼯具processOn画UML的⽤例图和时序图发现⼀个很不错的在线画图⼯具processOn,我⽤这个⼯具画了下我们此次羡慕的UML⽤例图
⽤例图
下⾯我们画下时序图
⾓⾊（Actor）
系统⾓⾊，可以是⼈、及其甚⾄其他的系统或者⼦系统。
对象（Object）
对象包括三种命名⽅式：
第⼀种⽅式包括对象名和类名；
第⼆中⽅式只显⽰类名不显⽰对象名，即表⽰他是⼀个匿名对象；
第三种⽅式只显⽰对象名不显⽰类明。
⽣命线（Lifeline）
⽣命线在顺序图中表⽰为从对象图标向下延伸的⼀条虚线，表⽰对象存在的时间
控制焦点（Focus of Control）
控制焦点是顺序图中表⽰时间段的符号，在这个时间段内对象将执⾏相应的操作。
⽤⼩矩形表⽰
消息（Message）
消息⼀般分为同步消息（Synchronous Message），异步消息（Asynchronous Message）和返回消息（Return Message）。
用rose画UML图（用例图，活动图）
⽤rose画UML图（⽤例图，活动图）
⽤rose画UML图（⽤例图，活动图）
⾸先，安装rose2003，电脑从win8升到win10以后，发现win10并不⽀持rose2003的安装，换了rose2007以后，发现也不可以。
解决途径：在虚拟机中安装（我装的是win xp的系统，安装的是rose2003）。
如果需要安装包，可以联系我。
此外，还有Visio2013的安装包等。
都有⽤过，不过还是觉得rose最好⽤了。
然后开始贴图吧！毕设做的电商购物系统的UML设计图。
⽤例图：
1.⽤户⽤例模型
2.系统管理员⽤例模型
3.订单⽤例模型
4.产品⽤例模型
5.⽹站管理⽤例模型
6.⽤户信息⽤例模型
7.分类⽤例模型
8.留⾔⽤例模型
活动图：
1.管理员⽂章管理活动图
1.⽤户获取商品活动图
时序图：
系统业务模块流程图：。
UML中的用例图绘制指南及注意事项
UML中的用例图绘制指南及注意事项引言：UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言，它提供了一套丰富的图形符号和规范，用于描述系统的结构、行为和交互。
其中，用例图是UML中最常用的图之一，用于描述系统的功能需求和用户与系统之间的交互。
本文将为读者介绍UML用例图的绘制指南及注意事项，帮助读者更好地理解和运用这一工具。
一、用例图概述用例图是用例驱动开发方法的核心，它能够帮助开发人员和用户之间更好地沟通和理解需求。
用例图主要由参与者（Actor）、用例（Use Case）和关系（Relationship）三个要素组成。
参与者指的是系统的外部用户或外部系统，用例则表示系统的功能需求，关系则描述参与者和用例之间的交互关系。
二、绘制用例图的步骤1. 确定参与者：首先需要明确系统的各个参与者，包括用户和外部系统。
参与者应该是与系统有直接交互的实体，例如管理员、用户等。
2. 识别用例：根据系统需求，识别出系统的各个功能需求，每个功能需求可以看作是一个用例。
用例应该能够描述系统的一个具体功能或者一个用户场景。
3. 绘制参与者和用例：在绘制用例图时，首先绘制参与者，然后绘制用例，用椭圆形表示。
参与者和用例之间可以用直线连接。
4. 添加关系：根据实际情况，添加参与者和用例之间的关系，常见的关系有关联（Association）、包含（Include）和扩展（Extend）等。
5. 完善用例图：根据需要，可以添加用例的详细描述、前置条件和后置条件等信息，以便更好地理解和使用用例图。
三、用例图绘制的注意事项1. 简洁明了：用例图应该尽量简洁明了，避免过多的细节和冗余信息。
只保留关键的参与者、用例和关系，以便更好地传达系统的功能需求。
2. 层次清晰：用例图应该有良好的层次结构，将不同的用例和参与者分组显示，以便更好地组织和理解系统的功能模块。
3. 一致性：用例图应该与系统的需求文档和其他模型保持一致，避免出现冲突和矛盾。
UML各种图画法总结
一．用例图用例模型是把应满足用户需求的基本功能(集) 聚合起来表示的强大工具。
用例模型的基本组成部件是用例角色和系统。
引入用例的主要目的是：确定系统应具备哪些功能这些功能是否满足系统的需求开发者与用户协商达成共识的东西为系统的功能提供清晰一致的描述，以便为后续的开发工作打下良好的交流基础，方便开发人员传递需求的功能为系统验证工作打下基础通过验证最终实现的系统能够执行的功能是否与最初需求的功能相一致保证系统的实用性从需求的功能用例出发提供跟踪进入系统中具体实现的类和方法检查其是否正确的能力特别是为复杂系统建模时常用用例模型构造系统的简化版本（也就是精化系统的变化和扩展能力使系统不要过于复杂）然后利用该用例模型跟踪对系统的设计和实现有影响的用例简化版本构造正确之后通过扩展完成复杂系统的建模图示用例图时既要画出三种模型元素，同时还要画出元素之间的各种关系（通用化关联依赖）用例代表的是一个完整的功能。
如何发现用例实际上从识别角色起发现用例的过程就已经已开始了对于已识别的角色通过询问下列问题就可发现用例●角色需要从系统中获得哪种功能角色需要做什么●角色需要读取产生删除修改或存储系统中的某种信息吗●系统中发生的事件需要通知角色吗或者角色需要通知系统某件事吗这些事件功能能干些什么●如果用系统的新功能处理角色的日常工作是简单化了还是提高了工作效率●还有一些与当前角色可能无关的问题也能帮助建模者发现用例例如●系统需要的输入/输出是什么信息这些输入/输出信息从哪儿来到哪儿去●系统当前的这种实现方法要解决的问题是什么也许是用自动系统代替手工操作UML 中的用例UML 中的用例用椭圆形表示用例的名字写在椭圆的内部或下方用例位于系统边界的内部角色与用例之间的关联关系或通信关联关系用一条直线表示用例和角色之间有连接关系用例和角色之间的关系属于关联association 又称作通信关联communication association，这种关联表明哪种角色能与该用例通信，关联关系是双向的一对一关系，即角色可以与用例通信，用例也可以与角色通信。
UML用例图画法
一、实验目的及内容1.实验目的1、掌握系统的功能描述、性能描述方法；2、掌握需求分析工具及常用模型；3、掌握需求分析的步骤和方法。
4、掌握用况建模2.实验内容创建一个用况模型，并画出用况图。
二、所用仪器、材料（设备名称、型号、规格等）PC机1台，建模工具PowerDesign15三、实验方法、步骤创建用况模型的步骤如下：（1）定义系统。
（2）确定执行者。
（3）确定用况。
（4）描述用况。
（5）定义用况间的关系。
（6）确认模型。
用况模型由用况图组成，用况图展示了执行者，用况以及它们之间的关系。
他们之间的关系有关联、扩展、包含、泛化等。
得到用况图如下：网吧计费系统网管用户系统设置管理在线电脑查询历史信息分配计算机登记用户信息上网下网查询消费信息执行者：Name Code Parent 用户用户Object-Oriented Model 'UseCases Definition_1' 网管网管Object-Oriented Model 'UseCases Definition_1'用况列表：Name Code Parent 上网上网Object-Oriented Model 'UseCases Definition_1' 下网下网Object-Oriented Model 'UseCases Definition_1' 分配计算机分配计算机Object-Oriented Model 'UseCases Definition_1' 查询历史信息查询历史信息Object-Oriented Model 'UseCases Definition_1' 查询消费信息查询消费信息Object-Oriented Model 'UseCases Definition_1'登记用户信息登记用户信息Object-Oriented Model 'UseCases Definition_1' 管理在线电脑管理在线电脑Object-Oriented Model 'UseCases Definition_1' 系统设置系统设置Object-Oriented Model 'UseCases Definition_1'用况与执行者之间的联系：Name Code Parent Destination Source Association_1 Association_1 Object-Oriented系统设置网管Model 'Use CasesDefinition_1'Association_2 Association_2 Object-Oriented管理在线电脑网管Model 'Use CasesDefinition_1'Association_3 Association_3 Object-Oriented查询历史信息网管Model 'Use CasesDefinition_1'Association_4 Association_4 Object-Oriented分配计算机网管Model 'Use CasesDefinition_1'Association_5 Association_5 Object-Oriented登记用户信息网管Model 'Use CasesDefinition_1'Association_6 Association_6 Object-Oriented用户上网Model 'Use CasesDefinition_1'Association_7 Association_7 Object-Oriented用户下网Model 'Use CasesDefinition_1'Association_13 Association_13 Object-Oriented用户查询消费信息Model 'Use CasesDefinition_1'四、实验结果分析、经验总结或结论通过本次实验，我学会了用况建模并用建模工具PowerDesign画出其用况图，创建用况模型需要进过确定执行者，确定用况，用况描述和定义用况之间的关系几个步骤，在实验中，在定义用况之间的关系时遇到了很多问题，不少问题也是出现在用况的确定中，不过通过老师的指导，问题最终也都得以解决，总的来说，掌握了创建用况模型的步骤，对用况图的画法有了清晰的认识。
ROSE绘制UML图的步骤
一使用ROSE绘制用例图的步骤1．创建用例图一般情况下，用例图是UML中要绘制的第一个图。
在用RATIONAL ROSE创建所用的模型之前，首先要新建一个工程。
新建工程可以点击【File->New】菜单项，选项卡【New】如图所示，用来选择新建模型时采用的摸板。
在此我们暂时不用摸板，选择Cancel。
要建立新的用例图，可以右键单击“Use Case View”节点，在弹出的菜单中选择【New->Use Case Diagram】菜单项，如下图所示。
此时，在“Use Case Diagram”树形结构下多了一个名为“NewDiagram”的图标，这个图标就是新建的用例图标。
右键单击次图标，在弹出菜单中选择【Rename】菜单项，可以为用例图重新命名。
最好为用例图模型取一个有意义的名字。
双击用例图标，出现用例图的编辑区和编辑工具栏，如图所示，左边是用例图的编辑工具栏，右边是用例图的编辑区2．用例图工具栏按纽简介选择一项添加文本框添加注释将图中的元素与注释连接起来包用例参与者关联关系依赖和实例化泛化关系3．工具栏的定制用户可以根据需要自行定制和添加工具栏中的图标，操作方法如下：右键单击工具箱的空白处（注意不要点到图标按纽），在弹出的菜单中选择【Customsize】菜单项后出现“自定义工具栏”对话框4．添加参与者与用例（1）绘制参与者和用例，参与者和用例的绘制方法相同，首先点击工具栏中的图标按纽，然后在编辑区要绘制的地方单击鼠标左键，如下说示显示了一个参与者和一个用例（2）设置用例的属性。
在用例上双击，弹出用例属性设置对话框，如图所示。
在对话框的“General”选项卡中可是设置用例的名称“name”，用例的类型“Stereotype”，用例的层次“rank”，以及对用例的问档说明“documentation”。
（3）设置参与者的属性。
参与者的属性设置跟用例的设置一样。
5．添加参与者与用例的关系参与者与用例的关系为关联关系，要绘制关联关系。
电子商务系统分析与设计0301UML用例图绘制
5
19:46
练习3
6
图书馆管理系统是对书籍的借阅及师生信息进行统一管 理的系统，具体包括读者的借书、还书、书籍预订；
图书馆管理员的书籍借出处理、书籍归还处理、预订信 息处理；
还有系统管理员的系统维护，包括增加书目、删除或更 新书目、增加书籍、减少书籍、增加读者账户信息删除 或更新读者账户信息、书籍信息查询、读者信息查询等。
复习
1
UML有哪些特点？ UML有哪些功能？ UML包含哪些视图？ 用例图主要由哪些元素组成？ 用例图中涉及哪些关系？ 如果你根据一组需求绘制用例图，你会分为哪几步呢？
19:46
2
1 用例图关系
用例图中涉及的关系有：关联、泛化、包含、扩展。
19:46
2 如何绘制用例图呢？
基本步骤
19:46
第一题答案
7
班级信息管理用例图
成绩管理用例图 19:46
8
网上选课用例图
账号管理用例图
19:46
第二题答案
显示是否有饮料 选择饮料
自动售货机 收钱
付款 找钱 提供饮料
顾客
9
19:46
第三题答案
10
19:46
11
19:46
1.ONE
2.TWO
识别 参与者
确定 用例
3
3.THREE
构建用 例模型
19:46
实例
4
4.7 实例“学生信息管理系统”的需求
（1）系统管理员登录后可以对班级的基本信息进行增加、删除、 修改、查询等操作。学校领导登录后可以对班级基本信息进行查询 操作。
（2）教师登录后可以对学生的考试成绩进行录入、删除、修改、 查询等操作。学生登录后可以对考试成绩进行查询操作。
第06章UML用例图ppt课件
基于这些信息的高层用例图。这些用例就构成了该 局域网系统的功能需求。
6.4.4 进一步深化
详细论述这些高层用例中的一个，并建立一个用 例模型。咨询公司中最重要的一项活动是书写提案。 因此检验一下“Create a proposal〞这个用例。
与某个顾问面谈，他就能通知他这个用例中的许 多步骤。首先，用例的发起者是一个顾问。顾问要登 录到局域网，并作为一个有成效户被验证。然后他运 用办公软件套件(包括文字处置软件包、电子表格软 件包以及绘图软件包等)来书写提案。在这个过程中， 顾问能够要重用一部分以前的提案。咨询公司的
上一章“引见用例〞中还给出了用例“Buy soda 〞的一些可选的场景。在详细描画中，可以分别列出 这些场景，或者把它们作为用例根本场景的扩展来思 索。详细怎样做需求根据客户、用户和他对问题的了 解。
要阐明一个场景中的步骤，还可以运用UML活动 图对场景进展描画(这部分内容将在 “活动图〞一章 中讨论)。
6.2.1 包含
上一章中的“Restock〞和“Collect〞用例都从 开锁和拉开销售机的门开场，都以关门和上锁终了。 第1步建立了“Expose the inside(翻开销售机)〞用例， 并且第2步创建了“Unexpose the inside (封锁销售机) 〞用例。“Restock〞和“Collect〞两者都包含了这 两个新用例。
6.1 用例模型的表示法
用例是由参与者发起的，参与者(也许是发起 者，但不是必需的)可以从用例的执行中获得有价 值的事物。用例模型的图形表示法很直观。用例 用一个椭圆形表示，直立人形图标表示参与者。 用例的发起参与者在用例图的左侧，接纳参与者
在用例图的右侧。参与者的名字放在参与者图标的下方， 用例的名字可以放在椭圆形里面也可以放在椭圆形下面。 关联线衔接参与者和用例，并且表示参与者与用例之间有 通讯关系。关联线是实线，和类之间的关联线类似。
UML第一次作业：UML用例图绘制
UML第⼀次作业：UML⽤例图绘制UML⽤例图绘制⼀、plantuml⽤例图语法⼩结1.⽤例⽤法：⽤例⽤圆括号（），或者使⽤关键字来定义⽤例⽰例1：@startuml(First UML)(Another UML)as(UC1)usecase WTLusecase(Last UML)as UC2@enduml2.⾓⾊⽤法：⽤两个冒号包裹来表⽰，或者通过关键字actor来定义⾓⾊⽰例2@startuml:First role::Another\role:as NO1actor wtlactor:last role:as NO2@enduml3.⽤例描述⽤法：⽤双引号来定义多⾏的⽤例描述，--，==为分隔符⽰例3@startumlusecase UC1 as"You can useplantuml to write your uml.--Several separators are possible.==And you can add titles:...wtl...This allows large description."@enduml4.连接⽤法：⽤箭头连接⾓⾊和⽤例，横杠越多箭头越长，可以在箭头定义的后⾯加⼀个冒号来添加标签⽰例4@startuml:User:-->(Start):User:--->(Use the application):wtl:Main Admin:---->(Use the application):wtl@enduml5.继承⽤法：如果想要表⽰⾓⾊或者⽤例继承于另⼀个，可以⽤<|--符号表⽰⽰例5@startuml:Main Admin:as Admin(Use the application)as(use):wtl:<|--Admin(Start)<|--(Use)@enduml6.使⽤注释⽤法：可以使⽤note left of等关键字来给对象添加注释⽰例6@startuml:Main Admin:as Admin(Use the application)as(Use):User:->(Start):User:->(Use)Admin-->(Use)note right of Admin:wtlnote right of(Use)wtlend notenote"This note is wtl objects."as N2 (Start)..N2N2..(Use)@enduml7.构造类型⽤法：⽤<<>>来定义⾓⾊或者⽤例的构造类型⽰例7@startumlUser<< wtl >>:Main Database:as MySql<<wtl>>(Start)<< wtl >>(Use the application)as(Use)<< wtl >>Use->(Start)Use-->(Use)MySql-->(Use)@enduml8.改变箭头⽅向⽤法：可以⽤⼀个横杠或者点来表⽰⽔平连接，也可以通过翻转箭头来改变⽅向，还可以使⽤left，down等关键词来改变⽅向⽰例8@startuml:User:->(wtl):User:->(wtl2)@enduml9.从左向右⽅向⽤法:默认从上往下，可以⽤left to right direction来改变⽅向⽰例9@startumlleft to right directionwtl1-->(Usecase1)wtl2-->(Usecase2)@enduml三、绘制图书管理系统的UML⽤例图1.plantuml脚本：@satrtumlleft to right directionskinparam packageStyle rectangleactor 管理员actor 读者rectangle 图书馆系统{:管理员:-->(办理借阅卡):管理员:-->(办理借书):管理员:-->(整理图书):管理员:->(逾期处理):管理员:-->(破损罚款):读者:->(办理借阅卡):读者:-->(办理借书):读者:-->(逾期处理):读者:-->(破损罚款)}:读者:-->(归还图书)@enduml2.⽤例图：。
- 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：
在按“提交”按钮之前，负责人随时可以按“返回”按钮，文本框的任何修改内容都不
会影响网站首页的公告
异常事件流：
四．总结
其实用例建模并不是这么简单，它涉及到的知识还有很多，这里只是简单的介绍一下。