首先,描述文档中找到名词,将所有可能的名词全部罗列出来,它们将是概念类。
准则:
如果我们认为某一个概念类X不是现实世界中的数字或文本,那么X可能是概念类而不是属性。
例如,sale概念类下是否该有一个store的属性?实际上,store是一个实际的事物,应该用store概念类来描述。
又如,在flight概念类下是否应该有一个destination的属性?看似destination只是一个字符串,但是实际上,destination是一个airport,每一个airport都是一个实际的存在的事物,所以,应该有一个airport的概念类。
然而,似乎利用如上准则可以解决所有数字或文本的问题。但是,如“ObjectBerger”问题值得我们重新思考。这个经典的问题是说,如果所有的berger信息都存在Berger类里,那么当每一个汉堡卖完就从数据库中删除,其信息页随之删除。最终的问题是,所有汉堡卖完,就再也找不到Berger的信息了,甚至不知道berger长什么样子或者多少钱。是不是很郁闷?除此之外,还有一个问题是,berger类会创建很多,但是这些描述信息往往相同,比如价格、大小等,所以,不必要每个berger类里都重复存放这些信息。这里,我们就使用“描述”类,如ProductDescription。
准则:
需要有关商品或服务的描述,独立于任何商品或服务的现有实例。
删除其所描述的事物实例后,信息丢失,但这些信息是需要维护的,但是被错误的与所删除的事物关联起来。
减少冗余或重复的信息。