UML系统用例及用例关系

.Register UC001高客户、数据库客户在即时通信系统中注册客户端应用程序主界面已经启动1、客户单击"注册"按钮；2、系统弹出一个注册交互对话框；3、客户输入注册信息；4、客户单击"提交"按钮,发送注册信息到数据库；5、数据库保存注册信息,并自动生成一个数字ID 返回；6、客户端弹出对话框显示注册的ID,提示注册成功7、用例终止。

在单击"提交"按钮前,客户可随时单击"取销"按钮,关闭注册窗口,返回客户端界面提示注册错误,请稍后再试,客户确认,然后返回客户端主界面客户获得一个ID,可用此ID 登录系统开始即时通信Log in UC002高客户、服务器客户登录即时通信系统客户端应用程序主界面已经启动,并且已经有了注册ID1、客户输入ID 和密码；2、客户单击"登录"按钮,发送登录请求到服务器；3、服务器执行"验证用户"用例,将登录请求中的信息发送给数据库；4、数据库将ID 和密码与数据库中的注册记录比对；5、如果用户信息合法,数据库发送合法信息、用户的详细注册资料和用户不在线期间收到的离线消息给服务器,否则进入可选事件流。

6、服务器将客户加入在线用户列表,返回登录成功消息和离线消息给客户,并将在线用户列表发送给所有的在线用户。

7、提示登录成功,更新好友列表的状态信息并显示离线消息8、用例终止将用户不合法消息发送给客户,提示重新登录提示登录失败,请稍后再试,客户确认,然后返回客户端主界面主界面显示用户好友及好友的在线状态Send Message UC003高客户、数据库客户给自己的好友〔在线和离线发送消息客户已成功登录即时通信系统1、客户选择一个好友；2、系统激活主界面消息编辑文本框；3、客户在文本框中输入、编辑消息,然后单击"发送" 按钮；4、如果好友不在线,发送消息给数据库,数据库保存该聊天记录；否则执行可选事件流5、数据库返回聊天记录已保存的通知。

UML用例图与活动图的关联关系与应用场景解析在软件开发过程中，UML（Unified Modeling Language）是一种常用的建模语言，用于描述软件系统的结构和行为。

其中，用例图和活动图是UML中常用的两种图表，它们之间存在着紧密的关联关系，并且在不同的应用场景中有着各自的作用。

一、用例图和活动图的概述用例图是一种用于描述系统功能和用户之间交互的图表。

它通过用例（Use Case）和参与者（Actor）之间的关系来展示系统的功能需求。

用例图主要包括用例、参与者和它们之间的关系。

活动图是一种描述系统行为的图表。

它通过活动（Activity）、控制流（Control Flow）和决策节点（Decision Node）等元素来展示系统的流程和交互。

活动图主要用于描述系统的业务流程、用例场景和算法等。

二、用例图和活动图的关联关系用例图和活动图之间存在着紧密的关联关系。

用例图主要描述系统的功能需求，而活动图则描述了这些功能的实现过程。

在用例图中，一个用例可以对应多个活动图，而一个活动图通常对应一个用例。

具体而言，在用例图中，每个用例表示一个系统功能，而参与者则表示与系统交互的用户或外部系统。

用例图展示了用例和参与者之间的关系，以及用例之间的关系。

而在活动图中，每个活动表示一个具体的操作或业务流程，控制流表示活动之间的顺序和条件，决策节点表示根据不同情况做出的决策。

活动图可以作为用例图的补充，用于更详细地描述用例的执行过程。

通过活动图，可以清晰地展示用例中的各个步骤和流程，帮助开发人员更好地理解和设计系统。

三、用例图和活动图的应用场景用例图和活动图在软件开发中有着广泛的应用场景。

首先，用例图和活动图可以帮助开发人员更好地理解和分析系统需求。

通过用例图，可以明确系统的功能需求，梳理各个用例之间的关系，从而为后续的设计和开发工作提供指导。

而活动图则可以更详细地描述用例的执行过程，帮助开发人员更好地理解和分析系统的业务流程。

