|
这个主题共有 31 回复 ／ 3 页 [
1 2 3
下一页
]
|
|
|
|
|
|
系统分析概念：四色原型
|
发表: 2006年02月19日 12:23
|
回复
|
|
|
|
|
|
|
|
Re: 系统分析概念：四色原型
|
发表: 2006年02月20日 12:11
|
回复
|
|
|
|
|
|
|
|
Re: 系统分析概念：四色原型
|
发表: 2006年02月22日 12:49
|
回复
|
|
|
非常好的一篇文章，大哥能不能再多弄些关于对业务领域建模方面的好文章呀
|
|
|
|
|
|
Re: 系统分析概念：四色原型
|
发表: 2006年02月23日 16:22
|
回复
|
|
领域建模文章会在本站继续下去，最终明白MDA的真相。
楼上说没看懂，我感觉很郁闷，能否提出没看懂的部分出来，我们讨论，我们接到一个软件项目，首先是了解业务需求，然后根据业务需求进行软件设计，本文就是讲这块的。
这块目前由两种方向，过去是使用面向数据表的建模，从业务需求中画出数据表结构，然后交给程序员写SQL等数据CRUD增删改查方法，这是一种完全依赖数据库的分析设计方法，我已经在“数据库时代终结”一文中指出过，这种方式已经过时，使用同样一套数据库，完全由两套优差不同的设计方案和代码，从JiveJdon3.0和JiveJdon2.5两个版本完全可以明白：
http://cosoft.org.cn/project/showfiles.php?group_id=5298
那么比较好的方式是什么呢？当然是面向对象的分析设计方法，也就是说，一开始我们不设计数据表，而是找出对象，设计类图，如何从业务需求中设计出类图不是一件简单的事情，以前我们都依赖分析设计员做过这方面工作，由这方面经验，或者他以前设计过这个领域的数据表，换成类图就可以了，但是这种方式严重依赖人员背景。
那么能否在，没有专业领域背景的情况下，按照一种分析方法来设计出类图来？无疑我们需要分析模式等更加抽象的方法工具，而四色原型则是一种必分析模式更抽象的方法工具，可暂时认为是一种高端的分析方法。
|
|
|
|
|
|
Re: 系统分析概念：四色原型
|
发表: 2006年02月26日 17:15
|
回复
|
|
给我感觉，这种分析法对帮助找出系统中的对象有点帮助。
以及正确的分析对象的属性也有点帮助。
渐渐有点面向对象思考的头绪了。
|
|
|
|
|
|
Re: 系统分析概念：四色原型
|
发表: 2006年03月01日 12:45
|
回复
|
|
>渐渐有点面向对象思考的头绪了
是啊，面向对象的设计思维首先需要从面向对象的分析开始，一个人的抽象能力决定了它面向对象的深浅程度。
|
|
|
|
|
|
Re: 系统分析概念：四色原型
|
发表: 2006年03月22日 15:22
|
回复
|
|
|
对我很有启发,jdon论坛真不错!!谢谢banq。
|
|
|
|
|
|
Re: 系统分析概念：四色原型
|
发表: 2006年04月04日 15:36
|
回复
|
|
|
|
|
|
|
|
Re: 系统分析概念：四色原型
|
发表: 2006年04月09日 17:26
|
回复
|
|
可以问下jive3.0@使用了多少人，16-20人。2个团队？
――――――――――――――――――――――――――
|
|
|
|
|
|
Re: 系统分析概念：四色原型
|
发表: 2006年04月09日 17:53
|
回复
|
|
FDD、TDD、DDD。
――――――――――――――――――――――――――--------
都没强调封装！系统要的是组件（module）,MDD可“拔插”的组件，不仅是通过XML ,DI一个类，EJB3.0强调了组件（module）封装。但是有没有在web、service、DAO都能实现可“拔插“的组件，即可以DI到class,到组件，甚至插件（plugin）.
在架构上，可以Tapstry/sturts 可以灵活替换，在ORM可以ibaties/hibernate 灵活替换。借助Spring基本可以做到。这是在plugins级别的替换，在组件级别了， 通过什么了！基于EJB的购物车可以和基于Tapstry的购物购物车灵活替换吗？接口统一吗？
――――――――――――――――――――――――――-――――
相反，FDD是不是要更进一步，从功能到组件了！MDD了强调对外封装，对内解藕！整个系统松散设计，对web暴露出来的只是service 接口了,内部是DAO 的DI，还是注解，对web无关。web就是用来显示，K**IN的。至于由什么组件处理是可替换的，web无关。
但是有个难题，IE仍然是同HTML标记！
|
|
|
|
|
|
Re: 系统分析概念：四色原型
|
发表: 2006年04月10日 11:46
|
回复
|
|
mythmoon想法非常好，从技术架构角度谈了一些个人见解，封装以及松耦合是设计的一个追求。
四色图和FDD其实跳出了设计的范畴，属于分析范畴，分析范畴应该说是一个正在发展和探索的领域，它是软件系统最高的抽象层次，打个比喻不是很确切，分析范畴类似哲学、易经等范畴，属于帮助人来将万千世界的需求用软件概念来表达。
对于分析范畴，准确反映需求（不要将设计和需求脱钩，就是最好的架构设计和技术也是南辕北辙）；跟随需求变化而变化（以Domain Model为龙头，所有设计和技术都是龙身和尾巴，舞龙者的灯笼是需求，龙头要随时跟随灯笼变化）。
在Jdon谈论四色图之前，基本国内媒体以及业界很少有提四色图的（Google搜索一下），这和当初我们谈论GoF设计模式、以及谈论IOC模式时一样。
我在这里谈四色图，不希望太多同好者，只希望将实战中有效的先进的理论介绍给大家，而不是跟随国外媒体毫无目的地推上所有的菜盘。
相信几年以后，这个帖子会有陆续跟帖的，就象Jdon的其他贴一样。
|
|
|
|
|
|
Re: 系统分析概念：四色原型
|
发表: 2006年04月15日 15:30
|
回复
|
|
|
不是太理解Description原型, 假设我在一个系统中, Party原型是 User ,Role原型是经理,组长等. Description原型是什么呢? 我觉得User已经是最高一层了, 按四色原型, Description原型应该是什么呢? 我们可不可以只定义 三个原型?
|
|
|
|
|
|
Re: 系统分析概念：四色原型
|
发表: 2006年04月15日 20:55
|
回复
|
|
description 是一个Party 或place或thing的描述，代表对应这种描述所有事情的总类，属于一种抽象种类概括，如果用类和对象关系来表达，description应该属于类描述，如一个Car模型。
User ,Role是和人相关，description则是和东西物体相关。
|
|
|
|
|
|
Re: 系统分析概念：四色原型
|
发表: 2006年04月16日 13:32
|
回复
|
|
|
看不出四色原型对写代码有什么指导作用.即便对于建模,似乎也没什么用嘛.呵呵
|
|
|
|
|
|
Re: 系统分析概念：四色原型
|
发表: 2006年04月17日 11:54
|
回复
|
|
>看不出四色原型对写代码有什么指导作用.即便对于建模,似乎也没什么用嘛.呵呵
那是你还在用数据库思维来分析需求，而不是面向对象，当然看不见新路了。
|
|
|
|
|
|
这个主题有 31 回复 ／ 3 页 [
1 2 3
下一页
]
|
|
|
注册
登陆
上一主题
下一主题
