关于ooAD

引自jsptw.com 的一篇文章:
------>
........
.......
結語

因為工作上的需要，我interview過不少想當SA的人。很多小公司的SA，其實就是負責design database 的table schema，並且說明每支程式應該要負責對data進行什麼處理。如此而已。

很多懂得OOAD的人都會嘲笑這些人的技術落後，覺得這些人的功力不過爾爾。不過在我看來，不過就是大家用不同的角度，來看應該要怎麼分析設計一套系統。沒有孰優孰劣，只有誰真正比較清楚並且完整地capture user requirement如此而已。

大多數用到database的商用系統，其實在進行modeling時，最重要的重點，其實就是data modeling。對於系統的behavior，其實並不是那麼在乎，那也就是為什麼我會不斷思考，UML, use case driven OOAD是否真的適用於這種類型的專案開發的原因。或許沒聽過structure analysis的人，在讀完這一章以後，可以擁有一個不同的觀點吧。

-------EOF--------
想来这是一位大牛。

需求分析、数据建模、对象建模、编程、测试，一个都不能少，全部都要做好。你能说项目的成功哪一个是可以缺少的吗？只不过是不同规模、不同类型的项目所占的比重不同而已。强调某一方面而忽视其它方面都是不可取的。传统软件工程理论之所以失败一个原因是因为他们认为某一方面是最重要的，可以偏废其它方面。果真如此，银弹早就该有了（《人月神话》）。就象一个人有视觉、听觉、嗅觉、味觉、触觉，合在一起才构成了一个完整的人。
国内一般的 SA 做的确实是很不够的，只做了数据建模，对象建模基本上没有做或者敷衍了事（可能因为面向对象太复杂，功力不够，毕竟熟悉设计模式的人很少，能从体系结构角度去考虑问题的就更少）
某些 SA 还有一个不好的倾向就是轻视编程（尤其是某些科班出身的 SA），认为自己是专业设计人员，编程是低级的工作。这是非常要不得的。这样的 SA 我们是绝对不会招的。Kent Beck 每天还在写程序，你算得了什么？！
我的朋友的爱人在加拿大滑铁卢大学计算机系念博士生，主修体系结构。她说她有个同学念本科学编译原理的时候做了一个 C 编译器，可以顺利地编译 DOOM。这是一个什么概念？你有把握写一个 C 编译器把 DOOM 完整地编译出来吗？

跑题了，前提是商业应用软件（99%面向DB)。

确实是有些跑题了。其实我们做的项目大部分是 MIS 项目，属于数据库操作集中型的应用。对于数据建模的要求是比较高的。一个好的 OR Mapping 框架（类似于 Hibernate）是必不可少的。我们开发了一套中间件来做开发，可以很方便地做数据库操作，这套框架已经比较成熟了。
像我们这样使用成熟的框架来做开发的厂商对于设计模式并不是非常重视的，因为设计模式所包含的复杂的设计策略取舍已经在框架的设计中确定了。只要选择了某个领域最合适的框架，开发效率是很高的。但是对于直接使用 JSP/Servlet/EJB 来做开发的厂商则需要使用较多的设计模式，而且在设计策略的取舍方面颇费心力。这也是 OOAD 目前面临的一个困境，即使用了太多的设计模式不但没有很好地解决业务问题，反而造成了系统过于复杂降低了开发效率（我想大部分的人都有 Deadline 的压力，除非生活在真空中）。我放弃使用 Struts 也是这个原因，我总觉得应该有更好的方法。现在的敏捷建模和 AOP 的出现就是为了走出困境所做的尝试。
我对数据建模的看法是这样的，数据建模的好坏决定你能不能做某件事（如果某个复杂的任务是现有的关系数据库理论都无法解决的，你该如何做？）。而对象建模决定你如何更好地（以更好的架构，更聪明更有效率）做这件事。两者都很重要，但是数据建模更关键。
这就像算法和面向对象的关系一样，以前见过很多人争论究竟哪个更重要，我觉得没有必要。其实软件的很多领域无法突破还是因为算法问题没有解决。但是我也并不认为面向对象不重要。面向对象确实解决了软件开发如何提高生产力降低缺陷率的大问题，在充满竞争的商业世界里，速度是一个公司存亡的关键。
面向对象的很多问题我也在思考之中，目前集中精力在研究其它问题，暂时还没有很好地整理过。将来我们可以进行更深入的讨论。

不可否认的是SWT给大家更多的选择， 就我自己而言， 我更喜欢SWT。

struts有什么不好吗，它跟中间层的设计好像没什么关系。
很想知道楼主的框架结构。

Struts有很多不好
不过Dlee在上面主要是说jsp/servlet的问题，不是说Struts

to：Dlee，你一篇帖子跑题两次了

数据建模固然重要
但是在企业应用中（楼主你说的DB应用）
对象建模同样重要

对象建模的根本意义在于用户行为的从需求到实现的一对一映射
否则当你的系统变大之后，你会被数据处理淹没
再来个需求变更，我估计你的人马就要疯了

:D 发现有个怪怪的老伯伯称做 dlee  ...

十分同意。

还有获得管理差异的能力。