南阳理工学院李亚红软件工程.docx

1、南阳理工学院李亚红软件工程南阳理工学院李亚红软件工程软件工程- 原理、方法与应用（第三版）主要内容v绪论v上篇-传统软件工程v软件生存周期与软件过程v结构化分析与设计v中篇-面向对象软件工程v面向对象与UMLv需求工程与需求分析v面向对象分析v面向对象设计v编码与测试v下篇-软件工程的近期进展、管理与环境v软件维护v软件复用v软件工程管理v软件质量管理v软件工程环境v软件工程高级课题第一章 绪论v软件和软件危机v软件工程学的范畴v软件工程的发展v软件工程的应用v软件工程的教学软件是能够完成预定功能和性能的可执行的计算机程序，包括使程序正常执行所需的数据，以及有关描述程序操作和使用的文档（R.

2、S. Pressman）软件=程序（包括数据）+文档程序是为了解决某个特定问题而用程序设计语言描述的适合计算机处理的语句序列数据是使程序能正常操纵信息的数据结构文档是与程序开发，维护和使用有关的图文材料软件与硬件的不同软件开发不同于硬件设计软件生产与硬件制造不同软件维护不同于硬件维修软件是逻辑的，而不是物理的软件开发与人关系密切软件开发成本大软件生产是简单的拷贝软件不会磨损和老化软件受环境影响大软件维护易产生新的问题软件危机的表现对软件开发成本和进度的估算很不准确用户很不满意质量很不可靠没有适当的文档软件成本比重上升供不应求：软件开发生产率跟不上计算机应用迅速深入的趋势 硬件/软件成本变化趋势

3、软件技术进步落后于需求增长软件危机的原因客观：软件本身特点-逻辑部件-规模庞大、复杂度高主观：不正确的开发方法-忽视需求分析-个人化方式：软件开发=程序编写-轻视软件维护解决途径组织管理-工程项目管理方法技术措施-软件开发技术与方法-软件工具促使了软件工程的诞生按工程化的原理和方法组织软件开发是软件开发中的问题一个主要出路2. 软件工程学的研究范畴2. 软件工程学的研究范畴软件开发方法为软件开发提供了 如何做 的技术个性化方法-结构化方法-面向对象方法-软件复用软件工具为软件开发提供了自动的或半自动的软件支撑环境单个工具-工具箱、集成工具-环境软件工程管理目的：为了按进度及预算完成软件计划内容

4、：成本估算、进度安排、人员组织、质量保证等三种编程范型过程式编程范型程序由一组被动数据和一组能动过程组成程序=数据结构+算法着眼于程序的过程和基本控制结构，粒度最小面向对象编程范型数据及其操作被封装在对象中程序=对象+消息着眼于程序中的对象，粒度比较大基于构件技术的编程范型构件是通用的、可复用的标准化对象类程序=构件+架构着眼于适合整个领域的类对象，粒度更大过程式和面向对象的编程范型三代软件工程传统软件工程结构化分析 结构化设计 面向过程的编码 软件测试 面向对象软件工程传统的软件过程软件演化模型形式化方法模型统一过程和敏捷过程软件可行性研究1. 软件生存周期 典型的软件生存周期软件生存周期的

5、主要活动需求分析明确需要解决的问题（从用户的视角）建立需求模型：功能、性能、约束、接口等软件分析从开发人员的视角对软件进行分析建立分析模型：软件的逻辑模型软件设计确定软件的总体结构和各部件的数据结构和操作建立软件设计模型：考虑实现技术和平台编码用程序设计语言将设计文档翻译成源程序建立软件实现模型：包含现有软件构件包软件测试发现程序中的错误、提高软件质量单元测试、集成测试、确认测试、系统测试运行维护软件过程与软件生存周期2. 传统的软件过程传统的过程模型瀑布模型waterfall model基于软件生存周期的线性开发模型快速原型模型rapid prototype model基于原型的迭代化开发模

