领域模型.pptx

1第9章 领域模型Domain Model2领域模型领域模型是对领域内的概念类或现实中对象的可视化表示领域模型也称为概念模型、领域对象模型和分析对象模型领域模型是可以在业务建模科目中创建的制品之一领域模型是UP业务对象模型(BOM)的特化3领域模型领域模型是OO分析中最重要的和经典的模型。确定一组概念类是OO分析的核心。（每次早期迭代不超过几个小时的时间来完成这项工作）领域模型的范围限定于当前迭代所开发的用例场景，通过迭代不断演进。领域模型与其它制品的关系见图9-1领域模型的示例见图9-24图9-1 UP制品样例的影响5图9-2 部分领域模型：可视化字典6领域模型是软件业务对象图吗图9-3 领域模型表示真实世界概念的可视化并非表示软件类在UML中，领域模型被描述为一组没有定义操作的类图7图9-4 领域模型并非表示软件制品或类8“领域模型”的两个传统含义含义一：领域模型是现实世界中对象的概念透视图，而非软件透视图含义二：软件对象的领域层。在表示层之下的软件对象层是由领域对象组成的。领域对象是表示问题领域空间事物的软件对象，并且与“业务逻辑”或“领域逻辑”方法相关在本书中，用领域层(domain layer)来表示第二种含义9什么是概念类概念类是思想、事物或对象。更正式地讲，概念类可以从其符号、内涵和外延来考虑。图9-5 概念类具有符号、内涵和外延10领域模型和数据模型是一回事吗领域模型不是数据模型（持久化数据）在领域模型中不会排除没有明确要求记录其相关信息的类，也不会排除没有属性的概念类在领域内充当纯行为角色而不是信息角色的概论类也是有效的。11动机：为什么要创建领域模型理解关键概念和词汇12动机：降低与OO建模之间的表示差异图9-6 OO建模减小了表示差异13如何创建领域模型1.寻找概念类2.将其绘制为UML类图中的类3.添加关联和属性14如何找到概念类找到概念类的三条策略重用和修改现有模型。在许多常见领域中都存在已发布的，绘制精细的领域模型和数据模型使用分类列表（见P104表9-1）确定名词短语。将对领域的文本描述中的名词和名词短语作为候选的概念类或属性。（见P106用例的文本描述）15示例：寻找和描述概念类(NextGen POS）根据分类列表衙名词短语分析，可以得到该领域候选概念类的列表根据迭代1所考虑的需求和简化的处理销售用例，即基本的现金交易场景，可以得到如P107所示的候选概念类的列表。没有什么所谓“正确”列表。上述列表中的抽象事物和领域词汇在一定程度上是随意收集的，但都是建模者认为重要的。实践中，可以不会创建文本列表，而是直接绘制成UML类图。见图9-7.16图9-7 初始的POS领域模型17案例：Monopoly领域图9-8 初始的Monopoly领域模型18准则：敏捷建模-绘制类图的草图注意图9-8中UML类图的风格，让类框的底部和右侧呈开放状态，以方便扩展。19准则：敏捷建模-是否要使用工具维护模型在后期的草图设计中或编程中发现新的概念类，是否需要更新早期的概念模型？视情况而定通常，进化的软件领域层对大部分重要术语会给予提示，而且长生命期的OO分析领域模型不会增加价值。20准则：报表对象-模型中是否要包括“票据”一般来说，在领域模型中显示其它信息的报表并没有意义，因为其所有信息都是源于或复制于其他信息源的。这是排除它的理由另一方面，就业务规则而言，票据有特殊的作用：通常持有（纸质）票据的人有退货的权利。这是在模型中要表示它的原因在本次迭代中没有考虑退货，所以不应包括票据。在解决“处理退货”用例的迭代中，再考虑将其包含在内。21准则：像地图绘制者一样思考：使用领域术语使用地域中现有的名称。在图书馆模型中，将顾客命名为“借书者”、“赞助者”等，这是图书馆职员使用的术语。排除无关或超出范围的特性不要凭空增加事物22准则：如何对非现实世界建模有些软件系统的领域与自然领域或业务领域几乎没有类似之处，例如：电信软件。此时需要高度的抽象，对常见的非OO设计进行回顾，并且认真汲取领域专家所使用的核心词汇和概念。例如，电信软件的候选概念类：消息、连接、端口、会话、路由、协议。23准则：属性与类的常见错误常见错误：把应该是概念类的事物表示为属性判别准则：如果我们认为某概念类X不是现实世界中的数字或文本，那么X可能是概念类而不是属性。SalestoreSaleStorephoneNumberFlightdestinationFlightAirportname或?或?24准则：何时使用“描述”类建模描述述(description class)包含描述其它事物的信息。如：ProductDescription记录Item的价格、图片和文字描述。命名方式：项目-描述符25 准则：何时需要描述类准则：何时需要描述类1.需要有关商品或服务的描述，独立于任何商务或服务现有实例2.删除其所描述事物(如Item)的实例后，导致信息丢失，而这些信息是需 要维护的，但是被错误地与所删除的事物关联起来3.减少冗余或重复信息图9-9 关于其它事物的描述26示例：航空领域中的描述图9-10 对其它事物的描述27关联(association)关联是类（更精确也说，是这些类的实例）之间的关系，表示有意义和值得关注的连接。在UML中，关联被定义为“两个或多个类之间的语义联系，涉及这些类元实例之间的连接。图9-11 关联28准则：何时表示关联在领域模型中要考虑如下关联：如果存在需要保持一段时间的关系，将这种语义表示为关联（“需要记住”的关联）。从常见关联列表中派生的关联（见P115表9-2）29准则：为什么应该避免加入大量关联节点间可以有(n*n(n-1)/2个关联太多关联，会产生“视觉干扰，使图变混乱。要谨慎地增加关联线，并重点关注”需要记住“的关联。30观点：关联是否会在软件中实现在领域建模中，关联不是关于数据流、数据库外键联系、实例变量或软件方案中的对象连接语句；关联声明是针对现实领域从纯概念角度看有意义的关系。这些关系的大部分将作为（设计模型和数据模型中的）导航和可见性路径在软件中加以实现。31应用UML:关联表示法图9-12 关联的UML表示法32准则：在UML中如何对关联命名以“类名-动词短语-类名”的格式为关联命名，其中的动词短语构成了可读的和有意义的顺序。例Sale paid-by CashPayment反面示例（动词短语没有增加意义），Sale Uses CashPaymentPlayer is-on Square反面示例（动词短语没有增加意义），Player Has Square关联名首字母应该大写，因为关联表示的是实例之间链接的类元。33应用UML：角色关联的每一端称为角色(role)。角色具有如下可选项多重性表达式名称导航34应用UML：多重性图9-13 关联的多重性图9-14 多重性的取值多重性(mumltiplicity)定义了类A有多少个实例可以和类B的一个实例关联35多重性是和语境有关的图9-15 多重性是和语境有关的36应用UML：两个类之间的多重关联图9-16 多重关联37示例：NextGen POS中的关联图9-17 NextGen POS部分领域模型38示例：Monopoly中的关联图9-18 Monopoly部分领域模型39属性属性(attribute)是对象的逻辑数据值确定概念类的属性是有助的，能够满足当前所开发场景的信息需求。40准则：何时展示属性当需求(例如：用例)建议或暗示需要记住信息时，引入属性。41应用UML：属性表示法图9-19 类和属性42更多表示法图9-20 UML属性表示法在UML中，属性的完整语法是：visibility name:type multiplicity=default property-string43准则：在哪里记录属性需求middleName:0.1等是嵌入到领域模型的需求或领域规则建议把所有这种属性需求置于UP词汇表中（UP词汇表可充当数据字典）44导出属性图9-21 在销售项目中记录售出的商品数量45准则：什么样的属性类型是适当图9-22 使用关联而不是属性表示关系领域模型中属性的类型更应该是数据类型。十分常见的数据类型包括：Boolean,Date,Number,Character,String,Time等，其它常见的类型有Address,Color,Geometrics,Phone Numer,Social Security Number,Universal Product Code(UPC),SKU,ZIP，枚举类型等46准则：何时定义新的数据类型类见P120表9-347准则：通过关联而不是属性来表示概念类之间的关系图9-23 不要用属性表示复杂概念48应用UML：在何处描述这些数据类型类图9-24 表示对象的数据类型特性的两种方式49准则：任何属性都不表示外键图9-25 不要将属性作为外键可以用许多方法来表示对象之间的关系，外键是其中的一种50准则：对数量和单位建模图9-26 对数量建模51示例：NextGen POS中的属性图9-27 NextGen POS的部分领域模型52示例：Monopoly中的属性图9-28 Monopoly的部分领域模型