1. 从需求阶段到设计阶段的整个流程;
2. 各个阶段的工作与产出物;
1. 学习RUP流程;
2. 找案例实践整个流程;
3. 熟悉RSA的使用,Eclipse的使用;
4. 学习业务建模
上图描述了“干系人需要、特性、软件需求、设计规范、测试过程、文档规划”之间的关系;
识别stakeholder,获取干系人请求,特性(描述系统如何实现干系人请求)
产出物,stakeholder, 获取干系人请求,特性;
1.获取用例,对用例进行分析;
2.获取非功能性需求,进行分析;
3.设计约束;
产出物,用例分析模型;非功能性需求;设计约束;
1. 建立用例实现与用例的跟踪关系;
2. 建立体系结构,以分层或分子系统的方式;
3. 识别分析机制;
4. 设计用例的实现;
5. 将识别的类,进行组织并放到相应的layer层中;
产出物,用例实现,用例实现与用例的跟踪关系,子系统或层,分析机制;
1. 建立用例与用例实现的跟踪关系;
2. 根据系统分析阶段的用例实现,进行系统设计阶段的用例实现设计;
产出物,用例与用例实现的跟踪关系,用例实现,可选(组件视图或模型,部署视图或模型);
用例模型的组织形式如下图所示,
Overviews中是这个用例视图的概览信息。
User-Case Building Blocks中,可以划分为多个function area,每个function area代表一个功能域,里面可承载多个用例,
Versatile Actors中,包含一些公用的actor;
分析阶段与设计阶段的元素组织方式相同,不同处,分析阶段是逻辑上的实现方式,设计阶段,考虑了具体实现技术;
包含《layer》层,分析机制Architecture Mechanisms,用例实现;
视图可以使用模型表示,用例模型,分析模型,设计模型,部署模型,组件模型,或是使用包package表示;系统中必须的模型有,用例模型、分析模型、设计模型,而组件视图和部署视图可根据需要放到需要的位置;
RUP描述用例的风格
l 谁(人/事物)使用系统?
l 谁(人/事物)从系统获取信息?
l 谁(人/事物)为系统提供信息?
l 系统在公司的哪里被使用?
l 谁(人/事物)支持和维护系统?
l 那些其他系统使用本系统?
l 包含关系, 基本用例包括扩展用例, 一条基本流程(是基本用例必须的流程);
l 扩展关系, 基本用例有扩展点, 在符合某条件时, 执行扩展用例(不是基本用例必须的流程)
l 继承关系