[转载]UML用例图总结

[转载]UML用例图总结

前言

用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展示一个外部用户能够观察到的系统功能模型图。用例图多用于静态建模阶段(主要是业务建模和需求建模),帮助开发团队以一种可视化的方式理解系统的功能需求。下面将从各个部分来分析和理解用例图。

参与者(Actor)

在系统外部与系统直接交互的人或事物;需要注意以下两点:

  1. 参与者是角色而不是具体的人,它代表了参与者在与系统打交道的过程中所扮演的角色。所以在系统的实际运作中,一个实际用户可能对应系统的多个参与者。不同的用户也可以只对应于一个参与者,从而代表同一参与者的不同实例。
  2. 参与者作为外部用户(而不是内部)与系统发生交互作用,是它的主要特征。

在UML中,参与者使用如图所示的一个小人表示:

[转载]UML用例图总结

用例(Use Case)

系统外部可见的一个系统功能单元。系统的功能由系统单元所提供,并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。用椭圆表示,椭圆中的文字简述系统的功能:

[转载]UML用例图总结

子系统(Subsystem)

用来展示系统的一部分功能,这部分功能联系紧密。

关系(Relationship)

用例图中涉及的关系有:

  1. 关联
  2. 泛化
  3. 包含
  4. 扩展

[转载]UML用例图总结

关联(Association)

表示参与者与用例之间的交互,通信途径,任何一方都可发送或接受消息。 箭头指向:指向消息接收方。

[转载]UML用例图总结

泛化(Inheritance)

在编程中,泛化关系是一种很重要的关系,我们随处可见。 泛化关系是一般和特殊关系,就是通常理解的继承关系,子用例和父用例相似,但表现出更特别的行为;子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为,也可以重载它。父用例通常是抽象的。 箭头指向(需要特别注意):指向父用例。

[转载]UML用例图总结

包含(Include)

包含关系用来把一个较复杂用例所表示功能分解成较小的步骤。包含用例是必须的,如果缺少包含用例,基用例就不完整;包含用例必须被执行。 箭头指向:指向分解出来的功能用例。

[转载]UML用例图总结

扩展(Extend)

扩展关系是指用例功能的延伸,相当于为基础用例提供一个附加功能。扩展用例是可选的,如果缺少扩展用例,不会影响到基用例的完整性。 箭头指向(需要特别注意):指向基用例

[转载]UML用例图总结

下图提供一个完整的系统的用例图,让大家有一个感官上的全面认识。

[转载]UML用例图总结

总结

用例图虽然作为UML中的一部分,给团队成员提供一种形象的系统表述,但是,用例图也由它本身的缺陷,用例图一般在需求分析阶段就给出了,有的时候对于系统的需求,并不能很好的表述,对于没有UML背景的人来说,更是一种痛苦与折磨,但是,话又说回来,作为软件开发人员,没有UML背景是说不过去的;有的时候,我们需要借助用例图对客户讲解系统,而让客户去理解用例图则是很困难的。 虽然,在用例图中的关系种类不是很多,也不是很复杂,但是UML的表示确实很让人费解的,别的还好,特别是扩展(Extend)和包含(Include),表示方式都一样的,仅靠上面的说明来进行区分,在一个复杂的系统中,是很容易看错的,从而理解出错,同时,扩展(Extend)中的箭头指向一直是让我很费解的,为什么需要让箭头指向基用例呢? 鉴于用例图有的时候并不能清楚地表达功能需求,开发中大家通常用用例描述表来补充某些不易表达的用例,请大家参考下图:

[转载]UML用例图总结

 

博客转自:《UML用例图总结


本文转自SanMaoSpace博客园博客,原文链接:http://www.cnblogs.com/SanMaoSpace/p/5095403.html,如需转载请自行联系原作者

上一篇:UML类图几种关系的总结


下一篇:两年摸爬滚打 Spring Boot,总结了这 16 条最佳实践