Page 1 ?
UML及软件建模
主讲人, 李 唯
clx7000@163.com
Page 2 ?
第十三章 在建模过程中运用 UML
Page 3 ?
3,软件开发过程
因为我们的软件建模就是在软件开发的过程中完成的，
这一节将讲解软件开发过程，以及如何软件开发的过程中完
成软件建模。
这一节还要谈论为什么要使用 UML以及什么时候使用
UML才是最好的。
Page 4 ?
? 过程就是针对某一给定目标的一系列运作步骤,[IEEE-
STD-610] 是在过程环境下的一系列有序活动。所谓活动（
Activity）就是过程对象一次状态改变，也叫过程步
(Step)。
? 活动起始态和活动结果态表征了活动的进行。可以说一切
事物的发生、发展、消亡都离不开过程，都寓于过程之中
。
3.1、过程
Page 5 ?
3.1.1,过程的一般定义
Page 6 ?
煮蛋的启示
Page 7 ?
? 软件过程是将用户的需求转化成有效的软件解决方案的一
系列活动。
? 许多软件组织无法正确定义和控制这一过程，但这恰恰是
组织改进的关键。
? 过程的好坏由结果状态与预期状态的差异决定，也就是目
标成果质量的好坏。
? 规程（ Procedure）是人们对客观事物运动规律的理解和
掌握，是规范了的过程。
? 软件过程是为了获得高质量软件产品所需要完成的一系列
任务的框架，它规定了完成各项任务的工作步骤。
? 软件过程必须科学、合理，才能开发出高质量 的软件产品。
3.2、软件过程
Page 8 ?
Page 9 ?
? 软件过程又称软件生存周期过程，是软件生存周期内为达
到一定目标而必须实施的一系列相关过程的集合。
早期：
立项、需求分析、设计、编码、
测试、交付、维护、退役
Page 10 ?
? 软件过程是人类制作产物的一系列活动，而过去的软件工
程师把产物和人分离，只研究产品过程及其质量，假定人力
、物力资源是无限大、无限好。现在认识到面对实际资源实
施软件过程学，求相对最佳质量才是有效的。
Page 11 ?
现在的软件生命周期过程包括：
早期：
立项、需求分析、设计、编码、
测试、交付、维护、退役
又加入了：
管理各种活动、质量保证
环境基础设施配置、文档管理等。
Page 12 ?
3.3,软件过程模型
? 瀑布模型（ Waterfall）
? 原型模型（ Prototype）
? 增量模型（ Incremental）
? 螺旋模型（ Spiral）
? 迭代模型（ Iterative）
Page 13 ?
（ 1）瀑布模型 (线性顺序模型 )
瀑布式模型包含以下活动：
? 软件需求分析
? 设计
? 代码生成
? 测试
? 维护
Page 14 ?
（ 1-1）瀑布模型 — 传统的瀑布模型
需求分析
验证
规格说明
验证
设计
验证
编码
测试
综合测试
维护
定义时期
开发时期
维护时期
Page 15 ?
传统的瀑布模型存在的问题
传统的瀑布模型过于理想化了，事实上，人在工作过程
中不可能不犯错误。
? 在设计阶段可能发生规格说明文档中的错误。
? 而设计上的缺陷或错误可能在实现过程中显现出来。
? 在综合测试阶段将发现需求分析、设计或编码阶段的许多
错误。
Page 16 ?
? Tom Gilb：
“假如你不积极地解决你项目中存在的风险，它们就会积
极地解决掉你”
? 瀑布方法会掩饰项目中真正的风险，当你太晚发现它们时
已无济于事。
Page 17 ?
（ 1－ 2）瀑布模型 — 实际的瀑布模型
需求分析
验证
规格说明
验证
设计
验证
编码
测试
综合测试
维护
变化的需求
验证
Page 18 ?
瀑布模型的特点
? 文档驱动的模型
? 阶段间具有顺序性和依赖性
? 推迟实现的观点
? 质量保证的观点
Page 19 ?
瀑布模型的问题
? 实际项目很少按照该模型给出的顺序进行
? 用户常常难以清楚地给出所有需求
? 用户必须有耐心
? 开发者常常被不必要地耽搁
Page 20 ?
（ 2）原型模型
? 快速建立起来的可以在计算机上运行的程序，他所能完成
的功能往往是最终产品能完成的功能的一个子集。
Page 21 ?
原型模型的适用情况
? 用户定义了一组一般性目标，但不能标识出详细的输入、
处理及输出需求；
? 开发者可能不能确定算法的有效性、操作系统的适应性或
人机交互的形式；
? ……
原型模型可能是最好的选择
Page 22 ?
? 原型模型从需求收集开始。 开发者和用户在一起定义软
件的总体目标，标识出已知的需求，并规划出进一步定义的
区域。
? 然后是“快速设计”，快速设计集中于软件那些对用户可
见
部分的表示。“快速设计”导致原型的建造。
? 原型由用户评估，并进一步细化待开发软件的需求，逐步
调整原型使其满足客户的要求。同时开发者对将要做的事情
有更好的理解,这个过程是 迭代 的。
Page 23 ?
原型模型
快速原型
验证
规格说明
验证
设计
验证
编码
测试
综合测试
维护
变化的需求
验证
维护过程
开发过程
Page 24 ?
原型模型的存在的问题
? 用户似乎看到的是软件的工作版本，其实 ……
? 开发者常常需要实现上的折衷，以使原型能够尽快工作
Page 25 ?
（ 3）增量模型
? 融合了瀑布模型的基本成分和原型的迭代特征。采用随着
日程时间的进展而交错的线性序列。
Page 26 ?
（ 3-1）增量模型
需求分析
验证
规格说明
验证
设计
验证
维护
针对每个构件完成
详细设计、编码和
集成，经测试后交
付给用户
Page 27 ?
（ 3－ 2）增量模型
分析
分析
分析
分析
设计
设计
设计
设计
编码
编码
编码
编码
测试
测试
测试
测试
增量 1
增量 2
增量 3
增量 4
Page 28 ?
? 增量模型融合了瀑布模型的基本成分和原型的迭代特性。
? 例如，使用增量模型开发字处理软件
– 基本的文件管理、编辑和文档生成功能。
– 更完善的编辑和文档生成能力。
– 实现拼写和文法检查功能。
– 完成高级的页面布局功能。
? 第一个增量往往是核心产品
? 每一个增量均发布一个可操作产品
? 早期的增量是最终产品的“可拆卸”版本
Page 29 ?
（ 4）螺旋模型
基本思想
? 使用原型及其他方法来尽量降低风险。
Page 30 ?
(4-1)螺旋模型 -简化
需求分析
验证
规格说明
验证
设计
验证
编码
测试
综合测试
维护
变化的需求
验证
风险分析 风险分析
风险分析
风险分析
风险分析
风险分析
Page 31 ?
(4-2)螺旋模型完整
Page 32 ?
? 优点
– 对可选方案和约束条件的强调有利于已有软件的重用
，也有助于把软件质量作为软件开发的一个重要目标；
– 减少了过多测试或测试不足；
– 维护和开发之间并没有本质区别。
? 特点
– 风险驱动的
? 主要适用于内部开发的大规模软件项目
Page 33 ?
（ 5）迭代模型
? 建立在 Barry Boehm 的螺旋模型基础上的。
Page 34 ?
(5-1)迭代模型
Page 35 ?
Planning
Requirements
Analysis & Design
Implementation
Deployment
Test
Evaluation
Management
Environment
Each iteration results in an
executable release.
(5-2)迭代模型
Page 36 ?
特点
? 这种方法可以在生命周期早期强制性的确定项目中存在的
风险。
? 这种方法是一个连续地发现、创造和实现的过程。
? 在每个迭代过程中，促使开发小组以一种循环的、可预测
的方式驱动项目制品的生产和制作。
Page 37 ?
提供解决方案：
? 在生命周期的早期，这种方法可以及时地发现一些严重的
需求理解错误，此时还可能修正这些错误。
? 允许并鼓励用户反馈信息，以明确系统的真实需求。
? 这种方法使开发小组重视项目中最关键的问题，而屏蔽掉
那些使他们远离项目真实风险的问题。
? 不断地迭代测试能够给出项目状况的客观评价。
Page 38 ?
3.4、软件的价值
? 动力源泉，世界不可或缺的一部分
Page 39 ?
3.5、软件的遇到的问题
? 规模、复杂性、分布和重要性不断扩张
? 生产和维护越来越难
? 熟悉的软件开发方法受到限制
Page 40 ?
3.5.1、软件开发问题的症状
? 对于最终用户的需要理解得不够精确
? 对需求的改变束手无策
? 程序块不兼容
? 软件不易维护或不易扩展
? 对项目严重缺陷的发现较晚
? 软件质量低劣
? 软件性能令人无法接受
? 开发组的人员按各自的方式进行开发，如果有人改变可部
分软件，将很难进行重组
? 一个不可靠的构造和发布过程
Page 41 ?
3.5.2、失败原因
? 特别的需求管理
? 模糊和不精确的交流
? 脆弱的构架
? 过度复杂
? 未检测出需求、设计和实现之间的不一致
? 测试的不足
? 对于项目状况的评估过于主观
? 未解决存在的风险
? 无法控制变化的产生和传播
? 自动控制不足
Page 42 ?
3.5.3、跟踪现象寻找原因
Needs not met
Requirements churn
Modules don’t fit
Hard to maintain
Late discovery
Poor quality
Poor performance
Colliding developers
Build-and-release
Insufficient requirements
Ambiguous communications
Brittle architectures
Overwhelming complexity
Undetected inconsistencies
Poor testing
Subjective assessment
Waterfall development
Uncontrolled change
Insufficient automation
Symptoms Root Causes Best Practices
s i i
ed i
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
Model Visually (UML)
Continuously Verify Quality
odules don’ fit
Page 43 ?
3.6、最佳软件开发实践 Best
Practices
? 迭代地开发软件 Develop Iteratively
? 管理需求 Manage Requirements
? 应用基于构件的构架 Use Component Architectures
? 为软件建立可视化的模型 Model Visually (UML)
? 不断地验证软件质量 Continuously Verify Quality
? 控制软件的变更 Manage Change
Page 44 ?
? 现在软件产业界普遍认为，开发复杂软件项目必须采用基
于 UML的、以构架为中心、用例驱动与风险驱动相结合
的迭代式增量开发过程，他是世界公认的开发复杂软件项
目的最好过程，已经成为软件界的“圣经”。这一开发过
程目前已经稳定、成熟。
? 这就是,RUP
UML及软件建模
主讲人, 李 唯
clx7000@163.com
Page 2 ?
第十三章 在建模过程中运用 UML
Page 3 ?
3,软件开发过程
因为我们的软件建模就是在软件开发的过程中完成的，
这一节将讲解软件开发过程，以及如何软件开发的过程中完
成软件建模。
这一节还要谈论为什么要使用 UML以及什么时候使用
UML才是最好的。
Page 4 ?
? 过程就是针对某一给定目标的一系列运作步骤,[IEEE-
STD-610] 是在过程环境下的一系列有序活动。所谓活动（
Activity）就是过程对象一次状态改变，也叫过程步
(Step)。
? 活动起始态和活动结果态表征了活动的进行。可以说一切
事物的发生、发展、消亡都离不开过程，都寓于过程之中
。
3.1、过程
Page 5 ?
3.1.1,过程的一般定义
Page 6 ?
煮蛋的启示
Page 7 ?
? 软件过程是将用户的需求转化成有效的软件解决方案的一
系列活动。
? 许多软件组织无法正确定义和控制这一过程，但这恰恰是
组织改进的关键。
? 过程的好坏由结果状态与预期状态的差异决定，也就是目
标成果质量的好坏。
? 规程（ Procedure）是人们对客观事物运动规律的理解和
掌握，是规范了的过程。
? 软件过程是为了获得高质量软件产品所需要完成的一系列
任务的框架，它规定了完成各项任务的工作步骤。
? 软件过程必须科学、合理，才能开发出高质量 的软件产品。
3.2、软件过程
Page 8 ?
Page 9 ?
? 软件过程又称软件生存周期过程，是软件生存周期内为达
到一定目标而必须实施的一系列相关过程的集合。
早期：
立项、需求分析、设计、编码、
测试、交付、维护、退役
Page 10 ?
? 软件过程是人类制作产物的一系列活动，而过去的软件工
程师把产物和人分离，只研究产品过程及其质量，假定人力
、物力资源是无限大、无限好。现在认识到面对实际资源实
施软件过程学，求相对最佳质量才是有效的。
Page 11 ?
现在的软件生命周期过程包括：
早期：
立项、需求分析、设计、编码、
测试、交付、维护、退役
又加入了：
管理各种活动、质量保证
环境基础设施配置、文档管理等。
Page 12 ?
3.3,软件过程模型
? 瀑布模型（ Waterfall）
? 原型模型（ Prototype）
? 增量模型（ Incremental）
? 螺旋模型（ Spiral）
? 迭代模型（ Iterative）
Page 13 ?
（ 1）瀑布模型 (线性顺序模型 )
瀑布式模型包含以下活动：
? 软件需求分析
? 设计
? 代码生成
? 测试
? 维护
Page 14 ?
（ 1-1）瀑布模型 — 传统的瀑布模型
需求分析
验证
规格说明
验证
设计
验证
编码
测试
综合测试
维护
定义时期
开发时期
维护时期
Page 15 ?
传统的瀑布模型存在的问题
传统的瀑布模型过于理想化了，事实上，人在工作过程
中不可能不犯错误。
? 在设计阶段可能发生规格说明文档中的错误。
? 而设计上的缺陷或错误可能在实现过程中显现出来。
? 在综合测试阶段将发现需求分析、设计或编码阶段的许多
错误。
Page 16 ?
? Tom Gilb：
“假如你不积极地解决你项目中存在的风险，它们就会积
极地解决掉你”
? 瀑布方法会掩饰项目中真正的风险，当你太晚发现它们时
已无济于事。
Page 17 ?
（ 1－ 2）瀑布模型 — 实际的瀑布模型
需求分析
验证
规格说明
验证
设计
验证
编码
测试
综合测试
维护
变化的需求
验证
Page 18 ?
瀑布模型的特点
? 文档驱动的模型
? 阶段间具有顺序性和依赖性
? 推迟实现的观点
? 质量保证的观点
Page 19 ?
瀑布模型的问题
? 实际项目很少按照该模型给出的顺序进行
? 用户常常难以清楚地给出所有需求
? 用户必须有耐心
? 开发者常常被不必要地耽搁
Page 20 ?
（ 2）原型模型
? 快速建立起来的可以在计算机上运行的程序，他所能完成
的功能往往是最终产品能完成的功能的一个子集。
Page 21 ?
原型模型的适用情况
? 用户定义了一组一般性目标，但不能标识出详细的输入、
处理及输出需求；
? 开发者可能不能确定算法的有效性、操作系统的适应性或
人机交互的形式；
? ……
原型模型可能是最好的选择
Page 22 ?
? 原型模型从需求收集开始。 开发者和用户在一起定义软
件的总体目标，标识出已知的需求，并规划出进一步定义的
区域。
? 然后是“快速设计”，快速设计集中于软件那些对用户可
见
部分的表示。“快速设计”导致原型的建造。
? 原型由用户评估，并进一步细化待开发软件的需求，逐步
调整原型使其满足客户的要求。同时开发者对将要做的事情
有更好的理解,这个过程是 迭代 的。
Page 23 ?
原型模型
快速原型
验证
规格说明
验证
设计
验证
编码
测试
综合测试
维护
变化的需求
验证
维护过程
开发过程
Page 24 ?
原型模型的存在的问题
? 用户似乎看到的是软件的工作版本，其实 ……
? 开发者常常需要实现上的折衷，以使原型能够尽快工作
Page 25 ?
（ 3）增量模型
? 融合了瀑布模型的基本成分和原型的迭代特征。采用随着
日程时间的进展而交错的线性序列。
Page 26 ?
（ 3-1）增量模型
需求分析
验证
规格说明
验证
设计
验证
维护
针对每个构件完成
详细设计、编码和
集成，经测试后交
付给用户
Page 27 ?
（ 3－ 2）增量模型
分析
分析
分析
分析
设计
设计
设计
设计
编码
编码
编码
编码
测试
测试
测试
测试
增量 1
增量 2
增量 3
增量 4
Page 28 ?
? 增量模型融合了瀑布模型的基本成分和原型的迭代特性。
? 例如，使用增量模型开发字处理软件
– 基本的文件管理、编辑和文档生成功能。
– 更完善的编辑和文档生成能力。
– 实现拼写和文法检查功能。
– 完成高级的页面布局功能。
? 第一个增量往往是核心产品
? 每一个增量均发布一个可操作产品
? 早期的增量是最终产品的“可拆卸”版本
Page 29 ?
（ 4）螺旋模型
基本思想
? 使用原型及其他方法来尽量降低风险。
Page 30 ?
(4-1)螺旋模型 -简化
需求分析
验证
规格说明
验证
设计
验证
编码
测试
综合测试
维护
变化的需求
验证
风险分析 风险分析
风险分析
风险分析
风险分析
风险分析
Page 31 ?
(4-2)螺旋模型完整
Page 32 ?
? 优点
– 对可选方案和约束条件的强调有利于已有软件的重用
，也有助于把软件质量作为软件开发的一个重要目标；
– 减少了过多测试或测试不足；
– 维护和开发之间并没有本质区别。
? 特点
– 风险驱动的
? 主要适用于内部开发的大规模软件项目
Page 33 ?
（ 5）迭代模型
? 建立在 Barry Boehm 的螺旋模型基础上的。
Page 34 ?
(5-1)迭代模型
Page 35 ?
Planning
Requirements
Analysis & Design
Implementation
Deployment
Test
Evaluation
Management
Environment
Each iteration results in an
executable release.
(5-2)迭代模型
Page 36 ?
特点
? 这种方法可以在生命周期早期强制性的确定项目中存在的
风险。
? 这种方法是一个连续地发现、创造和实现的过程。
? 在每个迭代过程中，促使开发小组以一种循环的、可预测
的方式驱动项目制品的生产和制作。
Page 37 ?
提供解决方案：
? 在生命周期的早期，这种方法可以及时地发现一些严重的
需求理解错误，此时还可能修正这些错误。
? 允许并鼓励用户反馈信息，以明确系统的真实需求。
? 这种方法使开发小组重视项目中最关键的问题，而屏蔽掉
那些使他们远离项目真实风险的问题。
? 不断地迭代测试能够给出项目状况的客观评价。
Page 38 ?
3.4、软件的价值
? 动力源泉，世界不可或缺的一部分
Page 39 ?
3.5、软件的遇到的问题
? 规模、复杂性、分布和重要性不断扩张
? 生产和维护越来越难
? 熟悉的软件开发方法受到限制
Page 40 ?
3.5.1、软件开发问题的症状
? 对于最终用户的需要理解得不够精确
? 对需求的改变束手无策
? 程序块不兼容
? 软件不易维护或不易扩展
? 对项目严重缺陷的发现较晚
? 软件质量低劣
? 软件性能令人无法接受
? 开发组的人员按各自的方式进行开发，如果有人改变可部
分软件，将很难进行重组
? 一个不可靠的构造和发布过程
Page 41 ?
3.5.2、失败原因
? 特别的需求管理
? 模糊和不精确的交流
? 脆弱的构架
? 过度复杂
? 未检测出需求、设计和实现之间的不一致
? 测试的不足
? 对于项目状况的评估过于主观
? 未解决存在的风险
? 无法控制变化的产生和传播
? 自动控制不足
Page 42 ?
3.5.3、跟踪现象寻找原因
Needs not met
Requirements churn
Modules don’t fit
Hard to maintain
Late discovery
Poor quality
Poor performance
Colliding developers
Build-and-release
Insufficient requirements
Ambiguous communications
Brittle architectures
Overwhelming complexity
Undetected inconsistencies
Poor testing
Subjective assessment
Waterfall development
Uncontrolled change
Insufficient automation
Symptoms Root Causes Best Practices
s i i
ed i
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
Model Visually (UML)
Continuously Verify Quality
odules don’ fit
Page 43 ?
3.6、最佳软件开发实践 Best
Practices
? 迭代地开发软件 Develop Iteratively
? 管理需求 Manage Requirements
? 应用基于构件的构架 Use Component Architectures
? 为软件建立可视化的模型 Model Visually (UML)
? 不断地验证软件质量 Continuously Verify Quality
? 控制软件的变更 Manage Change
Page 44 ?
? 现在软件产业界普遍认为，开发复杂软件项目必须采用基
于 UML的、以构架为中心、用例驱动与风险驱动相结合
的迭代式增量开发过程，他是世界公认的开发复杂软件项
目的最好过程，已经成为软件界的“圣经”。这一开发过
程目前已经稳定、成熟。
? 这就是,RUP
