有了hibernate和AOP,从技术方面来看，我们已经可以设计
足够复杂的Object Layer来代替原有的Database了。
也就是说，现在的设计-编码过程可以如下：
        UML       -----------> Object
这个过程不需要更多的中间过程和辅助代码，它接近传统的
        ER+流程图 -----------> Database
这也许意味着企业OO可以脱离“花瓶”的形象，从工程控制
上能够接近，甚至超过传统的过程。

但是，完成了技术手段，在需要设计实际系统时，还是卡
在了设计上。一个基本的 Party - User - Role的模型，改
了5遍还是觉得缺陷很大，不能适应需求变化。

在解决这个问题上，我曾经遇到过的所有“老”程序员都肯定会
比我做得更好。因为，他们有更为丰富的行业经验和项目经验。

如何来补足这个缺陷？Analysis Pattern吗？或者哪里可以找到
"完善"的Data Model资源？



☆─────────────────────────────────────☆  
holly (愤中) 于  (Wed Apr  2 12:24:24 2003)  提到:

【 在 gty (宜良-丽江-蝴蝶泉) 的大作中提到: 】                                   
: 有了hibernate和AOP,从技术方面来看，我们已经可以设计                           
: 足够复杂的Object Layer来代替原有的Database了。                                
: 也就是说，现在的设计-编码过程可以如下：                                       
:         UML       -----------> Object
: 这个过程不需要更多的中间过程和辅助代码，它接近传统的                          
:         ER+流程图 -----------> Database                                       
: 这也许意味着企业OO可以脱离“花瓶”的形象，从工程控制                          
: 上能够接近，甚至超过传统的过程。                                              
: 但是，完成了技术手段，在需要设计实际系统时，还是卡                            
: 在了设计上。一个基本的 Party - User - Role的模型，改                          
: 了5遍还是觉得缺陷很大，不能适应需求变化。                                     
: ...................

经验是不可替代的. 工具和方法只是工具和方法.



☆─────────────────────────────────────☆  
microweb (深呼吸，闭好你的眼睛) 于  (Wed Apr  2 13:53:54 2003)  提到:

不知道 agiledata 对你的设计是否有帮助：）

【 在 gty (宜良-丽江-蝴蝶泉) 的大作中提到: 】                                   
: 有了hibernate和AOP,从技术方面来看，我们已经可以设计                           
: 足够复杂的Object Layer来代替原有的Database了。                                
: 也就是说，现在的设计-编码过程可以如下：                                       
:         UML       -----------> Object                                         
: 这个过程不需要更多的中间过程和辅助代码，它接近传统的                          
:         ER+流程图 -----------> Database                                       
: 这也许意味着企业OO可以脱离“花瓶”的形象，从工程控制                          
: 上能够接近，甚至超过传统的过程。                                              
: 但是，完成了技术手段，在需要设计实际系统时，还是卡                            
: 在了设计上。一个基本的 Party - User - Role的模型，改                          
: 了5遍还是觉得缺陷很大，不能适应需求变化。                                     
: ...................

☆─────────────────────────────────────☆  
gty (宜良-丽江-蝴蝶泉) 于  (Wed Apr  2 16:11:38 2003)  提到:

但经验应该是可以学习的啊，通过模式...

毕竟OfBiz项目的Entity Model就是作者根据'The Data
Model Resource Book'建立的，数百个类在很短的时间
就完成了（好像是几个星期吧，以前好像看过他自己
的介绍）。

今天看了半天的Martin Fowler的Analysis Pattern，
感觉正是我想要的，也许实际做起来还有很多难点，
但毕竟有了希望；）

序章的第5句话就让我感到它就是我要找的东西：
Instead of focusing on the process - how to do
modeling - it concentrates on the result of the
process - the models themselves.

它的第二章就是介绍Accountability（责任，一种party
relation)。里面非常详细的描述了一个如何对Organization
和Person以及它们的关系如何建模。从最简单的垂直树状关系，
到项目管理中常见的双向负责机制，然后到最广泛的Party
责任关系，最后扩展到Operation Level和Knowledge Level
的概念。所有的问题它都阐述的非常清楚，而且有明确
（甚至有点苛刻）的模型。

其实Ofbiz的数据模型(或者说"The Data Model Resource Book"的)
和"Analysis Pattern"的模型很类似，(只不过不看推理过程，是
很难明白的)。

另外昨天看的'Java Modeling in Color with UML' 也不错，
有的概念比较类似。它把系统对象划分成四类：
        1. moment-interval archetype
        2. The role archetype
        3. The "catalog-entry-like description" archetype
        4. The "party, place or thing" archetype.
其中description archetype和knowlege level的区分还是有
一些相似之处的。并且，Color UML还给出了一个通用的建模
方法（可以在CoadLetter中看到），乍一看还算有趣。




【 在 holly (愤中) 的大作中提到: 】                                             
: 经验是不可替代的. 工具和方法只是工具和方法.                                   

☆─────────────────────────────────────☆  
gty (宜良-丽江-蝴蝶泉) 于  (Wed Apr  2 16:14:55 2003)  提到:
的免费资源都显得太抽象了，我目前很难理解。

而且，我现在想要都就是一个现成的“经验模型”，不是
方法论：）

【 在 microweb (深呼吸，闭好你的眼睛) 的大作中提到: 】                          
:   不知道 agiledata 对你的设计是否有帮助：）                                   

索引页面|上一篇|下一篇