如何判断UML中的各个组件的必要性

1.1业务模型部分

1.1.1是否需要业务模型

下面所涉及到的名词“机构”，可以理解为要为某个单位开发项目中的“单位”的概念标准：·你和工作组不熟悉机构。·机构最近进行了一些业务过程重建工作。·机构准备进行业务过程重建工作。·建立机构主要部分使用软件。·机构中有些大型复杂工作流的文档不足。·你到别人的公司当顾问。下列情况可能不需要业务模型：·你彻底了解机构的结构、目标、业务前景和主体。·建立的软件只在机构的局部使用，不会影响到公司其他部分。·机构中的工作流很简单，文档齐备。·没时间。我们要现实一些，并不是所有项目都有进行完全业务分析所需的时间。但要小心，不要吧没时间当借口。如果业务模型有助于项目成功，就应挤出时间。

1.1.2业务角色

看谁与业务交流，这个谁可以是自然人也可以是其他的实体，它必须在整个机构的范围之外。

1.1.3业务工人

与业务角色相对应，它要在机构范围之内。

1.1.4业务用例

这个不好说，应该说是从对甲方的了解和任务报告开始研究，或者从高层介绍公司向外部提供的价值。或者开会检查机构的过程，与客户和其他股东交谈或利用自己的业务知识。

1.1.5业务实体

·公司生产什么产品·公司提供什么服务·公司购买什么产品·公司发送或接收什么项目·什么东西从业务工人传给另一个业务工人处理

1.2 系统模型部分

1.2.1系统用例

1、理解文档。2、询问项目的保管员 ·这个保管人要用这个系统做什么？·保管人是否要维护任何信息（创建、读取、更新、删除）？·保管人是否要把外部事件告诉系统？·系统是否要把某些变化和事件告诉保管人？

1.2.2 事件流

事件流是系统用例必须要的，所以这里就不说明如何判断了，只是指出事件流应该包含什么东西。·简要说明·前提条件·主事件流·其他事件流·事后条件主事件流和其他事件流：①用例如何开始②使用用例的各种途径③使用用例的正常流程④使用用例主事件流（其他事件流）的变形⑤错误流⑥使用用例如何结束如何判断事件流的详细程度：1、开发者与客户不能有分歧，但是文档也不能太复杂。2、一定要足够详细到能够指导创建系统设计和最终建立系统。3、能够创建测试脚本。

1.2.3关系

如果是角色与用例之间的关系，那么就是关联关系。如果是用例之间的关系，那么就是关系、扩展关系和一般化关系。如果是描述角色之间的关系，那么就是一般化关系。角色一般化关系：如果角色一般化能使小组得到有用的信息，则进行角色一般化，否则就没必要进行角色一般化。*特别是，如果公司客户启动一些个人客户不启动的用例，则最好进行角色一般化。如果两种客户使用相同的用例，则没必要进行角色一般化。如果两种客户使用相同的用例，但只是稍有不同，则仍然没有必要进行角色一般化。其实，最一般的理解就是类的继承，如果有A类，它继承于B类，那么A类和B类就要进行角色一般化。*引用Rational Rose 2002从入门到精通
总之，看角色是否启动相同的用例，如果启动的话就没必要一般化，否则，就要一般化。同样，这个规则适用于其他的UML组件。