UML功能模型（⽤例图）在UML系统开发中有三个主要的模型：功能模型（从⽤户⾓度展⽰系统的功能，包括⽤例图）、对象模型（采⽤对象，属性，操作关联等概念展⽰系统的结构和基础，包括类图、对象图、包图）、动态模型（展⽰系统的内部⾏为，包括序列图，活动图，状态图）。

下⾯就说⼀说功能模型——⽤例图。

⽤例图是UML建模的⼀部分，也是UML⾥⾯最基础的部分，最主要的功能就是⽤来表达系统的功能性需求或⾏为。

⽤例图是由软件需求分析到最终实现的第⼀步，它描述⼈们如何使⽤⼀个系统，是尾部参与者所能观察到的系统功能模型图，该图呈现了⼀些参与者和⼀些⽤例，以及它们之间的关系，主要⽤于对系统、⼦系统或类的功能⾏为进⾏建模，⽤画图的⽅法来完成。

⽤例图展⽰了⽤例之间以及⽤例与参与者之间是怎样相互联系的。

⽤例图包含留个元素：参与者、⽤例、关联关系、包含关系、扩展关系、泛化关系。

参与者（Actor）：系统外部的⼀个实体，参与⽤例执⾏过程，通过向系统输⼊或请求系统输⼊某些事件来触发系统的执⾏。

参与者的种类概括为三种：系统⽤户、与所建造的系统交互的其他系统以及⼀些可以运⾏的进程。

注意：参与者表⽰⼈和事物与系统发⽣交互时所扮演的⾓⾊，⽽不是特定的⼈或特定的事物；每个参与者需要⼀个具有业务⼀样的名字；⼀个⼈或事物在与系统交互时，可以同时或不同时扮演多个⾓⾊。

⽤例（Use Case）：⽤例是对⼀个活动者使⽤系统的⼀项功能是所进⾏的交互过程的⼀个⽂字描述序列，是系统、⼦系统或类和尾部参与者交互动作序列的说明，包括可选的动作徐磊嗯哼会出现异常的动作序列。

⽤例是岱庙系统各种各个项⽬相关⼈员之间就系统的⾏为所达成的契约，软件开发过程是⽤例驱动的。

⽤例粒度（规模⼤⼩）。

关联关系（Association）：表⽰参与者⽤例之间进⾏通信包含关系（Include）：客户⽤例可以简单地包含提供者⽤例具有的⾏为，并把他所包含的⽤例⾏为作为⾃⾝⾏为的⼀部分。

调⽤⽤例执⾏到包含点，然后执⾏传递给被调⽤⽤例，当被调⽤⽤例完成时，控制在次返回调⽤⽤例。

《UML面向对象分析》课程实践项目报告项目名称：网上订购火车票系统项目组成员：学号：班级：指导教师：2008年 11 月 10 日目录1 需求分析 (1)1.1 需求概述 (1)1。

2 ................................... 需求分析11.3 需求模型（用例图） (5)2 静态模型 (6)2.1 类图 (6)2.2 对象图 (8)2.3 包图 (9)3 动态模型 (11)3。

1 ..................................... 时序图113.2 状态图 (13)3。

3 ..................................... 协作图143.4 活动图 (15)4 项目组成员分工说明 (16)5 总结 (17)6 参考资料 (18)1需求分析1.1 需求概述线上预订火车票系统是一款功能强大、操作简便、易维护的、具有良好人机交互界面的线上订票系统，它包括用户管理模块、系统参数设置模块、票务信息模块（提供票价、列车的实时信息）、订票管理模块（提供订票和退订功能）、实时信息提示模块(提供车况、路况、列车晚点等实时信息）、数据管理模块（提供数据备份、数据操作功能)。

实现火车票线上预定的自动化的计算机系统，为旅客提供准确、精细、迅速的火车票销售信息和方便、简单的订票功能。

线上预订火车票系统主要是对于订票信息的统一管理，满足了中小型线上订票网站对于用户的管理，订票信息的收集和处理方面的要求。

用现代化的方式取代以前的传统模式，更有利于信息的流通,资源的宏观管理。

具有体积小,代码简洁，易维护、易修改的优点.1.2 需求分析用户管理模块用户管理模块包括如下几个部分。

