大型bbs论坛用例图

论坛用例图

QQ 功能模型分析：

QQ业务模型分析：

步骤1：制作QQ注册操作流程。将QQ新用户录入的信息存入数据库，并提供一个新的QQ 给用户。录入信息中，分必填信息和选填信息。

步骤2：制作QQ好友添加流程。QQ注册之后要添加好友，分条件查询和模糊查询，并提供查看个人资料和添加成为好友的功能。

步骤3：制作QQ邮箱开通流程。QQ注册之后一般用户都会启用邮箱，所以，简化QQ邮箱开通流程。

步骤4：制作QQ空间开通流程。QQ注册完后，一般还会开通空间，以便了解好友的最近心情、动态，所以也要简化开通流程。开通后，在空间动态上显示开通，以便好友知道。步骤5：制作QQ安全密保设置流程。QQ开通后，为防止被盗，需要QQ用户设置密保，以便QQ密码丢失，或者QQ号被盗时能够找回。系统将用户录入的密保录入数据库，等到用户验证密保通过时，提醒用户输入新密码，并把新密码录入数据库。

步骤6：制作QQ废弃回收流程。有些用户会因为某些原因放弃使用QQ，而这些QQ会占用数据库空间。为有效利用QQ号码，如果用户数个月没有登录QQ，系统清除QQ号码的所有信息，回收到数据库中备用。

QQ数据模型：

用例图画法

说明：rose中创建边界类的方法： 1.右击logic view，选择“new”--“package”。新建一个文件夹“边界类”。 2.右击“边界类”文件夹，选择“new”--“class”。新建类。 3.为新建的类定义类名，然后右击该类选择“Open Specification”，或者直接双击该类。 4.在打开的窗口中，在“Stereotype”中选择“boundary”，标识该类为边界类。

5.如果是定义控制类，就设置Stereotype的值为control，如果是定义实体类，就设置Stereotype的值为entity。 2.顺序图图1 UC02选择课程用例的顺序图文档中蓝色及红色文字及图片，是与rose操作有关的介绍。在整理文档是务必要删除。说明：顺序图的画法： 1.在Logic View下新建文件夹命名为“顺序图”。 2.右击“顺序图”文件夹，选择new--Sequence Diagram

3.将新建的顺序图使用“用例编号和名称”命名。 4.双击打开该顺序图。 5.根据用例描述，确定参与用例的参与者、边界类、控制类以及使用到的实体类，并将上述对象从左侧模型树中找到，鼠标左键点中，拖到右侧主图版中。注意顺序图中各对象的顺序从左到右为参与者、边界类、控制类以及实体类。比如“UC03 退选课程”的参与对象如下： 5.根据用例描述中的主事件流，开始画顺序图中的消息。 UC03 退选课程主事件流如下： 1）学生查看已选课程。在图中，先在中间工具栏上单击Object Message，然后将鼠标移至画图板。单击“学生”后不要松开左键，向“WithdrawalForm”拖动，到达该对象后松开左键，就建立了学生到界面对象的一条消息。右击该消息，选择“new operation”

用例图含义及画法

用例图的含义及画法用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。它将系统功能划分成对参与者（即系统的理想用户）有用的需求。而交互部分被称作用例。用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。有时，可以将用例的实例引入到图中。用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。一．参与者（Actor） 1．参与者的概念参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。参与着由参与用例时所担当的角色来表示。在UML中，参与者用名字写在下面的人形图标表示。每个参与者可以参与一个或多个用例。它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。

用例图和用例模型

用例图和用例模型用例图用来描述用户的需求，它从用户的角度描述系统的功能，并指出各功能的执行者，强调谁在使用系统，系统为执行者完成哪些功能。用例图概述 UML用例图是软件产品外部特性描述的视图，它从用户的角度而不是开发者的角度来描述软件产品的需求，分析软件产品所需的功能和行为。用例图主要描述了系统需要实现的功能，而忽略系统是如何实现这些功能的。用例模型由用例图组成，它是系统用例图的集合，是对系统从宏观角度的确定描述。用例模型主要用于需求分析阶段，该模型是系统开发者和系统使用者反复讨论的结果，表明了系统开发者和系统使用者对需求规格达成的共识。首先，用例模型描述了待开发系统的功能需求；其次，用例模型将系统看作黑盒，仅从外部执行者的角度来理解系统；再次，用例模型驱动了需求分析之后各阶段的开发工作，影响到开发工作的各个阶段和UML的各个模型。一、用例图元素用例图主要用于定义系统的功能需求，它描述了系统的参与者与系统提供的用例之间的关系。用例图由以下几种元素组成：执行者、用例、关系、用例描述（1）执行者执行者（Actor）是系统的外部用户，它是与系统相关联的人或其它系统，可以是普通用户、外部硬件、其他系统。