6、型瀑布模型瀑布模型特点阶段的顺序性和依赖性推迟实现的观点质量保证的观点存在问题不适合需求模糊的系统开发初始阶段很难彻底弄清软件需求快速原型模型快速原型模型特点“逼真”的原型可以使用户迅速作出反馈循环回溯和迭代：非线性模型使用快速开发工具种类渐进型：对原型补充和修改获得最终系统抛弃型：原型废弃不用应防止的偏向舍不得抛弃，从而影响软件质量3. 软件演化模型演化开发模型：使所开发的软件在迭代中逐步完善增量模型（incremental model）螺旋模型（spiral model）构件集成模型（component integration model） 增量模型增量模型增量小而可用的软件第一个增量通常

7、是软件的核心特点在前面增量的基础上开发后面的增量每个增量的开发可用瀑布或快速原型模型每个增量开发的顺序性和总体的迭代性相结合螺旋模型螺旋模型特点瀑布模型（顺序性、边开发边复审）+快速原型（迭代性）风险分析-发现、控制风险一个螺旋式周期 计划：确定目标，选择方案，选定完成目标的策略 风险分析：从风险角度分析该策略 开发：启动一个开发活动 评审：评价前一步的结果，计划下一轮的工作 面向对象的基本概念对象Object类Class继承Inheritance消息Message 面向对象对象+类+继承+消息通信构件集成模型构件集成模型构件在某个领域内具有通用性，可以复用的软件部件将可以复用的构件存储起来，

8、形成构件库特点面向对象基于构件库融合螺旋模型特征支持软件开发的迭代方法 软件复用4. 形式化方法模型形式化方法模型：基于程序变换和验证技术的软件开发转换模型（transformational model）净室模型（cleanroommodel） 转换模型转换模型开发过程确定形式化需求规格说明书进行自动的程序变换针对形式化开发记录进行测试特点形式化软件开发方法 形式化需求规格说明 变换技术程序自动生成技术 确保正确 净室模型净室模型净室思想在分析和设计阶段消除错误在“洁净”状态下实现软件制作形式化盒结构表示分析和设计正确性验证增量模型把软件看成一系列的增量软件过程模型的特点汇总5. 统一过程和敏

9、捷过程统一过程Rational Unified Process（RUP）描述了软件开发中各个环节应该做什么、怎么做、什么时候做以及为什么要做，描述了一组以某种顺序完成的活动敏捷过程Agile Development是一种以人为核心、迭代、循序渐进的开发方法，其软件开发过程称为“敏捷过程” RUPRational Unified Process 将软件开发分为四个阶段：先启 定义整个项目的范围精化 制定项目计划、描述功能、建立体系架构框架构建 构造软件产品迁移 将软件产品移交到最终用户手中敏捷过程敏捷开发的价值观个人和交互胜过过程和工具 可以运行的软件胜过面面俱到的文档 客户合作胜过合同谈判 响

10、应变化胜过遵循计划敏捷开发的12条原则尽早、不断地提交有价值的软件 允许改变需求，利用变化来为客户创造优势尽快、不断地提交可运行的软件在业务人员和开发人员必须天天都在一起工作以积极向上的员工为中心建立项目组，提供环境和支持，并信任他们的工作在团队内部重视面对面的交流依据可运行软件来评估项目的进展提倡可持续的开发时刻关注技术上的精益求精和好的设计，以增强敏捷能力简单是最根本的最好的构架、需求和设计出于自组织团队每隔一定时间，要反省如何才能更有效地工作，然后作相应调整 极限编程eXtreme Programming是一种轻量级的、敏捷的软件开发方法4个价值观交流、简单、反馈、勇气4个方面改善加强交

11、流、从简单做起、寻求反馈、勇于实事就是12个核心实践完整团队、计划对策、测试、简单设计、结对编程、小软件版本、设计改进、持续集成、代码共有、编码标准、系统比喻、可持续的速度6. 软件可行性研究目的研究项目是否可能实现和值得进行回答 Why to do?研究的内容经济可行性技术可行性运行可行性法律可行性可行性研究的步骤对当前系统进行调查和研究弄清当前系统导出新系统逻辑模型导出新系统的解决方案设计不同的解决方案提出推荐的方案本项目的开发价值推荐这个方案的理由编写可行性认证报告系统概述可行性分析结论意见软件风险分析风险识别项目风险技术风险商业风险风险预测风险发生的可能性风险发生后的后果风险的驾驭和监

