第三部分 89cumt.pptVIP

导出属性 导出属性：数量可以从关联的多重性的实际值计算出来。 准则：什么样的属性类型是适当的 在领域模型中，建议属性主要为数据类型，常见的数据类型包括：Boolean、Date(或DateTime)、Number、Character、String(Text)和Time 其他常见类型有： Address、Color、Geometrics（Point、Rectangle）、PhoneNumber、Social Security Number、University Product Code、SKU、ZIP 或者邮政编码、枚举类型。 不应该是复杂的领域概念，例如Sale或Airport。 Cashier的currentRegister属性是不合适的，Register不是简单数据类型，表达Register的最有效方法是使用关联，而不是属性。 准则：什么样的属性类型是适当的 数据类型 UML术语中的数据类型指的是一组值，而这组值的标识本身不具有任何含义。 例如通常对以下内容进行区分没有意义： Integer 的单一实例，5 String 的单一实例，”Car“ Date 的单一实例，”Nov。13,1990” 相反，比较Person的名字实例是有意义的，即使具有相同的属性值，也可以通过比较其存储地址。 观点：领域模型中建议属性是数据模型，不意味着代码中的属性只能是简单的基本数据类型。 准则：何时定义新的数据类型类 在下述情况下，在领域模型里，把最初被认为是数字或字符串的数据类型表示为新的数据类型类： 由不同的小节组成（如电话号码、人名、地址） 具有与之相关的操作，例如解析或校验（如社会安全号） 具有其他属性（如促销价格有开始日期和结束日期） 单位的数量（如支付总额具有货币单位） 具有以上性质的一个或多个类型的抽象（如商品标识符） 准则：何时定义新的数据类型类 对POS领域模型的属性应用这些准则，会产生以下分析： 商品标识符 为数据类型ItemID类 price和amount属性的数据类型应该是Money类因为它们是货币单位的数量。 address属性的数据类型应该是Address类，因为其具有不同的小节。 应用UML：在何处描述这些数据类型类 领域模型是一种沟通工具，确定采用哪种解决方式都要考虑到这一点。 准则：任何属性都不表示外键 领域模型里的属性不应该用于表示概念类的关系。 Cashier中的currentRegisterNumber目的是将Cashier和Register联系起来，但是，应该使用关联而不是属性来将类型关联 准则：对数量和单位建模 大部分用数字表示的数量不能表示为纯数字,如:价格是13 一般情况下，可以把数量表示为单独的Quantity类，并且关联到Unit类。通常还可以对Quantity加以规格说明。 9.17 示例：领域模型中的属性 案例研究：Monopoly 9.18 结论：领域建模是否正确 没有唯一正确的领域模型。 有效的领域模型捕获了当前需求情形下的本质抽象和理解该领域所需要的信息，并且可以有助于人们理解领域的概念、术语和关系。 9.19 过程：迭代和进化式领域建模 准则：避免瀑布思维倾向，为完成详尽或“正确”的领域模型而进行大量的建模工作，这些方式都应避免，这种过量的建模工作反而会导致分析停滞，这种投入几乎不会有什么回报。 每次迭代的领域建模时间不超过几个小时。 初始： 不会发起领域模型 细化： 主要在细化阶段的迭代中创建，这时最需要理解那些重要概念，并且会通过设计工作将其映射为软件类。 对客观事物及其联系的逻辑组织描述。数据模型包括数据库数据的结构部分、数据库数据的操作部分和数据库数据的约束条件。 重用和修改现有的模型。 这是最佳和最简单的方法，对于存在已发布的、绘制今年关系的领域模型和数据模型的领域通常从这一步开始 Ledger:分类账 从事务开始 包括什么东西 参与者是谁？ 里面还有什么东西、物件 The first letter should be in capital. The reading sequence can be from top to bottom, left to right. The attributes in a domain model should preferably be simple attributes or data types. The restriction that attributes in the domain model be only of simple data types does not imply that C++ or java attributes must only be simple, primitive dat