在进行用例图绘制时，首先要找出系统的执行者。一般可以从以下几个方面来考虑怎样找到系统的执行者： ?谁使用系统的功能。 ?谁向系统提供必要的信息。 ?谁从系统获取信息。 ?谁维护、管理系统工作。 ?系统需要使用哪些外部资源。 ?需要与系统交互的其它系统有哪些。 ?其他对系统产生的结果感兴趣的人或事物。（2）用例用例是指系统中的一个功能单元，也可以将用例理解为系统功能的分解。用例的表示方法如下：（3）关系（1）关联在用例图中，用例和执行者之间的关系用一条连接二者带箭头的连线表示，如图所示，该连线称为关联。它表示了一个执行者和一个用例之间的关系。在用例图中，关联关系只用在执行者和用例之间，用例和用例之间不会存在关联关系。关联关系采用的是单箭头的连线，表示在该关联中执行者是主动的，是执行者启动的用例。如下图所示。

图书管理系统用例图

图书管理系统 UML建模与设计模式实验报告计算机与信息工程学院一、实验目的在熟悉用例概念与应用的基础上，掌握用例模型的建立，包括： 1．掌握用例图的建立。 2．掌握用例描述文档的编写。 3．掌握建模工具的使用。二、实验内容根据以下需求设计一个图书馆管理系统的用例图模型，包括：用例图和主要用例的描述文档。基本功能要求：图书管理：新书登记，图书查询，图书注销；借阅管理：借书，还书，查询今日到期读者；读者管理：增加读者、删除读者、查询读者、读者类别管理（可以设置不同类的读者，并使不同类读者对应不同类的图书流通参数，如可借册数，可借天数，可续借次数，可续借天数等）；报表管理：包括图书借阅统计报表，被注销图书统计报表等；报表可以有多种格式可供选择；可以把报表输出到文件中，可以预览报表、打印报表等。系统管理：系统管理员使用，包括用户权限管理（增加用户，删除用户，密码修改等），数据管理（提供数据修改、备份、恢复等多种数据维护工具），系统运行日志，系统设置等功能。三、实验思想（1）分析系统需求；（2）确定系统参与者：读者、图书管理员、图书管理系统；（3）确定系统用例；

四、实验结果借阅人用例图：图书系统管理员用例图：

图书管理员用例图： 1．用例名称：登录用例描述：根据用户输入的用户名和密码判断用户的身份，赋予相应的权限。前置条件：无后置条件：根据用户所有的权限进入相应的操作界面。基本操作流程： 1输入用户名 2输入密码 2校验密码是否正确。 3根据用户身份进入相应的操作界面。可选流程：如果密码不正确，提示重新输入密码；如果用户名不正确，提示没有此用户。 2.用例名称：查询图书用例描述：由读者进行操作，查询图书馆中有没有需要图书，如果有，显示该图书编号、书名、作者、出版日期、当前借阅状态等信息。前置条件：以顾客身份登录后置条件：无基本流程： 1 以读者身份登录。 2输入图书的名称或作者名称。

图书管理系统用例图

类的读者，并使不同类读者对应不同类的图书流通参数，如可借册数，可借天数，可续借次数，可续借天数等）；报表管理：包括图书借阅统计报表，被注销图书统计报表等；报表可以有多种格式可供选择；可以把报表输出到文件中，可以预览报表、打印报表等。系统管理：系统管理员使用，包括用户权限管理（增加用户，删除用户，密码修改等），数据管理（提供数据修改、备份、恢复等多种数据维护工具），系统运行日志，系统设置等功能。三、实验思想（1）分析系统需求；（2）确定系统参与者：读者、图书管理员、图书管理系统；（3）确定系统用例；四、实验结果借阅人用例图：

图书系统管理员用例图：图书管理员用例图：

用例图和用例描述设计实例

用例图和用例描述设计实例作者：ephyer 发表时间： 2004-09-09 18:01:35 更新时间： 2004-09-09 18:01:35 浏览：1954次主题：电脑技术评论：0篇地址：202.19 7.75.* :::栏目::: ? T hinkin g in jav a 学习笔记 ? J A VA 基础知识 ? U ML ? 软件设计师 ? 其他类别这里用我开发的一个家教网站来简单的分析用例图的画法和用例描述的写法。这个网站我用UML 完整的分析一下，以下我提取了用例图和用例描述的部分。这个家教网站分为前台客户系统和后台管理系统。前台客户系统的用例图如下：后台管理系统用例图如下：对于用例描述，篇幅有限，我在这里只列了后台管理系统中的网站公告发布这个用例的描述。如下：

