用例图
用例描述
学生： 用户登录 ID 1 用例名称：用户登录 参与者：学生 用例描述：大概过程：学生在系统上登录需要输入用户名、密码，系统确认身份。 输出结果：在系统的登陆界面区域确定身份后，登录界面转换登 录成功。 前置条件：系统已启动到登录界面，学生在进行其余操作之前必要完成的步骤。 后置条件：用户登录成功后系统显示信息查看的结果界面，用户登录成功后，进入到学生相应界面。 正常流程：1．学生在用户名输入框里输入用户名 2．在密码框里输入密码 3．用户按登录后，系统验证学生输入的有效性。 4．有效则进入系统的主界面。无效则提示相应错误给用户。 5．用例终止 异常事件流：显示错误信息，提示无效身份登录，认证无法通过登陆失败。 分支流程：在按“登录”按钮之前，学生可以随按“关闭”按钮。 特殊需求：要求用户密码安全。 签到 ID： 2 用例名称：签到 参与者：学生 用例描述：大概过程：学生在系统上选择签到按钮。 输出结果：在系统确定身份后，签到成功。
前置条件：在此用例开始之前，学生必须登录到系统中。 后置条件：如果用例执行成功，可以实现学生客户端的功能。 正常流程： 1.学生成功登陆客户端 2.点击签到按钮，此用例启动。 3.显示“签到成功”信息。 特殊需求：学生一次只允许签到一个用户。 发送文件 ID： 3 用例名称：发送文件 参与者：学生 用例描述：产生的原因：学生需要将所完成的功课提交老师批阅。 大概过程：学生完成作业后，按“提交按钮”发送给老师。 输出结果：系统提示文件送达成功或者失败。 前置条件：学生必须提供上传信息资源请求。 后置条件：学生可以快速提交作业，老师及时发现问题，可通过群聊方式纠正学生出现的问题。 正常流程： 1.学生提交上传文件信息请求 2.界面转换至上传文件界面 3.学生将所传文件内容进行上传 4.进行提交 5.系统提示成功与否信息 异常流程： 1.用户取消上传请求，系统回到界面。 2.文件上传失败，系统提示再次上传。 特殊需求：上传文件不宜过大。
案例描述 两位数加两位数口算的课堂作业.doc 在教学“两位数加两位数口算”时我创造性地使用教材，修改了书本上的习题，设计了如下的课堂作业： 第一部分 1.直接写出得数 37+21 23+25 30+20 37+33 43+27 30+80 37+31 43+25 300+200 37+36 46+27 300+800 2.把得数大于50的算式圈出来。 34+18 23+26 19+64 38+53 62+14 43+48 26+47 17+36 72+12 3.先估计得数是几十多，再口算。 73+15= 35+26= 19+64= （）十多（）十多（）十多 38+53= 26+47= 17+36= ( )十多（）十多（）十多 第一部分的习题为基本训练，即本节课的基本标准，全班每个学生必须完成，每人都要“保底”。如在完成的过程中有困难，有错误的学生，给予的课后作业为巩固练习，即第二部分的练习。 第二部分 1.先估计几十多，再口算。 35+32 45+14 37+55 26+29 35+38 49+14 21+78 44+17 2.比一比，算一算。 60+70 50+90 80+40 600+700 500+900 800+400 3.估计一下，填上“> ”“<”或“=”。 27+58（）58+27 54+18（）45+18 35+48（）48+53 23+18（）23+13 当学生能轻松完成第一部分的基本题，并且正确率100%的话，就不需要再做第二部分的巩固练习了，而是完成第三部分的提高题。 提高题 36+64 1000-547 175+225 16+28+72 409+191 38-13-17 这部分的题目要求全部口算，不列竖式能马上完成。 提高题是有一定难度的，对学生的计算能力，思维速度，都有较高要求，能完成这部分题目的学生，并能做到全对的话，将给予奖励，并且可以免做一道明天的基本题。练习到这儿还没结束，我还设计了更高难度的“挑战题”。 挑战题： 756-98 500-99-1-98-2-97-3-96-4 挑战题每天两个，不在多，而要精，有难度，能吸引一部分学有余力的学生。
用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。 当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。它将系统功能划分成对参与者（即系统的理想用户）有用的需求。而交互部分被称作用例。用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。 用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。 用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。有时，可以将用例的实例引入到图中。用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。
一．参与者（Actor） 1．参与者的概念 参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。参与着由参与用例时所担当的角色来表示。在UML中，参与者用名字写在 下面的人形图标表示。 每个参与者可以参与一个或多个用例。它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。 参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。 第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。 第二类参与者是其它的系统。这类位于程序边界之外的系统也是参与者。
XXX村村民交流互动网站系统 设计小组成员：何成龙、陆承林 黄元勇、王永亮 胡荣启 引言： 在计算机技术飞速发展的今天，各类交流网站挤满了互联网，本设计立足于XXX村村民交流互动而设计一个交流网站，网站为村民提供交流服务，村民可以在网上通过发帖聊天交流生活琐事以及农事科技等。 第一章：功能性需求分析 一、在本次设计中，“远程教育网站系统”包括以下功能模块： 1、个人工作台 2、在线浏览 3、资料共享 4、系统管理 5、在线帮助 二、功能描述 1、个人工作台 用户可通过个人工作台对个人信息进行注册和修改。 1.1、用户注册/登陆模块 用户通过注册模块进行注册成为会员，登陆模块为会员完成用户登陆； 1.2、修改信息 在本模块用户可对已填信息进行完善和修改。 2、在线浏览 在线浏览为会员和非会员提供阅读材料以及视频文件，可在线点播及阅读。 3、资料共享 此功能仅为会员提供，非会员无权享受此功能。会员通过此模块可下载所需内容以及上传文
件。 4、系统管理 4.1、后台管理 专为网站管理员开设。网站管理员通过此模块可对网站进行维护和管理。 4.2、网站数据库 主动收集网站各类数据并及时更新。 4.3、信息管理系统 仅为信息管理员提供，可以通过此模块对会员上传的文件进行审核和删除，以及对注册会员进行管理。 5、在线帮助 5.1、联系我们 用户通过此模块就网站存在的问题进行反馈。 6.功能描述文档： 功能编号功能名称功能描述备注 01 注册用户可以通过注册功能进行信息注册成为网站会员 02 登录会员/信息管理员用户通过此登录进行登录网站，登录时会员选择“会员登录”进行登录，信息管理员选择“管理员”进行登录。 03 浏览网页非会员和会员享有的权力，非会员只能浏览不能留言 以及下载上传文件。 04 个人中心一、会员个人中心包含以下内容模块： 1.个人主页 会员在个人主页里可以根据自己喜好设置主页属性； 2.个人信息修改 个人信息修改包括密码修改和基本信息修改； 3.好友 好友模块包含对好友的添加和删除功能，也可以对好友进行喊话；
百度文库 - 让每个人平等地提升自我 需求分析规范 用例描述文档编写规范（精要） 版本 <> 文档编号：001-0002-2
版本历史 日期版本描述作者2006-07-01 <> 初稿整理吕春秋
目录 1.前言5 1.1目的5 1.2范围5 1.3本文档说明5 2.基本要求6 3.用例事件流的描述6 3.1基本事件流的要求7 3.2子事件流的要求7 3.3备选事件流的要求8 3.4事件流中的序号标号9 3.5事件流中“确认”与“执行”操作描述的建议9 4.业务规则的描述9 4.1业务规则的种类9 4.1.1业务规则的抽取及编号10 4.1.2公共业务规则的抽取及编号10 4.2业务规则描述结构10 4.2.1要点说明式10 4.2.2顺序结构11 4.2.3分支结构11 4.2.4循环结构12 4.2.5混合结构13 4.2.6注意事项13 4.3业务规则描述中的缩进规则13 4.4业务规则描述中的标号13 5.子用例的定义与描述13 5.1子用例的设计方法13 5.2子用例中判断上级调用用例的方法13 6.用例描述中的其它规范14 6.1类、属性、参数、值的书写规则14 6.1.1类名的书写规则14 6.1.2属性名的书写规则14 6.1.3参数名的书写规则14 6.1.4各种值的书写规则14 6.2用例描述中的注释信息15 6.2.1注释要求15 6.2.2注释信息的描述15 6.3描述一致性15 7.接口15 8.新一代ERP系统中的几个公共机制15
8.1删除完整性检查15 8.2消息机制16 8.3编号管理16 9.用例描述中用词规范16 9.1范围值的描述16
1：总体用例 图 2：留言管 理 2-1:回复留言 用例描述: 用例名称：回复留 言用例标识号： 2-1
参与者：管理员简要说明：管理员对用户提交到系统的留言，进行浏览和回复。前置条件： 管理员已经登管理系统基本事件流：1．管理员鼠标点击“浏览留言”按钮，发出留言审核请求；2．系统提供系统中存储的留言，分页显示留言内容； 3. 管理员选择一条留言标题，点击浏览留言详细信息；4．管 理员可以在选择要回复的留言； 5. 管理员点击提交回复留言 6．用例终止；其他事件流A1：在按“提交”按钮之前，管理员随时可以按“返回”按钮，返回到浏览页面 异常事件流：1．提示错误信息，管理员确认；2．返回到留言管理页面。 后置条件：系统中的留言得到回复 注释：无 2-2:删除留言 用例描述: 用例名称：删除留言用例标识号：2-2 参与者：管理员简要说明：管理员对用户提交到系统的留言，进行浏览和删除前置条件： 管理员已经登管理系统基本事件流：1．管理员鼠标点击“浏览留言”按钮，发出浏览留言请求；2．系统提供系统中存储的经审核的留言，分页显示留言； 3. 管理员查看留言，点击删除按钮删除留言后重新列出留言； 7．用例终止；其他事件流A1： 在按“提交”按钮之前，管理员随时可以按“返回”按钮，返回到浏览
异常事件流：1．提示错误信息，管理员确认；2．返回到留言管理页面。 后置条件：系统中的留言被删除。 注释：无 3：管理帖子 3-1 回复帖子 用例描述: 用例名称：回复帖子用例标识号：3-1 参与者：管理员简要说明：管理员对用户提交到系统的帖子，进行浏览和回复帖子。前置条件：管理员已经登管理系统基本事件流：1．管理员鼠标点击“浏览帖子”按钮，发出帖子浏览请求；2．系统提供系统中存储的帖子，分页显示帖子内容； 3．管理员可以在选择要帖子的留言； 4. 管理员点击提交回复帖子5．用例终止；其他事件流A1： 在按“提交”按钮之前，管理员随时可以按“返回”按钮，返回到浏览异常事件流：1．提示错误信息，管理员确认；2．返回到帖子管理页面。 后置条件：系统中的帖子批准状态被修改。 注释：无
用例图的含义及画法 用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。 当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。它将系统功能划分成对参与者（即系统的理想用户）有用的需求。而交互部分被称作用例。用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。 用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。 用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。有时，可以将用例的实例引入到图中。用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。 一．参与者（Actor） 1．参与者的概念 参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。参与着由参与用例时所担当的角色来表示。在UML中，参与者用名字写在下面的人形图标表示。 每个参与者可以参与一个或多个用例。它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。
测试用例 目录 1．引言 (3) 1.1编写目的 (3) 1.2项目背景 (3) 1.3定义 (3) 1.4参考资料 (3) 1.5测试种类的分类 (4) 1.6测试阶段 (4) 1.7测试用例的分类 (4) 1.8测试种类、阶段和测试用例的关系 (4) 1.9用例编写方案 (5) 2测试用例 (5) 2.1 功能测试用例（代号F（Function ）） (5) 2.1.1 被测试对象（单元）的介绍 (5) 2.1.2测试范围与目的 (5) 2.1.3测试环境与测试辅助工具的描述 (5) 2.1.4测试驱动程序的设计 (5) 2.2 接口-路径测试用例(代号I（Interface）） (6) 2.2.1被测试对象（单元）的介绍 (6) 2.2.2测试范围与目的 (6) 2.2.3测试环境与测试辅助工具的描述 (6) 2.2.4 测试驱动程序的设计 (6) 2.2.5 路径测试的检查表（代号PI（Path Inspection ） (6) 2.3 性能测试用例(代号PE（Performance）） (7) 2.3.1 被测试对象（单元）的介绍 (7) 2.3.2 测试范围与目的 (7) 2.3.3 测试环境与测试辅助工具的描述 (7) 2.3.4 测试驱动程序的设计 (7) 2.4 图形用户界面测试用例（代号U（User Interface）） (8) 2.4.1 被测试对象的介绍 (8) 2.4.2 测试范围与目的 (8) 2.4.3 测试环境与测试辅助工具的描述 (8) 2.4.4测试驱动程序的设计 (8) 2.4.5测试人员分类 (8) 2.4.6用户界面测试的检查表 (8) 2.5 健壮性测试用例（代号RO（Robustness）） (9) 2.5.1 被测试对象的介绍 (9) 2.5.2测试范围与目的 (9) 2.5.3 测试环境与测试辅助工具的描述 (9) 2.5.4 测试驱动程序的设计 (9) 2.5.5 容错能力/恢复能力测试用例 (9)
用例图和用例模型 用例图用来描述用户的需求，它从用户的角度描述系统的功能，并指出各功能的执行者，强调谁在使用系统，系统为执行者完成哪些功能。 用例图概述 UML用例图是软件产品外部特性描述的视图，它从用户的角度而不是开发者的角度来描述软件产品的需求，分析软件产品所需的功能和行为。用例图主要描述了系统需要实现的功能，而忽略系统是如何实现这些功能的。 用例模型由用例图组成，它是系统用例图的集合，是对系统从宏观角度的确定描述。用例模型主要用于需求分析阶段，该模型是系统开发者和系统使用者反复讨论的结果，表明了系统开发者和系统使用者对需求规格达成的共识。 首先，用例模型描述了待开发系统的功能需求；其次，用例模型将系统看作黑盒，仅从外部执行者的角度来理解系统； 再次，用例模型驱动了需求分析之后各阶段的开发工作，影响到开发工作的各个阶段和UML的各个模型。 一、用例图元素 用例图主要用于定义系统的功能需求，它描述了系统的参与者与系统提供的用例之间的关系。用例图由以下几种元素组成： 执行者、用例、关系、用例描述 （1）执行者 执行者（Actor）是系统的外部用户，它是与系统相关联的人或其它系统，可以是普通用户、外部硬件、其他系统。
在进行用例图绘制时，首先要找出系统的执行者。一般可以从以下几个方面来考虑怎样找到系统的执行者： ?谁使用系统的功能。 ?谁向系统提供必要的信息。 ?谁从系统获取信息。 ?谁维护、管理系统工作。 ?系统需要使用哪些外部资源。 ?需要与系统交互的其它系统有哪些。 ?其他对系统产生的结果感兴趣的人或事物。 （2）用例 用例是指系统中的一个功能单元，也可以将用例理解为系统功能的分解。 用例的表示方法如下： （3）关系 （1）关联 在用例图中，用例和执行者之间的关系用一条连接二者带箭头的连线表示，如图所示，该连线称为关联。它表示了一个执行者和一个用例之间的关系。 在用例图中，关联关系只用在执行者和用例之间，用例和用例之间不会存在关联关系。关联关系采用的是单箭头的连线，表示在该关联中执行者是主动的，是执行者启动的用例。如下图所示。
长春一汽启明信息技术有限公司 ERP项目 需求分析规范用例描述文档编写规范（精要） 版本 <1.0> 文档编号：001-0002-2
版本历史
目录 1.前言5 1.1目的5 1.2范围5 1.3本文档说明5 2.基本要求6 3.用例事件流的描述6 3.1基本事件流的要求7 3.2子事件流的要求7 3.3备选事件流的要求8 3.4事件流中的序号标号9 3.5事件流中“确认”与“执行”操作的描述9 4.业务规则的描述9 4.1业务规则的种类10 4.1.1业务规则的抽取及编号10 4.1.2公共业务规则的抽取及编号10 4.2业务规则描述结构10 4.2.1要点说明式10 4.2.2顺序结构11 4.2.3分支结构11 4.2.4循环结构12 4.2.5混合结构13 4.2.6注意事项13 4.3业务规则描述中的缩进规则13 4.4业务规则描述中的标号13 5.子用例的定义与描述13 5.1上级调用用例的判断方法13 6.用例描述中的其它规范14 6.1类、属性、参数的书写规则14 6.1.1类名的书写规则14 6.1.2属性名的书写规则14 6.1.3参数名的书写规则14 6.1.4各种值的书写规则14 6.2用例描述中的注释信息15 6.2.1注释要求15 6.2.2注释信息的描述15 6.3参数传递错误！未定义书签。 7.新一代ERP系统中的几个公共机制15 7.1删除完整性检查16 7.2状态管理错误！未定义书签。
7.3变更管理错误！未定义书签。 7.4权限控制错误！未定义书签。 7.5消息机制16 7.6编号管理16 7.7地址管理错误！未定义书签。 7.8长文本错误！未定义书签。 8.用例描述中用词规范16
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这一步还远没有完成，接下来应该对要实现的功能进一步分析，那些用例其实是一种，用例之间有那些关系，如上面列出的一般化关系，扩展关系等等。当然这对actor也适用。单单用例图有时候太简单，不足以描述某个用例的详细情况，这是场景就必不可少了，用文字来描述这个用例的情况，正常流程，以及可能发生的异常情况，非常有用。当然也可以做进一步的分析，开始画每一个用例的序列图和协作图。 本文来自：https://www.doczj.com/doc/e73811888.html,/doc/15354.htm
用例图和用例描述设计实例 作者：ephyer 发表时间： 2004-09-09 18:01:35 更新时间： 2004-09-09 18:01:35 浏览：1954次 主题：电脑技 术 评论：0篇 地址：202.19 7.75.* :::栏目::: ? T hinkin g in jav a 学习 笔记 ? J A VA 基 础知识 ? U ML ? 软 件设计 师 ? 其 他类别 这里用我开发的一个家教网站来简单的分析用例图的画法和用例描述的 写法。这个网站我用UML 完整的分析一下，以下我提取了用例图和用例描述 的部分。这个家教网站分为前台客户系统和后台管理系统。 前台客户系统的用例图如下： 后台管理系统用例图如下： 对于用例描述，篇幅有限，我在这里只列了后台管理系统中的网站公告发布这个用例的描述。如下：
用例名称：用户登录 用例标识号：01 参与者：管理员、普通用户 简要说明： 参与者输入用户名、密码以及验证码，系统进行验证后，合法者登录系统，否则提供拒绝登录系统。 前置条件： 参与者已经打开系统的登录页面（login.jsp） 基本事件流： 1．参与者在用户名输入框里输入用户名 2．在密码框里输入密码 3．密码框下方显示验证码，验证码由4位数字构成，用户按原样输入验证码。 4．用户按登录后，系统验证参与者输入的有效性。 5．有效则进入系统的主界面。无效则提示相应错误给用户。 6．用例终止 其他事件流A1： 在按“登录”按钮之前，参与者可以随按“取消（或关闭）”按钮。 异常事件流： 1．提示错误信息，参与人确认 后置条件：进入的主界面main.jsp ,装载相应的数据 注释：（可选：记住用户）
我发现，在OO和UML几乎一统天下的今天，仍有很多系统分析员对OO和UML一知半解，甚至包括很多已经使用了很久UML的系统分析员。 于是打算写一个系列文章，将多年来的工作经验做一个总结。对初学者起个启蒙作用，也希望抛砖引喻，与各路大虾共同探讨，共同提高。 这个系列文章将以我对OO和系统分析的理解为主，从UML基础开始，阐述面向对象的需求分析方法，过程，并以RUP为例，阐述如何将OO过程与软件过程有机结合在一起，做一个真正OO应用。 好了，今天是第一篇。想得很远，不知能否坚持下去，呵呵:lol: 用例是什么？其原始英文是usecase，直译过来就成了用例。这也是一个比较贴切的叫法了，从字面的直接理解就是使用的例子。另一种比较流行的定义是用例就是与使用者(actor)交互的，并且给使用者提供可观测的有意义的结果的一系列活动的集合。 这个定义还是比较费解的，笔者在众多应聘者中发现很多使用用例来做需求的系统分析员，有的已经使用了两年以上，但仍不能把握用例的本质，虽然他们号称精通UML。 最具普遍意义的理解错误是认为用例就是功能的划分和描述，认为一个用例就是一个功能点。在这种理解下，用例变成了仅仅是较早前需求中功能框图的翻版，很多人用用例来划分子系统，功能模块和功能点。如果这样，用例根本没有存在的必要。有意思的是，造成这种理解错误的相当一部分原因却是因为对OO思想的理解不够深入，本质上说，把用例当成功能点的系统分析员脑子里还是面向过程的那一套思想，虽然他们在使用OO的工具，OO的语言，号称在做面向对象的开发，但过程的影子还没有从他们脑子里彻底抹去。 如果用例不是功能的话，它是什么呢？从定义上说，能给使用者提供一个执行结果的活动，不就是功能吗？我的回答是：错！功能是计算机术语，它是用来描述计算机的，而非定义需求的术语。功能实际描述的是输入-->计算-->输出。这让你想到了什么？DFD图？这可是典
3章：用例图习题
第3章用例图习题 一、简答题 1. 什么叫参与者，参与者有哪些基本特性？ 答：参与者也被称为活动者，是与系统发生交互的外部实体。参与者的特性有：1）参与者位于系统的外部，不属于系统的内容；2）参与者与系统发生交互关系，交互关系主要有：使用系统，启动系统，获取系统信息或给系统提供信息；3）参与者和系统之间存在交互信息的接口，系统提供接口让参与者使用系统，或者系统通过参与者的接口与参与者进行交互。 2. 用例有哪些特性？ 答：概括起来，用例有以下特性： 1）用例描述用户对系统的期望，被用于软件需求建模，一个用例对应于软件能够为参与者提供的一项服务。 2）用例反映参与者与系统一次完整的交互过程。这个交互过程总是要耗费一段时间，并 1
执行一定的流程。流程的执行是参与者与系统的一段互动过程，在这个过程中有输入到系统的信息，以及系统反馈给参与者的信息。 3）用例的执行过程是系统为参与者的一次服务过程，这个服务就体现为系统提供给参与者的功能。一个用例执行的完成，需要有确定的评价结果，这个结果表现为系统提供给参与者的一项完整的功能。 4）用例是软件设计和测试的依据。 3. 用例之间有哪几种关系？ 答：泛化关系，包含关系，扩展关系。 4. 用例叙述应该包括哪些基本内容？ 答：包括：用例编号，用例名，参与者，前置条件，事件流，后置条件。 二、填空题 1. 用例图的要素包括（参与者）、用例和（关系）。 2．参与者的英名名称是（actor），参与者 2
也被称为（活动者）。 3．参与者的类型可以是（人）、设备、（外部系统）和时间。 4．用例的英名名称是（usecase），也被称为（用案）和（用况）。 5．用例之间的关系有（泛化）、包含和（扩展）。 6．执行用例之前系统所处的状态被称为（前置条件），（事件流）被称为用例执行的流程。 三、选择题 1．下面不属于用例图作用的是（C） A：展现软件的功能 B：展现软件使用者和软件功能的关系 C：展现软件的特性 D：展现软件功能相互之间的关系 2．下面（B）不属于用例图的要素 A：参与者 B：包含 3
用例描述 学生管理系统的用例描述；用例编号：001；用例名：系统管理员的登录；用例描述：系统管理员完成学生信息管理系统登录的整；参与者：系统管理员老师学生；前置条件：系统运行正常；后置条件：如果管理员登录成功，可以对学生的基本信；基本路径：；1，系统管理员，学生，老师输入用户和密码；2，然后系统管理员，学生，老师提交输入的信息；3，系统对系统管理员，学生和老师的用户和 学生管理系统的用例描述 用例编号：001 用例名：系统管理员的登录 用例描述：系统管理员完成学生信息管理系统登录的整个过程。 参与者：系统管理员老师学生 前置条件：系统运行正常。 后置条件：如果管理员登录成功，可以对学生的基本信息进行进行管理。包括：录入，查询，修改，删除。如果教师登陆成功，可以对学生的成绩进行管理。如果学生登录成功，可以查看个人的基本信息。如果登录未成功，则不能进行如上操作。 基本路径：
1，系统管理员，学生，老师输入用户和密码。 2，然后系统管理员，学生，老师提交输入的信息。 3，系统对系统管理员，学生和老师的用户和密码信息进行有效的检查。 4，检查通过，则返回带用户登录界面。 扩展点： 3a:密码输入错误 3a1:系统弹出输入错误的警告信息。 3a2:系统管理员，学生和老师离开或重新输入密码。 变异点： 无 补充说明：无 用例编号：002 用例名：查询学生的基本信息 用例描述：完成系统管理员对学生的基本信息查询的完整过程。 参与者：系统管理员 前置条件：登录成功 后置条件：系统给出学生的基本信息。系统管理员可以查询操作。
基本路径： 1. 系统管理员，进入查询学生基本信息界面，发送查询学生基本信息的请求。 2.界面Form向控制对象Control请求学生的基本信息，控制对象到数据库查询学生的基本信息。 3.查询学生基本信息界面对象从控制对象中取得所查询得到的学生基本信息Course。并返回到查询界面上显示所有的学生基本信息。 4. 系统管理员查询学生的基本信息。 扩展点： 4a:查询学生基本信息失败。 4a1: 系统弹出查询学生信息失败的警告信息。 4a2: 系统管理员离开或重新查询学生的基本信息。 变异点： 无 补充说明： 无 用例编号：003 用例名：修改学生的基本信息
一．UML简介 UML（统一建模语言，Unified Modeling Language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。其实简单的理解，也是个人的理解，UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。 二．用例建模简介 用例建模是UML建模的一部分，它也是UML里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求或行为。依我的理解用例建模可分为用例图和用例描述。用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。用例描述用来详细描述用例图中每个用例，用文本文档来完成。 1．用例图 参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。 用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是UML对用例的正式定义，对我们初学者可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。 系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。
Quic用例文档 1. 参与者 .......................................................................................................................... - 1 - 1.1. 注册用户............................................................................................................ - 1 - 1.2. 游客.................................................................................................................... - 1 - 1.3. 管理员................................................................................................................ - 1 - 2. 用例说明........................................................................................................................ - 1 - 2.1. 注册用户............................................................................................................ - 1 - 2.2. 用户登录............................................................................................................ - 1 - 2.3. 修改个人信息.................................................................................................... - 2 - 2.4. 添加好友............................................................................................................ - 3 - 2.5. 编辑文档............................................................................................................ - 4 - 2.6. 发送邮件............................................................................................................ - 4 - 2.7. 发送消息............................................................................................................ - 4 - 2.8. 接收消息............................................................................................................ - 5 - 2.9. 查看消息记录.................................................................................................... - 5 - 2.10. 检索文档.......................................................................................................... - 6 - 2.11. 检索邮件.......................................................................................................... - 6 - 2.12. 用户管理.......................................................................................................... - 6 -
我发现，在00和UML几乎一统天下的今天，仍有很多系统分析员对00和UML —知半解，甚至包括很多已经使用了很久UML的系统分析员。 于是打算写一个系列文章，将多年来的工作经验做一个总结。对初学者起个启蒙作用，也希望抛砖引喻，与各路大虾共同探讨，共同提高。 这个系列文章将以我对00和系统分析的理解为主，从UML基础开始，阐述面向对象的需求分析方法，过程，并以RUP为例，阐述如何将00过程与软件过程有机结合在一起，做一个真正00应用。 好了，今天是第一篇。想得很远，不知能否坚持下去，呵呵：lol: 用例是什么？其原始英文是usecase直译过来就成了用例。这也是一个比较贴切的叫法了， 从字面的直接理解就是使用的例子。另一种比较流行的定义是用例就是与使用者(actor)交互的，并且给使用者提供可观测的有意义的结果的一系列活动的集合。 这个定义还是比较费解的，笔者在众多应聘者中发现很多使用用例来做需求的系统分析员, 有的已经使用了两年以上，但仍不能把握用例的本质，虽然他们号称精通UML。 最具普遍意义的理解错误是认为用例就是功能的划分和描述，认为一个用例就是一个功能 点。在这种理解下，用例变成了仅仅是较早前需求中功能框图的翻版，很多人用用例来划分 子系统，功能模块和功能点。如果这样，用例根本没有存在的必要。有意思的是，造成这种理解错误的相当一部分原因却是因为对00思想的理解不够深入，本质上说，把用例当成功 能点的系统分析员脑子里还是面向过程的那一套思想，虽然他们在使用00的工具，00的 语言，号称在做面向对象的开发，但过程的影子还没有从他们脑子里彻底抹去。 如果用例不是功能的话，它是什么呢？从定义上说，能给使用者提供一个执行结果的活动，不就是功能吗？我的回答是：错！功能是计算机术语，它是用来描述计算机的，而非定义需求的术语。功能实际描述的是输入--＞计算--＞输出。这让你想到了什么？DFD图？这可是典型的面向过程分析模式。因此我说把用例当做功能点的分析员实际在做面向过程的分析。
瑞天图书管理系统用例描述 一、图书借阅 该用例提供了用户借阅图书时管理员更新图书信息以及日志、记录借阅信息、创建和修改借阅者账户以及信息等 1、用例图如下： 记录图书数量与价格 (from ...) 2、用例描述： 用例名称: 图书借阅 简要说明：图书管理员输入读者编号和图书编号来完成图书借阅。 参与者：图书管理员 前置条件：读者出示的借阅证必须是有效的借阅证
后置条件：显示读者的全部借阅信息 假设条件：图书管理员已经成功登录图书管理系统 基本操作流程： (1) 图书管理员输入借阅证信息 (2) 系统检查读者是否有超期的借阅信息和读者的借书数量是否已经达到借书限额 (4) 图书管理员输入要借阅的图书信息 (5) 系统将读者的借阅信息保存到数据库中 可选操作流程：读者有超期的借阅信息，或者读者的借书数量已经达到借书限额，系统显示不能借阅图书的信息，图书管理员进行超期处理。 二、归还图书 1、用例图如下：
) (from ) 登录 2、用例描述： 用例名称：归还图书 简要说明：图书管理员收到要归还的图书，进行还书操作。参与者: 图书管理员、学生、其他用户 前置条件：无 后置条件：显示读者的全部借阅信息 假设条件：图书管理员已经成功登录图书管理系统 基本操作流程： (1) 图书管理员输入读者要归还的图书信息 (2) 系统检索与该图书相关的借阅者信息 (3) 系统检查该借阅者是否有超期的借阅信息 (4) 系统将借阅者的还书信息保存到数据库中
(5) 系统将该图书的状态改变为可借阅状态 可选操作流程：读者归还图书，图书管理员查看是否超出期限，并进行相应处罚，并且图书管理员将借阅信息删除。 三、图书查询 1、用例图如下： 输入书籍信息 2、用例描述： 用例名称: 图书查询 简要说明：用户登录网站进行查询 参与者：用户 前置条件：必须有登录账户 后置条件：显示要借图书的全部信息
超市运营管理系统系统用例文档 超市运营管理系统开发小组： 姓名学号 罗振强20 刘发胜48 徐壁38 黄伟浩39
2010月10日27
目录 1 超市运营系统顶层用例图 (4) 1.1系统角色用例图 (4) 1.2 超市运营系统顶层用例图 (4) 2 用例说明 (5) UC1 ：身份验证 (6) UC2 ：录入商品信息 (7) UC3 ：打印购物清单 (7) UC4 ：上架管理 (9) UC5：读取商品存入表 (10) UC6 ：接收订单 (11) UC7 ：商品入库管理 (12) UC8 ：读取商品存入表 (13) UC9 ：统计财务 (14) UC10 ：统计报表 (15)
1 超市运营系统顶层用例图 1.1系统角色用例图 超市服务的对象是顾客，外部有供应商，超市系统内部员工可以按人员的职能来分类。下图是超市进销存管理系统角色分析的用例图。其中，角色“员工”和“管理员”是抽象角色。 经理 供应商顾客 图1 1.2 超市运营系统顶层用例图
会计员 顾客 经理 图2 2 用例说明 超市运营系统登陆系统用例图
UC1 ：身份验证 范围：登陆系统 级别：用户目标 用例描述：超市员工要进入系统的时候，首先要通过身份验证，验证成功后才能进入系统。登陆成功后系统根据员工的职能权限判断验证员工的身份并进入相应的系统界面。 参与者：员工 前置条件：输入员工正确 后置条件：登陆相应的系统成功 涉众及其关注点： 员工：希望能够准确地输入员工号，成功登陆相应的系统。 基本路径： 1. 输入员工号 2. 系统验证员工信息 1.验证失败，返回1 2.进入相应的系统界面 扩展点：销售系统，采购系统，财务系统 补充说明：要确保输入员工号准确，才能成功登陆相应的系统 对应的用例图 图3