软件生命期一般包括：软件计划与可行性研究（问题定义、可行性研究）、需求分析、软件设计（概要设计和详细设计）、编码、软件测试、运行与维护。为了提高软件的开发效率出现了从不同角度作为出发点的软件开发方法，常见的有：数据库驱动开发DDD（Database-Driver- Development）、测试驱动开发TDD（Test-Driver-Development）、模型驱动开发MDD（Model-Driver-Development）。UML建模在模型驱动开发中运用比较多。
UML模型有用例图、类图、对象图、状态图、活动图、顺序图、协作图、构件图、部署图、包图、组合结构图、交互概览图等，他们的用途如下：
- 用例图：从用户角度描述系统功能。
- 类图：描述系统中类的静态结构。
- 对象图：系统中的多个对象在某一时刻的状态。
- 状态图：是描述状态到状态控制流，常用于动态特性建模
- 活动图：描述了业务实现用例的工作流程
- 顺序图：对象之间的动态合作关系，强调对象发送消息的顺序，同时显示对象之间的交互
- 协作图：描述对象之间的协助关系
- 构件图：一种特殊的UML图来描述系统的静态实现视图
- 部署图：定义系统中软硬件的物理体系结构
- 包图：对构成系统的模型元素进行分组整理的图
- 组合结构图：表示类或者构建内部结构的图
- 交互概览图：用活动图来表示多个交互之间的控制关系的图
在软件生命周期的不同阶段选用不同的UML模型可以帮助我们更好的理解业务需求和系统逻辑。按照开发阶段，使用UML建模时可以将模型架构分为：业务模型、需求模型、分析模型、设计模型、实现模型、部署模型。
1. 需求分析（用例图、类图、活动图）
1.1 需求获取（用例图）
使用用例图获取需求，这一阶段的主要任务就是了解用户需求，并将其转换为业务用例图。绘制业务用例图时需要注意三点：
- 业务用例是仅从系统业务角度关注的用例，而不是具体系统的用例。它描述的是"该实现什么业务"，而不是"系统该提供什么操作"。例如，在实际系统中，"登录"肯定要作为一个用例，但是这是软件系统中的操作，而用户所关注的业务是不包含"登录"的。
- 业务用例仅包含客户"感兴趣"的内容。
- 业务用例所有的用例名应该让客户能看懂，如果某个用例的名字客户看不懂什么意思，它也许就不适合作为业务用例。
以CMS系统为例，根据需求描述得出如下业务用例：
1.2 分析（状态图、类图、活动图）
完成了业务用例图后，就要为每一个业务用例绘制一幅活动图。活动图描述了这个业务用例中，用户可能会进行的操作序列。活动图有个很重要的使命：从业务用例分析出系统用例。
以管理新闻业务为例，他的活动图如下：
可以看到，一个"管理新闻"这个业务用例，分解出很多系统操作。活动图中很多"活动"都很可能是一个系统用例，例如，这个活动图中可能包含以下备选系统用例：登录、注销登录、查看新闻列表、修改新闻、删除新闻。
将每个业务用例都绘制出相应的活动图后，再将其中的"活动"整合，就得出所有备选系统用例。
找出所有的备选系统用例后，需要进行合并和筛选。合并就是将相同的用例合并成一个，筛选就是将不符合系统用例条件的备选用例去掉。一个系统用例应该是实际使用系统的用户所进行的一个操作，例如，"查看新闻列表"就不能算一个系统用例，因为他只是某系统用例的一个序列项。
最终我们得出的系统用例图如下：
得出系统用例图后，应该对每一个系统用例给出用例规约。用例规约没有通用的格式，可以按照习惯的格式进行编写,对用例规约唯一的要求就是"清晰易懂"。例如，"登录"这个系统用例的规约如下：
下面就是绘制业务领域类图了。业务领域类图要识别出系统中的实体、实体间的联系以及实体的操作，主要要描述以下三点：
- 系统中有哪些实体
- 这些实体能做什么操作
- 实体间的关系
CMS系统的业务领域类图如下：
注意：业务领域类图中的实体不是Actor，而是Actor使用系统时使用的所调用的实体，是处在系统边界之内的实体。例如，管理员就没有作为一个实体出现在这里，因为管理员处在系统边界之外，它所有的工作都可以通过调用这三个类的方法完成。并且，这里的"User"实体也不是刚才用例图中注册会员这个Actor，而是作为一个系统内的业务实体，供Actor们使用的。例如，其中的register功能是给注册会员这个Actor使用，而remove功能，则是给管理员这个Actor使用的。
业务领域类图中的实体一定是在系统边界之内的，如果混淆了实体和Actor的关系将导致画出的领域类图不准确或职责分配不准确。在领域分析阶段，实体的属性并不重要，重要的是找出实体的操作。
识别出系统中的实体后还需要对业务规则进行分析。例如可以使用状图图描述新闻的发布规则：
2. 设计阶段（类图、包图、活动图、协作图、顺序图）
设计阶段一般要绘制实现类图。实现类图和领域类图不一样，它描述的是真正系统的静态结构，是和最后的代码完全一致的。因此，它和平台关系密切，必须准确给出系统中的实体类、控制类、界面类、接口等元素以及其中的关系。因此，实现类图是很复杂的，而且是平台技术有关的。
实现类图跟具体的平台技术相关，下面是一个实现类图的示意图：
实现类图是一种静态结构，需要给出动态结构，才能看清系统间的类是如何交互的。一般使用活动图、协作图、顺序图进行描述（建议不要做详细的协作图或顺序图-很难维护）。
例如，系统登录的时序图：
各个类间的调用关系可以使用协作图来描述。
3. 实施阶段（组件图、部署图）
系统开发完成后，为了更好的帮助实施人员进行系统部署，一般使用部署图进行描述系统组成及软硬件的关系。例如：
