1、 软件工程-原理、方法与应用原理、方法与应用（第三版）（第三版）主要内容v 绪论v 上篇-传统软件工程v 软件生存周期与软件过程v 结构化分析与设计v 中篇-面向对象软件工程v 面向对象与UMLv 需求工程与需求分析v 面向对象分析v 面向对象设计v 编码与测试v 下篇-软件工程的近期进展、管理与环境v 软件维护v 软件复用v 软件工程管理v 软件质量管理v 软件工程环境v 软件工程高级课题第一章 绪论 软件危机的表现软件危机的表现对软件开发成本和进度的估算很不准确对软件开发成本和进度的估算很不准确用户很不满意用户很不满意质量很不可靠质量很不可靠没有适当的文档没有适当的文档软件成本比重上升软件
2、成本比重上升供不应求：软件开发生产率跟不上计算机应用供不应求：软件开发生产率跟不上计算机应用迅速深入的趋势迅速深入的趋势 硬件/软件成本变化趋势硬件软件100%0%195519701985软件技术进步落后于需求增长软件危机的原因软件危机的原因客观：软件本身特点客观：软件本身特点-逻辑部件-规模庞大、复杂度高主观：不正确的开发方法主观：不正确的开发方法-忽视需求分析-个人化方式：软件开发=程序编写-轻视软件维护解决途径解决途径组织管理组织管理-工程项目管理方法技术措施技术措施-软件开发技术与方法-软件工具 促使了软件工程的诞生促使了软件工程的诞生 按是软件开发中的问题一个主要出路软件开发技术软件
3、开发技术软件工程管理软件工程管理软件工程学软件工程学软件工程学的研究范畴软件工程学的研究范畴软件方法软件方法软件工具软件工具软件工程环境软件工程环境软件管理学软件管理学软件经济学软件经济学软件产权保护软件产权保护过程式和面向对象的编程范型存款取款利息结算帐户余额帐户余额利息结算存 款取 款银行储蓄处理业务 传统软件工程 结构化分析 结构化设计 面向过程的编码 软件测试 面向对象软件工程 OO分析与对象抽取 对象详细设计 面向对象的编码 和测试 基于构件的软件工程 领域分析和测试计划定制 领域设计 建立可复用构件库 查找并集成构件 4.软件工程的应用软件工程的应用 软件工程指导中小型软件 软件工
4、程指导大型软件 软件工程的成就 解决软件开发中的部分问题（非本质）软件生产率稳步增长 软件工程发展的展望 开发伴随软件复用，开发为了软件复用 软件就是服务5.软件工程的教学软件工程的教学 正确处理好4个关系 三代软件工程的相互关系 软件工程技术和软件工程管理的关系 形式化方法和非形式化方法的关系 小程序设计和大程序设计的关系 教学中加强实践训练小结 软件工程自软件工程自1968年提出以来，在过去年提出以来，在过去30余年中，已发展成余年中，已发展成为用于指导软件生产工程化，覆盖软件开发方法学、软件为用于指导软件生产工程化，覆盖软件开发方法学、软件工程管理、软件工具与环境等内容的一门新学科。工程
5、管理、软件工具与环境等内容的一门新学科。随着程序设计从结构化程序设计发展到面向对象程序设计，随着程序设计从结构化程序设计发展到面向对象程序设计，软件工程也由传统的软件工程演变为面向软件工程也由传统的软件工程演变为面向 对象的软件工程，对象的软件工程，现正向更新一代的基于构件的软件工程迈进。现正向更新一代的基于构件的软件工程迈进。长期的实践，软件工程积累了许多行之有效的原理与方法，长期的实践，软件工程积累了许多行之有效的原理与方法，已经为产业界广泛接受与应用。已经为产业界广泛接受与应用。第二章 软件生存周期与软件过程p软件生存周期软件生存周期p传统的软件过程传统的软件过程p软件演化模型软件演化模
6、型p形式化方法模型形式化方法模型p统一过程和敏捷过程统一过程和敏捷过程p软件可行性研究软件可行性研究1.软件生存周期 软件生存周期软件生存周期（Software Life Cycle）：一个软件项目）：一个软件项目从问题提出开始，直到软件产品最终退役（废弃不用）从问题提出开始，直到软件产品最终退役（废弃不用）为止。为止。软件生存周期分为三个时期：软件生存周期分为三个时期：计划计划、开发开发和和维护维护 整个软件生存周期划分为多个相对独立的较小整个软件生存周期划分为多个相对独立的较小阶段阶段，给，给每个阶段赋予确定而有限的任务，从而降低了整个软件每个阶段赋予确定而有限的任务，从而降低了整个软件工
7、程的难度，提高了软件开发生产率工程的难度，提高了软件开发生产率典型的软件生存周期需求分析软件分析软件设计编码（测试）交付测试使用维护典型的软件生存周期软件生存周期的主要活动需求分析 明确需要解决的问题（从用户的视角）建立需求模型：功能、性能、约束、接口等软件分析 从开发人员的视角对软件进行分析 建立分析模型：软件的逻辑模型软件设计 确定软件的总体结构和各部件的数据结构和操作 建立软件设计模型：考虑实现技术和平台编码 用程序设计语言将设计文档翻译成源程序 建立软件实现模型：包含现有软件构件包软件测试 发现程序中的错误、提高软件质量 单元测试、集成测试、确认测试、系统测试运行维护软件过程与软件生存
8、周期 软件过程软件过程 围绕软件开发所进行的一系列活动围绕软件开发所进行的一系列活动 软件过程模型软件过程模型 把软件生存周期中软件开发活动的有序流程用一个合把软件生存周期中软件开发活动的有序流程用一个合理的框架来规范描述。理的框架来规范描述。软件过程模型是一种软件过程的抽象表示法，它从一软件过程模型是一种软件过程的抽象表示法，它从一个特定的角度表现一个开发过程。个特定的角度表现一个开发过程。软件生存周期中的阶段和软件过程中的活动是基软件生存周期中的阶段和软件过程中的活动是基本一致的。本一致的。2.传统的软件过程 传统的过程模型 瀑布模型 waterfall model 基于软件生存周期的线性
9、开发模型 快速原型模型 rapid prototype model 基于原型的迭代化开发模型瀑布模型图2.2 瀑布模型的阶段与文档需求分析需求规格说明软件分析与总体设计软件结构图模块说明系统测试确认测试综合测试程序清单详细设计编 码用户要求单元测试nW.Royce于1970年提出n线性开发模型n强调软件文档每一个阶段必须完成规定的文档每一个阶段都要复审完成的文档瀑布模型 特点 阶段的顺序性和依赖性 推迟实现的观点 质量保证的观点 存在问题 不适合需求模糊的系统 开发初始阶段很难彻底弄清软件需求快速原型模型需求原型开发最终系统设计原型评价最终系统实现用户反馈快速原型模型 特点“逼真”的原型可以使
10、用户迅速作出反馈 循环回溯和迭代：非线性模型 使用快速开发工具 种类 渐进型：对原型补充和修改获得最终系统 抛弃型：原型废弃不用 应防止的偏向 舍不得抛弃，从而影响软件质量3.软件演化模型 演化开发模型：使所开发的软件在迭代中逐步完善 增量模型（incremental model）螺旋模型（spiral model）构件集成模型（component integration model）增量模型把软件看作一系列相互联系的增量，每次迭代完成一个增量把软件看作一系列相互联系的增量，每次迭代完成一个增量构件1：需求设计实现和集成交付客户构件2：需求设计实现和集成交付客户构件3：需求设计实现和集成交付客
11、户构件n：需求设计实现和集成交付客户规格说明组设计组实现和集成组增量模型 增量 小而可用的软件 第一个增量通常是软件的核心 特点 在前面增量的基础上开发后面的增量 每个增量的开发可用瀑布或快速原型模型 每个增量开发的顺序性和总体的迭代性相结合螺旋模型螺旋模型 特点 瀑布模型（顺序性、边开发边复审）+快速原型（迭代性）风险分析-发现、控制风险 一个螺旋式周期 计划：确定目标，选择方案，选定完成目标的策略 风险分析：从风险角度分析该策略 开发：启动一个开发活动 评审：评价前一步的结果，计划下一轮的工作 面向对象的基本概念 对象Object 类Class 继承Inheritance 消息Messag
12、e 面向对象 对象+类+继承+消息通信构件集成模型构件集成模型 构件 在某个领域内具有通用性，可以复用的软件部件 将可以复用的构件存储起来，形成构件库构件库 特点 面向对象 基于构件库 融合螺旋模型特征 支持软件开发的迭代方法 软件复用4.形式化方法模型 形式化方法模型：基于程序变换和验证技术的软件开发 转换模型（transformational model）净室模型（cleanroommodel）转换模型形式化规格说明与 需 求比 较 后修正变换2变换1变换n测试形式化开发记录系统需求目标系统转换模型 开发过程 确定形式化需求规格说明书 进行自动的程序变换 针对形式化开发记录进行测试 特点
13、形式化软件开发方法 形式化需求规格说明 变换技术 程序自动生成技术 确保正确净室模型需求收集盒结构规约形式化设计统计性使用测试正确性证明代码生成与检查测试计划认证需求收集盒结构规约形式化设计统计性使用测试正确性证明代码生成与检查测试计划认证需求收集盒结构规约形式化设计统计性使用测试正确性证明代码生成与检查测试计划认证增量1增量2增量n净室模型 净室思想 在分析和设计阶段消除错误 在“洁净”状态下实现软件制作 形式化 盒结构表示分析和设计 正确性验证 增量模型 把软件看成一系列的增量软件过程模型的特点汇总开发模型开发模型特特 点点适用场合适用场合瀑布模型线性模型，每一阶段必须完成规定的文档需求明
14、确的中、小型软件开发快速原型模型用户介入早，通过迭代完善用户需求，原型废弃不用需求模糊的小型软件开发增量模型每次迭代完成一个增量，可用于OO开发容易分块的大型软件开发螺旋模型典型迭代模型，重视风险分析，可用于OO开发具有不确定性大型软件开发构件集成模型软件开发与构件开发平行进行领域工程、行业的中型软件开发转换模型形式化的规格说明，自动的程序变换系统理想化模型，尚无成熟工具支持净室模型形式化的增量开发模型，在洁净状态下实现软件制作开发团队熟悉形式化方法，中小型软件开发5.统一过程和敏捷过程 统一过程 Rational Unified Process（RUP）描述了软件开发中各个环节应该做什么、怎
15、么做、什么时候做以及为什么要做，描述了一组以某种顺序完成的活动 敏捷过程 Agile Development是一种以人为核心、迭代、循序渐进的开发方法，其软件开发过程称为“敏捷过程”RUPRational Unified Process 将软件开发分为四个阶段：先启先启 定义整个项目的范围 精化精化 制定项目计划、描述功能、建立体系架构框架 构建构建 构造软件产品 迁移迁移 将软件产品移交到最终用户手中敏捷过程敏捷开发的价值观个人和交互胜过过程和工具 可以运行的软件胜过面面俱到的文档 客户合作胜过合同谈判 响应变化胜过遵循计划敏捷开发的12条原则尽早、不断地提交有价值的软件 允许改变需求，利用
16、变化来为客户创造优势尽快、不断地提交可运行的软件在业务人员和开发人员必须天天都在一起工作以积极向上的员工为中心建立项目组，提供环境和支持，并信任他们的工作在团队内部重视面对面的交流依据可运行软件来评估项目的进展提倡可持续的开发时刻关注技术上的精益求精和好的设计，以增强敏捷能力简单是最根本的最好的构架、需求和设计出于自组织团队每隔一定时间，要反省如何才能更有效地工作，然后作相应调整 极限编程 eXtreme Programming是一种轻量级的、敏捷的软件开发方法 4个价值观 交流、简单、反馈、勇气 4个方面改善 加强交流、从简单做起、寻求反馈、勇于实事就是 12个核心实践 完整团队、计划对策、
17、测试、简单设计、结对编程、小软件版本、设计改进、持续集成、代码共有、编码标准、系统比喻、可持续的速度6.软件可行性研究 目的 研究项目是否可能实现和值得进行 回答 Why to do?研究的内容 经济可行性 技术可行性 运行可行性 法律可行性可行性研究的步骤 对当前系统进行调查和研究 弄清当前系统 导出新系统逻辑模型 导出新系统的解决方案 设计不同的解决方案 提出推荐的方案 本项目的开发价值 推荐这个方案的理由 编写可行性认证报告 系统概述 可行性分析 结论意见软件风险分析 风险识别 项目风险 技术风险 商业风险 风险预测 风险发生的可能性 风险发生后的后果 风险的驾驭和监控小结 随着软件工程
18、的发展，许多学者先后提出了瀑布模型、快速原型模型、增量模型、螺旋模型、转换模型、净室模型和构件集成等多种过程模型，各种软件开发模型各有优缺点 在选定软件开发过程时，开发者不仅应该了解开发过程的特点，还应该结合待开发系统的特点一起考虑。如有必要，也可以同时组合多种模型或创建新的模型。第三章 结构化分析与设计概述概述结构化结构化系统分析系统分析结构化系统设计结构化系统设计模块化设计模块化设计1.概述概述 -结构化分析与设计的由来结构化分析与设计的由来 结构化分析与设计最初系由结构化程序设计扩展而来 瀑布模型的首次实践瀑布模型的首次实践 SA与与SD的流程的流程 结构化分析（工具：DFD、PSPEC
19、）分析模型（分层DFD图）+SRS 结构化设计（工具：SC图）映射 初始设计模型（初始SC图）初始设计模型（初始SC图）优化 最终设计模型（最终SC图）基本任务与指导思想基本任务与指导思想 结构化分析 建立分析模型 编写需求说明 结构化设计 软件设计=总体设计+详细设计 SC图须分两步完成 1.概述概述 -结构化分析与设计的由来结构化分析与设计的由来 结构化分析与设计最初系由结构化程序设计扩展而来 瀑布模型的首次实践瀑布模型的首次实践 SA与与SD的流程的流程 结构化分析（工具：DFD、PSPEC）分析模型（分层DFD图）+SRS 结构化设计（工具：SC图）映射 初始设计模型（初始SC图）初始
20、设计模型（初始SC图）优化 最终设计模型（最终SC图）基本任务与指导思想基本任务与指导思想 结构化分析 建立分析模型 编写需求说明 结构化设计 软件设计=总体设计+详细设计 SC图须分两步完成 1.概述概述 -SA模型的组成与描述模型的组成与描述 加工说明数据对象说明STD图DFD图E-R图DD控制说明（CSPEC）SA模型的描述工具：DFD、DD和PSPEC：这是早期SA模型的基本组成部分；CFD、CSPEC和STD：是早期SA模型的扩展成分，适应实时软件的建模需要；E-R图：适用于描述具有复杂数据结构的软件数据模型；结构化分析模型的描述工具结构化分析模型的描述工具 数据流图数据流图（DFD
21、）指明数据在系统中移动时如何被变换，描述对数据流进行变指明数据在系统中移动时如何被变换，描述对数据流进行变换的功能和子功能。换的功能和子功能。组成符号组成符号 圆框代表加工；圆框代表加工；箭头代表数据的流向，数据名称总是标在箭头的边上；箭头代表数据的流向，数据名称总是标在箭头的边上；方框表示数据的源点和终点；方框表示数据的源点和终点；双杠（或单杠）表示数据文件或数据库双杠（或单杠）表示数据文件或数据库 数据字典数据字典（DD）对软件中的每个数据规定一个定义条目。对软件中的每个数据规定一个定义条目。加工说明加工说明（PSPEC）对数据流图中出现的每个加工对数据流图中出现的每个加工/处理的功能描述
22、处理的功能描述 主要工具：结构化语言，判定树或判定表主要工具：结构化语言，判定树或判定表1.概述概述 -SD模型的组成与描述模型的组成与描述 过程设计接口设计体系结构设计数据设计SD模型的组成包含数据设计数据设计、体体系结构设计系结构设计、接口接口设计设计与过程设计过程设计。体系结构设计是用来确定软件结构的，其描述工具为结构结构图图，简称SC图图。过程设计过程设计主要指模块内部的详细设计 结构化设计模型的描述工具结构化设计模型的描述工具 SC图的组成符号 矩形框矩形框来表示模块，带箭头的连线带箭头的连线表示模块间的调用，并在调用线的两旁标出传入和传出模块的数据数据流流 ABCDABCABC（a
23、）简单调用 （b）选择调用 （c）循环调用 SC图中模块调用关系的表示2.结构化系统分析结构化系统分析 T.DeMarco的定义 结构化分析就是使用DFD、DD、结构化英语、判定表和判定树等工具，来建立一种新的、称为结构化说明书的目标文档 结构化分析的基本步骤 由顶向下对系统进行功能分解，画出分层DFD图 由后向前定义系统的数据和加工，编制DD和PSPEC 最终写出SRS 2.结构化系统分析结构化系统分析 -画分层数据流图画分层数据流图 教材购销系统的顶层DFD 学生教材购销系统书 库保 管员2.结构化系统分析结构化系统分析 -画分层数据流图画分层数据流图 教材购销系统的第二层DFD 领书单
24、进书通知 进书通知 购书单缺书单 1销售 2采购书库保管员学生F1教材存量表 F2缺书登记表 2.结构化系统分析结构化系统分析 -画分层数据流图画分层数据流图 教材购销系统的第三层DFD采购子系统.修改教材库存和待购量.按书号汇总缺书.按出版社统计缺书销售书库保管员F2缺书登记表 F1教材存量表 F5待购教材表 F6教材一览表 进书通知 进书通知 缺书单 从数据的终点开始定义数据和加工 数据定义DD 例如：发票 发票 学号姓名书号单价数量总价书费合计 加工策略PSPEC 分层DFD图产生了系统的全部数据和加工，通过对这些数据和加工的定义，常常对分析员提出一些新问题，促使新的调查和思考，并可能导
25、致对DFD的修改。画DFD，定义加工和数据，再画，再定义，如此循环，直至产生一个为用户和分析员一致同意的文档SRS。2.结构化系统分析结构化系统分析 -确定数据定义与加工策略确定数据定义与加工策略 复审人员 用户和系统分析员共同进行复审，并吸收设计人员参加 复审的重点 尽量多地发现文档中存在的矛盾、冗余与遗漏，尽可能确保DFD、DD、加工说明等文档的完整性、一改性和易读性，2.结构化系统分析结构化系统分析 -需求分析的复审需求分析的复审 3.结构化系统设计结构化系统设计 SD概述概述 面向数据流设计和面向数据设计面向数据流设计和面向数据设计 面向数据流：数据流是考虑一切问题的出发点 面向数据：
26、以数据结构作为分析与设计的基础 从分析模型导出设计模型从分析模型导出设计模型 结构化设计的描述工具：结构化设计的描述工具：SC图图 从分析模型导出设计模型从分析模型导出设计模型PSPEC数据对象描述CFDDFDE-RDDCSPEC过程设计 接口设计体系结构设计数据设计数据流图的类型数据流图的类型 数据流图的类型数据流图的类型 变换（变换（transform）型结构）型结构 传入路径 变换中心 传出路径 事务（事务（transaction）型结构）型结构 一条接受路径 一个事务中心 若干条动作路径 变换结构的DFD变换中心传入传出信息传入流传出流 变换流时间事务型结构DFD事务中心接受路径动作路
27、径同时存在两类结构T传入变换传出事务中心SD方法的步骤方法的步骤 SD方法的步骤方法的步骤 复审DFD图，必要时可再次进行修改或细化 鉴别DFD图所表示的软件系统的结构特征，确定它所代表的软件结构是属于变换型还是事务型 按照SD方法规定的一组规则，把DFD图为初始的SC图 变换映射 变换型DFD图 初始SC图 事务映射 事务型DFD图 初始SC图 按照优化设计的指导原则改进初始的SC图，获得最终SC图变换映射变换映射 划分DFD图的边界 建立初始SC图的框架 顶层都只含一个用于控制的主模块 第一层包括传入、传出和中心变换三个模块 分解SC图的各个分支 分解实质上是“映射”例子划分DFDPEDC
28、BAWRUVQabcdeprwuv传入部分变换中心传出部分第一级分解MEMTMCMAc,ec,eu,wu,w传入分支的分解GetEAtoBReadDDtoEReadABtoCGetBGetC MAc,ecebbcaabddb传出分支的分解 WriteW UtoV Write V PutU MEw,uwuuvv变换中心的分解 MT R P Qepc,prrw,u初始SC图 MC MT Q P R MEWriteW PutU Uto VWriteV A toBReadA GetB DtoER e a d D BtoC GetC Get E MA事务映射事务映射 在DFD图上确定边界 事务中心 接受
29、部分（包括接受路径）发送部分（包括全部动作路径）画出SC图框架 DFD图的三个部分分别映射为事务控制模块，接受模块和动作发送模块 分解和细化接受分支和发送分支 例子划分DFD传入 T变换传出接受部分事务中心动作部分第一层分解发送事务控制接收顶层第一层混合结构C1AC3BC2DLFGEKJabb1b2b3c1c2c3defghjklm优化结构设计的指导规则优化结构设计的指导规则 对模块划分的指导规则 提高内聚，降低耦合后 简化模块接口 少用全局性数据和控制型信息 保持高扇入/低扇出的原则 扇入高则上级模块多，能够增加模块的利用率 扇出低则表示下级模块少，可以减少模块调用和控制的复杂度 扇入和扇出
30、MM M的扇入M的扇出例子：扇出计算实发工资取得工资数据编外人员扣款编外人员工资编外人员税收薪金制工资额计时制工资额常规扣款税收扣款煎饼形结构不可取！例子：扇出常规扣款编外人员实发工资 计算实发工资取得工资数据计时工人实发工资计薪工人实发工资编外人员扣款编外人员税收编外人员工资税收扣款计时制工资额薪金制工资额塔型结构4.模块设计模块设计 模块设计也称详细设计 目的 为SC图中的每个模块确定算法和数据结构，用选定的表达工具给出清晰的描述 主要任务 编写软件的“模块设计说明书”模块设计的原则与方法模块设计的原则与方法 清晰第一的设计风格清晰第一的设计风格 结构化的控制结构结构化的控制结构 仅用这三
31、种控制结构来构成程序 每个控制结构只应有一个入口和一个出口 逐步细化的实现方法逐步细化的实现方法 常用的表达工具常用的表达工具 流程图流程图 NS图图 伪代码伪代码 PDL语言语言N-S图 S1 S2顺序 C T FS1 S2 选择While C S S Until C 循环小结 讨论传统软件工程的系统开发技术，重点放在基于瀑布模型的结构化分析与设计和模块设计上，但不涉及同为传统软件工程的快速原型开发等内容。全章以实例（从“教材销售”到“教材购销”）为主线，依次展示了结构化分析、结构化设计和模块设计的常用技术。第四章 面向对象与UML面向对象概述UML简介静态建模动态建模物理架构建模UML工具
32、 v实例是类的具体事物 v类是各个实例的综合抽象 面向对象的基本特征 面向对象的基本特征 抽象 在某个重要的或想关注的方面来表示某个物体或概念 忽略主题中与当前目标无关的方面 封装 把操作和数据包围起来，对数据的访问只通过已定义的接口来完成 继承 类之间的“is a”或“is like”关系 类层次，定义一个新类，可以从现有的类中派生出来 子类可以从父类继承方法和属性 多态 不同类的对象可以对同一消息作出响应，执行不同的处理 面向对象符合人类习惯的思维方式 OO开发的优点 提高软件系统的可复用性 提高软件系统的可扩展性 提高软件系统的可维护性 面向对象开发的优点2.UML简介 Unified
33、Modeling Language 近10多年来OOSE最重要的成果 贡献者：Grady Booch，Ivar Jacobson，Jim Rumbaugh 中文网站 http:/ http:/UML的组成 UML的模型元素 表示模型中的某个概念 类、对象、构件、用例、结点（node）、接口（interface）、包（package）和注释（note）表示模型元素之间的关系 关联、泛化、依赖、实现、聚合和组合 UML的元模型结构 元元模型层 元模型层 模型层 用户模型层用户模型元模型模型元元模型UML的组成图 静态图 用例图、类图、对象图、构件图和部署图 动态图 状态图、时序图、协作图和活动图
34、视图 用例视图 从用户的角度看到的系统应有的外部功能 逻辑视图 描述系统的静态结构和对象间的动态协作关系 进程视图 展示系统的动态行为及其并发性 构件视图 展示系统实现的结构和行为特征 部署视图 显示系统的实现环境和构件被部署到物理结构中的映射 UML的特点 统一标准 面向对象 表达能力强大 可视化UML的应用 用于描述系统开发的不同类型于不同阶段 从需求分析到软件设计到软件测试及维护 可视化问题描述，帮助理解问题 帮助建立各阶段的文档 获取和交流有关应用问题求解的知识 辅助构建系统3.静态建模 静态建模 用例图、类图和对象图 用例模型 用例图表示 从最终用户的角度描述系统功能 类和对象模型
35、类图和对象图表示用例图与用例模型 用例图的组成符号系统名称系统边界用例名用例参与者关联建立用例图保险商务系统签定保险单销售统计客户统计客户保险销售员用例之间的关系 扩展关系 根据指定的条件，一个用例中有可能加入另一个用例的动作 包含关系 一个用例的行为包含另一个用例的行为 扩展签保险单签汽车购买合同使用使用签保险单签汽车保险单签房屋保险单类图Class Diagram学生姓名:string学号:string书书名:string价格:real 1 购买 0.*属于对象图Object Diagram王平：学生姓名:王平学号:020106英语：书书名:英语价格:26.5数学：书书名:数学价格:21.
36、8类图表示类间关系 关联关系(Association)类之间存在的语义上的关系 普通关联、递归关联、多重关联等 聚集关系(Aggregation)特殊的关联：整体-部分 组合关系(Composition)特殊的聚集：整体强烈拥有部分 泛化关系(Generalization)继承 依赖关系(Dependency)对一个类/对象的修改会影响另一个类/对象关联关系1.*工人管理老板0.1员工递归关联 机器工人产品三重关联 聚集和组合成员课题组个人聚集关系窗口标题外框显示区组合关系泛化关系交通工具abstract船车轿车卡车客车依赖关系类B类A约束与派生 约束和派生机制能应用与任何模型元素 用花括号括
37、起放在模型元素旁边 典型的属性约束是该属性的取值范围 派生属性可由其它属性通过某种方式计算得到，通常在派生属性前面加一个“/”表示 关联关系可以被约束，也可以被派生 包图子系统A子系统D子系统B子系统C子系统E子系统F4.动态建模 消息（Message）状态图（State Diagram）时序图（Sequence Diagram）协作图（Collaboration Diagram）活动图（Activity Diagram）消息同步消息异步消息简单消息状态图State Diagram超时到达下楼上楼到达上楼到达在底楼向上移动向底楼移动向下移动空闲状态图之间发送消息Off()play()stop(
38、)On()CD机Off()/stop()stop()Off()On()stop()play()On()Off()遥控器关开关 开/停止开/播放play()时序图（Sequence Diagram）打印机忙保存文件打印机就绪打印文件打印文件打印文件计算机打印服务器打印队列打印机协作图（Collaboration Diagram）打印机忙2.2：保存文件打印机就绪2.1：打印文件1：打印文件计算机打印队列打印服务器打印机活动图Activity Diagram购买处理顾客 销售部门 处理销售支付货款库存处理发送商品收取商品水未开水开了打开信号接通电源加热显示灯亮水壶断电5.物理架构建模 逻辑架构和物
39、理架构 逻辑架构 物理架构 构件图 配置图构件图Component Diagram部署图Deployment Diagram6.UML 工具 Rational Rose StarUML Rational RoseStarUML小结 面向对象开发按人的思维方式来理解和解决问题，将问题空间的概念直接映射到解空间。面向对象的基本特征是抽象、封装、继承和多态。作为一种著名的建模语言，UML用图从不同的视角为系统建模，形成为不同的视图；每个视图代表系统完整描述中的一个抽象，显示这个系统中的一个特定的方面；每个视图由一组图构成，其中包含了强调系统中某一方面的信息。第5章 需求工程与需求分析 软件需求过程
40、需求分析与建模 需求获取的常用方法 需求模型 软件需求描述 需求管理 需求建模示例1.软件需求工程 软件需求的定义 一个软件系统必须遵循的条件或具备的能力 系统的外部行为 系统的内部特性 软件需求三个层次 业务需求 用户需求 功能需求 软件需求的层次关系业务需求项目愿景与范围用户需求质量属性用例模型文档功能需求非功能需求和约束条件软件需求规格说明软件需求的特性 功能性 可用性 可靠性 性能 可支持性 设计约束需求工程的由来 代码编写-生存周期-需求工程 软件需求工程 可以定义为应用有效的技术和方法，合适的工具和符号，来确定、管理和描述目标系统及其外部行为特征的学科 2.需求分析与建模 需求分析
41、的步骤 需求分析是迭代过程需求获取需求建模规格说明需求验证3.需求获取的常用方法 常规的需求获取方法 联合分析小组 用户代表、领域专家和系统分析员 客户访谈 充分准备，寻找共同语言 循循序渐进、逐步逼近 问题分析与确认 多个来回3.需求获取的常用方法 用快速原型法获取需求 利用各种分析技术和方法，生成一个简化的需求规格说明；对需求规格说明进行必要的检查和修改后，确定原型的软件结构、用户界面和数据结构等；在现有的工具和环境的帮助下快速生成可运行的软件原型并进行测试、改进；将原型提交给用户评估并征求用户的修改意见；重复上述过程，直到原型得到用户的认可。4.需求模型 需求模型概述 结构化需求模型 面
42、向对象需求模型 面向对象的需求建模 画用例图 写用例规约 描述补充规约 编写术语表结构化需求模型数据字典数据流图判定树判定表PDL加工说明数据定义.E-R图行为模型状态转换图控制流图和控制说明功能模型数据模型面向对象需求模型用例规约参与者用例图用例模型补充规约术语表全局性功能、非功能需求用例建模 确定参与者 存在于系统外部、与系统交互的人、硬件、其他系统 通过回答问题确定参与者 系统开发完成之后，有哪些人会使用这个系统？系统需要从哪些人或其他系统中获得数据？系统会为哪些人或其他系统提供数据？系统会与哪些其他系统相关联？系统是由谁来维护和管理的？用例建模 确定用例 考察每个参与者与系统的交互和需
43、要系统提供的服务 通过回答问题确定用例 参与者为什么要使用该系统？参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？参与者是否会将外部的某些事件通知给该系统？系统是否会将内部的某些事件通知该参与者？用例建模 绘制和检查用例图 按UML标准画用例图 检查用例图 细化每个用例的用例规约 内容包括：简要说明 事件流 特殊需求 前置条件和后置条件 用例模型的检查 功能需求的完备性 模型是否易于理解 是否存在不一致性 避免二义性语义用例建模示例选课系统问题陈述选课系统问题陈述 开发一个学生选课系统。通过这个系统，学生可以选课和查看成绩报告单，教授可以选择所
44、教的课和记录学生的成绩。学校保留原有的“课程目录”数据库系统来维护课程信息，但该系统的性能是有限的。所以新系统必须确保能及时访问旧系统上的数据。但新系统只能读取旧系统的课程信息，不能更新。每学期开始时，学生请求查看本学期开设的课程目录。有关课程的信息，包括教授名和所开设的系等，将帮助学生做出决定。系统允许学生每学期选择4门课，如果学生没有选到主要的课程，还有两门备选课程可选。每门课的学生人数限3到10人。不满3人的课程将被取消。另外，每个学期有一段时间让学生更改课程表。学生可在该时段内访问系统并添加/删除课程。某个学生的选课一旦结束，选课系统即将此学生本学期的账单信息送到财务系统。如果在选课时
45、某门课已经人满，学生在提交信息前必须被告知。学期结束，学生可进入系统查看自己的成绩。成绩属于隐秘信息，系统必须提供额外的安全措施阻止未授权的访问。教授必须能访问系统查询他们主讲课程。他们也需要知道是哪些学生选择了自己的课程。另外，教授也能登记学生的成绩。用例建模示例 确定参与者 确定用例学生要注册课程；教授要选择课程来教；注册管理人员要维护关于教授和学生的所有信息；财务系统要从注册系统获得学生的费用情况；课程目录系统维护课程信息。无论是学生，教授还是注册员都需要登陆到系统；学生需要使用系统来选课，也能查看自己的成绩；教授需要使用系统来选择课程，也能记录学生的成绩；注册员必须维护学生、教授的所有
46、信息，并在适当时候关闭注册系统；当选择课程的过程完成后，收费系统必须获得收费信息；学生和教授选择课程，需要启动课程目录系统。用例建模示例 选课系统用例图用例建模示例选课用例规约1简要说明本用例允许学生选本学期提供的课程。在学期开始的添加/删除时期，学生可以修改或删除选择的课程。课程目录系统提供了当前学期开设的所有课程的列表。2事件流2.1基本事件流用例开始于学生选择选课，或修改已存在的课程表。1）系统要求学生指出要执行的操作（创建，修改或删除课程表）2）一旦学生提供了所需要的信息，以下的一条子事件流将被执行 如果选择的是“创建课程表”，创建课程表子事件流将被执行 如果选择的是“修改课程表”，修
47、改课程表子事件流将被执行 如果选择的是“删除课程表”，删除课程表子事件流将被执行2.2备选事件流 。3特殊需求无4前置条件本用例开始前学生必须已经登录进系统。5后置条件如果用例成功，学生的课程表被创建，修改，删除。否则系统状态不变。描述补充规约示例选课系统的补充规约选课系统的补充规约1目标目标 本文档的目的是定义选课系统的需求。本补充规约列出了不便于在用例模型的用例中获取的系统需求。它和用例模型一起记录关于系统的一整套需求。2范围范围 本补充规约适用于选课系统，除定义了在许多用例中所共有的功能性需求以外，还定义了系统的非功能性需求，例如：可靠性、可用性、性能和可支持性等。（功能性需求在用例规约
48、中定义。）3参考参考无无4功能功能多个用户必须能同时执行操作。如果某个学生所建的课程表中包含人数已满的课程，必须通知这位学生。5可行性可行性 桌面用户界面应与 Windows 98/2000/XP 兼容。6可靠性可靠性 选课系统在每周7天，每天24小时内都应是可用的。宕机的时间应少于 10%。7性能性能。术语表示例选课系统的术语表选课系统的术语表1.简介简介这份文档是用来对一些术语进行定义的，同时将用例说明或其他文档中读者不太熟悉的术语进行解释性的描述。通常来说，这份文档对一些数据信息进行一些定义，从而使得用例规约和其他的文档显得简洁易懂。2.定义定义这份术语表包含了选课系统中核心概念的定义。
49、课程：大学提供的某一门课。开设课程：某一课程的具体安排情况，包括一周上课的天数、时间和教授。课程目录：大学所开设的所有课程的完整目录。教员：所有在此大学内任教的教授。财务系统：用来处理收费信息的系统。成绩：学生某门课程的成绩。5.软件需求描述 软件需求规格说明书 Software Requirement Specification 引言 信息描述 功能描述 行为描述 质量保证 接口描述 其他6.需求管理 需求管理的特定实践 需求管理的流程 需求确认 需求跟踪6.需求管理 需求变更控制 需求变更的利弊 需求变更的流程需求变更状态转换需求管理工具 IBM Rational RequisitePro
50、 Telelogic DOORSreg Borland CaliberRM7.需求建模示例网上购物系统当今，网上购物已成为一种时尚。本示例作为WEB 应用的一例，主要为普通购物用户和管理员服务。普通购物用户在使用本系统的购物功能前，必须先注册账号。在注册页面中填写个人信息，如使用本系统的账号名和密码,联系地址等。在提交表单、完成注册后，系统将保存信息，以方便管理员管理用户信息、联系用户。如果用户已经在系统中注册过，可以在登录页面输入账号名和密码。如果密码正确，用户就可以购物，否则只能做一般的页面浏览。进入系统后，用户也可选择维护自己的信息，比如修改账号名，密码，联系地址等。如果直接进行购物，系
