没有合适的资源?快使用搜索试试~ 我知道了~
从软件的胚谈到模型的参照系,从本质上让你理解建模的核心理念。
资源详情
资源评论
资源推荐
从软件的“胚”谈到模型的参照系
最近,网友 god2000 在 UMLChina 上发起了一个关于建模维度的话题,这与我前段时
间的一个想法非常近似,我的想法是:“能不能为模型本身建立一个系统化描述的参照系,
来统一大家对模型和建模过程本身的认识呢?”
原文(god2000 于 2003/05/19 14:32 粘贴)
标题:从分析到实现,几个维度---用户功能
我们的工作从功能定义开始或需求分析开始,到一个可运转的系统结束。考察在这个过
程中发生了什么
一、用户功能定义
我要盖一座房子,三室一厅,两个卧室,一个我和老婆,一个给老爷子。一间书房,一
间客厅,需要厨卫。
这些能给一个建筑设计者足够的信息拿出一个初步的供讨论的方案
一些功能:能睡、招待客人、读书、做饭
支持这些功能的部件:床、招待客人的桌子、书桌、电灯、厨具
隐含的部件:管道、电路等。
对于软件我们能想些什么?
书店老板: 我需要每天看到我卖了哪些书,挣了多少钱,这句话隐含了什么。
我理解 god2000 的意思是:我们从软件的分析走到实现是一个过程,那么,我们应该
怎样来认识这个过程呢?god2000 提出了他的第一个思路,就是:考察我们是如何根据用户
需要的功能找到软件的实现部件的。实际上,这是从建模过程本身的功能角度来认识建模过
程的思路。
这个帖子刚贴出来的一段时间并没有引来太多的注意。有几个赞许的发言都只是看到
了帖子中的和建筑工程对比说明的形式。
我注意到 god2000 的帖子中存在一个非常容易产生的,但并不十分充分的判断:认为
用户的需求表达背后隐藏的是满足这些需求的软件构件,而建模的过程正好是发现和定义隐
藏在这些需求表达背后的软件构件。之所以说这个判断不充分,是因为我们会从里面看到结
构化方法的影子。于是,我发表了一篇题为“是什么隐藏在背后?”的回帖。
原文(babituo 于 2003/10/08 10:22 粘贴)
标题:是什么隐含在背后?
不同的人需要(适合)从不同的点切入进行建模,是对的。
但最终模型的表达是应改具备同样的层次结构的。
用户谈到的可能是功能的要求,也可能就是直接的实现某种功能要求的部件的要求,
当然,还有可能是他的目的。
到底是什么隐藏在背后呢?
“隐藏在背后”并不是一个简单的参照系的相对变换,而是在变与不变之间的层析。
不变的就是“在背后”的,可变的是在不变的胚的基础上加入个性化信息才得到变化。个性
化信息是如何分层逐渐加入的,从不同的路径加入不同的个性化信息如何使得本质相同的东
西,看上去有不同的表象?
软件模型无非就是一个本质的胚向现实世界和计算机世界两个不同的方向进行个性
化的演化的结果。我们从现实世界进入,找到那个胚的过程就是分析,从那个胚向计算机世
界演绎的过程就是设计。
隐藏在背后的当然是用户的目的,用户会为实现自己的目的而接受适当的功能设置,
为实现功能设置而接受喜好的部件。
用户只能谈出自己清楚的内容,在目标-功能-部件的三个层次上,用户往往不能贯通。
分析师的目的就是帮助用户在现有业务方向上贯通这三个层次的需求。设计师的目的就是帮
助用户在新的计算机应用的方向上贯通这三个层次的需求。
用例模型就是希望通过用户对过程活动的交互行为来捕获用户的本质目的。这个层次
不涉及功能,也不涉及部件。因为目的必须通过交互行为来显化,所以才有用例模型。
用例模型不是以功能和部件为核心,而是以用户和用户的目标为核心的。复杂系统的
目标和功能存在多对多的映射关系。简单系统则可以是一对一的关系,这样才导致对用户目
标的分解就是对功能的分解的看法。“以用户为核心的设计”决不是一句广告词而已,他的
对立面是“以软件功能为核心的设计”。
我们绝大部分的分析师还没有完成这个观念的转变,因而会对用例建模存在认识的局
限。但这并不影响他们在较浅的层次完成现实世界和计算机世界的转译,只是这种转译相对
脆弱。
由于网站讨论组贴图不怎么方便,我的上述表达显得过于抽象,不太容易理解。尤其,
在其中我用了几个数学化和哲学化的概念,如:“胚”、“世界”、“层次”等。这几个概念获
得了一些人的认同,同时也带来了另外一些人的不解。
其实,我的回帖只是把我内心里早有的这些幅画面用文字描述了一遍而已:
图 1 是我认为 god2000 帖子想表达的思想;
图 2 是我的回帖想表达的思想。
图中带数字的箭头表示信息流,数字表示信息产生的相对次序。如果对比两幅图再读
我和 god2000 的上述讨论,应该会得到清晰的认识:图 1 只是看到了图 2 的一部分信息。
背后 表面
④
③
②
①
分析员
用户
软
件
部
件
需
求
业
务
功
能
需
求
图 1
设计
分析
部件层
功能层
目标层
背后
隐藏
⑿
软件世界业务世界
本质规律(难变)
表面现象(易变)
前面
⒀
⑾
⑩
软
⑨
件的“胚”
⑥
⑧
⑦
⑤
④
③
②①
分析员 用户
用户的表达
业务目的需求
软件功能需求
业务部件需求 软件部件需求
业务功能需求
图 2
请注意图 2 的三个红色箭头,就是我在讨论中所述的“不同层次的转译”。不经过更深
层次转译而开发的软件更脆弱,更难重用,生命周期更短。因而就有了软件开发水平的高低
之分。
虽然论坛上没有配图,但还是有网友表示看懂了我的发言,但同时也有“在看懂了的
基础上提出的质疑”。通常,这种质疑在沟通中是非常受欢迎的。提出质疑的是 orangutang
网友。他质疑的内容如下:
原文(orangutang 于 2003/10/24 02:06 粘贴)
标题:不错,全看懂了,完全同意,还有点儿问题
用例视图和商业模型他们的关系是怎么样的呢?
用例视图是和用户的交互吧,然后工程师将用例视图转换成商业模型。商业模型中的
信息部分来自于用例视图,还有一部分来自于用户直接给出的信息,还有从其它途径来的
么?比如一些技术上的?
似乎如果拿商业模型直接和用户交互的话,太费劲。
原文中说的那个最终模型(第二行)就是指的商业模型么?
我认为,只要商业模型建对了,就应该覆盖用户所有的目标了。
似乎,用户的所有目的最后都体现在这个商业模型中了。那用例视图就变成一种辅助
手段了。
其实用户不能理解的就是面向对象技术,而建立商业模型就会用到这种技术,所以用
户不能与商业模型直接交互。
说得比较乱,呵呵。
质疑中主要用到了两个概念:“用例视图”和“商业模型”。从其表述的上下文内容分
析:其“用例视图”指的是需求模型,而“商业模型”指的是软件的面向对象模型。
而在我的概念中:
“用例图”只是表达用例模型的一种视图,用例模型能用到的视图还有活动图,顺序
剩余11页未读,继续阅读
Dennis3408
- 粉丝: 0
- 资源: 3
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0