我目前正在阅读Martin Fowler的UML Distilled.我刚刚介绍了关于类图的部分,他强调在建模类图之前需要整理透视图.但是,我对实际绘制类图时的实际情况略显困惑.据我所知,理论上的含义会改变一个关联从一个角度到下一个角度的含义.
我想我的主要问题是,例如,如果我像书中那样建模一个简单的订购系统,那么类图会不同,并且从一个视角到另一个视角包含不同数量的符号.例如,从概念的角度来看,我只是展示类和一些模糊的关联及其多样性,然后在规范透视图中进行建模时,包括导航性和基本类操作和字段.
我真的很感激这方面的一些指导,因为我真的想更好地掌握这个主题.
好问题.这是我自己经历的一些想法; 不能说马丁是否同意(!)但仍然有用.
总结:主要区别来自形式和关系的设计选择.
我发现以下内容很有用:
基本结构:大致映射到Fowler的UML作为草图,并在交互式白板上完成.主要目的是了解整体结构.很随意.特别是,关注关系只是为了识别它们,而不是形式化 - 所以没有基数,删除行为,选择容器类等.
领域模型.一个精确的模型,专注于形式化关系.具体而言,命名关联结束,定义基数并确认删除行为.不考虑基数> 1的导航性或容器类的选择.我知道用于学习问题域的最佳技术之一.
我几乎总是使用上述两种方法.域模型的关键是使用基于动词的命名而不是基于角色 - 因为它描述了关系存在的原因(有效地表达了业务规则:例如"一个订单必须由一个客户放置").我使用了Simsion&Witt的书中描述的命名模板.
将域模型转换为工作代码,特别是在关系中,还有很多工作要做.编程语言不能很好地支持关系,因此必须将关联转换为参与类的属性.正是在这一点上,导航性发挥作用,同时选择多重性> 1的集合类型.它也是需要指定所有操作的地方.我个人认为这种图表并不特别有用.域模型加上代码可以为我提供所需的一切.
如果我使用可执行的UML工具,我将只使用"UML作为编程语言".
抱歉,如果这有点漫无边际,希望它有帮助......
PS:如果你想要一个更好的基于动词命名的例子,我的博客上有一篇文章.请不要把它作为自我推销,在这里重复没有意义.