1、软件工程概述软件工程概述第1页，共83页。课程内容l软件工程概述软件工程概述 SEl面向对象软件工程面向对象软件工程 OOSEl 面向对象分析与设计面向对象分析与设计 UMLl面向对象程序设计面向对象程序设计 Cl（选择）设计模式初步：（选择）设计模式初步：Design Patterns l（选择）（选择）SOA：Service Oriented Architecture l（选择）（选择）AOP：Aspect-Oriented Software Development l 项目设计实践：项目设计实践：Web Application Development using UMLl Web2.0l
2、 PM第2页，共83页。Contents软件危机软件危机(1)软件危机软件危机(1.2)软件工程软件工程(2)软件生命周期软件生命周期(3)软件过程软件过程(4)软件工程的目标软件工程的目标第3页，共83页。Contents1 软件危机软件危机 第4页，共83页。第5页，共83页。第6页，共83页。第7页，共83页。第8页，共83页。Contents软件危机软件危机(1.2)软件工程软件工程(1.2)第9页，共83页。第10页，共83页。第11页，共83页。第12页，共83页。第13页，共83页。第14页，共83页。第15页，共83页。第16页，共83页。第17页，共83页。第18页，共83页
3、。第19页，共83页。v 面向对象分析面向对象分析OOA，面向对象设计，面向对象设计OOD，面向对象，面向对象实现实现OOP，面向对象测试，面向对象测试OOT，面向对象维护，面向对象维护OOMv 面向对象的软件项目管理面向对象的软件项目管理第20页，共83页。Contents软件软件(1.1)软件危机软件危机(1.2)软件工程软件工程(1.2)软件生命周期软件生命周期(1.3)软件开发模型软件开发模型(1.4)软件工程的目标软件工程的目标第21页，共83页。第22页，共83页。Contents软件软件(1.1)软件危机软件危机(1.2)软件工程软件工程(1.2)软件生命周期软件生命周期(1.3
4、)软件过程软件过程(1.4)软件工程的目标软件工程的目标第23页，共83页。第24页，共83页。第25页，共83页。需求定义需求定义系统与软件设计系统与软件设计集成与系统测试集成与系统测试实现与单元测试实现与单元测试运行与维护运行与维护n各项活动按自上而下，相互衔接的固定次序，如同瀑各项活动按自上而下，相互衔接的固定次序，如同瀑布逐级下落。每项活动均处于一个质量环（输入布逐级下落。每项活动均处于一个质量环（输入-处理处理-输出输出-评审）中。评审）中。第26页，共83页。第27页，共83页。第28页，共83页。v确定要开发软件系统的第29页，共83页。第30页，共83页。第31页，共83页。第
5、32页，共83页。第33页，共83页。第34页，共83页。第35页，共83页。v 过程基本不可迭代过程基本不可迭代v 需求在开始的不确定性需求在开始的不确定性v 错误到最后才能发现错误到最后才能发现v 开发进程呈现塞阻状态开发进程呈现塞阻状态第36页，共83页。软件生存期循环第37页，共83页。v快速原型模型（快速原型模型（Rapid Prototype Model）的）的主要做法主要做法是：首先建立一个能够反映用户主要需求的原型，让用户实是：首先建立一个能够反映用户主要需求的原型，让用户实际看一看未来系统的概貌，以便判断哪些功能是符合需要的，际看一看未来系统的概貌，以便判断哪些功能是符合需要
6、的，哪些方面还需要改进。哪些方面还需要改进。v快速原型系统的快速原型系统的优越性优越性主要体现在：软件开发人员向用主要体现在：软件开发人员向用户提供一个户提供一个“样品样品”，用户向开发人员迅速作出，用户向开发人员迅速作出“反反馈馈”。第38页，共83页。快速原型模型图示快速原型模型图示用户测试，用户测试，运行原型运行原型建造修建造修改改/原型原型听取用听取用户意见户意见第39页，共83页。原型模型原型模型 原型产生步骤原型产生步骤第40页，共83页。如何产生快速原型系统？如何产生快速原型系统？v原型系统仅包括未来系统的主要功能，以及系统的重原型系统仅包括未来系统的主要功能，以及系统的重要接口
7、。要接口。v 为了尽快向用户提供原型，开发原型系统时应尽量使用能缩为了尽快向用户提供原型，开发原型系统时应尽量使用能缩短开发周期的语言和工具。短开发周期的语言和工具。v把原型系统作为基础，通过补充与修改获得最终的实把原型系统作为基础，通过补充与修改获得最终的实际系统。际系统。第41页，共83页。快速原型模型带来的问题：第42页，共83页。先完成一个系统子集的开发，再按同样的开发步骤先完成一个系统子集的开发，再按同样的开发步骤增加功能增加功能 (系统子集系统子集),),如此递增下去直至满足全部如此递增下去直至满足全部系统需求。系统需求。系统的总体设计在初始子集设计阶段就应作出系统的总体设计在初始
8、子集设计阶段就应作出设想。设想。第43页，共83页。增量模型增量模型分析分析设计设计编码编码测试测试分析分析设计设计编码编码测试测试分析分析设计设计编码编码测试测试分析分析设计设计编码编码测试测试增量增量2增量增量3增量增量4增量增量1第第1个增量的发布个增量的发布第第2个增量的发布个增量的发布第第3个增量的发布个增量的发布第第4增量的发布增量的发布要点：要点：顺序过程和原型过程相结合顺序过程和原型过程相结合 强调版本升级强调版本升级 每个版本的开发遵循顺序过程每个版本的开发遵循顺序过程 第44页，共83页。增量模型增量模型定义定义基本需求基本需求将需求赋予将需求赋予增量构件增量构件设计系统设
9、计系统体系结构体系结构开发开发增量构件增量构件确认确认增量构件增量构件集成集成增量构件增量构件确认系统确认系统第45页，共83页。结合瀑布模型与快速原型的基础上增加了风险分析结合瀑布模型与快速原型的基础上增加了风险分析第46页，共83页。u制定计划制定计划 确定软件目标，选定实施方案，确定软件目标，选定实施方案，弄清项目开发的限制条件；弄清项目开发的限制条件；u风险分析风险分析 分析所选方案，考虑如何识别分析所选方案，考虑如何识别和消除风险；和消除风险；u实施工程实施工程 实施软件开发实施软件开发u客户评估客户评估 评价开发，提出修正建议。评价开发，提出修正建议。第47页，共83页。螺旋螺旋模
10、型模型决定目标、决定目标、方案和限制方案和限制评价方案、评价方案、识别风险、识别风险、弱化风险弱化风险开发、验证、开发、验证、下一级产品下一级产品 计划下一阶段计划下一阶段集成测试第48页，共83页。风险分析风险分析工程工程构造及发布构造及发布用户评估用户评估客户交流客户交流计划计划项项目目入入口口螺旋模型螺旋模型轴线与增量模型的区别：与增量模型的区别：活动划分不同活动划分不同 更强调更强调“计划计划”、“风险分析风险分析”和和“用户评估用户评估”版本有更明确的目标版本有更明确的目标 要点：要点：相似于增量模型，是顺序过程与原型过程的统一，相似于增量模型，是顺序过程与原型过程的统一，强调版本和
11、版本升级。强调版本和版本升级。版本的明确目标：版本的明确目标：概念项目概念项目增量项目增量项目维护项目维护项目第49页，共83页。当前的软件的价值当前的软件的价值v动力源泉，世界不可或缺的一部分动力源泉，世界不可或缺的一部分v规模、复杂性、分布和重要性不断扩张规模、复杂性、分布和重要性不断扩张v生产和维护越来越难生产和维护越来越难v熟悉的软件开发方法收到限制熟悉的软件开发方法收到限制第50页，共83页。软件开发问题的症状软件开发问题的症状v 对于最终用户的需要理解得不够精确对于最终用户的需要理解得不够精确v 对需求的改变束手无策对需求的改变束手无策v程序块不兼容程序块不兼容v软件不易维护或不易
12、扩展软件不易维护或不易扩展v对项目严重缺陷的发现较晚对项目严重缺陷的发现较晚v软件质量低劣软件质量低劣v软件性能令人无法接受软件性能令人无法接受v开发组的人员按各自的方式进行开发，如果有人改变可开发组的人员按各自的方式进行开发，如果有人改变可部分软件，将很难进行重组部分软件，将很难进行重组v一个不可靠的构造和发布过程一个不可靠的构造和发布过程第51页，共83页。失败原因失败原因v 特别的需求管理特别的需求管理v模糊和不精确的交流模糊和不精确的交流v脆弱的构架脆弱的构架v过度复杂过度复杂v未检测出需求、设计和实现之间的不一致未检测出需求、设计和实现之间的不一致v测试的不足测试的不足v对于项目状况
13、的评估过于主观对于项目状况的评估过于主观v未解决存在的风险未解决存在的风险v无法控制变化的产生和传播无法控制变化的产生和传播v 自动控制不足自动控制不足第52页，共83页。最佳软件开发实践最佳软件开发实践 Best Practicesv迭代地开发软件迭代地开发软件 Develop Iterativelyv管理需求管理需求 Manage Requirementsv应用基于构件的构架应用基于构件的构架 Use Component Architecturesv 为软件建立可视化的模型为软件建立可视化的模型 Model Visually(UML)v不断地验证软件质量不断地验证软件质量 Continuo
14、usly Verify Qualityv控制软件的变更控制软件的变更 Manage Change第53页，共83页。Best Practices Reinforce Each Other:An ExampleValidates architectural decisions early onAddresses plexity of design/implementation incrementallyMeasures quality early and oftenEvolves baselines incrementallyEnsures users involved as requireme
15、nts evolveBest PracticesDevelop IterativelyManage RequirementsUse Component ArchitecturesModel Visually(UML)Continuously Verify QualityManage Change 第54页，共83页。v现在软件产业界普遍认为，开发复杂软件项目必须采用现在软件产业界普遍认为，开发复杂软件项目必须采用基于基于UML的、以构架为中心、用例驱动与风险驱动相结合的、以构架为中心、用例驱动与风险驱动相结合的迭代式增量开发过程，他是世界公认的开发复杂软件项目的迭代式增量开发过程，他是世界公认
16、的开发复杂软件项目的最好过程，已经成为软件界的的最好过程，已经成为软件界的“圣经圣经”。这一开发过程目。这一开发过程目前已经稳定、成熟。前已经稳定、成熟。这就是：这就是：RUPRational Unified Process第55页，共83页。Rational Unified ProcessRUP Rational 统一过程是由统一过程是由Rational 软件公司开发和营销软件公司开发和营销的一种软件工程过程，是开发组织用以分配与管理任务和职的一种软件工程过程，是开发组织用以分配与管理任务和职责的一种规范化方法。这个过程的目的是在预定的进度和预责的一种规范化方法。这个过程的目的是在预定的进度
17、和预算范围内，开发出满足最终用户需要的高质量软件。算范围内，开发出满足最终用户需要的高质量软件。第56页，共83页。RUP Implements Best PracticesBest PracticesProcess Made Practical Develop IterativelyManage RequirementsUse Component ArchitecturesModel Visually(UML)Continuously Verify QualityManage Change 第57页，共83页。软件开发过程软件开发过程v为开发小组的活动顺序提供向导为开发小组的活动顺序提供向导
18、v详细说明那些制品将被开发，以及什么时候开发详细说明那些制品将被开发，以及什么时候开发v指导每一个开发人员和整个开发组的工作指导每一个开发人员和整个开发组的工作v为监控和度量项目的产品和活动提供准则为监控和度量项目的产品和活动提供准则第58页，共83页。vRUP将这些最佳实践活动以一种适当的形式结合起来，从而将这些最佳实践活动以一种适当的形式结合起来，从而适应了广泛的项目和开发组织。适应了广泛的项目和开发组织。第59页，共83页。v RUP 是一个过程产品是一个过程产品(process product)。Rational(IBM)软件公司开发并维护着这个产品，软件公司开发并维护着这个产品，并将
19、其与并将其与Rational 软件公司自己的一系列软件开发工具软件公司自己的一系列软件开发工具集成。集成。第60页，共83页。vRUP 有自己的过程框架有自己的过程框架(process framework),这个框架可以被改造和扩展以适应采纳此方法的组织。这个框架可以被改造和扩展以适应采纳此方法的组织。第61页，共83页。RUP 简要历史RUP 2000RUP 5.5RUP 5.0ROP 4.1ROP 4.0Rational 方法Objective 过程3.8200019991998199719961995实时ROOM业务工程配置和变更管理需求学院Booch 方法OMT UML 0.8SQA
20、过程UML 1.1数据工程UI 设计UML 1.2基于WEB的开发UML1.3第62页，共83页。Rational Process WorkbenchMajor addition of contentMajor addition of tool mentorsImproved Process for independent testingRational Objectory Process 4.1 1997Rational Objectory Process 4.0 1996Rational Unified Process 5.0 1998Rational Unified Process 20
21、00Rational Unified Process 2001Rational Unified Process 5.5 1999Rational Unified Process 2002Rational Unified Process 2003Rational ApproachProject ManagementUML 1.3RealTimePerformance TestingBusiness ModelingConfiguration&Change MgtObjectory UI DesignData EngineeringUML 1.1OMTBoochUML 1.0Requirement
22、s Test ProcessTree browser upgraded for enhanced capabilities of creating customized My RUP treeIntroduction of RUP Platform providing a configurable process framework Objectory Process 3.8History of RUP第63页，共83页。RUP特点特点v 用例驱动用例驱动v以体系结构为中心以体系结构为中心v增量和迭代开发增量和迭代开发第64页，共83页。用例驱动用例驱动 用用Use Case作为划分问题的组织
23、单元，分析和设计活作为划分问题的组织单元，分析和设计活动的局部粒度都遵循这一划分原则。动的局部粒度都遵循这一划分原则。Use Case的定义的定义反映可系统外部要素根据特定目标使用拟建系统的状况，反映可系统外部要素根据特定目标使用拟建系统的状况，能确保问题的局部划分粒度适当，保持了全局与局部的平能确保问题的局部划分粒度适当，保持了全局与局部的平衡。衡。第65页，共83页。第66页，共83页。增量和迭代开发增量和迭代开发v基于风险前驱的原则，渐进地展开分析、设计及其相关基于风险前驱的原则，渐进地展开分析、设计及其相关活动，每个迭代都会提供一次验证和调整模型机会，推活动，每个迭代都会提供一次验证和
24、调整模型机会，推动软件质量的提升。动软件质量的提升。第67页，共83页。RUP 二维过程结构沿时间轴的组织结构沿内容轴的组织结构第68页，共83页。RUP的生命开发周期第69页，共83页。RUP的生命开发周期第70页，共83页。RUP的生命开发周期第71页，共83页。RUP的生命开发周期第72页，共83页。主要困难主要困难多层次持续的规划与评估多层次持续的规划与评估判断架构中关键风险的经验判断架构中关键风险的经验高效率的验证和评价手段高效率的验证和评价手段多工种之间的频繁沟通多工种之间的频繁沟通多版本工作产品的管理多版本工作产品的管理第73页，共83页。第74页，共83页。第75页，共83页。第76页，共83页。第77页，共83页。第78页，共83页。RUP 的裁减的裁减RUP 仅仅是一个通用的过程框架，需要根据实际仅仅是一个通用的过程框架，需要根据实际情况裁减。情况裁减。第79页，共83页。第80页，共83页。Contents软件软件(1.1)软件危机软件危机(1.2)软件工程软件工程(1.2)软件生命周期软件生命周期(1.3)软件开发模型软件开发模型(1.4)软件工程的目标软件工程的目标第81页，共83页。第82页，共83页。软件工程软件工程第83页，共83页。
