Transcript Document

第一章
面向对象的分析和设计
暨南大学计算机系
黄战
前言






在很多学科中，人们早就认识到模式在构造复杂系统时的重要性。
软件设计模式可以帮助开发人员描述设计片断、重要设计思想、
使用其他人的专业经验。
模式给出了抽象的探索式过程的名称和形式，以及面向对象技术
的规则和最佳实践。
明智的工程师是不会完全从头开始工作的，而是查询可以使用的
模式。
统一建模语言（UML)已经成为被用户广泛接受的描述软件设计蓝
图的语言。
UML是用来传递设计理念的可视化语言。本书的重点讲述开发者如
何真正地应用常用地UML元素而不是讲述UML的特征。
本章目标





目标和范围
OOA/D 的定义
OOA/D 的一个简单例子
UML和可视化敏捷建模
历史
目标和范围

开发OOA/D的核心技能掌握这些技能是基本
要求对于创建：




设计良好
健壮性
可维护的软件
使用面向对象技术和语言如Java
目标和范围
“拥有一把锤子未必能成为建筑师“


需要了解“对象”思想
应用统一建模语言（UML)和模式

基本原理的掌握
。分配职责给对象
。常用的UML表示法
。常见的设计模式
。框架设计和架构分析
目标和范围

UML vs. 对象思想




标准图形表示法
不是OOA/D也不是方法
没有面向对象设计UML是没有意义的
在OOA/D中应用UML
目标和范围

OOD：原则和模式

如何为对象类分配职责？

对象之间应该如何协作？

什么样的类应该做什么样的事情？

OO设计之象征：

职责驱动设计（responsibility-driven design)
模式：



某些针对设计问题的，经过反复验证的解决方案可以（和已经）被 表
示成为最佳实践的原则、启示。
已命名问题—解决方案公式，这些公式是系统化、典范的设计原则。
目标和范围



案例研究
用例

需求分析
敏捷方法到UP

使用著名的统一过程的敏捷（轻量的、灵活的）方法作为迭
代开发过程。
面向对象分析和设计

分析


强调的是对问题和需求的调查研究，而不是解决方案
设计

强调的是满足需求的概念上的解决方案（在软件方面
和硬件方面）
面向对象分析和设计


面向对象分析
 强调的是在问题领域内发现和描述对象（或概念）
 例如，在航班信息系统里包含飞机、航班、飞行员等
概念
面向对象设计
 强调的是定义软件对象以及它们如何协作以实现需求。
 例如，在航班信息系统里软件对象Plane可以有
tailNumber属性和getFightHistory方法。
面向对象分析和设计
Plane
领域概念
tailNumber
-在面向对象编程
语言中的表示
领域概念
的可视化
public class Plane
{
private String tailNumber;
public List getFlightHistory() {...}
}
UML

根据OMG规格说明



统一建模语言（UML）是描述、构造和文档化系
统制品的可视化语言。
www.omg.org
www.uml.org
UML

应用UML的方式：

UML作为草图

非正式的、不完整的图，借助可视化语言的功能，用于探讨问题或
解决方案空间的复杂部分。
UML作为蓝图


相对详细的设计图，用于：1）逆向工程，即以UML图的 方式对
现有代码进行可视化，使其易于理解。2）代码生成（前向工程）。
UML作为编程语言


用UML完成软件系统可执行规格说明。
UML

应用UML的三种透视图

概念透视图

用图来描述现实世界或关注领域中的事物
规格说明（软件）透视图


用图来描述软件的抽象物或具有规格说明和接口的构件，但是
并不约定特定实现
实现（软件）透视图


用图来描述特定技术中的软件实现（例如：Java)
OOA/D的历史









1960s到1970s－OO编程语言（例如Simula和Smalltalk)开始崭露
头角
Alan Kay – Smalltalk，“面向对象编程”，个人计算“
1982年OOD形成－Grady Booch (也是UML创立者之一),完成第一
篇论文“Object-Oriented Design”;Ivar Jacobson ( UML 创立者之
一)
1988 Object-Oriented Software Construction – Mellor
and Schlaer; “Object-Oriented Analysis”
1991 – Rumbaugh OMT 方法
1994 – UML = Booch + OMT (+ Rational later)
三剑客 = Booch + Rumbaugh + Jacobson
1997 – UML 1.0; OMG (对象管理组织)
资料







Martin Fowler – UML Distilled
Rumbaugh – The Unified Modeling Language
Reference Manual
www.uml.org
www.omg.org
www.agilemodeling.com
www.cetus-links.org
www.iturls.com
第2章 迭代、进化和敏捷
暨南大学计算机系
黄战
本章目标




动机
迭代过程
敏捷过程
统一过程
动机:迭代和进化式

瀑布生命周期



在编程之前就预先完成需求和设计步骤
软件项目的高失效率
迭代和进化式开发





及早地引入编程和测试,并重复这一循环
会在还没有详细定义所有需求的情况下假设开发开始
使用反馈来明确和改进演化中的规格说明
依赖于短时快速的开发步骤、反馈和改写来不断明确需
求和设计
软件项目的较高成功率
动机:统一过程(UP)

软件开发过程


统一过程




描述了构造、部署以及维护软件的方式
已经成为一种流行的构造面向对象系统的 迭代软件开发过程
UP实践提供了如何实施OOA/D的示范例子
UP具有灵活性,可以应用于轻量级和敏捷方法,这些方法包括其
他敏捷方法(诸如XP或Scrum)的实现
Rational统一过程

对统一过程的详细精化,并且已经被广泛采纳
迭代过程

迭代开发