用例名称：用户登录用例标识号：01 参与者：管理员、普通用户简要说明：参与者输入用户名、密码以及验证码，系统进行验证后，合法者登录系统，否则提供拒绝登录系统。前置条件：参与者已经打开系统的登录页面（login.jsp）基本事件流： 1．参与者在用户名输入框里输入用户名 2．在密码框里输入密码 3．密码框下方显示验证码，验证码由4位数字构成，用户按原样输入验证码。 4．用户按登录后，系统验证参与者输入的有效性。 5．有效则进入系统的主界面。无效则提示相应错误给用户。 6．用例终止其他事件流A1：在按“登录”按钮之前，参与者可以随按“取消（或关闭）”按钮。异常事件流： 1．提示错误信息，参与人确认后置条件：进入的主界面main.jsp ,装载相应的数据注释：（可选：记住用户）

我们应当怎样做需求分析：功能角色分析与用例图

我们应当怎样做需求分析：功能角色分析与用例图(转) 在我们进行一系列需求调研工作的同时，我们的需求分析工作也开始启动了。需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司，我们就应当对需求调研的成果进行一次需求分析。当下一次开始进行需求调研时，我们应当首先将上次需求分析的结果与客户进行确认，同时对需求分析中提出的疑问交给客户予以解答。这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。但是，当我们经过一番忙碌，将需求中的第一手资料从调研现场捕获回来以后，我们应当怎样进行分析呢？不少团队对此都比较迷茫，没有一个统一和有效的方法，往往采用想到哪里做到哪里的方式。一些问题想到了就做了，没有想到则忽略掉了。实际上，需求分析不应当是太公钓鱼，而应当是拉网排查。任何一个疏忽都可能对项目研发带来风险。因此，我们应当采用一套成熟而完整的分析方法，稳步而有序地完成这部分工作。不同类型的软件项目其分析方法可能存在差异，但一般来说，信息化管理类软件项目通常从这几个方面着手分析：功能角色分析、业务流程分析与业务领域分析。需求分析不是一项一蹴而就就可以完成的工作，它需要一个长期的过程，而这个过程是一个由粗到细的过程，它体现了人类认识事物的客观规律。在需求分析的初期，我们对需求的认识往往是整体的、宏观的，随着分析工作的逐渐深入，一步步细化。按照这个思路，我们对需求的分析，首先应当从功能角色分析开始。所谓功能角色分析，就是从一个外部用户的视角分析整个软件系统能够提供的功能，以及这些功能到底是提供给哪些角色使用。对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。用例图是UML的4+1视图中的一种，准确地说就是那个“+1”。用例图是贯穿整个面向对象分析/设计（OOA/D）的核心视图，它描述的是系统到底为用户提供了哪些功能，以及到底是哪些用户在使用这些功能，是沟通用户与技术人员的桥梁。运用用例视图对业务需求进行分析、抽象、整理、提炼，进而形成抽象模型的过程称之为用例建模，而这个模型就是用例模型。一般地，在一个用例图中通常有三种元素：参与者（Actor）、用例（Use Case）与系统边界（Boundary）。用例描述的是系统为用户提供的功能，也就是系统能为用户做什么，通常被绘制成一个椭圆；参与者，我认为称为角色更加合适，也就是系统为哪些类型的用户提供服务，他们都各自承担哪些不同的职责，通常被绘制成一个小人儿；最后是系统边界，也就是系统是对现实世界哪个范围的内容进行的模拟，它涉及到软件设计的工作范围与工作量，通常被绘制成一个方框。但是，通常情况下系统边界只是一个概念而不用真正绘制出来，因为被绘制成用例的必然是系统内部的功能，被绘制成参与者的必然是系统外部事物。从这个意义上讲，用例图中的参与者不仅包括人，还包括那些外部系统和自动触发器。根据这样一个思路，我以往常常将外部系统和自动触发器绘制成一个小人，这常常令客户感到困惑。随后我改变了思路，将外部系统和自动触发器绘制成另一种表达形式——类元符号表示法，并在构造型上标注为Actor。

1 用例图建模步骤

