工作产品 (工件):分析模型
该工作产品定义了一种描述用例实现的对象模型,并充当设计模型的抽象。
用途

分析模型包含分析类和任何关联的工作产品。分析模型可能是临时工作产品(这种情况下它发展为设计模型),或可能在项目的部分或整个过程内都存在,并可能在该项目结束后仍然存在,作为系统的概念性概述。

关系
角色负责人: 修改者:
主要描述
“分析模型”定义了一种描述用例实现的对象模型,它充当工作产品:设计模型的抽象形式。“分析模型”包含用例分析的结果和工作产品:分析类的实例。
属性
可选
已计划Yes
图示
示例
定制
说明选项

UML 说明:模型,构造型为 <<analysis model>>。 

分析模型可能有以下属性

  • 简介:文本描述,作为模型的简要介绍。 
  • 分析包: 模型中的包,表示层次结构。 
  • 类:模型中的类,由包所拥有。  
  • 关系:模型中的关系,由包所拥有。 
  • 用例实现:模型中的用例实现,由包所拥有。
  • 图:模型中的图,由包所拥有。 

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

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

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

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



更多信息
概念