UP和大多数其他现代方法中的关键实践
在这种的生命周期方法中,开发被组织成一 系列固
定的短期小项目,称为迭代
每次迭代都产生经过测试、集成并可执行的局部系
统
每次迭代都具有各自的需求分析、设计、实现和测
试活动
迭代过程

迭代和进化式(增量式)开发





迭代生命周期基于对经过多次迭代的系统进行持续扩展和精化
早期迭代过程的思想是螺旋式开发和进化式开发
每次迭代都产生可执行的但不完整的系统,它不是已经准备好可
以交付的产品
直到多次迭代(如10次或15次迭代)之后,系统才可能合格地用于
产品部署
迭代的输出不是实验性的或将丢弃的原型,迭代开发也不是构造
原型.与之相反,其输出是最终系统的产品子集
迭代项目中的变更


迭代开发抱以接受变更和改写的态度,并以此
为真正本质的驱动力—而不是企图全面和正确
地规格化、冻结需求集(瀑布模型)
UP-平衡需求和稳定性(VS反应式的特性蔓延)
迭代开发的优点






减少项目失败可能性,提高生产率、降低缺陷
率
在早期缓解高风险
早期可见的进展
早期反馈、用户参与和调整,会产生更接近涉
众真实需求的精华系统
可控复杂性
一次迭代中的经验可以被系统地用于改进开发
过程本身
一次迭代的时间定量

时间定量



时长固定
推延时间则违约
从本次迭代中除去一些任务或需求,并将其分配在将
来的迭代中
瀑布生命周期

瀑布





顺序生命周期
试图在编程之前详细定义所有或大部分需求
研究表明,在20世纪60年代到70年代,瀑布方法对于
大多数软件项目是拙劣的实践
它与高失败率、低生产率和高缺陷率具有极大关系
瀑布方法需求中45%的特性从未被使用,其早期时间
表和估计与最终实际情况可相差400%
为什么瀑布模型具有错误倾向



假设规格说明是可预知的和稳定的,并且能够
在项目开始时就正确定义
典型的软件项目在需求上会经历25%的变更
“新产品开发” 领域-软件开发是(平均而言)
变更极大且不稳定的领域
反馈和改写的必要性

在复杂、变更系统中,反馈和调整是成功的关
键要素




早期开发中的反馈
来自测试中的反馈,有助于开发者精化设计或模型
来自团队处理早期特性过程的中反馈,有助于精化时
间表和估计
来自客户和市场的反馈,有助于重新定义下一次迭代
实现特性的优先级
如何进行迭代和进化式分析和设计


看第１８－２０页的例子
一般错误认为

偏激的认为“完整”的编程前分析和设计是十分有
价值的
风险驱动和客户驱动的迭代计划



ＵＰ提倡风险驱动和客户驱动相结合的迭代计
划
早期的迭代目标

识别和降低最高风险

构造客户最关心的可视化特性
风险驱动迭代开发更明确地包含了以构架为中
心迭代开发的实践

早期迭代致力于核心架构的构造、测试和稳定

没有稳定的架构就会带来高风险
敏捷开发


敏捷开发方法
 通常应用时间定量的迭代和进化式开发
 使用自适应计划
 提倡增量交付
 并包含其他提倡（快速和灵活的响应变更）的价值
和实践
敏捷方法具备进化式精化的计划、需求和设计的短时
间定量迭代是这些方法所共有的基本实践．除此之外，
它们还倡导反映简易、轻量、沟通、自组织团队等更
多敏捷的实践和原则
敏捷方法

实践范例(Scrum)
公共项目工作室

自组织团队

ＸＰ：结队编程和测试驱动开发
ＵＰ：“不管黑猫还是白猫，抓到耗子就是好猫”的
态度

敏捷建模


建模的目的主要是为理解，而非文档
敏捷建模
 采用敏捷方法并不意味着不进行任何建模
 建模和模型的目的主要用于理解和沟通
 不要对所有或大多数软件设计建模或应用ＵＭＬ
 尽可能使用最简单的工具
 不要单独建模，而是结队（或三个人）在白板上建模
 并行地创建建模
 “足够好”的简单表示法
 知道所有模型都可能不准确的
 开发者应该进行ＯＯ设计建模
敏捷ＵＰ

可以采纳和应用可适应性和轻量级的精神






推荐使用ＵＰ活动和制品的简集
实现前的需求和设计是不完整的
以敏捷建模实践应用ＵＭＬ
对于整个项目不应有详细的计划
阶段计划－评估项目结束日期和主要里程碑
迭代计划－详细计划是由一次次迭代的调整而完成的
ＵＰ的阶段

四个主要阶段
初始


大体上的构想、业务案例、范围和模糊评估
细化


已精化的构想、 核心架构的迭代实现、 高风险的解决、 确
定大多数需求和范围以及进行更为实际的评估
构造


对遗留下来的风险较低和比较简单的元素进行迭代实现，准
备部署
移交


进行beta测试
ＵＰ科目

科目－在一个主题域中的一组活动，例如需求
分析中的活动




业务建模
需求
设计
ＵＰ实现表示编程和构建系统，而不是部署
ＵＰ开发案例

为项目选择实践和ＵＰ制品可以编写为简短文
档，这称为开发案例
第三章 案例研究
暨南大学计算机系
黄战
核心应用逻辑层



逻辑核心层的ＯＯ设计对各种技术来说是相似
的
在应用逻辑层语境中学习到的基本ＯＯ设计技
巧适用于所有其他层或够件
当新框架或技术出现时，其他层的设计方法和
模式呈现出快速变化的趋势
案例学习策略



迭代开发的策略
多次迭代，第一次迭代用于一些核心功能
例子


ＰＯＳ
Ｍonopoly 游戏系统