(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)
上传数据　这个对于用户是有价值的，而后面分解的子用例是一些步骤，对于用户而言不用关心