如何判断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 组件。