uml第二部分

 

业务过程模型创建

业务过程模型被用来定义发生在企业或组织内部的高级业务活动和业务过程，并且是建立用例模型的基础。一般来说业务过程模型比一个软件系统所能实现的更多（比如：业务模型包括人力和其他过程）。

映射用例模型到业务过程模型

以精确定义你要提供的功能，并且是站在业务用户角度考虑的。每增加一个用例时，将创建一个从适当的业务过程到该用例的可跟踪链接（如：一个实现链接）。这个映射清楚地表达新系统将提供什么样的功能来满足业务过程中所描述的业务需求。这种映射也确保系统中每个用例都是有用的。

完善用例

包括需求，约束、复杂程度、注释及情形。这些信息清楚地描述用例做什么，如何做以及执行时的相关约束。这个过程要保证用例始终满足业务过程的需求，包括每个用例的系统测试定义，该定义为该用例定义了接收标准。也包括了一些用户可接受的测试脚本：这些脚本定义了用户将如何进行测试和测试接收的标准。

 

构建领域模型、顺序图、协作图和用户接口模型

有了业务过程模型的输入与输出和用例的详细信息，就可以开始构建领域模型（高级业务对象）、顺序图、协作图和用户接口模型。这些图描述新系统中的要素以及这些要素之间的相互作用和用户执行用例时所需各种情形的接口。

建立对象类模型

在领域模型、用户接口模型和情形图的基础上，开始建立对象类模型。这是制定系统中对象的明确规范：数据、属性、行为和操作。使用继承机制，可将领域对象抽象为类层次结构。处理各种情形的消息一般被映射到类的操作。如果使用一个现存的框架或设计模式，则可能导入现存模型的元素到新系统中。为每一个类定义单元测试、集成测试和系统测试。测试目的：1）类的功能是否如所定义的，2）类与其它类及组件的交互是否如期望的。

构造组件模型

当开发类模型时，可能需要将它分解成包和组件。一个组件代表一个可使用的软件块，它是一个类或者多个类的数据和行为的结合，并严格定义一个对外提供服务的接口。所以，从类模型的角度看，构造组件模型就是定义类的逻辑包。对于每一个组件，需要定义集成测试，以证实组件的接口满足规范要求，即与其它软件元素的关系。

 整理额外需求

　　在完成上述工作的同时，需要获取一些额外的需求并整理成文档。例如：非功能性需求，性能需求，安全需求，义务需求，发布计划等。将这些需求在模型内部进行整合并随模型的进展而更新。

8. 部署模型定义系统的物理架构

部署模型定义系统的物理架构。这个工作可以提前开始以便于掌握系统的物理结构特性-使用什么样的硬件、操作系统、网络规模、接口与支持软件，来构成新系统，和系统部署在那里，以及出现灾难性故障时的系统恢复，系统可靠性、系统备份与支持等方面所使用的参数。随着模型开发的不断进展，物理系统模型应该不断更新以反映所开发系统的实际情况。