那个模型空间图绝对经典，对于区分、统一概念有很大帮助，我觉得对于从一个组织的业务系统到计算机的软件系统映射，也就是软件系统的分析、设计，这种维度的划分已经能很清晰地描述了，对于像时间、行业等这些维度没必要加入了，我想这些都属于项目管理了。过多的加入反倒让人理解有困难，呵呵

文章对我有很大帮助，不过还有一些不太清晰的地方，能不能解释一下核心用例模型和系统用例模型的区别，一般业务对象模型和领域模型的区别？不会就是简单的现象与本质的区别吧，呵呵

很高兴文章对圈友有帮助.

abel_zhyb提到核心用例模型和系统用例模型的区别,还有一般具体的业务对象模型和领域模型的区别.

我确实是从现象到本质的维度来划分的,我和abel_zhyb理解不同的是,我认为从现象到本质并不那么简单.

核心用例是从具体的操作流中抽取出操作的价值流对用例进行阐释的形式.我认为,具体有形的操作步骤的描述是对现象的描述,而对对应具体操作步骤背后所实现的价值的描述,则是对本质的描述.

用切削苹果的用例来说明如下:

核心用例模型会这样描述:

1.让苹果表面干净;

2.去掉苹果表皮;

3.将苹果变成小块.

而具体操作流用例则会这样描述:

1.将苹果用干净的自来水冲洗;

2.用水果刀压在苹果一端表皮下;

3.旋转苹果,水果刀将苹果的表皮剔下;

4.将剔掉皮的苹果置于砧板之上;

5.用水果刀将苹果切成片装;

6.将苹果片装盘.

由上可知,核心用例是对用例从价值流角度进行阐释,而操作流用例则是从具体的操作流角度进行描述,一个核心用例可以对应多种不同形式的操作流用例.

严格地说,

系统用例和核心用例的概念并非并列可比的概念,系统用例是和业务用例并列的,是从业务组织到计算机系统建模尺度大小这一维来并列的.

而核心用例则是和操作流用例并列的,无论是系统用例还是业务用例,都可以用核心用例和操作流用例的方式来表达.而这一维,正是从现象到本质的维度.

问统用例和核心用例的区别,这种问法就已经将模型参照系搞错乱了.这些概念本身并不难理解,关键是要纠正先入为主的错乱概念比从新理解一个正确的概念会困难的多.

很多开发人员认为搞清楚基本概念不那么重要,但他们在实际工作中确实会面临很多困惑,他们并不知道,这些困惑的来由就是他们没有搞清楚这些基本概念.

关于一般业务对象模型和领域模型的区别的问题,是引起混淆最多的问题之一.如果你对10个印刷厂的业务用例分别进行了业务对象建模,那么,你可能会发现这些对象模型会有很多相同和相似的地方,比如,相同的业务对象,相似的对象关系等,于是,你可以从中抽取出一个抽象的对象模型,这个抽象的对象模型,可以用来表达一般的印刷厂业务实现的机制.这就成了领域模型,既然领域模型是对具体业务对象模型的抽取和抽象的结果,那么,就会具有典型性和局部性.因而,RUP说领域模型是业务对象模型的一个子集,其实,是一个泛子集.

在OMT方法中,领域模型指的是软件所实现的业务中的信息对象的集合,应该是系统的对象模型.而RUP又说是业务对象模型的子集.这正是概念发展和进步的结果.从业务到系统两段式的开发模式来看,领域模型正是站在本质的层次来看业务对象模型所看到的部分,这部分,正好将是信息化的重点和核心部分,因而,将会在系统建模中作为自动化和可重用设计的重点部分.因为越本质的东西,越稳定,不易变化,越可重复进行,越易工具化.这正是软件追求的目标.如果一个程序编出来只为了运行一次,那么,它绝对不可以称为是软件.

所以,领域模型也可以看成是从业务模型到系统模型的交接界上处于业务这边的模型.

>From: "周喜宏" <hahong@163.com>
>To: "邱嘉文" <babituo@hotmail.com>
>Subject: 拜读《从软件的"胚"谈到模型的参照系》后，有些问题，请指教。
>Date: Wed, 29 Nov 2006 15:43:58 +0800 (CST)
>
>邱老师：
>     您好！今天看到你的文章对我影响很大！但文中一些词的意思，我不太理解，麻烦您能帮我解答一下：
>  (1)参照系
>  (2)业务部件
>  (3)软件部件
>
>
>
>                                                           周喜宏

周喜宏朋友,您好!
    很高兴鄙文能引起您的关注.
    关于参照系的概念,就是借鉴几何坐标系的概念,就是为被讨论的事物进行概念定位的一组分类概念.
    关于业务部件和软件部件,您可以参照我的另一篇blog分享文章"迎接业务部件软件时代的到来".链接如下:http://www.vsharing.com/Blog/Smarthings/A408560.html.

babituo

真的很经典~~