用例图应该说明什么级别的复杂性 - 应该包括多少细节，以及什么是应该使用序列图或替代UML图的“截止”点？
答案 0 :(得分：1)
虽然UML规范对任何UML图中可能出现的内容都有很大的自由度，但以下内容应该放入UC图中：
这适用于＆＃34; main＆＃34; UC图表，但您可能会创建包含设计要求和/或类等的其他图表。
现在，演员们都是首先与SUC互动的对象。用例是指SUC向其参与者提供的一些个人附加值（不是某些技术程序!!）的所有气泡。
用例图是关于系统的附加值，而不是技术特性！
答案 1 :(得分：0)
当然，简短的回答是任何细节（而不是复杂性）都是必要的。为了更周到，分析师经常使用用例向非技术利益相关者证明其所有基于使用的要求都得到满足。为此，应该有足够的细节，以便经理，客户和营销人员相信开发人员将开发他们想要的产品。对于为开发人员捕获决策的用例图，应该有足够的细节，可以继续进行更深入的设计或编程。最好不要开发试图满足两类用户（利益相关者和开发者）需求的图表。最后，这是一个绘制和审查的迭代过程。从简单开始，根据需要添加细节。
答案 2 :(得分：0)
使用案例
UML定义用例：
用例是捕获系统要求的一种手段，即 应该做什么系统。 （...）用例是一个规范 行为用例的实例是指出现的 紧急行为（......）。这样 实例通常由交互描述。
换句话说，它是系统在与外部世界互动中应该做些什么的外部观点。
细节水平应该相当高。通常，用户与系统交互的顶级，即用户为实现目标而调用的主要功能。使用通常的ATM示例，主要目标是＆＃34;提取现金＆＃34;，＆＃34;咨询帐户余额＆＃34;，当然不是＆＃34;插入卡＆＃34;，键入pin＆＃34; ;，＆＃34;选择菜单中的操作＆＃34;，＆＃34;拿钱＆＃34;。
但是没有规范：你也可以有非常详细的图表。只是他们画画会很痛苦，并不一定会增加对要求的理解。这就是为什么公认的做法是进一步详细说明高级用例（＆＃34; 海平面＆＃34;）作为叙述，例如使用Cockburn's方法。
使用序列图切断
UML定义了序列图：
序列图通过关注于交互来描述交互 交换的消息序列（..）交互 序列图描述的形成了理解的基础 Interactions包中元类的语义。
这里重点关注系统内部和消息交换。但是，UML将用例视为专用类图。考虑到这一点，如果您有非常详细的用例图，序列图应描述与actor和用例之间的交互。