是否需要在业务需求、功能需求、软件规范等文档中包含类图?
简单的答案是“这要看情况了!“
与其他任何UML图一样,类图只是一个供分析员使用的工具。如果没有一个固定的过程,分析师可以自行决定何时使用类图。因此,在哪个分析文档中应该包含类图取决于它的使用。
首先,让我们通过查看类图的一些特性来确定它能为您做些什么:
类图为“类”建模,也称为类型Class。它显示了在被分析的领域中可以存在哪些类型的事物。
记住:事物=名词!
比如为了表达交易可以找到“订单”这个事物名词,这称为名词法,分析领域基本分两大派:名词法和动词法。动词法就是首先找出动词、动作、事件,比如事件建模。又比如事件和状态就是动词和名词,从事件入手分析导致函数计算方向,从状态入手分析导致类图数据表等结构方向,这两者不能偏颇,见:一篇有关函数式编程的形象生动教程
类图可以显示类的“属性”,它显示了可以使用什么类型的数据来描述给定的事物。
类图说明了“类”是如何相互关联的。它描述了在一个特定领域中存在的各种事物之间可能存在的关系。
类图显示“多重性”,也称为“基数”。这个概念是用来进一步澄清事物之间的关系,通过指定一种类型的事物有多少与另一种类型的事物有多少相关。
因此,如果分析人员使用类图来描述业务用户(也称为业务域)的术语中发现的关键名词以及它们之间的关系,那么这个类图将表示一个领域模型,并且可能属于项目的早期构件之一,如业务需求文档。
另一方面,如果类图用于解释将使用哪些C类来实现功能需求和描述这些类的数据属性类型,那么该图将被视为设计工件,可能属于系统规范/技术规范文档。