1，识别概念类
我们的目标是在相关分析中创建有意义的概念类，比如说创建“处理销售”用例中的相
关概念类。一个方法是通过建立一个候选的概念类的列表，来开始建立模型。但是，更多的
是使用名词短语分析找出概念类的方法，然后把它们作为候选的概念类或者属性。使用这种
方法必须十分小心，从名词机械的映射肯定是不行的，而且自然语言中的单词本来就是模棱
两可的。不过，这仍然是灵感的另一种来源。
一般来说，用大量细粒度的概念类来充分描述概念模型，比粗略描述要好。下面是识别
概念类的一些指导原则：
不要认为概念模型中概念类越少越好，情况往往恰恰相反。
在初始识别阶段往往会漏掉一些概念类，在后面考虑属性和关联的时候才会发现
它，这是应该把它加上。
不要仅仅因为需求中没有要求保留一些概念类的信息，或者因为概念类没有属性，
就排除掉这个概念类。
无属性的概念类，或者在问题域里面仅仅担当行为的角色，而非信息的角色的概念类，
都可以是有效的概念类。
2，概念类识别的指导原则
1）事物的命名和建模
概念模型是问题域中的概念或这是事物的地图，所以地图绘制员的策略，也适用于概念
模型的建模。
使用地域中已有的地名（和城市名相同）
排除不相关的特性（比如居民人数）
不添加不属于某个地方的事物（比如虚构的山川）
以此，我们建议使用如下的原则：
给概念模型建模，要使用问题域中的词汇。
把和当前不相关的概念类排除在问题域之外。
概念模型应该排除不在当前考虑下的问题域中的事物。
2）在识别概念类的时候一个常犯的错误
在建立概念模型的时候，最常犯的一个错误就是把原本是类的事物当作属性来处理。
Store（商店）是 Sale（出售）的一个属性呢？还是单独的概念类 Store？大部分的属性有一个
特征，就是它的性质是数字或者文本。而商店不是数字和文本，所以 Store 应该是个类。
另一个例子：考虑一下飞机订票的问题，Destination（目的地）应该是 Flight（航班）的
属性呢还是一个单独的类 Airport（包括属性 name）。在现实世界中，目的地机场并不是数字
和文本，它是一个占地面积很大的事物，所以应该是个概念类。
建议：如果我们举棋不定，最好把这样的事物当做一个单独的概念类，因为概念模型中，
属性非常少见。
3，分析相似的概念类
有一些情况是比较不太容易处理的。举个例子，我们来分析一下“Register（记录）”和
“POST（终端）”这两个概念。POST 作为一个销售终端，可以是客户端任何终点的设备（用
户 PC，无线 PDA），但早期商店是需要一个设备来记录（Register）销售。而 POST 实际上
也需要这个能力。可见，Register 是一个更具抽象性的概念，在概念模型中，是不是应该用
Register 而不是 POST 吗？
我们应该知道，概念模型其实没有绝对正确和错误之分，只有可用性大小的区分。根据
绘图员原则，POST 是一个分析中常见的术语，从熟悉和传递信息的角度，POST 是一个有用
的符号。但是，从模型的抽象和软件实现相互独立的目标来看，Register 是一个更具吸引力
和可用性的表达，它可以方便的表达记录销售位置的概念，也可以表达不同的终端设备（如
POST）。两种方式各具优点，关键是看你的概念类重点是表达什么信息。这也是一个架构师
必备的能力—抓住重点。
4，为非现实世界建模
一些业务分析有自己独特的概念，只要这些概念是在业内被认可的，同样可以创建概念
类，比如在电信业可以建立这样的概念类：消息（Message）、连接（Connection）、端口（Port）、
对话（Dialog）、路由（Route）、协议（Protocol）等。
5，规格说明或者描述概念类
在概念模型中，对概念类作规格说明的需求是相当普遍的，因此它值得我们来强调。假
定有下面的情形：
一个 Item 实例代表商店中一个实际存在的商品
一个 Item 表达一个实际存在的商品，它有价格，ID 两个描述信息
每次卖掉一个商品，就从软件中删掉一个实例。
如果我们是这样来表达：
那很可能会认为随着商品的卖出，它的价格也删掉了，显然这是不对的。比较好的表达
方式是这样的：
1）何时需要规格说明类
在下面的情况下，需要添加概念类的说明类：
商品或服务的信息描述，独立于商品或者服务当前已经存在的任何实例。
删除所描述的事物，会导致维护信息的丢失。
希望减少冗余或者重复的信息。
2）服务的描述
作为概念类的实例可以是一次服务而不是一件商品，比如航空公司的航班服务。假定航
空公司由于事故取消了 6 个月的航班，这时它对应的 Flight（航班）软件对象也在计算机中
删除了，那么航空公司就不再有航班记录了。所以比较好的办法是添加一个 FlightDestination
（航班目的）的规格描述类，请看下面的例子。