《UML和模式应用》之领域模型
简介：领域模型是OO分析中最重要和经典的模型。它阐述了领域中的重要概念。本次将介绍有关领域模型的基本技术。
领域模型：是对领域内的概念类或现实世界中对象的可视化表示[MO95,Fowler96]。领域模型也称为概念模型，领域对象模型和分析对象模型。
UP对领域模型的定义是，可以在业务建模科目中创建的制品之一。更准确地讲，UP领域模型是UP业务对对象模型（BOM）的特化，“专用于解释业务领域中重要的‘事物’和产品”[RUP]。 BOM覆盖整个业务及其所有子域。
应用UML表示法，领域模型被描述为一组没有定义操作的类图。它提供了概念透视图。它可以展示：
1）领域类之间的关联
2）概念类之间的关联
3）概念类的属性
领域模型是可视化字典，表示领域的重要抽象、领域词汇和领域的内容信息。
领域模型是软件业务对象图吗？
UP领域模型是对所关注的现实世界领域中事物的可视化，而不是诸如JAVA或C#类的软件对象，或有职责软件对象。因此，以下元素不适用于领域模型：
1）软件制品
2）职责或方法
概念类：概念类是思想、事物或对象。概念类可以从其符号、内涵和外延来考虑。
符号：表示概念类的词语或图形
内涵：概念类的定义
外延：概念类所适用的一组示例
领域模型和数据模型是一回事吗？
领域模型不是数据模型，所以在领域模型里，并不会排除需求中没有明确要求记录其相关信息的类，也不会排除没有属性的概念类。例如，没有属性的概念类是合法的，或者是领域内充当纯行为角色而不是信息角色的概念类也是有效的。
如何创建领域模型
1）寻找概念类
2）将其绘制为UML类图中的类
3）添加关联和属性。
如何找到概念类
1）重用和修改现有的模型：这是首要、最佳且最简单的方法。
2）使用分类列表
3）通过识别名词短语寻找概念类
领域模型是重要领域概念和词汇的可视化。其中某些术语来源于用例。加外一些术语则源于其他文档，或是专家的想法。
下面是几个准则
准则：敏捷建模——绘制类图的草图
准则：敏捷建模——是否使用建模工具维护模型
如果采用敏捷建模方法，创建领域模型的目的是为了快速理解和沟通大致的关键概念。完美不是目的，敏捷模型在创建后通常很快就被抛弃了。基于这种观点，则没有理由去维护或更新这些模型，但是也不意味着更新模型就是错的。
准则：报表对象——模型中是否要包括“票据”
票据是POS领域的重要术语。但也许它只是销售和支付数据的报表，因此是一种信息的重复，以下是一些因素的考虑：
1）一般来说，在领域模型中显示其他信息的报表并没有意义，因为其所有信息都是源于或复制于信息源的。这是排除它的理由
2）另一方面，就业务规则而言，它有特殊的作用：通常持有票据的人有退货的权利，这是在模型中要表示它的原因
准则：像地图绘制者一样思考：使用领域术语
准则：如何对非现实世界建模
有些软件系统的领域与自然领域或业务领域几乎没有类似之处，例如电信软件。然而还是有可能为这些领域创建领域模型。此时需要高度的抽象，对常见的非OO设计进行回顾，并且认真汲取领域专家所使用的核心词汇和概念。
2）使用分类列表
3）通过识别名词短语寻找概念类
领域模型是重要领域概念和词汇的可视化。其中某些术语来源于用例。加外一些术语则源于其他文档，或是专家的想法。
下面是几个准则
准则：敏捷建模——绘制类图的草图
准则：敏捷建模——是否使用建模工具维护模型
如果采用敏捷建模方法，创建领域模型的目的是为了快速理解和沟通大致的关键概念。完美不是目的，敏捷模型在创建后通常很快就被抛弃了。基于这种观点，则没有理由去维护或更新这些模型，但是也不意味着更新模型就是错的。
准则：报表对象——模型中是否要包括“票据”
票据是POS领域的重要术语。但也许它只是销售和支付数据的报表，因此是一种信息的重复，以下是一些因素的考虑：
1）一般来说，在领域模型中显示其他信息的报表并没有意义，因为其所有信息都是源于或复制于信息源的。这是排除它的理由
2）另一方面，就业务规则而言，它有特殊的作用：通常持有票据的人有退货的权利，这是在模型中要表示它的原因
准则：像地图绘制者一样思考：使用领域术语
准则：如何对非现实世界建模
有些软件系统的领域与自然领域或业务领域几乎没有类似之处，例如电信软件。然而还是有可能为这些领域创建领域模型。此时需要高度的抽象，对常见的非OO设计进行回顾，并且认真汲取领域专家所使用的核心词汇和概念。
准则：属性和类的常见错误
在创建领域模型时最常见的错误是，把应该是概念类的事物表示为属性。
如果我们认为某概念类X不是现实世界中的数字或文本，那么X可能是概念类而不是属性
准则：何时使用“描述”类建模？
描述类包含描述其他事物的信息，例如，ProductDescription记录Item的价格、图片和文字描述。这种类最早被命名为项目—描述类（Item—Descriptor）模式
在创建领域模型时最常见的错误是，把应该是概念类的事物表示为属性。
如果我们认为某概念类X不是现实世界中的数字或文本，那么X可能是概念类而不是属性
准则：何时使用“描述”类建模？
描述类包含描述其他事物的信息，例如，ProductDescription记录Item的价格、图片和文字描述。这种类最早被命名为项目—描述类（Item—Descriptor）模式
准则：何时需要描述类？
在以下情况下需要增加描述类（例如，ProductDescription）：
1）需要有关商品或服务的描述，独立于任何商品或服务的现有实例
2）删除其所有描述事物的实例后，导致信息丢失，而这些信息是需要维护的，但是被错误地与所删除的事物关联起来
3）减少冗余或重复信息
在以下情况下需要增加描述类（例如，ProductDescription）：
1）需要有关商品或服务的描述，独立于任何商品或服务的现有实例
2）删除其所有描述事物的实例后，导致信息丢失，而这些信息是需要维护的，但是被错误地与所删除的事物关联起来
3）减少冗余或重复信息
关联：关联是类之间的关系，表示有意义和值得关注的连接
在UML中，关联被定义为“两个式多个类元之间的主义联系，涉及这些元实例之间的连接”
在UML中，关联被定义为“两个式多个类元之间的主义联系，涉及这些元实例之间的连接”
关联图
准则：何时表示关联？
准则：何时表示关联？
由于领域模型是从概念角度出发的，所以是否需要记录关联，要基于现实世界的需要，而不是基于软件的需要，尽管在实现过程中，会有出现大量对关联的需要。
在领域模型中要考虑如下关联：
1）如果存在需要保持一段时间的关系，将这种主义表示为关联
2）从常见关联列表中派生的关联
准则：为什么应该避免加入大量关联？
我们要避免在领域模型中加入太多的关联。回顾离散数学的相关知识，可以知道，在具有N个节点的图中，节点间有（n*(n-1)）/2个关联，这可能是个非常大的数值。连线太多会产生“视觉干扰”，使图变得混乱。所在要谨慎地增加关联线。
准则：在UML中如何对关联命名
以“类名—动词短语—类名”的格式为关联命名，其中的动词短语构成了可读的和有意义的顺序。
例如，Sale Paid—by CashPayment 反面示例，应改为Sale Uses CashPayment
Player Is—on Square 反面示例，应以为 Player Has Square
关联名称应该使用首字母大写的形式。在UML中，类元应该首字母大写。以下是复合性关联名称的两种常见并且等价的合法格式：
Records—current
在领域模型中要考虑如下关联：
1）如果存在需要保持一段时间的关系，将这种主义表示为关联
2）从常见关联列表中派生的关联
准则：为什么应该避免加入大量关联？
我们要避免在领域模型中加入太多的关联。回顾离散数学的相关知识，可以知道，在具有N个节点的图中，节点间有（n*(n-1)）/2个关联，这可能是个非常大的数值。连线太多会产生“视觉干扰”，使图变得混乱。所在要谨慎地增加关联线。
准则：在UML中如何对关联命名
以“类名—动词短语—类名”的格式为关联命名，其中的动词短语构成了可读的和有意义的顺序。
例如，Sale Paid—by CashPayment 反面示例，应改为Sale Uses CashPayment
Player Is—on Square 反面示例，应以为 Player Has Square
关联名称应该使用首字母大写的形式。在UML中，类元应该首字母大写。以下是复合性关联名称的两种常见并且等价的合法格式：
Records—current
RecordsCurrent
应用UML：角色
关联的每一端称为角色。角色具有如下可选项：
1）多重性表达式
2）名称
3）导航
应用UML：多重性
多重性定义了类A有多少个实例可以和类B的一个实例关联
应用UML：角色
关联的每一端称为角色。角色具有如下可选项：
1）多重性表达式
2）名称
3）导航
应用UML：多重性
多重性定义了类A有多少个实例可以和类B的一个实例关联
下图的Store的一个实例可以和Item的“多个”（*表示零个或多个）实例关联
关联性多重性
应用UML：两个类之间的多重关联
在UML类图中，两个类之间可能会有多重关联，这并不罕见。
属性：是对象的逻辑数据值
准则：何时展示属性
当需求建议或暗示需要记住信息时，引入属性。
例如，在处理销售用例中的票据通常含有工期和时间、店名和地址以及收银员ID等
准则：何时展示属性
当需求建议或暗示需要记住信息时，引入属性。
例如，在处理销售用例中的票据通常含有工期和时间、店名和地址以及收银员ID等
因此，
1）Sale需要dataTime属性
2）Store需要name和address属性
3）Cashier需要ID属性
2）Store需要name和address属性
3）Cashier需要ID属性
在UML中，属性的完整语法是：
visibility name：type multiplicity=default{property—string}
visibility name：type multiplicity=default{property—string}
UML属性表示法
准则：什么样的属性类型是适当的
准则：什么样的属性类型是适当的
十分常见的数据类型包括：Boolean、Date(or DataTime)、Number、Character、String(Text)和Time等
准则：何时定义新的数据类型类
下述情况下，在领域模型里，把最初被认为是数字或字符串的数据类型表示为新的数据类型类：
1）由不同的小节组成
2）具有与之相关的操作，例如解析或校验
3）具有其他属性
4）单位的数量
5）具有以上性质的一个或多个类型的抽象
准则：任何属性都不表示外键
领域模型里的属性不应该用于表示概念类的关系。违反这一原则的常见情况是像在关系数据库设计中的那样增加一种外键属性，用以关联两个类型。再强调一次，应该使用关联而不是属性来将类型关联起来。
UP中的领域模型
初始：初始阶段决不会发起领域模型，因为初始阶段的目标不是进行严格的调查，而是决定项目是否值得在细化阶段进行深入调查
细化：领域模型主要是在细化阶段的迭代中创建的，这种里最需要理解那些重要概念，并且会通过设计工作将其映射为软件类。
UP业务对象模型与领域模型
UP领域模型是较为少见的UP业务对象模型（BOM）的正式变体。不要与其他对BOM的定义混淆，UP BOM是一种描述整个业务的企业模型。BOM可以用来进行业务过程或再工程，而不依赖于任何软件应用。
结束语：看了《UML和模式应用》第九章：领域模型后写的这篇文章，基本上是摘了点书上我觉得关键的东西，希望能对和我一样在学习UML的朋友来说，能有点帮助。。。。
