用例图描述
用例图和用例描述设计实例
用例图和用例描述设计实例作者：ephyer 发表时间：2004-09-09 1 8:01:35更新时间：2004-09-09 1 8:01:35浏览：1954次主题：电脑技术评论：0篇地址：202.19 7.75.*:::栏目:::•Thinking in java 学习笔记•JA VA基础知识•UML•软件设计师•其他类别这里用我开发的一个家教网站来简单的分析用例图的画法和用例描述的写法。
这个网站我用UML完整的分析一下，以下我提取了用例图和用例描述的部分。
这个家教网站分为前台客户系统和后台管理系统。
前台客户系统的用例图如下：后台管理系统用例图如下：对于用例描述，篇幅有限，我在这里只列了后台管理系统中的网站公告发布这个用例的描述。
如下：用例名称：网站公告发布用例标识号：202参与者：负责人简要说明：负责人用来填写和修改家教网站首页的公告，公告最终显示在家教网站的首页上。
前置条件：负责人已经登陆家教网站管理系统基本事件流：1．负责人鼠标点击“修改公告”按钮2．系统出现一个文本框，显示着原来的公告内容3．负责人可以在文本框上修改公告，也可以完全删除，重新写新的公告4．负责人编辑完文本框，按“提交”按钮，首页公告就被修改5．用例终止其他事件流A1：在按“提交”按钮之前，负责人随时可以按“返回”按钮，文本框的任何修改内容都不会影响网站首页的公告异常事件流：1．提示错误信息，负责人确认2．返回到管理系统主页面后置条件：网站首页的公告信息被修改注释：无四．总结其实用例建模并不是这么简单，它涉及到的知识还有很多，我这里只是简单的介绍一下，希望对初学UML建模的同学有所帮助。
上一篇下一篇展开所有评论发表评论推荐转载写信问候返回目录快速返回我的百宝箱用例名称：用户登录用例标识号：01参与者：管理员、普通用户简要说明：参与者输入用户名、密码以及验证码，系统进行验证后，合法者登录系统，否则提供拒绝登录系统。
前置条件：参与者已经打开系统的登录页面（login.jsp）基本事件流：1．参与者在用户名输入框里输入用户名2．在密码框里输入密码3．密码框下方显示验证码，验证码由4位数字构成，用户按原样输入验证码。
利用用例图描述用户需求
（4）用例的命名
每个用例应有唯一的名称 命名的方式：用例通常用动词 + 名词短语来命名---如：登录系统
请见文档中的说明 书写用例的模板格式
四、UML中的用例图
1、用例图 （1）什么是用例图
提供用例图的目的之 一是下面的描述
用例图是一种图形化的工具，它用简单的图形元素表示出 系统的参与者、用例以及它们之间的联系
（2）用例图中的参与者和用例之间的通信
参与者和用例之间的使用关系，在用例图中表示为一个 带箭头的直线
二、UML中的用例之间的关系
1、用例之间的关系
主要体现在纵向方面的层次化关系和横向方面的关联性和 包含
（1）用例的层次化（纵向方面）
按照抽象层次，用例可以划分为系统层（最高层）、子系 统层（可以再细分）和对象类层（最低层）。 系统层用例图：描述系统提供的全部主要的功能或服务。 子系统层用例图：描述某一子系统所应该提供的服务，它 的外部交互者可以是其他的子系统或高一层的参与者。 对象类层的用例图描述对象类提供的功能片或操作，它的 外部交互者可以是其他对象类或高一层活动者。
（3）用例图的组成元素
在一个用例图中，一般主要 包含有 系统边界 参与者 用例和用例关系 （泛化、使用和扩展等 三种形式）。
这在前面已经 加以说明过
2、用例图的主要作用 （1）面向用户
可以实现从用户角度来描述系统所应该具有的功能，同时 并能够指出各功能的操作者； 也能够显示出与系统进行交互的外部参与者及其使用方式。 （2）面向开发者 表示正在构造的新系统应该具有的功能 同时对已经构造完毕的系统，则反映了系统能够完成什么 样的功能
UML用例图描述
用例名称
系统管理员登录
标识符001用Fra bibliotek描述系统管理员通过设置的用户名和密码登录到学生管理系统
参与者
系统管理员
优先级
1
状态
等待审查
前置条件
学生管理系统正常运行
后置条件
如果管理员登录成功，则可以对学生基本信息进行管理，包括录入，删除，修改，查询学生基本信息，并且可修改自己的密码；如果管理员登录不成功，则不能对学生基本信息进行操作。
2.系统管理员无用户名先进行注册，再输入正确的用户名和密码顺利登录，并对学生基本信息进行操作
3.系统管理员忘记用户名和密码，通过手机动态密码进行验证，找回密码，再输入正确的用户名和密码顺利登录，并对学生基本信息进行操作
被泛化的用例
无
被包含的用例
查学生基本信息
被扩展的用例
无
用例“查学生基本信息”的描述
基本操作流程
1.系统管理员进入学生管理系统
2.系统管理员输入用户名和密码
3.系统管理员提交输入信息
4.系统对系统管理员输入的用户名和密码进行有效性检查
5.系统管理员对学生基本信息进行操作
可选操作流程
1.系统管理员输入正确的用户名和验证码，错误的密码无法顺利登录，重新输入正确的用户名和密码顺利登录，并对学生基本信息进行操作
用例名称
查学生基本信息
标识符
002
用例描述
系统管理员输入要查看的学生的基本信息，系统显示该学生的详细信息
参与者
系统管理员
优先级
2
状态
等待审查
前置条件
学生管理系统正常运行
后置条件
系统管理员输入学生的基本信息，可查看学生的详细信息
用例图的简单描述
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这一步还远没有完成，接下来应该对要实现的功能进一步分析，那些用例其实是一种，用例之间有那些关系，如上面列出的一般化关系，扩展关系等等。
用例图
用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。
用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。
用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。
当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。
它将系统功能划分成对参与者（即系统的理想用户）有用的需求。
而交互部分被称作用例。
用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。
用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。
有时，可以将用例的实例引入到图中。
用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。
一．参与者（Actor）1．参与者的概念参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。
参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。
参与着由参与用例时所担当的角色来表示。
在UML中，参与者用名字写在下面的人形图标表示。
每个参与者可以参与一个或多个用例。
它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。
参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。
第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。
命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。
第二类参与者是其它的系统。
系统用例描述
瑞天图书管理系统用例描述-、图书借阅该用例提供了用户借阅图书时管理员更新图书信息以及日志、记 录借阅信息、创建和修改借阅者账户以及信息等 1、用例图如下：2、用例描述: 用例名称：图书借阅简要说明：图书管理员输入读者编号和图书编号来完成图书借阅。
参与者：图书管理员前置条件：读者出示的借阅证必须是有效的借阅证(from 图书管理系统参与创建新的借阅者帐户其他用户修改借阅者的帐户信息管理员已还书)(from 图书管理系统参与记录图书数量与价格学生(from 图书管理系统参与后置条件：显示读者的全部借阅信息假设条件：图书管理员已经成功登录图书管理系统基本操作流程：(1)图书管理员输入借阅证信息(2)系统检查读者是否有超期的借阅信息和读者的借书数量是否已经达到借书限额(4)图书管理员输入要借阅的图书信息(5)系统将读者的借阅信息保存到数据库中可选操作流程：读者有超期的借阅信息，或者读者的借书数量已经达到借书限额，系统显示不能借阅图书的信息，图书管理员进行超期处理。
二、归还图书1、用例图如下:2、用例描述: 用例名称：归还图书简要说明：图书管理员收到要归还的图书，进行还书操作。
参与者：图书管理员、学生、其他用户前置条件：无后置条件：显示读者的全部借阅信息假设条件：图书管理员已经成功登录图书管理系统 基本操作流程：(1) 图书管理员输入读者要归还的图书信息 (2) 系统检索与该图书相关的借阅者信息 (3) 系统检查该借阅者是否有超期的借阅信息 (4) 系统将借阅者的还书信息保存到数据库中(from))登录(5)系统将该图书的状态改变为可借阅状态可选操作流程：读者归还图书，图书管理员查看是否超出期限，并进行相应处罚，并且图书管理员将借阅信息删除。
三、图书查询1、用例图如下:输入书籍信息2、用例描述:用例名称：图书查询简要说明：用户登录网站进行查询参与者：用户前置条件：必须有登录账户后置条件：显示要借图书的全部信息假设条件：用户已经成功登录图书管理系统3、操作流程：(1)用户输入登录信息(2)系统检查读者是否有账号(3)用户输入要查询的图书信息(4)系统检查读者的借书信息是否存在可选操作流程：读者有超期的借阅信息，图书管理员进行超期处理; 读者的借书数量已经达到借书限额，系统显示不能借阅图书的信息。
用例图(User Case)
用例图（User Case）用例图是用来描述什么角色通过某某系统能做什么事情的图，用例图关系的是系统的外在表现，系统与人的交互，系统与其它系统的交互。
下面逐一说明用例图中各种符号的意义：小人：对使用某系统的用户进行分类后，可以总结出使用本系统有哪些角色，不同的角色的工作责任不太一样，他们需要用到的系统的功能也会不太一样。
小人就是角色，它给了我们一个启示，我们思考某系统的需求时，可从不同角色的角度来思考。
例如：我们要做一个考勤系统，你会怎样思考呢？会一下子列出很多功能？比较好的方式，应该是先思考什么人会用这个系统，我们大概可以估计一般员工、高层领导、前台、财务等都会用这个系统，对于一般员工来说除了打卡，他还关注什么？对于前台，她是不是要做一些考勤的统计？而财务是不是要根据考勤情况来调整员工的薪金？这样的思考方式，会让我们更容易全面发掘系统的需求。
还需要特别说明的是：角色可能是人，也可能不是人，而是另外的一个系统，本系统与另外一个系统交互的话，可以将另外一个系统画成某某角色。
圈圈：圈圈里面会有一段动宾结构的文字，也就是“动词+名词”这样的方式，这个圈圈+圈圈里面的文字，就是用例，这些用例表明了系统能做什么事情。
以考勤系统为例：有两个用例叫“打卡”、“查看自己的考勤情况”，这个两个圈圈分别用一条线连到了“一般员工”这个角色，我们可以按这样的顺序来读这个图：先读出角色的名字，然后读出用例中的文字。
按着这样的读法，我们可以得到两句完整的句子：“一般员工打卡”“一般员工查看自己的考勤情况”大家可以用这样的方式来检查自己用例图是否画得合适。
某用例不一定是只属于某个角色的，有不少用例是多个角色“共享”的。
大框框：在所有用例的外面，有一个方框，这个方框只框住了用例，没有框住角色，这个东西就叫做系统边界，框框的上部会注明本系统的名字。
我们所做的系统，是不可能包括角色的，系统要发挥各种作用，要靠各角色“穿越”系统边界来使用本系统的用例。
2.设计模式常用的UML图分析（用例图、类图与时序图）
2.设计模式常⽤的UML图分析（⽤例图、类图与时序图）1-⽤例图概述1. 展现了⼀组⽤例、参与者以及他们之间的关系。
2. ⽤例图从⽤户⾓度描述系统的静态使⽤情况，⽤于建⽴需求模型。
⽤例特征保证⽤例能够正确捕捉功能性需求，判断⽤例是否准确的依据。
1. ⽤例是动宾短语2. ⽤例是相互独⽴的3. ⽤例是由⽤户参与者启动的4. ⽤例要有可观测的执⾏结果5. ⼀个⽤例是⼀个单元参与者 ActorUML中，参与者使⽤⼀个⼩⼈表⽰:1. 参与者为系统外部与系统直接交互的⼈或事务，于系统外部与系统发⽣交互作⽤2. 参与者是⾓⾊⽽不是具体的⼈3. 代表参与者在与系统打交道时所扮演的⾓⾊4. 系统实际运作中，⼀个实际⽤户可能对应系统的多个参与者。
不同⾓⾊也可以只对应⼀个参与者，从⽽代表同⼀参与者的不通实例⽤例 Use Case系统外部可见的⼀个系统功能单元。
系统的功能由系统单元所提供，并通过⼀系列系统单元与⼀个或多个参与者之间交换的消息所表达。
系统单元⽤椭圆表⽰，椭圆中的⽂字简述系统功能:关系 Relationship常见关系类型有关联、泛化、包含和扩展关联 Association表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。
箭头指向：指向消息接收⽅：⼦系统 SubSystem⽤来展⽰系统的⼀部分功能(紧密联系)泛化 Inheritance继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。
⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。
⽗⽤例通常是抽象。
箭头指向：指向⽗⽤例2-类图描述系统中的类，以及各个类之间的关系的静态试图。
表⽰类、接⼝以及它们之间的协作关系，⽤于程序设计阶段。
注意:1. 抽象类或抽象⽅法⽤斜体表⽰2. 如果是接⼝，则在类名上⽅加 <<Interface>>3. 字段和⽅法返回值的数据类型⾮必需4. 静态类或静态⽅法加下划线类图实例:类图中的事务及解释如图，类图从上到下分为三部分,分别为类名、属性和操作1. 属性:如果有属性，则每⼀个属性都必须有⼀个名字，另外还可以有其它的描述信息，如可见性、数据类型、缺省值等2. 操作:如果有操作，则每⼀个操作也都有⼀个名字，其它可选的信息包括可见性、参数的名字、参数类型、参数缺省值和操作的返回值的类型等类图中的六种关系1.实现关系 implements (类实现接⼝)⽤空⼼三⾓虚线表⽰2.泛化关系 extends (表⽰⼀般与特殊的关系) is-a⽤空⼼三⾓实线表⽰3.组合关系 (整体与部分的关系) contains-a实⼼菱形实现表⽰eg.有头类、⾝体类与⼈类类三个类，则⼈类类中应包含头类及⾝体类这两个属性，则⼈类类与头类和⾝体的关系即为组合关系。
图书馆管理系统UML用例图
图书馆管理系统系统描述、用例图及用例描述
姓名：***
学号：**********
班级：2012级网工班
图书管理系统是应用于图书馆的人机互动系统。
该系统使图书馆变得信息化，它能有效协作图书馆的工作人员管理图书馆的各项信息，同时还能方便读者快速地查询、借阅和归还图书，极大地提高了图书馆的管理效率和服务质量。
二、用例图：
1
2
3
4
5
6
主要参与人系统管理员
次要参与人无
前置条件以系统管理员身份登录系统。
后置条件图书信息中增加一条信息。
基本操作流程 5.系统管理员登录系统。
6.系统管理员选择新增、修改或删除读者信息。
7.系统管理员对读者信息进行修改。
8.保存操作。
可选流程保存之前可自行取消操作。
四、领域类图
7
五、术语表
读者
持有图书证的在校学生。
图书馆工作人员
包括图书管理员和系统管理员，有账号作为身份标识。
图书管理员主要负责引导读者借阅和归还书籍，负责收取逾期罚金。
而系统管理员主要负责图书信息和读者信息的更新。
信息管理
由图书管理员进行，读者管理主要包括新增、修改和删除读者信息。
图书管理主要包括新增、修改和删除书籍信息。
数据存储
是整个图书管理系统的数据中心，在数据库中存储各项和书籍有关的活动，包括工作人员信息、读者信息、书籍信息、借书还书记录等。
六、借书活动图
8
9。
UML用例图介绍
UML用例图介绍目录1、UML用例图概述 (1)2、用例图怎么使用？ (1)3、UML用例图的目的 (2)4、如何画用例图？ (3)1、UML用例图概述用例图捕捉了模拟系统中的动态行为，并且描述了用户、需求以及系统功能单元之间的关系。
用例图展示了一个外部用户能够观察到的系统功能模型图。
用例图由主角，用例和它们之间的关系组成。
2、用例图怎么使用？要了解一个系统的动态，我们需要使用不同类型的图表。
用例图就是其中之一，其具体目的是收集系统的的需求和参与者。
用例图指定系统的事件和他们的流向。
但从未用例图描述了他们是如何实现的。
可以被想象成一个黑盒子，只有输入，输出和黑盒子的功能被称为用例图。
在这些图中使用的设计在一个非常高的水平。
那么这种高层次的设计高雅，一遍又一遍完善使系统得到一个完整实用的图片。
一个结构良好的用例，还介绍了前置条件，后置条件和例外。
而这些多余的元素在执行测试时被用来制造测试的情况下。
用例都不是正向和反向工程，但他们仍然使用略有不同的方式。
同样是真实的逆向工程。
仍用例图的使用方式不同，使其逆向工程的一个候选。
在正向工程用例图是用来做测试案例和逆向工程中的使用情况下是用来准备从现有的应用程序的需求细节。
所以下面的地方使用用例图：2.1.需求分析和高水平的设计。
2.2.模拟系统的上下文。
2.3.逆向工程。
2.4.Forward engineering.3、UML用例图的目的用例图的目的是捕捉到一个系统的动态方面。
用例图是用来收集系统的要求，包括内部和外部的影响。
这些要求大多是设计要求。
所以，分析一个系统时要收集其功能用例和确定参与者。
简单来说，用例图的目的如下：3.1.用例图用来收集系统的要求。
3.2.用例图用于获取系统的外观图。
3.3.用例图识别外部和内部因素影响系统。
3.4.用例图显示要求之间的相互作用是参与者。
4、如何画用例图？用例图被认为是高层次的需求分析系统。
因此，当系统的要求，分析被捕获在用例的功能。
uml用例描述
uml用例描述在软件开发过程中，用例是一种用来描述系统功能和用户需求的工具。
UML（Unified Modeling Language）是一种常用的建模语言，其中用例图是用来描述系统功能和行为的图形表示方法。
本文将使用UML用例图的描述方式，来介绍一个名为“在线购物系统”的软件系统。
1. 引言在线购物系统是一个电子商务平台，为用户提供了在线购买商品的功能。
本系统的主要参与者包括注册用户、游客和管理员。
注册用户可以浏览商品、添加商品到购物车、下单购买商品等；游客可以浏览商品，但无法添加商品到购物车或下单购买；管理员负责管理商品信息和用户信息。
2. 用例图下面是“在线购物系统”的用例图：- 注册用户用例：注册用户可以执行的操作包括浏览商品、搜索商品、添加商品到购物车、下单购买商品、查看订单状态和评价商品。
- 游客用例：游客可以执行的操作包括浏览商品、搜索商品和查看商品详情。
- 管理员用例：管理员可以执行的操作包括添加商品、编辑商品信息、删除商品、管理用户信息和查看订单信息。
3. 详细描述3.1 注册用户用例- 浏览商品：注册用户可以浏览系统中的商品列表，查看商品的基本信息和价格。
- 搜索商品：注册用户可以根据关键词搜索系统中的商品，系统会返回符合条件的商品列表。
- 添加商品到购物车：注册用户可以将感兴趣的商品添加到购物车中，以便稍后进行结算。
- 下单购买商品：注册用户可以选择购物车中的商品，生成订单并进行支付。
- 查看订单状态：注册用户可以查看自己的订单状态，包括待支付、待发货、已发货等。
- 评价商品：注册用户可以给已购买的商品进行评价，以供其他用户参考。
3.2 游客用例- 浏览商品：游客可以浏览系统中的商品列表，查看商品的基本信息和价格。
- 搜索商品：游客可以根据关键词搜索系统中的商品，系统会返回符合条件的商品列表。
- 查看商品详情：游客可以查看具体商品的详细信息，包括商品介绍、规格、用户评价等。
超市管理系统UML图
超市管理系统UML图超市管理系统的UML图包括以下几个主要部分：用例图、类图、时序图和活动图。
1. 用例图：用例图描述了超市管理系统的功能需求和用户角色之间的关系。
主要包括以下几个用例：- 登录：用户登录超市管理系统。
- 注册：新用户注册超市管理系统账号。
- 浏览商品：用户浏览超市的商品信息。
- 添加购物车：用户将商品添加到购物车。
- 结算：用户结算购物车中的商品。
- 管理商品：管理员管理商品信息，包括添加、删除、修改商品信息。
- 管理用户：管理员管理用户信息，包括添加、删除、修改用户信息。
2. 类图：类图描述了超市管理系统中的类和它们之间的关系。
主要包括以下几个类：- 用户：包括普通用户和管理员。
- 商品：包括商品名称、价格、库存等属性。
- 购物车：包括用户选择的商品信息。
- 订单：包括用户购买的商品信息和支付信息。
3. 时序图：时序图描述了超市管理系统中的交互过程和消息传递顺序。
主要包括以下几个时序图：- 用户登录：描述用户登录超市管理系统的过程。
- 浏览商品：描述用户浏览商品信息的过程。
- 添加购物车：描述用户将商品添加到购物车的过程。
- 结算：描述用户结算购物车中的商品的过程。
4. 活动图：活动图描述了超市管理系统中的业务流程和活动顺序。
主要包括以下几个活动图：- 用户注册：描述用户注册超市管理系统账号的流程。
- 管理商品：描述管理员管理商品信息的流程。
- 管理用户：描述管理员管理用户信息的流程。
以上是超市管理系统的UML图的主要内容，具体的细节和图形展示可以根据实际需求进行设计和补充。
用例及用例描述
用例图用例描述用例：留言ID：1简单描述：用户在本网站留言板上进行留言（咨询）主参与者：user副参与者：数据库前置条件：本网站被打开且用户有留言需要主流：i)用户打开本网站ii)进入留言板页面iii)在留言板对话框内发布信息iv)点击确定，完成留言后置条件：用户留言成功附加流：数据库添加失败时提醒错误原因并询问是否重新留言用例：搜索ID：2简单描述：在本网站进行所需信息的搜索主参与者：user副参与者：数据库前置条件：本网站被打开且用户有搜索信息的需要主流：i)用户打开本网站ii)在网站搜索引擎中键入搜索条件或直接按类别搜索iii)点击确定，完成搜索iv)得到预期信息，用户可以对所得信息进行浏览后置条件：搜索完成并且用户得到预期信息附加流：搜索数据库无结果，提示原因并询问是否重新搜索用例：回复ID：3简单描述：客服对用户的留言板提问或留言进行回复主参与者：客服副参与者：数据库前置条件：有用户在留言板上提问或留言主流：i)客服登录网站后台ii)进入留言板回复页面iii)点击回复，在出现的对话框内键入回复内容iv)点击确定，完成回复后置条件：客服回复信息成功附加流：数据库添加失败时提醒错误原因并询问是否重新回复ID：4简单描述：普通管理员将最新资讯信息添加到网站数据库中主参与者：普通管理员副参与者：数据库前置条件：网站有最新的咨询信息需要添加主流：i)普通管理员登录网站后台页面ii)将最新资讯信息录入到数据库中iii)点击确定完成录入后保存所作修改iv)修改成功后关闭后台页面后置条件：最新资讯信息成功添加到数据库中附加流：添加信息出错时数据库提示出错信息用例：删除网站信息ID：5简单描述：普通管理员将废旧资讯信息从网站数据库中删除主参与者：普通管理员副参与者：数据库前置条件：网站有废旧的咨询信息需要删除主流：i)普通管理员登录网站后台页面ii)查询废旧的资讯信息iii)将废旧资讯信息从数据库中删除iv)点击确定完成删除后保存所作修改v)删除成功后关闭后台页面后置条件：废旧资讯信息成功从数据库中删除附加流：删除信息出错时数据库提示出错信息ID：6简单描述：普通管理员对网站数据库中数据进行修改主参与者：普通管理员副参与者：数据库前置条件：网站有待修改的数据信息需要修改主流：i)普通管理员登录网站后台页面ii)查询待修改的资讯信息iii)对待修改资讯信息进行修改iv)点击确定完成修改后保存所作修改v)修改成功后关闭后台页面后置条件：待修改资讯信息在数据库中修改成功附加流：修改信息出错时数据库提示出错信息用例：查询网站信息ID：7简单描述：对数据库中的网站信息通过不同条件进行搜索查询主参与者：普通管理员副参与者：数据库前置条件：已确定要查询信息的关键字主流：i)普通管理员登录网站后台页面ii)根据搜索关键字对信息进行搜索iii)搜索成功，显示查询到的语句后置条件：信息查询成功，得到所查信息详情附加流：搜索失败，未能得到要查询信息并提示出错信息用例：删除留言ID：8简单描述：对数据库中的留言进行删除管理主参与者：普通管理员副参与者：数据库前置条件：存在不合法留言信息，普通管理员需要对其进行删除操作主流：i)普通管理员登录网站后台页面ii)在数据库中查询到不合法的留言信息iii)对不合法留言信息进行删除操作iv)点击确定完成操作后进行保存v)保存后关闭后台页面后置条件：不合法留言信息得以成功删除附加流：删除留言信息失败并提示出错信息用例：查询留言ID：9简单描述：对数据库中的留言信息进行查询检索主参与者：普通管理员副参与者：数据库前置条件：确定要检索留言信息的关键字主流：i)普通管理员登录网站后台页面ii)根据不同的检索条件对留言信息进行查询iii)成功检索到所要查询留言信息并显示信息详情后置条件：所要查询留言信息得以成功检索附加流：未能查询到所要查询的留言信息并提示出错信息用例：登录ID：10简单描述：网站的超级管理员、普通管理员和客服登录进本网站后台主参与者：超级管理员、普通管理员，客服副参与者：无前置条件：各种管理员需要进入后台进行各种信息维护主流：i)进入网站后台管理页面ii)键入预先分配好的帐号和密码iii)点击登录，进入后台iv)登录成功后置条件：各种管理员登录后台成功附加流：登录出错时提示出错信息用例：创建管理员用户ID：11简单描述：超级管理员创建一个新的管理员用户（普通管理员、客服）主参与者：超级管理员副参与者：数据库前置条件：网站需要新建一个管理员用户主流：i)超级管理员登录网站后台页面ii)创建一个新的管理员用户（帐号，密码）iii)点击确定完成新管理员用户的创建，数据库进行保存iv)创建成功后关闭后台页面后置条件：网站得到一个新的普通管理员用户或客服用户附加流：创建失败时数据库提示出错信息用例：删除管理员用户ID：12简单描述：超级管理员删除一个管理员用户（普通管理员、客服）主参与者：超级管理员副参与者：数据库前置条件：网站需要删除一个管理员用户主流：i)超级管理员登录网站后台页面ii)删除一个管理员用户（帐号，密码）iii)点击确定完成管理员用户的删除，数据库进行保存iv)删除成功后关闭后台页面后置条件：删除一个普通管理员用户或客服用户成功附加流：删除失败时数据库提示出错信息用例：设置管理员权限ID：13简单描述：超级管理员对网站中的管理员设置权限主参与者：超级管理员副参与者：数据库，普通管理员，客服前置条件：需要对网站内的普通管理员和客服进行区分，对他们分别设置不同的权限主流：i)超级管理员登录网站后台页面ii)对普通管理员设置权限，令其能对网站信息进行增、删、改、查以及对游客留言信息（不合法）进行查询和删除对客服设置权限，令其只能对游客的留言或提问信息进行回复iii)点击确定完成权限设置，数据库进行保存iv)设置成功后关闭后台页面后置条件：普通管理员或客服的权限设置成功附加流：权限设置失败时数据库提示出错信息用例：查看管理员用户信息ID：14简单描述：超级管理员对普通管理员用户或客服用户的信息进行查看主参与者：超级管理员副参与者：数据库前置条件：需要查看管理员用户信息主流：i)超级管理员登录网站后台页面ii)对指定普通管理员用户或客服用户的信息进行查询iii)显示指定管理员用户信息后置条件：管理员信息查询成功，得到所查信息详情附加流：查询信息失败时数据库提示出错信息。
UML建模——用例图（UseCaseDiagram）
UML建模——⽤例图（UseCaseDiagram）⽤例图主要⽤来描述⾓⾊以及⾓⾊与⽤例之间的连接关系。
说明的是谁要使⽤系统，以及他们使⽤该系统可以做些什么。
⼀个⽤例图包含了多个模型元素，如系统、参与者和⽤例，并且显⽰这些元素之间的各种关系，如泛化、关联和依赖。
它展⽰了⼀个外部⽤户能够观察到的系统功能模型图。
【⽤途】：帮助开发团队以⼀种可视化的⽅式理解系统的功能需求。
⼀、⽤例图所包含的的元素1. 参与者(Actor)——与应⽤程序或系统进⾏交互的⽤户、组织或外部系统。
⽤⼀个⼩⼈表⽰。
2. ⽤例(Use Case)——⽤例就是外部可见的系统功能，对系统提供的服务进⾏描述。
⽤椭圆表⽰。
3. ⼦系统(Subsystem)——⽤来展⽰系统的⼀部分功能，这部分功能联系紧密。
⼆、⽤例图所包含的的关系 ⽤例图中涉及的关系有：关联、泛化、包含、扩展。
如下表所⽰： a. 关联(Association) 表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。
【箭头指向】：⽆箭头，将参与者与⽤例相连接，指向消息接收⽅ b. 泛化(Inheritance) 就是通常理解的继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。
⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。
⽗⽤例通常是抽象的。
在实际应⽤中很少使⽤泛化关系，⼦⽤例中的特殊⾏为都可以作为⽗⽤例中的备选流存在。
【箭头指向】：指向⽗⽤例 c. 包含(Include) 包含关系⽤来把⼀个较复杂⽤例所表⽰的功能分解成较⼩的步骤。
包含关系对典型的应⽤就是复⽤，也就是定义中说的情景。
但是有时当某⽤例的事件流过于复杂时，为了简化⽤例的描述，我们也可以把某⼀段事件流抽象成为⼀个被包含的⽤例；相反，⽤例划分太细时，也可以抽象出⼀个基⽤例，来包含这些细颗粒的⽤例。
这种情况类似于在过程设计语⾔中，将程序的某⼀段算法封装成⼀个⼦过程，然后再从主程序中调⽤这⼀⼦过程。
《软件工程》第3章用例图及其应用
用例图在软件开发中重要性
1
用例图是软件开发过程中的重要工具之一，它能 够帮助开发团队更好地理解用户需求，明确系统 的功能范围。
2
通过用例图，开发团队可以对系统的交互方式进 行模拟和验证，从而发现潜在的问题和缺陷，提 高软件的质量。
用例图的更新可以及时地反映到自 动化测试脚本中，保证测试脚本的 实时性和准确性。
评估测试覆盖率
用例图可以帮助测试人员评 估测试的覆盖率，确保所有 重要的功能和业务流程都被
测试到。
通过对比用例图和已执行的 测试用例，可以找出未被测 试到的功能和业务流程，从
而完善测试计划。
测试覆盖率的评估有助于提 高测试的质量和效率，降低 漏测的风险。
02
针对每个测试场景，细化出具体的测试用例，包括输
入数据、预期结果和测试步骤。
03
用例图可以帮助测试人员更好地理解系统需求，从而
设计出更全面的测试用例。
指导自动化测试脚本编写
用例图提供了系统的功能框架和业务流 程，为自动化测试脚本的编写提供了指 导。
测试人员可以根据用例图中的元素和关系， 编写出对应的自动化测试脚本。
验证设计满足原始需求
01 用例图是需求分析和设计阶段源自重要产物，它描 述了用户期望的系统功能和行为。
02 在系统设计完成后，可以通过与原始用例图进行 对比，验证设计是否满足原始需求。
03 如果设计不符合原始需求，则需要重新调整设计， 直到满足所有需求为止。
评估系统可扩展性和可维护性
用例图可以帮助评估系统的可扩展性和可维护性。
扩展关系
02
03
图描述之：用例图总结
图描述之：⽤例图总结
⼀、什么是⽤例图
第⼀次见到⽤例图印象最深的就是那个⽤户⼩⼈，因为在之前，从来没有见过哪个图描述中会出现这样的图元。
能够得到的⽐较官⽅的描述是：由参与者，⽤例，以及他们之间的关系构成的⽤于描述系统功能的视图。
⽽那个⼩⼈正是作为参与者的⾝份出现在⽤例图当中。
⼆、能描述什么
从构成⽤例图的图元种类来看，这⾥有四种图元，分别是：参与者，⽤例，系统边界，箭头
参与者：不仅局限于⼈，也可以是实物，只要是存在于系统之外但⼜使⽤到了系统的功能的事物均可。
⽤例：⽤例⼆字我觉得在这⾥描述的并不是⼀个实际的物体，⽽是⼀些实际的动作的集合，来作为各个⽤例
系统边界：⽤来划分系统的内部和外部，但是多被省略，画图中也很少体现出来
箭头：⽤来表现⼀系列调⽤关系
三、我画过的⽤例图
在这张图中，⽤例之间的关系包括了《include》，《extend》即包含和扩展。
由于系统⽐较简单，所以在⽤例图中没有泛化的关系。
用例图描述
1． 学生在用户名输入框里输入用户名 2． 在密码框里输入密码 3． 用户按登录后，系统验证学生输入的有效性。 4． 有效则进入系统的主界面。无效则提示相应错误给用户。 5． 用例终止
异常事件流：
显示错误信息，提示无效身份登录，认证无法通过登陆失败。
分支流程：
在按“登录”按钮之前 ，学生可以随按“关闭”按钮。
前置条件：
1.学生进入到聊天界面。
2.用户必须联网方能使用。
后置条件：
1.聊天信息必须显示，所有成员都能看到。
2.聊天记录可清空。
正常流程：
1.打开群聊天窗口界面。
2.输入信息，点击发送。
3.群中所有成员发送信息都显示在群聊天窗口上。
分支流程：
1.若想进行私聊，一对一聊天
1.点击你想要聊天的好友，打开聊天窗口。
3.显示“签到成功”信息。
特殊需求：
学生一次只允许签到一个用户。
发送文件
ID：
3
用例名称：
发送文件
参与者：
学生
用例描述：
产生的原因：学生需要将所完成的功课提交老师批阅。
大概过程：学生完成作业后，按“提交按钮”发送给老师。
输出结果：系统提示文件送达成功或者失败。
前置条件：
学生必须提供上传信息资源请求。
输出结果：在系统的登陆界面区域确定身份后，登录界面转换登录成功。
前置条件：
系统已启动到登录界面，教师在进行其余操作之前必要完成的步骤。
后置条件：
用户登录成功后系统显示信息查看的结果界面，用户登录成功后，进入到教师相应界面。
正常流程：
1． 教师在用户名输入框里输入用户名 2． 在密码框里输入密码 3． 用户按登录后，系统验证学生输入的有效性。 4． 有效则进入系统的主界面。无效则提示相应错误给用户。 5． 用例终止
图书管理员用例图
4．系统显示读者的已借阅书籍供读者浏览。
5．读者确认该图书已还。
2.备选流
2 a如果读者已有图书超期，给出提示，进行罚款，继续3；
b如果图书有损坏，进行赔偿，继续3,；
特殊需求
无
前置条件
执行“登陆”用例，执行“查看读者信息”用例
后置条件
在超期情况下涉及执行“财务系统”用例
b如果图书管理只是查看个人信息，之后可直接退出；
特殊需求
无
前置条件
执行“登陆”用例
后置条件
无
扩展点管Biblioteka 个人信息主要包括：修改登录密码和查看个人信息；
相关数据
图书管理员信息
问题说明
对于修改个人信息和删除个人信息并不是图书管理员的权限，所以没有列出。
4.查询图书信息用例描述
简要说明
本用例描述图书管理员查询图书信息。
b如果读者已超过最大借阅，给出提示，结束
特殊需求
无
前置条件
执行“登陆”用例，执行“检查执行权限”用例，执行“查看读者信息”用例
后置条件
无
扩展点
无
相关数据
读者信息，图书信息
问题说明
无
2.处理还书用例描述
简要说明
本用例描述图书管理员处理还书。
事件流
1.基本流
1．读者将要还的书交给图书管理员；
2．图书管理员扫描读者信息，判断是否超期或者是否图书有损坏。
扩展点
无
相关数据
读者信息，图书信息
问题说明
无
3.管理个人信息用例描述
简要说明
本用例描述图书管理员管理个人信息。
事件流
1.基本流
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
学生：用户登录ID 1用例名称：用户登录参与者：学生用例描述：大概过程：学生在系统上登录需要输入用户名、密码，系统确认身份。
输出结果：在系统的登陆界面区域确定身份后，登录界面转换登录成功。
前置条件：系统已启动到登录界面，学生在进行其余操作之前必要完成的步骤。
后置条件：用户登录成功后系统显示信息查看的结果界面，用户登录成功后，进入到学生相应界面。
正常流程：1．学生在用户名输入框里输入用户名2．在密码框里输入密码3．用户按登录后，系统验证学生输入的有效性。
4．有效则进入系统的主界面。
无效则提示相应错误给用户。
5．用例终止异常事件流：显示错误信息，提示无效身份登录，认证无法通过登陆失败。
分支流程：在按“登录”按钮之前，学生可以随按“关闭”按钮。
特殊需求：要求用户密码安全。
签到ID： 2用例名称：签到参与者：学生用例描述：大概过程：学生在系统上选择签到按钮。
输出结果：在系统确定身份后，签到成功。
前置条件：在此用例开始之前，学生必须登录到系统中。
后置条件：如果用例执行成功，可以实现学生客户端的功能。
正常流程： 1.学生成功登陆客户端2.点击签到按钮，此用例启动。
3.显示“签到成功”信息。
特殊需求：学生一次只允许签到一个用户。
发送文件ID： 3用例名称：发送文件参与者：学生用例描述：产生的原因：学生需要将所完成的功课提交老师批阅。
大概过程：学生完成作业后，按“提交按钮”发送给老师。
输出结果：系统提示文件送达成功或者失败。
前置条件：学生必须提供上传信息资源请求。
后置条件：学生可以快速提交作业，老师及时发现问题，可通过群聊方式纠正学生出现的问题。
正常流程： 1.学生提交上传文件信息请求2.界面转换至上传文件界面3.学生将所传文件内容进行上传4.进行提交5.系统提示成功与否信息异常流程： 1.用户取消上传请求，系统回到界面。
2.文件上传失败，系统提示再次上传。
特殊需求：上传文件不宜过大。
接受文件ID： 3用例名称：接受文件参与者：学生用例描述：产生的原因：学生需要将作业要求发送给教师。
大概过程：学生收到新邮件提示信息，打开文件进行下载。
输出结果：系统提示文件下载成功或者失败。
前置条件：学生必须提交下载信息资源请求。
后置条件：学生需要接受作业要求。
正常流程：1学生收到新邮件信息2.学生点击新邮件3界面转换至下载文件界面4系统提示下载成功与否信息异常流程： 1.用户取消下载请求，系统回到界面。
2.文件下载失败，系统提示再次下载。
特殊需求：下载文件不宜过大。
申请求助ID： 4名称：申请求助参与者：学生描述：学生点击求助图标进行求助。
前置条件：学生在实验过程中出现问题。
后置条件：老师帮忙解决学生所出现的问题。
正常流程： 1.学生出现问题，点击“求助电话”按钮2.界面显示“乖乖，求助已送达”提示3.相应教师端出现机号求助信息4.异常流程：“求助电话”连接错误，界面等待特殊需求：教师端忙碌中时，不重复发送求助请求。
群聊ID： 5名称：群聊参与者：学生、老师描述：产生的原因：学生需要了解课程的一些信息大概过程：打开聊天界面，便弹出聊天窗口。
输入信息，点击发送，信息便发送成功，并且显示在聊天窗口上。
前置条件： 1.学生进入到聊天界面。
2.用户必须联网方能使用。
后置条件： 1.聊天信息必须显示，所有成员都能看到。
2.聊天记录可清空。
正常流程： 1.打开群聊天窗口界面。
2.输入信息，点击发送。
3.群中所有成员发送信息都显示在群聊天窗口上。
分支流程： 1.若想进行私聊，一对一聊天1.点击你想要聊天的好友，打开聊天窗口。
2.发送信息时，就点击到当前窗口。
异常流程： 1.学生取消发送的信息。
2学生发送离线信息。
3.信息发送时由于网络异常自己或对方掉线，对方未接收到。
4.学生停止发送信息。
5.学生重新发送信息。
教师：用户登录ID 1用例名称：用户登录参与者：教师用例描述：大概过程：教师在系统上登录需要输入用户名、密码，系统确认身份。
输出结果：在系统的登陆界面区域确定身份后，登录界面转换登录成功。
前置条件：系统已启动到登录界面，教师在进行其余操作之前必要完成的步骤。
后置条件：用户登录成功后系统显示信息查看的结果界面，用户登录成功后，进入到教师相应界面。
正常流程：1．教师在用户名输入框里输入用户名2．在密码框里输入密码3．用户按登录后，系统验证学生输入的有效性。
4．有效则进入系统的主界面。
无效则提示相应错误给用户。
5．用例终止异常事件流：显示错误信息，提示无效身份登录，认证无法通过登陆失败。
分支流程：在按“登录”按钮之前，教师可以随按“关闭”按钮。
特殊需求：要求用户密码安全。
监控学生端屏幕ID： 2名称：监控学生端屏幕参与者：教师描述：产生的原因：教师想了解学生的作业完成情况，及监管学生不做课外活动，如看电影，玩游戏。
大概过程：教师点击“学生电脑”，学生电脑出现在屏幕，教师可查看所有学生电脑屏幕界面。
前置条件：教师电脑已连接学生电脑，可实现远程访问后置条件：教师通过远程监控发现问题正常流程： 1.教师点击“学生电脑”图标2.所有学生的电脑屏幕显示在桌面3.点击某一具体机号，可放大观看具体内容异常流程： 1.教师端与学生端连接错误2.网络异常屏幕黑屏特殊需求：学生屏幕清晰，尺寸合理。
远程桌面控制ID： 3名称：远程桌面控制参与者：学生描述：产生的原因：需要向学生集体传授课程。
大概过程：学生点击“远程访问”，对学生电脑进行远程控制。
前置条件：教师电脑已连接学生电脑，可实现远程访问后置条件：教师可讲操作演示过程共同向学生集体演示，并且操作具体电脑。
正常流程： 1.点击“演示”图标2.教师可以远程控制所有学生电脑远程控制，将自己的具体操作过程演示给大家，实现屏幕的共享，实现一对多的授课。
3.点击“远程访问”图标4.教师可以对某学生出现的错误，进行远程修正及讲解，可以远程控制学生电脑界面。
异常流程： 1.教师端与学生端连接错误2.网络异常导致学生屏幕无法显示老师的共享屏幕。
特殊需求：系统切换显示界面的响应时间小于0.05s。
发送文件ID： 4用例名称：发送文件参与者：教师用例描述：产生的原因：教师需要将作业内容发送给老师。
大概过程：教师整理作业内容后，按“提交按钮”发送给所有学生。
输出结果：系统提示文件送达成功或者失败。
前置条件：教师必须提供上传信息资源请求。
后置条件：可快速共享文件给学生，并在群聊中发现学生存在的问题。
正常流程： 1.教师提交上传文件信息请求2.界面转换至上传文件界面3教师将所传文件内容进行上传4进行提交5系统提示成功与否信息异常流程：1用户取消上传请求，系统回到界面。
2文件上传失败，系统提示再次上传。
特殊需求：上传文件不宜过大。
接受文件ID： 5用例名称：接受文件参与者：教师用例描述：产生的原因：学生需要将作业要求发送给教师。
大概过程：教师收到新邮件提示信息，打开文件进行下载。
输出结果：系统提示文件下载成功或者失败。
前置条件：教师必须提交下载信息资源请求。
后置条件：教师接收学生的课堂作业正常流程：1教师收到新邮件信息2.教师点击新邮件3界面转换至下载文件界面4系统提示下载成功与否信息异常流程： 1.用户取消下载请求，系统回到界面。
2.文件下载失败，系统提示再次下载。
特殊需求：下载文件不宜过大。
群聊ID： 6名称：群聊参与者：学生、老师描述：产生的原因：教师需要了解学生对课程的掌握情况及存在的问题。
大概过程：打开聊天界面，便弹出聊天窗口。
输入信息，点击发送，信息便发送成功，并且显示在聊天窗口上。
前置条件： 1.教师进入到聊天界面。
2.用户必须联网方能使用。
后置条件： 1.聊天信息必须显示，所有成员都能看到。
2.聊天记录可清空。
正常流程： 1.打开群聊天窗口界面。
2.输入信息，点击发送。
3.群中所有成员发送信息都显示在群聊天窗口上。
分支流程： 1.若想进行私聊，一对一聊天1.点击你想要聊天的好友，打开聊天窗口。
2.发送信息时，就点击到当前窗口。
异常流程： 1.教师取消发送的信息。
2教师发送离线信息。
3.信息发送时由于网络异常自己或对方掉线，对方未接收到。
4.教师停止发送信息。
5.教师重新发送信息。