用例技术侧重于“从用户的角度，将系统当作一个黑盒子”的视角，关键点是“发现使用系统的角色「参与者」，了解并梳理这些角色如何使用系统「场景」”，从而更好地完成“用户”视角的需求梳理。
用例模型中包含两个元素：参与者、用例。
参与者是在系统之外，透过系统边界「是一种职责边界」与系统进行有意义交互的任何角色，可以是人、其他系统、硬件设备等。
参与者是直接使用系统的最终用户，间接使用系统相关的人是Stakeholders「干系人」。
用例实例是在系统中执行的一系列动作「即它是由一系列业务步骤组成的业务活动，如基本事件流、扩展事件流、子事件流等」，这些动作将生成特定执行者可见的价值结果「也就是说能为参与者带来有意义的结果，如“填写xx”这样的用例是不合适的」。
一个用例定义一组用例实例「也可以说用例是对一组场景/用例实例的抽象，比如ATM取款时，会遇到很多不同场景：正常取到钱、卡里钱不够、忘记密码等」。
用例之间的关系存在3种可能：包含<<include>>、扩展<<extend>>和泛化<<generalization>>。
包含：指基用例「base use case」在它内部说明的某一个位置上显示的合并了另一个用例的行为，是一定会执行的公共子事件流。
包含关系最典型的应用就是复用，某事件流段在多个用例中出现时，被抽取出来成为一个单独的用例。这样简化基用例的事件流描述的同时，整个系统描述也更加清晰。
也就是说面向客户的用例图通常都不应该出现“包含”关系，因为子事件流存在共性对于客户而言是不关心的，它是开发团队对用例细节填充之后的归纳。
扩展：它表示基用例在由扩展用例间接说明的一个位置上，隐式的合并了一个用例的行为，是不一定会执行的扩展事件流，使基用例行为更简练和目标更集中。
泛化：表示子用例继承父用例的所有结构、行为和关系，还可以增加或覆盖父用例的行为，子用例可以出现在父用例出现的任何位置，是公共的事件流。父用例通常是抽象的。在实际应用中很少使用泛化关系。而面向客户的用例图中也不应该出现“泛化”关系，它也是开发团队在后期开发时才绘制的。
参与者之间的关系只存在一种——泛化。
网友评论