对于各用况图应该综合考虑，进行检查与调整。下面针对参与者和用况给出一些需要注意的检查与调整原则。1参与者1) 确定系统环境中的所有角色，并都归入了相应的参与者。2) 每个参与者都至少与一个用况相关联。3) 若一个参与者是另一个参与者的一部分，或扮演了类似的角色，考虑把它们合并或在它们之间建立继承关系。2用况1) 每个用况都至少与一个参与者相关联。2) 若两个用况有相同或相似的序列，可能需要合并它们，或抽取出一个新用况，在它们之间建立包含、扩展或继承关系。3) 若用况过于复杂，为了易于理解和开发，考虑进行分解；若一个用况中有着完全不相关的动作序列，最好把它分解成不同的用况。在对系统的功能需求进行捕获和描述时，还需要注意以下几点：1）对所有用况的描述应该尽可能完整、准确。2）在后续的开发过程中，很可能发现需求有了新的变化，或发现原先的理解有偏差，这时有必要修改已有的用况模型，以保证系统模型的正确性和一致性。3）在用用况描述需求时，讲的是系统做什么，而不是如何做。也就是说，仅描述系统内外交互的情况，不应该包含系统内部的实现信息。若使用第5章要讲述的活动图描述用况，注意不要描述系统的内部功能。4）用况的大小要适中，原则是不但要捕获需求，还要便于实施后续的分析、设计与测试。若发现用况过大，就要通过进一步的分析对它进行分解。若发现用况过小，就要考虑是否把它作为其他用况的一部分。5）用况描述的是系统内外交互的情况，但不能按人机界面来建立用况图，而应该按功能来描述系统内外的交互。注意，界面不是用况，用况也不是界面，一个用况可能包含所要建造的系统的多个界面，一个界面也可能由多个用况使用。6）尽量不要使用多层的包含、扩展或继承关系，因为这样做有可能要走上功能分解的道路。本书强调以用况图为基础，针对问题域和系统责任进行面向对象的分析和设计，而没有进一步说明以用况为驱动的开发方法。若要使用这样的方法，就要充分考虑开发各用况的优先级和风险，并要对用况做高层与低层、主要与次要、本质与具体的区分[6]。
相关资源：JAVA上百实例源码以及开源项目源代码