关于OOA、OOD的思考

我比较同意“凤凰”对于建模的认识：
建模可以思考的方式可以是面向对象建模与面向过程建模。
面向对象建模可能会涉及：业务建模(use case)，系统对象建模，数据建模的PDM。(O/R mapping)
面向过程建模可能会涉及：业务建模(use case)，数据建模CDM,LDM+流程建模；数据建模的PDM。
在面向过程建模中，同样可以使用OOD和OOP；但是不是OOA

术语好多呀！
是有明确的定义吗？还是个人有个人的理解？如果我们自己都弄不清楚这些术语的话，我想当和客户交流的时候应该也有很多问题吧。
记得某本书中有这样一个例子（回头我找到的时候把具体章节补上来），某个传统行业用户找了一家软件公司帮助他们建立系统，结果看到2个设计人员就一个概念问题就争论了一天还是不能达成一致。那么她会如何去做呢。
还有一个例子是在《软件架构师职业导读》中的：大家可以很容易的理解建筑师，建筑工人的区别，但是否可以理解软件工程师是干什么的吗。（原话记不住，回头补吧）
还有一个小问题，大家是怎么理解“软件工程”的呢，好像可以去参考软件工艺。
我觉得这些可能都是发展中的问题

说的很乱，好像没有什么意义，哈 ，就当灌水吧

不管是对象建模（准确的说是对象建模+对象持久化）还是数据建模（准确的说是数据建模+流程结构）
对于类MIS系统来说，得到的数据表结构应该是类似的
（谁让你非要用二维表为存储结构了？用二维表就要遵循二维表的规则）


我认为对象建模和数据建模是一个问题的两个部分
不知道是谁放大了两个名词的语义范围
变成上面括号里的语义

对象建模（OOA、OOD）的主要问题在于对业务行为从需求到实现的一对一映射
这样做的目的，一是符合人类的正常思考方式，二是为了对大系统内部行为的可控性
在面向过程的分析方式中，也有很多这样的努力，如IPO图、使用内聚和耦合的分析方法等等
但是结构化分析方法统一的问题是对数据的滥用，因为是基于数据字典，所以数据字典变成一个大坑，设计的时候不去考虑，维护的时候都陷到里面
想想看，我们在使用数据字典，可是谁在控制数据字典？

个人的理解不同罢了...原理应该都一样....