rup与传统软件工程之设计分析

三.设计分析
传统软件工程模式：
在传统软件工程中，分析阶段又叫总体设计阶段。
目的：选取最佳方案，将系统的概念性描述转化为结构化的模块层次(进一步的具体化)。

与需求阶段的定义做什么相反，现在定义如何做。分析阶段主要1.划分组成系统的物理元素(程序，文件，数据库，文档等)。但并不考虑这些

元素的细节。2.划分系统的模块，定义这些模块的相互关系。3.复审。

如何选取最佳方案：
以数据流图为出发点，定义系统各个处理模块的边界(部署)，根据这些边界来设想各种实现方案。
根据当前情况(包括技术，资金，时间等)来选择数个合适的方案。
开发方和用户方根据上述方案的利弊共同商讨出一个最佳的方案。

划分系统的物理元素：
程序(即下述系统的模块)；数据库(如涉及到则需进行数据库设计)；制定测试计划(从现在开始，测试将持续到开发结束)；书写文档(系统说明
，测试计划，详细的实现计划，数据库设计结果)。

系统模块的设计：
功能的分解，将需求阶段得到的数据流图作进一步的分解，直到每个处理功能都明显易懂为止。
面向数据流图的模块建立，根据数据流图定义出系统的模块结构(层次图)，以及每个模块的算法(HIPO图，包括输入，输出，处理)。

层次图是描述模块间调用和被调用关系的图。与层次方框图不同，层次方框图是用来描述实体间的组成关系的图。

RUP模式：
目的：建立系统的总体架构，定义系统元素的雏形和它们之间的关系。
产生设计模型和用户体验模型。

分析过程：
1.定义初始架构(包括部署模型，初步的设计模型，建立分析机制)。
目的：定义系统的总体架构，包括建立部署模型，建立结构化设计模型，建立分析机制。

部署模型：分析当前情况，选择已有的架构或自行设计(比如j2ee的三层结构等)，将架构的各个处理化为节点即为部署模型。

结构化设计模型：找到系统的关键抽象元素和它们之间的关系(功能上的抽象类，并不包括边界与控制等中间层)。这是一个整体分析的步骤，

在行为分析阶段还要针对每个用例找到它们的抽象和关系，还要分析它们的行为。并且两处的元素不能出现矛盾的地方。
定义设计包，将设计元素通过设计包分为若干个部分。

建立分析机制：即建立用于支撑系统运行的各种机制(包括安全系统，进程通信，管理等)。

2.分析行为(包括用户体验模型和分析上述建立的结构化的设计模型)
目的：建立用户体验模型，分析用例。

分析用例：
主要定义用例实现。
用构造型协作来分析每个用例的实现。协作包括结构部分(分析类图)，行为部分(交互图)。该步骤与设计层相应步骤对应。
对于每个用例，设计出边界类(用于表达用户与系统的交互)，控制类(封装用例的行为，类似于command模式或代理模式的中间层)，功能类/实

体类(用于具体描述功能的实现，即上述的系统的关键抽象类)

用户体验模型：用户体验模型表达了系统的界面元素以及用户与系统交互的抽象表示。它包括屏幕模型，用例使用情节，屏幕跳转图。

用例使用情节用协作来表示其屏幕上的实现，它包括屏幕类模型及其关系来表示其结构，以及屏幕流的交互图来表示其行为，与前述的用例协

作实现有明显区别。此处是基于屏幕界面的实现。

屏幕跳转图从整体上来定义整个系统的屏幕跳转关系。它是综合单个用例参与屏幕的结果，用于协调用例使用情节，消除冗余。

总结一下：
1.用例模型中的用例被设计模型中的用例实现(分析类协作)以及用户体验模型中的用例使用情节(屏幕类协作)所实现。

2.用例模型中的用户与用例的交互将映射到设计模型中的边界类以及用户体验模型中的屏幕类。

3.用例模型中用户及用例描述中的用户请求将映射到设计模型中边界类的职责以及用户体验模型中屏幕类所定义的活动中。

4.设计模型和用户体验模型亦具有同样的映射关系。

5.分析阶段进一步将需求分析阶段的用例模型具体化。

即：用例模型------->设计模型

6.而下一步的设计阶段将会对分析阶段的设计模型具体化。

即：初始架构------->精化架构 
    分析行为------->细化设计