UML用例中的包含、扩展、泛化关系的理解.docxVIP

UML用例中的包含、扩展、泛化关系的理解.docx

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
UML用例中的包含、扩展、泛化关系的理解? \o 收藏到我的网摘中,并分享给我的朋友 收藏 在用例关系中有有三种关系,一是包括,include 一是扩展extend一是泛化,当然还有最基本的关系,“关联”. 其中,包含关系: 包含关系用于将部分工作流程分离出去,对这部分工作流程来说,基本用例只取决于结果,与获得结果的方法无关。如果这种分离可以简化对基本用例的理解(隐藏详细的行为),或者可以在其他基本用例中复用被分离的行为,您就可以将这部分工作流程分离出去。 基本用例通过包含关系连接到包含用例。包含用例总是抽象的。它描述在执行基本用例的用例实例中插入的行为段。基本用例可控制与包含用例的关系,并可依赖于执行包含用例所得的结果,但是基本用例和包含用例都不能访问对方的属性。从这种意义上来讲,包含用例是被封装的,它代表可以在各种不同的用例中复用的行为。 包含关系用于:(1)从基本用例中分解出来这种的行为:它对于了解基本用例的主要目的不是必需的,只有它的结果才比较重要。(2)分解出两个或者多个用例所共有的行为。 扩展关系: 扩展关系将扩展用例与基本用例连接了起来,通过在基本用例中引用扩展点,可以定义在基本用例的哪些位置插入扩展用例,扩展用例通常是抽象的,但是不是必须抽象。 扩展的目的在于:(1)表明用例的某一部分是可选的(或者可能可选)的系统行为。这样,你就可以将模型中的可选行为和必选行为分开。(2)表明只有在特定条件下(有时候是异常情况下)才执行的分支流,如触发警报。(3)表明可能有一组行为段,其中的一个或者多个段可以在基本用例中的扩展点处插入。所插入的行为段(以及插入的顺序)将取决于在执行基本用例时与主角进行的交互。 扩展是有条件的,它是否执行取决于在执行基本用例时所发生的事件。基本用例并不控件执行扩展的条件,这些条件在扩展关系中进行说明。扩展用例可以访问和修改基本用例的属性。但是基本用例看到到扩展用例,也无法访问它们的属性。 扩展用例以隐含的方式修改基本用例。也可以说,基本用例定义了可以在其中添加扩展用例的模块化的框架,但是基本用例看不见特定的扩展用例。 基本用例自身应该是完整的,即基本用例应该是可理解并且有意义的,而不必引用任何扩展用例。但是基本用例并不独立于扩展用例,因为如果无法遵循扩展用例,就不能执行基本用例。 泛化关系:用例的泛化关系是指一种从子用例到父用例的关系,它指定了子用例如何特化父用例的所有特征和行为。 父用例可以特化形成一个或者多个子用例,这些子用例代表了父用例比较特殊的形式。尽管在大多数情况下父用例是抽象的,但是无论是父用例还是子用例这两者都不要求一定抽象。子用例继承父用例的所有结构、行为和关系。同一父用例的子用例都是该父用例的特例。这就是可适用于用用例的泛化关系。 当你发现两个或者多用例在行为,结构和目的方面存在共性时,就可以使用泛化关系。这种情况发生时,你可以用一个新的、通常也是抽象的用例来描述这些共有部分,该用例随后被子用例特化。 ?

文档评论(0)

beoes + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档