以下模型是一个项目从启动到最终部署，逐步细化（精化）、实现的过程
1、业务用例模型
业务用例模型在项目启动阶段，使用业务用例模型来获取需求，是为了真是业务建立模型，为了和客户达成共识，暂不考虑计算机环境。
业务用例模型是非必须的，尤其是在规模较小的软件项目中。
2、概念用例模型
概念用例模型在项目启动阶段，是业务用例模型的一个子集，是从业务用例中抽取的某个关键业务流程。在项目规模较小，不需要该模型。
3、系统用例模型
系统用例模型在项目启动阶段末期或精化阶段的早期。系统建模就是需求获取，系统用例就是平时常见的普通用例，因此系统用例模型可以简称为用例模型。
用例模型是需求获取的输出，是分析设计、测试流程的输入。可以作为合同附件来约定系统开发范围。
4、领域模型
领域模型是现实世界的映射，主要关注对现实世界的概念，而不是纯粹计算机语言的描述，因此领域模型也被称作概念透视图。由于领域模型会把重要的特征抽象出来，更容易进行分析和后续构思。在之后的类图设计过程中，也会参考领域模型，作为重要的灵感来源之一。
领域模型实质是UML类图的一部分，不过与完整的类图最大区别是领域模型所使用的类名完全是现实中使用，而且领域模型中每个类都代表了一个现实对象，而非计算机软件模型中的对象。
5、分析模型
分析模型是从需求阶段到设计阶段的过渡。
分析模型包括：架构视图、用例视图、静态视图、动态视图、组件视图、部署视图
时序图，将主角和系统之间加入边界类作为操作界面，在边界类和实体交互之间加入控制类作为业务逻辑，边界类不要和实体类直接交互。
类之间的关系：
实体类和实体类之间可以有聚合或组合关系，不要有依赖关系，只能通过控制类间接交互；
控制类和控制类之间不要有聚合或组合关系，尽量减少依赖；
边界类依赖于控制类，控制类依赖于实体类。
6、软件架构和框架模型
架构：是系统骨架，是系统蓝图，是对系统高层次的定义和描述，具有战略性；
框架：是解决方案，是基础机构，是多某个问题的通过的、可复用的解决方法，具有战术性；
软件架构通过两个视角来描述：广度视角、深度视角，这两个视角构成对软件架构的“立体”描述。
广度视角：先对软件分层描述；
深度视角：再对每一层进行更深入的描述。
软件框架：是针对一个普遍问题的通用解决方案，例如第三方开源或商用的框架。
到这里已经实现：概要设计
7、设计模型
设计模型也称为详细设计，是编码现象之前的最后一道建模工序。
设计模型包括：架构视图、用例视图、静态视图、动态视图、组件视图、部署视图，可以通过对分析模型的细化来实现设计模型。
【UML】类图Class Diagram
【UML】活动图Activity Diagram、状态机图State Machine Diagram、顺序图Sequence Diagram
【UML】用例图Use Case Diagram、部署图Deployment Diagram、构件图Component Diagram
8、组件模型
组件是组成架构的子项，一般会称为某个架构的某个组件。一般在分布式系统中，经常提到组件。
不同情况下，组件还有不同的称呼：模块、子系统、类库、可执行程序、包等。
9、实施模型
实施模型由配置节点和组件组成。一般用配置节点描述硬件、组件描述软件，通常用于分布式系统中。
