领域模型52页.pptVIP

第9章 领域模型Domain Model 领域模型 领域模型是对领域内的概念类或现实中对象的可视化表示 领域模型也称为概念模型、领域对象模型和分析对象模型 领域模型是可以在业务建模科目中创建的制品之一 领域模型是UP业务对象模型(BOM)的特化 领域模型 领域模型是OO分析中最重要的和经典的模型。 确定一组概念类是OO分析的核心。（每次早期迭代不超过几个小时的时间来完成这项工作） 领域模型的范围限定于当前迭代所开发的用例场景，通过迭代不断演进。 领域模型与其它制品的关系见图9-1 领域模型的示例见图9-2 领域模型是软件业务对象图吗 “领域模型”的两个传统含义 含义一：领域模型是现实世界中对象的概念透视图，而非软件透视图 含义二：软件对象的领域层。在表示层之下的软件对象层是由领域对象组成的。领域对象是表示问题领域空间事物的软件对象，并且与“业务逻辑”或“领域逻辑”方法相关 在本书中，用领域层(domain layer)来表示第二种含义 什么是概念类 概念类是思想、事物或对象。更正式地讲，概念类可以从其符号、内涵和外延来考虑。 领域模型和数据模型是一回事吗 领域模型不是数据模型（持久化数据） 在领域模型中不会排除没有明确要求记录其相关信息的类，也不会排除没有属性的概念类 在领域内充当纯行为角色而不是信息角色的概论类也是有效的。 动机：为什么要创建领域模型 理解关键概念和词汇 动机：降低与OO建模之间的表示差异 如何创建领域模型 寻找概念类 将其绘制为UML类图中的类 添加关联和属性 如何找到概念类 找到概念类的三条策略 重用和修改现有模型。 在许多常见领域中都存在已发布的，绘制精细的领域模型和数据模型 使用分类列表（见P104表9-1） 确定名词短语。将对领域的文本描述中的名词和名词短语作为候选的概念类或属性。（见P106用例的文本描述） 示例：寻找和描述概念类(NextGen POS） 根据分类列表衙名词短语分析，可以得到该领域候选概念类的列表 根据迭代1所考虑的需求和简化的处理销售用例，即基本的现金交易场景，可以得到如P107所示的候选概念类的列表。 没有什么所谓“正确”列表。上述列表中的抽象事物和领域词汇在一定程度上是随意收集的，但都是建模者认为重要的。 实践中，可以不会创建文本列表，而是直接绘制成UML类图。见图9-7. 案例：Monopoly领域 准则：敏捷建模-绘制类图的草图 注意图9-8中UML类图的风格，让类框的底部和右侧呈开放状态，以方便扩展。 准则：敏捷建模-是否要使用工具维护模型 在后期的草图设计中或编程中发现新的概念类，是否需要更新早期的概念模型？视情况而定 通常，进化的软件领域层对大部分重要术语会给予提示，而且长生命期的OO分析领域模型不会增加价值。 准则：报表对象-模型中是否要包括“票据” 一般来说，在领域模型中显示其它信息的报表并没有意义，因为其所有信息都是源于或复制于其他信息源的。这是排除它的理由 另一方面，就业务规则而言，票据有特殊的作用：通常持有（纸质）票据的人有退货的权利。这是在模型中要表示它的原因 在本次迭代中没有考虑退货，所以不应包括票据。在解决“处理退货”用例的迭代中，再考虑将其包含在内。 准则：像地图绘制者一样思考：使用领域术语 使用地域中现有的名称。在图书馆模型中，将顾客命名为“借书者”、“赞助者”等，这是图书馆职员使用的术语。 排除无关或超出范围的特性 不要凭空增加事物 准则：如何对非现实世界建模 有些软件系统的领域与自然领域或业务领域几乎没有类似之处，例如：电信软件。 此时需要高度的抽象，对常见的非OO设计进行回顾，并且认真汲取领域专家所使用的核心词汇和概念。 例如，电信软件的候选概念类：消息、连接、端口、会话、路由、协议。 准则：属性与类的常见错误 常见错误：把应该是概念类的事物表示为属性 判别准则：如果我们认为某概念类X不是现实世界中的数字或文本，那么X可能是概念类而不是属性。 准则：何时使用“描述”类建模 描述述(description class)包含描述其它事物的信息。如：ProductDescription记录Item的价格、图片和文字描述。命名方式：项目-描述符 准则：何时需要描述类1.需要有关商品或服务的描述，独立于任何商务或服务现有实例2.删除其所描述事物(如Item)的实例后，导致信息丢失，而这些信息是需 要维护的，但是被错误地与所删除的事物关联起来3.减少冗余或重复信息 示例：航空领域中的描述 关联(association) 关联是类（更精确也说，是这些类的实例）之间的关系，表示有意义和值得关注的连接。 在UML中，关联被定义为“两个或多个类之间的语义联系，涉及这些