用例视图
【软件架构】运用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之后对⽤例图和类图的理解，感觉理解的不是⾮常清楚，若有什么问题希望⼤家积极指正。
- 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中用例图用于对系 统、子系统或类的行为的可视化，以便使系统的用 户更容易理解这些元素的用途，也便利了软件开发 人员最终实现这些元素。