图方案管理系统uml用例图
UML之用例图
UML之⽤例图⽤例图⽤例图是⽤来描述系统功能的技术，表⽰⼀个系统中⽤例与参与者及其关系的图，主要⽤于需求分析阶段。
⽤例图的基本组成元素：参与者、⽤例、元素之间的关系。
⽤例图使⽤范围：需求分析1.捕获需求。
描述功能需求、⾏为需求（系统要完成什么任务）2.分析需求。
明确类和对象，建⽴之间的关系⽤例图的基本概念1、⽤例图是表⽰⼀个系统中⽤例与参与者关系之间的图。
它描述了系统中相关的⽤户和系统对不同⽤户提供的功能和服务。
2、⽤例图相当于从⽤户的视⾓来描述和建模整个系统，分析系统的功能与⾏为。
3、⽤例图中的主要元素包括参与者、⽤例以及元素之间的关系。
此外，⽤例图还可以包括注解和约束，也可以使⽤包将图中的元素组合成模块。
如：参与者的概念1、参与者是与系统主体交互的外部实体的类元，描述了⼀个或⼀组与系统产⽣交互的外部⽤户或外部事物。
2、参与者位于系统边界之外，⽽不是系统的⼀部分。
3、参与者是从现实世界中抽象出来的⼀种形式，却不⼀定确切对应的现实中的某个特定对象。
符号：如何确定参与者？通过对参与者进⾏关注和分析，我们可以把重点放在如何与系统交互这⼀问题上，便于进⼀步确定系统的边界。
另外，参与者也决定了系统需求的完整性。
确定参与者可以从以下⼏个⾓度来考虑：1）为系统提供输⼊的⼈或事物2）接收系统输出的⼈或事物3）需要接⼊的第三⽅系统或设备4）时间是否会触发某些事件5）负责⽀持或维护系统中信息的⼈系统中的参与者⼀般可以分为四类：主要业务参与者：主要从⽤例的执⾏中获得好处的关联⼈员。
主要系统参与者：直接同系统交互以发起或触发业务或系统事件的关联⼈员。
外部服务参与者：响应来⾃⽤例的请求的关联⼈员。
外部接收参与者：从⽤例中接收某些价值或输出的⾮主要的关联⼈员。
参与者的泛化关系当系统中的⼏个参与者既扮演⾃⾝的⾓⾊，同时也有更⼀般化的⾓⾊时，可以通过建⽴泛化关系来进⾏描述。
与类相似，⽗参与者可以是抽象的，即不能创建⼀个⽗参与者的直接实例，这就要求属于抽象⽗参与者的外部对象⼀定能够属于其⼦参与者之⼀。
如何利用UML用例图描述软件系统的需求
因明
（4）参与者之间的主要关系---泛化（继承）关系
泛化或者继 承
（5）所要注意的问题
（6）如何获 得系统中的 参与者
5、用例模型中的用例（UseCase） （1）用例及其定义—某种特定的功能
（2）用例的分类——业务用例 描述一个业务的流程以及它们与外部各方(如客户和合 作伙伴)之间的交互 代表系统中需要提供的核心功能：如报表数据汇总计算 （3）用例的分类——系统用例 系统既定功能及系统环境的模型，描述且仅仅描述系 统的功能 系统提供的附加其它功能或者服务：如报表打印
Abstract use case – use case that reduces redundancy in two or more other use cases by combining common steps found in both.
（3）用例的横向方面的联系---扩展关联（Extension use case）
2、可以采用UML中的用例模型（用例图）方法 利用用例（Use Case）和用例图、需求文档来确定系 统的高层逻辑视图。
3、用例模型中的基本组成部件
用例最初由Ivar Jackboson博士提出，后被综合 到UML规范之中，成为需求表述的标准化体系。 Ivar Jacobson博士与Grady Booch和James Rumbaugh一道共同创建了UML建模语言，被业界誉 为UML之父。
（2）主要的特性
UML 由图和元模型组成，图是语法，而元模型则给出图的 意思，是UML的语义 它提供了描述软件系统模型的概念，同时由于它采用面向 对象的技术、方法，它的作用域不限于支持面向对象的分 析与设计,还支持从需求分析开始的软件开发的全过程。
（ 3 ）它是编制软件蓝图的标准化语言 ---- 是标准的建模 语言
UML之用例图详解
UML之⽤例图详解原⽂链接:https:///mj_ww/article/details/53020080 UML,即Unified Model Language,统⼀建模语⾔。
百度百科对他的定义是：它是⼀个⽀持模型化和软件系统开发的图形化语⾔，为软件开发的所有阶段提供模型化和可视化⽀持，包括由到规格，到构造和配置。
作为⼀个软件⼯程师，很多技能并不⼀定说⾮得具备，但是，⼀旦我们具备了，很多时候机会总是会多那么⼀点点。
对于⽤例图来说我们需要了解的是什么叫⽤例图，构成⽤例图的要素，⽤例图有哪些重要的元素，各个⽤例之间的关系。
当然最重要的是如何根据需求创建⽤例图。
具体的创建通过⼀个简单的学⽣管理的例⼦说明创建的过程和例⼦。
我的所有例⼦都是是使⽤Rose这个软件来画的，现在虽然有新的UML模型画图软件，但是我⽐较喜欢⽤这个Rose，如果你还没有装这个软件需要先装⼀个，或者使⽤你⽐较喜欢的UML画图软件。
下⾯我们直接进⼊正题吧，学习⼀下⽤例图的相关概念和具体的创建过程。
什么叫⽤例图1. ⽤例图的含义 由参与者（Actor）、⽤例（Use Case）以及它们之间的关系构成的⽤于描述系统功能的动态视图称为⽤例图。
要在⽤例图上显⽰某个⽤例，可绘制⼀个椭圆，然后将⽤例的名称放在椭圆的中⼼或椭圆下⾯的中间位置。
要在⽤例图上绘制⼀个参与者（表⽰⼀个系统⽤户），可绘制⼀个⼈形符号。
参与者和⽤例之间的关系使⽤带箭头或者不带箭头的线段来描述，箭头表⽰在这⼀关系中哪⼀⽅是对话的主动发起者，箭头所指⽅是对话的被动接受者。
在⽤例建模中，为了更加清楚的描述⽤例或者参与者，会使⽤到注释。
2. ⽤例图的作⽤ ⽤例图是需求分析中的产物，主要作⽤是描述参与者和⽤例之间的关系，帮助开发⼈员可视化的了解系统的功能。
借助于⽤例图，系统⽤户、系统分析⼈员、系统设计⼈员、领域专家能够以可视化的⽅式对问题进⾏探讨，减少了⼤量交流上的障碍，便于对问题达成共识。
UML 用例图、关系图、活动图
例如，一个银行系统中，有
一个“验证用户”用例，用 身份认证
于验证用户的合法性，它有
两 个 特 殊 的 子 用 例 ， 一 个 是 密码认证
指纹认证
“检查密码”，另一个是
“检查指纹”，它们都有父
用例“验证用户”的行为，
并且可以出现在父用例出现
的任何地方，还可以添加自
己的行为。
用例图实例
• 以前面图书信息管理系统为例，画出用例 图。先找出参与系统地的角色：
• 扩展关系——允许一个用例扩展另一个用
例的功能。例如，在图书信息管理系统中，
读者还书时，系统检查所还图书是否有预
订记录，如果有则执行“通知”用例。在
UML中扩展关系表示为箭头和《extend》形
式。
《extend》
还书
通知
管理员
读者
注意
• 使用关系和扩展关系之间的区别，A使用B 本质上是A一定使用B，同时增加自己的专 属行为；而A被用例B扩展是说明A是一个一 般用例，B是一个特殊用例，A在某些条件 下可能使用B。
（2）取消预订——本用例提供取消预订图书的功能。
（3）还书——完成还书任务，在还书是要检查所还的书是否超 期、是否有其他读者预订，有的话要通知预订者。
（4）借书——提供借阅书功能 。
• 分析这个用例图，发现“还书”用例应该 被扩展，因为在还书时检查所还图书是否 有预订记录，若有，则应该通知预订者前 来借书。
• 一个用例内部的具体处理细节是由其他图形工具描述 的，用例图只是反映系统的总体功能，以及与这些功 能的相关的角色。有些人可能在画“借书”用例时， 情不自禁地就考虑了“输入读者号和书号”，“检查 图书是否在库？”，“图书数量减1”，“添加读者借 书记录”等等，一旦考虑了这些细节，就会发现用例 图画不下去了。因此，读者注意用例图中不要考虑处 理细节。
UML用例图
用例图初感UML是一组图示符号的标准。
所谓图示符号，就是一组定义好的图示，它们可以表达定义好的各种意思。
用UML进行软件建模，就是用规定好的符号画图，这些图表达了开发人员脑中的软件系统。
用UML进行软件建模，其难度并不比我们小时候上的美术课更难。
在美术课上，一个圆形加上四根线条表示太阳，一个三角形加上一个矩形表示房子；同理，在UML的用例图中，一个椭圆表示用例，一个小人表示参与者。
我并不认为它们之间有质的区别，想到我对这种小学生画图课恐惧了几年，不由得感到羞愧。
用例图是UML的九个图中较为重要和常用的一种图。
常常用于软件开发的需求分析阶段，也能用于软件的系统测试阶段。
简单的来说，用例图是描述系统的外部视图。
在开始设计一个软件系统时（更广义的情况下，可以用来设计任何系统），需要一种手段来发现系统的功能，用例图虽然是图示，但是这些图示隐含了一种启发系统功能的手段。
其实所有的UML图都只包含图示和标准，并不包含方法，但是它们往往隐含了某种方法。
UML和软件开发方法的关系，很类似于汉字和语文的关系。
用例图包含了三种基本的概念：用例、角色和系统。
它们可以组合起来表达系统的外部视图。
而且这种表达方式是如此直观和简单。
第一张用例图画用例图是一件很简单的事情，而且感觉还很舒适，因为用例图简洁、直观。
虽然用例图不能像HelloWorld一样运行，也不能生成代码，不过画一张清晰的用例图还是很有成就感的。
我使用的工具是Eclipse+EclipseUML插件，功能不如Rose，但是是开源而且免费的（EclipseUML有free版也有企业版），而且效果也不错。
第一张用例图如下：可以看出图中有一个系统（保险商务系统），两个角色（客户和保险销售员）以及三个用例（签订保险单、销售统计资料、客户数据资料），另外还有四个连接线以及一个注释。
如果在纸上或者合适的工具中，画这样一张用例大概只需要五分钟吧。
不过仅仅画出来是没有意义的，需要弄清楚其背后真正的含义才行。
软件工程9种图
3.关联关系（Association）
【概念】表示一个事物的对象与另一个事物的对象之间的语义上连接， 简单的理解为两个类或类与接口之间的强依赖关系
【绘图方式】实线箭头，双向箭头或无箭头 【包括】 1 聚集 【概念】描述的是部分与整体关系，描述了“has a”的关系，部分离 开整体可以单独存在 【绘图方式】空菱形的实线，头部指向整体
【实现关系图】
泛化和实现关系的区别： 泛化关系是指同一语义层的元素连接起来， 通常在同一模型内； 实现关系将不同语义层内的元素连接起来，通常在不同模型内。
UML 的视图
相信大家都知道 UML 的全称，统一建模语言（UML 是 Unified Modeling Language 的缩写） 是用来对软件系统进行可视化建模的一种 语言。UML 为面向对象开发系统的产品进行说明、可视化、和编制文 档的一种标准语言。 我想问大家两个问题: 一、什么是模型？模型是对现实世界的形状或状态的抽象模拟和简 化。 二、为什么要建模？最简单的理由：为了能够更好地理解正在开发
UML 的9种图
上文我们介绍了， UML 的视图， 在每一种视图中都包含一个或多种图。 本文我们重点讲解 UML 每种图的细节问题：
1、用例图（use case diagrams）
【概念】描述用户需求，从用户的角度描述系统的功能 【描述方式】椭圆表示某个用例；人形符号表示角色 【目的】帮组开发团队以一种可视化的方式理解系统的功能需求 【用例图】
【依赖图】
2,泛化关系（继承） （Generalization）
【概念】描述类的一般和具体之间的关系，描述的“is a kind of ”的关 系 【绘图方式】实线空心三角箭头，箭头指向父类 【继承方式】
图书馆管理系统uml建模
基于UML的图书馆管理系统建模设计一、摘要面向对象的软件工程，同传统的面向过程的软件工程相比,在需求的获取、系统分析、设计和实现方面都有着很大的区别.ＵＭL是OＯA和OOD的常用工具。
使用UML来构建软件的面向对象的软件工程的过程,就是一个对系统进行不断精化的建模的过程。
这些模型包括用例模型、分析模型、设计模型,然后，我们需要使用具体的计算机语言来建立系统的实现模型。
当然,在整个软件工程中，我们还需要建立系统的测试模型,以保证软件产品的质量．使用面向对象的工具来构建系统，就应该使用面向对象的软件工程方法。
然而,我们经常会发现,在实际的开发过程中,很多开发人员虽然能够理解UＭL的所有图形,却仍然不能得心应手的使用UMＬ来构建整个项目,其很大的原因,是仍然在使用原有的软件工程方法，而不清楚如何使用UMＬ来建立系统的这些模型，不清楚分析和设计的区别，以及他们之间的转化.应用软件系统，就其本质来说，是使用计算机对现实世界进行的数字化模拟。
应用软件的制造过程,按照ＵML的方法，就是建立这一系列模型的过程。
关于这个图书馆系统，基本的需求比较简单,就是允许学生可以在图书馆借阅和归还图书，另外，也可以通过网络或者图书馆的终端来查阅和预订书。
当然,图书馆管理员也可以对图书进行管理.为了简化系统，我们没有把图书馆中的人员作细分。
本文只是对使用UＭL的过程做一个探讨，着眼于使用UMＬ进行建模的过程，说明各个层次的模型之间的区别和联系,展示系统演进的过程,而不会深入UML的细节方面.对于更加复杂的系统，其分析和设计的方法是相通的，可以举一反三。
二、图书馆管理系统可行性分析随着政府机关与广大企事业单位内部网络的广泛建立,在通用信息平台上构筑高效实用的协同工作和自动化办公应用系统,满足信息高度共享和即时发布的需求，有效实现内部知识管理,已成为众多用户的共同需求.图书管理系统，为政府机关与广大企事业单位自动化办公提供了一个较好的解决方案.在开发过程中,按照软件工程的步骤，从设计到开发采用了面向对象的思想和技术,采用了SQL SERＶER 200０数据库，使得本系统可以方便的和其他子系统进行数据交换。
UML功能模型（用例图）
UML功能模型（⽤例图）在UML系统开发中有三个主要的模型：功能模型（从⽤户⾓度展⽰系统的功能，包括⽤例图）、对象模型（采⽤对象，属性，操作关联等概念展⽰系统的结构和基础，包括类图、对象图、包图）、动态模型（展⽰系统的内部⾏为，包括序列图，活动图，状态图）。
下⾯就说⼀说功能模型——⽤例图。
⽤例图是UML建模的⼀部分，也是UML⾥⾯最基础的部分，最主要的功能就是⽤来表达系统的功能性需求或⾏为。
⽤例图是由软件需求分析到最终实现的第⼀步，它描述⼈们如何使⽤⼀个系统，是尾部参与者所能观察到的系统功能模型图，该图呈现了⼀些参与者和⼀些⽤例，以及它们之间的关系，主要⽤于对系统、⼦系统或类的功能⾏为进⾏建模，⽤画图的⽅法来完成。
⽤例图展⽰了⽤例之间以及⽤例与参与者之间是怎样相互联系的。
⽤例图包含留个元素：参与者、⽤例、关联关系、包含关系、扩展关系、泛化关系。
参与者（Actor）：系统外部的⼀个实体，参与⽤例执⾏过程，通过向系统输⼊或请求系统输⼊某些事件来触发系统的执⾏。
参与者的种类概括为三种：系统⽤户、与所建造的系统交互的其他系统以及⼀些可以运⾏的进程。
注意：参与者表⽰⼈和事物与系统发⽣交互时所扮演的⾓⾊，⽽不是特定的⼈或特定的事物；每个参与者需要⼀个具有业务⼀样的名字；⼀个⼈或事物在与系统交互时，可以同时或不同时扮演多个⾓⾊。
⽤例（Use Case）：⽤例是对⼀个活动者使⽤系统的⼀项功能是所进⾏的交互过程的⼀个⽂字描述序列，是系统、⼦系统或类和尾部参与者交互动作序列的说明，包括可选的动作徐磊嗯哼会出现异常的动作序列。
⽤例是岱庙系统各种各个项⽬相关⼈员之间就系统的⾏为所达成的契约，软件开发过程是⽤例驱动的。
⽤例粒度（规模⼤⼩）。
关联关系（Association）：表⽰参与者⽤例之间进⾏通信包含关系（Include）：客户⽤例可以简单地包含提供者⽤例具有的⾏为，并把他所包含的⽤例⾏为作为⾃⾝⾏为的⼀部分。
调⽤⽤例执⾏到包含点，然后执⾏传递给被调⽤⽤例，当被调⽤⽤例完成时，控制在次返回调⽤⽤例。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
精心整理Use Case图即用例图，是从外部用户的角度来描述系统功能的一种需求表达方式。
一个系统常常包含了众多的用例，每个用例表达了用户对系统的一项需求或描述了人们使用系统某项功能的途径。
使用系统的不同功能，其操作的场景不同。
而使用相同的功能，其场景则相似。
将同一用例的场景用文字描述出来就得到了系统用例描述。
完整的描述用例，通常包括用例名称、参与执行者、前置条件、事件流、后
图书管理系统简示：
图书管理系统
a.系统管理员用例图
系统管理员能通过该系统进行如下活动内容和要求：
添加借阅者：系统管理员可以在添加符合身份的新读者信息
删除借阅者：系统管理员可以在删除页面添加已不符合身份的借阅者信息
修改借阅者信息：系统管理员可以在修改信息页面修改借阅者信息
添加图书信息：系统管理员可以在添加图书信息页面添加图书馆新增图书
删除图书信息：系统管理员可以删除不能在借阅图书的信息
系统维护：系统管理员维护该系统的日常工作
b
分类处理：图书管理员能通过分类图书页面将新增图书和已还图书进行分类回放，以便下一位借阅者阅读查看
用例说明：
Librarian login：图书管理员登录
Book management：图书管理
Get book：还书
Get with fine：违规罚款
Lend book：借书
Check user account：身份验证
Book category：图书分类
c
出
Return book：返还图书
d．整体用例图
参与者：borrower：借阅者；administrator：系统管理员；librarian：图书管理员用例说明：
Login system：系统登录
Account management：账户管理（其中包括图书管理、借阅者管理、系统管理）Add book：添加图书
Remove book：删除图书
Add borrower：添加借阅者
Remove borrower：删除借阅者
Borrowe book：借阅图书
Return book：返还图书。