（1）添加用户信息：管理员可以对用户信息进行添加操作。

（4）修改用户信息权限：管理员可以修改用户的管理权限.（5）删除管理权限：管理员在权限管理中可以删除管理权限。

（6）添加管理权限：管理员在权限管理中可以添加管理权限。

2.设计模式常⽤的UML图分析（⽤例图、类图与时序图）1-⽤例图概述1. 展现了⼀组⽤例、参与者以及他们之间的关系。

2. ⽤例图从⽤户⾓度描述系统的静态使⽤情况，⽤于建⽴需求模型。

⽤例特征保证⽤例能够正确捕捉功能性需求，判断⽤例是否准确的依据。

1. ⽤例是动宾短语2. ⽤例是相互独⽴的3. ⽤例是由⽤户参与者启动的4. ⽤例要有可观测的执⾏结果5. ⼀个⽤例是⼀个单元参与者 ActorUML中，参与者使⽤⼀个⼩⼈表⽰:1. 参与者为系统外部与系统直接交互的⼈或事务，于系统外部与系统发⽣交互作⽤2. 参与者是⾓⾊⽽不是具体的⼈3. 代表参与者在与系统打交道时所扮演的⾓⾊4. 系统实际运作中，⼀个实际⽤户可能对应系统的多个参与者。

不同⾓⾊也可以只对应⼀个参与者，从⽽代表同⼀参与者的不通实例⽤例 Use Case系统外部可见的⼀个系统功能单元。

系统的功能由系统单元所提供，并通过⼀系列系统单元与⼀个或多个参与者之间交换的消息所表达。

系统单元⽤椭圆表⽰，椭圆中的⽂字简述系统功能:关系 Relationship常见关系类型有关联、泛化、包含和扩展关联 Association表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。

箭头指向：指向消息接收⽅：⼦系统 SubSystem⽤来展⽰系统的⼀部分功能(紧密联系)泛化 Inheritance继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。

⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。

⽗⽤例通常是抽象。

箭头指向：指向⽗⽤例2-类图描述系统中的类，以及各个类之间的关系的静态试图。

表⽰类、接⼝以及它们之间的协作关系，⽤于程序设计阶段。

注意:1. 抽象类或抽象⽅法⽤斜体表⽰2. 如果是接⼝，则在类名上⽅加 <<Interface>>3. 字段和⽅法返回值的数据类型⾮必需4. 静态类或静态⽅法加下划线类图实例:类图中的事务及解释如图，类图从上到下分为三部分,分别为类名、属性和操作1. 属性:如果有属性，则每⼀个属性都必须有⼀个名字，另外还可以有其它的描述信息，如可见性、数据类型、缺省值等2. 操作:如果有操作，则每⼀个操作也都有⼀个名字，其它可选的信息包括可见性、参数的名字、参数类型、参数缺省值和操作的返回值的类型等类图中的六种关系1.实现关系 implements (类实现接⼝)⽤空⼼三⾓虚线表⽰2.泛化关系 extends (表⽰⼀般与特殊的关系) is-a⽤空⼼三⾓实线表⽰3.组合关系 (整体与部分的关系) contains-a实⼼菱形实现表⽰eg.有头类、⾝体类与⼈类类三个类，则⼈类类中应包含头类及⾝体类这两个属性，则⼈类类与头类和⾝体的关系即为组合关系。

UML中的用例图与活动图之间的关联关系UML（统一建模语言）是一种用于软件开发的标准化建模语言，它提供了一套丰富的图形符号和规范，用于描述软件系统的不同方面。

在UML中，用例图和活动图是两个重要的图形模型，它们分别用于描述系统的功能需求和业务流程。

本文将探讨用例图和活动图之间的关联关系，并探讨它们在软件开发过程中的作用。

用例图是用于描述系统功能需求的一种图形模型。

它主要由参与者（Actor）和用例（Use Case）两个主要元素组成。

参与者是与系统进行交互的外部实体，可以是人、其他系统或外部设备。

用例则是对系统功能的描述，它表示系统的一个具体功能或服务。

用例图通过参与者和用例之间的关系，展示了系统的功能和参与者之间的交互。

