建立领域模型
简介
领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。
识别候选对象与类
发现对象与类的方法
（1）概念类分类表
就是事先分好类，然后由分析人员在需求信息中寻找相应类别的候选对象进行确定和归纳，形成概念类。
- 顾客向系统提起查询请求。
- 系统根据请求为顾客提供CD的推荐列表。
- 顾客在推荐列表中选定一个CD，然后要求查看详细的信息。
- 系统为顾客提供选定CD的详细信息。
- 顾客购买选定的CD。
- 顾客离开。
图一：
(2)名词分析
从文本表述中提取有关的名词和名词短语，作为候选对象，然后对候选对象经行分析，初步确定感念类。
如下（加粗的为候选对象）：
- 顾客向系统提起查询请求。
- 系统根据请求为顾客提供CD的推荐列表。
- 顾客在推荐列表中选定一个CD，然后要求查看详细的信息。
- 系统为顾客提供选定CD的详细信息。
- 顾客购买选定的CD。
- 顾客离开。
（3）行为分析
行为分析是从需求描述中搜索及物动词，我们都知道及物动词前后的是主动对象和被动对象，把他们作为候选对象。
图二:
第7行和第15行是“无”，因为用户的个人行为和电梯系统无关，不属于系统行为。
确定概念类
确定概念类的准则
主要是看候选类是否具有状态（类的属性值）和行为特征（对类对象的操作）。
候选类既有状态又有行为，那么它应该是对立存在的概念类。例如候选类~“商品”和“价格”，商品同时具有状态和行为，而价格只有状态，顾客会查询商品信息，里面就包含价格，而顾客不会凭空查询价格。价格应该作为商品的属性存在。
如果候选类只有行为没有状态说明出现了纰漏。
示例
-
图一的修正
概念列中的详细信息不能作为概念类，因为它只有状态没有行为。
-
图二的修正
摒弃的对象：
用户：系统之外的对象，提供数据输入。 第i,j层：只有状态没有行为。
建立类之间的关联
在得到孤立的概念类后，要建立他们之间的关联，把它们联系起来。
两个方面着手：
一：分析问题域内的静态结构关系，发现静态类的关系。
二：分析概念类的协作。
-
保证类之间写作所必需的可见性。如果两个对象实例需要实现互相之间的写作，那么至少它们中的一个对象实例要持有另一个现象实例的链接(如：主键和外键)。在保证可见性的情况下写作才能成为可能。因此，如果两个类存在写作关系，那么它们就应该具有能够保证可见性的管理。为保证类之间写作而建立的关联时必要关联，是对象模型必不可少的部分。
-
适当使用问题域内的关联，增强领域模型的可理解性。有些类之间不需要互相协作（如：包含），但是它们的对象实例在问题域内存在某些重要而且固定的关系。这些关系式问题域特性的必要部分，因此需要为这些关系建立关联以增强领域模型的可理解性。对问题域内关系的识别要适可而止，因为问题域内的关系式复杂而繁多的，它们建立太多的关联不仅不能有效地表示领域模型，反而会是的领域模型变得混乱。
-
不要再关联的识别上花费太多的时间。识别概念类比识别关联更加重要。一方面是因为遗漏的概念类比较难以发现，而遗漏的关联则很容易在后续的处理阶段得到建立。另一方面是因为常常有些深层次的关联发现起来非常费时，但带来的好处不大。
-
避免显示冗余和导出的关联。发现关联后使用合适的动词短语为关联命名，描述每个关联端的角色和多重性。关联名称通常按照自上至下、至左至右的方式白哦大概念类之间的关系。在分析阶段，一般不会描述关联的方向和关联端的可见性。不过在非常必要的情况下（如存在重要的约束或者某些类有特殊要求），也可以描述关联的方向而活关联端的可见性。
用图一来举例:
需要协作的概念类~1.顾客（发起）购买（选择）CD。
问题域内的联系~1.查询请求（产生）CD推荐列表。2.CD推荐列表（包括）CD。
图：