这里用我开发的一个家教网站来简单的分析用例图的画法和用例描述的写法。这个网站我用UML完整的分析一下，以下我提取了用例图和用例描述的部分。这个家教网站分为前台客户系统和后台管理系统。
前台客户系统的用例图如下：
后台管理系统用例图如下：
对于用例描述，篇幅有限，我在这里只列了后台管理系统中的网站公告发布这个用例的描述。如下：
学生： 用户登录 ID 1 用例名称：用户登录 参与者：学生 用例描述：大概过程：学生在系统上登录需要输入用户名、密码，系统确认身份。 输出结果：在系统的登陆界面区域确定身份后，登录界面转换登 录成功。 前置条件：系统已启动到登录界面，学生在进行其余操作之前必要完成的步骤。 后置条件：用户登录成功后系统显示信息查看的结果界面，用户登录成功后，进入到学生相应界面。 正常流程：1．学生在用户名输入框里输入用户名 2．在密码框里输入密码 3．用户按登录后，系统验证学生输入的有效性。 4．有效则进入系统的主界面。无效则提示相应错误给用户。 5．用例终止 异常事件流：显示错误信息，提示无效身份登录，认证无法通过登陆失败。 分支流程：在按“登录”按钮之前，学生可以随按“关闭”按钮。 特殊需求：要求用户密码安全。 签到 ID： 2 用例名称：签到 参与者：学生 用例描述：大概过程：学生在系统上选择签到按钮。 输出结果：在系统确定身份后，签到成功。
前置条件：在此用例开始之前，学生必须登录到系统中。 后置条件：如果用例执行成功，可以实现学生客户端的功能。 正常流程： 1.学生成功登陆客户端 2.点击签到按钮，此用例启动。 3.显示“签到成功”信息。 特殊需求：学生一次只允许签到一个用户。 发送文件 ID： 3 用例名称：发送文件 参与者：学生 用例描述：产生的原因：学生需要将所完成的功课提交老师批阅。 大概过程：学生完成作业后，按“提交按钮”发送给老师。 输出结果：系统提示文件送达成功或者失败。 前置条件：学生必须提供上传信息资源请求。 后置条件：学生可以快速提交作业，老师及时发现问题，可通过群聊方式纠正学生出现的问题。 正常流程： 1.学生提交上传文件信息请求 2.界面转换至上传文件界面 3.学生将所传文件内容进行上传 4.进行提交 5.系统提示成功与否信息 异常流程： 1.用户取消上传请求，系统回到界面。 2.文件上传失败，系统提示再次上传。 特殊需求：上传文件不宜过大。
用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。 当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。它将系统功能划分成对参与者（即系统的理想用户）有用的需求。而交互部分被称作用例。用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。 用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。 用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。有时，可以将用例的实例引入到图中。用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。
一．参与者（Actor） 1．参与者的概念 参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。参与着由参与用例时所担当的角色来表示。在UML中，参与者用名字写在 下面的人形图标表示。 每个参与者可以参与一个或多个用例。它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。 参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。 第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。 第二类参与者是其它的系统。这类位于程序边界之外的系统也是参与者。
一个关于人事管理的详细用例，希望大家多提意见，多多交流！ 人事系统用例 用例：设置部门（Set Department） 角色：人事管理员（Personnel Manager） 概述：设置部门用例用于建立维护组织结构，包括建立新部门、删除部门、编辑部门 项目相关人员及其兴趣： λ人事管理员：希望能够快捷准确录入、修改、查询 λ公司：希望系统能够形象、直观地显示公司部门组织结构，以利于管理和决策 前置条件：无 后置条件：系统对人事管理员对部门所作修改进行存储 成功场景： 1. 人事管理员发出“设置部门”请求 2. 系统在屏幕上显示组织结构 3. 人事管理员使用建立新部门、编辑部门、删除部门对组织结构进行修改 4. 重复步骤3、4直到建立起人事管理员预期的组织结构 可选场景： 1. 建立新部门 a. 人事管理员录入部门信息（上级部门、部门编号、部门名称、部门主管、备注） b. 人事管理员提交录入结果 c. 系统记录新部门信息 扩展场景： b.1人事管理员放弃提交，用例完成。 c.1 部门信息重复 c.1.1 系统提示错误，用例完成 2. 编辑部门 前提条件：部门数据存在 a. 人事管理员输入所需编辑的部门标识 b. 系统定位并显示部门信息 c. 人事管理员编辑部门信息 d. 人事管理员提交编辑结果 e. 系统更新部门信息 扩展场景： b.1 待编辑部门不存在 b.1.1 系统提示错误，用例取消 d.1人事管理员放弃提交，用例完成 e.1 部门信息重复 e.1.1 系统提示错误，用例完成 3. 删除部门 前提条件：部门数据存在 a. 人事管理员输入所需删除的部门标识 b. 系统定位到相应部门 c. 人事管理员删除部门 d. 系统删除该部门记录 扩展场景：
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中，参与者用名字写在下面的人形图标表示。 每个参与者可以参与一个或多个用例。它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。
用例图和用例模型 用例图用来描述用户的需求，它从用户的角度描述系统的功能，并指出各功能的执行者，强调谁在使用系统，系统为执行者完成哪些功能。 用例图概述 UML用例图是软件产品外部特性描述的视图，它从用户的角度而不是开发者的角度来描述软件产品的需求，分析软件产品所需的功能和行为。用例图主要描述了系统需要实现的功能，而忽略系统是如何实现这些功能的。 用例模型由用例图组成，它是系统用例图的集合，是对系统从宏观角度的确定描述。用例模型主要用于需求分析阶段，该模型是系统开发者和系统使用者反复讨论的结果，表明了系统开发者和系统使用者对需求规格达成的共识。 首先，用例模型描述了待开发系统的功能需求；其次，用例模型将系统看作黑盒，仅从外部执行者的角度来理解系统； 再次，用例模型驱动了需求分析之后各阶段的开发工作，影响到开发工作的各个阶段和UML的各个模型。 一、用例图元素 用例图主要用于定义系统的功能需求，它描述了系统的参与者与系统提供的用例之间的关系。用例图由以下几种元素组成： 执行者、用例、关系、用例描述 （1）执行者 执行者（Actor）是系统的外部用户，它是与系统相关联的人或其它系统，可以是普通用户、外部硬件、其他系统。
在进行用例图绘制时，首先要找出系统的执行者。一般可以从以下几个方面来考虑怎样找到系统的执行者： ?谁使用系统的功能。 ?谁向系统提供必要的信息。 ?谁从系统获取信息。 ?谁维护、管理系统工作。 ?系统需要使用哪些外部资源。 ?需要与系统交互的其它系统有哪些。 ?其他对系统产生的结果感兴趣的人或事物。 （2）用例 用例是指系统中的一个功能单元，也可以将用例理解为系统功能的分解。 用例的表示方法如下： （3）关系 （1）关联 在用例图中，用例和执行者之间的关系用一条连接二者带箭头的连线表示，如图所示，该连线称为关联。它表示了一个执行者和一个用例之间的关系。 在用例图中，关联关系只用在执行者和用例之间，用例和用例之间不会存在关联关系。关联关系采用的是单箭头的连线，表示在该关联中执行者是主动的，是执行者启动的用例。如下图所示。
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/6e18167931.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
一．UML简介 UML（统一建模语言，Unified Modeling Language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。其实简单的理解，也是个人的理解，UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。 二．用例建模简介 用例建模是UML建模的一部分，它也是UML里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求或行为。依我的理解用例建模可分为用例图和用例描述。用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。用例描述用来详细描述用例图中每个用例，用文本文档来完成。 1．用例图 参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。 用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是UML对用例的正式定义，对我们初学者可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。 系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。
北大青鸟网上商城系统 概要设计说明书 第一部分:引言 编写目的 本说明是北大青鸟网上商城电子商务系统案例研究项目软件产品的总体设计和实现说明，记录了系统整体实现上技术层面上的考虑，并且以需求说明作为依据，同时该文档将作为产品实现、特性要求和控制的依据。 软件开发小组的每一位参与开发成员应该阅读本说明，以清楚产品在技术方面的要求和实现策略，本手册将进行技术评审和技术的可行性检查，同时为下一步的详细设计说明提供框架。 背景 A、软件系统的名称：北大青鸟网上商城系统 B、任务提出者：北大青鸟九月J2EE班级第三小组 开发者：北大青鸟九月J2EE班级第三小组 实现完成的系统将作为线销售系统使用，所应用的网络为Internet网络。 C、本系统将是一个独立的系统，目前所产生的输出都是独立的。 本系统将使用Oracle9i作为数据库存储系统. 定义
参考资料 相关的文件包括： A、内部文件《北大青鸟网上商城电子商务系统案例研究项目》； B、北大青鸟网上商城电子商务系统案例研究项目分析会议备忘录； C、《北大青鸟网上商城电子商务系统案例研究项目可行性分析》；参考资料： A、北大青鸟Aptech Y2《基于软件开发项目的毕业设计》； B、国家标准《软件需求说明书（GB856T——88）》； C、亚马逊网站的软件需求说明； 合同： A、《北大青鸟网上商城电子商务系统案例研究项目合同- 2》；
第二部分:总体设计 需求规定 需求规定的详细内容，请参考独立的文档《北大青鸟网上商城项目需求说明》.运行环境 、硬件设备要求： 客户程序硬件要求： 具有Pentium III 处理器且满足以下要求的计算机： 最低64 MB 内存 最小GB 硬盘 鼠标 键盘 服务器硬件需求： 具有Pentium III 处理器且满足以下要求的计算机： 最低512MB 内存 最小8 GB 硬盘 鼠标 键盘 、支持程序 客户程序软件： Windows 98/NT /2000或更高版本 数据库服务器软件： Windows NT / 2000 Server 或更高版本 Oracle9i/SQL Server 2000/My Sql/Access
瑞天图书管理系统用例描述 一、图书借阅 该用例提供了用户借阅图书时管理员更新图书信息以及日志、记录借阅信息、创建和修改借阅者账户以及信息等 1、用例图如下： 记录图书数量与价格 (from ...) 2、用例描述： 用例名称: 图书借阅 简要说明：图书管理员输入读者编号和图书编号来完成图书借阅。 参与者：图书管理员 前置条件：读者出示的借阅证必须是有效的借阅证
后置条件：显示读者的全部借阅信息 假设条件：图书管理员已经成功登录图书管理系统 基本操作流程： (1) 图书管理员输入借阅证信息 (2) 系统检查读者是否有超期的借阅信息和读者的借书数量是否已经达到借书限额 (4) 图书管理员输入要借阅的图书信息 (5) 系统将读者的借阅信息保存到数据库中 可选操作流程：读者有超期的借阅信息，或者读者的借书数量已经达到借书限额，系统显示不能借阅图书的信息，图书管理员进行超期处理。 二、归还图书 1、用例图如下：
) (from ) 登录 2、用例描述： 用例名称：归还图书 简要说明：图书管理员收到要归还的图书，进行还书操作。参与者: 图书管理员、学生、其他用户 前置条件：无 后置条件：显示读者的全部借阅信息 假设条件：图书管理员已经成功登录图书管理系统 基本操作流程： (1) 图书管理员输入读者要归还的图书信息 (2) 系统检索与该图书相关的借阅者信息 (3) 系统检查该借阅者是否有超期的借阅信息 (4) 系统将借阅者的还书信息保存到数据库中
(5) 系统将该图书的状态改变为可借阅状态 可选操作流程：读者归还图书，图书管理员查看是否超出期限，并进行相应处罚，并且图书管理员将借阅信息删除。 三、图书查询 1、用例图如下： 输入书籍信息 2、用例描述： 用例名称: 图书查询 简要说明：用户登录网站进行查询 参与者：用户 前置条件：必须有登录账户 后置条件：显示要借图书的全部信息
用例建模指南 级别： 初级 傅纯一 , Rational 中国区技术销售经理 , IBM 中国有限公司软件部 2004 年 11 月 01 日 用 例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。用例方法最早是由Iva Jackboson 博士提出的，后来被综合到UML 规范之中，成为一种标准化的需求表述体系。用例的使用在RUP 中被推崇备至，整个RUP 流程都被称作 是"用例驱动"(Use-Case Driven)的，各种类型的开发活动包括项目管理、分析设计、测试、实现等都是以系统用例为主要输入工件，用例模型奠定了整个系统软件开发的基础。 1. 什么是用例？ 在介始用例方法之前，我们首先来看一下传统的需求表述方式-"软件需求规约"(Software Requirement Specification)。传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块 中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。一个典型的软件需求规约可能具有以下形式： 采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。由此常常导致这样的迷惑：系 统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计。在有些公司的开发流程中，这种需 求被称为"内部需求"，而对应于用户的原始要求则被称之为"外部需求"。 功能分解方法的另一个缺点是这种方法分割了各项系统功能的应用环境，从各项功能项入手，你很难了解到这些功能项是如何相互关联来实现一 个完成的系统服务的。所以在传统的SRS 文档中，我们往往需要另外一些章节来描述系统的整体结构及各部分之间的相互关联，这些内容使得SRS 需求更象是一 个设计文档。 1.1 参与者和用例
用例描述 对“身份验证”用例的完整描述 主参与者：参保人 目标：参保人登陆查询系统 范围：医疗保险管理系统 前置条件： 触发事件：参保人想进入查询系统进行操作 主成功场景： 1）参保人输入卡号，系统验证其有效性 2）参保人输入密码，系统验证其有效性和正确性 扩展： 1a：系统不存在该卡号 2a：输入密码有误，无法通过验证 发生频率：一天100次 对“信息统计处理”用例的完整描述 主参与者：参保人 目标：参保人察看统计信息 范围：医疗保险管理系统 前置条件：参保人已登陆查询系统 触发事件：参保人鼠标点击查询或键盘输入请求 主成功场景： 1）参保人鼠标点击查询或键盘输入请求 2）系统内部进行查询 3）系统显示查询结果给参保人 扩展： 1a：参保人输入请求有误 2a：系统内部忙 发生频率：一天100次 对“反馈信息”用例的完整描述 主参与者：医疗保险管理系统 目标：显示结果给参保人 范围：医疗保险管理系统 前置条件：参保人发出查询请求，并经过系统处理触发事件：系统处理结束 主成功场景： 1）参保人发出查询请求，并经过系统处理 2）可视化显示给参保人
扩展： 2a：系统发生错误 发生频率：一天100次 对“录入报销记录”用例的完整描述主参与者：工作人员 目标：向系统输入报销记录 范围：医疗保险管理系统 前置条件：参保人来到服务窗口 触发事件：参保人要求报销回退 主成功场景： 1）参保人来到服务窗口要求报销回退 2）参保人提供卡号及密码 3）工作人员验证报销记录并确认 4）工作人员录入报销记录 扩展： 2a：参保人忘记了自己的卡号密码 3a：报销凭证有误无法通过验证 4b：录入时系统发生错误 发生频率：一天100次 对“返回处理结果”用例的完整描述主参与者：工作人员，参保人 目标：显示结果给参保人 范围：医疗保险管理系统 前置条件：工作人员录入记录 触发事件：工作人员录入记录并保存 主成功场景： 1）工作人员录入记录并保存 2）系统显示处理成功界面 扩展： 1a：工作人员未能正常录入 1b：系统未能正常保存 2a：系统显示出错 发生频率：一天100次 对“输入处方”用例的完整描述 主参与者：工作人员 目标：向系统输入处方 范围：医疗保险管理系统 前置条件：参保人来到服务窗口请求报销
UML用例图 用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。 用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。 共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。 1、包含(include) 包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。 包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。 例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。
实验二用例图 【实验目的】 1．掌握用例的概念。 2．掌握UML中用例图的组成、作用以及使用场合。 3．掌握用例与用例之间的各种关系。 4．学习针对具体场景使用用例图进行分析说明的方法。 5．掌握用例描述的概念和基本结构，以及用例描述的作用。 【实验性质】 设计性实验。 【实验要求】 1．学习针对具体场景识别参与者和用例的方法，设计其用例图。 2．学习通过Rational Rose绘制用例图的方法。 3．掌握如何对每个用例进行用例描述。 【实验内容】 一．网上选课系统需求分析 1．某学校的网上选课系统主要包括如下功能：管理员通过系统管理界面进入，建立本学期要开的各种课程，将课程信息保存在数据库中并可以对课程进行改动和删除；学生通过客户机浏览器根据学号和密码进入选课界面，在这里学生可以进行三种操作：查询已选课程、选课以及付费。同样，通过业务层，这些操作结果存入数据库中。 2．对本系统的的用例、参与者进行分析： 本系统拟使用java语言通过三层模型实现：数据核心层、业务逻辑层和接入层。数据核心层包括对数据库的操作；业务逻辑层作为中间层对用户输入进出逻辑处理，在映射到相应的数据层操作；接入层包括用户界面、系统登录界面、管理界面、用户选课界面等。 本系统涉及的用户包括管理员和学生，是用例图中的活动者，他们的主要特征类似，都有学号和姓名等信息，可抽象出“基”活动者people，而register和student则从people 诞生，数据库管理系统是另外一个活动者。 3．写出系统中出现的一些事件流，如添加课程事件流、删除课程事件流、修改课程事件流，选课事件流等。下面是系统中出现的一些事件流。 添加课程事件流： a）管理员选择进入管理界面，用例开始。 b）系统提示输入管理员密码。 c）管理员输入密码。 d）系统验证密码。 A1：密码错误 e）进入管理界面，系统显示目前所建立的全部课程信息。 f）管理员选择添加课程。 g）系统提示输入新课程信息。 h）管理员输入信息。 i）系统验证是否和已有课程冲突。 A2：有冲突
一、面向对象分析 1. 建立用例模型 i. 开户 用例描述：开户用例图中，由管理员发起开户事务，储户提供账户信息、身份信息，管理员验证账户合法性和身份真实性后输入账户信息，储户设置密码，过程中涉及验证合法性（账户号正确、身份真实等）、添加账户信息等。储户可以打印凭证。 ii. 销户
用例描述：销户用例图中，主动销户由管理员发起销户事务，储户提供账户信息、身份信息，输入密码，管理员验证密码正确身份真实性后输入账户信息，并验证账户余额，若有余额则返还给储户完成销户，若无余额直接完成销户。过程中涉及验证合法性（密码正确、身份真实等）、处理余额、删除账户信息等。储户可以打印凭证。被动销户则需要进行销户判断（挂失子系统），若判断可以销户，则处理余额，完成销户。 iii. 冻结
用例描述：冻结用例图中，主动冻结由管理员发起冻结事务，储户提供账户信息、身份信息，管理员验证密码正确身份真实性后输入账户信息，完成冻结。过程中涉及验证正确性（密码正确、身份真实等）、修改账户状态信息等。储户可以打印凭证。被动冻结则需要进行冻结判断，若输入密码大于三次，账户冻结。 iv. 挂失
用例描述：挂失用例图中，管理员需要用户输入账户信息，可以触发挂失事务，其中挂失事务包括生成挂失信息，获取余额信息以及销户触发判断，判断是否挂失一定时间，自动触发销户。 v. 存款
用例描述：存款用例图中，管理员需要用户输入账户信息，或者打印存款信息才可以触发存款事务，其中存款事务包括修改余额信息以及生成存款信息两个功能。 vi. 取款
用例描述：取款用例图中，管理员需要用户输入账户信息，以及账户密码，经过余额验证才可以触发取款事务，其中取款事务包括修改余额信息以及生成取款信息打印凭证两个功能。 vii. 转账