咨询青润老师一个问题：
编写设计文档时，对于时序图是不是可以准确、精细到方法名和参数、返回值等。
2010-12-4 13:47:03 一只熊猫.
那是必须的
2010-12-4 13:48:34 墨池
一只熊猫.
你们现在是这么做的吗？
2010-12-4 13:50:24 一只熊猫.
那你想要这个secq去给程序员直接开发么
2010-12-4 13:51:47 墨池
我可以把这个过程留给程序员
2010-12-4 13:52:46 一只熊猫.
凡事没有绝对 都是具体看你怎么用
2010-12-4 13:52:57 一只熊猫.
详细到什么程度得看你的用途
2010-12-4 13:56:16 墨池
可惜我们的程序员不会对对象交互的过程建模，一般都是看着用例说明，直接编码。偶尔我也会制作些参考界面。
2010-12-4 14:00:13 一只熊猫.
那你需要说很多文字说明 甚至自己去讲解了
2010-12-4 14:01:54 墨池
是的，至今我没有用过时序图。
2010-12-4 16:04:40 青润
我刚回来。
时序图作的就是时序图的事情，只是时序图开发的时候，类图会同步完成。这个在我的书中写的很详细了，每一个操作步骤都标记清楚了的。
2010-12-4 16:05:29 一只熊猫.
领导的回答就是不一样
2010-12-4 16:05:59 墨池
类图是静态的，时序图可以反应对象之间的交互。
2010-12-4 16:06:14 青润
但是，时序图是类图作为基础才能绘制出来的。
2010-12-4 16:06:24 青润
这也就是为什么很多人的时序图其实绘制错误的原因。
2010-12-4 16:07:03 青润
你去看一下我书中给出的例子，和别人时序图中的例子的仔细对比，可以对比出很多的不同点，这些不同点，就是关键所在。
2010-12-4 16:07:43 飞鱼576
2010-12-4 16:07:44 墨池
嗯，时序图基于类图，绘制时序图时又可能会去修改完善类图。相互的推导和验证。
2010-12-4 16:08:45 青润
为什么说很多人只是会uml语言，而没有在实际工程中操作过，没有操作过的人，就容易犯这样的错误。
直接看我书中关于时序图设计到的分析模型和设计模型开发的过程，其他书中绝对找不到一样的内容。
2010-12-4 16:10:40 墨池
时序图开发过程中，可以给类图补充属性方法。
2010-12-4 16:10:55 青润
本来就是时序图开发过程中给类补充属性方法的。
2010-12-4 16:11:04 墨池
为什么说很多人只是会uml语言，而没有在实际工程中操作过，没有操作过的人，就容易犯这样的错误。
这样的错误是指？
2010-12-4 16:11:18 青润
类的属性方法不是凭空想象出来的，它是和业务实际相关联的。每一个方法都应该完成业务流程的一个内容。
2010-12-4 16:12:16 青润
比如我曾经举过的一些书中的时序图断流问题，还有一些人做设计的时候，那些从头到尾一个接一个的所谓的对象，没有mvc的划分，actor甚至操作到每一个时序图中的对象。这些都不是实际项目中应该出现的东西。
2010-12-4 16:13:59 墨池
actor甚至操作到每一个时序图中的对象
这个是不是破坏了封装？
2010-12-4 16:14:14 一只熊猫.
应该是通过一个对象操作另一个对象
2010-12-4 16:14:46 青润
你去看看你曾经购买过的uml的书，比如台湾人写的，里面就是这个情况。
2010-12-4 16:14:50 一只熊猫.
我国婚姻法明确规定 只能有一个对象
2010-12-4 16:15:08 青润
熊猫，想上餐桌么？
2010-12-4 16:15:25 墨池
呵呵，餐具。
2010-12-4 16:15:38 一只熊猫.
我没说错吧
2010-12-4 16:15:46 一只熊猫.
一个对象 操作一个对象
2010-12-4 16:16:08 一只熊猫.
不能所有对象都被一个小人干了
2010-12-4 16:16:08 青润
你找小三去吧，别打岔。
2010-12-4 16:17:17 墨池
台湾女士写得，时序图制作建议，左边是用例的启动者，右边是用例的支持者{如果有}
2010-12-4 16:17:42 墨池
一般一个用例一个时序图，但复杂的用例有时会有多个。
2010-12-4 16:17:51 青润
呵呵，完全脱离了业务系统的实现过程来谈时序图。
2010-12-4 16:18:12 青润
一个用例有几个时序图，在用例阐述的时候就已经确定了，不是随便想对应几个就对应几个的
2010-12-4 16:18:30 一只熊猫.
除非客户蛮不讲理
2010-12-4 16:18:43 青润
和客户没关系。
2010-12-4 16:18:44 轻影(52925703)
怎么从类图讨论到时序又讨论到用例
2010-12-4 16:19:00 轻影(52925703)
类图和时序 与用例不是一个概念吧
2010-12-4 16:19:07 青润
别乱插言，你要是讨论问题，就正经讨论，讨论结束，随便你怎么说话。熊猫，讨论问题的时候不要乱说话。
2010-12-4 16:19:13 墨池
用例编写时，已经决定了有几个时序图
2010-12-4 16:19:19 墨池
对的
2010-12-4 16:19:19 青润
我从来没说用例和类图时序图是一个概念。
2010-12-4 16:20:15 青润
我的书上写的很明白了。
用例撰写时候的主流，就是用例的主时序图
每一个子流对应一个子时序图。
每一个分支流对应一个分支流时序图。
2010-12-4 16:20:45 青润
而每一个时序图的绘制，都是用力阐述时候这些主流，子流，分支流描述的时候已经写清楚地过程。
2010-12-4 16:21:13 墨池
那么分支流和子流程，会不会出现时序图没有actor吗？
2010-12-4 16:21:35 轻影(52925703)
这个到工作流了，我来解释
2010-12-4 16:22:01 青润
这时候完成的就是分析模型时序图的开发。
在分析模型时序图上应用架构层模式，就完成了第一层架构级别的设计模型时序图的开发，对于复杂的业务系统，还可能在上面应用其他层级的设计模式对该设计模型时序图进行细化，于是得到最终实际的设计模型时序图。同时，类图也开发完成
2010-12-4 16:22:11 轻影(52925703)
分支流程和子流程所依赖的是父流程或者主流程的actor
2010-12-4 16:22:12 青润
时序图都不可能没有actor
2010-12-4 16:22:46 一只熊猫.
支持
2010-12-4 16:24:10 墨池
所以，建模实现。需要在用例编写时就把好关，用例编写也要标准化。
2010-12-4 16:24:26 青润
说句实在话，只有不做业务系统的人，才能设计出没有actor的时序图。
时序图的启动是什么？
主动触发者
要么是时间，要么是人，要么是外部系统。这些都是你这个系统的actor
2010-12-4 16:25:04 青润
是的。必须标准化。
我的新书里面对用例阐述也进行了模型化定义，但是，目前国际上还没有uml工具可以支持我定义的模型化用例阐述方式。
2010-12-4 16:25:12 墨池
我们公司老板现在不给时间写用例规格说明，导致我后面几乎没有考虑采用时序图UML制品。至今我们公司都没用上时序图。
2010-12-4 16:25:23 青润
这个用例阐述方式我整整思考了五年多的时间才设计出来
2010-12-4 16:25:41 墨池
牛啊，青润老师。
2010-12-4 16:25:50 墨池
我一定拜读。
2010-12-4 16:26:16 墨池
估计我拜读后，定能说服我们老板。征服开发人员。
2010-12-4 16:26:48 墨池
是啊，如果哪个工具能生成一个模型化的用例编写格式，多好。
2010-12-4 16:26:59 青润
呵呵，这些东西，说实话，不做实际系统开发，根本考虑不到这上面，最多就是拿uml语言做一大堆描述罢了。
2010-12-4 16:27:12 墨池
可以省很多事情，很方便。应该给uml工具开发商提供建议。
2010-12-4 16:28:16 墨池
我现在编写用例，关于流程就分成两大块：主流程和替代流程
2010-12-4 16:28:19 青润
呵呵，truefun没有资金实力，我曾经把这个最初的版本送给了他们还给他们提了9条uml工具改进建议。
不过，他们没有资金实力，所以，后续合作就受到了阻碍。
ea那边，因为他们的中国区总代的人品有严重问题，所以，后续的合作我就没有提，直接把他们扔掉了。
2010-12-4 16:28:46 墨池
没有分子流程和分支流程。统一归到了替代流程中
2010-12-4 16:29:33 墨池
你考虑下微软，vs2010自带了uml建模工具
2010-12-4 16:29:36 青润
那不是替代流程。替代流程其实就是分支流程的定义。
2010-12-4 16:29:40 墨池
还有starUML
2010-12-4 16:29:58 青润
我和微软没有合作关系，而且，人家公司那么大，我就是个无名小卒，怎么可能看得上我。呵呵。
2010-12-4 16:30:15 墨池
uml和模式应用中，流程也是分为两个。
2010-12-4 16:30:35 墨池
一个是主流程一个是补充性流程
2010-12-4 16:30:43 青润
starUML这样的opensource工具最多只是跟进UML标准就不错了，他们没有商业目的的话，不可能针对我的方法进行改进，这个情况和truefun是一样的。
2010-12-4 16:32:19 墨池
uml和模式应用中，流程分为主成功场景和扩展场景（或替代流程）
2010-12-4 16:32:27 青润
那样不合理。主流程和补充流程，这样的形势根本不能表达清楚复杂的业务系统的全部内容。
主流程里面涉及到分支判断的时候，就会出现子流程。
子流程的分支判断会出现分支流程。
这里面还涉及到一个用例规模定义的问题。
也就是我03年提出的用例大小定义的一个判断标准——这个标准也是没有其他人提出来过的。
2010-12-4 16:33:20 青润
墨池 16:32:19
uml和模式应用中，流程分为主成功场景和扩展场景（或替代流程）
这样的描述，完全处理不了复杂的业务系统用例。实际用一次就知道了。
2010-12-4 16:33:34 墨池
牛，青润。
2010-12-4 16:34:07 墨池
我正在尝试规范我的用例编写模式
2010-12-4 16:34:21 墨池
看来是时候购买一本老师的书了
2010-12-4 16:34:30 青润
这不是牛，这是实际项目中的总结。
不是拍脑袋想出来的东西。
2010-12-4 16:34:48 墨池
期望华章送一本，看来等不急啊
2010-12-4 16:34:58 青润
呵呵。
2010-12-4 16:35:15 墨池
我写那个评价写了一个小时呢
2010-12-4 16:35:19 墨池
呵呵
2010-12-4 16:35:32 青润
呵呵。看来评论的人少，他们要等，那我也没办法。
2010-12-4 16:36:05 墨池
不管了，先买一本。
然后送的话，就可以当礼物送别人了。
2010-12-4 16:36:47 墨池
年底有机会找老师签名，以释对我们这些后生们的鼓励和支持啊。青润老师。
2010-12-4 16:36:56 青润
我书中的内容，从需求，到编码，每一个过程之间都有关联关系，不是随便想开发哪个就开发哪个的。
需求和代码之间都可以获得直接的对应关系。
或者说，我只要看到了需求的用例阐述，我立刻就可以知道有几个主要的设计类，类中有几个主要的方法。
2010-12-4 16:36:59 墨池
你是我们的精神力量。呵呵
2010-12-4 16:37:09 青润
这个还真不敢当。
2010-12-4 16:37:37 墨池
呵呵，老师不用谦虚
2010-12-4 16:38:04 墨池
我相信理论，但对于软件开发等技术行业，我更相信实践中的理论
2010-12-4 16:38:19 青润
同样，在需求和设计之间，设计和编码之间，分析与设计和需求之间都有严密的对应关系和验证关系。
注意，相邻两个层级之间有验证关系，可以保证前一段时间开发内容的有效性。
2010-12-4 16:38:44 墨池
我一直有个疑惑，不知道该不该讲。
2010-12-4 16:39:04 青润
没什么不该讲的。
2010-12-4 16:39:09 墨池
就是这样一个严密的过程，务必与RUP过程发生一些冲突。
2010-12-4 16:40:41 青润
对，的确和rup过程之间有一些冲突。
说句实在话，rup自身并不是十分严密的，里面有很多的漏洞和不少的冗余步骤。
我04年版本的书，如果非要和rup划上关系，我当时说，是最简化版本的rup。
而我10年版本的书，已经完全突破的rup的内容，在他的基础上补充了大量内容。这些内容都是rup中根本缺失的东西。
2010-12-4 16:42:11 墨池
嗯，rup强调不要试图定义完美的需求后再进入开发。
2010-12-4 16:43:06 墨池
正是因为这样，有些甚至想过的模块，连需求都不知道，就开始编写了现有的这个知道得很细的模块
2010-12-4 16:43:07 青润
我更强调迭代的进展，需求的定义必须稳定可靠。
这是业务系统开发，对于一些其它系统开发，可以不求完整，但是讲求变更。所以，我书中也给出了实际操作的变更方式。
2010-12-4 16:44:15 墨池
嗯，看来不错。
2010-12-4 16:45:24 墨池
不管后续的建模，对我们现状的可实践性。
光那用例编写来说，我得先看看老师的这本书。
2010-12-4 16:45:22 轻影(52925703)
需求的定义必须稳定可靠。
这一点：是不能保证的
客户的需求天空星马，想到哪里是哪里，需求怎么能控制的住。
除非自己做产品，像taobao这样
2010-12-4 16:46:01 墨池
补充：
其实产品的需求变化也是高频率的。
2010-12-4 16:46:28 青润
需求的稳定可靠，要在于用人。
即使是taobao也不是100%稳定可靠。
需求中要善于甄别那些是稳定的，哪些是不稳定的，哪些有变化。
2010-12-4 16:46:44 墨池
因为市场需要和客户需要也在变。产品的迭代是提高可用性，和市场竞争力。
2010-12-4 16:46:49 墨池
等
2010-12-4 16:46:57 青润
这些变化一方面会形成你的子流，子分支流，备选流。
也可能会形成系统的开发变更。
2010-12-4 16:47:57 墨池
关键问题不是在于需求变化。
主要是如果需求一般，如果整个过程是严密的，那么要修改和调整的文字和图会很多。
带来工作效率问题。
2010-12-4 16:47:58 青润
我强调的是作稳定的部分，不是要求你的需求必须全部稳定。
为什么要讲求迭代开发，就是把稳定可靠的先做起来，给用户逐渐补充推动，让用户对他们不稳定和变更较大的需求有一个用起来之后的直接感受，就更容易让他们明白自己需要的是什么。
2010-12-4 16:48:33 墨池
关键问题不是在于需求变化。
主要是如果需求一变，如果整个过程是严密的，那么要修改和调整的文字和图会很多。
带来工作效率问题。
2010-12-4 16:49:12 青润
如果你能有效地用好UML，文字就会大量减少，描述也会更直接可观。
2010-12-4 16:49:51 墨池
这个可能需要更多的uml工具支持，那就会显得相当完美。
2010-12-4 16:50:13 青润
是的，但是现阶段，没有办法。
2010-12-4 16:50:15 墨池
迭代只能保证稳定的细化和精化
2010-12-4 16:50:32 墨池
但不能解决相互的验证问题
2010-12-4 16:50:51 轻影(52925703)
墨池 16:50:15
迭代只能保证稳定的细化和精化
墨池 16:50:32
但不能解决相互的验证问题
迭代和验证有什么关系
2010-12-4 16:50:51 青润
验证是前后验证，不是左右验证。
2010-12-4 16:51:04 青润
所以，迭代和验证没有直接关系。
2010-12-4 16:51:09 轻影(52925703)
迭代和瀑布是一组概念，和验证是没有关系的吧
2010-12-4 16:51:36 墨池
但是迭代的意义已经扩大到整个项目的管理
2010-12-4 16:51:54 墨池
自然要更多的解决项目中的问题。
2010-12-4 16:52:18 青润
明确一下概念：
瀑布，迭代，螺旋等等，这些都是开发过程论，或者称之为开发过程模型。
rup，xp的具体方法，我的全程建模，属于开发方法论，或者称之为方法模型。
2010-12-4 16:53:56 轻影(52925703)
清润解释一下
我个人认为 迭代和验证，一个是宏观，一个是微观。
视乎扯不到一起
2010-12-4 16:54:36 轻影(52925703)
一个是软件工程，一个是具体的框架实现或者业务实现
2010-12-4 16:54:49 墨池
你没发现老师的这本书就是解决了这样一个问题吗
2010-12-4 16:54:50 墨池
？
2010-12-4 16:55:09 青润
我前面不是说过了么？
青润 16:50:51
验证是前后验证，不是左右验证。
青润 16:51:04
所以，迭代和验证没有直接关系。
2010-12-4 16:55:12 轻影(52925703)
还没读过。
以上是我的浅见
2010-12-4 16:55:43 墨池
也是我的俗见
2010-12-4 16:55:50 墨池
2010-12-4 16:55:54 青润
如果没有读过，我建议你去读一下。
不一定买，去书店站着读一下没有人找你要钱的。
2010-12-4 16:56:18 青润
如果没有实际用过UML，是不可能体会到我所说的验证关系的。
2010-12-4 16:56:32 青润
因为传统常规的开发过程中，根本体现不了验证这个过程。
2010-12-4 16:59:04 墨池
青润老师把过程中的前后验证关系，在书中写得很精确了，在实际工作中，我虽然不能用上青润老师书中所有的验证关系，但了解这些，对于我发现潜在问题和敏感问题有很大帮助。
2010-12-4 16:59:20 轻影(52925703)
青润 16:50:51
验证是前后验证，不是左右验证。
明白了，清润的验证讲的是：时序图或者流程图中的前后逻辑验证
我刚才说的是：数据准确安全验证
2010-12-4 16:59:56 墨池
这只是前后验证之一。
2010-12-4 17:00:07 青润
这个不仅仅是业务流程的前后验证，也包括数据的验证。
比如，我代码实现后，代码和需求之间可以设计一个工具，通过需求直接验证代码的有效性。
2010-12-4 17:01:13 墨池
青润老师，待拜读全书之后，再来细聊。
2010-12-4 17:01:39 青润
ok
2010-12-4 17:01:49 轻影(52925703)
必须的!多看点东西还是有好处~~~
2010-12-4 17:05:13 轻影(52925703)
也是个艰苦的过程啊
我现在还在适应
2010-12-4 17:05:28 墨池
所以你来到这个群了
2010-12-4 17:05:29 墨池
呵呵
2010-12-4 17:05:39 青润
呵呵，我01年过这一关的时候，也很难。
2010-12-4 17:05:40 墨池
也是一个牛人啊
2010-12-4 17:05:40 轻影(52925703)
我一直都在
2010-12-4 17:06:11 墨池
群里牛人很多。都慕名而来的吧
2010-12-4 17:06:17 青润
当时曾经直接拒绝领导安排的项目，非要做自己几个弟兄一起提出的项目。
拒绝使用rose。
后来是用rose进行jboss系统反工才开始使用的。
2010-12-4 17:03:33 墨池
幸运的是我经历了从学语言到编程、设计、分析、市场调研的过程
2010-12-4 17:03:48 墨池
现在就差没有去经历测试了
2010-12-4 17:04:13 轻影(52925703)
哎。。。我现在沦为了从代码开发到设计到业务了
2010-12-4 17:04:36 墨池
应该是件好事
2010-12-4 17:04:40 墨池
呵呵
2010-12-4 17:04:56 轻影(52925703)
领导来了一句话：找个开发人员，大街上随便都能
不懂业务，是混不起来的
2010-12-4 17:06:53 墨池
哇哦，经历果然不同凡响啊
2010-12-4 17:07:46 轻影(52925703)
转型很痛苦。
毕竟写了那么多年代码。
为了生活，还是痛苦中找点快乐吧
2010-12-4 17:07:53 墨池
青润老师建议到哪个书店买你的书比较好，限网购。
2010-12-4 17:08:15 青润
我也不知道，你们找找看，哪个价格最低，就买哪个吧
2010-12-4 17:08:25 墨池
代码的技术学不完
2010-12-4 17:08:30 墨池
几乎就是个无底洞。
2010-12-4 17:08:39 青润
前段时间，京东是75折免邮费，现在82折，好像就不一定合适了。
2010-12-4 17:09:36 墨池
适当的拔高，有利于看透很多事理
2010-12-4 17:10:11 轻影(52925703)
墨池还在做技术吧？
2010-12-4 17:10:38 墨池
嗯，今年开始不做了。不过上几个月还写了很多sql。
2010-12-4 17:12:40 墨池
上次问了下一个大师，他说要回去好好学习数学。
2010-12-4 17:13:31 墨池
从最初的冯诺依曼原理开始学起
2010-12-4 17:13:49 墨池
兄弟们，先撤了。
做饭。
001.JPG来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/257598/viewspace-681582/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/257598/viewspace-681582/
扫一扫
483
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
