第一篇：用例分析总结
用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。
当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。它将系统功能划分成对参与者（即系统的理想用户）有用的需求。而交互部分被称作用例。用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。
用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。有时，可以将用例的实例引入到图中。用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。
一．参与者（Actor）1．参与者的概念
参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。参与着由参与用例时所担当的角色来表示。在UML中，参与者用名字写在下面的人形图标表示。
每个参与者可以参与一个或多个用例。它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。
第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。
第二类参与者是其它的系统。这类位于程序边界之外的系统也是参与者。第三了参与者是一些可以运行的进程，如时间。当经过一定的时间触发系统中的某个事件时，时间就成了参与者。２．确定参与者
在获取用例前首先要确定系统的参与者，开发人员可以通过回答以下的问题来寻找系统的参与者。
（1）谁将使用该系统的主要功能。
（2）谁将需要该系统的支持以完成其工作。
（3）谁将需要维护、管理该系统，以及保持该系统处于工作状态。（4）系统需要处理哪些硬件设备。（5）与该系统那个交互的是什么系统。
（6）谁或什么系统对本系统产生的结果感兴趣。
在对参与者建模的过程中，开发人员必须要牢记以下几点。
（1）参与者对于系统而言总是外部的，因此它们可以处于人的控制之外。
（2）参与者可以直接或间接的与系统交互，或使用系统提供的服务以完成某件事务。（3）参与者表示人和事物与系统发生交户时所扮演的角色，而不是特定的人或者特定的事物。
（4）每个参与者需要一个具有业务一样的名字，在建模中不推荐使用类似“新参与者”的名字。
（5）每一个参与者要必须有简短的描述，从业务角度描述参与者是什么。
（6）一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色。
（7）和类一样，参与者可以具有表示参与者的属性和可以接受的事件，但使用的不频繁。３．参与者之间的关系
因为参与者是类，所以多个参与者之间可以具有与类相同的关系。在用例视图中，使用了泛化关系来描述多个参与者之间的公共行为。如果系统中存在几个参与者，它们既扮演自身的角色，同时也扮演更具一般化的角色，那么就用泛化关系来描述它们。这种情况往往发生在一般角色的行为在参与者超类中描述的场合。特殊化的参与者继承了该超类的行为，然后在某些方面扩展了此行为。参与者之间的泛化关系用一个三角箭头来表示，指向扮演一般角色的超类。这与UML中类之间的返还关系符号相同。
二用例（Use Case）1．用例的概念
用例是外部可见的系统功能单元，这些系统功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。用例的用途是，在不揭示系统内部构造的前提下定义连贯的行为。
用例的定义包含它所必须的所有行为——执行用例的主线次序、标准行为的不同变形、一般行为下的所有异常情况及其预期反应。从用户的角度来看，上述情况很可能是异常情况；从系统的角度来看，它们是必须被描述和处理的附加情况。更确切地说，用例不是需求或功能的规格说明，但是也展示和体现其所描述的过程中的需求情况。在UML中，用例用一个椭圆表示。
在模型中，每个用例的执行都独立与其它用例，尽管在执行一个用例时由于用例之间共享对象的原因可能会在用例之间产生隐含的依赖关系。每个用例都表示一个纵向的功能块，这个功能块的执行会和其它用例的执行混合在一起。
用例的动态执行过程可以用UML的交互来说明，可用用状态图、时序图、协作图或非正式的文字描述来表示。用例功能的执行通过系统中类之间的协作来实现。一个类可以参与多个协作，因此也参与了多个用例。在系统层，用例表示整个系统对外部用户可见的行为。一个用例就像外部用户可以使用的系统操作。但是，它不又与操作不同，用例可以在执行过程中持续接受参与者的输入消息。用例也可以被像子系统和独立类这样的系统小单元所应用。一个内部用例表示了系统的一部分对其它部分呈现出的行为。例如，某个类的用例表示了一个连贯的功能块，这个功能块是该类提供给系统内其它有特定作用的类的。一个类可以有多个用例。２．识别用例
用例图对整个系统建模过程非常重要，在绘制系统用例图前，还有许多工作要做。系统分析者必须分析系统的参与者和用例，他们分别描述了“谁来做”和“做什么”这两个问题。
识别用例最好的方法就是从分析系统的参与者开始，考虑每一个参与者是如何使用系统的。使用这种策略的过程中可能会发现新的参与者，这对完善整个系统的建模有很大的帮助。用例建模的过程是一个迭代和逐步精华的过程，系统分析者首先从用例的名称开始，然后添加用例的细节信息。这些信息由简短的描述组成，它们被精华成完整的规格说明。在识别用例的过程中，通过回答以下几个问题，系统分析者可以获得帮助。
（1）特定参与者希望系统提供什么功能。
（2）系统是否存储和检索信息，如果是，由哪个参与者触发。（3）当系统改变状态时，是否通知参与者。（4）是否存在影响系统的外部事件。（5）哪个参与者通知系统这些事件。３．用例与事件流
用例分析处于系统的需求分析阶段，这个阶段应该尽量避免考虑系统实现的细节问题。但是要实际建立系统，则需要更加具体的细节，这些细节写在事件流文件中。事件流的目的是为用例的逻辑流程建立文档，这个文档详细描述系统用户的工作和系统本身的工作。
虽说事件流很详细，但其仍然是独立于实现的方法的。换句话说，事件流描述的是一个系统“做什么”而不是“怎么做”。事件流通常包括：简要说明、前提条件、主事件流、其它事件流和事后事件流。（1）简要说明。每个用例应当有一个相关的说明，描述该用例的作用，说明应当简明扼要，但应包括执行用例的不同类型的用户和通过这个用例要达到的结果。
（2）前提条件。用例的前提条件列出用例之间必须满足的条件。例如，前提条件是另一个用例已经执行或用户具有运行当前用例的权限。但并不是所有用例都有前提条件。
（3）主事件流和其它事件流。用例的具体细节在主事件流和其它事件流中描述。事件流是从用户角度描述执行用例的具体步骤，关注系统“做什么”，而不是“怎么做”。主事件流和其它事件流包括：用例如何开始和结束、用例如何与参与者交互、用例的正常流程（主流程）、用例主事件流（其它事件流）的变体和错误流。
（4）事后条件。事后条件是用例执行完毕后必须为真的条件。例如，可以在用例完成之后设置一个标识，这种信息就是事后条件。与前提条件一样，事后条件可以增加用例次序方面的信息，如果要求一个用例执行完后必须执行另一个用，那么就可以在事后条件中说明这一点。当然，并不是每个用例中都有事后条件。三用例间的关系
用例除了与参与者发生关系外，还可以具有系统中的多个关系，这些关系包括包含关系、扩展关系和泛化关系。应用这些关系的目的是为了从系统中抽取出公共行为和其变体。1．关联关系（Association）
关联关系描述参与者与用例之间的关系，它是用于表示类的挂系的关联元类的实例。在UML中，关联关系用箭头来表示。
关联关系表示参与者与用例之间的通信。不同的参与者可以访问相同的用例，一般说来它们和该用例的交互是不一样的，如果一样的话，说明它们的角色可能是相同的。如果两中交互的目的也相同，说明它们的角色是相同的，就可以将它们合并。
２．包含关系（Include）
虽然每个用例的实例都是独立的，但是一个用例可以用其它的更简单的用例来描述。这有点像通过继承父类并增加附加描述来定义一个类。一个用例可以简单地包含其它用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作包含关系。在这种情况下，新用例不是初始用例的一个特殊例子，并且不能被初始用例所代替。爱UML中，包含关系表示为虚线箭头交<
包含关系使一个用例的功能可以在另一个用例中使用，如下所述。（1）如果两个以上用例有大量一致的功能，则可以将这个功能分解到另外一个用例中。其它用例可以和这两个用例建立包含关系。（2）一个用例的功能太多时，可以用包含关系建模两个小用例。要使用包含关系，就必须在客户用例中说明提供者用例行为别包含的详细位置。这一点同功能调用有点类似。事实上，它们在某种程度上具有相似的语义。
３．扩展关系（Extend）一个用例也可以被定义为基础用例的增量扩展，这被称作扩展关系，扩展关系是把新的行为插入到已有的用例中的方法。同一个基础用例的几个扩展用例可以在一起应用。基础用例的扩展增加了原有的语义，此时基础用例而不是扩展用例被作为例子使用。在UML中，扩展关系表示为虚线箭头加<
基础用例提供了一组扩展点，在这些新的扩展点中可以添加新的行为，而扩展用例提供了一组插入片片段，这些片段能够被插入到基础用例的扩展点上。基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。事实上，基础用例即使没有扩展用例也是完整的，这点与包含关系有所不同。一个用例可能有多个扩展点，每个扩展点可以出现多次。但是一般情况下，基础用例的执行不和涉及到扩展用例，只有特定的条件发生，扩展用例才被执行。扩展关系为处理异常或构建灵活的系统框架提供了一种有效的方法。
４．泛化关系（Generalization）一个用例可以被特别列举为一个或多个用例，这被称为用例泛化。当父用例能够被使用时，任何子用例也可以被使用。在UML中用例泛化与其它泛化关系的表示法相同，用一个三角箭头从子用例指向父用例。在用例泛化中，子用例表示父用例的特殊形式。子用例从父用例处继承行为和属性，还可以添加、覆盖或改变继承的行为。如果系统中一个或多个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。
用例建模技术
一．对语境建模
对于一个系统，会有一些事物存在于其内部，而一些事物存在于其外部。存在于系统内部的事物的任务是完成系统外部事物所期望的系统行为，存在于系统外部并与其进行交互的事物构成了系统的语境，即系统存在的环境。在UML建模中，用例图对系统的语境进行建模，强调的是系统的外部参与者。对系统语境建模应当遵循以下的方法：（1）用以下几组事物来识别系统外部的参与者：需要从系统中得到帮助以完成其任务的组；执行系统功能时所必须的组；与外部硬件或其它软件系统进行交互的组；为了管理和维护而执行某些辅助功能的组。（2）将类似的参与者组织成泛化/特殊化的结构层次。
（3）在需要加深理解的地方，为每个参与者提供一个构造型。
（4）将参与者放入到用例图中，并说明参与者与用例之间的通信路径。二．对需求建模
需求就是根据用户对产品功能的期望，提出产品外部功能的描述。需要分析所要做的工作是获取系统的需求，归纳系统所要实现的功能，使最终的软件产品最大限度的贴近用户的要求。对系统需求建模可以参考以下的方法。
（1）识别系统外部的参与者来建立系统的语境。
（2）考虑每一个参与者期望的行为或需要系统提供的行为。（3）把公共的行为命名为用例
（4）分解公共行为，放入到新的用例中以供其它的用例使用：分解异常行为，放入新用例中以延伸为主要的控制流。简而言之，就是确定提供者用例和扩展用例。
（5）在用例视图中对用例、参与者和它们之间的关系进行建模。
第二篇：RUP-用例分析范例
DJ01：处理开业登记
用例描述
参与者根据处理方式录入开业登记信息，编发纳税人登记证号、纳税人编码、档案管理编码。
参与者
税务文书受理人员
基本事件流
1.参与者请求进行开业登记
2.系统检查到参与者权限足够，提示选择处理方式（一般方式和快速方式）。
3.参与者选择处理一种处理方式，提交
4.系统显示开业登记申请的详细内容的输入表单（详细内容由税务（扣缴税款）
登记表决定（见补充说明1））
5.参与者输入纳税人工商注册号和名称
6.如果是快速方式，参与者录入必须的开业登记信息（见补充说明10）
7.如果是一般方式，参与者录入全部的开业登记信息（见补充说明1）
8.参与者提交已录入的信息
9.系统进行数据合法性检查
10.系统进行逾期登记检查（见补充说明5），核定划分征管归属（见补充说明6），对占投资总额25%的相关业户做关联企业归类，生成税务登记证信息（见补充说明9），编发税务登记证号、纳税人编码（见补充说明7）、档案管理编码（见补充说明8），保存参与者录入的信息，提示参与者登记成功。
11.可选事件流
5a、在与工商局连网的情况下，系统通过网络到工商局信息系统检索纳税人资料 5a1、系统未能检索到纳税人资料
5a11、系统提示参与者“未能找到该纳税人的工商注册号，需重新输入纳税人工商注册号”
5a12、系统转到5
5a2、系统能检索到纳税人资料
5a21、系统提示参与者“能找到该纳税人的工商注册号”，把工商资料（见补充说明11）导入到开业登记申请的输入表单中
5a22、参与者校对导入的数据
5a22、参与者转到6或7
5b、系统检查到该纳税人已做开业登记
5b1、系统提示参与者“该纳税人已做过开业登记”
5b2、系统转到
55c、系统检查到该纳税人已在网上做登记
5c1、系统带出已有的登记信息
5c2、系统转到6或7
8a、参与者取消申请详细内容的输入。
8a1、系统清空申请的详细内容的输入表单。
8a2、系统返回6或7
9a、系统检查到数据不合法
9a1、系统提示参与者错误信息。错误信息：错误的原因，更正提示
9a2、系统返回6或7
9b、系统检查到组织机构代码、纳税人名称、法人身份证号码有与现有系统中数据相同的9b1、系统提示参与者，询问是否继续
9b2、参与者选择继续，系统返回10
9b3、参与者选择取消，系统返回6或7
10a、系统检查到该纳税人逾期登记。
10a1、系统显示“该纳税人逾期登记”，记录该纳税人逾期登记标志（即通知行政处罚人员进行行政处罚，产生罚款告知书、送达回证、处罚决定书（见补充说明
4））。返回11
10b、系统保存不成功
10b1、系统提示错误信息。错误信息：错误的原因，更正提示
10b2、系统返回6或712、若需要应税管理事项告知书，参与者请求打印应税管理事项告知书
13DJ05）
结束状态
系统已编发纳税人登记证号、纳税人编码、档案管理编码，保存参与者录入的开业登记信息
补充说明
1.纳税人开业登记信息参见表证单书-DJ01：税务（扣缴税款）登记表。
2.纳税人逾期登记时，系统开出罚款告知书、送达回证、处罚决定书，但开业登
记继续进行，只是拿税务登记证时须有进行过逾期登记行政处罚的收据。
3.缴费通知书的内容参见表证单书-DJ24:收取工本费—缴费通知书。
4.罚款告知书、送达回证、处罚决定书的具体内容参见表证单书-CF007、CF008、CF024
5.逾期登记的判定及处罚规则参见业务规则-DJ0005：逾期登记判定及处罚规则
6.核定划分征管归属是依据录入的纳税户实际经营地址，规则参见DJ0006：开业
登记应税管理事项核定规则
7.编发纳税人登记证号、纳税人编码规则参见DJ0007：纳税人识别号、档案管理
编码编设规则
8.编发档案管理编码规则参见DJ0007：纳税人识别号、档案管理编码编设规则
9.税务登记证信息有税务登记证号、发证机关、发证日期、纳税人名称、法定代
表人、地址、登记注册类型、经营方式、经营范围（包括主营和兼营）、经营期限、证件有效期限
10.必须的开业登记信息有组织机构统一代码，登记注册类型及代码，纳税人，扣
缴义务人，业户名称，注册地址，实际经营，业务地址，法定代表人、董事长、负责人、业主姓名、国籍及代码，经营、业务范围，管理机关及代码，受理日期，发证日期，前台审核录入人员，注册资本、联系电话
11.工商转入的登记资料补充说明：第一部分是工商转入的前台资料，允许录入人
员进行修改，包括的数据是：注册类型、名称、注册地址、注册地址邮编、法定代表人、负责人、首席代表、身份证号码、经营范围、营业执照发照日期、变更日期、企业登记注册机关、批准证件名称、营业执照的期限。第二部分工商转入其他的资料，录入人员不进行修改。包括的数据是：企业联系电话、注册资金（本）、注册资金（本）币种、投资人名单、法人股东名单、从业人数、企业联系用电子邮件、注册资本折万美元、经济性质、企业信息身份代码、年检日期、注/吊销日期、企业状态。
更新记录
第三篇：UML用例图总结
UML用例图
用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。
用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。
共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
1、包含(include)
包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。
2、扩展(extend)扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。对于一个扩展用例，可以在基用例上有几个扩展点。
例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：
4、泛化(generalization)泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。
例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：
上面是我参考的一篇文章，觉得将三种关系的区别讲得很清晰，在此基础上结合自己的系统，对项目(在线购物系统)的用例做了整体的描绘。
*****************************************************************
(1)系统整体用例图
(商品用例图)
（购买信息用例）
(用户资料用例)
按照先整体用例，后子系统用例来进行描绘的，欢迎大家提出好的建议!
转：UML中扩展和泛化的区别
泛化表示类似于OO术语“继承”或“多态”。UML中的Use Case泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子Use Case；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：
●泛化侧重表示子用例间的互斥性；
●包含侧重表示被包含用例对Actor提供服务的间接性；
●扩展侧重表示扩展用例的触发不定性；详述如下：
既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：
⒈无条件发生：肯定发生的；
⒉有条件发生：未必发生，发生与否取决于系统状态；
因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。
另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。
第四篇：(用例图)Use Cases总结
用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。
【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求。
用例图所包含的元素如下：
1.参与者(Actor)
表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
2.用例(Use Case)
用例就是外部可见的系统功能，对系统提供的服务进行描述。用椭圆表示。
3.子系统(Subsystem)
用来展示系统的一部分功能，这部分功能联系紧密。
4.关系
用例图中涉及的关系有：关联、泛化、包含、扩展。
如下表所示：
a.关联(Association)
表示参与者与用例之间的通信，任何一方都可发送或接受消息。
【箭头指向】：指向消息接收方
b.泛化(Inheritance)
就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。
【箭头指向】：指向父用例
c.包含(Include)
包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。
【箭头指向】：指向分解出来的功能用例
d.扩展(Extend)
扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。
【箭头指向】：指向基础用例
e.依赖(Dependency)
以上4种关系，是UML定义的标准关系。但VS2010的用例模型图中，添加了依赖关系，用带箭头的虚线表示，表示源用例依赖于目标用例。
【箭头指向】：指向被依赖项
5.项目(Artifact)
用例图虽然是用来帮助人们形象地理解功能需求，但却没多少人能够通看懂它。很多时候跟用户交流甚至用Excel都比用例图强，VS2010中引入了“项目”这样一个元素，以便让开发人员能够在用例图中链接一个普通文档。
用依赖关系把某个用例依赖到项目上：
然后把项目-》属性 的Hyperlink设置到你的文档上；
这样当你在用例图上双击项目时，就会打开相关联的文档。
6.注释(Comment)
包含(include)、扩展(extend)、泛化(Inheritance)的区别：
条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的；
直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include中被包含的用例为参与者提供间接服务。
对extend而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。
对Inheritance而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系；
一个用例图示例：
牢骚：
感觉用例图还不成熟，并不能很好地表达系统的需求，没有UML背景的用户几乎不知道画的是些什么。
其次，包含关系、扩展关系的箭头符号竟然是同样的箭头，仅靠上方写个文字来加以区别，翻译成其他语言的话，几乎就不知道代表什么意思。扩展关系的箭头朝向也很难理解，为何要指向基用例，而不指向扩展用例。
VS2010添加的“项目”元素，是个很好的创新，能够在用例图中关联word, excel这些文档。但为什么不把这些功能直接集成到用例里面，双击用例就弹出一份文档岂不更容易理解，非要画蛇添足地加一个元件，仅仅为了提供个链接功能。
用例描述表：
鉴于用列图并不能清楚地表达功能需求，开发中大家通常用描述表来补充某些不易表达的用例，下图的表给大家提供一个参考：
第五篇：会员用例描述
会员用例描述
表1 用例“会员注册”的描述
用例名称
会员注册
用例描述
普通用户通过注册成为网上花店系统的会员 参与者
用户
前置条件
用户已经打开网上花店系统的页面 后置条件
基本操作流程
1.用户打开注册页面；
2.用户输入昵称、E—mail地址、登录密码、再次输入登录密码；
3.单击“提交”；
4.系统将验证登录用户名的有效性和重复性、密码的正确性，如果都正确则显示“你已成功注册”，否则提示用户重新输入。
可选操作流程
1.用户选择“重置”，系统将清空输入框信息；
2.用户选择“返回”，该页面将返回到网上花店系统主页面。
.表2 用例“会员登录”的描述
用例名称
会员登录
用例描述
普通用户通过注册成为网上花店系统的会员登录该系统 参与者
会员
前置条件
用户已经是网上花店系统的会员 后置条件
基本操作流程
1.会员请求进入网上花店系统；
2.会员打开登录页面；
3.会员输入昵称、登录密码，再选择“登录”；
4.系统将验证登录用户名和密码的正确性，如果都正确则进入系统，否则提示用户重新输入。
可选操作流程
1.用户选择“重置”，系统将清空输入框信息
.表3 用例“个人信息维护”的描述
用例名称
个人信息维护
用例描述
用来维护会员的相关信息 参与者
会员 前置条件
登录系统 后置条件
基本操作流程
1.会员打开了个人信息维护页面；
2.会员输入需要修改的信息，确认后再选择“登录”；
3.系统将验证登录修改后的用户名和密码的正确性，如果都正确则进入系统，否则提示用户重新输入。
可选操作流程
1.用户选择“重置”，系统将清空输入框信息 ；
2.用户选择“返回”，该页面将返回到网上花店系统主页面。
.表4 用例“添加购物车商品”的描述
用例名称
添加购物车商品 用例描述
会员新增购物车信息 参与者
会员 前置条件
登录系统 后置条件
基本操作流程
1.会员获取选购商品信息，点击商品图片；
2.系统打开用户选定商品的详细信息页面
3.系统显示商品信息，包括商品图片、市场价、会员价、库存量、商品描述，并选择“加入购物车”，如果该商品库存量为0，则只能选择‘收藏’，不购买，只有库存量大于0，方可加入购物车；
4.会员继续浏览商品、加入购物车。可选操作流程
.表5 用例“删除购物车商品”的描述
用例名称
删除购物车商品
用例描述
会员删除所加购物车的商品信息 参与者
会员 前置条件
登录系统 后置条件
基本操作流程
1.会员选择“删除”按钮；
2.系统打开确认删除对话框；
3.会员点击“确认”按钮，删除商品信息；
4.系统删除选中的商品信息，并更新商品信息列表。
可选操作流程
1.选择“取消”按钮，系统将取消删除操作，并返回商品列表页面。
.表6 用例“确认收货”的描述
用例名称
确认收货
用例描述
会员收到货后进行确认收货 参与者
会员 前置条件
登录系统 后置条件
基本操作流程
1.会员打开订单页面；
2.选择“未完成订单”；
3.点击“确认收货”按钮；
4.更新商品订单，返回未完成订单页面。
可选操作流程
1.在未完成订单页面，点击“退货”按钮，对于已发货订单，等待管理员审核，返回未完成订单页面。
.表7 用例“进行评价”的描述
用例名称
进行评价
用例描述
会员确认收货后进行评价 参与者
会员 前置条件
登录系统 后置条件
基本操作流程
1.会员打开订单页面；
2.选择“未完成订单”；
3.点击“评价”按钮，输入评价内容，进行“提交”；
4.更新商品订单，返回未完成订单页面。可选操作流程
.表8 用例“订单管理”的描述
用例名称
订单管理
用例描述
会员可以对自己的订单进行修改、增添、删除管理。参与者
会员 前置条件
登录系统 后置条件
基本操作流程
1.会员打开订单页面；
2.按照条件可以“查询”自己的订单；
3.对目标订单进行修改发货地址和信息管理
4.系统更新商品订单，返回未完成订单页面。
可选操作流程
1.对未发货或者已完成的目标订单选择“删除”按钮，删除订单，系统.更新商品订单，返回未完成订单页面。.
点击咨询 