活动图是用于描述业务流程的一种图形模型。

它主要由活动（Activity）和控制流（Control Flow）两个主要元素组成。

活动表示系统中的一个操作或动作，可以是一个简单的任务或一个复杂的业务流程。

控制流则表示活动之间的顺序关系，它描述了活动之间的流转和依赖关系。

活动图通过活动和控制流之间的关系，展示了系统的业务流程和操作之间的关联。

用例图和活动图之间存在着紧密的关联关系。

用例图描述了系统的功能需求，而活动图则描述了系统的业务流程。

在软件开发过程中，用例图和活动图通常是一起使用的，它们相互补充，帮助开发人员更好地理解和设计系统。

首先，用例图可以作为活动图的输入。

在软件开发的初期阶段，通过分析用户需求和使用场景，可以绘制用例图来描述系统的功能需求。

用例图可以帮助开发人员明确系统的功能范围和参与者之间的交互关系。

这些信息可以为后续的活动图设计提供重要的参考和指导。

其次，活动图可以用于详细描述用例图中的用例。

用例图通常只能提供对系统功能的高层次描述，而活动图可以进一步展开用例中的具体操作和业务流程。

通过活动图，开发人员可以更加详细地描述每个用例的具体执行过程，包括涉及的活动、条件和并发流程等。

UML用例图介绍目录1、UML用例图概述 (1)2、用例图怎么使用？ (1)3、UML用例图的目的 (2)4、如何画用例图？ (3)1、UML用例图概述用例图捕捉了模拟系统中的动态行为，并且描述了用户、需求以及系统功能单元之间的关系。

用例图展示了一个外部用户能够观察到的系统功能模型图。

用例图由主角，用例和它们之间的关系组成。

2、用例图怎么使用？要了解一个系统的动态，我们需要使用不同类型的图表。

用例图就是其中之一，其具体目的是收集系统的的需求和参与者。

用例图指定系统的事件和他们的流向。

但从未用例图描述了他们是如何实现的。

可以被想象成一个黑盒子，只有输入，输出和黑盒子的功能被称为用例图。

在这些图中使用的设计在一个非常高的水平。

那么这种高层次的设计高雅，一遍又一遍完善使系统得到一个完整实用的图片。

一个结构良好的用例，还介绍了前置条件，后置条件和例外。

而这些多余的元素在执行测试时被用来制造测试的情况下。

用例都不是正向和反向工程，但他们仍然使用略有不同的方式。

同样是真实的逆向工程。

仍用例图的使用方式不同，使其逆向工程的一个候选。

在正向工程用例图是用来做测试案例和逆向工程中的使用情况下是用来准备从现有的应用程序的需求细节。

所以下面的地方使用用例图：2.1.需求分析和高水平的设计。

2.2.模拟系统的上下文。

2.3.逆向工程。

2.4.Forward engineering.3、UML用例图的目的用例图的目的是捕捉到一个系统的动态方面。

用例图是用来收集系统的要求，包括内部和外部的影响。

这些要求大多是设计要求。

所以，分析一个系统时要收集其功能用例和确定参与者。

简单来说，用例图的目的如下：3.1.用例图用来收集系统的要求。

3.2.用例图用于获取系统的外观图。

3.3.用例图识别外部和内部因素影响系统。

3.4.用例图显示要求之间的相互作用是参与者。

4、如何画用例图？用例图被认为是高层次的需求分析系统。

因此，当系统的要求，分析被捕获在用例的功能。

UML用例图与活动图的关联关系与适用场景解析UML（Unified Modeling Language）是一种用于软件开发的标准建模语言，它提供了一系列图形化的工具，帮助开发人员更好地理解和设计软件系统。

在UML 中，用例图和活动图是两种常用的图形表示方式，用于描述系统的功能和流程。

本文将分析用例图和活动图之间的关联关系，并探讨它们的适用场景。

一、用例图和活动图的基本概念用例图是一种用于描述系统功能的图形化表示方式。

它主要由参与者（Actor）和用例（Use Case）组成。

参与者是系统的外部角色，可以是人或其他系统，而用例则表示系统的一个功能或行为。

