We have established in Part 1 that the UML is a language for specifying the artifacts and interactions of a software system. We have also seen that it deals with 6 major domains - from Use Case models, through dynamic and logical models to the final physical deployment model - and that extension mechanisms have been included to allow for specialised additions to the model notation.
我们已经在第一部分建立了这样一种认识，即UML是一种用于制定软件系统构成要素和交互方式标准的语言。UML涉及6大主要方面—— 从用例模型、动态和逻辑模型到最终的物理部署模型，以及允许给模型添加特别标注的扩展机制。
So... How do you use the UML?
那么，如何使用UML呢?
The UML is typically used as a part of a software development process, with the support of a suitable CASE tool, to define the requirements, the interactions and the elements of the proposed software system. The exact nature of the process depends on the development methodology used. An example process might look something like the following:
一般地，UML作为软件开发过程的一部分，在具体的CASE工具支持下，用来定义所开发系统的需求，交互和元素。开发过程的确切性质则取决所采用的开发方法。一个典型的开发过程大致如下：
1. Capture a Business Process Model. This will be used to define the high level business activities and processes that occur in an organization and to provide a foundation for the Use Case model. The Business Process Model will typically capture more than a software system will implement (ie. it includes manual and other processes).
1. 建立一个业务过程模型。业务过程模型被用来定义发生在企业或组织内部的高级业务活动和业务过程，并且是建立用例模型的基础。一般来说业务过程模型比一个软件系统所能实现的更多（比如：业务模型包括人力和其他过程）。
2. Map a Use Case Model to the Business Process Model to define exactly what functionality you are intending to provide from the business user perspective. As each Use Case is added, create a traceable link from the appropriate business processes to the Use Case (ie. a realisation connection). This mapping clearly states what functionality the new system will provide to meet the business requirements outlined in the process model. It also ensures no Use Cases exist without a purpose.
2. 映射用例模型到业务过程模型以精确定义你要提供的功能，并且是站在业务用户角度考虑的。每增加一个用例时，将创建一个从适当的业务过程到该用例的可跟踪链接（如：一个实现链接）。这个映射清楚地表达新系统将提供什么样的功能来满足业务过程中所描述的业务需求。这种映射也确保系统中每个用例都是有用的。
3. Refine the Use Cases - include requirements, constraints, complexity rating, notes and scenarios. This information unambiguously describes what the Use Case does, how it is executed and the constraints on its execution. Make sure the Use Case still meets the business process requirements. Include the definition of system tests for each use case to define the aceptance criteria for each use case. Also include some user acceptance test scripts to define how the user will test this functionality and what the acceptance criteria are.
3. 完善用例-包括需求，约束、复杂程度、注释及情形。这些信息清楚地描述用例做什么，如何做以及执行时的相关约束。这个过程要保证用例始终满足业务过程的需求，包括每个用例的系统测试定义，该定义为该用例定义了接收标准。也包括了一些用户可接受的测试脚本：这些脚本定义了用户将如何进行测试和测试接收的标准。
4. From the inputs and outputs of the Business Process Model and the details of the use cases, begin to construct a domain model (high level business objects), sequence diagrams, collaboration diagrams and user interface models. These describe the 'things' in the new system, the way those things interact and the interface a user will use to execute use case scenarios.
4. 有了业务过程模型的输入与输出和用例的详细信息，就可以开始构建领域模型（高级业务对象）、顺序图、协作图和用户接口模型。这些图描述新系统中的要素以及这些要素之间的相互作用和用户执行用例时所需各种情形的接口。
5. From the domain model, the user interface model and the scenario diagrams create the Class Model. This is a precise specification of the objects in the system, their data or attributes and their behaviour or operations. Domain objects may be abstracted into class hierarchies using inheritance. Scenario diagram messages will typically map to class operations. If an existing framework or design pattern is to be used, it may be possible to import existing model elements for use in the new system. For each class define unit tests and integration tests to thoroughly test i) that the class functions as specified internally and that ii) the class interacts with other related classes and components as expected.
5. 在领域模型、用户接口模型和情形图的基础上，开始建立对象类模型。这是制定系统中对象的明确规范：数据、属性、行为和操作。使用继承机制，可将领域对象抽象为类层次结构。处理各种情形的消息一般被映射到类的操作。如果使用一个现存的框架或设计模式，则可能导入现存模型的元素到新系统中。为每一个类定义单元测试、集成测试和系统测试。测试目的：1）类的功能是否如所定义的，2）类与其它类及组件的交互是否如期望的。
6. As the Class Model develops it may be broken into discrete packages and components. A component represents a deployable chunk of software that collects the behaviour and data of one or more classes and exposes a strict interface to other consumers of its services. So from the Class Model a Component Model is built to define the logical packaging of classes. For each component define integration tests to confirm that the component's interface meets the specifcation given it in relation to other software elements.
6. 当开发类模型时，可能需要将它分解成包和组件。一个组件代表一个可使用的软件块，它是一个类或者多个类的数据和行为的结合，并严格定义一个对外提供服务的接口。所以，从类模型的角度看，构造组件模型就是定义类的逻辑包。对于每一个组件，需要定义集成测试，以证实组件的接口满足规范要求，即与其它软件元素的关系。
7. Concurrent with the work you have already done, additional requirements should have been captured and documented. For example - Non Functional requirements, Performance requirements, Security requirements, responsibilities, release plans & etc. Collect these within the model and keep up to date as the model matures.
7. 在完成上述工作的同时，需要获取一些额外的需求并整理成文档。例如：非功能性需求，性能需求，安全需求，义务需求，发布计划等。将这些需求在模型内部进行整合并随模型的进展而更新。
8. The Deployment model defines the physical architecture of the system. This work can be begun early to capture the physical deployment characteristics - what hardware, operating systems, network capabilities, interfaces and support software will make up the new system, where it will be deployed and what parameters apply to disaster recovery, reliability, back-ups and support. As the model develops the physical architecture will be updated to reflect the actual system being proposed.
8. 部署模型定义系统的物理架构。这个工作可以提前开始以便于掌握系统的物理结构特性——使用什么样的硬件、操作系统、网络规模、接口与支持软件，来构成新系统，和系统部署在那里，以及出现灾难性故障时的系统恢复，系统可靠性、系统备份与支持等方面所使用的参数。随着模型开发的不断进展，物理系统模型应该不断更新以反映所开发系统的实际情况。
9. Build the system: Take discrete pieces of the model and assign to one or more developers. In a Use Case driven build this will mean assigning a Use Case to the development team, having them build the screens, business objects, database tables, and related components necessary to execute that Use Case. As each Use Case is built it should be accompanied by completed unit, integration and system tests. A Component driven build may see discrete software components assigned to development teams for construction.
9. 构造系统：将模型的分散模块分配给一个或多个开发者。如果采用用例驱动的方法构造系统，这将意味分配一个用例给开发小组，让他们构造用户界面，业务对象，数据库表以及执行该用例所必须的相关组件。在构造每个用例时，应该同时完成单元测试、集成测试和系统测试。如果采用组件驱动的方法构造系统，则需将各个组件分配给开发小组。
10. Track defects that emerge in the testing phases against the related model elements - eg. System test defects against Use Cases, Unit Test defects against classes & etc. Track any changes against the related model elements to manage 'scope creep'.
10. 对照模型中的元素，跟踪查找出现在测试阶段的缺陷。如：查看针对用例的系统测试缺陷，查看针对对象类的单元测试缺陷等等，跟踪相关模型元素的修改以防止范围漫延。
11. Update and refine the model as work proceeds - always assessing the impact of changes and model refinements on later work. Use an iterative approach to work through the design in discrete chunks, always assessing the current build, the forward requirements and any discoveries that come to light during development.
11. 随着工作进展不断更新和完善模型——每次修改模型或完善模型，都要评价所做的修改或改善对后续工作的影响。在模块设计中使用反复式工作方法，评介当前构造的模块，新到达的需求，以及开发过程发现的任何问题。
12. Deliver the complete and tested software into a test then production environment. If a phased delivery is being undertaken, then this migration of built sofware from test to production may occur several times over the life of the project.
12. 将完整的，并经过测试的软件发送到测试生产环节。如果采用分阶段发送，那么这种软件生产方式需要从测试到生产的多次往复才能最终完成整个项目。
Note that the above process is necessarily brief in description, leaves much unsaid and may not be how you work or follow the process you have adopted. It is given as an example of how the UML may be used to support a software development project.
注意：上面描述的过程只是项目开发所必须经历的一个简要概述，还有很多没有提及。它不是告你应该如何工作，或者不遵循你已经采用的方法。它只给出如何用UML来支持软件开发项目的一个例子。