用例图建模步骤窗口说明 1.开始用例图在用例视图目录下，使用右键菜单“new”——》“use case diagram”。 2.工具栏调整一般情况下，所有UML模型的工具栏都是可以调整的，可以根据具体需要对工具栏上的按钮进行定制。在工具栏上使用右键菜单，选择“Customize”如图2，选择需要增加或减少的图标，如图3所示。

3.增加参与者参与者的增加有2种方式，方式一：使用工具栏上的快捷菜单如图4，图5所示方式二：使用左边栏右键菜单“new”——》“Actor”新增参与者功能如图6所示，需要注意的是：使用此方式增加的参与者将不会自动出现在右边的绘图区中，需要把这个参与者拖到绘图区方可。

关于删除：在右边的绘图区，删除参与者可以使用Del键删除，但删除之后被删除的参与者在左边的目录下仍然是存在的。即在绘图区中不能彻底的删除参与者。在左边的目录区，4.增加用例用例增加的方式和方法与参与者增加的方式和方法是相同的。 5.建立参与者之间的关系参与者之间的关系常见的是泛化关系。步骤如下： 1）选择泛化关系，如图7所示。 2）如图8所示，画出两个参与者之间的泛化关系。注意：起点是继承类，终点是被继承类。即，画的时候是从儿子开始，到父亲结束。 6.建立用例之间的关系用例之间的关系主要是3种，分别是包含（include），扩展（extend）和泛化（generalization）。我们只要熟悉一种建立方式，其他2种都可以采用同样的步骤实现。建立包含关系步骤如下：

1）如图9所示，选择用例关系的图标。 2）如图10所示，从“登陆系统”用例开始，到“密码验证”用例结束画出关联关系，注意箭头的方向。 3）双击这条线或者右键点击这条线然后选择“Open Specification”菜单项（图11所示），在弹出的窗口（图12）的Stereotype中选择包含（include）关系结果如图13，图14所示

UML用例图总结

UML用例图用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。 1、包含(include) 包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

UML用例图的画法

一．UML简介 UML（统一建模语言，Unified Modeling Language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。其实简单的理解，也是个人的理解，UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。二．用例建模简介用例建模是UML建模的一部分，它也是UML里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求或行为。依我的理解用例建模可分为用例图和用例描述。用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。用例描述用来详细描述用例图中每个用例，用文本文档来完成。 1．用例图参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是UML对用例的正式定义，对我们初学者可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。

图书管理系统用例图(完整资料).doc

【最新整理，下载后即可编辑】图书管理系统 UML建模与设计模式实验报告计算机与信息工程学院一、实验目的在熟悉用例概念与应用的基础上，掌握用例模型的建立，包括： 1．掌握用例图的建立。 2．掌握用例描述文档的编写。 3．掌握建模工具的使用。二、实验内容根据以下需求设计一个图书馆管理系统的用例图模型，包括：用例图和主要用例的描述文档。基本功能要求：图书管理：新书登记，图书查询，图书注销；借阅管理：借书，还书，查询今日到期读者；读者管理：增加读者、删除读者、查询读者、读者类别管理（可以设置不同类的读者，并使不同类读者对应不同类的图书流通参数，如可借册数，可借天数，可续借次数，可续借天数等）；报表管理：包括图书借阅统计报表，被注销图书统计报表等；报表可以有多种格式可供选择；可以把报表输出到文件中，可以预览报表、打印报表等。系统管理：系统管理员使用，包括用户权限管理（增加用户，删除用户，密码修改等），数据管理（提供数据修改、备份、恢复等多种数据维护工具），系统运行日志，系统设置等功能。三、实验思想

（1）分析系统需求；（2）确定系统参与者：读者、图书管理员、图书管理系统；（3）确定系统用例；四、实验结果借阅人用例图：图书系统管理员用例图：

图书管理员用例图：

1．用例名称：登录用例描述：根据用户输入的用户名和密码判断用户的身份，赋予相应的权限。前置条件：无后置条件：根据用户所有的权限进入相应的操作界面。基本操作流程： 1输入用户名 2输入密码 2校验密码是否正确。 3根据用户身份进入相应的操作界面。可选流程：如果密码不正确，提示重新输入密码；如果用户名不正确，提示没有此用户。 2.用例名称：查询图书用例描述：由读者进行操作，查询图书馆中有没有需要图书，如果有，显示该图书编号、书名、作者、出版日期、当前借阅状态等信息。前置条件：以顾客身份登录后置条件：无基本流程： 1 以读者身份登录。 2输入图书的名称或作者名称。 3显示相关图书的信息。可选流程：如果没有该图书，返回提示信息：“没有找到图书”。3．用例名称：借书用例描述：由图书管理员把读者的借书卡的条码读入计算机，再将读者所选图书的条码读入计算机，在不超过读者允许借书的情况下，累计该读者所借的书；否则提示超过借书数量。前置条件：以图书管理员的身份登录系统。后置条件：图书信息中相应记录的还书日期值做改变；将借书明细加入借书记录中。

