1-用例图建模步骤

UML建模之⽤例图关系⼀．UML简介 UML（统⼀建模语⾔，Unified Modeling Language）是⼀种定义良好、易于表达、功能强⼤且普遍适⽤的可视化建模语⾔。

它融⼊了软件⼯程领域的新思想、新⽅法和新技术。

它的作⽤域不限于⽀持⾯向对象的分析与设计，还⽀持从需求分析开始的软件开发的全过程。

在系统分析阶段，我们⼀般⽤UML来画很多图，主要包括⽤例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况⽽定。

其实简单的理解，个⼈理解，UML的作⽤就是⽤很多图从静态和动态⽅⾯来全⾯描述我们将要开发的系统。

⼆、什么是⽤例 ⽤例是对包括变量在内的⼀组动作序列的描述，系统执⾏这些动作，并产⽣传递特定参与者的价值的可观察结果。

这是UML对⽤例的正式定义，可能有点难懂。

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

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

⽤例在画图中⽤椭圆来表⽰，椭圆下⾯附上⽤例的名称。

三、什么是⽤例图 ⽤例图（use case diagram）就是由主⾓、⽤例以及它们之间的关系构成的图。

该图说明了⽤例模型中的关系。

可以将⽤例图组织到⽤例包中，并归⽤例包所有，让特定包中仅显⽰互为关联关系的内容。

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

参与者不是特指⼈，是指系统以外的，在使⽤系统或与系统交互中所扮演的⾓⾊。

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

还有⼀点要注意的是，参与者不是指⼈或事物本⾝，⽽是表⽰⼈或事物当时所扮演的⾓⾊。

⽐如⼩明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个⾓⾊参与管理，也可以作为借书者向图书馆借书，在这⾥⼩明扮演了两个⾓⾊，是两个不同的参与者。

参与者在画图中⽤简笔⼈物画来表⽰，⼈物下⾯附上参与者的名称。

《面向对象设计UML建模》---08本新版上机实验（一）创建用例及用例图一.实验目的：在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 drink Set drink Take moneyOpen machine Close machine显然, 前三个名词为参与者. 后面的那些功能为Use Case .③绘制自动饮料售货机售货的用例图. (提示：首先找出参与者和用例之间的关系, 建立初步用例图, 然后细化用例建立用例之间的《include》或《extend》关系。

)案例2. 用例之间的三种关系练习·分析用例之间的“泛化关系”、“include”和“extend”关系。

·在Rose下创建包括以上三种关系的Use Case图。

一．UML简介UML（统一建模语言，Unified Modeling Language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。

它融入了软件工程领域的新思想、新方法和新技术。

它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。

在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。

其实简单的理解，也是个人的理解，UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2021/2/4
类的图形表示和示例
4
在类图中，根据建模的不同景象，类图标中不一定列出全部的
内容。如在建立分析模型或设计模型时，甚至可以只列出类名， 在图中着重表达的是类与类之间的联系；在建立实现 模型时，则应当在类图标中详细给出类的属性和方法等细节。
2021/2/4
5
1. 属性
属性（Attribute）在UML类图标的矩形框中用文字串说明，如 下图所示。
UML类图详细教程
4.1 UML基本类图
面向对象设计的基础就是使用类。类是用来代表现实事务或 者功能的构造块。在本节中，我们将要学习如何建模类及其相互 之间的关系，以便在编写代码之前让你对系统拥有全面的认识。
类图是由若干类关联在一起，反映系统或者子系统组成结构的 静态图。类图的建模贯穿工程的分析和设计阶段的始终，通常从 商务伙伴能够理解的类开始建模，最终往往成为只有开发小组才 能够完全理解的类。
displays
1
Administrator
OnlineUser
WebSite
use
+ UserName : String = ""
# Password : String = ""
+ Logon() + View()
2021/2/4
45
练习： 建模一个类图
在这个练习中，将会从用例图建模一个类图。读者应该遵循
•若可视性标记为“-”或“ private”，则为私用属性，不可以被外部 对象访问，只能为本类的对象使用。
•可视性可以缺省，表示该属性不可视。Leabharlann 2021/2/47
Student类
2021/2/4

