工件:
|
![]() |
描述用例实现的一种对象模型,也充当工件:设计模型的抽象。分析模型包含用例分析的结果,工件:分析类的实例。 | |
其它关系: |
包含
| |
---|---|---|
角色: | 软件设计人员 | |
可选/发生: | 可选。精化和构造阶段。 | |
模板和报告: |
|
|
示例: | ||
UML 表示: | 模型,构造成 <<分析模型>>。 | |
更多信息: | ||
活动的输入: | 活动的输出: |
分析模型包含分析类和任何关联的工件。分析模型可能是临时工件(这种情况下它发展为设计模型),或可能在项目的部分或整个生命期内继续存在,并可能超过该期限,作为系统的概念性概述。
属性名 |
简短描述 |
UML 表示 |
---|---|---|
简介 | 文本描述,作为模型的简介。 | “短文本”类型的标记值。 |
分析包 | 模型中的包,表示一个层次结构。 | 通过关联“代表”拥有,或通过聚集“拥有”递归拥有。 |
类 | 模型中的类,由包所拥有。 | 通过聚集“拥有”递归拥有。 |
关系 | 模型中的关系,由包所拥有。 | -" - |
用例实现 | 模型中的用例实现,由包所拥有。 | -" - |
图 | 模型中的图,由包所拥有。 | -" - |
分析模型在精化阶段创建,并在构造阶段更新,此时更新模型的结构。
软件设计人员负责分析模型的完整性,确保:
通常,“分析类”将直接演化成设计模型中的元素:有些类变成设计类,其它类变成设计子系统。分析的目标是确定从所需的行为到系统中建模元素的初步映射。设计的目标是将该初步(并有些理想化)映射转换成可实施的一组模型元素。结果,从分析到设计的转移过程中,存在着细节和精度的优化。因此,“分析类”在设计活动中固化之前,它们常常是相当不固定的、可变的,并大幅发展。
决定是否需要一个单独的分析模型时,需要考虑的要点:
在有些公司中,系统生存期为数十年,或系统有许多变体,这时单独的分析模型已证明是很有用的。
Rational Unified Process
|