第10章 软件演化、再工程与逆向工程
第10章 软件产品线体系结构
产品的开发时间减少1.5-2倍，维护成本降低2-5倍， 软件质量提升5-10倍，软件重用达50%-80%，开发成本 降低12%-15%。
软件产品线的发展得益于软件体系结构的发展和软件重 用技术的发展。
第10章 软件产品线体系结构 10.1 软件产品线的出现和发展 ◇ 软件体系结构的发展(1/2)
领域工程部门
10.2 软件产品线概述
有一个专门的单位——领域工程部门负责核心资源库的开发 和维护，其他业务单位使用这些核心资源来构建产品。这种 结构可有效的降低通讯的复杂度、保持资源的通用性，适于 超过100人的组织。 缺点是难以管理领域工程部门和不同产品工程部门之间的需 求冲突和因此导致的开发周期增长。
通过构件/类的组合来支持重用和扩展
松耦合
② 白盒框架
一般使用类的继承机制实现，由未完成的类（抽象类）组 成，类有一个或多个抽象接口或虚方法
紧耦合 具体的框架实际上都是“灰色”的， 是可继承和可组合方式的结合。
第10章 软件产品线体系结构 ◇ 产品线基本活动
领域工程 应用工程
10.4 软件产品线基本活动
第10章 软件产品线体系结构 ◇ 框架技术基本特征
① 反向控制 ② 可重用性 ③ 扩展性
10.3 框架和应用框架技术
④ 模块化和构件化
◇ 框架建立方式
自顶向下
软件工程中的可维护性与演化
需求分析
软件升级的流程
测试与发布
设计与开发
纠错性维护
软件维护的类型
完善性维护
适应性维护
修复软件中的错误
改进现有软件功能
使软件适应新的环境
需求分析不清
软件升级与维护的挑战
用户反馈不及时
成本高昂
●04
第四章 可维护性与演化的工具支持
静态分析工具
静态代码分析工具在软件工程中起着至关重要的作 用，可以帮助开发人员检测代码中的潜在问题、优 化代码结构并提高代码质量。常见的静态分析工具 包括Lint、PMD、FindBugs等，开发人员在使用 这些工具时需要注意代码规范、潜在问题的修复以
持续演化和变化。
业务需求驱动的可维护性改进策略
需求变更对可维护 性影响
改进策略结合需求 管理
需求演化中保持可 维护性
快速响应需求变更，减少 对系统结构的影响
与需求管理流程结合，保 证软件与需求同步演化
持续改进代码质量，保持 代码灵活性
●03
第三章 软件演化的过程
软件演化的定义
软件演化是指软件经历不同阶段的变化和发 展过程。它可以是由软件本身的需求变更、 技术更新或市场需求变化等原因所引起的。 软件演化分为逐步演化和革命性演化两种类 型。逐步演化是在原有的软件基础上不断进 行修改和增强，而革命性演化则是通过完全
有限元第10章 有限元软件技术
第10章有限元软件技术
10.1 引言
有限元方法经过近半个世纪的发展，目前已成为各种工程问题特别是结构分析问题的标准分析方法，而有限元软件已成为现代结构设计不可缺少的工具。有限元软件是由有限元理论通向实际工程应用的桥梁。通用有限元软件的物质基础是数字计算机，而有限元软件的理论与知识基础是：有限元法、连续统力学、本构理论、线性与非线性代数与常微分方程的算法、瞬时积分以及软件设计技术。因此，通用有限元软件是有限元力学理论、计算数学、计算机技术综合的知识与高度密集性产品。从有限元理论到有限元软件是一次重要的技术升华。既要有坚实高深的理论基础，又要具备广博的计算机知识，更应以坚韧的毅力付出艰辛的劳动，投入必要的资金。因此，衡量一个国家计算结构力学水平的高低，除了看其理论水平外，更应着重于其结构分析软件的水平。
10.2 有限元软件的发展
有限元软件的发展是随着计算机硬件与软件技术的进步而不断发展。有限元软件的发展大约可以分成以下几个阶段：
(])有限元分析软件，
(2)有限元分析与设计软件；
(3)有限元分析、设计与CAD软件；
(4)有限元分析、设计与CAD＋专家系统；
(5)智能性有限元结构分析系统；
(6)集成化有限元软件开发环境。
下面分别叙述各个阶段有限元软件的主要特点。．
10.2.1 有限元分析软件’
早期的有限元软件实质上只是有限元分析软件，因为从软件的组成上说，其程序主要由单元分析、组装和求解组成，缺乏前后处理功能，如图10.1所示；从软件的功能上说，它解决的问题的范围窄、复杂性小、且规模也小，功能简单，诸如线性热传导以及线性结构分析等，从软件技术上来说，它有以下几个鲜明的特点：
软件维护与软件工程管理
14
1. 逆向工程
软件的逆向工程通过对程序的分析，导出更高抽象层次的 表示，如从现存的程序中抽取数据、体系结构、过程的设计信息 等，是一个设计恢复过程。
逆向工程过程所抽取的信息，一方面可以提供给软件工程 师以便在维护活动中使用这些信息；另一方面可以用来重构原来 的系统，使新系统更易维护。
15
2. 重构
13.1.5 自动化运维
针对上述自动化运维的范畴,Gartner 还定义了成熟度模型。Gartner 将企业实施自动化 的成果分为起步、基本、标准、合理、动态共 5 个阶段,在每个阶段定义了企业应该达成怎 样的目标。
13.1.6 软件再工程技术
• 软件维护的矛盾
软件维护使软件的可维护性下 降，束缚着新软件的开发。
因此，进行维护工作要相当谨慎。
5
13.1 软件维护
• 13.1.1 软件维护的过程 • 典型的软件维护的过程可以概括为：
• 建立维护机构 • 用户提出维护申请并提交维护申请报告 • 维护人员确认维护类型并实施相应的维护工作 • 整理维护记录并对维护工作进行评审 • 对维护工作进行评价
6
13.1 软件维护
3
的工作带来不便的情况。
11
13.1.5 自动化运维
自动化运维是指将IT 运维中日常的、大量的重复性工作自动化,将过去的手工执行转为自动化操作,最终达 到提升运维效率的目的。自动化是IT 运维工作的提升,IT 运维自动化不单纯是一个维护过程,更是一个管理的提 升过程,是 IT 运维的最高层次,也是未来的发展趋势。
软件工程课程目录
软件工程课程目录第一章：导论
1.1 软件工程概述
1.2 软件工程的定义和特点
1.3 软件工程的发展历程
第二章：软件开发过程模型
2.1 瀑布模型
2.2 增量模型
2.3 螺旋模型
2.4 敏捷开发模型
2.5 DevOps模型
第三章：需求工程
3.1 需求获取与分析
3.2 需求规格说明
3.3 需求验证与确认
3.4 变更管理
第四章：软件设计与实现
4.1 结构化设计
4.2 面向对象设计
4.3 软件架构设计
4.4 系统建模
4.5 设计原则和模式
第五章：软件测试与维护5.1 测试基础知识
5.2 测试设计技术
5.3 测试用例编写
5.4 软件维护流程及策略5.5 缺陷管理
第六章：软件项目管理6.1 项目启动与规划
6.2 项目进度管理
6.3 资源管理
6.4 风险管理
6.5 团队协作与沟通
第七章：软件质量保证和评估
7.1 质量保证概述
7.2 质量标准与度量
7.3 代码审查
7.4 归纳测试
7.5 质量评估与改进
第八章：软件工程伦理与职业道德
8.1 软件工程伦理概述
8.2 软件专业人员责任
8.3 知识产权保护
8.4 软件工程师的职业道德
结语：
软件工程课程目录涵盖了软件工程学科的基本知识和方法，帮助学生全面了解软件开发的过程和要素。通过学习本课程，学生可以系统学习软件工程的理论和实践知识，培养良好的软件开发习惯和职业道德意识，为将来的软件开发工作奠定坚实的基础。
软件工程理论方法与实践
软件⼯程理论⽅法与实践
第⼀章、概述软件是⼈类思维的杰作，并成为⼈类现代⽣活的催化剂。今天软件遍布整个世界，在⽣物⼯程、现代通信、宇宙探索、商务处理、⼯业控制等⽅⾯发挥出巨⼤的威⼒，并推动了商业、科学和⼯程领域的跨越式发展，对整个社会的经济和⽂化产⽣了深远的影响。软件⼯程师为了解决开发成本效益和软件质量的问题⽽产⽣的。软件是计算机程序、规程以及运⾏计算机系统可能需要的相关⽂档和数据。软件分为通⽤软件和定制软件。软件的特性分别是软件是复杂的、软件是不可见的、软件是不断变化的、⼤多数软件是定制的⽽不是通过已有构件组装⽽成的。软件⼯程是将系统性的、规范化的、可定量的⽅法应⽤于软件的开发、运⾏和维护，即将⼯程化应⽤到软件上。软件⼯程的三要素分别是⽅法、⼯具和过程。软件开发的主要挑战是遗留系统的问题、⾼可信软件开发的要求和软件开发⽅式的变化。软件⼯程⼈员的职业道德建设：1、遵纪守法是软件⼯程⼈员应具备的基本素质；2、服务客户、造福社会是软件⼯程⼈员必须牢固树⽴的观念；3、诚实信⽤是软件⼯程⼈员职业道德的核⼼所在。
第⼆章、软件⼯程软件⼯程的⽬标是在规定的时间和预算内开发出⾼质量的软件。软件⼯程的基本活动是问题提出、软件需求规格说明、软件设计、软件实现、软件确认和软件演化。软件过程模型有瀑布模型、快速原型模型、增量模型、螺旋模型、形式化⽅法模型、基于组件的开发模型。
第三章、软件项⽬管理随着计算机应⽤的飞速发展，软件开发规模和开发队伍⽇益庞⼤，软件开发不再像过去那样是由个别开发⼈员即可以解决的事情，因此，有必要将软件项⽬管理引⼊软件开发活动中，从⽽有效的保证软件项⽬能够按照预定的成本、进度、质量要求顺利完成。软件项⽬的特征有软件产品的不可见性、项⽬的⾼度不确定性、软件⼈员的⾼流动性。软件项⽬管理集中于四个⽅⾯：⼈员、产品、过程、项⽬。软件项⽬的组织有民主式组织结构、主程序员式组织结构、技术管理式组织结构。项⽬沟通活动：规划项⽬沟通、建⽴基础设施、实施阶段性评审、每周组织⼩组会议。软件规模估算：代码⾏技术、功能点技术。软件成本估算：专家判断、类⽐估算、COCOMO模型。软件⼯程风险识别：软件规划风险、商业影响风险、客户相关风险、软件过程风险、开发技术风险、开发环境风险、开发⼈员风险。
小议软件保护措施中的软件逆向工程技术
文◎ 石泉 （ 杭州师范大学钱江学 院 计算机科学与技术 浙 江杭州 ）
固圆
小议 软件保护措施 中的软件逆向工程 技术
摘要 ：随 着 网络技 术 的发展 ，更多软件 的 不 同是 对于 形式化 规格 语 言的应 用 。形式
是 在 不确 定 （ 至 是 恶 意 ） 环 境 下 运 行 的 ， 甚 的 主机可 以任 意地对软 件进 行 分析和跟 踪 ，而 且 随 着 各 种 逆 向 工 程 技 术 的 发 展 ，使 得 对 软 件 的 攻击 变得 更加 容 易。如何 保护软 件 中的 核 心 算 法 和 机 密数 据 成 为 人 们 关 注 的 一 个 焦 化 规 格 语 言 有 良好 定 义 的 句 法 和 语 义 ， 因 此
二 、 逆 向 工 程 技 术
（ ）逆 向工 程 的 概 念 一 逆 向工程 定义 为包含 两个 步骤 的过程 ： 第一步 分析 目标系 统，标 识系 统对象 及其 关 系 ； 第 二 步 创 建 不 同 形 式 或 更 高 抽 象 层 次 的 系 统 表 示 。Ｓ ｏ ｔ ． Ｔ １ｅ 将 抽 取 和 抽 象 ｃ ｔ Ｒ ｉ １ｙ
一
图。
百度文库
（ ）程 序 切 片 。 二 切 片 技 术 是 将 程 序 简 化 为 和 某 个 特 殊 计 算 相 关 的 语 句 的 技 术 ，来 源 于 数 据 流 分 析 方 法 。 切 片 技 术 自动 将 程 序 分 解 为 较 小 的 称 为切 片 的代码 段 ，使 关注 点确定 在一 个较 小 范 围 而 不 必 关 注 整 个 程 序 。 一 个 程 序 切 片 是 由程序 中的一 些语 句和判 定表达 式组 成的集 合 。 这 些 语 句 和 判 定 表 达 式 可 能 会 影 响 在 程 序 的某个 位置 （ 用 行号标 识） 所 定义或使 常 上 用 的 变 量 的 值 。 切 片 技 术 己经 成 为 很 多 程 序 理 解 工 具 的基 础 。 （ ） 象解释 。 三 抽 抽 象 解 释 是 对 程 序 语 言 的 语 义 形 式 上 构 建 一 个 保 守 的 近 似 ，用 基 于 语 义 的 分 析 来 确
软件工程中的可维护性与演化策略实践
新技术对软件可维护性的影响
人工智能
01
通过AI技术实现自动化的代码优化和修复，提高软件的可维护性
云计算
02
利用云端资源部署和管理软件，方便演化和扩展
区块链
03
实现去中心化的数据交换和验证，增强软件系统的安全性和可靠性
持续演化的挑战与机遇
技术更新速度快
需要及时学习和应 用新技术，以保持 软件系统的竞争力
版本控制策略
版本控制策略包括分支管理、版本发 布和回滚操作。通过合理的版本控制， 可以确保团队协作的顺利进行，避免 代码冲突和错误版本发布。
持续集成与持续交付
持续集成原理
01
将代码频繁集成到共享仓库
持续交付优势
02
快速、可靠地发布软件
03
Jenkins
开源的持续集成工具 支持插件扩展
持续集成工具介绍
第四章 可维护性与演化的实践案例
Google的软件维护实践
Google的代码规范
Google 的 代 码 审 查 流程
Google 的 持 续 集 成 实践
Facebook的软件演化案例
Facebook作为社交网络软件，不断 演化，保持更新，其版本控制策略与 持续交付经验备受关注。
Netflix的软件可维护性实践
易理解性
01
清晰的代码结构和命名规范有助于快速理解代码逻辑
第10章 软件配置管理计划
南京理工大学计算机学院
6/81
第10章 软件配置管理计划
配臵管理的目标
配臵管理是对系统中配臵项进行标识和定义
的过程，通过控制某个配臵项及其后续变更， 记录并报告配臵项的状态和变更要求，证明 配臵项的完整性和正确性实现。 软件配臵的目标：
软件配臵管理的各项工作是有计划进行的。 被选择的项目产品得到识别，控制并且可以被相
前一页
休息
南京理工大学计算机学院
15/81
第10章 软件配置管理计划
配臵项版本
需求规格
配臵项类 配臵项实例
需求规格 V1.1
需求规格 V1.2
需求规格 V1.3
前一页
休息
南京理工大学计算机学院
16/81
第10章 软件配置管理计划
基线定义
基线提供了软件生存期中各个开发阶段的一
个特定点 一个(些)配臵项形成并通过审核，即形成基 线 基线标志开发过程一个阶段的结束和里程碑 基线修改需要执行正式的程序
前一页
休息
南京理工大学计算机学院
24/81
第10章 软件配置管理计划
配臵管理员分类
全职配臵管理员 开发员、配臵管理员、测试员、项目经理等这些 角色都在一个小组内，配臵管理角色会和其他角 色由同一个员工兼任。 兼职配臵管理员 一个新的项目时，项目经理来申请一个配臵管理 员负责支持其项目的配臵管理，但是这个配臵管 理员也会兼职从事其他项目的配臵管理。
软件工程导论第一章
软件工程的研究范围涵盖了软件开发的各个阶段，包括需求分析、设计、编码、 测试和维护等，同时也涉及到软件项目管理、软件质量保证和软件测试等方面。
软件工程的重要性
提高软件质量
通过采用先进的软件工程方法和工具，可以显著提高软件的质量，减 少软件中的缺陷和错误，提高软件的稳定性和可靠性。
降低开发成本
原型设计
通过快速构建原型来验证软件需求和设计方案，及时发现和解决 问题。
软件设计文档的编写与评审
设计说明书
详细描述软件系统的设计方案，包括系统结构、模块功能、接口定义等。
数据结构图
用图形方式表示软件系统中的数据结构和数据流程。
软件设计文档的编写与评审
• 系统流程图：用图形方式表示软件系统的处理流程和各组 成部分之间的关系。
逆向工程的步骤和工具
逆向工程的步骤包括代码分析、 设计恢复、文档生成等。常用的 逆向工程工具包括反汇编器、调 试器、代码分析工具等。
THANKS FOR WATCHING
感谢您的观看
针对软件的最小可测试单元进行测试，确保每个单元的功能正 确无误。
将多个单元组合在一起进行测试，验证它们之间的接口和功能 是否正常。
对整个软件系统进行全面的测试，包括功能测试、性能测试、 安全测试等，确保软件满足需求和设计要求。
记录和管理测试过程中发现的缺陷，跟踪缺陷的修复进度和结 果，确保软件质量得到持续改进。
海南大学研究生835-软件工程原理方法与应用 考试大纲
海南大学硕士研究生入学考试
《835软件工程原理方法与应用》考试大纲
一、考试性质
海南大学硕士研究生入学考试初试科目。
二、考试时间
180分钟。
三、考试方式与分值
闭卷、笔试。满分150分。
四、考试内容
第一部分软件工程的基本概念
第1章绪论
软件与软件危机，软件工程，软件开发生命周期，模型，方法，技术，工具，过程，软件工程原理，软件工程环境，软件工程管理，软件开发风险，软件需求，软件设计，软件工具，自顶向下，分解，抽象，细化，模块，模块化，软件复审，软件测试等。
第二部分传统（结构化）软件工程
第2章软件生存期与软件过程
2.1软件生存周期
2.2传统的软件过程
2.3软件演化模型
2.4形式化方法模型
2.5软件可行性研究
第3章结构化分析与设计
3.1概述（结构化分析的工具与模型组成）
3.2结构化系统分析（需求分析的任务、步骤，DFD过程模型）
3.3结构化系统设计（软件设计的任务，数据存储的设计，人机交互的设计）
3.4模块化设计
第二部分面向对象软件工程
第4章面向对象与UML
4.1面向对象概述
4.2UML简介
4.3静态建模
4.4动态建模
4.5物理架构建模
4.6UML工具(Rational Rose)第5章需求工程与需求分析*
5.1软件需求工程
5.2需求分析与建模
5.3需求获取的常用方法
5.4需求模型
5.5软件需求描述
5.6需求管理
5.7需求建模示例
第6章面向对象分析
6.1软件分析概述
6.2面向对象分析建模
6.3面向对象分析示例
第7章面向对象设计
7.1软件设计概述
7.2面向对象设计建模
7.3系统架构设计
7.4系统元素设计
第10章 软件产品线体系结构
第10章 软件产品线体系结构
10.2 软件产品线概述
◇ Jan Bosch产品线组织结构(1)
◎ 开发部门：所有的软件开发集中在一个部门，每个人都可承担 领域工程和应用工程中适合的任务，简单、利于沟通，适用于不 超过30人的组织。 ◎ 业务部门：每个部门负责产品线中一个和多个相似的系统，共 性资源由需要使用它的一个和几个部门协作开发，整个团体都可 享用。资源更容易共享，适用于30－100人的组织，主要缺点是业 务部门更注重自己的产品而将产品线的整体利益放在第二位。
第10章 软件产品线体系结构
10.5 产品线体系结构的演化
◇ 背景介绍
NFS 文件系统框架 ISO9660 FAT-16 块设备 SCSI 硬件 Pseudo UFS 存取控制框架
第二代文件系统框架
第10章 软件产品线体系结构
10.5 产品线体系结构的演化
◇ 两代产品的各种发行版本
以太网模块 网络文件系统框架 Netware 令牌网模块 NFS SMB 网络协议框架 SCSI 文件系统框架 Pseudo ISO9660
新构件
修改了的构件
未改变的构件
第一代产品的第四个版本
第10章 软件产品线体系结构
10.5 产品线体系结构的演化
◇ 两代产品的各种发行版本
1994 版本一 第一代 第二代
1995 版本二
软件工程知识点
名词解释：
1、软件工程：软件工程是应用计算机科学、数学及管理科学等原理，以工程化
的原则和方法制作软件的工程
2、软件生存周期：是指产品或软件洗头你那个从产生。投入使用到被淘汰的
全过程。。软件生存周期主要分为六个阶段：计算机系统工程，需求分析。设计。编码。测试。运行和维护。
3、.软件过程：软件过程是软件生存周期中的一系列相关的过程。过程是活动的集合，活动是任务的集合。
4、逆向工程：指在软件生存周期中，将软件的某种形式描述转换成更抽象形式的活动。
5、再工程：指在逆向工程所获信息的基础上修改或重构已有的系统，产生
系统的一个新版本。
6、程序设计语言：是指用于书写计算机程序的语言，它是一种实现性的软件语言
7、计算机系统工程：是一个问题求解的活动，其目的是分析基于计算机的系统的功能、性能等要求，并把它们分配到基于计算机系统的各个系统元素中，确定它们的约束条件和接口。
8.计算机软件：指计算机系统中的程序，数据和文档。软件分类：系统软件，支撑软件，应用软件。
9.可行性分析：主要从经济、技术、法律等方面分析所给出的解决方案是否可行，能否在规定的资源和时间的约束下完成。
经济可行性：主要进行成本-效益分析，从经济角度，确定系统是否值得开发。还有“短期-长远利益”分析。技术可行性主要根据系统的功能、性能、约束条件等，分析在现有资源和技术条件下系统能否实现。技术可行性分析通常包括:风险分析、资源分析、技术分析。法律可行性分析研究系统开发过程中可能涉及到的合同、侵权、责任以及各种与法律相抵触的问题。
10.系统工程的任务：1.识别用户的要求2. 系统建模和模拟{2.1硬件系统模型2.2软件系统模型2.3人机接口模型2.4数据模型}3.成本估算及进度安排 4.可行性分析5.生成系统规格说明
第10章 软件重用技术
10.2.1 可重用构件 一个软件只有在多个系统中被使用才可称为“ 一个软件只有在多个系统中被使用才可称为“可重 用构件” 必须具备的条件： 用构件”，必须具备的条件： (4)通用性 构件解决的问题，应在同类应用中具有一般性； 构件解决的问题，应在同类应用中具有一般性； (5)适应性 应用场合有某些变化时， 构件仍是可用的， 应用场合有某些变化时 ， 构件仍是可用的 ， 使构 件的某些数据参数化和数据类型参数化； 件的某些数据参数化和数据类型参数化； (6)可靠性 要求构件对预计将要使用它的系统时可靠的； 要求构件对预计将要使用它的系统时可靠的； (7)标准化 可重用构件的标准化对于软件重用是至关重要的。 可重用构件的标准化对于软件重用是至关重要的。
输入信息
技术文献 已有应用 专家经验/建议 专家经验/ 当前与未来的需求 领域分析
输出信息
领域语言 重用标准 分类方法 功能/行为模型 功能 行为模型
领域分析的输入和输出
领域分析不是针对某个特定的软件系统， 领域分析不是针对某个特定的软件系统，而是针 对一类软件系统的共同的特征、知识和需求。比需求 对一类软件系统的共同的特征、知识和需求 比需求 分析更一般、更抽象、更广泛的特征。 分析更一般、更抽象、更广泛的特征。 领域分析(Domain Analysis)是对一类应用系统的 领域分析(Domain Analysis)是对一类应用系统的 共同应用领域进行系统化分析, 共同应用领域进行系统化分析,以发现该领域的共同知 需求及其应用系统的共同特征。 识、需求及其应用系统的共同特征。 领域分析又称领域工程(Domain Engineering)， 领域分析又称领域工程(Domain Engineering)， 是软件工程的发展与延伸。 是软件工程的发展与延伸。 领域分析是一项比系统分析更难的工作。 领域分析是一项比系统分析更难的工作。领域分 析方法可采用结构化方法和面向对象方法， 析方法可采用结构化方法和面向对象方法，而后者将 成为主流。 成为主流。
软件工程第一套
第一弓长
1瀑布模型把软件生命周期划分为八个阶段：问题的定义、可行性研究、软件需求分析、系统总体设计、详细设计、编码、测试和运行、维护。八个阶段又可归纳为三个大的阶段: 计划阶段、开发阶段和运行阶段
2从结构化的瀑布模型看，在它的生命周期的八个阶段中，需求分析阶段环节出错，对软件的影响最大。
3在结构化的瀑布模型中，需求分析阶段定义的标准将成为软件测试中的系统测试阶段的目标。
4软件工程的出现主要是由于软件危机的出现
5软件工程方法学的目的是：使软件生产规范化和工程化，而软件工程方法得以实施的主要保证是软件开发工具和软件开发的环境
6软件开发常使用的两种基本方法是结构化和原型化方法，在实际的应用中，它们之间的关系表现为，相互补充
7UML是软件开发中的一个重要工具，它主要应用于基于对象的面向对象的软件开发方法。
8原型化方法对软件设计和开发人员的开发要求最高。
9结构化分析方法是一种预先严格定义需求的方法，它在实施时强调的是分析对象的数据流
10软件开发的结构化生命周期方法将软件生命周期划分成计划阶段、开发阶段、运行阶段
11软件开发中常采用的结构化生命周期方法，由于其特征而一般称其为瀑布模型
12软件开发的瀑布模型，一般都将开发过程划分为：分析、设计、编码和测试等阶段，一般认为可能占用人员最多的阶段是编码阶段
13软件开发模型是指软件开发的全部过程、活动和任务的结构框架。主要的开发模型有瀑布模型、演化模型、螺旋模型、喷泉模型和智能模型。螺旋模型将瀑布模型和演化模型相结合，并增加了风险分析，它建立在原型的基础上，沿着螺线自内向外每旋转一圈，就得到原型的一个新版本。喷泉模型描述了面向对象的开发模型，它体现了这种开发方法创建软件的过程所固有的递归和开发各阶段之间无“间隙”的特征。
第10章 软件产品线体系结构
框架建立方式
自顶向下 自底向上 混合方式
2013年7月14日9时15分
Mail:yrmeixue@sina.com
21
第10章 软件产品线体系结构 – 框架和应用框架技术 框架分类
黑盒框架 通过构件/类的组合来支持重用和扩展。 松耦合
白盒框架 一般使用类的继承机制实现，由未完成的类（抽 象类）组成，类由一个或多个抽象接口或虚方法。 紧耦合
具体的框架实际上都是“灰色”的，是可继承和可组合方式的结合。
2013年7月14日9时15分
Mail:yrmeixue@sina.com
22
第10章 软件产品线体系结构
10.4 软件产品线基本活动
产品线开发
领域工程
应用工程
2013年7月14日9时15分
Mail:yrmeixue@sina.com
23
第10章 软件产品线体系结构 – 软件产品线基本活动 1. 产品线分析
产品线分析是产品线的需求工程，是商业机遇的确认 和产品线体系结构的设计之间的桥梁。 产品线分析强调： 通过捕获风险承担者的观点来揭示产品线需求； 通过系统的推理和分析、集成功能需求和非功能需 求来完成产品线需求； 产品线设计师对产品线需求的可用性。
25
第10章 软件产品线体系结构 – 软件产品线基本活动 1. 产品线分析
（1）上下文 （2）风险承担者观点
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第10章软件演化、再工程与逆向工程10.1 软件演化的基本概念
10.1.1 软件演化、软件维护与软件复用
10.1.2 软件演化的分类
10.2 设计时演化
10.2.1 设计模式对设计时演化的支持
10.2.2 构件技术对设计时演化的支持
1. 构件包装
2. 基于继承机制的构件演化
10.2.3 框架技术对设计时演化的支持
1.白箱框架
2. 黑箱框架
10.3 软件再工程10.3.1 概述
软件再工程是指对既存对象系统进行调查，并将其重构为新形式代码的开发过程。最大限度地重用既存系统的各种资源是再工程的最重要特点之一。从软件重用方法学来说，如何开发可重用软件和如何构造采用可重用软件的系统体系结构是两个最关键问题。不过对再工程来说前者很大部分内容是对既存系统中非可重用构件的改造。
在软件再工程的各个阶段，软件的可重用程度都将决定软件再工程的工作量。
（1）再分析。再分析阶段的主要任务是对既存系统的规模、体系结构、外部功能、内部算法、复杂度等进行调查分析。这一阶段早期分析最直接目的就是调查和预测再工程涉及的范围。北京工业大学软件工程研究所研制开发的“软件再工程辅助调查工具——SFRE”正是从整体上支持该分析阶段的再工程自动化工具。重用是软件工程经济学最重要原则之一，重用得越多，再工程成本越低，所以逆向工程再分析阶段最重要的目的是寻找可重用的对象和重用策略，最终确定的再工程任务和工作量也将依存于可重用对象范围(重用率)和重用策略。
与一次工程不同，再工程分析者最终提出的重用范围和重用策略将成为决定再工程成败以及再工程产品系统可维护性高低的关键因素。如果重用对象都是既存代码级的当然理想，然而可能性有限。但是再工程分析者如果因此而放弃重用，以为“改他人的代码不如自己重新编写”，便犯了再工程的大忌。因为一个运行良久的既存系统，最起码的价值是在操作方法和正确性上已被用户接受。而再高明的程序员在软件没有经过用户一段时间的使用验证之前都不敢保证自己的程序正确无误;更何况越是有经验的程序员越是知道对一个处于局部变更地位的程序进行重新编写远比一次工程的原始编程复杂得多，因为他需要对应无数的“副作用”，正所谓“碰一筋而动全身”。所以，读文档——即使是“破烂不堪”、读代码——即使是“千疮百孔”，也要坚持住，并且从中筛出可重用对象。
（2）再编码。根据再分析阶段做成的再工程设计书，再编码过程将在系统整体再分析基础上对代码做进一步分析。如果说再分析阶段产品是再工程的基本设计书，那么再编码阶段如同一次工程一样，先要产生的是类似详细设计书的编码设计书。但是再工程比一次工程更难以进行过程分割，换言之，瀑布模型更不适应再工程，无法将再分析、再设计、再编码截然分开。
（3）再测试。一般来说，再测试是再工程过程中工作量最大的一项工作。如果能够重用原有的测试用例及运行结果，将能大大降低再工程成本。对于重用的部分，特别是可重用的（独立性较强的）局部系统，还可以免除测试，这也正是重用技术被再工程高度评价的关键原因之一。当然再工程后的系统总有变动和增加的部分，对受其影响的整个范围都要毫无遗漏地进行测试，不可心存侥幸，以免因“一个苍蝇坏了百年老汤”。
软件再工程的两部分：首先，逆向过程：从代码开始推导出设计或是规格说明（可理解性）；其次，改善软件的静态质量（可维护性、复用性或演化性）。
为什么实施软件再工程？（1）再工程可帮助软件机构降低软件演化的风险。（2）再工程可帮助机构补偿软件投资。（3）再工程可使得软件易于进一步变革。（4）软件再工程有着广阔的市场。（5）再工程能力扩大CASE工具集。（6）再工程是推动自动软件维护发展的动力。
10.3.2实用的重用战略
在判断既存系统应该如何重用时，首先要明确哪些是可重用对象，以及如何使用这些可重用对象。下面以既存LAN系统重构成Web系统的再工程为例，说明再分析和再编码将遇到的一些重用课题。
我们可以将既存LAN系统划分成界面、逻辑、数据三个层次。用既存系统的三个层次去分别对应典型Web系统的表示层、逻辑层和数据层。由此从逻辑上得到对应每个层次的输入和输出，然后为每一层寻找能够实现最大程度重用的重构方法。
（1）界面重用策略
界面模拟方法：将基于文本的旧界面包装为新的图形界面。旧界面运行在终端上，新界面可以是基于PC的图形界面，也可以是运行在浏览器上的HTML页面。新用户界面通过一个界面模拟工具与旧界面通信。此方法重用率相当高。但是不修改既存系统会同时将旧系统的结构性缺点全部继承下来。
基于客户端的Web应用（Java Applet）：Applet可以实现从界面、逻辑到数据库的许多功能。完全用Java语言重写一个系统是不现实的，重用率也不会很高，这不是软件再工程所提倡的。但目前已有许多Applet自动转化工具，而且其转化后代码的重用率相当高。
基于服务器端的Web应用：重新开发界面。这种方法看上去没有重用既存界面代码，其实不然。首先，界面设计完全可以重用，从而节省设计时间；其次，我们可以将某些界面做成可重用的，这样也会减少工作量。
（2）逻辑层包装原则
通过对逻辑层的分解可得到可重用和不可重用的两部
分代码。对可重用部分可直接使用，对于不可重用部分则应
尽量通过各种包装技术按统一标准将其改造成可重用构件。
包装方法有很多，如对象包装法、部件包装法等。
（3）数据层重用策略
数据层通常要求更高的重用率。逻辑和数据休戚相关，
如果改动数据库，逻辑势必不能正常运行，对逻辑部分的重
用也就无从谈起。如果非改不可的话，也要以保证最大限度
的重用为原则，争取做到只增不删，以保证数据的完整性。
再工程工具。再工程工具用来支持重构一个功能和性能
更为完善的软件系统。目前的再工程工具主要集中在代码重
构、程序结构重构和数据结构重构等方面。
10.3.3 软件再工程过程
典型的软件再工程过程模型如图所示，该模型定义了6