UML中usecase之间的关系

老文。

 

用例描述的是系统外部可见的行为,是系统为某一个或几个参与者提供的一段完整的服务。从原则上来讲,用例之间都是并列的,它们之间并不存在着包含从属关系。但是从保证用例模型的可维护性和一致性角度来看,我们可以在用例之间抽象出包含(include)、扩展(extend)和泛化(generalization)这几种关系。这几种关系都是从现有的用例中抽取出公共的那部分信息,然后通后过不同的方法来重用这部公共信息,以减少模型维护的工作量。

 

泛话(继承)就不说了很好理解.

 

包含(include) 

 

包含关系是通过在关联关系上应用<<include>>构造型来表示的,如下图所示。它所表示的语义是指基础用例(Base)会用到被包含用例(Inclusion),具体地讲,就是将被包含用例的事件流插入到基础用例的事件流中。

 

扩展(extend) 

 

扩展(extend)关系如下图所示,基础用例(Base)中定义有一至多个已命名的扩展点,扩展关系是指将扩展用例(Extension)的事件流在一定的条件下按照相应的扩展点插入到基础用例(Base)中。

至少从这个两个定义里面都看到了”将扩展(被包含)用例的事件流插入基础用例事件流”, 也就是 如果 用例A include 用例B, 似乎就又可以描述为 用例B extend 用例A, 是这样吗?

前一分钟, 我问了从我身边经过的一个同事这个问题, 他的答案是:可以把extend理解为并联,include理解为串联. 也就是说 include所包含的用例必须是基础用例的一部分,没有他基础用例就不完整. 而extend则意味着扩展, 可以扩展用例插入到任何扩展点.或者说 “对于包含关系而言,子用例中的事件流是一定插入到基础用例中去的,并且插入点只有一个。而扩展关系可以根据一定的条件来决定是否将扩展用例的事件流插入基础用例事件流,并且插入点可以有多个。”

笔记 – UML基础 – 组件图

主要目的:显示系统组件间的结构关系

在 UML 2 中,组件被认为是独立的,在一个系统或子系统中的封装单位提供接口(一个或多个)。虽然 UML 2 规范没有严格地声明它,但是组件是呈现事物的更大的设计单元,这些事物一般将使用可更换的组件来实现。但是,并不象在 UML 1. x中,现在,组件必须有严格的逻辑,设计时构造

主要思想:你能容易地在你的设计中重用及/或替换一个不同的组件实现,因为一个组件封装了行为,实现了特定接口。

系统管理员发现组件图是有用的,因为他们可以获得将运行于他们系统上的逻辑软件组件的早期视图。虽然系统管理员将无法从图上确定物理设备或物理的可执行程序,但是,他们仍然欢迎组件图,因为它较早地提供了关于组件及其关系的信息(这允许系统管理员轻松地计划后面的工作)。

一个组件是提供一个或更多公共接口的独立单元。提供的接口代表了组件提供给它的用户/客户的服务的正式契约。

该例中,组件提供了名为 OrderEntry 和 AccountPayable 的接口。此外,组件也要求另外一个组件提供Person接口。
另一种显示方法:

–组件关系建模,简单的是就是要通过provided interface和required interface把所有组件连接起来。ps:接口定义了依赖

UML 2 规范在如何区别子系统与组件方面相当含糊。从建模的观点,规范并不认为组件与子系统有任何区别

UML 2 规范中说,何时该使用组件或子系统决定于建模者的方法论。 — 也就是说这是一个见仁见智的问题

组件图经常是一个架构师在项目的初期就建立的非常重要的图。然而,组件图的有用性跨越了系统的寿命。组件图是无价的,因为它们模型化和文档化了一个系统的架构。因为组件图文档化了系统的架构,开发者和系统可能的系统管理员会发现这一工作的关键产品有助于他们理解系统

组件图也视为软件系统配置图的输入。??

uml hierarchie des diagrammes

結構性圖形(Structure diagrams) 強調的是系統式的塑模:

行為式圖形(Behavior diagrams) 強調系統模型中觸發的事件:

溝通性圖形(Interaction diagrams), 屬於行為圖形的子集合,強調系統模型中的資料流程:

—来自中文wikipedia