12、控小结随着软件工程的发展，许多学者先后提出了瀑布模型、快速原型模型、增量模型、螺旋模型、转换模型、净室模型和构件集成等多种过程模型，各种软件开发模型各有优缺点在选定软件开发过程时，开发者不仅应该了解开发过程的特点，还应该结合待开发系统的特点一起考虑。如有必要，也可以同时组合多种模型或创建新的模型。 第三章 结构化分析与设计概述 -结构化分析与设计的由来结构化分析与设计最初系由结构化程序设计扩展而来 瀑布模型的首次实践 SA与SD的流程 结构化分析（工具：DFD、PSPEC） 分析模型（分层DFD图）+ SRS结构化设计（工具：SC图） 映射 初始设计模型（初始SC图）初始设计模型（初始SC图）

13、 优化 最终设计模型（最终SC图）基本任务与指导思想 结构化分析 建立分析模型 编写需求说明 结构化设计 软件设计 = 总体设计 + 详细设计 SC图须分两步完成 概述 -结构化分析与设计的由来结构化分析与设计最初系由结构化程序设计扩展而来 瀑布模型的首次实践 SA与SD的流程 结构化分析（工具：DFD、PSPEC） 分析模型（分层DFD图）+ SRS结构化设计（工具：SC图） 映射 初始设计模型（初始SC图）初始设计模型（初始SC图） 优化 最终设计模型（最终SC图）基本任务与指导思想 结构化分析 建立分析模型 编写需求说明 结构化设计 软件设计 = 总体设计 + 详细设计 SC图须分两步完

14、成 概述 -SA模型的组成与描述 结构化分析模型的描述工具概述 -SD模型的组成与描述 结构化设计模型的描述工具SC图的组成符号矩形框来表示模块，带箭头的连线表示模块间的调用，并在调用线的两旁标出传入和传出模块的数据流 2. 结构化系统分析 T.DeMarco的定义 结构化分析就是使用DFD、DD、结构化英语、判定表和判定树等工具，来建立一种新的、称为结构化说明书的目标文档 结构化分析的基本步骤 由顶向下对系统进行功能分解，画出分层DFD图由后向前定义系统的数据和加工，编制DD和PSPEC最终写出SRS 2. 结构化系统分析 -画分层数据流图 2. 结构化系统分析 -画分层数据流图 2. 结构

15、化系统分析 -画分层数据流图 2. 结构化系统分析 -确定数据定义与加工策略 从数据的终点开始定义数据和加工数据定义DD例如：发票发票 学号姓名书号单价数量总价书费合计加工策略PSPEC分层DFD图产生了系统的全部数据和加工，通过对这些数据和加工的定义，常常对分析员提出一些新问题，促使新的调查和思考，并可能导致对DFD的修改。画DFD，定义加工和数据，再画，再定义，如此循环，直至产生一个为用户和分析员一致同意的文档SRS。 2. 结构化系统分析 -需求分析的复审 复审人员用户和系统分析员共同进行复审，并吸收设计人员参加 复审的重点 尽量多地发现文档中存在的矛盾、冗余与遗漏 ，尽可能确保DFD、

16、DD、加工说明等文档的完整性、一改性和易读性，3.结构化系统设计 从分析模型导出设计模型数据流图的类型数据流图的类型 变换（transform）型结构 传入路径变换中心传出路径事务（transaction）型结构一条接受路径一个事务中心若干条动作路径 变换结构的DFD事务型结构DFD同时存在两类结构SD方法的步骤 变换映射划分DFD图的边界 建立初始SC图的框架顶层都只含一个用于控制的主模块 第一层包括传入、传出和中心变换三个模块 分解SC图的各个分支 分解实质上是“映射” 例子划分DFD第一级分解传入分支的分解传出分支的分解变换中心的分解初始SC图事务映射在DFD图上确定边界事务中心接受部分

