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

软件工程- 原理、方法与应用（第三版）主要内容v 绪论v 上篇-传统软件工程v 软件生存周期与软件过程v 结构化分析与设计v 中篇-面向对象软件工程v 面向对象与UMLv 需求工程与需求分析v 面向对象分析v 面向对象设计v 编码与测试v 下篇-软件工程的近期进展、管理与环境v 软件维护v 软件复用v 软件工程管理v 软件质量管理v 软件工程环境v 软件工程高级课题第一章 绪论v 软件和软件危机v 软件工程学的范畴v 软件工程的发展v 软件工程的应用v 软件工程的教学 软件是能够完成预定功能和性能的可执行的计算机程序，包括使程序正常执行所需的数据，以及有关描述程序操作和使用的文档（R. S. Pressman） 软件=程序（包括数据）+文档 程序是为了解决某个特定问题而用程序设计语言描述的适合计算机处理的语句序列 数据是使程序能正常操纵信息的数据结构 文档是与程序开发，维护和使用有关的图文材料q 软件与硬件的不同q 软件开发不同于硬件设计q 软件生产与硬件制造不同q 软件维护不同于硬件维修q 软件是逻辑的，而不是物理的n 软件开发与人关系密切n 软件开发成本大n 软件生产是简单的拷贝n 软件不会磨损和老化n 软件受环境影响大n 软件维护易产生新的问题n 软件危机的表现 对软件开发成本和进度的估算很不准确 用户很不满意 质量很不可靠 没有适当的文档 软件成本比重上升 供不应求：软件开发生产率跟不上计算机应用迅速深入的趋势 硬件/软件成本变化趋势软件技术进步落后于需求增长n 软件危机的原因 客观：软件本身特点-逻辑部件-规模庞大、复杂度高 主观：不正确的开发方法-忽视需求分析-个人化方式：软件开发=程序编写-轻视软件维护n 解决途径 组织管理-工程项目管理方法 技术措施-软件开发技术与方法-软件工具n 促使了软件工程的诞生n 按工程化的原理和方法组织软件开发是软件开发中的问题一个主要出路2. 软件工程学的研究范畴2. 软件工程学的研究范畴n 软件开发方法n 为软件开发提供了 如何做 的技术n 个性化方法-结构化方法-面向对象方法-软件复用n 软件工具n 为软件开发提供了自动的或半自动的软件支撑环境n 单个工具-工具箱、集成工具-环境n 软件工程管理n 目的：为了按进度及预算完成软件计划n 内容：成本估算、进度安排、人员组织、质量保证等r 三种编程范型r 过程式编程范型r 程序由一组被动数据和一组能动过程组成r 程序=数据结构+算法r 着眼于程序的过程和基本控制结构，粒度最小r 面向对象编程范型r 数据及其操作被封装在对象中r 程序=对象+消息r 着眼于程序中的对象，粒度比较大r 基于构件技术的编程范型r 构件是通用的、可复用的标准化对象类r 程序=构件+架构r 着眼于适合整个领域的类对象，粒度更大过程式和面向对象的编程范型r 三代软件工程n 传统软件工程n 结构化分析 结构化设计 面向过程的编码 软件测试 n 面向对象软件工程n OO分析与对象抽取 对象详细设计 面向对象的编码 和测试 n 基于构件的软件工程n 领域分析和测试计划定制 领域设计 建立可复用构件库 查找并集成构件 4. 软件工程的应用n 软件工程指导中小型软件n 软件工程指导大型软件n 软件工程的成就n 解决软件开发中的部分问题（非本质）n 软件生产率稳步增长n 软件工程发展的展望n 开发伴随软件复用，开发为了软件复用n 软件就是服务5. 软件工程的教学n 正确处理好4个关系n 三代软件工程的相互关系n 软件工程技术和软件工程管理的关系n 形式化方法和非形式化方法的关系n 小程序设计和大程序设计的关系n 教学中加强实践训练小结第二章 软件生存周期与软件过程p 软件生存周期p 传统的软件过程p 软件演化模型p 形式化方法模型p 统一过程和敏捷过程p 软件可行性研究1. 软件生存周期 典型的软件生存周期软件生存周期的主要活动n 需求分析n 明确需要解决的问题（从用户的视角）n 建立需求模型：功能、性能、约束、接口等n 软件分析n 从开发人员的视角对软件进行分析n 建立分析模型：软件的逻辑模型n 软件设计n 确定软件的总体结构和各部件的数据结构和操作n 建立软件设计模型：考虑实现技术和平台n 编码n 用程序设计语言将设计文档翻译成源程序n 建立软件实现模型：包含现有软件构件包n 软件测试n 发现程序中的错误、提高软件质量n 单元测试、集成测试、确认测试、系统测试n 运行维护软件过程与软件生存周期2. 传统的软件过程n 传统的过程模型n 瀑布模型n waterfall modeln 基于软件生存周期的线性开发模型n 快速原型模型n rapid prototype modeln 基于原型的迭代化开发模型瀑布模型瀑布模型n 特点n 阶段的顺序性和依赖性n 推迟实现的观点n 质量保证的观点n 存在问题n 不适合需求模糊的系统n 开发初始阶段很难彻底弄清软件需求快速原型模型快速原型模型n 特点n “逼真”的原型可以使用户迅速作出反馈n 循环回溯和迭代：非线性模型n 使用快速开发工具n 种类n 渐进型：对原型补充和修改获得最终系统n 抛弃型：原型废弃不用n 应防止的偏向n 舍不得抛弃，从而影响软件质量3. 软件演化模型n 演化开发模型：使所开发的软件在迭代中逐步完善n 增量模型（incremental model）n 螺旋模型（spiral model）n 构件集成模型（component integration model） 增量模型增量模型n 增量n 小而可用的软件n 第一个增量通常是软件的核心n 特点n 在前面增量的基础上开发后面的增量n 每个增量的开发可用瀑布或快速原型模型n 每个增量开发的顺序性和总体的迭代性相结合螺旋模型螺旋模型n 特点n 瀑布模型（顺序性、边开发边复审）+快速原型（迭代性）n 风险分析-发现、控制风险n 一个螺旋式周期 n 计划：确定目标，选择方案，选定完成目标的策略 n 风险分析：从风险角度分析该策略 n 开发：启动一个开发活动 n 评审：评价前一步的结果，计划下一轮的工作 面向对象的基本概念n 对象Objectn 类Classn 继承Inheritancen 消息Message n 面向对象n 对象+类+继承+消息通信构件集成模型构件集成模型n 构件n 在某个领域内具有通用性，可以复用的软件部件n 将可以复用的构件存储起来，形成构件库n 特点n 面向对象n 基于构件库n 融合螺旋模型特征n 支持软件开发的迭代方法 n 软件复用4. 形式化方法模型n 形式化方法模型：基于程序变换和验证技术的软件开发n 转换模型（transformational model）n 净室模型（cleanroommodel） 转换模型转换模型n 开发过程n 确定形式化需求规格说明书n 进行自动的程序变换n 针对形式化开发记录进行测试n 特点n 形式化软件开发方法 n 形式化需求规格说明 n 变换技术n 程序自动生成技术 n 确保正确 净室模型净室模型n 净室思想n 在分析和设计阶段消除错误n 在“洁净”状态下实现软件制作n 形式化n 盒结构表示分析和设计n 正确性验证n 增量模型n 把软件看成一系列的增量软件过程模型的特点汇总5. 统一过程和敏捷过程n 统一过程n Rational Unified Process（RUP）描述了软件开发中各个环节应该做什么、怎么做、什么时候做以及为什么要做，描述了一组以某种顺序完成的活动n 敏捷过程n Agile Development是一种以人为核心、迭代、循序渐进的开发方法，其软件开发过程称为“敏捷过程” RUPRational Unified Process 将软件开发分为四个阶段：n 先启 定义整个项目的范围n 精化 制定项目计划、描述功能、建立体系架构框架n 构建 构造软件产品n 迁移 将软件产品移交到最终用户手中敏捷过程n 敏捷开发的价值观n 个人和交互胜过过程和工具 n 可以运行的软件胜过面面俱到的文档 n 客户合作胜过合同谈判 n 响应变化胜过遵循计划n 敏捷开发的12条原则n 尽早、不断地提交有价值的软件 n 允许改变需求，利用变化来为客户创造优势n 尽快、不断地提交可运行的软件n 在业务人员和开发人员必须天天都在一起工作n 以积极向上的员工为中心建立项目组，提供环境和支持，并信任他们的工作n 在团队内部重视面对面的交流n 依据可运行软件来评估项目的进展n 提倡可持续的开发n 时刻关注技术上的精益求精和好的设计，以增强敏捷能力n 简单是最根本的n 最好的构架、需求和设计出于自组织团队n 每隔一定时间，要反省如何才能更有效地工作，然后作相应调整 极限编程n eXtreme Programming是一种轻量级的、敏捷的软件开发方法n 4个价值观n 交流、简单、反馈、勇气n 4个方面改善n 加强交流、从简单做起、寻求反馈、勇于实事就是n 12个核心实践n 完整团队、计划对策、测试、简单设计、结对编程、小软件版本、设计改进、持续集成、代码共有、编码标准、系统比喻、可持续的速度6. 软件可行性研究n 目的n 研究项目是否可能实现和值得进行n 回答 Why to do?n 研究的内容n 经济可行性n 技术可行性n 运行可行性n 法律可行性可行性研究的步骤n 对当前系统进行调查和研究n 弄清当前系统n 导出新系统逻辑模型n 导出新系统的解决方案n 设计不同的解决方案n 提出推荐的方案n 本项目的开发价值n 推荐这个方案的理由n 编写可行性认证报告n 系统概述n 可行性分析n 结论意见软件风险分析n 风险识别n 项目风险n 技术风险n 商业风险n 风险预测n 风险发生的可能性n 风险发生后的后果n 风险的驾驭和监控小结n 随着软件工程的发展，许多学者先后提出了瀑布模型、快速原型模型、增量模型、螺旋模型、转换模型、净室模型和构件集成等多种过程模型，各种软件开发模型各有优缺点n 在选定软件开发过程时，开发者不仅应该了解开发过程的特点，还应该结合待开发系统的特点一起考虑。如有必要，也可以同时组合多种模型或创建新的模型。 第三章 结构化分析与设计 概述 -结构化分析与设计的由来n 结构化分析与设计最初系由结构化程序设计扩展而来 n 瀑布模型的首次实践 n SA与SD的流程 n 结构化分析（工具：DFD、PSPEC） 分析模型（分层DFD图）+ SRSn 结构化设计（工具：SC图） 映射 初始设计模型（初始SC图）n 初始设计模型（初始SC图） 优化 最终设计模型（最终SC图）n 基本任务与指导思想 n 结构化分析 n 建立分析模型 n 编写需求说明 n 结构化设计 n 软件设计 = 总体设计 + 详细设计 n SC图须分两步完成 概述 -结构化分析与设计的由来n 结构化分析与设计最初系由结构化程序设计扩展而来 n 瀑布模型的首次实践 n SA与SD的流程 n 结构化分析（工具：DFD、PSPEC） 分析模型（分层DFD图）+ SRSn 结构化设计（工具：SC图） 映射 初始设计模型（初始SC图）n 初始设计模型（初始SC图） 优化 最终设计模型（最终SC图）n 基本任务与指导思想 n 结构化分析 n 建立分析模型 n 编写需求说明 n 结构化设计 n 软件设计 = 总体设计 + 详细设计 n SC图须分两步完成 概述 -SA模型的组成与描述 结构化分析模型的描述工具 概述 -SD模型的组成与描述 结构化设计模型的描述工具n SC图的组成符号n 矩形框来表示模块，带箭头的连线表示模块间的调用，并在调用线的两旁标出传入和传出模块的数据流 2. 结构化系统分析 n T.DeMarco的定义 n 结构化分析就是使用DFD、DD、结构化英语、判定表和判定树等工具，来建立一种新的、称为结构化说明书的目标文档 n 结构化分析的基本步骤 n 由顶向下对系统进行功能分解，画出分层DFD图n 由后向前定义系统的数据和加工，编制DD和PSPECn 最终写出SRS 2. 结构化系统分析 -画分层数据流图 2. 结构化系统分析 -画分层数据流图 2. 结构化系统分析 -画分层数据流图 2. 结构化系统分析 -确定数据定义与加工策略 n 从数据的终点开始定义数据和加工n 数据定义DDn 例如：发票n 发票 学号姓名书号单价数量总价书费合计n 加工策略PSPECn 分层DFD图产生了系统的全部数据和加工，通过对这些数据和加工的定义，常常对分析员提出一些新问题，促使新的调查和思考，并可能导致对DFD的修改。画DFD，定义加工和数据，再画，再定义，如此循环，直至产生一个为用户和分析员一致同意的文档SRS。 2. 结构化系统分析 -需求分析的复审 n 复审人员n 用户和系统分析员共同进行复审，并吸收设计人员参加 n 复审的重点 n 尽量多地发现文档中存在的矛盾、冗余与遗漏 ，尽可能确保DFD、DD、加工说明等文档的完整性、一改性和易读性，3.结构化系统设计 从分析模型导出设计模型数据流图的类型n 数据流图的类型 n 变换（transform）型结构 n 传入路径n 变换中心n 传出路径n 事务（transaction）型结构n 一条接受路径n 一个事务中心n 若干条动作路径 变换结构的DFD事务型结构DFD同时存在两类结构SD方法的步骤 变换映射n 划分DFD图的边界 n 建立初始SC图的框架n 顶层都只含一个用于控制的主模块 n 第一层包括传入、传出和中心变换三个模块 n 分解SC图的各个分支 n 分解实质上是“映射” 例子划分DFD第一级分解传入分支的分解传出分支的分解变换中心的分解初始SC图事务映射n 在DFD图上确定边界n 事务中心n 接受部分（包括接受路径）n 发送部分（包括全部动作路径） n 画出SC图框架 n DFD图的三个部分分别映射为事务控制模块，接受模块和动作发送模块 n 分解和细化接受分支和发送分支 例子划分DFD第一层分解混合结构优化结构设计的指导规则 n 对模块划分的指导规则 n 提高内聚，降低耦合后n 简化模块接口n 少用全局性数据和控制型信息n 保持高扇入/低扇出的原则 n 扇入高则上级模块多，能够增加模块的利用率n 扇出低则表示下级模块少，可以减少模块调用和控制的复杂度 扇入和扇出例子：扇出例子：扇出4. 模块设计n 模块设计也称详细设计n 目的n 为SC图中的每个模块确定算法和数据结构，用选定的表达工具给出清晰的描述 n 主要任务 n 编写软件的“模块设计说明书” 模块设计的原则与方法 n 清晰第一的设计风格 n 结构化的控制结构 n 仅用这三种控制结构来构成程序 n 每个控制结构只应有一个入口和一个出口 n 逐步细化的实现方法 常用的表达工具 n 流程图n NS图 n 伪代码n PDL语言N-S图小结n 讨论传统软件工程的系统开发技术，重点放在基于瀑布模型的结构化分析与设计和模块设计上，但不涉及同为传统软件工程的快速原型开发等内容。全章以实例（从“教材销售”到“教材购销”）为主线，依次展示了结构化分析、结构化设计和模块设计的常用技术。第四章 面向对象与UML 面向对象概述 UML简介 静态建模 动态建模 物理架构建模 UML工具1. 面向对象概述v 对象：代表客观世界中实际或抽象的事物 v 客观世界是由各种对象组成的 v 数据以及在其上的操作的封装体 v 类：一组相似的对象的共性抽象v 类是一组客观对象的抽象v 实现抽象数据类型的工具 v 类与对象的关系v 抽象与具体的关系v 组成类的每个对象都是该类的实例 v 实例是类的具体事物 v 类是各个实例的综合抽象 面向对象概述 -面向对象的基本特征n 面向对象的基本特征n 抽象n 在某个重要的或想关注的方面来表示某个物体或概念 n 忽略主题中与当前目标无关的方面 n 封装n 把操作和数据包围起来，对数据的访问只通过已定义的接口来完成 n 继承n 类之间的“is a”或“is like”关系 n 类层次，定义一个新类，可以从现有的类中派生出来 n 子类可以从父类继承方法和属性 n 多态 n 不同类的对象可以对同一消息作出响应，执行不同的处理 面向对象概述 -面向对象开发的优点2. UML简介n Unified Modeling Languagen 近10多年来OOSE最重要的成果n 贡献者：Grady Booch， Ivar Jacobson，Jim Rumbaughn 中文网站n http:/www. umlchina.comn http:/www.uml.com.cnUML的组成n UML的模型元素n 表示模型中的某个概念n 类、对象、构件、用例、结点（node）、接口（interface）、包（package）和注释（note） n 表示模型元素之间的关系n 关联、泛化、依赖、实现、聚合和组合 n UML的元模型结构n 元元模型层n 元模型层n 模型层n 用户模型层UML的组成n 图n 静态图n 用例图、类图、对象图、构件图和部署图 n 动态图n 状态图、时序图、协作图和活动图 n 视图n 用例视图n 从用户的角度看到的系统应有的外部功能 n 逻辑视图n 描述系统的静态结构和对象间的动态协作关系 n 进程视图n 展示系统的动态行为及其并发性 n 构件视图n 展示系统实现的结构和行为特征 n 部署视图n 显示系统的实现环境和构件被部署到物理结构中的映射 UML的特点n 统一标准n 面向对象n 表达能力强大n 可视化UML的应用n 用于描述系统开发的不同类型于不同阶段n 从需求分析到软件设计到软件测试及维护n 可视化问题描述，帮助理解问题n 帮助建立各阶段的文档n 获取和交流有关应用问题求解的知识n 辅助构建系统3. 静态建模n 静态建模n 用例图、类图和对象图n 用例模型n 用例图表示n 从最终用户的角度描述系统功能n 类和对象模型n 类图和对象图表示用例图与用例模型n 用例图的组成符号建立用例图用例之间的关系n 扩展关系n 根据指定的条件，一个用例中有可能加入另一个用例的动作 n 包含关系n 一个用例的行为包含另一个用例的行为 类图Class Diagram对象图Object Diagram类图表示类间关系n 关联关系 (Association) n 类之间存在的语义上的关系n 普通关联、递归关联、多重关联等n 聚集关系(Aggregation) n 特殊的关联：整体-部分n 组合关系(Composition)n 特殊的聚集：整体强烈拥有部分n 泛化关系(Generalization) n 继承n 依赖关系(Dependency) n 对一个类/对象的修改会影响另一个类/对象关联关系聚集和组合泛化关系依赖关系约束与派生n 约束和派生机制能应用与任何模型元素 n 用花括号括起放在模型元素旁边 n 典型的属性约束是该属性的取值范围 n 派生属性可由其它属性通过某种方式计算得到，通常在派生属性前面加一个“/”表示 n 关联关系可以被约束，也可以被派生 包图4. 动态建模n 消息（Message）n 状态图（State Diagram）n 时序图（Sequence Diagram）n 协作图（Collaboration Diagram）n 活动图（Activity Diagram）消息状态图State Diagram状态图之间发送消息时序图（Sequence Diagram）协作图（Collaboration Diagram）活动图Activity Diagram5. 物理架构建模n 逻辑架构和物理架构n 逻辑架构n 物理架构n 构件图n 配置图构件图Component Diagram部署图Deployment Diagram6. UML 工具n Rational Rosen StarUML Rational RoseStarUML小结n 面向对象开发按人的思维方式来理解和解决问题，将问题空间的概念直接映射到解空间。面向对象的基本特征是抽象、封装、继承和多态。 n 作为一种著名的建模语言，UML用图从不同的视角为系统建模，形成为不同的视图；每个视图代表系统完整描述中的一个抽象，显示这个系统中的一个特定的方面；每个视图由一组图构成，其中包含了强调系统中某一方面的信息。 第5章 需求工程与需求分析n 软件需求过程n 需求分析与建模n 需求获取的常用方法n 需求模型n 软件需求描述n 需求管理n 需求建模示例1. 软件需求工程n 软件需求的定义n 一个软件系统必须遵循的条件或具备的能力 n 系统的外部行为 n 系统的内部特性 n 软件需求三个层次 n 业务需求n 用户需求n 功能需求 软件需求的层次关系软件需求的特性n 功能性n 可用性n 可靠性n 性能n 可支持性n 设计约束需求工程的由来n 代码编写-生存周期-需求工程n 软件需求工程n 可以定义为应用有效的技术和方法，合适的工具和符号，来确定、管理和描述目标系统及其外部行为特征的学科 2. 需求分析与建模n 需求分析的步骤n 需求分析是迭代过程3. 需求获取的常用方法n 常规的需求获取方法n 联合分析小组 n 用户代表、领域专家和系统分析员n 客户访谈 n 充分准备，寻找共同语言 n 循循序渐进、逐步逼近 n 问题分析与确认 n 多个来回3. 需求获取的常用方法n 用快速原型法获取需求n 利用各种分析技术和方法，生成一个简化的需求规格说明；n 对需求规格说明进行必要的检查和修改后，确定原型的软件结构、用户界面和数据结构等；n 在现有的工具和环境的帮助下快速生成可运行的软件原型并进行测试、改进；n 将原型提交给用户评估并征求用户的修改意见；n 重复上述过程，直到原型得到用户的认可。 4. 需求模型n 需求模型概述n 结构化需求模型n 面向对象需求模型n 面向对象的需求建模n 画用例图n 写用例规约n 描述补充规约n 编写术语表结构化需求模型面向对象需求模型用例建模n 确定参与者n 存在于系统外部、与系统交互的人、硬件、其他系统n 通过回答问题确定参与者n 系统开发完成之后，有哪些人会使用这个系统？ n 系统需要从哪些人或其他系统中获得数据？ n 系统会为哪些人或其他系统提供数据？ n 系统会与哪些其他系统相关联？ n 系统是由谁来维护和管理的？ 用例建模n 确定用例n 考察每个参与者与系统的交互和需要系统提供的服务n 通过回答问题确定用例n 参与者为什么要使用该系统？ n 参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？ n 参与者是否会将外部的某些事件通知给该系统？ n 系统是否会将内部的某些事件通知该参与者？用例建模n 绘制和检查用例图n 按UML标准画用例图n 检查用例图n 细化每个用例的用例规约n 内容包括：n 简要说明n 事件流n 特殊需求n 前置条件和后置条件n 用例模型的检查n 功能需求的完备性n 模型是否易于理解n 是否存在不一致性n 避免二义性语义用例建模示例n 选课系统问题陈述 开发一个学生选课系统。通过这个系统，学生可以选课和查看成绩报告单，教授可以选择所教的课和记录学生的成绩。学校保留原有的“课程目录”数据库系统来维护课程信息，但该系统的性能是有限的。所以新系统必须确保能及时访问旧系统上的数据。但新系统只能读取旧系统的课程信息，不能更新。每学期开始时，学生请求查看本学期开设的课程目录。有关课程的信息，包括教授名和所开设的系等，将帮助学生做出决定。系统允许学生每学期选择4门课，如果学生没有选到主要的课程，还有两门备选课程可选。每门课的学生人数限3到10人。不满3人的课程将被取消。另外，每个学期有一段时间让学生更改课程表。学生可在该时段内访问系统并添加/删除课程。某个学生的选课一旦结束，选课系统即将此学生本学期的账单信息送到财务系统。如果在选课时某门课已经人满，学生在提交信息前必须被告知。学期结束，学生可进入系统查看自己的成绩。成绩属于隐秘信息，系统必须提供额外的安全措施阻止未授权的访问。教授必须能访问系统查询他们主讲课程。他们也需要知道是哪些学生选择了自己的课程。另外，教授也能登记学生的成绩。用例建模示例n 确定参与者n 确定用例用例建模示例n 选课系统用例图用例建模示例选课用例规约1简要说明本用例允许学生选本学期提供的课程。在学期开始的添加/删除时期，学生可以修改或删除选择的课程。课程目录系统提供了当前学期开设的所有课程的列表。2事件流2.1基本事件流用例开始于学生选择选课，或修改已存在的课程表。1）系统要求学生指出要执行的操作（创建，修改或删除课程表）2）一旦学生提供了所需要的信息，以下的一条子事件流将被执行 如果选择的是“创建课程表”，创建课程表子事件流将被执行 如果选择的是“修改课程表”，修改课程表子事件流将被执行 如果选择的是“删除课程表”，删除课程表子事件流将被执行2.2备选事件流 。3特殊需求无4前置条件本用例开始前学生必须已经登录进系统。5后置条件如果用例成功，学生的课程表被创建，修改，删除。否则系统状态不变。 描述补充规约示例选课系统的补充规约1目标 本文档的目的是定义选课系统的需求。本补充规约列出了不便于在用例模型的用例中获取的系统需求。它和用例模型一起记录关于系统的一整套需求。2范围 本补充规约适用于选课系统，除定义了在许多用例中所共有的功能性需求以外，还定义了系统的非功能性需求，例如：可靠性、可用性、性能和可支持性等。（功能性需求在用例规约中定义。）3参考无4功能多个用户必须能同时执行操作。如果某个学生所建的课程表中包含人数已满的课程，必须通知这位学生。5可行性 桌面用户界面应与 Windows 98/2000/XP 兼容。6可靠性 选课系统在每周7天，每天24小时内都应是可用的。宕机的时间应少于 10%。7性能。术语表示例选课系统的术语表1.简介这份文档是用来对一些术语进行定义的，同时将用例说明或其他文档中读者不太熟悉的术语进行解释性的描述。通常来说，这份文档对一些数据信息进行一些定义，从而使得用例规约和其他的文档显得简洁易懂。2. 定义这份术语表包含了选课系统中核心概念的定义。课程：大学提供的某一门课。开设课程：某一课程的具体安排情况，包括一周上课的天数、时间和教授。课程目录：大学所开设的所有课程的完整目录。教员：所有在此大学内任教的教授。财务系统：用来处理收费信息的系统。成绩：学生某门课程的成绩。5. 软件需求描述n 软件需求规格说明书n Software Requirement Specificationn 引言n 信息描述n 功能描述n 行为描述n 质量保证n 接口描述n 其他6. 需求管理n 需求管理的特定实践n 需求管理的流程n 需求确认n 需求跟踪6. 需求管理n 需求变更控制n 需求变更的利弊n 需求变更的流程需求变更状态转换需求管理工具n IBM Rational RequisitePron Telelogic DOORSregn Borland CaliberRM7. 需求建模示例网上购物系统n 当今，网上购物已成为一种时尚。本示例作为WEB 应用的一例，主要为普通购物用户和管理员服务。n 普通购物用户在使用本系统的购物功能前，必须先注册账号。在注册页面中填写个人信息，如使用本系统的账号名和密码,联系地址等。在提交表单、完成注册后，系统将保存信息，以方便管理员管理用户信息、联系用户。n 如果用户已经在系统中注册过，可以在登录页面输入账号名和密码。如果密码正确，用户就可以购物，否则只能做一般的页面浏览。n 进入系统后，用户也可选择维护自己的信息，比如修改账号名，密码，联系地址等。如果直接进行购物，系统可让用户首先浏览商品信息，使之对商品的数量、种类有一个大概的了解。如果用户对某件商品感兴趣，就可以选择特定商品查看其详细信息，接着选择将商品加入购物车，或继续查看其他商品。当购物结束时，用户首先要浏览一下已经存在于购物车中的商品项目，包括数量、单价及总价。这时用户可以更改任何已存在购物车中的商品数量。如果确定要购买购物车内的商品，系统即生成一份订购商品的订单（包括所有商品的名字，单价，小计，总价），然后由用户填写包括用户姓名、家庭地址、信用卡号码、电子邮件地址等信息，并提交订单。以后，系统自动将用户信息、信用卡信息和购物总价发送到银联系统，由银联系统验证信用卡信息并执行扣款，并将银联系统操作成功与否的信息返回到系统。系统根据银联系统的操作结果，向用户发送E-MAIL，提示用户操作成功与否的消息。如果扣款成功，就与物流系统接口，安排给用户派送购买的商品。n 管理员进入系统时，首先要输入口令。如果检查通过，就可以对系统中的信息进行维护和管理，包括： 管理用户信息。当有些用户有不正常操作时，如填写订单时使用不存在的信用卡号，可以将此用户账号冻结，也可以启用用户账号。但管理员无权修改客户信息； 管理系统中的商品信息，例如有新的商品时，管理员可向系统中添加此商品。当商品的价格或规格发生浮动时，管理员也可以对它们作修改，使用户及时了解商品的最新情况。若某件商品没有存货或不再出售时，管理员可删除系统中的此项商品记录。 管理客户定单。及时获得客户的资料（资料中有电子邮件地址），以便与客户联系。n 要求系统对数据库的存取速度要尽量快，并保证系统在配置完成以后一天24小时都可用。还要求系统有较高的安全性，当生成订单时，用户的信用卡号码要在网上传输，所以必须提供额外的安全措施。用例模型用例模型n 用例规约n 补充规约n 术语表小结n 需求分析由需求获取、需求建模、规格说明和需求验证四个步骤组成n 建立需求模型是需求分析的核心，它通过各种图形及符号，可视化地从各个侧面描述系统需求n 需求规格说明书以各方共同认可的文档形式表述出来，是软件设计、系统验收的可靠依据n 面向对象的用例模型，由用例模型、补充规约和术语表一起组成n 随着人们对需求重要性的认识逐渐深入，软件需求管理应运而生 第6章 面向对象分析n 软件分析概述n 面向对象分析建模n 面向对象分析示例1. 软件分析概述n 软件需求与软件分析n 软件需求：用户角度，注重软件外在表现n 软件分析：开发者角度，注重软件内部逻辑结构n 面向对象软件分析n 面向对象分析模型面向对象软件分析n OOA的主要任务n 理解用户需求n 全面地理解和分析用户需求n 明确所开发的软件系统的职责n 形成文件并规范地加以表述 n 进行分析，提取类和对象，并结合分析进行建模 n OOA的模型n 需求模型n 类/对象模型n 对象-关系模型n 对象-行为模型面向对象分析模型面向对象分析n OOA的优点（1）同时加强了对问题域和软件系统的理解；（2）改进包括用户在内的与软件分析有关的各类人员之间的交流；（3）对需求的变化具有较强的适应性；（4）很好地支持软件复用；（5）确保从需求模型到设计模型的一致性。 n 分析模型的特点n 全面覆盖软件的功能需求 n 分析模型与软件的实现无关 n 分析模型的表述方法与所采用的分析技术有关 OOA的共同特征n 共同特征 n 类和类层次的表示n 建立对象-关系模型n 建立对象-行为模型 n OOA建模步骤 n 需求理解n 定义类和对象n 标识对象的属性和操作n 标识类的结构和层次n 建立对象-关系模型n 建立对象-行为模型n 评审OOA模型OOA模型在软件开发中的地位 2. 面向对象分析建模n 基于用例的面向对象分析方法 n 回顾需求阶段产生的用例规约，补充必要的详细信息；n 研究用例的事件流，将用例的职责分配给若干分析类；n 基于这些职责分配以及分析类之间的协作，即可开始为分析类间的关系建模了n 一旦分析了用例，就需要查看确定的类，确保它们被详尽地描述n 并确保分析模型各个部分之间的一致 识别与确定分析类n 三种分析类n 边界类 n 用户界面n 系统接口n 硬件接口n 控制类n 封装用例所特有的控制行为n 实体类n 系统存储的信息及其相关行为三种分析类查找分析类n 为每对参与者/用例确定一个边界类 查找分析类n 为每个用例设置一个控制类 查找分析类n 确定相关的各个实体（包括属性与方法） 建立对象行为模型 n 绘制出选课用例创建课表事件流的时序图 建立对象行为模型 n 绘制出选课用例创建课表事件流的协作图 建立对象行为模型 n 为分析类分配职责 建立对象行为模型 n 绘制状态图n 用例行为比较复杂，并且分散到不同的事件序列中，这时就需要为这个类创建一个状态图 n 针对一个类的状态变化n 研究该类的动态行为 建立对象关系模型 n 分析类的属性n 分析类本身具有的信息n 分析类的关联n 通过关联可以找到其他分析类n 链与关联的对应关系n 分析类图n 表现分析类及其关系n VOPCn 分析类的合并 n 每个分析类都代表一个明确定义的概念，具有不相重叠的职责 链与关联的对应关系选课用例的参与类图 分析类的合并 3. 面向对象分析示例 -注册用例3. 面向对象分析示例 -注册用例3. 面向对象分析示例 -注册用例3. 面向对象分析示例 -维护个人信息3. 面向对象分析示例 -维护个人信息3. 面向对象分析示例 -维护个人信息3. 面向对象分析示例 -维护购物车 3. 面向对象分析示例 -维护购物车 3. 面向对象分析示例 -维护购物车 3. 面向对象分析示例 -从购物车中删除商品 3. 面向对象分析示例 -修改购物车中的商品信息 3. 面向对象分析示例 -生成订单 3. 面向对象分析示例 -生成订单 3. 面向对象分析示例 -生成订单 3. 面向对象分析示例 -管理订单 3. 面向对象分析示例 -管理订单 3. 面向对象分析示例 -管理订单 3. 面向对象分析示例 -管理订单 3. 面向对象分析示例 -管理订单 3. 面向对象分析示例 -管理订单 3. 面向对象分析示例 -管理订单 小结n 软件分析将软件需求阶段产生的需求模型转变为软件分析模型。分析模型其实就是从软件开发者的角度，在静态组成结构和动态行为两个方面来描述的待开发的软件系统。n 面向对象分析利用面向对象的技术来分析问题、建立问题域的静态模型和动态模型，并用UML等工具来表示这一需求对应的类对象模型、对象-关系模型和对象-行为模型等，从而完成对问题域建模，形成面向对象的分析模型。n 软件分析通常从用例分析开始，建立系统需求的静态结构模型和动态行为模型。第7章 面向对象设计n 软件设计概述n 面向对象设计建模n 系统架构设计n 系统元素设计n 面向对象设计示例1. 软件设计概述n 软件设计的概念n 模块与构件n 抽象与细化n 信息隐藏n 软件复用n 软件设计的任务n 把分析阶段产生的分析模型转换为用适当手段表示的软件设计模型 n 软件设计一般都包括数据设计、体系结构设计、接口设计和过程设计等 模块化设计(modular design)n 分解（decomposition）n 模块独立性（module independence）n 自顶向下（topdown design）n 自底向上（bottomup design）分解（decomposition）C (P1+P2)C (P1)+C (P2)E (P1+P2)E (P1)+E (P2) C为问题的复杂度，E为解题需要的工作量 模块独立性（module independence）n 内聚（cohesion）n 模块内部各成分之间n 耦合（coupling）n 一个模块与其它模块之间n 模块的独立性高 n 块内联系强 n 块间联系弱 内聚内聚 cohesionn .偶然性内聚 coincidental cohesionn .逻辑性内聚 logical cohesionn .时间性内聚 temporal cohesionn .过程性内聚 procedural cohesionn .通讯性内聚 communicational cohesionn .顺序性内聚 sequential cohesionn .功能性内聚 functional cohesion逻辑性模块 耦合 coupling1.非直接耦合no direct coupling2.数据耦合data coupling3.特征耦合 stamp coupling4.控制耦合control coupling 5.外部耦合 external coupling6.公共耦合 common coupling7.内容耦合 content coupling弱耦合公共耦合2. 面向对象设计建模n 面向对象设计模型n 系统架构层n 类和对象层n 消息层n 责任层 n 面向对象设计的任务n 系统架构设计n 系统元素设计n 模式的应用n 模式是解决某一类问题的方法论，也是对通用问题的通用解决方案 n 软件模式可以分为架构模式、设计模式和习惯用法三种 OOA模型转换到OOD模型3. 系统架构设计n 系统高层结构设计n 确定设计元素n 任务管理策略n 分布式实现机制n 数据存储设计n 人机交互设计系统高层结构设计 n 应用架构模式 n 层次架构（Layers）n 模型-视图-控制架构（Model-View-Control）n 管道与过滤器架构（Pipes and Filters）n 黑板架构（Blackboard）n 典型的分层方法 确定设计元素 n 映射分析类到设计元素 n 一个分析类可以映射为一个设计类或多个设计类的组合,也可以将其映射为子系统接口 n 确定子系统 n 划分成几个子系统需根据实际情况来确n 确定子系统的一些指导性参考原则 n 定义子系统接口 n 为子系统确定一个备选接口集 n 寻找接口之间的相似点 n 定义接口依赖关系 n 将接口映射到子系统 n 定义接口所指定的行为 任务管理策略 n 对多用户、多任务的并行处理支持n 多处理器方案-将并发子系统分配到不同的处理器n 操作系统方案-将并发子系统分配到相同的处理器并由操作系统提供同步控制n 应用程序方案-应用软件负责在适当的时间从一个代码分支切换到另一个代码分支n 引进任务管理部件 n 基于进程和线程的控制 n 进程和线程建模n 确定进程的生命周期n 在进程间分布模型元素选课系统的进程建模创建进程和线程的时序图 设计元素与进程的关系 分布式实现机制n 确定网络拓扑配置n 将设计元素分配到网络节点n 节点容量（指内存量和处理能力） n 通信介质带宽（总线、LAN、WAN） n 硬件与通信链路的可用性、重选路由 n 对冗余与容错能力的要求n 响应时间要求n 吞吐量要求 n 设计分布处理机制 n 采用RMI实现分布处理机制n 引入可直接利用的类库 n 建立一些有role标识的类，代表实际设计元素 n 描述分布机制的静态结构 网络拓扑配置图 基于RMI的分布处理机制 数据存储设计 n 基于JDBC的数据存储机制n 引入JDBC相关类库 （java.sql包中的类 ）n 构造一些具有role标识的类，代表际设计元素 n 描述持久存储机制的静态结构 n 描述机制的典型应用场景 持久存储机制的静态结构 初始化与数据库的连接 创建PersistentClass的实例 人机交互设计 n 分类分析用户特点，设计不同界面 n 增加用户界面专用的类与对象 n 利用快速原型演示，改进界面设计 4. 系统元素设计 n 子系统设计 n 将子系统行为分配给子系统元素 n 描述子系统元素 n 说明子系统的依赖关系 n 分包设计 n 分包的原则 n 描述包之间的依赖关系 n 包之间的耦合关系 n 类/对象设计课程目录子系统时序图 课程目录子系统内部类图 子系统间依赖关系 包的依赖关系 University Artifacts包内元素的类图 类/对象设计n 设计初始类n 设计边界类、实体类、控制类n 定义操作n 研究每个类的职责，为职责确定操作n 增加一些典型的操作n 定义方法n 方法是对操作的实现n 定义状态n 可以创建状态图n 定义属性n 定义依赖关系n 定义关联关系n 定义泛化关系n 处理非功能需求类的重新设计 定义操作的类图 开设课程类的状态图 标明属性的类图 定义依赖关系的类图 5.面向对象设计示例 n 关联关系具体化组合关系、依赖关系网上购物系统的架构设计 n 各层分析n 数据访问层n 业务逻辑层n 表现层n 架构模式n MVC模式网上购物系统的类/对象设计 -注册网上购物系统的类/对象设计 -维护个人信息网上购物系统的类/对象设计 -维护购物车网上购物系统的类/对象设计 -生成订单网上购物系统的类/对象设计 -管理订单小结n 软件设计的任务，是将分析阶段建立的分析模型转变为软件设计模型，确保最终能平滑地过渡到程序代码。n OOD的软件设计也分为两个层次：系统架构设计和系统元素设计。n 系统架构设计是指确定系统主要组成元素的组织或结构，组成元素之间通过接口进行交互，以及其它全局性决策；系统元素设计是对每一个设计元素进行详细的设计，系统元素包括组成系统的类、子系统与接口、分包等。第八章 编码和测试n 编码概述n 编码语言与编码工具n 编码示例 n 测试的基本概念n 黑盒测试和白盒测试n 测试用例设计n 多模块程序的测试策略n 面向对象系统的测试1. 编码概述n 编码的目的 编码设计模型-源程序-可执行代码(不可执行的) (可执行的)n 编码的过程 n 熟悉所选语言的功能和程序开发环境 n 仔细阅读设计模型 n 弄清要编码的模块的外部接口与内部过程 编码的风格n 追求“聪明”