用例建模指南用例(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简介、工具及示例UML（Unified Modeling Language）是一种用于软件开发的标准化建模语言，它使用图形表示法来描述软件系统的不同方面。

在软件开发过程中，使用UML可以帮助开发人员更清晰地理解系统的结构和行为，从而更好地进行设计和实现。

UML提供了包括结构模型、行为模型和交互模型在内的多种建模方式，其中每种模型都有各自的符号和语法规则。

通过使用这些模型，开发人员可以将系统分解成不同的部分，然后逐步细化这些部分的设计，以便更好地组织和管理项目。

在UML中，最常用的建模元素包括用例图、类图、时序图、活动图、状态图等。

每种图表都有其特定的用途和表达能力，开发人员可以根据实际需要选择合适的图表进行建模。

除了建模元素外，UML还定义了一系列的建模工具，这些工具可以帮助开发人员更高效地进行建模和分析。

其中一些常用的建模工具包括Enterprise Architect、Rational Rose、StarUML等。

下面将对13种UML简介、工具及示例进行详细介绍：1. 用例图（Use Case Diagram）用例图是UML中描述系统功能和用户交互的基本图表之一。

它用椭圆表示用例，用直线连接用例和参与者，展示了系统外部用户和系统之间的交互。

用例图可以帮助开发人员更清晰地理解系统的功能需求，从而指导系统的设计和实现。

示例：一个简单的在线购物系统的用例图包括用例“浏览商品”、“添加商品到购物车”、“提交订单”等，以及参与者“顾客”和“管理员”。

2. 类图（Class Diagram）类图是UML中描述系统结构和静态关系的基本图表之一。

它用矩形表示类，用线连接类之间的关系，包括关联关系、聚合关系、继承关系等。

类图可以帮助开发人员更清晰地理解系统的对象结构和类之间的关系，从而支持系统的设计和重构。

示例：一个简单的学生信息管理系统的类图包括类“学生”、“课程”、“教师”等，以及它们之间的关系如“选修”、“授课”等。

够决定出哪些人将会与系统进行交互。
书面的规格说明和其它项目文档（如会谈备忘录等） 需求研讨会和联合应用开发会议的记录：这些会议的参 与者通常是很重要的，因为他们在组织中所代表的角色 就是可能与系统发生交互的参与者。 当前过程和系统的培训指南及用户手册：这些东西中经 常会有潜在参与者。
24
•
如何寻找系统的参与者（2/2）
如ATM柜员机系统中，银行后台系统就是一个
参与者； 2）硬件设备：如果系统需要与硬件设备交互时， 如在开发IC卡门禁系统时，IC卡读写器就是一 个参与者；
3）时钟：当系统需要定时触发时，时钟就是参与
者
20
识别参与者：考勤卡系统
开发者：谁将使用这个应用程序？ 客 户：所有用它来记录可记帐以及不可记帐的工时的雇员 …… Employee 开发者：现在考勤卡应用程序是什么样的？ 客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表 格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目 代码，横向是日期。雇员可以在每个条目上填写说明。 开发者：这个收费项目代码可以从什么地方得到？ …… 开发者：谁来管理收费项目代码？ Administrativ 客 户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经 e User 理总会告诉他的下属应该填写什么。 ……
例子：学生注册课程系统
• 某大学准备开发一个学生课程注册系统：
– 学生使用该系统查询新学期将开设的课程和讲课教师情况，选择自己要 学习的课程进行登记注册，并可以查询成绩单 – 教师使用该系统查询新学期将开设的课程和选课学生情况，并可以登记 成绩单 – 注册管理员使用该系统进行注册管理，包括维护教师信息、学生信息和 课程信息等 – 在每个学期的开始，学生获得该学期的课程目录表，课程目录表列出每 门课程的所有信息，诸如基本信息、教师、开课系和选课条件等 – 新学期开始前两周为选课注册时间，在此期间学生可以选课注册，并且 允许改变或取消注册申请，开学两周后注册管理员负责关闭课程注册。 每个学生可以选择不超过4门课程，同时指定2门侯选课程以备主选课程 未选上。每门课程最多不能超过10人，最少不能低于3人，低于3人选课 的课程将被取消。一旦学生的注册过程完毕，注册系统将有关信息提交 收费系统以便学生付费。如果在实际注册过程中名额已满，系统将通知 学生在提交课程表之前予以更改 – 在学期结束时，学生可以存取系统查看电子成绩单。由于学生成绩属于 敏感信息，系统必须提供必要的安全措施以防非法存取

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用例建模[实验日期]年月日[实验目的]·掌握客户需求分析的方法和步骤·了解以用例驱动的软件开发方法·识别并编写用例·掌握用Rose进行用例建模的具体方法和步骤[实验内容]要求学生根据周围的实际情况，自选一个小型应用项目，分析业务需求，识别并编写用例、绘制用例图以理解系统需求。

亦可采用教师指定的“企业综合信息管理系统”中的“进销存管理子系统”(参见“项目背景及简要分析.pdf”)。

[实验原理和步骤]建模原理：(1)需求获取。

以任务和客户为中心，通过会议、面谈等手段对客户需求进行调研，获得系统目标、范围和功能要求的初步说明。

(2)用例分析。

确定用例，同时采用分层思想，对用例的层次级别进行划分（高层用例、子系统级、用户目标级）（3）用例描述。

分层绘制用例图，撰写用例的文字描述（采用单栏格式）。

步骤：（1）需求获取。

自选题目，与相关客户、领域专家等反复商讨，获得系统目标、范围和功能要求的初步说明。

（也可采用教师指定的题目：“企业综合信息管理系统”中的“进销存管理子系统”，但要仔细研读“企业现状”、“系统目标、范围和功能要求”等文字说明）。

（2）用例分析。

确定系统范围和边界、确定参与者、确定用例。

（3）用例描述。

分层绘制用例图、描述用例。

画图原理：采用Rose软件进行用例建模必须建立在完好的系统用例分析基础之上．只有做好系统用例分析，系统用例建模才能这到预期的效果。

步骤：（1）分层绘制用例图，每层采用“包”进行管理。

（2）以“企业综合信息管理系统”->“进销存管理”子系统->“销售管理”->“合同管理”->“收款单处理”为主线，完成附录2中的操作过程（亦可选择“企业综合信息管理系统”->“进销存管理”子系统->“库存管理”->“原材料出库”->“领料单处理”主线）[实验结果]《学生填写》采用ROSE绘制的“企业综合信息管理系统”的1级用例图，以及其中的“进销存管理”用例的文字描述。

用例图建模流程
用例图建模是一种描绘系统功能需求的有效方式，其基本流程如下：
1. 确定参与者：识别系统外部所有与系统交互的实体，如用户、硬件设备或其他系统，定义为参与者。

2. 描述用例：列举系统应提供的各项主要功能，每个功能视为一个用例，描述其目的、前置条件、基本流程和可能的扩展流程。

3. 建立关系：在用例图中绘制参与者和用例，使用关联线连接参与者和他们所使用的用例，表示参与者与用例之间的交互关系。

4. 标注扩展和包含关系：若某个用例的行为可以根据特定条件变化或包含其他用例的行为，标注扩展（extend）和包含（include）关系。

5. 完善细节：添加必要的注释说明，细化用例描述，完善用例图，确保其准确反映系统功能需求。

实验二：建立动态模型一旦定义了一个工程的用例，就可以用它们来指导对系统的进一步开发。

用例的实现描述了相互影响的对象的集合，这些对象将支持用例所要求的功能。

给出系统用例的实现，是从外部视图转到内部结构的第一步。

在UML中，用例的实现用交互图来指定和说明。

交互图通过显示对象之间的关系和对象之间处理的消息来对系统的动态特性建模。

有两种交互图：序列图和协作图。

1、创建交互图的步骤交互图一步一步地显示用例的实现流程。

它包括流中需要什么对象、对象之间发送什么、什么角色启动流、消息按什么顺序发送等。

系统要求实现的所有不同情形都在交互图中记录。

通过从用例建模得到的用例文档说明、词汇表和用例图来创建交互图。

2、实例本节主要以选课系统中的选课用例（Select Course）为例，来学习序列图的设计与实现。

2.1 分析为了使问题更简单一些，不考虑学生的登陆。

假设学生已经成功登陆系统，选课的事件流如下：（1）学生进入选课主界面。

（2）学生点击选课。

（3）系统显示所有课程信息。

（4）学生选择课程。

（5）系统验证课程是否可选。

A1：课程不可选（6）系统提示课程选择成功，提示学生交费。

（7）用例结束。

A1：课程不可选（1）系统提示课程不可选及原因。

（2）学生重新选课。

（3）重新验证直至成功。

（4）转选课事件流第6步。

首先，查找Select Course用例的对象。

从事件流中发现涉及以下对象：（1）界面。

（2）课程。

（3）对于业务层的操作，也应该有对象进行处理。

（4）事件流中设计的角色有：学生、数据库。

然后，分析对象、角色之间交互的消息。

本用例主要有以下交互：（1）学生通过界面发送选课命令。

（2）界面向控制对象请求课程信息。

（3）控制对象向数据库发送查询数据消息。

（4）控制对象暂存数据库的查询结果。

（5）界面对象从控制对象中取得所有的课程信息。

（6）在界面上显示所有的课程信息。

（7）界面对象发送命令要求控制对象删除课程信息。

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. 确定参与者及其目标
寻呼台系统。用户如果预订了天气预报，系统每天 定时给他发送天气消息；如果当天气温高于35度， 还要提醒用户注意防暑。 这个叙述里，谁是寻呼台系统的Actor？用户？气温？ 还是时间？ 回答：时间，或者是一个外部消息发送系统；时间 启动该用例功能，温度是启动之后的一个条件， 所以温度不应算为一个参与者。

用例的必要性
有助于理解系统需求 有助于正确设计系统功能 有助于正确建立需求与功能间的关系
构建用例图
问题详述
系统边界框
用例
用例
参与者
开发典型用例
用例之间的关系
用例之间的关系是可以结构化的。以下是三 种常见的用例关系 包含关系 扩展关系 泛化关系 对于简单的应用，独立用例就足够了。但是， 对于大型应用，组织用例的结构是会有帮助的。 复杂的用例可以用包含、扩展和泛化关系自小 型用例的基础之上构建起来。
修改历史记录* 关于用例的修改时间、原因和修改人信息等
问题*
决策* 频率*
与此用例开发相关的问题列表
关键决策列表 参与者访问该用例的频率
构建用例图的过程
步骤 1. 识别系统边界 步骤 2. 确定参与者及其目标 步骤 3. 确定用例 步骤 4. 确定参与者和用例之间的关系 用例模型的一些准则，书P108 每个用例必须给用户提供价值 用例的描述是非形式化的，但用例的关系 可以形式化
用例图的元素

参与者
一个参与者也可以由多个人来担任
这是错的
这是对的
用例图的元素

参与者
•我们建立的是
系统模型，而非 业务模型，所以 要站在系统的角 度对业务对象进 行有效的分类

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里，如果一个系统可以创建多个用例图，则可以用包的形式来组织。

实验一、建模工具Visio软件和PlayCase的使用方法及用例图班级：姓名：学号：评分：一．实验目的熟悉建模工具Microsoft Visio和PlayCase软件的使用方法；通过实例掌握软件需求分析的概念和步骤，并通过以上两个软件完成用例图。

二．实验设备计算机及windows 7操作系统、Microsoft Visio和PlayCase软件。

三．软件工具的实验内容及步骤实验内容：1．熟悉开发绘图工具Microsoft Visio软件的工作环境和基本使用方法。

2．熟悉建模工具PlayCase的功能和特点。

3．掌握利用PlayCase自动生成项目文档（以需求分析文档为例）的方法。

4. 了解Visio和PlayCase两种软件在软件工程建模过程中的作用，初步了解有关软件设计中常用的流程图、数据流图、用例图、顺序图、类图、组件图、部署图等的基本概念。

实验步骤：1、在启动操作系统（如Windows 7）之后，启动Microsoft Visio软件。

2．利用软件中的入门教程进行学习。

3、进入Visio的UML建模绘图界面通过“开始”|“程序”，运行Microsoft Office Visio 2007，出现Microsoft Visio 界面。

方法一：在左侧的“类别”区域中单击“软件和数据库”，然后在右侧的“特色模板”中单击“UML模型图”，则进入Visio的UML建模绘图界面。

模板类别特色模板方法二：单击菜单“文件”| “新建”| “软件和数据库”| “UML模型图”。

4、熟悉UML建模绘图界面在Visio的UML建模绘图界面中，最大的白色区域就是绘图区。

左上方的“形状”窗口就是Visio的UML元素调板，它由很多的标签页组成。

每个标签页提供了一个特定的UML图标。

左下方的“模型资源管理器”就是Visio的字典，字典就是所创建的所有元素及其属性的记录的集合。

当Visio打开并准备开始UML绘图的时候，“UML静态结构”标签页就会激活，我们就可以创建UML 模型（如类图、对象图、包图、用例图、交互图、活动图等等）。