用例图可以帮助开发人员更好地理解系统的需求和功能，并与系统的参与者进行交互。

活动图是一种用于描述系统流程的图形化表示方式。

它主要由活动（Activity）、控制流（Control Flow）和决策（Decision）等元素组成。

活动表示系统中的一个操作或过程，控制流表示活动之间的顺序关系，而决策则表示系统在某个点上的选择。

活动图可以帮助开发人员更好地理解系统的流程和操作。

二、用例图和活动图的关联关系用例图和活动图之间存在着紧密的关联关系。

用例图描述了系统的功能和参与者之间的交互，而活动图则描述了系统中具体的操作和流程。

用例图可以作为活动图的上下文，帮助开发人员更好地理解活动图中的操作和流程。

在用例图中，每个用例可以对应一个或多个活动图。

用例图中的用例可以作为活动图的起点或终点，描述了系统中的一个具体功能或操作。

而活动图中的活动和控制流则可以帮助开发人员更好地理解用例图中的功能和参与者之间的交互。

举个例子来说，假设我们正在开发一个在线购物系统。

在用例图中，我们可以有一个用例叫做“用户登录”，表示用户登录系统的功能。

而在活动图中，我们可以详细描述用户登录的具体流程，包括输入用户名和密码、验证用户信息、登录成功或失败等操作。

用例图和活动图之间的关联关系可以帮助开发人员更好地理解用户登录这个功能的具体实现。

UML⽤例图中泛化、扩展、包括在画⽤例图的时候，理清⽤例之间的关系是重点。

⽤例的关系有泛化(generalization)、扩展(extend)和包含(include)。

其中include和extend 最易混淆。

下⾯我们结合实例彻底理清三者的关系。

基本概念⽤例图（Use Case Diagram）:⽤例图显⽰谁是相关的⽤户，⽤户希望系统提供什么服务（⽤例），以及⽤例之间的关系图。

⽤例图主要的作⽤是获取需求、指导测试。

⽤例图的4个基本组件：参与者(Actor)、⽤例(Use Case)、关系(Relationship)和系统。

泛化(generalization)：泛化关系是⼀种继承关系，⼦⽤例将继承基⽤例的所有⾏为，关系和通信关系，也就是说在任何使⽤基⽤例的地⽅都可以⽤⼦⽤例来代替。

泛化关系在⽤例图中使⽤空⼼的箭头表⽰，箭头⽅向从⼦⽤例指向基⽤例。

扩展(extend)： extend关系是对基⽤例的扩展，基⽤例是⼀个完整的⽤例，即使没有⼦⽤例的参与，也可以完成⼀个完整的功能。

extend的基⽤例中将存在⼀个扩展点，只有当扩展点被激活时，⼦⽤例才会被执⾏。

extend关系在⽤例图中使⽤带箭头的虚线表⽰(在线上标注<<extend>>)，箭头从⼦⽤例指向基⽤例。

包含(include)： include为包含关系，当两个或多个⽤例中共⽤⼀组相同的动作，这时可以将这组相同的动作抽出来作为⼀个独⽴的⼦⽤例，供多个基⽤例所共享。

因为⼦⽤例被抽出，基⽤例并⾮⼀个完整的⽤例，所以include关系中的基⽤例必须和⼦⽤例⼀起使⽤才够完整，⼦⽤例也必然被执⾏。

include关系在⽤例图中使⽤带箭头的虚线表⽰(在线上标注<<include>>)，箭头从基⽤例指向⼦⽤例。

实例需求场景联通客户响应OSS。

系统有故障单、业务开通、资源核查、割接、业务重保、⽹络品质性能等功能模块。

UML⽤例图总结⽤例图主要⽤来描述“⽤户、需求、系统功能单元”之间的关系。

它展⽰了⼀个外部⽤户能够观察到的系统功能模型图。

【⽤途】：帮助开发团队以⼀种可视化的⽅式理解系统的功能需求。

⽤例图所包含的元素如下： 1. 参与者(Actor) 表⽰与您的应⽤程序或系统进⾏交互的⽤户、组织或外部系统。

⽤⼀个⼩⼈表⽰。

