1704180688
a）一个层次是为Simpay有限公司确切描述，如何建立业务需求，或者通过技术解决方案自动实现，或者由操作者手动编写。
1704180689
1704180690
b）另一个层次主要是为移动操作者和移动业务需求方，描述设计准则（不包括个别实体）。
1704180691
1704180692
特定的自然语言表达有技术内涵（比如，回路）。如果你使用这些表达，确定他们在作为技术设计建议时不会被误解。
1704180693
1704180694
业务用例描述商业流；它们决定谁是信息的来源，以及谁是目标。它们没有暗示流的技术实现。没有明确定义信息是否要推或拉，信息交换是批量的或在线的，是否要使用缓存。这样的技术性决断主要关联到非功能需求。确定人们理解业务用例中的词，例如联系、请求，不要为基本的技术交流基础设施暗示技术约束。
1704180695
1704180696
争取涉及参与者及产品间的简单交流模式。尝试遵照同步请求/响应沟通模型。这暗示一个请求的响应在用例描述持续情况下，或者被接收，或者不被接收（举例来说，在超时的情况下）。当用例已经在它的描述中继续前进时，它不可能接受响应。请求的表达是充分的，并且它简化了描述。应强调的是，它并不暗示同一模型的技术性实现。
1704180697
1704180698
当你为用例步骤编号时，人们通常认为你正在下令应该如何完成功能。然而，用例步骤的顺序通常仅仅关系到参与者的下一个交互。当在这样一组步骤的特定顺序被托管时，请习惯于跟随明确的状态。
1704180699
1704180700
交流这些指导方针是重要的。对于Simpay来说，我们在产品概述文档（见页面边栏）捕获它们。在RUP中最适合做这件事的地方是用例模型、指导方针文档。更为重要的是，如果你正工作于定制的过程之中，要有一个试验。选取一个用例，并努力与整个队伍前进一致，这样每个人都会对你将如何生成事务及管理期望，感到满意。
1704180701
1704180702
原则6：提出域模型
1704180703
1704180704
在RUP中一个域模型（见图2-7）被定义为：在域的语境中捕获最重要类型的对象。域模型是业务分析模型的一个子集，业务分析模型包含描述业务参与者（见原则4）和业务实体如何获得用例功能的业务用例实现。域模型很有用，即使你不提出业务用例实现也是如此。它通过为你的用例描述提供具有精确含义的通用词汇术语，来连接你的各个用例。域模型确保相同的术语指向相同的业务实体，正好也捕获如下类型的需求：
1704180705
1704180706
业务实体及其多样性之间的联系（举例来说，一个移动用户使用一个或多个移动电话）。
1704180707
1704180708
限制因素（举例来说，一个支付不能够超过一个特定的数值）和推导规则（举例来说，利息计算），尤其当这些不仅仅与一个用例相关时更是如此。
1704180709
1704180710
结构化你的域模型文档，为这一信息（见到图2-7）加入占位符。在我的经验中，业务用户对这些细微改进的形式感到相当满意，而且它为你提高稳定性和完全性检验：
1704180711
1704180712
1704180713
1704180714
1704180715
图2-7 域模型图和相关文本
1704180716
1704180717
所有的业务实体及其属性是否都已经定义？
1704180718
1704180719
你是否已经捕获了所有的联系？
1704180720
1704180721
所有涉及的业务实体是否至少在一个用例中？
1704180722
1704180723
所有涉及的业务实体是否都存在于域模型的用例中？
1704180724
1704180725
当创造域模型的时候，除了根据常识和读者的偏好之外，你可以使用下列的指导方针：
1704180726
1704180727
使用图帮助描述，尤其是显示业务实体间的彼此联系。
1704180728
1704180729
宁愿冗余的泛化；否则，你可以从业务用户那里要求。
1704180730
1704180731
对于简单的关系类型使用属性；否则，将会使图混乱。
1704180732
1704180733
当属性的类型会明显避免制造困惑时，忽略它们。
1704180734
1704180735
如果识别符（比如用户ID)与商业无关，忽略它们。
1704180736
1704180737
只有当参与者名字有助于澄清语境的时候，才使用它们。否则，意味着把业务实体作为参与者命名，以避免弄乱图。