4

用例图应该说明什么级别的复杂性 - 应该包含多少细节，以及何时应该使用序列图或替代 UML 图的“截止点”是什么？

4

3 回答 3

1

尽管 UML 规范对于可能出现在任何 UML 图中的内容给予了很大的自由，但以下内容应该进入 UC 图中：

  • 演员
  • 用例
  • 可能是象征所考虑的系统 (SUC) 的边界。

这适用于“主要”UC 图表，但您可能会创建其他包含需求和/或设计类等的图表。

现在，演员都是首先与 SUC 交互的对象。用例是所有那些表示SUC向其参与者提供的一些个人附加值（而不是一些技术程序！！）的气泡。

用例图是关于系统的附加值，而不是技术特性！

于 2016-03-15T12:42:50.627 回答
0

用例

UML 定义了用例：

用例是一种捕获系统需求的方法，即系统应该做什么。(...) 用例是行为规范。用例的实例是指紧急行为（...）的发生。此类实例通常由交互来描述。

换句话说，它是系统在与外部世界交互时应该做什么的外部视图。

详细程度应该相当高。通常，用户与系统交互的顶层，即用户为实现其目标而调用的主要功能。使用通常的 ATM 示例，主要目标是“提取现金”、“查询账户余额”，当然不是“插入卡”、输入密码、“在菜单中选择操作”、“取钱”。

但是没有标准：你也可以有非常详细的图表。只是他们画起来会很痛苦，不一定会增加对需求的理解。这就是为什么一个公认的做法是将高级用例（“海平面”）进一步详细描述为叙述，例如使用Cockburn 的方法。

用序列图截断

UML 定义了序列图：

序列图通过关注交换的消息序列来描述交互 (..) 序列图描述的交互构成了理解交互包中元类​​语义的基础。

这里的重点更多地放在系统的内部和交换的消息上。但是，UML 将用例视为专门的类图。考虑到这一点，如果您有非常详细的用例图，序列图应该描述参与者和用例之间的交互。

于 2016-03-19T17:24:45.067 回答
0

当然，简短的回答是任何级别的细节（而不是复杂性）都是必要的。对于更深思熟虑的用例，分析师最常使用用例向非技术利益相关者证明他们所有基于使用的需求都得到了满足。为此，应该有足够的细节，以便经理、客户和营销人员相信开发人员会开发出他们想要的产品。对于为开发人员捕获决策的用例图，应该有足够的细节来继续进行更深入的设计或编程。最好不要开发试图同时满足两种类型用户（利益相关者和开发人员）需求的图表。最后，这是一个绘制和审查的迭代过程。从简单开始并根据需要添加细节。

于 2016-03-15T12:52:01.080 回答