下载文档原格式
用例图百科名片用例图就是由主角、用例以及它们之间的关系构成的图。
该图说明了用例模型中的关系。
简介用例图（User Case）是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
用例图展示了用例之间以及同用例参与者之间是怎样相互联系的。
用例图用于对系统、子系统或类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。
将每个系统中的用户分出工作状态的属性和工作内容，方便建模，防止功能重复和多余的类。
用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部对功能的具体实现。
ps: 提取出“名词”，画用例图构成用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。
参与者参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。
还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。
参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。
用例用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
这是UML对用例的正式定义，对我们初学者可能有点难懂。
我们可以这样去理解，用例是参与者想要系统做的事情。
对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。
用例在画图中用椭圆来表示，椭圆下面附上用例的名称。
系统边界系统边界是用来表示正在建模系统的边界。
边界内表示系统的组成部分，边界外表示系统外部。
系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。
用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。
用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。
用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。
当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。
它将系统功能划分成对参与者（即系统的理想用户）有用的需求。
而交互部分被称作用例。
用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。
用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。
有时，可以将用例的实例引入到图中。
用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。
一．参与者（Actor）1．参与者的概念参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。
参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。
参与着由参与用例时所担当的角色来表示。
在UML中，参与者用名字写在下面的人形图标表示。
每个参与者可以参与一个或多个用例。
它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。
参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。
第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。
命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。
第二类参与者是其它的系统。
⽤例图-包含、扩展、泛化
⽤例图=参与者+⽤例
参与者在图中表⽰为⽕柴⼈⼀样,⼈、物、系统都能分为参与者
⽤例通常使⽤圆形来表⽰.
参与者去使⽤⽤例这个功能
⽤例和⽤例之间的关系有⼏种情况:
包含:⼀个⽤例有时会包含另⼀个⽤例,在图中使⽤虚线和箭头来表⽰
就像是借书->查书,想要借书,就必定要进⾏查书,所以说借书⽤例包含查书
扩展关系:分俩种情况:⼀种是可选,⼀种是特殊.
扩展关系有时候就像if⼀样,当发⽣⼀些情况的时候,或者你想额外做什么的时候,从原实例扩展出⼀个新的实例应对特殊情况或者额外可选操作,则说新 实例是扩展于原实例的.
特殊:扩展关系是被扩展⽤例的⼀种特殊情况,就⽐如扩展⽤例是有时候会发⽣的特殊情况,如迟到和上课,迟到就是由上课扩展的⽤例.
可选:可选的操作,是由原来的实例扩展出来可选的操作,就⽐如取票和打印凭证,
可以说必定发⽣⽤<<include>>(包含),可能发⽣使⽤<<extend>>(扩展)
泛化关系<<generalization>>,⼀般使⽤实现+空三⾓形来表⽰.
泛化⼀般指的就是⼀般和特殊的关系,就像是⽗类和⼦类的关系,如同er图的超类,⼦类是⼀种特殊的⽗类类型
就⽐如缴费⽤例和线上缴费、线下缴费之间,线上缴费和线下缴费就是缴费⽤例的⼦类,由⼦类指向⽗类的<<generalization>>关系. 泛化关系就是描述⽤例的⼀般和特殊关系.。
用例图（User Case）用例图是用来描述什么角色通过某某系统能做什么事情的图，用例图关系的是系统的外在表现，系统与人的交互，系统与其它系统的交互。
下面逐一说明用例图中各种符号的意义：小人：对使用某系统的用户进行分类后，可以总结出使用本系统有哪些角色，不同的角色的工作责任不太一样，他们需要用到的系统的功能也会不太一样。
小人就是角色，它给了我们一个启示，我们思考某系统的需求时，可从不同角色的角度来思考。
例如：我们要做一个考勤系统，你会怎样思考呢？会一下子列出很多功能？比较好的方式，应该是先思考什么人会用这个系统，我们大概可以估计一般员工、高层领导、前台、财务等都会用这个系统，对于一般员工来说除了打卡，他还关注什么？对于前台，她是不是要做一些考勤的统计？而财务是不是要根据考勤情况来调整员工的薪金？这样的思考方式，会让我们更容易全面发掘系统的需求。
还需要特别说明的是：角色可能是人，也可能不是人，而是另外的一个系统，本系统与另外一个系统交互的话，可以将另外一个系统画成某某角色。
圈圈：圈圈里面会有一段动宾结构的文字，也就是“动词+名词”这样的方式，这个圈圈+圈圈里面的文字，就是用例，这些用例表明了系统能做什么事情。
以考勤系统为例：有两个用例叫“打卡”、“查看自己的考勤情况”，这个两个圈圈分别用一条线连到了“一般员工”这个角色，我们可以按这样的顺序来读这个图：先读出角色的名字，然后读出用例中的文字。
按着这样的读法，我们可以得到两句完整的句子：“一般员工打卡”“一般员工查看自己的考勤情况”大家可以用这样的方式来检查自己用例图是否画得合适。
某用例不一定是只属于某个角色的，有不少用例是多个角色“共享”的。
大框框：在所有用例的外面，有一个方框，这个方框只框住了用例，没有框住角色，这个东西就叫做系统边界，框框的上部会注明本系统的名字。
我们所做的系统，是不可能包括角色的，系统要发挥各种作用，要靠各角色“穿越”系统边界来使用本系统的用例。
UML功能模型（⽤例图）在UML系统开发中有三个主要的模型：功能模型（从⽤户⾓度展⽰系统的功能，包括⽤例图）、对象模型（采⽤对象，属性，操作关联等概念展⽰系统的结构和基础，包括类图、对象图、包图）、动态模型（展⽰系统的内部⾏为，包括序列图，活动图，状态图）。
下⾯就说⼀说功能模型——⽤例图。
⽤例图是UML建模的⼀部分，也是UML⾥⾯最基础的部分，最主要的功能就是⽤来表达系统的功能性需求或⾏为。
⽤例图是由软件需求分析到最终实现的第⼀步，它描述⼈们如何使⽤⼀个系统，是尾部参与者所能观察到的系统功能模型图，该图呈现了⼀些参与者和⼀些⽤例，以及它们之间的关系，主要⽤于对系统、⼦系统或类的功能⾏为进⾏建模，⽤画图的⽅法来完成。
⽤例图展⽰了⽤例之间以及⽤例与参与者之间是怎样相互联系的。
⽤例图包含留个元素：参与者、⽤例、关联关系、包含关系、扩展关系、泛化关系。
参与者（Actor）：系统外部的⼀个实体，参与⽤例执⾏过程，通过向系统输⼊或请求系统输⼊某些事件来触发系统的执⾏。
参与者的种类概括为三种：系统⽤户、与所建造的系统交互的其他系统以及⼀些可以运⾏的进程。
注意：参与者表⽰⼈和事物与系统发⽣交互时所扮演的⾓⾊，⽽不是特定的⼈或特定的事物；每个参与者需要⼀个具有业务⼀样的名字；⼀个⼈或事物在与系统交互时，可以同时或不同时扮演多个⾓⾊。
⽤例（Use Case）：⽤例是对⼀个活动者使⽤系统的⼀项功能是所进⾏的交互过程的⼀个⽂字描述序列，是系统、⼦系统或类和尾部参与者交互动作序列的说明，包括可选的动作徐磊嗯哼会出现异常的动作序列。
⽤例是岱庙系统各种各个项⽬相关⼈员之间就系统的⾏为所达成的契约，软件开发过程是⽤例驱动的。
⽤例粒度（规模⼤⼩）。
关联关系（Association）：表⽰参与者⽤例之间进⾏通信包含关系（Include）：客户⽤例可以简单地包含提供者⽤例具有的⾏为，并把他所包含的⽤例⾏为作为⾃⾝⾏为的⼀部分。
调⽤⽤例执⾏到包含点，然后执⾏传递给被调⽤⽤例，当被调⽤⽤例完成时，控制在次返回调⽤⽤例。
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.有头类、⾝体类与⼈类类三个类，则⼈类类中应包含头类及⾝体类这两个属性，则⼈类类与头类和⾝体的关系即为组合关系。
用例图（User Case）用例图是用来描述什么角色通过某某系统能做什么事情的图，用例图关系的是系统的外在表现，系统与人的交互，系统与其它系统的交互。
下面逐一说明用例图中各种符号的意义：小人：对使用某系统的用户进行分类后，可以总结出使用本系统有哪些角色，不同的角色的工作责任不太一样，他们需要用到的系统的功能也会不太一样。
小人就是角色，它给了我们一个启示，我们思考某系统的需求时，可从不同角色的角度来思考。
例如：我们要做一个考勤系统，你会怎样思考呢？会一下子列出很多功能？比较好的方式，应该是先思考什么人会用这个系统，我们大概可以估计一般员工、高层领导、前台、财务等都会用这个系统，对于一般员工来说除了打卡，他还关注什么？对于前台，她是不是要做一些考勤的统计？而财务是不是要根据考勤情况来调整员工的薪金？这样的思考方式，会让我们更容易全面发掘系统的需求。
还需要特别说明的是：角色可能是人，也可能不是人，而是另外的一个系统，本系统与另外一个系统交互的话，可以将另外一个系统画成某某角色。
圈圈：圈圈里面会有一段动宾结构的文字，也就是“动词+名词”这样的方式，这个圈圈+圈圈里面的文字，就是用例，这些用例表明了系统能做什么事情。
以考勤系统为例：有两个用例叫“打卡”、“查看自己的考勤情况”，这个两个圈圈分别用一条线连到了“一般员工”这个角色，我们可以按这样的顺序来读这个图：先读出角色的名字，然后读出用例中的文字。
按着这样的读法，我们可以得到两句完整的句子：“一般员工打卡”“一般员工查看自己的考勤情况”大家可以用这样的方式来检查自己用例图是否画得合适。
某用例不一定是只属于某个角色的，有不少用例是多个角色“共享”的。
大框框：在所有用例的外面，有一个方框，这个方框只框住了用例，没有框住角色，这个东西就叫做系统边界，框框的上部会注明本系统的名字。
我们所做的系统，是不可能包括角色的，系统要发挥各种作用，要靠各角色“穿越”系统边界来使用本系统的用例。
一个关于人事管理的详细用例，希望大家多提意见，多多交流！人事系统用例用例：设置部门（Set Department）角色：人事管理员（Personnel Manager）概述：设置部门用例用于建立维护组织结构，包括建立新部门、删除部门、编辑部门项目相关人员及其兴趣：λ人事管理员：希望能够快捷准确录入、修改、查询λ公司：希望系统能够形象、直观地显示公司部门组织结构，以利于管理和决策前置条件：无后置条件：系统对人事管理员对部门所作修改进行存储成功场景：1. 人事管理员发出“设置部门”请求2. 系统在屏幕上显示组织结构3. 人事管理员使用建立新部门、编辑部门、删除部门对组织结构进行修改4. 重复步骤3、4直到建立起人事管理员预期的组织结构可选场景：1. 建立新部门a. 人事管理员录入部门信息（上级部门、部门编号、部门名称、部门主管、备注）b. 人事管理员提交录入结果c. 系统记录新部门信息扩展场景：b.1人事管理员放弃提交，用例完成。
c.1 部门信息重复c.1.1 系统提示错误，用例完成2. 编辑部门前提条件：部门数据存在a. 人事管理员输入所需编辑的部门标识b. 系统定位并显示部门信息c. 人事管理员编辑部门信息d. 人事管理员提交编辑结果e. 系统更新部门信息扩展场景：b.1 待编辑部门不存在b.1.1 系统提示错误，用例取消d.1人事管理员放弃提交，用例完成e.1 部门信息重复e.1.1 系统提示错误，用例完成3. 删除部门前提条件：部门数据存在a. 人事管理员输入所需删除的部门标识b. 系统定位到相应部门c. 人事管理员删除部门d. 系统删除该部门记录扩展场景：b.1 删除部门不存在b.1.1 系统提示错误信息，用例取消d.1待删除部门拥有下级部门d.1.1 系统提示错误，取消删除操作特殊需求：1. 部门信息不能重复2. 拥有下级部门的部门不能删除3. 可按多种方式显示部门结构（如树形、图表形）用例：设置职位（Set Position）角色：人事管理员（Personnel Manager）概述：设置职位用例用于管理部门职位，包括增加职位、编辑职位、删除职位项目相关人员及其兴趣：λ人事管理员：希望能够快捷准确录入、修改、查询职位信息λ公司：希望系统能够形象、直观地显示公司职位，以利于管理和决策前置条件：部门信息已经设置后置条件：系统记录人事管理员对职位进行的修改成功场景：1. 人事管理员发出“设置职位”请求2. 系统显示职位表3. 人事管理员使用增加职位、编辑职位、删除职位对职位表进行修改4. 重复步骤3、4直到建立起人事管理员预期的组织结构可选场景：1. 增加职位a.人事管理员录入职位信息（职位编号、部门编号、职位名称、备注）b.人事管理员提交录入结果c.系统记录新职位信息扩展场景：b.1人事管理员放弃提交，用例完成。
c.1 职位信息重复c.1.1 系统提示错误，用例完成2. 编辑职位前提条件：待编辑职位数据存在a. 人事管理员输入所需编辑的职位标识b. 系统定位并显示职位信息c. 人事管理员编辑职位信息d. 人事管理员提交编辑结果e. 系统更新职位信息扩展场景：d.1人事管理员放弃提交，用例完成e.1 职位信息重复e.1.1 系统提示错误，用例完成3. 删除职位前提条件：职位数据存在a. 人事管理员输入所需删除的职位标识b. 系统定位到相应职位c. 人事管理员删除职位d. 系统删除该职位记录扩展场景：d.1待删除职位已经使用d.1.1 系统提示错误，取消删除操作特殊需求：1. 职位信息不能重复2. 已经使用的不能删除用例：管理人员（Manage Personnel）角色：人事管理员（Personnel Manager）概述：管理人员用例用于对公司员工信息进行维护及调动员工职位，包括增加人员、编辑人员信息、删除人员、查询人员信息和调动职位、制作人事报表项目相关人员及其兴趣：λ人事管理员：希望通过系统准确，快捷地完成人员信息的维护；系统能提供指定格式报表λ公司：希望系统保证人员信息的准确性；从多视角展示人员信息，为合理分配人力资源提供信息λ员工：希望系统保证自身信息的准确性；能方便维护，更新自身信息前置条件：部门信息、职位信息设置完成后置条件：成功场景：1．人事管理员发出管理人员信息请求2．系统在屏幕上显示人员信息3．人事管理员使用增加人员、删除人员、编辑人员信息对人员信息进行修改4．重复步骤3、4直到人事管理员预期的维护操作结束5．在2以后任何时候都可以调用查询人员信息、制作人事报表（可选场景）。
扩展场景：特殊需求：1. 人员信息不能重复2. 人员信息包括照片信息3. 增加、编辑人员信息时必须符合相应信息规则（名字不能为空）用例：增加人员（Add Personnel）角色：人事管理员（Personnel Manager）概述：增加新人员的信息项目相关人员及其兴趣：λ人事管理员：希望通过系统能快捷、准确地录入新人员信息公司：希望能准确记录人员信息λλ员工：希望能准确记录自身信息前置条件：后置条件：增加人员信息成功场景：1. 人事管理员发出“增加人员”请求2. 人事管理员录入人员信息3. 人事管理员提交人员信息4. 系统保存人员信息扩展场景：3.1 人事管理员放弃提交4.1 人员信息重复4.1.1 系统提示错误，放弃保存特殊需求：1. 人员信息不能重复用例：删除人员（Delete Personnel）角色：人事管理员（Personnel Manager）概述：删除人员信息项目相关人员及其兴趣：λ人事管理员：希望系统能准确快速的定位待删除人员信息，能提示以防止误操作公司：希望避免误删除λλ员工：希望避免误删除前置条件：员工信息必须存在后置条件：成功删除员工信息成功场景：1.人事管理人员输入待删除人员标识2.系统定位到待删除人员3.人事管理员确认删除4.系统删除人员信息扩展场景：2.1没有找到待删除人员2.1.1系统提示错误信息，用例结束3.1取消删除操作特殊需求：1.待删除人员与其他信息有特殊关联的不能删除（欠款、计划未完成等）用例：编辑人员信息（Delete Personnel Information）角色：人事管理员（Personnel Manager）概述：维护人员信息项目相关人员及其兴趣：λ人事管理员：希望系统能准确快速的定位和编辑待编辑人员信息；公司：希望人员信息准确λλ员工：希望人员信息准确前置条件：存在员工信息后置条件：正确维护人员信息成功场景：1．人事管理员输入待编辑人员标识2．系统定位到待编辑人员3．人事管理员编辑人员信息4．人事管理员提交编辑结果5．系统保存编辑记录扩展场景：3.1 待编辑人员信息不存在2.1.1系统提示错误，用例结束4.1 人事管理员取消提交特殊需求：1．一些特殊项目信息限制修改（工资，奖金）？用例：查询人员信息（Query Personnel Information）角色：人事管理员（Personnel Manager）、员工（Personnel）概述：根据相关条件查找人员信息项目相关人员及其兴趣：λ人事管理员，员工：希望系统快速、准确的查找出符合条件的人员信息前置条件：存在员工信息后置条件：查找出符合条件的人员信息成功场景：1．系统使用者输入查询条件2．系统查找并显示符合条件的人员信息扩展场景：特殊需求：1．输入查询条件合法2．当无符合条件人员时，系统给出提示用例：生成人员报表（Create Personnel Report）角色：人事管理员（Personnel Manager）概述：根据要求生成出指定内容、格式的报表项目相关人员及其兴趣：λ人事管理员，其他报表需求者：希望系统能按指定格式、内容，准确、快捷地制作出报表前置条件：存在人员信息；人员报表模板列表不为空后置条件：生成出指定内容、格式的报表成功场景：1. 人事管理员发出“生成人员报表”请求2. 系统显示人员报表模板列表3. 人事管理员选择报表模板4. 系统提示相应查询条件5. 人事管理员输入查询条件并请求系统查询6. 系统生成并显示指定格式、内容的报表“可选”场景：7.1人事管理员请求保存报表7.2人事管理员请求打印报表特殊需求：用例：调动职位(Redeploy Position)角色：人事管理员(Personnel Manager)概述：调动职位用于对人员职位进行调整。
项目相关人员及其兴趣：λ人事管理员：希望系统能快速准确时进行调动职位公司：希望系统能对调动操作进行记录λλ员工：希望系统能准确调动职位前置条件：人员信息、职位信息存在后置条件：将修改的员工职位存储，并记录调动记录成功场景：1. 人事管理员录入待调动职位人员标识2. 系统查找定位并显示人员职位信息3. 人事管理员录入员工新职位4. 系统对人员进行更新职位，并记录调动记录5. 在2以后，可以进行“分配职位”、“撤销职位”可选场景可选场景：1. 分配职位前置条件：待分配职位人员没有设置职位a.人事管理员录入人员新职位b.系统对人员进行分配职位，并记录调动记录2. 撤销职位前置条件：待分配职位人员已经设置职位a.系统撤销人员职位，职位设置为空，并记录调动记录扩展场景：2.1 没有找到人员2.1.1 系统提示错误，用例取消特殊需求：用例的用途是在不揭示系统内部构造的情况下定义联贯的行为。
用例描述了系统具有的行为，但是没有规定怎样实现这些行为，它是从用户的角度来看系统的特定方式。
…账户登陆‟是操作包的其中一个用例。
因其属于网络游戏最基本的功能，所以选取它来说明开发过程。
步骤1：描述用例及其事件流用例描述：注册用户在官方网站帐户登陆页面上输入ID和密码登陆管理个人帐户。
主事件流：1．用户点击主页上的登陆按钮，开始用例。
2．系统显示登陆页面。
3．用户输入ID和密码，然后点击登陆。
4．系统验证登陆信息和数据库一致，然后回到主页。
5．用例结束。
其他事件流A1：如果用户点击登陆页面上的提示词按钮，系统在一个单独的对话框里显示为用户储存的提示词，用户点击确定按钮，系统页面回到登陆页。
其他事件流A2：如果用户输入了一个系统无法识别的ID，系统显示错误信息并提示用户输入一个不同的ID。
其他事件流A3：如果用户输入了一个不正确的密码，系统显示错误信息并提示用户输入正确的密码。
其他事件流A4：如果用户连续3次输入错误的密码，系统显示消息告诉用户无法再连接服务器，并且冻结登陆页。
步骤2：建立对象交互图交互图描述了系统的动态行为。
绘制对象交互图，首先是确定该用例所涉及的对象。
从用例说明中可以分析出包括Player、主页、登陆页、提示对话框、帐户记录这几个对象，对象之间通过发送消息进行交互。
下面就是“登陆帐户”的顺序图，它其实是一张表，X轴上排列着对象，Y轴上按时间顺序排列着对象之间发送的消息，最左边标明了消息所属的事件流。