2. ⽤例(Use Case) ⽤例就是外部可见的系统功能，对系统提供的服务进⾏描述。

⽤椭圆表⽰。

3. ⼦系统(Subsystem) ⽤来展⽰系统的⼀部分功能，这部分功能联系紧密。

4. 关系 ⽤例图中涉及的关系有：关联、泛化、包含、扩展。

如下表所⽰： a. 关联(Association) 表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。

【箭头指向】：指向消息接收⽅ b. 泛化(Inheritance) 就是通常理解的继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。

⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。

⽗⽤例通常是抽象的。

【箭头指向】：指向⽗⽤例 c. 包含(Include) 包含关系⽤来把⼀个较复杂⽤例所表⽰的功能分解成较⼩的步骤。

【箭头指向】：指向分解出来的功能⽤例 d. 扩展(Extend) 扩展关系是指⽤例功能的延伸，相当于为基础⽤例提供⼀个附加功能。

【箭头指向】：指向基础⽤例 e. 依赖(Dependency) 以上4种关系，是UML定义的标准关系。

但VS2010的⽤例模型图中，添加了依赖关系，⽤带箭头的虚线表⽰，表⽰源⽤例依赖于⽬标⽤例。

【箭头指向】：指向被依赖项 5. 项⽬(Artifact) ⽤例图虽然是⽤来帮助⼈们形象地理解功能需求，但却没多少⼈能够通看懂它。

很多时候跟⽤户交流甚⾄⽤Excel都⽐⽤例图强，VS2010中引⼊了“项⽬”这样⼀个元素，以便让开发⼈员能够在⽤例图中链接⼀个普通⽂档。

⽤依赖关系把某个⽤例依赖到项⽬上： 然后把项⽬-》属性的Hyperlink设置到你的⽂档上； 这样当你在⽤例图上双击项⽬时，就会打开相关联的⽂档。

UML建模——⽤例图（UseCaseDiagram）⽤例图主要⽤来描述⾓⾊以及⾓⾊与⽤例之间的连接关系。

说明的是谁要使⽤系统，以及他们使⽤该系统可以做些什么。

⼀个⽤例图包含了多个模型元素，如系统、参与者和⽤例，并且显⽰这些元素之间的各种关系，如泛化、关联和依赖。

它展⽰了⼀个外部⽤户能够观察到的系统功能模型图。

【⽤途】：帮助开发团队以⼀种可视化的⽅式理解系统的功能需求。

⼀、⽤例图所包含的的元素1. 参与者(Actor)——与应⽤程序或系统进⾏交互的⽤户、组织或外部系统。

⽤⼀个⼩⼈表⽰。

2. ⽤例(Use Case)——⽤例就是外部可见的系统功能，对系统提供的服务进⾏描述。

⽤椭圆表⽰。

3. ⼦系统(Subsystem)——⽤来展⽰系统的⼀部分功能，这部分功能联系紧密。

⼆、⽤例图所包含的的关系 ⽤例图中涉及的关系有：关联、泛化、包含、扩展。

如下表所⽰： a. 关联(Association) 表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。

【箭头指向】：⽆箭头，将参与者与⽤例相连接，指向消息接收⽅ b. 泛化(Inheritance) 就是通常理解的继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。

⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。

⽗⽤例通常是抽象的。

在实际应⽤中很少使⽤泛化关系，⼦⽤例中的特殊⾏为都可以作为⽗⽤例中的备选流存在。

【箭头指向】：指向⽗⽤例 c. 包含(Include) 包含关系⽤来把⼀个较复杂⽤例所表⽰的功能分解成较⼩的步骤。

包含关系对典型的应⽤就是复⽤，也就是定义中说的情景。

但是有时当某⽤例的事件流过于复杂时，为了简化⽤例的描述，我们也可以把某⼀段事件流抽象成为⼀个被包含的⽤例；相反，⽤例划分太细时，也可以抽象出⼀个基⽤例，来包含这些细颗粒的⽤例。

这种情况类似于在过程设计语⾔中，将程序的某⼀段算法封装成⼀个⼦过程，然后再从主程序中调⽤这⼀⼦过程。

