精华内容
下载资源
问答
  • 用例图中包括三种元素,参与者,用例,...下面说说参与者与用例之间,用例与用例之间有哪些关系。 1.关联关系 定义:参与者与用例之间通常用关联关系来描述。 表示方法:带箭头的实线,箭头指向用例。 ...

    本文转载至:http://blog.csdn.net/ls1645/article/details/42969587

     

     

    用例图中包括三种元素,参与者,用例,它们之间的关系。下面说说参与者与用例之间,用例与用例之间都有哪些关系。

    1.关联关系

            定义:参与者与用例之间通常用关联关系来描述。

            表示方法:带箭头的实线,箭头指向用例。

            如图所示:

     

     

    2. 泛化关系

            定义:一个用例可以被特别列举为一个或多个子用例,这被称为用例泛化。

            泛化关系在类间也有。

            子用例从父用例处继承行为和属性,还可以添加行为或覆盖、改变已继承的行为。

            表示方法:带空心箭头的实线,箭头指向被泛化(被继承的用例,即父用例。(PS:泛化关系的箭头不是指向被泛化,而是指向被继承。泛化和继承是不同的方向。泛化是从下到上的抽象过程,继承是从上到下,从一般到特殊的过程。)

            如图所示:

     

            机房收费系统中可以这样应用:

     

            当系统中具有一个或多个用例是一般用例的特化时,就使用用例泛化。

    3.包含关系

            定义:其中一个用例(基础用例)的行为包含了另一个用例(包含用例)的行为。基础用例可以看到包含用例,并依赖于包含用例的执行结果。但是二者不能访问对方的属性。

            表示方法:虚线箭头+<<include>>字样,箭头指向被包含的用例。

            如图所示:

     

            使用情况:

                (1)如果两个以上用例有重复的功能,则可以将重复的功能分解到另一个用例中。其他用例可以和这个用例建立包含关系。

                (2)一个用例的功能太多时,可以用包含关系创建多个子用例。

     

     4.扩展关系(extend)

            定义:是把新行为插入到已有用例的方法。

           个人感觉可以叫做特殊情况处理。比如去食堂用饭卡打饭,绝大部分人是刷卡,拿饭,两个步骤就完成了。但是如果某个学生的饭卡里没钱了,假定不用现金或者借钱或者赊账等等其他的方式来打饭,而是必须用自己的饭卡来打饭。那么他就要先去给饭卡充值。“饭卡充值”就是“刷卡”的一个扩展用例。“饭卡充值”与“刷卡”就是扩展关系。

            表示方法:虚线箭头+<<extend>>字样,箭头指向被扩展的用例(即基础用例)。

           如图所示:

            作用:为处理异常或构建灵活系统框架提供了一种有效的方法。

    对比:

            包含与扩展的区别。在扩展关系中,基础用例没有扩展也是完整的,而在包含关系中,基础用例依赖于包含用例的执行结果。

    总结:

            所有的箭头指向都是“被”的一端。

            找关系,是一件挺复杂的事儿。从不同的角度看会有不同的结果。找到大前提,再理顺特定环境下的关系,会更加顺手。

    转载于:https://www.cnblogs.com/Camier-myNiuer/p/6705211.html

    展开全文
  • 在"在Visual Studio中使用用例图描述系统与参与者间的关系"中,使用用例图表示参与者与系统的关系,本篇体验参与者与用例(参与者要做的事情)的关系。 首先创建有关Customer参与者的UML用例图。 在解决方案下创建一个...


    在"在Visual Studio中使用用例图描述系统与参与者间的关系"中,使用用例图表示参与者与系统的关系,本篇体验参与者与用例(参与者要做的事情)的关系。

     

    首先创建有关Customer参与者的UML用例图

     

    在解决方案下创建一个名称为"Customer"的UML用例图。

     

    打开"UML模型资源管理器",把其中的"Customer 参与者"拖动到右侧的主界面。

     

    在主界面添加若干个用例图标,用来表示Customer需要完成的任务。

     

    添加Customer参与者与用例的关联。

     

    7

     

    以上,描述的是普通Customer能做的事。

     

    如果是注册Customer该如何描述呢?换句话说,注册Customer拥有普通Customer的一切动作,除此之外还有自己的特权动作,该如何表示呢?

     

    在界面上添加一个名称为Registered Customer的参与者。

     

    为Registered Customer这个参与者添加一个"泛化"关系,指向名称为Customer的参与者,如下:

     

    8

     

    添加几个针对Registered Customer参与者的用例,并添加关联关系,如下:

    9

     

    如果一个用例下包括多种情况该如何表示呢?

     

    只需要在父类和子类用例之间添加包括关系

     

    10

     

    再在解决方案下添加一个名称为"Store Manager"的用例图

     

    11

     

    然后Store Manage有时候会取消订单,通常情况下是不取消的,如何描述这种情况呢

     

    这就需要为处理订单用例添加一个取消订单的用例。

     

    还可以为取消订单这个用例添加一个备注,让备注链接到取消订单这个用例。

    12

     

    备注:

    ● 把参与者看作是系统的角色,而不是实际工作中的职位
    ● 把动作粒度放在参与者要做的事,而不是具体的操作细节
    ● 一个用例图只秒速一个参与者要做的事
    ● 在有必要的时候添加备注,并可用显眼的背景色

     

    总结:

    ● 当一个参与者继承于另一个参与者,为该子参与者添加"泛化"关系,使其指向父类参与者


    ● 当用例之间包含父子关系,为父用例添加"包括"关系指向子用例


    ● 当一个用例作为另一个用例的特俗情况,就为正常情况下的用例添加"扩展"关系,使其指向特殊用例

     


    参考资料:https://channel9.msdn.com/Blogs/clinted

    转载于:https://www.cnblogs.com/darrenji/p/4727283.html

    展开全文
  • 参与者用例之间关系 的连线用直线还是用箭头线 什么区别的? 谢谢
  • 用例之间关系

    2019-09-30 04:44:46
    用例图主要用来图示化系统...用来描述软件应具备哪些功能模块以及这些模块之间的调用关系,用例图包含了用例和参与者用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员(通常是软件的用户),对应...
        用例图主要用来图示化系统的主事件流程,它主要用来描述客户的需求,即用户希望系统具备的完成一定功能的动作,通俗地理解用例就是软件的功能模块,所以是设计系统分析阶段的起点,设计人员根据客户的需求来创建和解释用例图,用来描述软件应具备哪些功能模块以及这些模块之间的调用关系,用例图包含了用例和参与者,用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员(通常是软件的用户),对应的是软件的结构和功能分解。


    用例是从系统外部可见的行为,是系统为某一个或几个参与者(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提供服务,但用例提供服务的方式可分为间接和直接两种,依据于此,泛化中的子用例提供的是直接服务,而包含中的被包含用例提供的是间接服务。同样,扩展用例提供的也是直接服务,但扩展用例的发生是有条件的。

             另外一点需要提及的是:泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。

    转载于:https://www.cnblogs.com/HeroBeast/archive/2010/09/02/1816095.html

    展开全文
  • 如何使用用例之间关系?

    千次阅读 2019-04-11 09:21:20
    什么是用例图? 用例提供了系统的高级视图。用例建模是用户和其他利益相关就系统和目标进行沟通的有效方式。用例描述了系统执行的动作序列,其...定义两个用例之间关系是用例图的建模的决定。使用不同类型...

    什么是用例图?

    用例提供了系统的高级视图。用例建模是与用户和其他利益相关者就系统和目标进行沟通的有效方式。用例描述了系统执行的动作序列,其为特定的actor产生可观察的值结果。它支持需求工程活动和捕获系统应该执行的需求过程,主要是系统功能需求。

    用例之间的关系

    用例共享不同类型的关系。两个用例之间的关系基本上是两个用例之间的依赖关系。定义两个用例之间的关系是用例图的建模者的决定。使用不同类型关系的现有用例减少了在系统中定义用例所需的总体工作量。用例关系可以是以下之一:

    • 通信 (communication link): 通过将actor符号连接到用例符号的实线路径来显示演员在用例中的参与。据说演员与用例“沟通”。这只是一个actor和用例之间的关系。见图 1。

    图3.4
    图  1通信关系

    • 扩展 (Extends): 扩展显示用例之间的关系。用例A和用例B之间的关系表明用例B的实例可以包括(在扩展中指定的)由A指定的行为。用例之间的“扩展”关系用带有点线的有向箭头描绘。轴。箭头的尖端指向父用例,子用例连接在箭头的底部。构造型“”标识为扩展关系,如图 2 所示。

    图3.5

    图 2扩展关系的示例

    例如,验证用户的系统。无效密码是验证密码用例的扩展,如图3.5所示。

    • 包含 (include) :_当用例被描述为使用另一个用例的另一个功能的功能时,用例之间的这种关系被命名为包含或使用关系。换句话说,在包含关系中,用例包括在另一用例中描述的功能作为其业务处理流程的一部分。从用例A到用例B的使用关系表示用例的实例还将包括由B指定的行为。包含关系用具有虚轴的有向箭头描绘。箭头的尖端指向子用例和在箭头底部连接的父用例。构造型“”将关系标识为包含关系。

    图3.6

    图 3包含关系的示例

    系统边界可能是需求文档中定义的整个系统。对于大型复杂系统,每个模块可以是系统边界。例如,对于组织的ERP系统,诸如个人,工资单,会计等的每个模块可以形成特定于这些业务功能中的每一个的用例的系统边界。整个系统可以跨越描述整个系统边界的所有这些模块。

    • 泛化 (Generalization): 泛化关系也是用例之间的父子关系。泛化关系中的子用例具有基础业务流程的含义,但是是对父用例的增强。在用例图中,泛化显示为带有三角形箭头的有向箭头。儿童用例连接在箭头的底部。箭头的尖端连接到父用例。

    图3.7

    图 4 泛化关系的一个例子

    从表面上看,泛化和延伸似乎或多或少相似。但是泛化和延伸关系之间存在细微差别。当在用例之间建立泛化关系时,这意味着父用例可以被子用例替换而不会破坏业务流。另一方面,用例之间的扩展关系意味着子用例将父用例的功能增强为专用功能。扩展关系中的扩展中的父用例不能被子用例替换。


    从泛化关系图(图 4)中,您可以将“Store_patient_records(纸质文件)”(父)用例描述为“Store_patient_records(计算机化文件)”(子)用例的通用版本。定义两者之间的泛化关系意味着系统业务流中任何出现的“Store_patient_records(纸质文件)”用例都可以用“Store_patient_records(计算机化文件)”用例替换,而不会影响任何业务流程。这意味着将来您可能会选择将患者记录存储在计算机化文件中而不是纸质文档中,而不会影响其他业务操作。
    现在,考虑无效密码用例的示例,它是Login用例的扩展。登录用例不能被无效密码用例替换。如果您尝试这样做,您将无法使用“无效密码”用例无缝替换“登录”用例的出现。

    用例图指南

    • 确保每个用例都能满足可观察的用户目标
    • 用例图未显示用例的详细信息:它仅总结了用例,参与者和系统之间的一些关系。
    • 用例图未显示为实现每个用例的目标而执行步骤的顺序。
    • 与用例相关的其他详细信息可以在其他图表和文档中描述,例如用于描述系统场景行为的序列图,或用于在用例场景中涉及的对象建模的类图。
    • 用例仅涉及系统的功能要求。其他要求(如业务规则和实施约束)必须单独表示。
    • 将大型应用程序划分为包以形成软件架构。

    用例图示例:包含和扩展用例

    此用例图示例描述了几个业务用例的模型。用例模型表示餐馆(业务系统)与其主要利益相关者(业务角色和业务角色)之间的交互。在确定了基本用例之后,您可以使用<构造这些用例>和<>用例以更清晰。

    åå«åæ©å±ç¨ä¾

    使用此用例图模板创建自己的图表。只需单击“使用此模板进行编辑

    用例图示例:ATM

    这是ATM的用例图模板。在学习UML时,ATM系统被广泛用作例子。ATM用例图是非常经典和流行的UML示例之一。让我们来看看。在此示例中,作为ATM用户的客户被建模为actor。提取现金,转移现金,向慈善机构捐款,支票余额和结算账单等主要功能都被模拟为用例。所有这些用例都包含Login用例。这意味着它们都包含与Login用例建模相同的登录功能。登录用例通过两个用例进一步扩展。这可以模拟登录过程中可能发生的异常情况。

    èªå¨å款æº

    使用此用例图模板作为创建自己的图表的起点。单击“使用此模板"进行编辑”


    为初学者推荐UML文章

     

    展开全文
  • 实战UML之用例之间关系

    千次阅读 热门讨论 2014-12-07 19:16:42
    目前正在处于画图阶段,由于前期没有仔细认真的看视频,加上心里有点着急,思绪万千,有点乱,现在理理清楚,接着奋斗......  用例除了与参与者发生关系外,... 关联关系描述参与者与用例之间关系,它是用于表示类
  • Rose的 一些简单说明--类类之间的关系、用例与用例之间关系  (674) (0) 举报 收藏 1、uml中图的放置位置   注释: 用例视图 用例视图中包括了系统中的所有参与者、用例和用例图,必要时还可以...
  • Tenet?运动网站基于用例 需求说明书 1 系统需求.3 1.1 基于网上客户的电子商务网站.3 1.1.1 功能分析.3 1.1.2 系统顶层活动图.5 1.1.3 用例图.6 参与者.6 用例.6 顶层用例图.7 1.1.4 用
  • 用例之间的可视化关系:用例除了与参与者有关联关系外用例之间也存着一定的关系,如泛化关系、包含关系、扩展关系等。 包含关系:两个用例之前的产系,其 一个用例的行为包含了另一个用例的行为。如下图 扩展...
  •  参与者的定义:actor是在系统之外系统交互的某人或某事物。它在建模过程中处于核心地位。  注意:在参与者存在的场景中,系统边界是一个很重要的概念,一提到参与者,我们就必须想到系统边界的存在,否则参与...
  • 简单介绍用例间的关系
  • 一、版型在UML里一个概念叫版型(stereotype),也被称为类型、构造型。版型是由UML里的元素扩展而来,每个元模型都很多版型,比如用例有“业务用例”...参与者和系统之间有一个明确的边界,参与者只能存在于边界之
  • 工具主要 Rose PowerDesinger 2、StarUML的模型、视图 starUML中清晰地区分了模型(model),视(View)图(Diagram)的概念。 模型是包含软件模式信息的元素。 视是模型中信息的可视表达法。 图是表示用户...
  • uml用例关系

    2018-10-23 10:49:00
     关联关系是指执行者与用例之间关系,又称为通信关系,如果某个执行可以对某个用例进行操作,它们之间就具有关联关系,如下图所示,“经理”一个功能为“查看库存报表”,因此可以在执行“经理”和用例...
  • 网上书店需求分析,能分析功能层次图,图书用例关系图,会员用例关系
  • 用例建模

    千次阅读 2020-04-21 11:35:49
    用例建模UML需求建模图示需求分析阶段的工作任务什么是业务用例建模什么是用例图用例图的作用用例图对开发的意义大学信息系统的一个用例图...用例之间的关系******(2)参与者之间关系******(3)用例之间关系***详解...
  • UP 的阶段,用例和使用场景之间是什么关系以及和协作之间关系,软件开发过程中使用 UML 的必要性以及好处 1.什么是 UP 的阶段? 1) 初始:大体上的构想、业务案例、范围和模糊评估; 2) 细化:已精化的构想、...
  • 分析和考察待开发系统的行为,并通过参与者(可能是最终用户也可能是外围系统)系统之间的交互关系描述了了系统对外提供的功能特性----这种参与者与系统功能特性间的交互关系就是用例 用例分析和用例建模就是通过...
  • 参与者、用例以及用例与用例之间关系构成的用于描述系统功能的动态视图称为用例图。 参与者的基本概念 参与者(Actor)是指存在于系统外部并直接系统交互的人、系统或者设备等。 参与者在画图中使用...
  • 参与者

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 20,437
精华内容 8,174
关键字:

参与者与用例之间的关系有哪些