CASE软件Enterprise Architect教程 ：UML（二）

【点击下载Enterprise Architect最新版本】

我们在上篇教程UML（一）已经确定UML是一种用于指定软件系统的工件和交互的语言。我们还看到它涉及6个主要领域，从用例模型，通过动态和逻辑模型到最终的物理部署模型，并且已经包含扩展机制以允许对模型符号进行专门添加。

那么如何使用UML？

UML通常用作软件开发过程的一部分，在合适的CASE工具的支持下，定义所提出的软件系统的要求，交互和元素。该过程的确切性质取决于所使用的开发方法。示例流程可能如下所示：

1获得业务流程模型，将用于定义组织中发生的高级业务活动和流程，并为用例模型提供基础。所述业务流程模型通常将捕获比软件系统更将实现（它包括手动和其它进程）。

2将用例模型映射到业务流程模型，以准确定义您希望从业务用户角度提供的功能。在添加每个用例时，创建从适当的业务流程到用例（即实现连接）的可跟踪链接。此映射清楚地说明了新系统将提供哪些功能以满足流程模型中概述的业务要求。它还确保在没有目的的情况下不存在用例。

3优化用例：包括要求，约束，复杂性评级，注释和方案。此信息明确地描述了用例的作用，执行方式以及执行的约束。确保用例仍符合业务流程要求。包括每个用例的系统测试定义，以定义每个用例的接受标准。还包括一些用户验收测试脚本，用于定义用户将如何测试此功能以及验收标准。

4 从业务流程模型的输入和输出 以及用例的详细信息，开始构建域模型（高级业务对象），序列图，协作图和用户界面模型。这些描述了新系统中的“事物”，这些事物的交互方式以及用户用于执行用例场景的界面。

5从域模型，用户界面模型和场景图创建类模型。这是对系统中对象，其数据或属性及其行为或操作的精确说明。可以使用继承将域对象抽象为类层次结构。场景图消息通常映射到类操作。如果要使用现有框架或设计模式，则可以导入现有模型元素以在新系统中使用。对于每个类，定义单元测试和集成测试以彻底测试i）该类在内部指定的功能和ii）该类与预期的其他相关类和组件交互。

6随着类模型的发展，它可以分解为独立的包和组件。组件表示可部署的软件块，用于收集一个或多个类的行为和数据，并向其服务的其他使用者公开严格的接口。因此，从类模型 中构建组件模型来定义类的逻辑包。对于每个组件，定义集成测试以确认组件的接口满足与其他软件元素相关的规范。

7在您已完成的工作的同时，应该捕获并记录其他要求。例如 - 非功能需求，性能要求，安全要求，职责，发布计划等。在模型中收集这些内容并随着模型的成熟保持最新。

8部署模型定义了系统的物理结构。这项工作可以尽早开始，以捕获物理部署特征 - 硬件，操作系统，网络功能，接口和支持软件将构成新系统，将在何处部署以及哪些参数适用于灾难恢复，可靠性，返回起来和支持。随着模型的发展，将更新物理架构以反映所提议的实际系统。

9构建系统：获取模型的离散部分并分配给一个或多个开发人员。在用例驱动的构建中，这将意味着将一个用例分配给开发团队，让他们构建执行该用例所必需的屏幕，业务对象，数据库表和相关组件。随着每个用例的构建，它应该伴随着完整的单元，集成和系统测试。组件驱动的构建可能会看到分配给开发团队的独立软件组件以进行构建。

10根据相关模型元素跟踪测试阶段出现的缺陷 - 例如。针对用例的系统测试缺陷，针对类的单元测试缺陷等。跟踪相关模型元素的任何更改以管理“范围蔓延”。

11随着工作的进行，更新和优化模型 - 始终评估变更和模型改进对后续工作的影响。使用迭代方法在离散块中完成设计，始终评估当前构建，前向要求以及在开发过程中发现的任何发现。

12将完整且经过测试的软件交付到测试然后生产环境中。如果正在进行分阶段交付，那么内置软件从测试到生产的迁移可能会在项目的整个生命周期内多次发生。

注意：上述过程在描述中必然是简短的，并且没有说明，并且可能不是您的工作方式或遵循您采用的过程。它是作为UML如何用于支持软件开发项目的示例给出的。

想要购买Enterprise Architect正版授权的朋友可以。

有关产品动态更多的精彩内容，敬请关注下方的微信公众号▼▼▼