描述用例实现的一种对象模型,也充当工件:设计模型的抽象。分析模型包含用例分析的结果,工件:分析类的实例。
其它关系:  包含
角色: 软件设计人员 
可选/发生: 可选。精化和构造阶段。
模板和报告:
     
示例:
     
UML 表示: 模型,构造成 <<分析模型>>。 
更多信息:  
活动的输入:   活动的输出:  

用途 到页首

分析模型包含分析类和任何关联的工件。分析模型可能是临时工件(这种情况下它发展为设计模型),或可能在项目的部分或整个生命期内继续存在,并可能超过该期限,作为系统的概念性概述。

属性 到页首

属性名

简短描述

UML 表示

简介 文本描述,作为模型的简介。  “短文本”类型的标记值。 
分析包 模型中的包,表示一个层次结构。  通过关联“代表”拥有,或通过聚集“拥有”递归拥有。 
模型中的类,由包所拥有。  通过聚集“拥有”递归拥有。 
关系 模型中的关系,由包所拥有。  -" - 
用例实现 模型中的用例实现,由包所拥有。  -" - 
模型中的图,由包所拥有。  -" - 

计时 到页首

分析模型在精化阶段创建,并在构造阶段更新,此时更新模型的结构。

职责 到页首

软件设计人员负责分析模型的完整性,确保:

  • 维护其当前状态,反映设计的抽象概述。

定制 到页首

通常,“分析类”将直接演化成设计模型中的元素:有些类变成设计类,其它类变成设计子系统。分析的目标是确定从所需的行为到系统中建模元素的初步映射。设计的目标是将该初步(并有些理想化)映射转换成可实施的一组模型元素。结果,从分析到设计的转移过程中,存在着细节和精度的优化。因此,“分析类”在设计活动中固化之前,它们常常是相当不固定的、可变的,并大幅发展。

决定是否需要一个单独的分析模型时,需要考虑的要点:

  • 当必须为具有单独设计体系结构的多个目标环境设计系统时,单独的分析模型会很有用。该分析模型是设计模型的抽象或泛化。为了概述系统的功能,它忽略了大部分设计细节。
  • 设计非常复杂,这样就需要一个简化的、抽象的“设计”来向新团队成员引见该设计。重申,一个明确的体系结构可以起到相同的作用。
  • 所需要的额外工作是确保分析和设计模型保持一致,该工作必须与了解一个系统所带来的益处相平衡,该系统仅代表最重要的系统工作方式细节。维护分析模型和设计模型之间的高度一致性的成本非常高。一个更实际的方法可能是仅使用设计中最重要的领域类和关键抽象来维护设计模型。当设计模型的复杂度增加时,维护成本也增加。
  • 一旦不再维护分析模型,它会快速贬值。在某一时刻,如果不再维护它,它将不再有用,因为它不会再准确反映系统的当前设计。决定不再维护分析模型可能是正确的(它可能已起到了作用),但应谨慎做出这一决定。

在有些公司中,系统生存期为数十年,或系统有许多变体,这时单独的分析模型已证明是很有用的。



Rational Unified Process   2003.06.15