确切地说,UML类图只是一种符号,您可以(并且应该)根据您所处的软件开发阶段而有所不同。您可以从只有类,属性和关联开始,然后优化图表以添加属性的类型信息,然后导航,类方法,关联限定符......直到你得到一个完整的类图为实现阶段做好准备
请注意,您甚至可以迭代到删除关联的位置,并将其替换为复杂类型的属性,以使类图更类似于最终实现。由您决定如何在每个阶段使用类图。
一旦他开始谈论班级图,马丁福勒的书对我来说就是废话(例如我个人的感觉)!我同意其他图表但是类图应该更实用,而不仅仅是高级设计!!
你需要在更高的抽象层次上进行建模,然后对你真正需要的东西进行建模。 我更喜欢快速提供正在运行的代码并将其显示给客户。从第一阶段开始,我们开始建模以获得功能需求以及代码。一旦我们完成第二阶段,我们再次向客户展示它,并再次提供UML类图来改变需要完成的工作。经过10次迭代后,我的项目通常会完成。 例如我的项目持续3到6个月。这是一个非常复杂的项目,我的客户通常很满意。使用Martin fowler的推荐,我的项目将在12-18个月内完成,客户肯定会感到失望。
以下是我向开发人员解释这些想法的方法。
概念是关系。这是应该发生耦合的水平。您不应该看到从概念到实现的耦合 - 这是设计不佳的信号。
规范定义算法而不定义实现。在类图中,这可以表示为抽象类。 Alan Shalloway称这些领域的方法属于“警长方法”:他们只是吠叫命令。
实施是实际工作发生的地方。这可能由实现您的抽象规范的具体类表示。
好问题。这是我自己经历的一些想法;不能说马丁是否同意(!)但仍然有用。
总结:主要区别来自形式和关系的设计选择。
我发现以下内容很有用:
基本结构:大致映射到Fowler的UML作为草图,并在交互式白板上完成。主要目的是了解整体结构。很随意。特别是,关注关系只是为了识别它们,而不是形式化 - 所以没有基数,删除行为,选择容器类等。
领域模型。一个精确的模型,专注于形式化关系。具体而言,命名关联结束,定义基数并确认删除行为。不考虑基数> 1的导航性或容器类的选择。我知道用于学习问题域的最佳技术之一。
我几乎总是使用上述两种方法。域模型的关键是使用基于动词的命名而不是基于角色 - 因为它描述了关系存在的原因(有效地表达了业务规则:例如“一个订单必须由一个客户放置”)。我使用了中描述的命名模板 Simsion&威特 的书。
将域模型转换为工作代码,特别是在关系中,还有很多工作要做。编程语言不能很好地支持关系,因此必须将关联转换为参与类的属性。正是在这一点上,导航性发挥作用,以及多重性> 1的集合类型的选择。它也是需要指定所有操作的地方。我个人认为这种图表并不特别有用。域模型加上代码可以为我提供所需的一切。
如果我使用可执行的UML工具,我将只使用“UML作为编程语言”。
抱歉,如果这有点漫无边际,希望它有帮助......
PS:如果你想要一个更好的基于动词命名的例子,我有一个 发布在我的博客上 。请不要把它作为自我推销,在这里重复没有意义。