所在位置:答疑 - 内容   
因为没有UML编译器,画错了也不容易发现
 

(195***59) 2013/3/13 12:38:13 因为没有UML编译器,画错了也不容易发现
2013-03-13 14:06:18 潘加宇(3504847)
编译器也不能"判错"啊,你以为编译能判错,那是因为你对"做对"的要求太低。

2013-03-13 14:05:17 京吴彬(195***59)
潘老师,有没有检查UML图是否画正确的工具?
2013-03-13 14:08:45 潘加宇(3504847)
看你的"正确"说的是什么

2013-03-13 14:07:54 京吴彬(195***59)
个人期望是做到完美,可是画错了,没有人指导,会误认作自己画对了,从而养成了不好的习惯
2013-03-13 14:09:21 京吴彬(195***59)
比如时序图中的一些方法和约束
2013-03-13 14:09:28 潘加宇(3504847)
我问你,从网上下载一个现成的项目的代码,把某个变量名全部替换一遍。这个代码是对是错

2013-03-13 14:09:40 京吴彬(195***59)
课程里面,关于提交XXX申请的那个箭头
2013-03-13 14:10:11 京吴彬(195***59)
如果不是您指出来,可能我会一直错下去
2013-03-13 14:11:44 潘加宇(3504847)
编译器能知道你写的"提交×××"是什么意思吗?

2013-03-13 14:11:55 广李学政(65720627)
是想找一个检查"语法"错误的工具?
2013-03-13 14:12:18 京吴彬(195***59)
语法错误和画法错误的工具
2013-03-13 14:12:50 潘加宇(3504847)
你在C#里面说人是狗的一种,编译器能检测出来吗? 你把变量命名为:提交×××,编译器能认为是错的吗?

2013-03-13 14:13:30 京吴彬(195***59)
比如,把字符串赋给int型就会报错
2013-03-13 14:13:35 京吴彬(195***59)
UML
2013-03-13 14:13:46 京吴彬(195***59)
的话,没找到类似的提醒
2013-03-13 14:14:56 潘加宇(3504847)
把变量命名为:提交××× 人是狗的一种 和 把字符串赋给int型 不是一个事情

2013-03-13 14:15:12 京吴彬(195***59)
我个人的最大问题就是,UML画的不规范,不影响工作上的沟通,但是按照老师讲的东西,肯定是有问题的。
2013-03-13 14:15:20 京吴彬(195***59)
恩,没错
2013-03-13 14:15:46 潘加宇(3504847)
所谓的"规范"问题不是规范问题,是对后面的道理的理解问题

2013-03-13 14:17:51 京吴彬(195***59)
这句话理解起来有点儿难度[表情]
2013-03-13 14:18:07 潘加宇(3504847)
你可以回顾一下,和编码对比,从学校开始学习编码算起,你编写了多少错误的、玩具的代码,才终于写出能在真正的商业项目里用上的代码?

2013-03-13 14:19:17 京吴彬(195***59)

2013-03-13 14:19:41 京吴彬(195***59)
代码的输入输出可以帮助检查代码功能的正确性
2013-03-13 14:20:06 京吴彬(195***59)
虽然不能检查代码效率和其它规范性。但能保证功能正常。
2013-03-13 14:20:21 京吴彬(195***59)
UML有类似的工具吗? 我比较头疼的就是这个
2013-03-13 14:20:25 潘加宇(3504847)
"正常"?

2013-03-13 14:20:39 京吴彬(195***59)
当然是不正常啊
2013-03-13 14:20:50 潘加宇(3504847)
你怎么知道你的UML模型就不正常呢?

2013-03-13 14:20:52 京吴彬(195***59)
但我的情况是,UML写的更糟糕
2013-03-13 14:21:16 京吴彬(195***59)
听了课之后,感觉之前sequence画的很多都不对
2013-03-13 14:21:22 京吴彬(195***59)
用例分析的也有问题
2013-03-13 14:21:42 潘加宇(3504847)
还是我前面说的,"正确","正常"的标准是什么

2013-03-13 14:22:24 潘加宇(3504847)
之前sequence画的很多都不对 --那么七八年前前你写的代码是"对"的吗

