用例图描述
用例图和用例描述设计实例
用例图和用例描述设计实例作者：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.有头类、⾝体类与⼈类类三个类，则⼈类类中应包含头类及⾝体类这两个属性，则⼈类类与头类和⾝体的关系即为组合关系。
- 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.教师重新发送信息。