用例视图
【软件架构】运用RUP4+1视图软件架构设计（逻辑视图、实现视图、进程视图、物理视图和用例视图）
【软件架构】运⽤RUP4+1视图软件架构设计（逻辑视图、实现视图、进程视图、物理视图和⽤例视图）RUP概述RUP（Rational Unified Process），统⼀软件开发过程，统⼀软件过程是⼀个⾯向对象且基于⽹络的程序开发⽅法论。
在RUP中采⽤“4+1”视图模型来描述软件系统的体系结构。
“4+1”视图包括逻辑视图、实现视图、进程视图、部署视图和⽤例视图。
最终⽤户关⼼的是系统的功能，因此会侧重于逻辑视图；程序员关⼼的是系统的配置、装配等问题，因此会侧重于实现(开发)视图；系统集成⼈员关⼼的是系统的性能、可伸缩性、吞吐率等问题，因此会侧重于进程(处理)视图；系统⼯程师关⼼的是系统的发布、安装、拓扑结构等问题，因此会侧重于部署(物理)视图。
分析⼈员和测试⼈员关⼼的是系统的⾏为，因此会侧重于⽤例(场景)视图；原⽂链接：https:///turbock/article/details/102930810（2）4+1视图介绍：（3）UML 4+1视图：（）运⽤RUP 4+1视图⽅法进⾏软件架构设计下⽂摘⾃：⽐如设计⼀座跨江⼤桥：我们会考虑"连接南北的公路交通"这个"功能需求"，从⽽初步设计出理想化的桥墩⽀撑的公路桥⽅案；然后还要考虑造桥要⾯临的"约束条件"，这个约束条件可能是"不能影响万吨轮从桥下通过"，于是细化设计⽅案，规定桥墩的⾼度和桥墩之间的间距；另外还要顾及"⼤桥的使⽤期质量属性"，⽐如为了"能在湍急的江流中保持稳固"，可以把⼤桥桥墩深深地建在岩⽯层之上，和⼤地浑然⼀体；其实，"建造期间的质量属性"也很值得考虑，⽐如在⼤桥的设计过程中考虑"施⼯⽅便性"的⼀些措施。
和⼯程领域的功能需求、约束条件、使⽤期质量属性、建造期间的质量属性等类似，软件系统的需求种类也相当复杂，具体分类如图1所⽰。
第6章 用例图
3、构建用例模型
采 购 员 用 例 图
采购员能够通过该系统进行订货管理活动。采购员首先根据经营情 况统计所缺的生产资料，根据需要制定出订单。
UML统一建模语言
五、使用Rose创建用例图的步骤说明
3、构建用例模型
会 计 用 例 图
会计负责产品的统计分析 管理，它能够通过该系统 进行如下活动： （1）查询基本信息。会计 能够查询产品的基本信息， 根据产品的基本信息，制 定出相应的方案。 （2）查询销售信息。会计 根据销售情况汇总后交销 售部制定合理的销售方案。 （3）查询供应商信息。会 计能够查询供应商信息。 （4）查询缺货信息。会计 能够查询缺货信息。 （5）查询报损信息。会计 能够查询报损信息。
1、需求分析
“企业进、存、销管理系统” 功能性需求包括以下内容： （1）采购员根据生产原料的使用情况判断采购用品，对需要订购产品信息 统计订货的，并制作产品订单。最后根据订单进行采购活动。 （2）仓库管理员负责产品的库存管理。包括产品入库管理、处理盘点信息、 处理报损产品信息和一些信息的设置。这些设置信息，包括：供应商信息、产 品信息。仓库管理员每天对产品进行一次盘点，当发现库存产品有损坏时，及 时处理报损信息。当产品生产后，将产品进行入库。当产品销售后时，产品进 行出库处理。 （3）统计人员负责统计分析管理，包括：查询产品信息、查询销售信息、 查询供应商信息、查询缺货信息、查询报表信息，并制作报表。统计分析员使 用系统的统计分析功能，了解产品信息、销售信息、供应商信息、库存信息。 （4）在销售员为客户提供售货服务时，接受客户购买产品，根据系统的定 价计算出产品的总价，客户付款，系统自动保存客户购买记录。 （5）系统管理员负责本系统的系统维护。系统管理员负责员工信息管理、 供货商信息管理以及系统维护等。每种管理者都通过自己的用户名称和密码登 录到各自的管理系统中。
用例图的简单描述
Use Case View Summary这段文字是翻译自Mark Priestley《Practical Object-Oriented Design with UML》的，算是对用例图作个总结，增加我自己的理解和记忆，也希望对大家有所帮助。
●用例视图（use case view）包括actors 和用例(use cases)。
Actors描述了用户在和系统交互的过程中可以扮演的角色。
用例描述了系统提供给actors的功能。
●用例定义了用户和系统之间的某种特定类型事务。
某个特定类型的交互，或者说用例的实例可以在场景(scenarios)中描述。
UML并没有给出用例和场景的正式定义。
●场景可以被定义为陈述了用例所描述的基本的事件发生过程，并且陈述了可能发生的异常情况。
●用例图（use case diagram）画出了参与在系统中的actors和用况。
一个actor和一个用况之间存在关联说明这个actor参与这个用况其中。
●用例和用例之间， actor和actor之间可以存在一般化关系（类似于类class之间的超类、继承），就是说某个用例或actor是另外一个的特殊情况。
●用例之间还存在这“包含（include）”关系，就是说一个用例可以包含另外一个。
类似于函数调用，这为用例的重用提供了一种机制。
●用例之间的另外一种关系“扩展(extend)”运行一个用例提供可选的功能。
通过定义扩展点和何时执行何种功能来定义这种关系。
这些信息在用例图中是可选的。
●一个用例或者场景的实现描述了足够实现这个用例（或场景）功能的，可交互对象的结构。
●序列图（sequence diagram）和协作图（collaboration diagram）画出参与在一个交互中的对象和他们之间互相发送的消息，可以描述一个用例的实现。
译文就到此为止了，我想大概的就我的理解说明一下，以防止大家看的摸不着北。
Use case view是由需求到最终实现的第一步，目标系统需要有那些潜在或者明显的功能，有那些目标用户，这些东西画出来后use case这一步还远没有完成，接下来应该对要实现的功能进一步分析，那些用例其实是一种，用例之间有那些关系，如上面列出的一般化关系，扩展关系等等。
软件工程 第5章--UML
UML的定义
UML定义有两个主要组成部分：语义和表示法。 语义用自然语言描述，表示法定义了UML的可 视化标准表示符号，这决定了UML是一种可视 化的建模语言。 在语义上，模型是元模型的实例。UML定义给 出了语法结构的精确定义。 使用UML时，要从不同的角度观察系统，为此 定义了概念“视图(View)‖。视图是对系统的模 型在某方面的投影，注重于系统的某个方面。
独立于过程
系统建模语言，独立于开发过程。
9
容易掌握使用 概念明确，建模表示法简洁明了，图形结 构清晰，容易掌握使用。 着重学习三个方面的主要内容： (1) UML的基本模型元素 (2) 组织模型元素的规则 (3) UML语言的公共机制 与程序设计语言的关系 用Java，C++ 等编程语言可实现一个系统。 一些CASE工具可以根据 UML所建立的系 统模型来产生Java、C++ 等代码框架。
31
UML事物 — 注释事物
11) Note（注释）
依附于一个元素或一组元素之上，对其进
行约束或解释的简单符号。没有语义影响。
See policy8-5-96.doc for details about these algorithms.
CashAccount presentValue()
32
15
UML定义 9 种图，表达UML中的 5 种视图，各 视图在静态和动态方面表示系统模型。
结构 视图 静态 方面
动态 方面
行为 视图 同左
实现 视图 构件图
环境 视图 部署图
同左
用例 视图 用例图
同左
类图 对象图
顺序图 同左 顺序图 合作图 (注重 合作图 状态图 进程、 状态图 活动图 线程) 活动图
UML（UnifiedModelingLanguage统一建模语言）
UML（UnifiedModelingLanguage统⼀建模语⾔）UML（Unified Modeling Language 统⼀建模语⾔），⼜称标准建模语⾔。
是⽤来对软件密集系统进⾏可视化建模的⼀种语⾔。
UML是⼀种⾯向对象的建模语⾔，它可以实现⼤型复杂系统各种成分描述的可视化、说明并构造系统模型，以及建⽴各种所需的⽂档，是⼀种定义良好、易于表达、功能强⼤且普遍适⽤的建模语⾔。
UML基本内容详述（1）视图 视图是表达系统的某⼀⽅⾯特征的UML建模元素的⼦集；试图并不是图，它是由⼀个或多个图组成的对系统某个⾓度的抽象。
1）⽤例视图（核⼼视图） 强调从⽤户的⾓度看到的或需要的系统功能。
2）逻辑视图 该视图⽤于描述系统内实现的逻辑功能，展现系统的静态或结构组成及特征。
3）组件视图 该视图从系统实现的⾓度来描述模型对象间的关系。
4）配置视图 该视图⽤于说明系统的物理配置。
（2）图表 图表是描述视图内容的图。
1）⽤例图 ⽤于描述外部项与系统提供的使⽤事件之间的联系。
⼀个使⽤事件是系统提供的功能的具体描述，是系统分析⼈员从⽤户⾓度描述系统的功能，是功能与功能之间以及功能与⽤户之间的关系。
使⽤事件定义了系统的功能需求。
简单理解：⽤来描述系统的功能。
2）类图 ⽤于描述系统的静态结构。
类可以⽤不同⽅式连接，主要包括联合、依赖、独⽴和包装。
⼀个系统⼀般有多张类图，⼀个类可在不同的视图中出现。
3）对象图 ⽤于表述系统在某个时刻的静态结构。
对象图也可作为协作图的⼀部分，说明⼀组对象之间的动态协作关系。
对象图与类图的区别：对象图表⽰的是类中的许多对象实例，⽽不是类本⾝。
4）状态图 ⽤于说明类中的对象可能具有的状态，以及由时间引起的状态的改变。
简单理解：描述了系统元素的状态条件和响应。
5）顺序图（时序图） ⽤于描述对象间的动态协作关系。
表达了对象间发⾏消息的时序，同时也表达出对象间的相互作⽤，以及当系统执⾏到某个特定位置时可能会发⽣的事。
用例图和类图
类图的需求分析
• 小王是一个爱书之人，家里各类书籍已过千册， 而平时又时常有朋友外借，因此需要一个个人图 书管理系统。 • 该系统应该能够将书籍的基本信息按计算机类、 非计算机类分别建档，实现按书名、作者、类别 、出版社等关键字的组合查询功能。在使用该系 统录入新书籍时系统会自动按规则生成书号，可 以修改信息。该系统还应该能够对书籍的外借情 况进行记录，可对外借情况列表打印。另外，还 希望能够对书籍的购买金额、册数按特定时间周 期进行统计。
筛选备选类(分析过程)
1.“小王”、“人”很明显是系统外的概念，无 须对其建模； 2.而“个人图书管理系统”和后面的“系统”指 的就是将要开发的系统，即系统本身，也无须 对其进行建模； 3.很明显，“书籍”是一个很重要的类，而“书 名”、“作者”、“类别”、“出版社”、“ 书号”等则都是用来描述书籍的基本信息的， 因此应该作为“书籍”类的属性处理，而“规 则”是指书号的生成规则，书号则是书籍的一 个属性，因此“规则”可以作为编写“书籍” 类构造函数的指南。
1. 其它系统：当系统需要与其它系统交互时，如ATM柜 员机系统中，银行后台系统就是一个参与者； 2. 硬件设备：如果系统需要与硬件设备交互时，如在开 发IC卡门禁系统时，IC卡读写器就是一个参与者； 3. 时钟：当系统需要定时触发时，时钟就是参与者。
识别参与者的用例案例
• 酒店管理系统（前台）
• 事件描述：客户前来酒店预定座位，由前台服 务人员为其检查座位信息。如果客满或客户对 座位不满意，则进入等待队列；如果有满意座 位，则由前台服务人员为其安排座位。客户完 成消费后，至前台服务人员处办理结账，其可 选择现金付款或刷卡消费2种结账方式。
（ 酒 店 识 管 别 理 参 系 与 统 用 者 例 ） 图
UML第4章 用例视图讲解
付福福福福州州州州大大大大学学学学
亓晓静 亓晓静 亓晓静
亓晓静33
福福州州大大学学 福福福福福福福福州州州州州州州州大大大大大大大大学学学学学学学学
泛化与扩展
扩展事件流是临时附加到基用例事件流的某个位 置上，是属于同一层的
泛化与包含
泛化和包含都是用于抽取用例的公共行为，但泛 化关系要求父用例和子用例之间拥有“is-a -kindof”关系，这样继承才有意义。
亓晓静 静
亓晓静
福州大学 亓晓静
福州大学
福州大学 亓晓静
亓晓静 亓晓静 亓晓静 亓晓静
福州大学 亓晓静
福州大学 亓晓静
福州大学 亓晓静
福州大学 亓晓静
福福州州大大学学
亓晓支静 付 亓晓静
宝支福福付州州大大学学
亓晓静 亓晓静
福州大学 亓晓静
福州大学 亓晓静
福州大学 亓晓静 邮局福汇州款大学支付亓晓静
福福福福州州州州大大大大学学学学
亓晓静 亓晓静网银支 亓晓静 亓晓静
福州大学 亓晓静
福州大学 亓
福州大学 亓晓静
福州大学 亓
福州大学 亓晓静 学静
3
福州大学 亓 学
模拟基金项目
用例视图中包含4个用例图
用例图说明了系统应该有哪 些功能，每个功能为谁服务
4
用例图
从系统外部来观察系统提供哪些服务或系统具有 什么样的行为
优点
• 易于沟通 • 关注用户的目标，可以较准确地描述需求
<<extend>>
交纳罚金
将可选的行为列到扩展用例
• 交纳罚金 • 触发：超期或车辆损坏 • 扩展点：还车中的检查 • 级别：子功能
▪ …… ▪ 3 计算罚金 ▪ ……
UML九种图之用例图和类图
UML九种图之⽤例图和类图前⾔近期写UML⽂档，看视频的时候感觉掌握的还能够，当真正写⽂档的时候才发现不是⼀件easy的事。
写⽂档⾃⼰⼜翻开⾃⼰的笔记看了⼀遍⼜⼀遍。
以下就给⼤家介绍⼀下我画的⼏张图：⽤例图1. ⽤例图的构成（⽤例，⾓⾊，关系）⽤例：指功能的描写叙述⾓⾊：触发起某种事件关系：⽤例图的关系（依赖，泛化，关联）2. ⽤例图的作⽤（1）⽤例视图是整个UML设计的关键，影响到整个UML设计的过程（2）⽤例模型驱动了需求分析后各个阶段的开发（3）⽤例模型⽤于需求分析阶段，表明了开发⼈员和⽤户针对需求达成的某种共识注意⼏个keyword：开发⼈员，⽤户，共同商讨达成某种共识3.设计原则将系统看做⿊盒⼦，从⽤户⾓度理解系统，不须要考虑某个功能是怎样实现的。
仅仅须要考虑系统由谁来运⾏和怎样交互和运⾏。
以下是我画的⽤例图：以⽤户的权限为基础画出来的。
类图1.类图的构成类、接⼝、协作、关系、包2.类的构成2.类图的作⽤类图⼀般在具体设计过程中出现，主要⽤来描写叙述系统中各个模块中类之间的关系，包含类或者类与接⼝的继承关系，类之间的依赖、聚合等关系。
通过类图，就能实际的把系统中的各个类，即对象描写叙述清楚，下⼀步就是依照这个具体的设计编码了。
3.类图的设计Use case——>class（要点，抽象名词得到类）——>确定类的属性和⽅法——>属性是静态⾏为描写叙述，⽅法是动态⾏为的描写叙述——>正确表达类与类之间的关系以下是我对机房收费系统设计的类图，理解的不是⾮常清楚，可定存在诸多问题，希望⼤家积极指正。
以上是我看完UML之后对⽤例图和类图的理解，感觉理解的不是⾮常清楚，若有什么问题希望⼤家积极指正。
用例图基础
识别参与者
面对一个复杂系统，要列出用例清单通常 是很困难的。这时我们可以先识别出参与 者，因为参与者是相对比较容易确定的， 再围绕每个参与者识别它的用例。
识别参与者
首先分析如下问题：
谁将使用系统? 谁向系统提供输入？ 谁将管理，维护系统？ 谁是系统使用的外部资源？ 哪个已有系统与之交互？ 有事情自动发生吗？ 系统需要操纵哪些设备？
的背离方向为发起者
参与者之间的关系
常见的是泛化关系，如people与student，
teacher的关系
用例间的关系
用例与用例之间可以存在的关系分为3种： 泛化（generalization），包含（include），和
扩展（extend）。
用例间关系
泛化关系
泛化表示几个元素的某些共性。例如在买票系统中，
个人购买和团体购买都是买票的特例，具有一些共同 的特性，将这些共同的特性抽象出来，定义一个“买 票”的基用例，个人购买和团队购买从“买票”基用 例继承。
包含关系
包含使一个用例的功能可以在另一个用例中使用。在
两种情况下我们引入包含关系：首先，如果两个以上 的用例有相同的功能，则可以将这个功能分解到另一 个用例中。其次，一个用例的功能太多时，可以用包 含关系建模两个小用例。在自动饮料售货系统中，用 例“放置饮料”和“收钱”都包含打开和关闭机器的 功能。由此可以抽取出这两个用例，并让用例“放置 饮料”和“收钱”包含它们。
用例
在UML中，用例用椭圆来表示，它用来描 述系统所执行的动作序列集，并为执行者 产生一个可供观察的结果。 用例表示了系统提供给参与者的功能，所 以用例集合构成了系统的所有使用功能。
UML图基础介绍
依赖 【依赖关系】：是一种使 用的关系，即一个类的实现需 要另一个类的协助，所以要尽 量不使用双向的互相依赖.
【代码表现】：局部变量、 方法的参数或者对静态方法的 调用 【箭头及指向】：带箭头 的虚线，指向被使用者
各种类图关系
3、对象图（Object Diagrams）
描述的是参与交互的各个对象在交互过程中某一时刻的状态。对象图 可以被看作是类图在某一时刻的实例。
第三部分
图的差异比较
图的差异比较
1.序列图(时序图)VS协作图 序列图和协作图都是交互图。二者在语义上等价，可以相互转化。但是侧重点不同： 序列图侧重时间顺序，协作图侧重对象间的关系。 共同点：时序图与协作图均显示了对象间的交互。 不同点：时序图强调交互的时间次序。 协作图强调交互的空间结构。 2.状态图VS活动图 状态图和活动图都是行为图。状态图侧重从行为的结果来描述，活动图侧重从行为 的动作来描述。状态图描述了一个具体对象的可能状态以及他们之间的转换。在实际的 项目中，活动图并不是必须的，需要满足以下条件：1、出现并行过程&行为；2、描述 算法；3、跨越多个用例的活动图。 3.活动图VS交互图 二者都涉及到对象和他们之间传递的关系。区别在于交互图观察的是传送消息的对 象，而活动图观察的是对象之间传递的消息。看似语义相同，但是他们是从不同的角度 来观察整个系统的。
第四部分
UML与软件工程
UML与软件工程
UML图是软件工程的组成部分，软件工程从宏观的角度保证了软件 开发的各个过程的质量。而UML作为一种建模语言，更加有效的实现了软 件工程的要求。
UML与软件工程 如下图，在软件 的各个开发阶段需要的 UML图。
UML与软件工程 下表是UML使用人员图示。
1绘制用例图
就可以完成的任务。 用例强调了能够增加可见的或可度量的业务价值
EBP级别上的用例
一个EBP级别上的用例通常被称为
一个用户目标级别上的用例，以强
调用例应该帮助系统的用户来实现
自己的目标
解决
找出用户的目标
你想做什么？
方案
你的目标是什么？ 和过
系统分析师UML用例实战》介绍如 何通过用例掌握UML。《系统分析 师UML用例实战》的案例基于 Wesley和Richard两个角色叙述，从 两人开始接到一个书店系统的项目， 到动手建立用例模型，并且应用用 例技术来估算工时，系统记述了 UML用例的应用方法。
第1章 绘制用例图
《系统分析师UML用例实战》
收银员或顾客
目标
处理销售 处理销售
……
……
……
确定用例——EBP级别的用例
一个好的用例为参与者产生一种可以估 量的价值结果
描述参与者想要系统完成的事情
用例
一组用例是一个系统的用户能够使 用系统完成的不同任务
可以通过考虑在系统实现后参与者 能够用它来做什么，简单地草拟出 这次迭代的一组初步的用例
影响软件项目的因素
不充分的用户输入 13%
其其它它 505%0%
不完整需求 12%
员工不足 6%
变更需求 12%
技术技能不足 7%
用例到底用在哪？
What
How
Do
用用 例例 图描
述
“用例”先睹为快——用例图
接待员 前台 领班
餐饮管理系统 记录预约
取消预约 <<include>>
<<include>> 调换餐桌
第4章 初识UML
4.4 UML中的扩展机制
4.4.3 标记值
4.4.3.2 自定义标记值
► 标记值是有关模型和模型元素的附加信息，在最终
的系统中是不可见的。 ► 自定义标记值时的具体步骤分成以下的几步： 1. 确定要定义标记值的目的。 2. 定义需要标记值的元素。 3. 为标记进行命名。 4. 定义值类型。 5. 根据使用标记值对象的不同，适当定义标记值。 6. 在文档中给出一个以上使用该标记值的例子。
4.4 UML中的扩展机制
4.4.2 构造型
► 构造型可以基于所有种类的模型元素：类、节点、
组件、注释、关联、泛化和依赖等都可以用来作为 构造型的基类。 ► 要表示一个构造型，可以将构造型名称用一对尖括 号括起来，然后放置在构造型模型元素名字的邻近， 例如<<use>>、<<extends>>等，<<use>>和 <<extends>>构造型的名字就是由UML预定义的。 ► 使用这些预定义的构造型用于调整一个已存在的模 型元素，而不是在UML工具中添加一个新的模型元 素。 ► UML中已经预定义了多种标准构造型，我们可以在 这些标准构造型的基础上自己定义构造型。
4.4 UML中的扩展机制
4.4.1 UML的体系结构
4.4.1.1 四层元模型体系结构
►
UML具有一个四层的体系结构，每个层次是根据该层 中元素的一般性程度划分的。从一般到具体，这四层 分别为元元模型层、元模型层、模型层、用户模型层， 如下图所示。
4.4 UML中的扩展机制
4.4.1 UML的体系结构
图、状态图、活动图、构件图和部署图。
4.1 UML的构成
4.1.2 图
UML各种图总结-精华
UML各种图总结-精华UML（UnifiedModelingLanguage）是一种统一建模语言，为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。
下面将对UML的九种图+包图的基本概念进行介绍以及各个图的使用场景。
一、基本概念如下图所示，UML图分为用例视图、设计视图、进程视图、实现视图和拓扑视图，又可以静动分为静态视图和动态视图。
静态图分为：用例图，类图，对象图，包图，构件图，部署图。
动态图分为：状态图，活动图，协作图，序列图。
1、用例图（UseCaseDiagrams）：用例图主要回答了两个问题：1、是谁用软件。
2、软件的功能。
从用户的角度描述了系统的功能，并指出各个功能的执行者，强调用户的使用者，系统为执行者完成哪些功能。
2、类图（ClassDiagrams）：用户根据用例图抽象成类，描述类的内部结构和类与类之间的关系，是一种静态结构图。
在UML类图中，常见的有以下几种关系:泛化（Generalization）,实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)。
各种关系的强弱顺序：泛化=实现>组合>聚合>关联>依赖2.1.泛化【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何继承父类的所有特征和行为。
例如：老虎是动物的一种，即有老虎的特性也有动物的共性。
2.2.实现【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现。
2.3.关联【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。
双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。
【代码体现】：成员变量2.4.聚合【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。
Rational Rose的四种视图模型
/art/201007/215560.htm.1 Rational Rose的四种视图模型在Rational Rose建立的模型中包括四种视图，分别是用例视图(Use Case View)、逻辑视图(Logical View)、构件视图(Component View)和部署视图(Deployment View)。
创建一个Rational Rose工程的时候，会自动包含这四种视图，如图5-1所示。
每一种视图针对不同的模型元素，具有不同的用途。
在下面的几个小节中将分别对这四种视图进行说明。
.1.1 用例视图（2）用例图(Use Case Diagram)。
在用例视图中，用例图显示了各个参与者、用例以及它们之间的交互。
在用例图下可以连接与用例图相关的文件和URL地址。
在浏览器中选择某个用例图，右键单击，可以看到在该用例图中允许创建的元素，如图5-7所示。
类图(Class Diagram)。
在用例视图下，允许创建类图。
类图提供了结构图类型的一个主要实例，并提供了一组记号元素的初始集，供所有其他结构图使用。
在用例视图中，类图主要提供了各种参与者和用例中对象的细节信息。
与在用例图下相同，在类图下可以创建连接类图的相关文件和URL地址。
在浏览器中选择某个类图，右键单击，可以看到在该类图中允许创建的元素，如图5-8所示。
协作图(Collaboration Diagram)。
在用例视图下，也允许创建协作图，来表达各种参与者和用例之间的交互协作关系。
与在用例图下相同，在协作图下可以创建连接与协作图相关的文件和URL地址。
在浏览器中选择某个协作图，右键单击，可以看到在该协作图中允许创建的元素，如图5-9所示。
序列图(Sequence Diagram)。
在用例视图下，也允许创建序列图，和协作图一样表达各种参与者和用例之间的交互序列关系。
与在用例图下相同，在序列图下也可以创建连接与序列图相关的文件和URL地址。
在浏览器中选择某个序列图，右键单击，可以看到在该序列图中允许创建的元素，如图5-10所示。
用例视图
•图形上用例用一个椭圆来表示，用例的名字可以书 写在椭与者（Actor）
• 参与者（Actor）是系统外部的一个实体（可以是 任何的事物或人），它以某种方式参与了用例的执 行过程。参与者通过向系统输入或请求系统输入某 些事件来触发系统的执行。参与者由他们参与用例 时所担当的角色来代表。 • 在图形上，参与者用人形图符表示。
三、用例（Use Case）
对需求建模
软件需求就是根据用户对产品的功能的期望，提出产品外部功 能的描述。需求分析师的工作是获取系统的需求，归纳系统所 要实现的功能，使最终的软件产品最大限度的贴近用户的要求。 需求分析师的一般只考虑系统做什么（what），而尽可能的不 去考虑怎么做（how）。 对系统功能建模可以参考如下方法： （1）识别系统外部的参与者，从而建立系统的语境。 （2）考虑每一个参与者期望的行为或需要系统提供的行为。 （3）把公共行为命名为用例。 （4）确定供其他用例使用的用例和扩展其他用例的用例。 （5）在用例图中对这些用例、参与者和它们间的关系建模。 （6）用描述非功能需求的注释修饰用例图。
第五章 用例视图
• 一、概述 • 二、参与者（Actor） • 三、用例（Use Case） • 四、用例图建模技术
一、用例图概述
• 画好用例图（Use Case Diagrams）是由软件需求 到最终实现的第一步，在UML中用例图用于对系 统、子系统或类的行为的可视化，以便使系统的用 户更容易理解这些元素的用途，也便利了软件开发 人员最终实现这些元素。 • UML中的用例图描述了一组用例、参与者以及它 们之间的关系。用例图包括以下3方面内容。 • （1）用例（Use Case） • （2）参与者（Actor） • （3）依赖、泛化以及关联关系
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 在图形上，参与者用人形图符表示。
三、用例（Use Case）
•用例是一个叙述型的文档 ，用来描述一个参与者 （Actor）使用系统完成某个事件时的事情发生顺序。 用例是系统的使用过程。更确切的说，用例不是需求 或者功能的规格说明，但用例也展示和体现出了其所 描述的过程中的需求情况。
•图形上用例用一个椭圆来表示，用例的名字可以书 写在椭圆的内部或下方。
• UML中的用例图描述了一组用例、参与者以及它 们之间的关系。用例图包括以下3方面内容。
• （1）用例（Use Case） • （2）参与者（Actor） • （3）依赖、泛化以及关联关系
二、参与者（Actor）
• 参与者（Actor）是系统外部的一个实体（可以是 任何的事物或人），它以某种方式参与了用例的执 行过程。参与者通过向系统输入或请求系统输入某 些事件来触发系统的执行。参与者由他们参与用例 时所担当的角色来代表。
• 可以通过一个清晰的，易被用户理解的时间流来 说明一个用例的行为。这个事件流包括用例何时 开始和结束，用例何时和参与者交互，什么对象 被交互以及该行为的基本流和可选流。
用例间的关系
• 用例除了与其参与者发生关联外，还可以参与系 统中的多个关系，这些关系包括：泛化 （Generalization）关系、包含（Include） 关系 和扩充（Extend） 关系。应用这些是为了抽取出 系统的公共行为和变种。
四、用例图建模技术
对语境建模 对系统语境建模可以参考如下方法。 • （1）得出需要从系统中得到帮助的组；执行系统
功能必须的组；与外界进行交互的组；执某些辅助 功能的组，并由此来识别系统外部的参与者。 • （2）将类似的参与者组织成泛化的关系中。 • （3）如需加深理解，可以为参与者提供构造型。 • （4）说明用例图中参与者和用例间的通信路径。
识别用例
• 识别用例最好的办法就是从分析系统的参与者开 始，考虑每个参与者是怎样使用系统。使用这种 策略的过程中可能会找出一个新的参与者，这对 完善整个系统建模很有帮助。
• 在识别用例的过程中，通过以下的几个问题可以 帮助识别用例：
• （1）特定参与者希望系统提供什么功能？ • （2）系统是否存储和检索信息？如果是，这个行
为由哪个参与者触发? • （3）当系统改变状态时，通知参与者吗？ • （4）存在影响系统的外部事件吗？ • （5）是哪个参与者通知系统这些事件？
用例与事件流
• 用例分析是处于系统的需求分析阶段，这个阶段 应该尽量的避免去考虑系统实现的细节问题。也 就是说，用例描述的是一个系统做什么，而不是 怎么做。
Hale Waihona Puke 对需求建模软件需求就是根据用户对产品的功能的期望，提出产品外部功 能的描述。需求分析师的工作是获取系统的需求，归纳系统所 要实现的功能，使最终的软件产品最大限度的贴近用户的要求。 需求分析师的一般只考虑系统做什么（what），而尽可能的不 去考虑怎么做（how）。
对系统功能建模可以参考如下方法： • （1）识别系统外部的参与者，从而建立系统的语境。 • （2）考虑每一个参与者期望的行为或需要系统提供的行为。 • （3）把公共行为命名为用例。 • （4）确定供其他用例使用的用例和扩展其他用例的用例。 • （5）在用例图中对这些用例、参与者和它们间的关系建模。 • （6）用描述非功能需求的注释修饰用例图。
第五章 用例视图
• 一、概述 • 二、参与者（Actor） • 三、用例（Use Case） • 四、用例图建模技术
一、用例图概述
• 画好用例图（Use Case Diagrams）是由软件需求 到最终实现的第一步，在UML中用例图用于对系 统、子系统或类的行为的可视化，以便使系统的用 户更容易理解这些元素的用途，也便利了软件开发 人员最终实现这些元素。