求建模意见及建议

07-07-10 yuzhi

对于一般的程序员来说对于建模可能是既熟悉又陌生的一个东西,熟悉的是天天在网上或者周围的人天天都在说这个名词,陌生的是当我们真正拿起建模工具或者理论用到现实的时候又变得不知怎么下手,我就是其中的一位.
我的理解现在软件开方面的建模是不是应该包括数据库建模及业务方面的建模(有误请指正,谢谢!),对于这两方面我们这些程序员应该怎样学习和规划一下自己这方面的能力的,请大家展开讨论,谢谢!!!!

banq

2007-07-10 16:51

建模现在是对象建模，数据库建模已经是过去时代，现在是OO时代，从分析设计到编程都是围绕对象，数据库只是在部署时进行配置，数据库已经和服务器或操作系统或JDK都变成系统管理员的事情，怎么可能还会上升到软件最高阶段建模呢？

对象建模就是买本Evans DDD书看看，学习UML。对象建模不是每个人学完这些知识就能拿起建模工具就能下手的，就象不是每个人拿起油画笔就能画油画一样，这是一个专业，而且需要有多年项目实践经验。

所以，建模也不需要软件背景，只要有专业领域背景就可以，而且有自己对业务的抽象概况思维总结能力，说白了，非得是某个领域专家，比如企业管理软件建模，他就是管理专家；财务软件建模，他就是财务专家等等。

建模其实不是程序员的事情，充其量，一些老程序员由于做某个软件做了N多年，对业务系统也滚瓜烂熟，这时他可以兼做建模，但是不是说软件知识是建模必须的。

可以说：建模是业务专家做的事情，不是程序员做的。所以，从这点可以看出所谓数据库建模更是扯淡了，让对软件不懂的业务专家先学习数据库，再对自己业务建模，
简直是笑话。

什么是业务专家

http://www.jdon.com/jivejdon/thread/32044.html

[该贴被banq于2007年07月10日 16:53修改过]

yuzhi

2007-07-11 09:33

首先谢谢banq大哥的回复,有以下几个问题
1数据库建模已经是过去时代?
难道数据库就真的该终结了吗,下载是像banq您所注的"数据库时代的终结"那样不应该存在,但是现在的系统架构为什么还会提出一个持久层的概念呢?

2非得是某个领域专家?建模其实不是程序员的事情?
我们都是一些程序员起家,对于作行业软件我们的业务知识是要在开发的过程当中不断的积累,那我们是不是就不能往这方面走呢,只能一本正经的作开发,并且专家的话只是对行业有资深的经理,但是对软件的理论应该比我们开发人员可能会欠缺点,我觉得建模应该是建模是业务专家和软件开发人员共同的一件事情?

banq

2007-07-16 14:32

>但是现在的系统架构为什么还会提出一个持久层的概念呢?
数据库是持久层一个具体实现，两者不是同一个概念，保存文件也属于持久层一种手段。正是提出持久层这样一个抽象概念，就将数据库更从架构设计中抹去了，举个例子，本来高层开会时，老是提你的名字，但是后来，不提你的名字，提你部门名字，虽然你还在这个部门，并且做主管，但是你肯定感觉自己个人重要性下降，有些不爽吧。开个玩笑。

>我觉得建模应该是建模是业务专家和软件开发人员共同的一件事情
原来大家是这么认为，但是实践证明，两者很难协调沟通，就象鸡和鸭讲话一样，尽管有UML这个共同语言，但是对于同一个UML符合，两种人员会从自己的观点，也就是从两个不同观点去理解。Evans DDD伟大革命之处就在于，他提出建模人员从分析设计全部包揽，因为数据库等具体知识已经从分析设计领域剔除出去，对于建模人员进入设计领域已经没有任何技术障碍。然后开发人员再依赖框架来实现建模人员的分析设计结果，甚至无需开发人员，通过MDSD工具可以直接生成代码。TSS最近介绍了这方面一个工具Sculptor，可生成spring+Hibernate多层架构代码：
http://www.theserverside.com/tt/articles/article.tss?l=ProductivityWithSculptor

你问我未来软件人员的位置在哪里？两个：
1. 依靠面向过程设计那些旧代码苟延残喘。
2. 依靠OO思想，掌握机器不能替代的复杂软件设计编码工作。

软件人员和工人一样，也会遭受来自自动化流水线的挑战，下岗或转岗。这是必然的。

[该贴被banq于2007年07月17日 13:24修改过]