2004-12-07 14:41:53 Song
青润，用例的分包，分析模型的分包，以及系统的分包等必须统一吗？

2004-12-07 14:43:25 Song
系统的分包，我理解是设计模型的分包，与导出的代码是一致的，如果与前面的分包保持一致，那这些类混合在一起会很臃肿啊

2004-12-07 14:47:12 青润
不，是需要统一考虑的，而且是一个逐层递进的关系。
用例得分包得到的是子系统。
分析模型的分包得到的是子系统下每一个子模块。
设计模型的分包划分的是每一个模块下的类的具体路径。

2004-12-07 14:49:55 Song
用例得分包得到的是子系统。－－子系统下就是那些用例呀。
 

2004-12-07 14:50:18 Song
分析模型的分包得到的是子系统下每一个子模块。－－这个子模块对应的也是用例吧？

2004-12-07 14:50:28 青润
是呀，分析模型是对用例的分解，设计模型是对分析模型中的分析类的进一步细化。

2004-12-07 14:50:43 青润
是的。

2004-12-07 14:51:06 Song
我觉得在这两步，自己做的很到位了，可是在设计模型的时候，还是感觉有难点。

2004-12-07 14:52:35 Song
例如我在设计模型阶段，为了导出代码一致性，我的包名会是com，com下会是公司名，公司名下面会是系统名，系统名下面会是子系统名

2004-12-07 14:53:05 青润
注意，你的com的意思是什么。

2004-12-07 14:53:19 Song
子系统下就是从用例到分析模型再到设计模型的东西

2004-12-07 14:53:42 Song
因为一直对java的包名进行这样的命名规范

2004-12-07 14:54:02 青润
com一般是通用包名称，也就是说，在设计中提取出来的公共部分才放置在这下面。
将来，公司内部代码库中所保存的通用性代码组件，都应该是放在com下的。

2004-12-07 14:54:22 青润
其它的包名才是你系统的业务/功能包名。

2004-12-07 14:55:15 Song
其实“com.公司名”相当于RUP模板里面的设计模型包，这个我到不是很担心混淆或麻烦，后面的“系统名.子系统名”与你在书中所说的就对应上了。

2004-12-07 14:55:40 Song
现在烦恼的就是子系统下的类

2004-12-07 14:56:35 青润
我认为com是通用类或者通用模块的上级目录名称，可以看作是通用子系统。
其它的则要按照具体的业务进行划分，得到其他业务相关的包名和目录结构。

2004-12-07 14:58:06 Song
这就是一个细化的过程，在用例和分析模型阶段不是很突出，可是在设计模型阶段，基本上每个子模块都对应好些类，这些类在一起管理很麻烦

2004-12-07 14:59:04 青润
如果你按照我的方式来做了细分，那就不会那么麻烦了。

2004-12-07 14:59:52 青润
当然，还要考虑你的项目的后续发展问题，也就是公司对你的项目的认定方式，这就是我书中提到的功能性划分和业务性划分中的区别。对于不同的项目要有不同的应对策略。

2004-12-07 15:00:07 青润
同样，也会产生不同的目录结构和包的命名结构。

2004-12-07 15:01:12 Song
以前也总是在这里走不下去，开始不规范，往往直接设计数据库，分配编码任务，复杂的业务就做一些类协作图，仔细阅读你书中的相关内容，还是不得要领，你的下一版会深化这方面的东西吗？

2004-12-07 15:01:31 Song
以前也总是在这里走不下去，开始不规范，往往直接设计数据库，分配编码任务，复杂的业务就做一些类协作图，仔细阅读你书中的相关内容，还是不得要领，你的下一版会深化这方面的东西吗？

2004-12-07 15:02:51 青润
我相信会的。不过，会不会有第二版，我也不好说。因为我不是写书的人，国内的版税太低，我也要为活命考虑呀。呵呵。所以，很多东西，都只能通过别的方式来进行。
除非我其他方面都稳定了下来，然后也有时间，当大家的问题积累到一定数量，我认为再出一本书对得起大家的时候，我才会考虑后续的内容。