定义
概念模型表征了待解释的系统的学科共享知识。为了把现实世界中的具体事物抽象、组织为某一资料库管理系统支持的资料模型,人们常常首先将现实世界抽象为信息世界,然后将信息世界转换为机器世界。也就是说,首先把现实世界中的客观对象抽象为某一种信息结构,这种信息结构并不依赖于具体的电脑系统,不是某一个资料库管理系统(DBMS)支持的资料模型,而是概念级的模型,称为概念模型。
简介
概念资料模型是面向使用者、面向现实世界的资料模型,是与DBMS无关的。它主要用来描述一个单位的概念化结构。採用概念资料模型,资料库设计人员可以在设计的开始阶段,把主要精力用于了解和描述现实世界上,而把涉及DBMS的一些技术性的问题延后到设计阶段去考虑。
让读者更易理解,读时有个参考的东西。由于概念模型用于信息世界的建模型,是现实世界到信息世界的第一层抽象,是使用者与资料库设计人员之间进行交流的语言,因此概念模型一方面应该具有较强的语义表达能力,能够方便、直接地表达套用中的各种语义知识,另一方面它还应该简单、清晰、易于使用者理解。由于概念模型在此次的迭代过程非常简单,所以本来计画PASS掉其中的具体分析,不过概念模型的确非常之重要,他是OOD的一个基石。除了用例,应该说概念模型是OO开发过程中另一个充满主观色彩的工件。
然而不同的人对同一个场景进行研究,可能提炼出来的概念模型都不一样,所以说这是颇受主观认识影响的一个过程。然而,概念模型的质量对整个系统的影响至关紧要,因为,所谓的面向对象,就是从这裏开始。
一般来说,构建概念模型的过程与程式员的关系并不大。最适合进行这项活动的人,应该是那些有较深资历的领域专家,极端一点,甚至可以就是最为熟悉自身业务流程的客户代表。只要稍稍学习简单的建模知识,他们就可以胜任了。技术出身的人要做好这个工作,在开始之前他可能首先需要做的就是:忘掉VB,忘掉JAVA,忘掉.Net, 忘掉C++ 。。。
不过,作为开发人员,我比较认可一个思维跳出技术的条框,学习真正从对应现实世界的角度考虑问题的好办法,就是--假想一下,自己正在通过某部电影的故事来製作一个RPG游戏,电影裏的桥段与游戏中的场景相对应,然后思考,其中需要表达哪些不同概念。好吧,试着弄一个简单的例子,这裏,我用《神鬼无间》来试试(不要笑我eld啊)。
构建模型
构建概念模型,需要从场景中提取各种对系统目标有用的概念。通常的方法是通过识别主要的领域辞彙,或者通过已有的概念目录检查表来查找。由于时间关系,我已经预先想好了一些。看过的朋友知道,像卧底、警察、黑社会、情报等等,都是《神鬼无间》这部电影裏的一些核心概念。很自然地,开始时我会倾向于发展这样一个模型:(见右图)
这样看起来比较直观。警察和黑帮成员是两个较大的概念,下面分别有较小的两个子概念。像黄Sir和韩琛这样的角色,是可以很直接地归入到正规警察和普通黑帮成员的範围中去的,而陈永仁和刘健明都分别属于不同的卧底角色。但这样出现了一个问题,就是陈和刘都是同时具有警察、黑帮的双重身份(尽管一个在明,一个在暗)的人,他们都有可能同时拥有警察和黑帮的某些行为。比如陈永仁在拥有黑帮劈友,收数的行为时,也有可能执行警察逮捕,救死扶伤这样的责任,刘健明表面上是警察,暗中也有进行黑帮洗钱的行为。两个人的行为相似,但本质立场不同,怎样在模型中表达出这样的概念呢?
用例的概念模型曾经也想过将卧底同时作为警察和黑帮成员的子概念,但觉得这样比较复杂且僵硬,实现起来也不容易(对不起,我又想到实现了)。后来觉得可以试试将身份和行为概念提取出来,于是建立下面这样的一个模型(见右图):在这个模型中,每个人物可以机动地拥有1个以上的身份,多个行为。每个行为也可以与特定的身份挂钩。这样的话,对表达不同角色的复杂身份就可以比较灵活了。对陈、刘之间的本性问题,又引入价值观这样的概念描述。但可以看到,改变后的模型复杂度提高了,尤其当人物的行为很多的时候,就可能会在其下面出现比较大的概念群了。
用例的概念模型系统的弹性和复杂度的矛盾,是在提炼概念模型时必须慎重思考的问题。
可想而知,如果真的要做成RPG的话,更多的概念需要被提取出来。譬如情感、人际关系、情报、武器、女朋友。。。。。。由于时间关系,就不在这裏乱唱了。这次做的这个粗陋的模型,就权当抛砖引玉吧。
找出模型
最好是能够尽量充分地使用细粒度的概念来描述模型,而避免粗略描述。
这是书中推荐的一条指导原则,我没有从正面理解也没有找到论据去推翻他,这是让我困惑的地方。其他一些指导性的原则包括:不能简单地因为需求说明中没有明显的要求保留某个概念的信息或是概念中没有属性,就去掉概念,在问题领域中,那些只担当纯行为的概念也是存在的。其后便是一个用于搜寻概念的'黑名单',这让我更觉得不可思议,为什麽是这样一个长长的黑名单而不是几条简洁的依据。最后我还是决心把他抄一遍:
概念类目 | 举例 |
物理的或实在的对象 | 销售点终端、飞机 |
规格说明、设计或者事物的描述 | 产品规格说明、航班描述 |
地点 | 商店、机场 |
事务 | 销售、支付、预定 |
线上事务处理项 | 线上销售项 |
人的角色 | 出纳员、飞行员 |
包含其他事物的包容器 | 商店、银行识别号、飞机 |
被包含在包容器内的事物 | 销售商品项、乘客 |
系统外部的其他电脑系统或机械电子设备 | 额度卡授权系统、空中交通控製系统 |
抽象的名词性概念 | 饥饿的人、恐高症 |
组织 | 销售部、对象航线 |
事件 | 销售、抢劫、会议、出航、坠机、着陆 |
过程(通常不用概念来表达,但有时也会用概念来表达过程) | 出售一个产品的过程、预定一个座位的过程 |
规则和策略 | 退货政策、取消政策 |
目录 | 产品目录、零件目录 |
财政收支、工作情况、契约等的记录 | 收据、分类帐目、僱佣契约、维护日志 |
金融工具和服务机构 | 额度卡、股票 |
手册、书籍 | 僱员手册、修理手册 |
抄完了一遍,没有找出一个通用性的指导原则,书中接下来给出的是根据名词性短语找出概念,这让我想起了某一期的程式员中有关于建模的文章,其中的概念模型的建立就是说根据名词来找,想来这是一种极其幼稚的做法了,其中还有这样一种情况,某些名词只作为对象的属性。
建模过程
1,运用概念目录列表或名词性短语找出问题领域中的后选概念
2,绘製概念到概念模型图中
3,为概念增加关联关系
4,为概念增加属性
模型设计
概念模型设计
概念模型不依赖于具体的电脑系统,他是纯粹反映信息需求的概念结构。
建模是在需求分析结果的基础上展开,常常要对资料进行抽象处理。常用的资料抽象方法是'聚集'和'概括'。
E-R方法是设计概念模型时常用的方法。用设计好的ER图再附以相应的说明书可作为阶段成果
概念模型设计可分三步完成:
局部模型
① 确定局部概念模型的範围
② 定义实体
③ 定义联系
④ 确定属性
⑤ 逐一画出所有的局部ER图,并附以相应的说明档案
全局模型
建立全局E-R图的步骤如下:
① 确定公共实体类型
② 合并局部E-R图
③ 消除不一致因素
④ 最佳化全局E-R图
⑤ 画出全局E-R图,并附以相应的说明档案。
模型评审
概念模型的评审分两部分进行:
第一部分是使用者评审。
第二部分是开发人员评审。

















