外贸公司网站建设哪家好,电商沙盘seo优化,宁波网站建设公司费用价格,wordpress u-deginDDD领域驱动设计批评文集
做强化自测题获得“软件方法建模师”称号
《软件方法》各章合集 下图是《分析模式》原书第2章的图2.10#xff0c;里面有一些错误和考虑不周的地方#xff1a; 2004中译本和2020中译本的翻译如下#xff1a; 基本上都是照搬#xff0c;没有改过…DDD领域驱动设计批评文集
做强化自测题获得“软件方法建模师”称号
《软件方法》各章合集 下图是《分析模式》原书第2章的图2.10里面有一些错误和考虑不周的地方 2004中译本和2020中译本的翻译如下 基本上都是照搬没有改过来。
Fowler网站上提供了该图的UML版本 但从图上看除了多重性和角色颠倒的错误得到修正——而且也没修正到位角色应该靠近Party Type而不是放中间。
其他错误没有改过来只是把这个图的表示法改成了UML。
我们下面先来看一下图2.10有哪些问题以及应该怎么改。
我把有问题的地方编了号如下 1
约束应该加在Accountability上而不是加在Accountability Type上。
一般来说**Type**类型这样的类它的对象个数很少而且值很稳定。很少需要在上面加不变式之类的约束。
就像一个类是“人”一个类是“性别”约束加在哪里一般是加在“人”上面。
人的属性值会变年龄增加个子变高体重变重结婚有配偶……
他的属性值之间可能会存在约束。例如如果年龄不到20岁是不能有配偶的。或者说如果说你年龄是20岁以下又有配偶那就违反了约束。
如果在“性别”上搞一个不变式“性别”除了“名称”还有什么属性让“性别”知道“人”然后把“性别”所关联的“人”一个很大的集合拉进来那为什么不干脆放在“人”上面呢
图2.10就是如此。约束加在Accountability Type上但第1行就定义了一个x说是self.Accountability这不又绕回去了嘛干吗不把约束加在Accountability上面呢
2
假设我们咬紧牙关坚持己见一定要把约束加在Accountability Type上但self.Accountability的Accountability在哪里呢图上没有。
3
即使图上有Accountability还有另一个问题Accountability Type的self.Accountability是一个集合不能直接.commissioner得加类似-forAll(a|a.commissioner……
2020中译本把原文以复数形式表示的词都加了一个后缀“集合”这个做法好不好另外讨论不过如果这样做的话下面这个地方也要加一个“集合” 4
多重性和角色颠倒的问题type、all types放在Party一侧supertype和subtypes的多重性颠倒。
5
多了一个冗余关联all types意思是Party所属的Party Type以及其上的所有supertype组成的Party Type集合。
在图上是用自然语言表达的现在可以用OCL的闭包Closure运算来表达并删除冗余关联。
求闭包是关系代数常见试题下图是2021年的一道软考题 OCL有closure运算 考虑以上的问题之后我们修正的类图如下 修改的要点
1加上了“当责Accountability”。
2把约束放在“当责”上。
3多重性和角色位置的调整。
4删除冗余all types关联
5约束的意思是
对“当责”的“委托方”当事者的“类型”当事者类型做求超类型的闭包运算就得到了原书图上的冗余all types“当事者类型”集合然后该集合中有元素也在“当责”的“类型”当责类型的“委托方”当事者类型集合中也就是说这两个集合交集不为空。
对“责任方”也如此操作就得到了图中的约束。