2013-03-13 14:23:18 京吴彬(195***59)
哦,您的意思是,按照课程的标准要求,我们是画出了更规范的更好的UML?
2013-03-13 14:24:04 潘加宇(3504847)
我的意思是,不要把技能问题总结为"规范"问题

2013-03-13 14:24:26 京吴彬(195***59)

2013-03-13 14:24:42 潘加宇(3504847)
这样相当于认为"事情很容易,只要大家把规范背诵一遍,就OK了"
2013-03-13 14:25:14 潘加宇(3504847)
提高编码技能是不是也是高手宣布一个规范,然后整个团队就上去了?

2013-03-13 14:26:18 长李涛(819***008)
老师的意义是不是 是思考问题或者解决问题的思路?
2013-03-13 14:26:19 京薛志方(39***830)
潘老师,编码正确与否可以用是否完成所需要的功能来衡量,图画的正确与否用什么来衡量?
2013-03-13 14:27:25 潘加宇(3504847)
"是否完成所需要的功能"是编译器判断的吗?

2013-03-13 14:29:11 京吴彬(195***59)
编译器有一些基础检查项目阿
2013-03-13 14:29:21 潘加宇(3504847)
回到最初的问题,很多UML工具有模型检查的功能,例如,EA里面,Project菜单下面的Model Validation
2013-03-13 14:30:27 潘加宇(3504847)
但是,我对大家的问题不满意的是,把事情想得太容易。 要是有这么容易的事情,要你们做什么?

2013-03-13 14:31:16 京吴彬(195***59)
呃,这个问题很尖锐
2013-03-13 14:31:44 京吴彬(195***59)
一针见血
2013-03-13 14:32:55 广梁裕询(52***9929)
提供一个输入框,输入"银行系统",敲个按钮,啪啪啪生成所有UML模型。 然后我们都失业了。
2013-03-13 14:32:56 京薛志方(39***830)
我们需要对自己的工作做一个衡量,但是自己做的时候肯定是按照自己认为最正确的方式去做。完成以后,谁能给出这个评判呢。
2013-03-13 14:34:55 潘加宇(3504847)
那你想想,如果有这样一个垂手可得的评判工具,你能买,竞争对手也能买,有意义吗

2013-03-13 14:36:55 橙子cc(839***032)
原始需求的收集、整理和理解,只能人肉来做
2013-03-13 14:40:08 潘加宇(3504847)
参见群共享"做有市场思维的开发人员"
2013-03-13 14:40:25 umlchina1
[图片] 潘加宇 分享文件 14:40:23
"做有市场思维的开发人员.pdf" 下载

2013-03-13 14:43:48 京薛志方(39***830)
我曾经看过一份设计文档 其中一个用例图是这样的 用例—上传数据 后面 又分为多个子用例,包括上传失败,网络异常等等 开始的时候我并没有觉得这样有什么不妥,后来听了课程以后,知道这么画是错误的。 但是对于研发人员来说,他们更愿意接收那些错误的用例图,因为这样关注点更加突出。 这是为什么?怎么用正确方式去引导?
2013-03-13 14:44:14 京吴彬(195***59)
傲雪的问题和我一样啊
2013-03-13 14:44:18 京吴彬(195***59)
我也有这个疑问
2013-03-13 14:45:20 潘加宇(3504847)
讲清楚背后的道理。用例是做需求,需求是要使系统更好卖
2013-03-13 14:45:35 潘加宇(3504847)
《软件方法》里有详细的阐述

2013-03-13 14:46:12 长李涛(819***008)
我们的问题应该不是让开发人员"更好"的做系统,而是让客户更好的用系统。
2013-03-13 14:46:14 潘加宇(3504847)
这是为什么? --你自己回答出来了吗,为什么用例这样层层分解是错的?
2013-03-13 14:46:53 潘加宇(3504847)
"知道这么画是错误的"是因为我说的这样是错的,还是因为理解了"为什么这样是错的"?

2013-03-13 14:47:46 京薛志方(39***830)
上传数据 这个对于用户是有价值的,而后面分解的子用例是一些步骤,对于用户而言不用关心