点名系统用例图及用例规约

点名系统项目背景在高校的教学管理中，点名也是很普通的事情，学生的出勤情况，以及平时上课是回答问题的情况，都要有记录，以作为学生的平时成绩，在期末考评的时候是一项重要指标，利用计算机辅助，做出一个点名系统的程序，将老师上课时需要用到的程序都做出来，将给老师上课及平时给学生评分带来方便。我国高校都实行了学分制，平时成绩作为一项重要参考被录入期末考试中，这样子即使学生一次考试失误也不会造成学生的的得分不公平。在这里，学生上课时的制约因素比较复杂，记录学生平时成绩的工作量也很大，而且往往期末考试时再计算学生的平时成绩，需要的时间也比较多。运用计算机辅助上课点名及记录平时上课的出勤情况还有回答问题的情况，即能实时地对大量学生平时成绩的数据进行检验和统计，十分方便地输出平时结果，同时也避免了人工处理时容易产生的错误。利用计算机辅助进行上课点名工作，既提高了点名的科学性，又可大大减轻管理老师统计的工作强度，提高工作效率，从而使学校教务管理现代化迈上了一个新台阶。系统建模需求模型建立一个模型 ,需求分析是第一步 ,首先对点名系统系统需求进行分析 ,识别系统的用户和相关外部系统 ,以确定系统的角色,它可以帮助界定软件系统的边界 ,引导和发掘用户需求;其次再依据系统功能来确立系统的用例模型。功能需求分析本系统的需求分析说明大致如下:登录系统、点名子系统、成绩统计、报表打印等;系统管理员输入相应信息，权限分配;任课教师可以录入成绩、修改成绩、学分统计、查询成绩、报表打印等;学生查询本人成绩、学分统计。系统的角色可以分为3个: 系统管理员、任课教师、学生。三种不同的用户所具有的操作权限以及操作内容均不一样。系统管理员只负责向系统中添加学生和教师的个人信息以及班级课程信息。系统管理员不参与点名记分过程等，一切由教师上课自行完成。教师用户登录系统后可以输入上课信息和点名方式，从而选择学生名单，然后点名或者提问，给与分数，记录成绩，还可以查询查询自己学生的平时成绩情况。对于学生用户，每个学生登录系统不能对自己及同学的出勤及答题成绩信息进行修改，只能查看。

用例图元素之间的关系.doc

用例图元素之间的关系.doc 用例图元素之间的关系用例图中包含的元素除了系统边界、角色和用例，另外就是关系。包括:角色之间的关系、用例之间的关系、用例和角色之间的关系。角色之间的关系由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。用例之间的关系: (1)包含关系:基本用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中箭头的方向是从基本用例到包含用例。

简单的理解就是用例可以包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分。 (2)泛化关系:代表一般于特殊的关系。它的意思和面向对象程序设计中的继承的概念是类似的。不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。泛化(Generalization)在面向对象的技术中无处不在，下图给出了一个使用泛化的用例图:

在用例图中，角色和用例都能够泛化。角色的泛化/继承很容易理解，因为角色本来就是类(Class)，它是一种版型(stereotype)为Actor的类，所以角色的继承直观而自然。但是用例的继承实际上分为两种情况，并不是简单的使用泛化，而是使用扩展(extended)和包含(include)两种泛化的特例。扩展用于子用例的动作步骤基本上和父用例的动作步骤相同，只是增加了另外的一些步骤的情况下。包含用于子用例包含了所有父用例的动作，它将父用例作为了自己的一个大步骤，子用例常常包含一个以上的父用例。 (3)扩展关系: 扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。与包含关系一样，扩展关系也是依赖关系的版型。在扩展关系中，箭头的方向是从扩展用例到基本用例，这与包含关系是不同的。它是以隐含形式插入的，也就是说，扩展用例并不在基本用例中显示。在以下几种情况下，可使用扩展用例: a.表明用例的某一部分是可选的系统行为(这样，您就可以将模型中的可选行为和必选行为分开); b.表明只在特定条件(如例外条件)下才执行的分支流;