17、（包括接受路径）发送部分（包括全部动作路径） 画出SC图框架 DFD图的三个部分分别映射为事务控制模块，接受模块和动作发送模块 分解和细化接受分支和发送分支 例子划分DFD第一层分解混合结构优化结构设计的指导规则 对模块划分的指导规则 提高内聚，降低耦合后简化模块接口少用全局性数据和控制型信息保持高扇入/低扇出的原则 扇入高则上级模块多，能够增加模块的利用率扇出低则表示下级模块少，可以减少模块调用和控制的复杂度 扇入和扇出例子：扇出例子：扇出4. 模块设计模块设计也称详细设计目的为SC图中的每个模块确定算法和数据结构，用选定的表达工具给出清晰的描述 主要任务 编写软件的“模块设计说明书” 模块

18、设计的原则与方法 清晰第一的设计风格 结构化的控制结构 仅用这三种控制结构来构成程序 每个控制结构只应有一个入口和一个出口 逐步细化的实现方法 常用的表达工具 流程图NS图 伪代码PDL语言N-S图小结讨论传统软件工程的系统开发技术，重点放在基于瀑布模型的结构化分析与设计和模块设计上，但不涉及同为传统软件工程的快速原型开发等内容。全章以实例（从“教材销售”到“教材购销”）为主线，依次展示了结构化分析、结构化设计和模块设计的常用技术。第四章 面向对象与UML面向对象概述UML简介静态建模动态建模物理架构建模UML工具1. 面向对象概述v对象：代表客观世界中实际或抽象的事物 v客观世界是由各种对象

19、组成的 v数据以及在其上的操作的封装体 v类：一组相似的对象的共性抽象v类是一组客观对象的抽象v实现抽象数据类型的工具 v类与对象的关系v抽象与具体的关系v组成类的每个对象都是该类的实例 v实例是类的具体事物 v类是各个实例的综合抽象 面向对象概述 -面向对象的基本特征面向对象的基本特征抽象在某个重要的或想关注的方面来表示某个物体或概念 忽略主题中与当前目标无关的方面 封装把操作和数据包围起来，对数据的访问只通过已定义的接口来完成 继承类之间的“is a”或“is like”关系 类层次，定义一个新类，可以从现有的类中派生出来 子类可以从父类继承方法和属性 多态 不同类的对象可以对同一消息作出

20、响应，执行不同的处理 面向对象概述 -面向对象开发的优点2. UML简介Unified Modeling Language近10多年来OOSE最重要的成果贡献者：Grady Booch， Ivar Jacobson，Jim Rumbaugh中文网站http:/www. UML的组成UML的模型元素表示模型中的某个概念类、对象、构件、用例、结点（node）、接口（interface）、包（package）和注释（note） 表示模型元素之间的关系关联、泛化、依赖、实现、聚合和组合 UML的元模型结构元元模型层元模型层模型层用户模型层UML的组成图静态图用例图、类图、对象图、构件图和部署图 动态图

21、状态图、时序图、协作图和活动图 视图用例视图从用户的角度看到的系统应有的外部功能 逻辑视图描述系统的静态结构和对象间的动态协作关系 进程视图展示系统的动态行为及其并发性 构件视图展示系统实现的结构和行为特征 部署视图显示系统的实现环境和构件被部署到物理结构中的映射 UML的特点统一标准面向对象表达能力强大可视化UML的应用用于描述系统开发的不同类型于不同阶段从需求分析到软件设计到软件测试及维护可视化问题描述，帮助理解问题帮助建立各阶段的文档获取和交流有关应用问题求解的知识辅助构建系统3. 静态建模静态建模用例图、类图和对象图用例模型用例图表示从最终用户的角度描述系统功能类和对象模型类图和对象图

