说明：本课程基于实训时间和项目体量，需求分析以功能需求为主。
登录系统前，需要对学生用户和教师用户进行信息注册。注册信息可以分成两个部分，个人身份信息和账号信息。如果注册成功，则给出相应提示，转入登录界面，否则可以重置信息再次注册。
登录时，需要先选择用户角色，输入正确的用户名和密码，登录成功则进入系统主界面，否则提示登录失败，需要重新登录。
该任务点要求对注册登录模块的功能描述和业务处理流程两部分进行撰写，最后形成本模块的用例图。
1、用例图的含义
由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。要在用例图上显示某个用例，可绘制一个椭圆，然后将用例的名称放在椭圆的中心或椭圆下面的中间位置。
要在用例图上绘制一个参与者（表示一个系统用户），可绘制一个人形符号。参与者和用例之间的关系使用带箭头或者不带箭头的线段来描述，箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者。
在用例建模中，为了更加清楚的描述用例或者参与者，会使用到注释。
2、用例图的作用
用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的了解系统的功能。借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。
3、用例图的构成要素
a)参与者
参与者（Actor）是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。
每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者。
在用例图中使用一个人形图标来表示参与者，参与者的名字写在人形图标下面。
b)参与者间的关系
由于参与者实质上也是类，所以它拥有与类相同的关系描述，即参与者与参与者之间主要是泛化关系（或称为“继承”关系）。
泛化关系的含义是把某些参与者的共同行为提取出来表示成通用行为，并描述成超类。泛化关系表示的是参与者之间的一般/特殊关系，在UML图中，使用带空心三角箭头的实线表示泛化关系。
c)系统边界
系统边界是指系统与系统之间的界限。通常我们所说的系统可以认为是由一系列的相互作用的元素形成的具有特定功能的有机整体。
4、如何识别用例
可以通过以下问题来寻找用例：
(1)参与者希望系统提供什么功能？
(2)参与者是否会读取、创建、修改、删除、存储系统的某种信息？如果是的话，参与者又是如何完成这些操作的？
(3)参与者是否会将外部的某些事件通知给系统？
(4)系统中发生的事件是否通知参与者？
(5)是否存在影响系统的外部事件
5、用例粒度
用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。
比如：网站后台管理系统中的会员信息维护用例，管理员需要进行添加会员信息、修改会员信息、删除会员信息等操作。
功能描述：
【编写要求：详细描述本功能需求需要实现的功能。】
使用者在程序运行登录窗口，选择角色或权限，有教师或学生，再输入相应的用户名和密码，按下登录按钮，登录到程序主界面，若用户名或密码有错误，给出错误提示。
如果点击的是注册按钮，进入程序注册界面，注册也先选择角色，教师或学生，然后输入对应的个人信息，若没有重复用户名，则注册成功，返回登录界面；若用户名重复，则提示错误原因。
处理流程：
【编写要求：用程序流程图说明本功能需求的业务处理流程，描述业务规则和业务约束。】
业务规则：
程序使用者输入正确的用户名和密码，需按下登录按钮进入程序主界面。
若是进行注册业务，先点击注册按钮，然后输入个人注册信息，注册成功后返回登录界面。
该业务流程结束后，用户可以重复输入再次注册登录。
业务约束：
登录注册模块仅支持教师或学生两种角色。例如：在角色下拉菜单选择教师或学生。
本系统中，登录注册功能模块的用例图建模可以参考如下一些图片所示：