二．用例建模简介用例建模是UML建模的一部分，它也是UML里最基础的部分。

用例建模的最主要功能就是用来表达系统的功能性需求或行为。

依我的理解用例建模可分为用例图和用例描述。

用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。

用例描述用来详细描述用例图中每个用例，用文本文档来完成。

1．用例图参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。

因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。

还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。

比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。

参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。

用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。

这是 UML对用例的正式定义，对我们初学者可能有点难懂。

我们可以这样去理解，用例是参与者想要系统做的事情。

对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。

用例在画图中用椭圆来表示，椭圆下面附上用例的名称。

系统边界是用来表示正在建模系统的边界。

边界内表示系统的组成部分，边界外表示系统外部。

系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。

因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。

箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。

箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。

2．用例描述用例图只是简单地用图描述了一下系统，但对于每个用例，我们还需要有详细的说明，这样就可以让别人对这个系统有一个更加详细的了解，这时我们就需要写用例描述。

图书管理系统UML图案例：图书管理系统⼀、图书管理系统功能描述图书管理系统能够对图书进⾏注册登记，也就是将图书的基本信息（如编号、书名、价格、作者等）预先存⼊数据库中，供以后检索，并且能够对借阅⼈进⾏注册登记，包括记录借阅⼈的姓名、编号、班级、年龄、性别、地址、电话等信息。

同时，图书管理系统提⾼⽅便的查询⽅法。

如以书名、作者、出版社、出版时间等信息进⾏图书检索，并能反映出图书的借阅情况；以借阅⼈编号对借阅⼈信息进⾏检索；以出版社名称查询出版社联系⽅式等信息。

图书管理系统提供对书籍进⾏预订的功能，也提供旧书销毁功能，对于淘汰、损坏、丢失的书名可及时对数据库进⾏修改。

图书管理系统能够对使⽤该管理系统的⽤户进⾏管理，按照不同的⼯作职能提供不同的功能授权。

总的来说，图书管理系统主要包含下列功能。

1）读者管理：读者信息的制定、输⼊、修改、查询，包括种类、性别、借书数量、借书期限、备注等。

2）书籍管理：书籍基本信息制定、输⼊、修改、查询，包括书籍编号、类别、关键词、备注。

3）借阅管理：包括借书、还书、预订书籍、续借、查询书籍、过期处理和书籍丢失后的处理。

4）系统管理：包括⽤户权限管理、数据管理和⾃动借还机的管理。

⼆、图书管理系统⽤例图1.确定参与者本系统的参与者包括两个：读者、管理员。

2.确定⽤例管理员包括的⽤例：1）登录系统：管理员可以通过登录该系统进⾏各项功能的操作。

2）书籍管理：包括对书籍的增删改查操作。

3）书籍借阅管理：包括借书、还书、预订、书籍逾期处理和书籍丢失处理4）读者管理：包括对读者的增删改查操作。

读者包括的⽤例：1）登录系统。

2）借书。

3）还书。

4）查询：包括对个⼈信息和书籍信息的查询业务。

5）预订：读者对书籍的预订业务。

6）逾期处理：书籍过期缴纳罚⾦等。

7）书籍丢失处理：对书籍丢失后的不同措施进⾏处理。

8）⾃动借书机的使⽤。

3.⽤例图管理借书机还书缴纳罚⾦<>三、图书管理系统⽤例规约1. 借书⽤例规约四、图书管理系统类图1. ⽅法：名词分析法2. 操作步骤：1)找到功能描述或事件流描述中的名词，经过筛选，形成后续类2)确定类和类之间的关系3)给出类的结构，即属性和⽅法3. 系统总的类图五、图书管理系统顺序图1. 借书顺序图参照借书⽤例规约主事件流，画出顺序图2.还书顺序图六、协作图按F5可以将顺序图转换为协作图七、活动图1.借书活动图N2.还书活动图3.预定图书活动图⼋、状态图图书状态还书九、项⽬部署图客户端 {IE,FireFox,⾕歌浏览器等}Web 服务器{Tomcat, JDK,Eclipse}数据库服务器{MySQL}视图层控制层DAOVO。