22、表示用例图与用例模型用例图的组成符号建立用例图用例之间的关系扩展关系根据指定的条件，一个用例中有可能加入另一个用例的动作 包含关系一个用例的行为包含另一个用例的行为 类图Class Diagram对象图Object Diagram类图表示类间关系关联关系 (Association) 类之间存在的语义上的关系普通关联、递归关联、多重关联等聚集关系(Aggregation) 特殊的关联：整体-部分组合关系(Composition)特殊的聚集：整体强烈拥有部分泛化关系(Generalization) 继承依赖关系(Dependency) 对一个类/对象的修改会影响另一个类/对象关联关系聚集和组合泛化

23、关系依赖关系约束与派生约束和派生机制能应用与任何模型元素 用花括号括起放在模型元素旁边 典型的属性约束是该属性的取值范围 派生属性可由其它属性通过某种方式计算得到，通常在派生属性前面加一个“/”表示 关联关系可以被约束，也可以被派生 包图4. 动态建模消息（Message）状态图（State Diagram）时序图（Sequence Diagram）协作图（Collaboration Diagram）活动图（Activity Diagram）消息状态图State Diagram状态图之间发送消息时序图（Sequence Diagram）协作图（Collaboration Diagram）活动图

24、Activity Diagram5. 物理架构建模逻辑架构和物理架构逻辑架构物理架构构件图配置图构件图Component Diagram部署图Deployment Diagram6. UML 工具Rational RoseStarUML Rational RoseStarUML小结面向对象开发按人的思维方式来理解和解决问题，将问题空间的概念直接映射到解空间。面向对象的基本特征是抽象、封装、继承和多态。 作为一种著名的建模语言，UML用图从不同的视角为系统建模，形成为不同的视图；每个视图代表系统完整描述中的一个抽象，显示这个系统中的一个特定的方面；每个视图由一组图构成，其中包含了强调系统中某一方

25、面的信息。 第5章 需求工程与需求分析软件需求过程需求分析与建模需求获取的常用方法需求模型软件需求描述需求管理需求建模示例1. 软件需求工程软件需求的定义一个软件系统必须遵循的条件或具备的能力 系统的外部行为 系统的内部特性 软件需求三个层次 业务需求用户需求功能需求 软件需求的层次关系软件需求的特性功能性可用性可靠性性能可支持性设计约束需求工程的由来代码编写-生存周期-需求工程软件需求工程可以定义为应用有效的技术和方法，合适的工具和符号，来确定、管理和描述目标系统及其外部行为特征的学科 2. 需求分析与建模需求分析的步骤需求分析是迭代过程3. 需求获取的常用方法常规的需求获取方法联合分析小组

26、 用户代表、领域专家和系统分析员客户访谈 充分准备，寻找共同语言 循循序渐进、逐步逼近 问题分析与确认 多个来回3. 需求获取的常用方法用快速原型法获取需求利用各种分析技术和方法，生成一个简化的需求规格说明；对需求规格说明进行必要的检查和修改后，确定原型的软件结构、用户界面和数据结构等；在现有的工具和环境的帮助下快速生成可运行的软件原型并进行测试、改进；将原型提交给用户评估并征求用户的修改意见；重复上述过程，直到原型得到用户的认可。 4. 需求模型需求模型概述结构化需求模型面向对象需求模型面向对象的需求建模画用例图写用例规约描述补充规约编写术语表结构化需求模型面向对象需求模型用例建模确定参与者存在于系统外部、与系统交互的人、硬件、其他系统通过回答问题确定参与者系统开发完成之后，有哪些人会使用这个系统？ 系统需要从哪些人或其他系统中获得数据？ 系统会为哪些人或其他系统提供数据？ 系统会与哪些其他系统相关联？ 系统是由谁来维护和管理的？ 用例建模确定用例考察每个参与者与系统的交互和需要系统提供的服务通过回答问题确定用例参与者为什么要使用该系统？ 参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？ 参与者是否会将外部的某些事件通知给该系统？ 系统是否会将内部的某些事件通知该参与者？用例建模