一、确定系统用例
系统用例由业务用例抽象而来，系统用例描述系统，业务用例描述业务。
业务用例抽象为系统用例的基本方法有：
映射：映射是最简单最直接的方法；
抽象：当业务场景当中的备选用例不能够被直接映射时，需要进行一些抽象；
合并：当业务场景当中的备选用例不具备独立性时，它必然是其他某个时间的组成部分；
拆分：有时业务用例场景当中的一个备选用例粒度很大，就需要进行拆分；
演绎：有时业务用例场景当中找不到备选用例，或者不适合用计算机来实现，但是能够遇见到某个可能的系统用例潜伏在这个场景当中，就需要演绎找出来。
在确定系统用例后，可以采用活动图、时序图、交互图等进行系统用例的描述。
软件工程当中，需求的可追溯性是很重要的。从业务需求到系统需求的过程关键就在映射、抽象、合并、差分和演绎的过程能否被记录下来。
根据阶段不同，使用不同的粒度：在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜；在概念建模阶段，用例的粒度以每个用例能描述一个完整的事件流为宜；在系统建模阶段，用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。
二、分析业务规则
业务规则对一个组织的运转来说至关重要，从管理制度到业务手册、从操作规范到岗位指南，业务规则充斥着整个企业的方方面面。
分析业务规则的目的是从业务规则当中发现出那些将对系统构成重大影响的部分，将其转化为系统需求，并且针对这一部分进行有针对性的架构、框架、程序的设计。
分析全局规则
全局规则是那些对于系统大部分业务或系统设计都起约束作用的那些规则。
全局规则在应用程序当中就被反应到了软件结构当中，通过软件架构来对用例产生影响。
分析交互规则
交互规则产生于用例场景当中。用例场景是由活动图、交互图等来描述的，不论是活动、状态还是业务对象，它们在活动转移、状态变迁和对象交互时必然会有一些限制性条件，这些条件就是交互规则。
交互规则产生于用例场景当中，很可能是跨用例的，为了避免依赖的出现，应当将较复杂的交互规则设计成单独的对象或模块。
分析內禀规则
内禀规则是业务对象本身具备的，并且不因为外部的交互而变化的规则。
内禀规则非常类似于对象的封装原则，所以交给程序员来处理即可。
三、用例实现
一个用例可能有多个用例实现，每个用例实现都是设想的一种实现方式。
要为用例实现建模，我们需要经过一下三个步骤：
1.需要再用例场景当中发现和定义实体对象；
2.需要用控制对象来操作和处理实体对象当中的数据；
3.需要用边界对象来构建接受外部指令的界面。
用边界对象、控制对象和实体对象实现场景后，我们就得到了分析类图。
分析类是高层次抽象出系统实现业务需求的原型，业务需求通过分析类被逻辑化，成为可以被计算机理解的语义。分析类抽象层次高于设计实现，高于语言实现，也高于实现方式。
高于设计实现意味着，在为需求考虑系统实现的时候，可以不理会复杂的设计要求，专心地为从需求到实现搭建一座桥梁；
高于语言实现意味着，在为需求考虑系统实现的时候，可以不理会采用哪一种语言来编写，而能专注在需求实现上；
高于实现方式意味着，在为需求考虑系统实现的时候，可以不考虑采用哪一种具体实现方式，只需要用一个程序逻辑来完成需求即可。
四、软件架构和框架
架构设计考虑使用一个软件层次结构、一个或多个软件框架以及连接这些软件层次和软件框架之间的接口，将功能性需求和非功能性需求有机结合在一起，在进行系统设计之前就充分考虑到了系统各功能部件如何在整个系统内安置。
软件架构是一种思想，一个系统蓝图，对软件结构组成的规划和职责设定。软件架构的意义就是要将这些可逻辑划分的部分独立出来，用约定的接口和协议将它们有机地结合在一起，形成职责清晰、结构清楚的软件架构。
软件框架是是软件架构的一种实现，是一个半成品。它通常针对一个软件架构当中某一个特定的问题提供解决方案和辅助工具。
五、分析模型
分析类的推导过程为：
1、通过用例确定了系统需求；
2、通过用例实现，得到了系统需求的计算机视角理解；
3、规定了软件架构，确定了软件层次；
4、在每一个软件层次上决定了适用的软件框架；
5、分析了用例实现在每个软件层次上是如何动作的；
6、根据每个软件层次上所使用的软件框架并使用分析类来实现用例；
7、综合各个软件层次得到的分析类，形成分析模型；
8、得到实现了系统需求最基本的类和类方法。
六、组件模型
组件是用来容纳分析类或设计类的，建立组件的目的是为了将一些类组织在一起完成一组特定的功能。
组件可以看成一种特殊的包，不应当包含实现细节，只包含服务的接口，同时只维护调用服务的实现方式。
组件是可复用的单元。
组件是可独立变化的单元。
组件是可独立部署的单元。
组件可在软件架构支持环境下自由组装。
七、部署模型
部署模型又称为实施模型，它主要的作用就是定义构成应用程序的各个部分在物理结构上的安装和部署位置。
部署模型与应用程序和运行环境有关。
系统用例由业务用例抽象而来，系统用例描述系统，业务用例描述业务。
业务用例抽象为系统用例的基本方法有：
映射：映射是最简单最直接的方法；
抽象：当业务场景当中的备选用例不能够被直接映射时，需要进行一些抽象；
合并：当业务场景当中的备选用例不具备独立性时，它必然是其他某个时间的组成部分；
拆分：有时业务用例场景当中的一个备选用例粒度很大，就需要进行拆分；
演绎：有时业务用例场景当中找不到备选用例，或者不适合用计算机来实现，但是能够遇见到某个可能的系统用例潜伏在这个场景当中，就需要演绎找出来。
在确定系统用例后，可以采用活动图、时序图、交互图等进行系统用例的描述。
软件工程当中，需求的可追溯性是很重要的。从业务需求到系统需求的过程关键就在映射、抽象、合并、差分和演绎的过程能否被记录下来。
根据阶段不同，使用不同的粒度：在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜；在概念建模阶段，用例的粒度以每个用例能描述一个完整的事件流为宜；在系统建模阶段，用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。
二、分析业务规则
业务规则对一个组织的运转来说至关重要，从管理制度到业务手册、从操作规范到岗位指南，业务规则充斥着整个企业的方方面面。
分析业务规则的目的是从业务规则当中发现出那些将对系统构成重大影响的部分，将其转化为系统需求，并且针对这一部分进行有针对性的架构、框架、程序的设计。
分析全局规则
全局规则是那些对于系统大部分业务或系统设计都起约束作用的那些规则。
全局规则在应用程序当中就被反应到了软件结构当中，通过软件架构来对用例产生影响。
分析交互规则
交互规则产生于用例场景当中。用例场景是由活动图、交互图等来描述的，不论是活动、状态还是业务对象，它们在活动转移、状态变迁和对象交互时必然会有一些限制性条件，这些条件就是交互规则。
交互规则产生于用例场景当中，很可能是跨用例的，为了避免依赖的出现，应当将较复杂的交互规则设计成单独的对象或模块。
分析內禀规则
内禀规则是业务对象本身具备的，并且不因为外部的交互而变化的规则。
内禀规则非常类似于对象的封装原则，所以交给程序员来处理即可。
三、用例实现
一个用例可能有多个用例实现，每个用例实现都是设想的一种实现方式。
要为用例实现建模，我们需要经过一下三个步骤：
1.需要再用例场景当中发现和定义实体对象；
2.需要用控制对象来操作和处理实体对象当中的数据；
3.需要用边界对象来构建接受外部指令的界面。
用边界对象、控制对象和实体对象实现场景后，我们就得到了分析类图。
分析类是高层次抽象出系统实现业务需求的原型，业务需求通过分析类被逻辑化，成为可以被计算机理解的语义。分析类抽象层次高于设计实现，高于语言实现，也高于实现方式。
高于设计实现意味着，在为需求考虑系统实现的时候，可以不理会复杂的设计要求，专心地为从需求到实现搭建一座桥梁；
高于语言实现意味着，在为需求考虑系统实现的时候，可以不理会采用哪一种语言来编写，而能专注在需求实现上；
高于实现方式意味着，在为需求考虑系统实现的时候，可以不考虑采用哪一种具体实现方式，只需要用一个程序逻辑来完成需求即可。
四、软件架构和框架
架构设计考虑使用一个软件层次结构、一个或多个软件框架以及连接这些软件层次和软件框架之间的接口，将功能性需求和非功能性需求有机结合在一起，在进行系统设计之前就充分考虑到了系统各功能部件如何在整个系统内安置。
软件架构是一种思想，一个系统蓝图，对软件结构组成的规划和职责设定。软件架构的意义就是要将这些可逻辑划分的部分独立出来，用约定的接口和协议将它们有机地结合在一起，形成职责清晰、结构清楚的软件架构。
软件框架是是软件架构的一种实现，是一个半成品。它通常针对一个软件架构当中某一个特定的问题提供解决方案和辅助工具。
五、分析模型
分析类的推导过程为：
1、通过用例确定了系统需求；
2、通过用例实现，得到了系统需求的计算机视角理解；
3、规定了软件架构，确定了软件层次；
4、在每一个软件层次上决定了适用的软件框架；
5、分析了用例实现在每个软件层次上是如何动作的；
6、根据每个软件层次上所使用的软件框架并使用分析类来实现用例；
7、综合各个软件层次得到的分析类，形成分析模型；
8、得到实现了系统需求最基本的类和类方法。
六、组件模型
组件是用来容纳分析类或设计类的，建立组件的目的是为了将一些类组织在一起完成一组特定的功能。
组件可以看成一种特殊的包，不应当包含实现细节，只包含服务的接口，同时只维护调用服务的实现方式。
组件是可复用的单元。
组件是可独立变化的单元。
组件是可独立部署的单元。
组件可在软件架构支持环境下自由组装。
七、部署模型
部署模型又称为实施模型，它主要的作用就是定义构成应用程序的各个部分在物理结构上的安装和部署位置。
部署模型与应用程序和运行环境有关。