黄冈师范学院
计科院--实验报告
课程名称 UML建模语言
（实验类型：□综合性 √□设计性 □应用性）
实验课程 UML用例图的分析和设计
实验次数 第 一 次实验
学生姓名 黄燕霞
专业班级 计专0802
学 号 200826730212
一、 实验目的和要求
1.1 理解用例图的基本特点与分析方法
1.2 掌握用例建模方法
1.3 熟悉用例建模的基本过程
二、 实验条件（软件和硬件等条件）
2.1 微型机计算机
2.2 StarUML
三、 实验分析
3.1 以“在线留言系统”为目标，完成对系统的需求建模
3.2 完成系统整体的用例图（包括所有参与者）
3.3 对其中某个参与者的用例图进行细化（例如：管理员等）
3.4 对用例图进行分析，归纳优点、特色、缺陷
四、 实验方案或步骤
4.1 明确系统的参与者
4.2 从参与者的角度，识别系统用例并对其命名
4.3 画出参与者与用例的关系
4.4 画出用例之间或者参与者之间的关系
4.5 将某个用例进行细化
五、 实验小结
实验小结：通过本次实验掌握了各用例图之间的关系，掌握了用例建摸
的基本方法。能比较熟练的画出用例之间或参与者之间的关系，画图的过程中可以学到很多课本上没有的东西。
实验成绩：
教师签名：
日 期：
图书管理系统用例图
Return With FineQuery Borrower InfoQuery Book InfoAdd TitleRemove or Update TitleAdd BookAdd BorrowerRemove BookRemove or Update BorrowerAdd LibrarianRemove or Update librarianAdministatorSearch for bookQuery InfoBorrower<><>Reserve the bookLogin the system<><>Return the book<>Borrow the bookLibrarian<>Remove Reservation<>
汽车租赁系统用例图
by callon the webfill the order formreturn with fineget the carreturn the carcustormer<><>check the carQuery customer order recordrefuse requestsystem loginget the car to customerend the bussiness<>employeereserve the car<><><>
网络教学系统用例图
UserSystem LoginCourse IntroUpload CAIMessage IssueDownloadLook through infoArtical SearchIdentiy<>CAI ProcessInfomation UpdatePage MaintenanceProcess RegistrationAdministrator<>studentteacherMessage UPdate
UML用例图
Engineering Notebook
C++报告
98.11-98.12
翻译杨健
UML的一个重要部分是画用例图的功能在工程的分析阶段用例图被用来鉴别和划分系统功能它们把系统分成动作者(actor)和用例
动作者(actor)表示系统用户能扮演的角色(role)这些用户可能是人可能是其他的计算机 一些硬件或者甚至是其它软件系统唯一的标准是它们必须要在被划分进用例的系统部分以外它们必须能刺激系统部分并接收返回 用例描述了当动作者之一给系统特定的刺激时系统的活动这些活动被文本描述它描述了触发用例的刺激的本质输入和输出到其他活动者和转换输入到输出的活动用例文本通常也描述每一个活动在特殊的活动线时可能的错误和系统应采取的补救措施 例如考虑销售系统的一个网点活动者之一是客户和另一个是销售店员这正是一个来自该系统的用例
用例1销售店员结算一件商品 1 顾客放商品到柜台 2 店员用UPC读取器扫描商品上的UPC码 3 系统在数据库中查找UPC码获得商品的描述和价格 4 系统发出可听见的蜂鸣 5 系统用声音宣布商品的描述和价格 6 系统加价格和商品类型到当前发票 7 系统加价格到调节税小计
错误情况1UPC代码不能读取
如果在第2步之后UPC码无效或没有正确读取系统发出一声巨响
错误情况2商品不在数据库中
如果在第3步之后不能在数据库中找的该UPC闪动终端上的手动输入按 钮接收店员输入的价格和税码设商品描述为未知商品进入第4步 无疑销售系统的一个网点有比这更多的用例的确一个复杂系统这数目可达上千系统的全部功能可象这样在用例中被描述这使得用例成为很强的分析工具
画用例图
图1显示在UML图标形式下上面的用例看起来可能的样子用例自身被画成一个椭圆活动者被画成一个小人活动者被用线连到用例
销售店员
顾客商品结算
图 1 显然这是一个漂亮而简单的标记但还不止这些用例和活动者图标能被组装到大型的系统边框图这种图在一个矩形中显示系统中所有的用例矩形的外部是所有该系统的活动者并且它们被线连到用例这箱子表示系统的边框也就是它显示了一个特定系统内的
UML用例图用例描述详解
描述用例规约
应该避免这样一种误解――认为由参与者和用例构成的用例图就是用例模型，用例图只是在总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有一个总体的认识。除此之外，我们还需要描述每一个有例的详细信息，这些信息包含在用例规约中，用例模型是由用例图和每一个用例的详细描述――用例规约所组成的。RUP中提供了用例规约的模板，每一个用例的用例规约都应该包含以下内容：
• 简要说明 (Brief Description)
简要介绍该用例的作用和目的。
• 事件流 (Flow of Event)
包括基本流和备选流，事件流应该表示出所有的场景。
• 用例场景 (Use-Case Scenario)
包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。
• 特殊需求 (Special Requirement)
描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。
• 前置条件 (Pre-Condition)
执行用例之前系统必须所处的状态。
• 后置条件 (Post-Condition)
用例执行完毕后系统可能处于的一组状态。
用例规约基本上是用文本方式来表述的，为了更加清晰地描述事件流，也可以选择使用状态图、活动图或序列图来辅助说明。只要有助于表达的简洁明了，就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。如活动图有助于描述复杂的决策流程，状态转移图有助于描述与状态相关的系统行为，序列图适合于描述基于时间顺序的消息传递。
基本流
基本流描述的是该用例最正常的一种场景，在基本流中系统执行一系列活动步骤来响应参与者提出的服务请求。我们建议用以下格式来描述基本流：
1) 每一个步骤都需要用数字编号以清楚地标明步骤的先后顺序。
2) 用一句简短的标题来概括每一步骤的主要内容，这样阅读者可以通过浏览标题来快速地了解用例的主要步骤。在用例建模的早期，我们也只需要描述到事件流步骤标题这一层，以免过早地陷入到用例描述的细节中去。
