我的用例图
2012-03-06
背景感言:在大学混日子的时候,打酱油的选修课却在实际工作中,不经意就给我一个突然袭击,悔不当初啊……
背景知识准备:
1.UML:Unified Modeling Language 的简称,为面向对象软件设计提供的统一的、标准的、可视化的建模语言。适用于描述以用例为驱动,以体系结构为中心的软件设计的全过程。
总的来说,UML给开发团队提供了一种简洁明了的沟通工具,和设计模式一样,给开发者一个统一的,没有二义性的沟通,尤其在需求不清晰的时候,可以给每个人明确的概念,减少大家扯皮的机会。
2.用例是UML事物中的构件事物(UML模型的静态部分,描述概念或物理元素)的一种,代表一个系统或系统的一部分行为,是一组动作序列的集合。
总的来时,用例就是一个独立的功能模块
3.主要UML图之间的关系
我的用例要点理解:
用例图:被称为参与者(actor)的外部用户所能观察到的系统功能的模型图。(参与者发起用例(系统外部可见的一个系统功能单元))。
用处:多用在静态建模阶段,业务建模和需求建模。
尤其是在需求建模的时候,用例图让产品设计者和开发者理解产品是个什么样子,具体有功能点的明确意义,避免大家在探讨需求时偏离了主题,通俗的讲就是驴头不对马嘴。
用例图的关系:
角色(Actor)之间的关系,泛化(is A),可以通俗的理解成继承关系。
特殊方B继承了一般方A,并增加了新特性。
角色(Actor)用例间关系:关联。
用例间关系
1)包含(has A)
MSDN: An including use case calls or invokes the included one. Inclusion is used to show how a use case breaks into smaller steps. The included use case is at the arrowhead end.
箭头指向的用例为被包含的用例,成为包含用例;出发方为基用例。包含用例必选,是基用例的一部分,必须被执行,不改变基用例的行为。
包含用例,总是抽象的,基本用例关心的是包含用例的结果,而不关心如何获得的。基本用例和包含用例的用例实体是不能互相访问属性的。
使用场景:1)从基本用例中分解出这种行为,它对于了解基本用例的主要目的不重要,只有它的结果才比较重要。
2) 分解出两个或多个用例所共有的行为(封装)
3)扩展
MSDN: An extending use case adds goals and steps to the extended use case. The extensions operate only under certain conditions. The extended use case is at the arrowhead end.
箭头指向的用例是被扩展的用例,基本用例;箭头出发的用例是扩展用例。扩展用例可选,没有扩展用例,基用例也是完整的。扩展用例在一定条件下才会执行,并且会改变基用例的行为。
基本用例自身应该是完整的,即基本用例应该是可理解并且有意义的,而不必引用任何扩展用例。但是基本用例并不独立于扩展用例,因为如果无法遵循扩展用例,就不能执行基本用例。
基本用例必须声明扩展点,而扩展用例只能在扩展点上为基本用例增加新的行为和含义。在扩展关系中,箭头的方向是从扩展用例到基本用例的,这与包含关系不同。
扩展用例是隐含插入,并不在基本用例中显示。
使用场景:1)说明用例的某一部分是可选的系统行为。把模型中可选和必选分开。
2)只有在特定条件下或异常情况下才执行的分支流,如触发告警。
3)表明可能有一组行为段,其中的一个或多个段可以在基本用例中的扩展点处插入。所插入的行为段和插入的顺序取决于基本用例与主角进行的交互。