门户网站用例图与用例描述
02-用例和用例图
3.4.4 几种关系的比较
关系类型
说明
表示符号
关联
actor与use case之间
泛化
actor之间或use case之间
包含
use case之间
扩展
use case之间
用例图
用例图(use case diagram)是显示一组用例、角色以及它 们之间的关系的图.
在UML中, 一个用例模型若干个用例图描述.
角色
由于Actor实际上是一个特殊类, 因此它们之间可以 存在一定的关系,如：
脚本/场景
脚本(scenario)在UML中指贯穿用例的一条单一路径, 用 来显示用例中的某种特殊情况.
其它译名: 情景、情节、剧本.
每个用例有一系列脚本, 包括一个主要脚本, 以及几个 次要脚本. 相对于主要脚本, 次要脚本描述了执行路径 中的异常或可选择的情况.
实例分析：语音邮箱系统----用例脚本
用例3: 登录系统 1. 邮箱用户完成邮箱号输入操作. 2. 邮箱用户键入密码并后跟#键.(默认号码与邮箱号相同) 3. 语音邮件系统播放邮箱菜单: 按1键接收信息. 按2键更改密码. 按3键更改问候语.
实例分析：语音邮箱系统----用例脚本
用例4: 接收信息 1. 邮箱用户完成登录操作. 2. 邮箱用户选择 “接收信息”菜单选项. 3. 语音邮件系统播放信息菜单: 按1收听当前信息; 按2存储当前信息; 按3删除当前信息; 按4返回邮箱菜单. 4. 邮箱用户选择“收听当前信息”菜单选项. 5. 语音邮件系统播放当前新信息,若无新信息,播放当前已有信 息.(注意: 只播放,不删除) 6. 语音邮件系统播放信息菜单. 7. 用户选择”删除当前信息”,则信息被永久删除. 8. 继续执行第3步.
用例图和用例描述设计实例
用例图和用例描述设计实例作者：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位数字构成，用户按原样输入验证码。
系统用例描述 (2)
瑞天图书管理系统用例描述一、图书借阅该用例提供了用户借阅图书时管理员更新图书信息以及日志、记录借阅信息、创建与修改借阅者账户以及信息等 1、用例图如下:记录图书数量与价格(from ...)2、用例描述: 用例名称: 图书借阅简要说明:图书管理员输入读者编号与图书编号来完成图书借阅。
参与者:图书管理员前置条件:读者出示的借阅证必须就是有效的借阅证后置条件:显示读者的全部借阅信息假设条件:图书管理员已经成功登录图书管理系统基本操作流程:(１) 图书管理员输入借阅证信息(2) 系统检查读者就是否有超期的借阅信息与读者的借书数量就是否已经达到借书限额(4) 图书管理员输入要借阅的图书信息(５) 系统将读者的借阅信息保存到数据库中可选操作流程:读者有超期的借阅信息,或者读者的借书数量已经达到借书限额,系统显示不能借阅图书的信息,图书管理员进行超期处理。
二、归还图书1、用例图如下:) (from)登录2、用例描述:用例名称:归还图书简要说明:图书管理员收到要归还的图书,进行还书操作。
参与者:图书管理员、学生、其她用户前置条件:无后置条件:显示读者的全部借阅信息假设条件:图书管理员已经成功登录图书管理系统基本操作流程:(1)图书管理员输入读者要归还的图书信息(2) 系统检索与该图书相关的借阅者信息(3) 系统检查该借阅者就是否有超期的借阅信息(4) 系统将借阅者的还书信息保存到数据库中(5)系统将该图书的状态改变为可借阅状态可选操作流程:读者归还图书,图书管理员查瞧就是否超出期限,并进行相应处罚,并且图书管理员将借阅信息删除。
三、图书查询1、用例图如下:输入书籍信息２、用例描述:用例名称: 图书查询简要说明:用户登录网站进行查询参与者:用户前置条件:必须有登录账户后置条件:显示要借图书的全部信息假设条件:用户已经成功登录图书管理系统3、操作流程:(1) 用户输入登录信息(2)系统检查读者就是否有账号(３) 用户输入要查询的图书信息(4)系统检查读者的借书信息就是否存在可选操作流程:读者有超期的借阅信息,图书管理员进行超期处理;读者的借书数量已经达到借书限额,系统显示不能借阅图书的信息。
用例及用例图案例
用例及用例图-案例
3.7 业务用例图 3.8 案例
1
3.7 业务用例图
• 作用
– 帮助了解机构及其软件系统（或工作内容） – 帮助业务过程重建工程工作 – 帮助员工（小组内成员）充分了解业务及其角色
• 什么时候需要
– 对机构不熟悉 – 机构业务发生变更 – 机构中主要部分使用的软件需建立 – 机构中有些大型复杂工作流的文档不足
20
● ⑤ 绘制用例图。
21
● ⑥ 编制用例说明。
● 用例：客房预订 ●参与者：柜台工作人员 ●说明：
① 工作人员启动预订功能。 ② 根据预订需求查看客房空闲信息。 ③ 输入预订人信息。 ④ 安排客房。 ⑤ 预订成功。
22
● ⑥ 编制用例说明。
● 用例：预订变更 ●参与者：柜台工作人员 ●说明：
Ａ２：有冲突。
⑧系统添加新课程，并提示添加成功。
⑨系统回到管理主界面，显示所有课程，用例结束。
14
● ⑦ 对异常流程确定单独用例。 ⑧ 优化用例图，解决用例之间的冲突和重复。
15
案例3：
宾馆客房业务管理用例分析
宾馆客房业务管理提供客房预订、预订变更、 客房入住、退房结帐、旅客信息查询几个方面的 功能。
第3章 用例和用例图
● 3.4 用例图 3.4.1 用例图的作用 3.4.2 用例图的形式
● 3.5 用例描述 ● 3.6 用例分析 ● 3.7 业务用例图
● —— 重要知识点
26
本章作业
(1) 什么叫用例？ (2) 用例图在软件建模中的作用是什么？ (3) 用例之间存在那几种关系？ (4) 包含关系和扩展关系有什么区别? (5) 参与者可以是那几种形式？ (6) 什么叫事件流,作用是什么？
用例和用例图
用例
用例(use case)是Ivar Jacobson发明的. 其它的中 文译名有: 用况、用案等. 定义1: 用例是对一个活动者(actor)使用系统的一项 功能时所进行的交互过程的一个文字描述序列. 定义2: 用例是系统、子系统或类和外部参与者交互 的动作序列的说明, 包括可选的动作序列和会出现 异常的动作序列. 用例是代表系统中各个项目相关人员之间就系统的 行为所达成的契约, 软件开发过程是用例驱动的.
实例1：图书馆管理系统中的用例图
1.确定系统涉及的总体信息 图书馆管理系统是对书籍的借阅及读者信息进行统 一管理的系统，具体包括读者的借书、还书，书籍 预订；图书馆管理员的书籍借出处理、书籍归还处 理、预订信息处理；还有系统管理员的系统维护， 包括增加书目、删除或更新书目、增加书籍、减少 书籍、增加读者账户信息、删除或更新读者账户信 息、书籍信息查询、读者信息查询等。
用例图的作用
用例图展示了用例之间以及用例与参与者之间是怎样相互联 系的。用例图对系统、子系统或类的行为进行了可视化，使 用户能够理解如何使用这些元素，并使开发者能够实现这些 元素。 用例图主要用来描述用户的功能需求。UML侧重从最终用户 的角度来理解软件系统的需求，强调谁在使用系统、系统可 以完成哪些功能。用例分析技术已经是一种公认有效的用户 需求获取、分析和描述技术
情况二：假如机票购买者通过呼叫中心，由人工座席 操作订票系统购买机票，那么谁是参与者？
情况三：如果机票购买者通过呼叫中心的自动语音预 定机票而不是通过人工座席，那么谁是参与者？
情况四：如果扩大系统边界，让呼叫中心成为机票预 定系统的一个子系统，并且假设机票购买者将可以 自主选择是通过人工座席还是自动语音登录网站预 订机票，那么谁是参与者？
普通用户用例图
普通用户用例图
图2.1是普通用户对该网站进行操作的用例图，对于用户来说，要访问该网站，必须先注册，登陆，然后才能对该网站进行操作，经过身份认证后，用户可以进行课件浏览，可以对答疑模块，测试模块，进行操作。
图2.1 普通用户用例图
2.3.2学生用例图
在该系统中，学生要进行访问该网站的时候，要像一般用户一样注册登陆，不过学生比一般用户多的一个权限就是先进行身份认证后对作业系统进行操作。
用例图如图2.2所示：
图2.2 学生用例图
2.3.3教师用例图
教师用例图表示了教师的操作权限，教师可以有管理员的权限，身份认证通过以后，教师可以进行公告管理，作业模块管理，答疑模块管理，学习资料库模块管理，考试模块管理。
具体用例图如图2.3所示：
图2.3教师用例图
2.4 活动图
进入本系统后，有两个活动选项，一个是供一般用户的系统登陆入口，一个是供教师的系统登陆入口，系统活动图如图2.4所示：
图2.4系统活动图2.5 数据流图
以下是系统的部分数据流图，主要是老师和学生的登陆，然后老师和学生由于权限的不同所做的不同的操作。
不过在系统中，学生要重新注册一个帐号才能登陆，这样就给了其他游客也可以访问该网站的权限，不过也要注册帐号。
图2.5是系统一级数据流图，图2.6是系统二级数据流图。
图2.5一级系统数据流图
图2.6二级系统数据流图。
什么是用例和用例描述
我发现，在OO和UML几乎一统天下的今天，仍有很多系统分析员对OO和UML一知半解，甚至包括很多已经使用了很久UML的系统分析员。
于是打算写一个系列文章，将多年来的工作经验做一个总结。
对初学者起个启蒙作用，也希望抛砖引喻，与各路大虾共同探讨，共同提高。
这个系列文章将以我对OO和系统分析的理解为主，从UML基础开始，阐述面向对象的需求分析方法，过程，并以RUP为例，阐述如何将OO过程与软件过程有机结合在一起，做一个真正OO应用。
好了，今天是第一篇。
想得很远，不知能否坚持下去，呵呵:lol:用例是什么？其原始英文是usecase，直译过来就成了用例。
这也是一个比较贴切的叫法了，从字面的直接理解就是使用的例子。
另一种比较流行的定义是用例就是与使用者(actor)交互的，并且给使用者提供可观测的有意义的结果的一系列活动的集合。
这个定义还是比较费解的，笔者在众多应聘者中发现很多使用用例来做需求的系统分析员，有的已经使用了两年以上，但仍不能把握用例的本质，虽然他们号称精通UML。
最具普遍意义的理解错误是认为用例就是功能的划分和描述，认为一个用例就是一个功能点。
在这种理解下，用例变成了仅仅是较早前需求中功能框图的翻版，很多人用用例来划分子系统，功能模块和功能点。
如果这样，用例根本没有存在的必要。
有意思的是，造成这种理解错误的相当一部分原因却是因为对OO思想的理解不够深入，本质上说，把用例当成功能点的系统分析员脑子里还是面向过程的那一套思想，虽然他们在使用OO的工具，OO的语言，号称在做面向对象的开发，但过程的影子还没有从他们脑子里彻底抹去。
如果用例不是功能的话，它是什么呢？从定义上说，能给使用者提供一个执行结果的活动，不就是功能吗？我的回答是：错！功能是计算机术语，它是用来描述计算机的，而非定义需求的术语。
功能实际描述的是输入-->计算-->输出。
这让你想到了什么？DFD图？这可是典型的面向过程分析模式。
网上投稿系统用例图
图一 网上投稿系统注册登录子系统用例图
查看稿件
稿件管理
查看状态稿件编号
查询
用户管理员
<< include >>
<< include >>
<< include >>
<< include >>
图二 网上投稿系统稿件查询子系统用例图
（一）用户注册登录用例描述：
用例游客编号：001
用例名称：游客注册并登录
简要描述：游客进行填写自己的基本信息，并会在注册完成之后生成用户ID ，用户可以根据用户ID 进行登录。
前置条件：这个用例启动之前游客必须登陆到系统中。
基本流：
① 游客填写自己的基本信息
② 信息填写完成后，进行提交
③ 提交成功后，注册完成，用户进行登录
备选流：
① 游客注册信息不完整或邮箱未通过，注册失败，用例终止
② 用户需要记住自己用户ID，以便进行下次登录
后置条件：如果这个用例成功，系统数据库将添加用户信息。
（二）稿件查询用例描述
用例名称：投递稿件查询
简要描述：用户在投递稿件之后，可以对稿件进行查询，查看稿件状态信息。
前置条件：用户稿件已投递
基本流：
① 用户投递稿件
② 对稿件进行查询
③ 显示稿件状态信息
备选流：
① 未投递过稿件的用户查询界面会出现提示信息
后置条件：若用例成功，将会在数据库留下信息。
用例和用例图
技巧 实地观察
访谈
描述
• 直接观察个人工作旳情况，以发觉现存旳实践方式和
问题
• 从个人处搜集特定信息
特定群体 调查
对一组人员进行调查，以便了解工作态度和共同看法
• 问卷调查 搜集详细数据和统计意义上比较主要旳数据
• • 顾客指 导
让最终顾客告诉你，他们是怎样操作系统旳
• 原型制作 模拟一种无法直接测试旳系统
人、外部系统、外部因素等
12
3.2.2 辨认参加者：参加者要点
• 参加者指在系统中所扮演旳角色。即在拟定参加者时，
应主要考虑他旳角色，而不是这个角色旳实例。
• 某些组织中可能有诸多营销人员，但他们均起着同
一种作用，扮演着相同旳角色。
• 一种顾客也能够扮演多…种角色：一种高级营销人员
既能够是贸易经理，也能够是一般旳营销人员。
小一点旳蓝色大理石
5
3.2.1 获取原始需求：如此脆弱
客户/顾客旳要 求/想法/期望
验收
分析和设计
没价值旳 软件需求
补文档
软件产品 编码和测试
软件设计
6
3.2.1 获取原始需求：也需要开发
客户/顾客旳要 求/想法/期望
软件产品
开发
验收
编码和测试
有价值旳 软件需求
分析和设计
软件设计
7
3.2.1 获取原始需求：技巧
第三章 用例和用例图
1
3.1 概述
• 用例图着重从系统外部执行者旳角度来描述系统需要提
供哪些功能，执行者能够是人或外部系统。
2
3.1 概述
用例图旳构成元素
• 图中旳元素涉及：参加者、用例、某些表达关系旳连接
门户网站用例图和用例描述doc13页版
1：整体用例图注册用户登岸旅客阅读信息改正个人信息用户答复留言公布帖子公布留言2：留言管理答复留言管理员删除留言2-1:答复留言用例描绘:管理帖子管理留言管理员管理新闻管理用户用例名称：答复留言用例表记号：2-1参加者：管理员简要说明：管理员对用户提交到系统的留言，进行阅读和答复。
前置条件：管理员已经登管理系统基本领件流：1．管理员鼠标点击“阅读留言”按钮，发出留言审查恳求；2．系统供给系统中储存的留言，分页显示留言内容；管理员选择一条留言标题，点击阅读留言详尽信息；4．管理员能够在选摘要答复的留言；管理员点击提交答复留言6．用例停止；其余事件流A1：在按“提交”按钮以前，管理员随时能够按“返回”按钮，返回到阅读页面异样事件流：1．提示错误信息，管理员确认；2．返回到留言管理页面。
后置条件：系统中的留言获得答复说明：无2-2:删除留言用例描绘:用例名称：删除留言用例表记号：2-2参加者：管理员简要说明：管理员对用户提交到系统的留言，进行阅读和删除前置条件：管理员已经登管理系统基本领件流：1．管理员鼠标点击“阅读留言”按钮，发出阅读留言恳求；2．系统供给系统中储存的经审查的留言，分页显示留言；管理员查察留言，点击删除按钮删除留言后从头列出留言；7．用例停止；其余事件流A1：在按“提交”按钮以前，管理员随时能够按“返回”按钮，返回到阅读页面异样事件流：1．提示错误信息，管理员确认；2．返回到留言管理页面。
后置条件：系统中的留言被删除。
说明：无3：管理帖子答复帖子管理员删除帖子3-1答复帖子用例描绘:用例名称：答复帖子用例表记号：3-1参加者：管理员简要说明：管理员对用户提交到系统的帖子，进行阅读和答复帖子。
前置条件：管理员已经登管理系统基本领件流：1．管理员鼠标点击“阅读帖子”按钮，发出帖子阅读恳求；2．系统供给系统中储存的帖子，分页显示帖子内容；3．管理员能够在选摘要帖子的留言；管理员点击提交答复帖子5．用例停止；其余事件流A1：在按“提交”按钮以前，管理员随时能够按“返回”按钮，返回到阅读页面异样事件流：1．提示错误信息，管理员确认；2．返回到帖子管理页面。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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．返回到帖子管理页面。
后置条件：系统中的帖子批准状态被修改。
注释：无3-2 删除帖子用例描述用例名称：删除帖子用例标识号：3-2 参与者：管理员简要说明：管理员对用户提交到系统的帖子，进行浏览和删除帖子。
前置条件：管理员已经登管理系统基本事件流：1．管理员鼠标点击“浏览帖子”按钮，发出帖子浏览请求；2．系统提供系统中存储的帖子，分页显示帖子内容；3．管理员可以在选择要删除帖子；4. 管理员点击删除按钮删除帖子5．用例终止；其他事件流A1：在按“提交”按钮之前，管理员随时可以按“返回”按钮，返回到浏览页面异常事件流：1．提示错误信息，管理员确认；2．返回到帖子管理页面。
后置条件：系统中的帖子被删除注释：无4：管理新闻4-1 添加新闻用例描述：用例名称：添加新闻用例标识号：4-1 参与者：管理员简要说明：管理员向网站添加新闻前置条件：管理员已经登管理系统基本事件流：1．负责人鼠标点击“添加新闻”按钮2．系统出现一个空白的文本框。
3．负责人可以在文本框添加新闻，4．负责人编辑完文本框，按“提交”按钮，首页新闻信息就被更新5．用例终止其他事件流A1：在按“提交”按钮之前，管理员随时可以按“返回”按钮，文本框的任何修改内容都不会影响网站首页的新闻信息异常事件流：1．提示错误信息，管理员确认；2．返回到留言管理页面。
后置条件：系统中的新闻信息被更新。
注释：无4-2 更新新闻：用例名称：更新新闻用例标识号：4-2 参与者：管理员简要说明：管理员用来修改网站新闻信息，该新闻信息最终更新显示在网站的首页上。
前置条件：管理员已经登陆网站管理系统基本事件流：1．管理员鼠标点击“更新新闻”按钮2．系统出现一个文本框，显示着原来的新闻内容3．管理员可以在文本框上修改新闻，4．管理员编辑完文本框，按“提交”按钮，首页公告就被修改5．用例终止其他事件流A1：在按“提交”按钮之前，管理员随时可以按“返回”按钮，文本框的任何修改内容都不会影响网站首页的新闻信息异常事件流：1．提示错误信息，管理员确认2．返回到管理系统主页面后置条件：网站首页的新闻信息被更新注释：无4-3 删除新闻：用例名称：删除新闻用例标识号：4-3 参与者：管理员简要说明：管理员用来删除网站新闻信息，该新闻信息从网站首页上消失前置条件：管理员已经登陆网站管理系统基本事件流：1．管理员鼠标点击“删除新闻”按钮2．系统出现一个文本框，显示着原来的新闻内容3. 管理员按“确认”按钮，首页上该条新闻信息就被删除4．用例终止其他事件流A1：在按“确认”按钮之前，管理员随时可以按“返回”按钮，不会影响网站首页的新闻信息异常事件流：1．提示错误信息，管理员确认2．返回到管理系统主页面后置条件：网站首页的新闻信息被更新注释：无5：管理用户6：游客用例5．管理用户：5-1 查看用户信息用例名称：查看用户信息用例标识号：5-1 参与者：管理员简要说明：管理员用来查看用户信息。
前置条件：管理员已经登陆网站管理系统基本事件流：1．管理员鼠标点击“ 查看用户信息”按钮2．系统出现一个文本框，显示已经存在的用户信息3. 用例终止其他事件流A1：管理员随时可以按“返回”按钮返回到管理系统主页面异常事件流：1．提示错误信息，管理员确认2．返回到管理系统主页面后置条件：无注释：无5-2 修改用户信息：用例名称：修改用户信息用例标识号：4-2 参与者：管理员简要说明：管理员用来修改用户信息，该用户信息最终更新用户列表上。
前置条件：管理员已经登陆网站管理系统，并查看用户信息。
基本事件流：1．管理员鼠标点击“ 修改用户信息”按钮2．系统出现一个文本框，显示着原来的用户信息3．管理员可以在文本框上修改用户信息，4．管理员编辑完文本框，按“提交”按钮，该用户信息就被修改5．用例终止其他事件流A1：在按“提交”按钮之前，管理员随时可以按“返回”按钮，文本框的任何修改内容都不会影响该用户的信息异常事件流：1．提示错误信息，管理员确认2．返回到管理系统主页面后置条件：该用户的信息被修改注释：无5-3 删除用户信息：用例名称：删除用户信息用例标识号：5-3 参与者：管理员简要说明：管理员用来删除用户信息，该用户信息从用户列表上消失。
前置条件：管理员已经登陆网站管理系统，并查看用户信息。
基本事件流：1．管理员鼠标点击“删除用户信息”按钮2．系统出现一个文本框，显示着原来的用户信息3. 管理员按“确认”按钮，首页上该条用户信息就被删除4．用例终止其他事件流A1：在按“确认”按钮之前，管理员随时可以按“返回”按钮，文本框的任何修改内容都不会影响该用户的信息异常事件流：1．提示错误信息，管理员确认2．返回到管理系统主页面后置条件：该用户信息被删除，用户列表被更新注释：无6-2：登陆用例描述用例名称：登陆用例标识号：6-2 参与者：游客简要说明：游客登陆系统变为用户身份，游客可以登陆也可以不登陆前置条件：游客已经在浏览门户网站基本事件流：1．游客鼠标点击“登陆”按钮，发出登陆请求；7：用户用例：7-1：浏览信息用例描述用例名称：浏览信息用例标识号：7-1 参与者：用户简要说明：游客可以浏览新闻，帖子，留言等各种信息前置条件：游客已经在浏览门户网站基本事件流：1．用户点击信息标题2．系统跳转到详细信息页面；3. 游客浏览信息；4．用例终止；其他事件流A1：无异常事件流：1．提示错误信息，游客确认；2．返回到门户网站首页。
后置条件：无注释：无7-2：修改个人信息用例描述用例名称：修改个人信息用例标识号：7-2参与者：用户简要说明：用户修改个人信息前置条件：用户已登录基本事件流：1．用户鼠标点击“修改个人信息”按钮2．系统出现一个表单，表单：密码，电话号码，邮箱，且显示原有信息3．用户编辑要修改的信息，按“修改”按钮，完成修改4．用例终止其他事件流A1：突发性终止，返回用户中心！异常事件流：1．提示错误信息用户确认2．返回用户中心后置条件：信息修改成功注释：无7-3：发布帖子用例描述用例名称：发布帖子用例标识号：7-3 参与者：用户简要说明：用户发布帖子前置条件：用户已登录基本事件流：1．用户鼠标点击“发布帖子”按钮2．系统出现一个表单，表单包括：帖子标题，帖子内容3．用户编辑帖子，按“发布”按钮，完成帖子发布4．用例终止其他事件流A1：无异常事件流：1．提示错误信息用户确认2．返回主页后置条件：帖子发布成功注释：无7-4 回复留言用例描述用例名称：回复留言用例标识号：7-4 参与者：用户简要说明：用户回复别人对自己帖子的回复前置条件：用户已登录，且到相应的帖子下，看到相应的留言基本事件流：1．用户鼠标点击“回复留言”按钮2．系统出现文本域，用户编辑回复内容3．用户编辑完回复内容，点击“提交”按钮，提交回复4．用例终止其他事件流A1：当用户回复写到一半不想继续写，或者突发性终止，返回主页异常事件流：1．提示错误信息，点击“确认”按钮2．返回主页后置条件：回复成功注释：无7-5：发布留言用例描述用例名称：发布留言用例标识号：7-3参与者：用户简要说明：用户对相应帖子发布留言前置条件：用户已登录，切到相应帖子页面下基本事件流：1．用户鼠标点击“发布留言”按钮2．系统出现一个文本域3．用户编辑留言，按“发布”按钮，完成留言发布4．用例终止其他事件流A1：突发性终止，或者用户点击返回，返回到主页异常事件流：1．提示错误信息用户确认2．返回主页后置条件：留言发布成功注释：无最新文件仅供参考已改成word 文本。
方便更改word.。