25轮题目
以下图都是不合适的。其中犯错的思想根源相同的是( )
1)
2)
3)
4)
A) 1和4
B) 2和3
C) 2和4
D) 3和4
【解析】答案D。
图1的错误是对类关系的误解,图2的错误是责任分配不恰当,而图3和图4看起来每一处采用的符号都没有问题,但从整体上看,两张图都违反了建模抽象级别一致的原则。
图3,研究对象写着永王商场,突然想到自己做的系统可能有刷脸结账用例,随手就画了上去,如果刚好突然想到代码怎么实现,有可能会把每行代码也画在用例图中。
图4,类图画着画着,突然想到了订单有几个状态,恰好又突然想到了怎么实现这些状态(用GoF的State模式),于是就画上去了。莫非订单项,商品等类没有状态?
这种“建模”的特点是没有严格的推导,思维无序跳跃,“突然想到”什么就乱画什么,没“突然想到”就是不存在。
缺少严谨、有序的建模训练,很容易得到这种“突然想到”的模型,而且还可能边画边为自己的“灵感”沾沾自喜呢。
话又说回来,能画出图3和图4,已经算是不太差的了。犯图1图2错误的人,估计建模水平还达不到让人专挑图3图4错误的地步。
至于为什么要抽象级别一致,可以看《软件方法》第8章。
====广告分隔线====
[训练介绍] 软件开发中,需求是解决“产品怎样好卖”的问题,设计是解决“降低生产成本”的问题。二者相辅相成,缺一不可。而且,不能相互取代。要迈向“低成本制造好卖的产品”的境界,并非喊喊口号就能达到,需要静下心来,学习和实践各种技能。 在这个强调“做减法”的时代,建模是正确帮助您“做减法”的绝佳工具。 本训练就是教授如何使用UML2.5相关的需求和设计技能来全程实例剖析一个系统的过程。 本训练对每个开发工作流,结合讲解、做练习巩固、应用到实际项目三种方式,展示使用UML2.5相关技能开发软件系统的全过程,解答实际应用中的疑难细节问题。 [学员要求] 有一年以上项目经验的需求或设计(编码)人员。不需要您有“UML基础”,只需要您有项目经验。欢迎学员携带自己的项目来听课,由专家在现场进行剖析。 [专家] UMLChina首席专家 潘加宇。在1999年还是一名程序员时,利用业余时间创建了UMLChina,潜心研究软件需求和设计技能。2002年开始对外提供UML需求和设计的技术指导和训练服务,到现在为止,已经上门为超过280家的软件组织提供服务,覆盖了国内各个领域的领袖企业,包括通信、企业管理、电子商务、房地产、网络游戏、地理信息、物流、数码设备、医疗设备、工业控制.....等领域。 [课程大纲] 1. 概论 以上时间分配会根据项目特点和训练进程调整。 |