1-用例图建模步骤
学生选课系统完整的UML建模
信息系统集成技术及应用题目：UML系统分析设计、建模与实现学号：100430112022姓名：杨家建专业：计算机技术指导教师：舒远仲UM L系统分析设计与建模以简单的学生选课系统进行详细的系统分析与建模。
（一）系统用例图1•首先根据需求分析可知：管理员维护课程信息，对其进行添加、修改、删除等。
学生可以在线查询课程信息，并进行选课，也可以在规定时间内更改选修 的课程。
我们发现系统中的参与者有：管理员和学生，然后从参与者的角度就可 以发现系统的用例，并绘制出系统的用例图，如图 1所示：图1学生选课系统用例图2.对部分用例进行描述：“添加课程”用例1） 用例名：添加课程2） 执行者：管理员3） 目的：管理员通过系统界面进入，添加所要开设的课程，确认无误后将其信息保 存到数据库中，以供学生选择。
4）过程描述:5） 管理员选择进入管理界面，用例开设修改课程停开课程A —管理员vvinclude>><<include>>添加课程vvinclude>><<extend>>删除课程查询课程信息6）系统提示输入管理密码7）管理员输入密码8）系统验证密码9）A1:密码错误10）进入管理界面，系统显示目前所建立的全部课程信息11）管理员选择添加课程12）系统提示输入新课程信息13）管理员输入信息14）系统验证是否和已有的课程冲突15）A2 :有冲突16）10 ）系统添加新课程，提示课程添加成功17）11 ）系统重新进入管理界面，显示所有课程18 ）12 ）用例结束19 ）异常事件流处理：20 ）A1 :密码错误：1）系统提示再次输入。
2）用户确认后进入第5）步。
21 ）A2 :有冲突：1）系统提示冲突，显示冲突的课程信息。
2）用户重新输入,验证无误后进入第10 ）步。
选课”用例1）用例名：选课2）执行者：学生3）目的：学生进入选课系统界面，浏览的课程，最后选择一门自己喜欢的课程并提交。
数据建模--用例图
刹车系统 传动系统
是什么
骑行 载物
能做什么
捏合刹车
蹬踏前行
人们能用他来做什么
用例建模符号
提问，下列哪些是用例
以日常接触的银行业务为例：
支持跨行业务
错，这是一个业务规则限定业务范围
插入卡片
错，这是一个过程步骤，不是完整目标
3、实例：图书管理系统的用例图
借阅者 图书馆管理员 系统管理员
借阅者请求服务的用例图
图书馆管理员处理借书、还书的用例图
系统管理员进行系统维护的用例图
课后作业
复习用例图概念，及相应的建模步骤 创建“学生选课系统”用例图
谢谢观看
用例间常用的两类关系
包含关系
<<include>>
基础用例 维护数据
包含用例
管理员
<<include>>
<<include>> <<include>>
修改数据
删除数据
添加数据
用例间常用的两类关系
扩展关系
<<extend>>
基础用例
扩展用例
查询成绩
学生
<<extend>>
导出查询结果
<<extend>>
数据建模
————用例图
主要学习内容
1、用例图相关概念
用例图定义：
定义分析： • 要素？ • 主要作用？
参与者是为了完成一个事件而与系统交互的实体，是指系统以外的，
UML 新编实验指导书(实验一)
天津理工大学（华信软件学院）实验指导书课程名称：面向对象设计UML建模适应课程：（1460460/1460466/14606617）上机实验（一）创建用例及用例图：一.实验目的：在Rose 2003 环境下设计应用系统的UML用例图（Use Case Diagram）。
二.实验内容：根据用户“需求陈述”创建Use Case框图。
案例1. 绘制“自动饮料机售货”的Use Case框图（包括功能扩展）案例2. 用例之间的三种关系练习案例3. 设计“网上学生选课系统”的Use Case 框图案例4. 设计“图书管理系统”的Use Case 框图三.操作步骤：案例1.①建立用例图的步骤：。
右击Use Case View。
选New Use Case Diagram。
起名，比如：Buy Drink。
双击Buy Drink图标，这时工具栏变成适合Use Case作图的形式。
设计Use Case Diagram.②“自动饮料机售货”需求陈述:“顾客通过自动饮料售货机, 可以方便地买到一听饮料。
而自动饮料售货机除了卖给顾客饮料外，还具备以下功能：〃供应商可以向自动饮料售货机添加饮料（需要打开和关闭自动饮料售货机的门）;〃收银员可以从自动饮料售货机取钱.（需要打开和关闭自动饮料售货机的门）经过分析可知自动饮料售货机系统涉及到的名词及概念有:Customer Supplier Cashier Buy drinkSet drink Take money Open machine Close machine显然, 前三个名词为参与者. 后面的那些功能为Use Case .③绘制自动饮料售货机售货的用例图.(提示：首先找出参与者和用例之间的关系, 建立初步用例图, 然后细化用例建立用例之间的《include》或《extend》关系。
)案例2.用例之间的三种关系练习〃分析用例之间的“泛化关系”、“include”和“extend”关系。
学生选课系统完整的UML建模
U M L系统分析设计与建模以简单的学生选课系统进行详细的系统分析与建模。
(一)系统用例图1.首先根据需求分析可知：管理员维护课程信息，对其进行添加、修改、删除等。
学生可以在线查询课程信息，并进行选课，也可以在规定时间内更改选修的课程。
我们发现系统中的参与者有：管理员和学生，然后从参与者的角度就可以发现系统的用例，并绘制出系统的用例图，如图1所示：图1 学生选课系统用例图停开课程删除课程2.对部分用例进行描述：“添加课程”用例1）用例名：添加课程2）执行者：管理员3）目的：管理员通过系统界面进入，添加所要开设的课程，确认无误后将其信息保存到数据库中，以供学生选择。
4）过程描述：5）管理员选择进入管理界面，用例开设6）系统提示输入管理密码7）管理员输入密码8）系统验证密码9）A1:密码错误10）进入管理界面，系统显示目前所建立的全部课程信息11）管理员选择添加课程12）系统提示输入新课程信息13）管理员输入信息14）系统验证是否和已有的课程冲突15）A2：有冲突16）10）系统添加新课程，提示课程添加成功17）11）系统重新进入管理界面，显示所有课程18）12）用例结束19）异常事件流处理：20）A1：密码错误：1）系统提示再次输入。
2)用户确认后进入第5)步。
21）A2：有冲突：1)系统提示冲突，显示冲突的课程信息。
2）用户重新输入，验证无误后进入第10）步。
“选课”用例1）用例名：选课2）执行者：学生3）目的：学生进入选课系统界面，浏览的课程，最后选择一门自己喜欢的课程并提交。
4）过程描述：5）1）学生进入选课登录界面，用例开始6）2) 系统提示输入学号与密码7）3) 学生输入学号与密码8）4）系统验证9）A1：验证错误10）5) 进入选课主界面11）6）学生点击选课12）7）系统显示所有课程信息13）8）学生选择课程14）9）系统验证课程是否可选15）A2：不可选16）10）系统提示课程选择成功17）11）用例结束18）异常事件流处理：19）A1：验证错误：1）系统提示验证错误，提示重新输入。
UML用例图的画法
一．UML简介UML（统一建模语言，Unified Modeling Language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。
它融入了软件工程领域的新思想、新方法和新技术。
它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。
在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。
其实简单的理解，也是个人的理解，UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。
二．用例建模简介用例建模是UML建模的一部分，它也是UML里最基础的部分。
用例建模的最主要功能就是用来表达系统的功能性需求或行为。
依我的理解用例建模可分为用例图和用例描述。
用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。
用例描述用来详细描述用例图中每个用例，用文本文档来完成。
1．用例图参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。
还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。
参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。
用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
这是UML对用例的正式定义，对我们初学者可能有点难懂。
我们可以这样去理解，用例是参与者想要系统做的事情。
对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。
用例在画图中用椭圆来表示，椭圆下面附上用例的名称。
用例建模指南
用例建模指南用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。
用例方法最早是由Iva Jackboson博士提出的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。
1. 什么是用例？传统的需求表述："软件需求规约"(Software Requirement Specification)。
传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。
缺点：采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。
由此常常导致这样的迷惑：系统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计。
在有些公司的开发流程中，这种需求被称为"内部需求"，而对应于用户的原始要求则被称之为"外部需求"。
功能分解方法的另一个缺点是这种方法分割了各项系统功能的应用环境，从各项功能项入手，你很难了解到这些功能项是如何相互关联来实现一个完成的系统服务的。
所以在传统的SRS文档中，我们往往需要另外一些章节来描述系统的整体结构及各部分之间的相互关联，这些内容使得SRS需求更象是一个设计文档。
1.1 参与者和用例从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。
用例模型主要由以下模型元素构成：∙参与者(Actor)参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。
∙用例(Use Case)用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
用例图和类图
类图的需求分析
• 小王是一个爱书之人，家里各类书籍已过千册， 而平时又时常有朋友外借，因此需要一个个人图 书管理系统。 • 该系统应该能够将书籍的基本信息按计算机类、 非计算机类分别建档，实现按书名、作者、类别 、出版社等关键字的组合查询功能。在使用该系 统录入新书籍时系统会自动按规则生成书号，可 以修改信息。该系统还应该能够对书籍的外借情 况进行记录，可对外借情况列表打印。另外，还 希望能够对书籍的购买金额、册数按特定时间周 期进行统计。
筛选备选类(分析过程)
1.“小王”、“人”很明显是系统外的概念，无 须对其建模； 2.而“个人图书管理系统”和后面的“系统”指 的就是将要开发的系统，即系统本身，也无须 对其进行建模； 3.很明显，“书籍”是一个很重要的类，而“书 名”、“作者”、“类别”、“出版社”、“ 书号”等则都是用来描述书籍的基本信息的， 因此应该作为“书籍”类的属性处理，而“规 则”是指书号的生成规则，书号则是书籍的一 个属性，因此“规则”可以作为编写“书籍” 类构造函数的指南。
1. 其它系统：当系统需要与其它系统交互时，如ATM柜 员机系统中，银行后台系统就是一个参与者； 2. 硬件设备：如果系统需要与硬件设备交互时，如在开 发IC卡门禁系统时，IC卡读写器就是一个参与者； 3. 时钟：当系统需要定时触发时，时钟就是参与者。
识别参与者的用例案例
• 酒店管理系统（前台）
• 事件描述：客户前来酒店预定座位，由前台服 务人员为其检查座位信息。如果客满或客户对 座位不满意，则进入等待队列；如果有满意座 位，则由前台服务人员为其安排座位。客户完 成消费后，至前台服务人员处办理结账，其可 选择现金付款或刷卡消费2种结账方式。
（ 酒 店 识 管 别 理 参 系 与 统 用 者 例 ） 图
13种uml简介、工具及示例
13种uml简介、工具及示例UML（Unified Modeling Language）是一种用于软件开发的标准化建模语言，它使用图形表示法来描述软件系统的不同方面。
在软件开发过程中，使用UML可以帮助开发人员更清晰地理解系统的结构和行为，从而更好地进行设计和实现。
UML提供了包括结构模型、行为模型和交互模型在内的多种建模方式，其中每种模型都有各自的符号和语法规则。
通过使用这些模型，开发人员可以将系统分解成不同的部分，然后逐步细化这些部分的设计，以便更好地组织和管理项目。
在UML中，最常用的建模元素包括用例图、类图、时序图、活动图、状态图等。
每种图表都有其特定的用途和表达能力，开发人员可以根据实际需要选择合适的图表进行建模。
除了建模元素外，UML还定义了一系列的建模工具，这些工具可以帮助开发人员更高效地进行建模和分析。
其中一些常用的建模工具包括Enterprise Architect、Rational Rose、StarUML等。
下面将对13种UML简介、工具及示例进行详细介绍：1. 用例图（Use Case Diagram）用例图是UML中描述系统功能和用户交互的基本图表之一。
它用椭圆表示用例，用直线连接用例和参与者，展示了系统外部用户和系统之间的交互。
用例图可以帮助开发人员更清晰地理解系统的功能需求，从而指导系统的设计和实现。
示例：一个简单的在线购物系统的用例图包括用例“浏览商品”、“添加商品到购物车”、“提交订单”等，以及参与者“顾客”和“管理员”。
2. 类图（Class Diagram）类图是UML中描述系统结构和静态关系的基本图表之一。
它用矩形表示类，用线连接类之间的关系，包括关联关系、聚合关系、继承关系等。
类图可以帮助开发人员更清晰地理解系统的对象结构和类之间的关系，从而支持系统的设计和重构。
示例：一个简单的学生信息管理系统的类图包括类“学生”、“课程”、“教师”等，以及它们之间的关系如“选修”、“授课”等。
软件工程用例图
使用Rose创建用例的步骤说明
系统管理员参与用 例创建新账号、设 置账号、设置账号 基本信息、设置账 号权限、查看账号 和删除账号。在设 置帐号时，主要分 为设置账号的基本 信息和设置账号的 权限，为了便于修 改和维护，将这两 个功能分别抽象为 两个用例。所以用 例设置账号基本信 息、设置账号权限 和用例设置账号之 间是包含关系。
什么叫用例图
在用例建模中，为了更加清楚的描述用 例或者参与者，会使用到注释。
什么叫用例图
2. 用例图的作用
用例图是需求分析中的产物，主要作用是描述参与者 和用例之间的关系，帮助开发人员可视化的了解系统 的功能。借助于用例图，系统用户、系统分析人员、 系统设计人员、领域专家能够以可视化的方式对问题 进行探讨，减少了大量交流上的障碍，便于对问题达 成共识。 用例图可视化地表达了系统的需求，具有直观、规范 等优点，克服了纯文字性说明的不足。 用例方法是完全从外部来定义系统功能，它把需求和 设计完全的分离开来。我们不用关心系统内部是如何 完成各种功能的，系统对于我们来说就是一个黑箱子。
练习题
（1）学生需要登录“远程网络教学系统”后才能正常使用该系统所有功能。
如果忘记密码，可以通过“找回密码”功能找回密码。登录后学生可以 浏览课件、查找课件、下载课件、观看教学视频，请画出学生参与者的 用例图。
练习题
（2）教师登录“远程网络教学系统”后可以上传课件、上传教学视频课件、 发布教学心得、修改教学心得。如果忘记密码，可以通过“找回密码” 功能找回密码。请画出教师参与者的用例图。
用例之间的关系
在处理包含关系时，具体的做法就是把几个用例的公 共部分单独的抽象出来成为一个新的用例。主要有两 种情况需要用到包含关系： 第一，多个用例用到同一段的行为，则可以把这段共 同的行为单独抽 象成为一个用例，然后让其他用例 来包含这一用例。 第二，某一个用例的功能过多、事件流过于复杂时， 我们也可以把某一段事件流抽象成为一个被包含的用 例，以达到简化描述的目的。
跟我学UML建模工具StarUML(第3部分)——创建需求分析中的UML用例图的创建示例
1.1跟我学UML建模工具StarUML（第3部分）——创建需求分析中的UML用例图的创建示例1.1.1UML中的用例及用例图1、用例模型的基本组成部件为参与者、用例和系统删除成员2、用例模型的基本组成部件中的参与者（1）参与者（Actor）参与者表示系统用户能扮演的角色(role)，这些参与者可能有三大类：系统用户、与所建系统交互的其他系统、时间。
1)软件系统用户：使用本软件系统的人；2)其他系统：可能是其他的计算机或者一些硬件或者甚至是其它软件系统；3)时间：时间作为参与者时，经过一定时间触发系统的某个事件。
例如，ATM机可能每天午夜运行一些协调处理。
由于事件不在本系统的控制之内，因此也是本软件系统的参与者。
（2）某个“网上书店”和“在线网校”项目中的各个参与者示例说明在“网上书店”项目中的参与者主要有用户和系统统管理员，而管理员使用控制面板对系统和用户管理，也就是进行系统设置，管理用户、用户组、权限，查看系统访问日志及用户使用情况等的统计信息。
在“在线网校”项目中的学校课程管理子系统中则有三个参与者在不同的应用中互动。
这三个参与者分别是学生，讲师以及系统管理者。
而学生参与者使用了系统中浏览课程以及注册课程的功能，而系统管理者参与者则是负责管理注册的学员，编排课程以及确认课程。
讲师则是主导课程的参与者，他可以浏览，开办以及移除课程（当然，必须是这个讲师自己的课程）。
（3）在UML中参与者的图示（4）参与者之间的关系——泛化（特化或者继承）关系由于参与者是类，所以它拥有与类相同的继承关系描述（请见后面的类的关系说明），其UML的图示是用带空心三角形（箭头）的直线表示。
在特殊的参与者中还需要给出其特殊的成员定义。
（5）所要注意的问题1)参与者主要是指角色而非具体的个人2)用户与参与者之间的关系一个用户可以抽象为多个参与者，如：张三即可以是网上书店的读者，也可以是管理员；一个参与者可以包含多个用户，如：网上书店的读者可以是张三和李四。
《UML与软件建模》实验1 用例建模
《UML与软件建模》实验1用例建模[实验日期]年月日[实验目的]·掌握客户需求分析的方法和步骤·了解以用例驱动的软件开发方法·识别并编写用例·掌握用Rose进行用例建模的具体方法和步骤[实验内容]要求学生根据周围的实际情况，自选一个小型应用项目，分析业务需求，识别并编写用例、绘制用例图以理解系统需求。
亦可采用教师指定的“企业综合信息管理系统”中的“进销存管理子系统”(参见“项目背景及简要分析.pdf”)。
[实验原理和步骤]建模原理：(1)需求获取。
以任务和客户为中心，通过会议、面谈等手段对客户需求进行调研，获得系统目标、范围和功能要求的初步说明。
(2)用例分析。
确定用例，同时采用分层思想，对用例的层次级别进行划分（高层用例、子系统级、用户目标级）（3）用例描述。
分层绘制用例图，撰写用例的文字描述（采用单栏格式）。
步骤：（1）需求获取。
自选题目，与相关客户、领域专家等反复商讨，获得系统目标、范围和功能要求的初步说明。
（也可采用教师指定的题目：“企业综合信息管理系统”中的“进销存管理子系统”，但要仔细研读“企业现状”、“系统目标、范围和功能要求”等文字说明）。
（2）用例分析。
确定系统范围和边界、确定参与者、确定用例。
（3）用例描述。
分层绘制用例图、描述用例。
画图原理：采用Rose软件进行用例建模必须建立在完好的系统用例分析基础之上．只有做好系统用例分析，系统用例建模才能这到预期的效果。
步骤：（1）分层绘制用例图，每层采用“包”进行管理。
（2）以“企业综合信息管理系统”->“进销存管理”子系统->“销售管理”->“合同管理”->“收款单处理”为主线，完成附录2中的操作过程（亦可选择“企业综合信息管理系统”->“进销存管理”子系统->“库存管理”->“原材料出库”->“领料单处理”主线）[实验结果]《学生填写》采用ROSE绘制的“企业综合信息管理系统”的1级用例图，以及其中的“进销存管理”用例的文字描述。
用例图建模流程
用例图建模流程
用例图建模是一种描绘系统功能需求的有效方式，其基本流程如下：
1. 确定参与者：识别系统外部所有与系统交互的实体，如用户、硬件设备或其他系统，定义为参与者。
2. 描述用例：列举系统应提供的各项主要功能，每个功能视为一个用例，描述其目的、前置条件、基本流程和可能的扩展流程。
3. 建立关系：在用例图中绘制参与者和用例，使用关联线连接参与者和他们所使用的用例，表示参与者与用例之间的交互关系。
4. 标注扩展和包含关系：若某个用例的行为可以根据特定条件变化或包含其他用例的行为，标注扩展（extend）和包含（include）关系。
5. 完善细节：添加必要的注释说明，细化用例描述，完善用例图，确保其准确反映系统功能需求。
UML建模课程设计(史上最全)
UML建模课程设计目录1 引言 (4)2 UML概述 (4)2.1 UML简介 (4)2.2 UML模型图的构成 (4)2.3UML事物 (4)2.3.1构件事物 (5)2.3.2行为事物 (5)2.3.3分组事物 (5)2.3.4注释事物 (6)2.4 UML图及特征 (6)2.4.1 用例图 (6)2.4.2 类图 (6)2.4.3 对象图 (6)2.4.4 时序图 (6)2.4.5 协作图 (7)2.4.6状态图 (7)2.4.7活动图 (7)2.4.8组件图 (7)2.4.9配置图 (8)3 UML结合实例分析 (8)3.1 需求分析 (8)3.1.1系统开发需求 (8)3.1.2系统功能需求 (8)3.2 UML建模分析 (9)3.2.2类图 (10)3.2.3 活动图 (11)3.2.4 顺序图 (12)3.2.5 协作图 (13)3.2.6 状态图 (14)3.2.7 组件图 (15)3.2.8 部署图 (15)4 总结 (16)1 引言建模是开发优秀软件所有活动的核心部分。
在开发中利用UML来编制系统蓝图,并与仓库管理系统开发的特色相结合,提出了自己的一套UML的建模过程。
基于这个过程来进行系统的分析,设计,实现与测试。
运用UML建模思想与各种模型对仓库管理系统进行详细的描述。
2 UML概述2.1 UML简介UML (Unified Modeling Language)为面向对象软件设计提供统一的、标准的、可视化的建模语言。
适用于描述以用例为驱动，以体系结构为中心的软件设计的全过程。
UML的定义包括UML语义和UML表示法两个部分。
UML语义：UML对语义的描述使开发者能在语义上取得一致认识，消除了因人而异的表达方法所造成的影响。
UML表示法：UML表示法定义UML符号的表示法，为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。
2.2 UML模型图的构成事物(Things)：UML模型中最基本的构成元素，是具有代表性的成分的抽象关系(Relationships)：关系把事物紧密联系在一起图(Diagrams )：图是事物和关系的可视化表示2.3UML事物UML语言的事物,包括四类:结构事物:语言的静态构成要素，有7种：类和对象、接口、主动类、用例、协作、构件、节点。
第2章 用例图
构建用例图的过程
步骤 2. 确定参与者及其目标
寻呼台系统。用户如果预订了天气预报，系统每天 定时给他发送天气消息；如果当天气温高于35度， 还要提醒用户注意防暑。 这个叙述里，谁是寻呼台系统的Actor？用户？气温？ 还是时间？ 回答：时间，或者是一个外部消息发送系统；时间 启动该用例功能，温度是启动之后的一个条件， 所以温度不应算为一个参与者。
用例的必要性
有助于理解系统需求 有助于正确设计系统功能 有助于正确建立需求与功能间的关系
构建用例图
问题详述
系统边界框
用例
用例
参与者
开发典型用例
用例之间的关系
用例之间的关系是可以结构化的。以下是三 种常见的用例关系 包含关系 扩展关系 泛化关系 对于简单的应用，独立用例就足够了。但是， 对于大型应用，组织用例的结构是会有帮助的。 复杂的用例可以用包含、扩展和泛化关系自小 型用例的基础之上构建起来。
修改历史记录* 关于用例的修改时间、原因和修改人信息等
问题*
决策* 频率*
与此用例开发相关的问题列表
关键决策列表 参与者访问该用例的频率
构建用例图的过程
步骤 1. 识别系统边界 步骤 2. 确定参与者及其目标 步骤 3. 确定用例 步骤 4. 确定参与者和用例之间的关系 用例模型的一些准则，书P108 每个用例必须给用户提供价值 用例的描述是非形式化的，但用例的关系 可以形式化
用例图的元素
参与者
一个参与者也可以由多个人来担任
这是错的
这是对的
用例图的元素
参与者
•我们建立的是
系统模型，而非 业务模型，所以 要站在系统的角 度对业务对象进 行有效的分类
Rational Rose【UML建模】 教程+使用详解
Rational Rose 简介Rose模型（包括所有框图、对象和其他模型元素）都保存在一个扩展名为.mdl的文件中。
1. 环境简介Rational Rose可视化环境组成Rose界面的五大部分是浏览器、文档工具、工具栏、框图窗口和日志。
见图1-1。
图1-1：Rose界面浏览器：用于在模型中迅速漫游。
文档工具：用于查看或更新模型元素的文档。
工具栏：用于迅速访问常用命令。
框图窗口：用于显示和编辑一个或几个UML框图。
日志：用于查看错误信息和报告各个命令的结果。
浏览器和视图浏览器是层次结构，用于在Rose模型中迅速漫游。
在浏览器中显示了模型中增加的一切，如参与者、用例、类、组件等等。
Rose浏览器见图1-2。
浏览器中包含四个视图：Use Case视图、Logical视图、Component视图和Deployment 视图。
点击每个视图的右键，选择new就可以看到这个视图所包含的一些模型元素。
图1-2：Rose浏览器1.3框图窗口在图1-3所示的框图窗口中，我们可以浏览模型中的一个或几个UML框图。
改变框图中的元素时，Rose自动更新浏览器。
同样用浏览器改变元素时，Rose自动更新相应框图。
这样，Rose就可以保证模型的一致性。
图1-3：框图窗口各类框图的建立2.1建立用例图use case diagram从用例图中我们可以看到系统干什么，与谁交互。
用例是系统提供的功能，参与者是系统与谁交互，参与者可以是人、系统或其他实体。
一个系统可以创建一个或多个用例图。
创建用例图（图2-1-1）在浏览器内的Use Case视图中，双击Main，让新的用例图显示在框图窗口中。
也可以新建一个包（右击Use Case视图，选择new→package，并命名），然后右击这个新建包的，选择new→use case diagram。
对系统总的用例一般画在Use Case视图中的Main里，如果一个系统可以创建多个用例图，则可以用包的形式来组织。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1-用例图建模步骤
用例图建模步骤
窗口说明
1.开始
用例图在用例视图目录下，使用右键菜单“new”——》“use case diagram”。
2.工具栏调整
一般情况下，所有UML模型的工具栏都是可以调整的，可以根据具体需要对工具栏上的按钮进行定制。
在工具栏上使用右键菜单，选择“Customize”如图2，选择需要增加或减少的图标，如图3所示。
3.增加参与者
参与者的增加有2种方式，
方式一：使用工具栏上的快捷菜单
如图4，图5所示
方式二：使用左边栏右键菜单“new”——》“Actor”新增参与者功能
如图6所示，需要注意的是：使用此方式增加的参与者将不会自动出现在右边的绘图区中，需要把这个参与者拖到绘图区方可。
关于删除：在右边的绘图区，删除参与者可以使用Del键删除，但删除之后被删除的参与者在左边的目录下仍然是存在的。
即在绘图区中不能彻底的删除参与者。
在左边的目录区，
4.增加用例
用例增加的方式和方法与参与者增加的方式和方法是相同的。
5.建立参与者之间的关系
参与者之间的关系常见的是泛化关系。
步骤如下：
1）选择泛化关系，如图7所示。
2）如图8所示，画出两个参与者之间的泛化关系。
注意：起点是继承类，终点是被继承类。
即，画的时候是从儿子开始，到父亲结束。
6.建立用例之间的关系
用例之间的关系主要是3种，分别是包含（include），扩展（extend）和泛化
（generalization）。
我们只要熟悉一种建立方式，其他2种都可以采用同样的步骤实现。
建立包含关系步骤如下：
1）如图9所示，选择用例关系的图标。
2）如图10所示，从“登陆系统”用例开始，到“密码验证”用例结束画出关联关系，注意箭头的方向。
3）双击这条线或者右键点击这条线然后选择“Open Specification”菜单项（图11所示），
在弹出的窗口（图12）的Stereotype中选择包含（include）关系
结果如图13，图14所示
7.啊啊。