`
jiagou
  • 浏览: 2530627 次
文章分类
社区版块
存档分类
最新评论

[全程建模]关于分包的问题——用例、分析模型、设计模型的分包的作用和差异的对话

 
阅读更多

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

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics