门户网站用例图与用例描述
UML用例和用例图
h
18
主要内容
基本概念：Use case、Actor、
Scenario Use case间的关系 Use Case 分析技术 案例讲解
h
19
关系
• 参与者与用例之间
– 关联关系
• 用例与用例之间
– 包含关系 (include) – 扩展关系 (extend) – 泛化关系 (generalization)
• 主事件流： • 1、系统显示ID和密码窗口； • 2、顾客键入ID和密码，然后按OK键； • 3、系统验证顾客ID和密码，并显示个人信息窗口； • 4、顾客键入姓名、街道地址、城市、邮政编码、电话号码，然
后按OK键； • 5、系统验证用户是否为老顾客； • 6、系统显示可以卖的商品列表； • 7、顾客在准备购买的商品图片上单击，并在图片旁边输入要购
• 用例结束后的系统状态
• 其他需要描述的内容
用例描述原则：尽可能写的“充分”，而不是追求写的形 式化、完整或漂亮。
h
32
h
33
书写用例文档
——路径交互步骤的描述
只书写“可观测”的 使用主动语句 句子必须以执行者或系统作为主语 每一句都要朝目标迈进 分支和循环 不要涉及界面细节
h
34
书写用例文档
买的数量。选购商品完毕后按Done按钮； • 8、系统通过库存系统验证要购买的商品是否有足够库存； • …….（后续描述省略）
问题：对用户界面的描述过于详细，对于需求文档来说， 详细的用户描述对获取需求并无帮助。
h
45
改进后的描述
• Use Case：Buy Something • 参与者：Customer • 主事件流： • 1、顾客使用ID和密码进入系统； • 2、系统验证顾客身份； • 3、顾客提供姓名、地址、电话号码； • 4、系统验证顾客是否为老顾客； • 5、顾客选择要购买的商品和数量； • 6、系统通过库存系统验证要购买的商品是否有足
用例图和用例描述设计实例
用例图和用例描述设计实例作者：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位数字构成，用户按原样输入验证码。
图书管理系统用例描述
图书管理系统设计报告班级：信管１001学号：2010０59８姓名：王勇一、图书管理系统用例图1.１、图书管理系统用例图根据平常自己去图书馆的经历，简单绘制了图书馆的用例图,其中包括学生借书、还书、交罚金的功能,以及管理员处理还书、更新图书、读者信息邓等功能。
1.２、图书管理系统用例描述变异点:补充说明:二、图书管理系统类图２.1、实体类图因为存在图书,所以才会有读者借书，借书会因为图书的改变而改变，所以借书与图书是依赖关系。
2.2、边界类图查询页面、借书页面、还书页面、更新图书信息页面、更新读者信息页面、处理还书页面都是在登陆页面后选择的业务,所以属于普通关联关系。
由于版本问题,选择边界和控制类,图形无法改变,只能在图形上用单词“ｂｏｕndａry”标出。
望老师见谅。
2.３、控制类图处理罚金是处理还书过程中的一个任务,所以是一种组成关联关系三、图书管理系统时序图３．1、读者查询借阅记录时序图、图书馆数据库中存有读者的借阅记录。
3.２、读者登录时序图３.３、读者还书时序图管理员处理还书时存在图书过期和没有过期两钟情况，所以会返回两种信息。
3.４、读者借书时序图３.５、管理员处理还书时序图读者还书过程中也会存在两种情况,一种图书过期，一种没有过期。
3.6、管理员更新读者时序图3．７、管理员更新图书时序图四、图书管理系统协作图4.1、读者查询借阅记录协作图4.2、读者登录协作图4.3、读者还书协作图图书返回个处理还书有两种可能一是“4:没有过期”二是“7：过期”；当返回“4:没有过期时”系统执行５、６；当返回“7：过期”时系统执行8、94.４、读者借书协作图4．5、管理员处理还书协作图图书返回个处理还书有两种可能一是“４:没有过期”二是“7：过期”;当返回“4：没有过期时”系统执行5、6;当返回“7:过期”时系统执行8、９4.6、管理员更新读者协作图4.7、管理员更新读者协作图五、图书管理系统组件图当读者借书时，分两个过程,一个是图书的过程，一个是图书信息的过程。
普通用户用例图
普通用户用例图
图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图？这可是典型的面向过程分析模式。
网上购物系统详细精炼版(UML-类图-时序图-数据流图)
网上购物系统作为B2B，B2C（Business to Customer，即企业对消费者），C2C（Customer to Customer，即消费者对消费者)电子商务的前端商务平台，在其商务活动全过程中起着举足轻重的作用。本文主要考虑的是如何建设B2C的网上购物系统。
1.3
本说明书的主要目的是明确所要开发的软件应具有的功能、性能，使系统分析人员和软件设计人员能清楚地了解用户的需求，并在此基础上进一步提出概要设计和完成后续设计与开发工作，为软件开发范围、业务处理规范提供依据，也是应用软件进行合同最终验收的依据。
本文档的读者对象：项目经理、系统分析师、项目开发人员、客户代表。
（3）商品查询：商品速查，根据查询条件，快速查询用户所需商品；商品分类浏览，按照商品的类别列出商品目录；
（4）订单管理：订单信息浏览订单结算订单维护
（5）购物车管理
购物车中商品的增删；
采购数量的改变
生成采购订单
（6）后台管理
商品分类管理
商品基本信息管理
订单处理
会员信息管理
图1系统顶级用例图
3.2
用例图及相关的用例描述如图
1.4
网上购物系统作为B2B，B2C（Business to Customer，即企业对消费者），C2C（Customer to Customer，即消费者对消费者)电子商务的前端商务平台，在其商务活动全过程中起着举足轻重的作用。本文主要考虑的是如何建设B2C的网上购物系统。
2
2.1
系统用例描述
瑞天图书管理系统用例描述-、图书借阅该用例提供了用户借阅图书时管理员更新图书信息以及日志、记 录借阅信息、创建和修改借阅者账户以及信息等 1、用例图如下：2、用例描述: 用例名称：图书借阅简要说明：图书管理员输入读者编号和图书编号来完成图书借阅。
参与者：图书管理员前置条件：读者出示的借阅证必须是有效的借阅证(from 图书管理系统参与创建新的借阅者帐户其他用户修改借阅者的帐户信息管理员已还书)(from 图书管理系统参与记录图书数量与价格学生(from 图书管理系统参与后置条件：显示读者的全部借阅信息假设条件：图书管理员已经成功登录图书管理系统基本操作流程：(1)图书管理员输入借阅证信息(2)系统检查读者是否有超期的借阅信息和读者的借书数量是否已经达到借书限额(4)图书管理员输入要借阅的图书信息(5)系统将读者的借阅信息保存到数据库中可选操作流程：读者有超期的借阅信息，或者读者的借书数量已经达到借书限额，系统显示不能借阅图书的信息，图书管理员进行超期处理。
二、归还图书1、用例图如下:2、用例描述: 用例名称：归还图书简要说明：图书管理员收到要归还的图书，进行还书操作。
参与者：图书管理员、学生、其他用户前置条件：无后置条件：显示读者的全部借阅信息假设条件：图书管理员已经成功登录图书管理系统 基本操作流程：(1) 图书管理员输入读者要归还的图书信息 (2) 系统检索与该图书相关的借阅者信息 (3) 系统检查该借阅者是否有超期的借阅信息 (4) 系统将借阅者的还书信息保存到数据库中(from))登录(5)系统将该图书的状态改变为可借阅状态可选操作流程：读者归还图书，图书管理员查看是否超出期限，并进行相应处罚，并且图书管理员将借阅信息删除。
三、图书查询1、用例图如下:输入书籍信息2、用例描述:用例名称：图书查询简要说明：用户登录网站进行查询参与者：用户前置条件：必须有登录账户后置条件：显示要借图书的全部信息假设条件：用户已经成功登录图书管理系统3、操作流程：(1)用户输入登录信息(2)系统检查读者是否有账号(3)用户输入要查询的图书信息(4)系统检查读者的借书信息是否存在可选操作流程：读者有超期的借阅信息，图书管理员进行超期处理; 读者的借书数量已经达到借书限额，系统显示不能借阅图书的信息。
用例图设计：根据需求,绘制用例图,明确系统功能和模块
用例图设计：根据需求，绘制用例图，明确系统功能和模块一、引言随着信息技术的快速发展，软件系统在各个领域得到广泛应用。
而在软件系统开发的过程中，需求分析是至关重要的一环。
其中，用例图作为一种常用的需求分析工具，能够帮助开发团队理解系统功能并明确系统模块。
本文将介绍用例图设计的基本概念和步骤，并结合一个实际案例进行说明。
二、用例图设计概述1. 用例图的定义用例图是一种描述系统功能和角色之间交互关系的图形化工具。
它能够帮助开发团队和用户理解系统的功能，并明确各个模块的职责和关系。
2. 用例图的组成元素用例图由用例、参与者和关系三个主要元素组成。
- 用例（Use Case）：用例是指系统提供给用户的功能需求，用一个椭圆形图标表示。
每个用例都有一个唯一的名称，用以描述其功能和目的。
- 参与者（Actor）：参与者是指与系统交互的用户、其他系统或外部设备，用一个小人形图标表示。
每个参与者都有一个唯一的名称，用以描述其角色和功能。
- 关系（Relationship）：关系是指用例与参与者之间或用例之间的交互关系，用实线、虚线或箭头表示。
常见的关系有包含关系、扩展关系和泛化关系。
三、用例图设计步骤用例图设计的步骤主要包括需求收集、用例识别、参与者识别、用例编写和关系建立。
1. 需求收集需求收集是用例图设计的第一步，开发团队需要与用户进行充分的沟通和交流，了解系统的功能需求和用户的期望。
通过与用户积极互动，收集尽可能多的信息，以便后续的用例识别和设计。
2. 用例识别用例识别是根据需求收集的结果，将系统的功能需求划分为不同的用例。
每个用例都应该描述一个具体的功能，并具有明确的输入和输出。
3. 参与者识别参与者识别是根据需求收集的结果，将与系统交互的用户、其他系统或外部设备识别出来，并为每个参与者定义明确的角色和功能。
4. 用例编写用例编写是将识别出来的用例进行详细描述。
每个用例应包含用例名称、前置条件、正常流程、异常流程和后置条件等内容。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
4：管理新闻
4-1添加新闻
用例描述：
用例名称：添加新闻
用例标识号：4-1
参与者：管理员
简要说明：
管理员向网站添加新闻
前置条件：
管理员已经登管理系统
基本事件流：
1．负责人鼠标点击“添加新闻”按钮
2．系统出现一个空白的文本框。
3．负责人可以在文本框添加新闻，
4．负责人编辑完文本框，按“提交”按钮，首页新闻信息就被更新
3.用例终止
其他事件流A1：
管理员随时可以按“返回”按钮返回到管理系统主页面
异常事件流：
1．提示错误信息，管理员确认
2．返回到管理系统主页面
后置条件：
无
注释：无
5-2修改用户信息：
用例名称：修改用户信息
用例标识号：4-2
参与者：管理员
简要说明：
管理员用来修改用户信息，该用户信息最终更新用户列表上。
前置条件：
其他事件流A1：
在按“提交”按钮之前，管理员随时可以按“返回”按钮，文本框的任何修改内容都不会影响网站首页的新闻信息
异常事件流：
1．提示错误信息，管理员确认
2．返回到管理系统主页面
后置条件：
网站首页的新闻信息被更新
注释：无
4-3删除新闻：
用例名称：删除新闻
用例标识号：4-3
参与者：管理员
简要说明：
管理员用来删除网站新闻信息，该新闻信息从网站首页上消失。
异常事件流：
1．提示错误信息，点击“确认”按钮
2．返回主页
后置条件：回复成功
注释：无
7-5：发布留言
用例描述
用例名称：发布留言
用例标识号：7-3
参与者：用户
简要说明：用户对相应帖子发布留言
前置条件：用户已登录，切到相应帖子页面下
基本事件流：
1．用户鼠标点击“发布留言”按钮
2．系统出现一个文本域
3．用户编辑留言，按“发布”按钮，完成留言发布
3. 管理员选择一条留言标题，点击浏览留言详细信息；
4．管理员可以在选择要回复的留言；
5. 管理员点击提交回复留言
6．用例终止；
其他事件流A1：
在按“提交”按钮之前，管理员随时可以按“返回”按钮，返回到浏览页面
异常事件流：
1．提示错误信息，管理员确认；
2．返回到留言管理页面。
后置条件：
系统中的留言得到回复
1：总体用例图
2：留言管理
2-1:回复留言
用例描述:
用例名称：回复留言
用例标识号：2-1
参与者：管理员
简要说明：
管理员对用户提交到系统的留言，进行浏览和回复。
前置条件：
管理员已经登管理系统
基本事件流：
1．管理员鼠标点击“浏览留言”按钮，发出留言审核请求；
2．系统提供系统中存储的留言，分页显示留言内容；
1．管理员鼠标点击“删除用户信息”按钮
2．系统出现一个文本框，显示着原来的用户信息
3. 管理员按“确认”按钮，首页上该条用户信息就被删除
4．用例终止
其他事件流A1：
在按“确认”按钮之前，管理员随时可以按“返回”按钮，文本框的任何修改内容都不会影响该用户的信息
异常事件流：
1．提示错误信息，管理员确认
2．返回到管理系统主页面
4．用例终止
其他事件流A1：突发性终止，或者用户点击返回，返回到主页
异常事件流：
1．提示错误信息用户确认
2．返回主页
后置条件：留言发布成功
注释：无
最新文件仅供参考已改成word文本。方便更改
前置条件：
管理员已经登陆网站管理系统
基本事件流：
1．管理员鼠标点击“删除新闻”按钮
2．系统出现一个文本框，显示着原来的新闻内容
3. 管理员按“确认”按钮，首页上该条新闻信息就被删除
4．用例终止
其他事件流A1：
在按“确认”按钮之前，管理员随时可以按“返回”按钮，不会影响网站首页的新闻信息
异常事件流：
1．提示错误信息，管理员确认
参与者：用户
简要说明：用户回复别人对自己帖子的回复
前置条件：用户已登录，且到相应的帖子下，看到相应的留言
基本事件流：
1．用户鼠标点击“回复留言”按钮
2．系统出现文本域，用户编辑回复内容
3．用户编辑完回复内容，点击“提交”按钮，提交回复
4．用例终止
其他事件流A1：当用户回复写到一半不想继续写，或者突发性终止，返回主页
后置条件：
无
注释：无
7：用户用例：
7-1：浏览信息
用例描述
用例名称：浏览信息
用例标识号：7-1
参与者：用户
简要说明：
游客可以浏览新闻，帖子，留言等各种信息。
前置条件：
游客已经在浏览门户网站
基本事件流：
1．用户点击信息标题
2．系统跳转到详细信息页面；
3. 游客浏览信息；
4．用例终止；
其他事件流A1：
无
4．系统检验游客登陆信息；
5．检验成功系统跳转到系统首页；检验失败系统进行提示，登陆页面清空。
6．用例终止；
其他事件流A1：
在按“提交”按钮之前，游客随时可以按“返回”按钮，登陆状态不改变。
异常事件流：
1．提示错误信息，游客确认；
2．返回到登陆页面顶部页面。
后置条件：
游客登陆成功
注释：无
6-3：浏览信息
异常事件流：
1．提示错误信息，游客确认；
2．返回到门户网站首页。
后置条件：
无
注释：无
7-2：修改个人信息
用例描述
用例名称：修改个人信息
用例标识号：7-2
参与者：用户
简要说明：用户修改个人信息
前置条件：用户已登录
基本事件流：
1．用户鼠标点击“修改个人信息”按钮
2．系统出现一个表单，表单：密码，电话号码，邮箱，且显示原有信息
管理员已经登陆网站管理系统，并查看用户信息。
基本事件流：
1．管理员鼠标点击“修改用户信息”按钮
2．系统出现一个文本框，显示着原来的用户信息
3．管理员可以在文本框上修改用户信息，
4．管理员编辑完文本框，按“提交”按钮，该用户信息就被修改
5．用例终止
其他事件流A1：
在按“提交”按钮之前，管理员随时可以按“返回”按钮，文本框的任何修改内容都不会影响该用户的信息
异常事件流：
1．提示错误信息，管理员确认；
2．返回到帖子管理页面。
后置条件：
系统中的帖子批准状态被修改。
注释：无
3-2删除帖子
用例描述
用例名称：删除帖子
用例标识号：3-2
参与者：管理员
简要说明：
管理员对用户提交到系统的帖子，进行浏览和删除帖子。
前置条件：
管理员已经登管理系统
基本事件流：
1．管理员鼠标点击“浏览帖子”按钮，发出帖子浏览请求；
5．用例终止
其他事件流A1：
在按“提交”按钮之前，管理员随时可以按“返回”按钮，文本框的任何修改内容都不会影响网站首页的新闻信息
异常事件流：
1．提示错误信息，管理员确认；
2．返回到留言管理页面。
后置条件：
系统中的新闻信息被更新。
注释：无
4-2更新新闻：
用例名称：更新新闻
用例标识号：4-2
参与者：管理员
前置条件：
管理员已经登管理系统
基本事件流：
1．管理员鼠标点击“浏览帖子”按钮，发出帖子浏览请求；
2．系统提供系统中存储的帖子，分页显示帖子内容；
3．管理员可以在选择要帖子的留言；
4. 管理员点击提交回复帖子
5．用例终止；
其他事件流A1：
在按“提交”按钮之前，管理员随时可以按“返回”按钮，返回到浏览页面
用例描述
用例名称：浏览信息
用例标识号：6-3
参与者：游客
简要说明：
游客可以浏览新闻，帖子，留言等各种信息。
前置条件：
游客已经在浏览门户网站
基本事件流：
1．游客点击信息标题
2．系统跳转到详细信息页面；
3. 游客浏览信息；
4．用例终止；
其他事件流A1：
无
异常事件流：
1．提示错误信息，游客确认；
2．返回到门户网站首页。
后置条件：
该用户信息被删除，用户列表被更新
注释：无
6-2：登陆
用例描述
用例名称：登陆
用例标识号：6-2
参与者：游客
简要说明：
游客登陆系统变为用户身份，游客可以登陆也可以不登陆。
前置条件：
游客已经在浏览门户网站
基本事件流：
1．游客鼠标点击“登陆”按钮，发出登陆请求；
2．系统跳转到登陆页面；
3. 游客填写登陆信息；
2．系统提供系统中存储的帖子，分页显示帖子内 管理员点击删除按钮删除帖子
5．用例终止；
其他事件流A1：
在按“提交”按钮之前，管理员随时可以按“返回”按钮，返回到浏览页面
异常事件流：
1．提示错误信息，管理员确认；
2．返回到帖子管理页面。
后置条件：
系统中的帖子被删除
简要说明：
管理员用来修改网站新闻信息，该新闻信息最终更新显示在网站的首页上。
前置条件：
管理员已经登陆网站管理系统
基本事件流：
1．管理员鼠标点击“更新新闻”按钮
2．系统出现一个文本框，显示着原来的新闻内容
3．管理员可以在文本框 上修改新闻，
4．管理员编辑完文本框，按“提交”按钮，首页公告就被修改
5．用例终止
2．返回到管理系统主页面
后置条件：