设计模型和uml应用中的实例分析
一个朋友 2008-07-22 10:46:14
润润高手，你好，请教个问题，帮我看一副时序图，提提意见
青润 11:01:20
？？
青润 11:01:31
贴上来，我看看．
一个朋友 11:01:39
提提意见
一个朋友要给您发送文件“素材入库时序图.jpg(285.8KB)”，接收，另存为 还是 谢绝该文件
您同意了接收文件“素材入库时序图.jpg”，正在建立连接，如果要中止接收文件，请按取消
文件已经保存到目录：“目录/MyRecvFiles”，转存至QQ网络硬盘
青润 11:05:01
呵呵，你这个图的整个设计思路是面向过程的方法，不是面向对象的，不过，这不是主要问题．
一个朋友 11:05:31
还有什么问题？
青润 11:05:33
你并没有把类提取出来，而是把每一个类的方法或者说操作都变成了一个类的形式的体现
青润 11:05:44
只能说，你这个绘制的方式，全都错了．
青润 11:06:27
问题实在很多．不过，已经有了时序图的基本结构，这个是对的，比欧洲的***总部的工程师绘制的要合理一些．
青润 11:07:20
你这样绘制，使得系统看上去太过于复杂，无法清晰的表现出系统的实际实现结构，所以，你这个图，说白了只是你文档描述方式的一种所谓自创的ＵＭＬ语言的表达形式．
青润 11:07:36
太乱了．呵呵．
一个朋友 11:09:30
提点具体的改进意见？比如用对象的方法，
青润 11:09:36
你把数据库的表都进行了类的实例化，这样做也是可以的，只是我不知道你是否是这样考虑的，因为你的表达中，并没有很明确的说出你的这种设计想法．
青润 11:10:35
你这个更像是函数的写法，而不是ＯＯ的设计思路．
青润 11:11:06
而且，你目前的设计都是中文表达，这应该是属于分析阶段的时序图，可是你表达的却是设计阶段的效果．
一个朋友 11:11:20
就是，高手
青润 11:12:41
跨越了两个阶段作设计，对于软件过程来说，其实并不合适，这个观点０２年的时候我和当时在联想的老哥周海峰有过这方面的对话，也就是过度设计／开发的问题．
青润 11:13:12
这样做违背了正常人的逻辑思维和对事物的分析和认识的过程，其实是不合适的．
一个朋友 11:13:53
这个有道理，如果我要改成OO方式？你说具体怎么入手
青润 11:14:09
呵呵，这个要说起来就太多了，你去看看我那本书吧．
青润 11:14:44
从过程到ＯＯ的设计思路地变化，这相当于对事物认识的两个阶段的跨越，不是几句话能说清楚的．
一个朋友 11:15:25
我正在读，理解得不够深刻，如果针对这个图，给点提示
青润 11:16:07
我觉得，你应该先分析出来你的这个要解决的问题中有哪些可以抽象出来的对象实例，然后再作下一步的考虑．
青润 11:16:54
对象抽取不出来，那就不可能获得后面的内容了．
当然，对象的抽取也可能不是一步就能结束的，也许需要一两次分析的迭代．呵呵
青润 11:17:39
其实这个分析的迭代不要认为太大，只是脑子里面思路的几个反复而已，有些人喜欢用大概念压人，其实是多次的反复思考，就足够了
一个朋友 11:17:42
设计这东西，复杂，
青润 11:18:39
呵呵．ＵＭＬ的全面设计的应用，的确是需要花费精力和时间来操作的，只是做完之后你会发现，很多以前在编码阶段才会发现的问题都提前解决了．呵呵
一个朋友 11:19:44
什么时候到成都指导下我们的工作，^_^，我现在在一家公司做SA，
青润 11:20:20
呵呵，我提供咨询和培训，如果你们公司需要，当然没问题．
一个朋友 11:22:00
我专门把“转码处理”，“日志管理”，“附件管理”，“素材元信息”，抽象成类，你觉得？
一个朋友 11:22:33
素材管理只是一个接口，不做任何实际操作
青润 11:23:33
从对象存在的方面来考虑，日志可以作为一个独立的对象，附件也可以，但是转码处理好像有待于商榷，呵呵．
青润 11:24:05
其实你的转码处理更多的应该是个公用的方法，而不是对象．呵呵
一个朋友 11:24:22
对，高手，转码是一个公共组件
青润 11:24:57
所以，你老哥的ＯＯ思想还不太成型，建议，反复思考几次，来处理你目前的这个设计吧．
一个朋友 11:27:00
谢谢，明白了，控制类与实体类打交道，你觉得图中这样处理对不对？
青润 11:27:48
呵呵，你这里面说实话，我没有看到ＭＶＣ的划分方式，所以，你这里没有控制类，只有一些实体类的存在．
青润 11:28:36
如果要作ＭＶＣ，你这个系统的逻辑结构还是很简单的，直接照搬我书上的例子，就应该可以解决了．
一个朋友 11:29:09
我再重构下，谢谢
青润 11:29:32
ｏｋ
扫一扫
4883
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
