1704180644
1704180645
同时，确定支持目标，如维护重要的业务实体，并把它们排除在外，使之独立并使用自己的图支持用例包。
1704180646
1704180647
原则3：使用需求属性决定最好的用例模型
1704180648
1704180649
需求属性包含需求信息。优先级：显示一个需求对于商业用户有多重要；迭代：表明需求分配到哪个迭代；稳定度：指出哪些需求可能遭受变更，此外还有更多的属性，但是，让我们把目光集中到上述三个属性上。请确定你在坚持不懈地为你的用例捕获这些属性，因为它们可以使过程变成更轻松。特别地，你将时常会有关于如何构建用例模型的多种选择；当你这样做时，用上述的属性定位你的用例模型。这将产生最少的重构工作，并聚焦于你的工作。
1704180650
1704180651
实际上，考虑下列的指导方针有助于你做出选择：
1704180652
1704180653
如果任何的这些指导方针违背原则2，并导致用例增加，不要应用指导方针！如果两个用例有不同的优先级，避免合并它们。
1704180654
1704180655
如果两个用例被分配到不同的迭代中，避免合并它们。如果两个用例具有不同的稳定性等级，避免合并它们。
1704180656
1704180657
不要为取得不稳定用例的模型花太多时间；这个功能可能根本上不需要改变。现在，把焦点集中在稳定用例上，以得到正确的模型。
1704180658
1704180659
记住：你如何重构用例模型将会影响其他的工作。业务用户将不得不找到适合新模型的方法，对于不同的可交付变量的追踪也将需要被更新。从一开始就正确地构建模型，也将节省其他人的时间。
1704180660
1704180661
在上面的例子中，我们坚决反对把延期和即付功能归并到一个单一用例中（如，请求支付），因为“初始Simpay开发，可以而且也会包括延迟的或直接的支付”可能很快会被产生；无论选择哪种支付机制，其他的将是以后版本的范围。这种用例反复属性的变化，导致分裂为即付请求和迟延支付请求。
1704180662
1704180663
原则4：分解和规则——通过业务参与者分解
1704180664
1704180665
现在你有一个结构良好并可以理解的业务用例模型。接下来你要往哪里去呢？一件重要的事情是不要把功能分解到你的用例模型中；即，不要把你的用例打破成较小的部分。这样的部分将会变成孤立的，违反用例步骤的最重要优点之一：在参与者的目标语境中呈现需求。相反，答案是递归地在当前语境中，基于用例步骤重新应用。
1704180666
1704180667
让我们回过头看看图2-5。底部的Simpay产品语境显示由Simpay有限公司、移动运营商和移动商家银行实现的Simpay产品。这些实体的RUP术语是业务参与者。这些业务参与者合作完成Simpay产品功能。一个，二个，或所有的业务参与者，都参与每个Simpay产品用例。通过这一信息，你可以为每个业务参与者（由Simpay产品语境分配的）产生一个语境。每个语境由下面二者建立：（1）通过业务参与者划分用例，（2）从现有的业务参与者派生出新的参与者。这个过程在图2-6中举例说明，它为移动操作者显示了一个实例结果。带有两段用例和一个新参与者(Simpay有限公司）的新移动运营商语境已经由更高抽象层派生出来。现在你能分开控制（相互调用）新的语境。
1704180668
1704180669
1704180670
1704180671
1704180672
图2-6 业务参与者划分
1704180673
1704180674
这与功能分解有什么不同吗？是的！取代在Simpay产品语境（不是由参与者目标激发的）创建孤立部分的是，你已经用新参与者表现的精确目标，创建了更小的域。看看移动运营商语境的结果。很明显，Simpay有限公司代表移动业务需求方（依次代表贸易商）做这些事情。然而，移动运营商的领域是自我包含的；它不需要了解Simpay有限公司参与者做什么。相反，功能分解方式将把用例分解成许多部分：获得商业细节、进行外汇交易、授权支付、捕获支付。哪种方式更适合管理方案范围呢？
1704180675
1704180676
原则5：用例描述是陈述“做什么”，而非“如何做”
1704180677
1704180678
很幸运，我们拥有感兴趣的业务代表，他们很快就适应了用例方式和有能力的技术队伍，他们的目标是把需求自动翻译成科技规范。然而，如同它被生成一样，业务代表尽可能地由状态激发，而且科技队伍对于强加于他们之上的不必要限制因素感到不安。用例通过描述产品做什么来展现需求，以达到参与者的目标。“做什么”和“如何做”间的产品活动是人们（特别是全球性的分布化团队）不太清楚的一些事情，误解是正常的。这里有四种类型的指导方针可以帮助我们避免这些错误：
1704180679
1704180680
业务需求交付产物的结构
1704180681
1704180682
Simpay产品（如这里所示）业务需求的可交付文档，采用了UML类图结构。过程框架和功能架构是高层次的业务需求文档，相当于针对Simpay产品的RUP业务视图和业务用例模型。在产品定义中捕获详细说明的业务需求，产品定义是接近于三个业务参与者（在Simpay中作为实体引用）：Simpay有限公司，移动操作者和移动业务需求方）的业务用例模型的文档集。对于Simpay有限公司，产品定义捕获了在RUP中引用、作为业务分析模型的东西。标准的RUP交付产物内容已经被修改，因为：
1704180683
1704180684
1）业务需求存在于两个抽象层面上（例如，Simpay产品和移动电话操作者或Simpay有限公司或移动业务需求方）
1704180685
1704180686
2）在第二个抽象层上要求两个不同层的细节：
1704180687
1704180688
a）一个层次是为Simpay有限公司确切描述，如何建立业务需求，或者通过技术解决方案自动实现，或者由操作者手动编写。
1704180689
1704180690
b）另一个层次主要是为移动操作者和移动业务需求方，描述设计准则（不包括个别实体）。
1704180691
1704180692
特定的自然语言表达有技术内涵（比如，回路）。如果你使用这些表达，确定他们在作为技术设计建议时不会被误解。
1704180693