一，分析概述

分析活动是对系统功能的结构化，即将系统功能落实到具体的抽象对象——分析类。
分析活动由开发团队主导，是设计实现的开端
分析活动的目标是得到与平台和技术无关，仅与系统需求有关，不易受变化影响，非常稳定的分析模型。
分析模型从开发人员视角，在逻辑上验证需求是否可以实现，是否自相矛盾（与需求过程中冲突识别不同）。同时，也为后续的设计和实现提供基础。
分析模型主要由包含了当前全部“用例实现分析”的“分析包”构成

二，分析模型建立

用例实现分析以分析类之间的协作，说明参与者和系统如何实现用例描述的功能。
用例实现分析也称为“鲁棒性分析”（健壮性分析）
鲁棒性分析过程分三步：（“鲁棒图”）
- 查看用例描述中的每一语句；
- 确定该语句所指动作需哪些界面、实体和控制对象参与；
- 画出这些对象及它们的关系。
鲁棒性分析的目的是为了检查用例所述功能在逻辑上，或理想情况下是否可以实现。
鲁棒性分析中识别实现用例的三种分析类：
- 界面类：负责与系统参与者的交互，即承担与参与者交互的职责。可能是人机接口，也可能是系统接口。
- 实体类：代表领域对象。其中，需要永久保存的对象要存放在文件或数据库中。
- 控制类：实现不适合界面和实体类实现的功能。控制类是增加稳定性的关键。
三种类可以从表现(Presentation)、行为(Behavior)、信息(Information)三个维度描述系统。
每种类别的类，至少具有两个维度的信息，这不同于传统功能/数据分割的结构化分析方法，同时可以提供抗变化的稳定模型。
将系统分成三层。实体类一层，控制类一层，界面类一层（与MVC模式一致）
识别分析类经验法则：每一个用例，首先给定一个界面类、一个控制类，然后参考从用例文本中识别出的领域类，确定本用例需要哪些实体类参与。在此基础上，根据需要适当增减。
识别出分析类后，再考虑用例所描述的功能(流程)是否可以落实(分配)到这些类上。方法是画分析类在用例流程中的动态关联。因为这种图表示了分析类之间不受外界影响的强壮关系，故称为“鲁棒图”
举例：登录用例的分析
- 用例名：登录系统
- 参与者：注册用户
- 前置条件：用户已进入系统主页
- 主要流程：
  1. 用户选择登录，系统显示登录页面；
  2. 用户在登录页输入用户名，密码，确认登录，系统验证用户资料；
  3. 系统显示登录成功。

三，设计概述

在分析模型的基础上，增加实现的考虑，就得到设计模型，实现考虑主要包括：
- 使用何种架构（以架构为中心）；
- 使用何种编程语言和运行平台
- 使用何种中间件（第三方组件）
- 使用何种应用框架
- 使用何种数据库
在模型中增加上述因素的考虑，往往涉及拆分或合并一些控制类，增加一些控制类等。
确定实现的参与类后，再明确各参与类有何动态关系，并进而确定各参与类之间传送的消息。这通过画顺序图或通信图达成。
由此也就明确了各参与类的职责(用方法实现)。

四，设计模型举例

以登录系统用例为例。
- 如果决定采用 Asp.Net Core MVC框架实现，
- 使用C#编程，
- 使用框架包含的Identity(身份识别) 和EF(实体框架)组件，
- 使用Sql Server数据库存放数据，通过User表存放客户信息。
- 则登录时需要涉及的参与类包括：
从图中，可以识别出有关控制类的操作。
属性，在分析阶段就可以定出。
在交互图的基础上，可以画出设计类图。
如果对每一个用例作这样的分析设计，就得到了完整的设计模型。
设计模型可以直接转化为代码，即实现模型。

小结

分析模型是从需求模型导出的逻辑模型，未考虑实现细节
分析模型的建立主要是分析用例需要哪些分析类参与实现。分析类分为三种：界面、控制、实体。分析类之间的动态关系，是稳定的，不受变化影响的，为Robustness Diag.
设计模型在分析模型的基础上加上实现细节
获得设计模型的主要途径是在分析出设计类的基础上，画用例实现时各设计对象之间的顺序图或通信图（统称交互图Interaction Diag.），得到各设计类的操作，并将结果在类图中画出。