1、什么叫软件：软件是计算机系统中鱼硬件相互依存的另一部分，它包括程序，数据以及其相关文档的完整集合。

2、什么是软件危机？软件危机的表现是什么？其产生的原因是什么？

软件危机：软件发展第二阶段的末期，由于计算机硬件技术的进步，计算机运行速度、容量、可靠性有显著的提高，生产成本显著下降，这为计算机的广泛应用创造了条件。一些复杂的、大型的软件开发项目提出来了，但是，软件开发技术的进步一直未能满足发展的需要。在软件开发中遇到的问题找不到解决办法，使问题积累起来，形成了尖锐的矛盾，导致软件危机。 软件危机表现在以下四个方面：（1）经费预算经常突破，完成时间一再拖延。（2）开发的软件不能满足用户要求。（3）开发的软件可维护性差。（4）开发的软件可靠性差。 造成软件危机的原因是：（1）软件的规模越来越大，结构越来越复杂。（2）软件开发管理困难而复杂。（3）软件开发费用不断增加。（4）软件开发技术落后。（5）生产方式落后。

6）开发工具落后，生产率提高缓慢。

软件质量保证应做好哪几方面的工作：（1）采用技术手段和工具。（2）组织正式技术评审。（3）加强软件测试。（4）推行软件工程规范（标准）。（5）对软件的变更进行控制。

（6）对软件质量进行度量。

3、简述软件工程的概念：软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。

4、两种软件工程方法学开发软件时要建立哪些模型：软件工程方法学包括传统方法学和面向对象方法学。常用的开发模型有：瀑布模型，原型模型，增量模型，螺旋模型和喷泉模型。

5、软件过程模型有哪些？简述它们的特点：过程模型分为五大类：

第1章 软件工程学概述

1.1.1软件危机的介绍 1.1.2产生软件危机的原因

图1.1引入同一变动付出的代价随时间变化的趋势

1.1.3消除软件危机的途径

1.2.1软件工程的介绍

1. 软件工程关注于大型程序的构造 2. 软件工程的中心课题是控制复杂性 3. 软件经常变化

4. 开发软件的效率非常重要 5. 和谐地合作是开发软件的关键 6. 软件必须有效地支持它的用户

7. 在软件工程领域中通常由具有一种文化背景的人替具有另一种文化背景的人创造产品

1.2.2软件工程的基本原理

1. 用分阶段的生命周期计划严格管理 2. 坚持进行阶段评审 3. 实行严格的产品控制 4. 采用现代程序设计技术 5. 结果应能清楚地审查

6. 开发小组的人员应该少而精

7. 承认不断改进软件工程实践的必要性

1.2.3软件工程方法学

1. 传统方法学 2. 面向对象方法学

1. 问题定义 2. 可行性研究 3. 需求分析 4. 总体设计 5. 详细设计

6. 编码和单元测试 7. 综合测试 8. 软件维护

图1.2传统的瀑布模型

1. 阶段间具有顺序性和依赖性 2. 推迟实现的观点 3. 质量保证的观点

图1.3实际的瀑布模型

1.4.2快速原型模型

图1.4快速原型模型 1.4.3增量模型

图1.6风险更大的增量模型

图1.7简化的螺旋模型

图1.8完整的螺旋模型

2. RUP软件开发生命周期

图1.10 RUP软件开发生命周期

1.4.7敏捷过程与极限编程

1. 敏捷过程 2. 极限编程

图1.11 XP项目的整体开发过程

1. 微软过程准则 2. 微软软件生命周期

图1.13微软软件生命周期阶段划分和主要里程碑

图1.14微软过程的生命周期模型

2.1可行性研究的任务 2.2可行性研究过程

1. 复查系统规模和目标 2. 研究目前正在使用的系统 3. 导出新系统的高层逻辑模型 4. 进一步定义问题

5. 导出和评价供选择的解法 6. 推荐行动方针 7. 草拟开发计划 8. 书写文档提交审查

图2.3库存清单系统的系统流程图 2.3.3分层

图2.4数据流图的符号 2.4.2例子

图2.5定货系统的基本系统模型

图2.6定货系统的功能级数据流图

图2.7把处理事务的功能进一步分解后的数据流图 2.4.3命名

1. 为数据流(或数据存储)命名 2. 为处理命名

图2.8这种划分自动化边界的方法暗示以

图2.9另一种划分自动化边界的方法建议 2.5数据字典

2.5.1数据字典的内容

2.5.2定义数据的方法 2.5.3数据字典的用途

2.5.4数据字典的实现

1. 代码行技术 2. 任务分解技术

3. 自动估计成本技术

2.6.2成本/效益分析的方法

2. 投资回收期 3. 纯收入 4. 投资回收率

3.1.1确定对系统的综合要求

1. 功能需求 2. 性能需求

3. 可靠性和可用性需求 4. 出错处理需求 5. 接口需求 6. 约束 7. 逆向需求

8. 将来可能提出的要求

3.1.2分析系统的数据要求 3.1.3导出系统的逻辑模型 3.1.4修正系统开发计划

3.2与用户沟通获取需求的方法

3.2.2面向数据流自顶向下求精

图3.1面向数据流自顶向下求精过程 3.2.3简易的应用规格说明技术 3.2.4快速建立软件原型

3.3分析建模与规格说明

3.3.1分析建模 3.3.2软件需求规格说明

图3.2某校教学管理ER图 3.4.4实体联系图的符号

图3.3状态图中使用的主要符号

图3.4电话系统的状态图 3.7其他图形工具

图3.5层次方框图的一个例子

图3.8改进的IPO图的形式

3.8.1从哪些方面验证软件需求的正确性 3.8.2验证软件需求的方法

1. 验证需求的一致性 2. 验证需求的现实性

3. 验证需求的完整性和有效性

3.8.3用于需求分析的软件工具 第4章 形式化说明技术

4.1.1非形式化方法的缺点 4.1.2形式化方法的优点 4.1.3应用形式化方法的准则

图4.1保险箱的状态转换图

图4.2电梯按钮的状态转换图

图4.3楼层按钮的状态转换图

图4.4电梯的状态转换图

图4.7图4.6的Petri网在转换t1被激发后的情况

图4.8图4.7的Petri网在转换t2被激发后的情况

1. 给定的集合 2. 状态定义

1. 设想供选择的方案 2. 选取合理的方案 3. 推荐最佳方案 4. 功能分解 5. 设计软件结构 6. 设计数据库 7. 制定测试计划 8. 书写文档 9. 审查和复审

图5.1模块化和软件成本

1. 改进软件结构提高模块独立性 2. 模块规模应该适中

3. 深度、宽度、扇出和扇入都应适当 4. 模块的作用域应该在控制域之内

图5.2模块的作用域和控制域

5. 力争降低模块接口的复杂程度 6. 设计单入口单出口的模块 7. 模块功能应该可以预测

5.4描绘软件结构的图形工具

图5.3正文加工系统的层次图

图5.5结构图的例子——产生最佳解的一般结构

图5.6判定为真时调用A，为假时调用B

图5.7模块M循环调用模块A、B、C 5.5面向数据流的设计方法

图5.10面向数据流方法的设计过程

图5.11数字仪表板系统的数据流图

图5.12具有边界的数据流图

图5.13第一级分解的方法

图5.14数字仪表板系统的第一级分解

图5.15第二级分解的方法

图5.16未经精化的输入结构

图5.17未经精化的变换结构

图5.18未经精化的输出结构

图5.19精化后的数字仪表板系统的软件结构

图5.20事务分析的映射方法

图6.1 3种基本的控制结构

图6.2其他常用的控制结构

1. 系统响应时间 2. 用户帮助设施 3. 出错信息处理 4. 命令交互 6.2.2设计过程 6.2.3人机界面设计指南

1. 一般交互指南 2. 信息显示指南 3. 数据输入指南

图6.3程序流程图中使用的符号

图6.4盒图的基本符号

图6.5PAD图的基本符号

图6.6使用PAD图提供的定义功能来逐步求精的例子 6.3.4判定表

图6.7用判定树表示计算行李费的算法 6.4面向数据结构的设计方法

1. 顺序结构 2. 选择结构

图6.8A由B、C、D 3个元素顺序组成

图6.9根据条件A是B或C或D中的某一个

图6.12表示输入输出数据结构的Jackson图

图6.13描绘统计空格程序结构的Jackson图

图6.14把操作和条件分配到程序结构图的适当位置

6.5程序复杂程度的定量度量

图6.15把程序流程图映射成流图

图6.16由PDL翻译成的流图

图6.17由包含复合条件的PDL映射成的流图

2. 计算环形复杂度的方法 3. 环形复杂度的用途

7.1.1选择程序设计语言 7.1.2编码风格

1. 程序内部的文档 2. 数据说明 3. 语句构造 4. 输入输出 5. 效率

1. 模块测试 2. 子系统测试 3. 系统测试 4. 验收测试 5. 平行运行 7.2.5测试阶段的信息流

图7.1测试阶段的信息流

1. 模块接口 2. 局部数据结构 3. 重要的执行通路 4. 出错处理通路 5. 边界条件

图7.2正文加工系统的层次图 7.4集成测试

7.4.1自顶向下集成

7.4.2自底向上集成

图7.4自底向上结合 7.4.3不同集成测试策略的比较 7.4.4回归测试

图7.5被测试模块的流程图

2. 判定覆盖 3. 条件覆盖

4. 判定/条件覆盖 5. 条件组合覆盖 6. 点覆盖 7. 边覆盖 8. 路径覆盖 7.6.2控制结构测试

图7.6求平均值过程的流图

2. 条件测试 3. 循环测试

图7.73种循环 7.7黑盒测试技术

1. 软件可靠性的定义 2. 软件的可用性

7.9.2估算平均无故障时间的方法

3. 估算平均无故障时间 4. 估计错误总数的方法

8.1软件维护的定义 8.2软件维护的特点

8.2.1结构化维护与非结构化维护差别巨大

1. 非结构化维护 2. 结构化维护

8.2.2维护的代价高昂 8.2.3维护的问题很多

1. 维护组织 2. 维护报告 3. 维护的事件流

图8.1维护阶段的事件流

4. 保存维护记录 5. 评价维护活动

8.4.1决定软件可维护性的因素

1. 用户文档 2. 系统文档

8.4.3可维护性复审

8.5预防性维护 8.6软件再工程过程

图8.2软件再工程过程模型

1. 库存目录分析 2. 文档重构 3. 逆向工程 4. 代码重构 5. 数据重构 6. 正向工程 第9章 面向对象方法学引论

9.1面向对象方法学概述

9.1.1面向对象方法学的要点 9.1.2面向对象方法学的优点

1. 与人类习惯的思维方法一致 2. 稳定性好 3. 可重用性好

4. 较易开发大型软件产品 5. 可维护性好

图9.1对象的形象表示

图9.2用自动机模拟对象

3.对象的特点 9.2.2其他概念

图9.3实现继承机制的原理

9.4.1类图的基本符号

图9.4表示类的图形符号

2. 定义属性 3. 定义服务

9.4.2表示关系的符号

7月9日 19:00-21:30 阿里云开发者社区首场“Offer 5000”直播开启！14位团队技术大牛在线招人，更有《阿里云技术面试红宝书》助你拿下Offer！戳下图或链接马上投递简历：

---

对于整个电脑而言，它有一个自己的固定状态：如果要读取数据，流程是将硬盘上的内容直接加载到内存里，而后再通过内存进行读取。因为硬盘上所保存的都是物理上的二进制数据。

如果你的电脑只是你一个人使用，那么没有任何问题,如果多人使用，你就会发现电脑变得像蜗牛跑步一样慢。你一个人在使用，慢一点或许感觉不到，一旦换到公网上，一群用户要进行数据读取，问题就出现了，所有的操作如果通过数据库查询得到（物理磁盘上），那么速度就会非常慢。例如一个查询需要60毫秒的时间，如果人一多就会成指数倍增长，效率会非常低。

如何减少这种操作所带来的延迟时间的增长呢？

有人提出，不使用普通的硬盘（物理磁盘），全部换固态硬盘。然而，使用固态硬盘虽然速度可以提升，但价格也相对高，且不实用。

无法缩短内存与磁盘间的读取的延迟，这个时候该怎么办？

解决方案是不读取硬盘上的内容，速度就会非常快了。这种做法有三种实现模式：

1.利用文件（CMS系统，这个系统的特点是把所有要读的数据都生成静态文件，静态页面的加载速度很快）；

2.直接使用内存作为缓存，也就是将所读取进来的数据保存在内存里面（考虑数据的实效问题）；

**对于内存缓存而言，有两种常用的组件：
-oscache（主要在页面上使用）
-ehcache（在一些开发框架中出现**）

缓存的本质是减少物理磁盘的读取时间，直接读内存，因而还需要进行合理的内存管理。

---

使用缓存的核心意义在于减少数据库的操作，缓存和数据库之间有一定的内容差异。

如果要求尽可能保持缓存和数据库同步，那么需要思考以下几个问题：
1.你的缓存是否为数据库专用的缓存？
在所有的ORMapping设计组件之中都会存在有EHCache缓存组件，这个缓存组件主要目的是帮助用户减少数据库的处理操作，一般这样的缓存都会有自己的回收算法，比如：FIFO、软引用，弱引用。这些算法只是保证缓存中不需要的内容被及时清理干净。如果一直被使用，那么将被一直保留，并且这一操作只能通过明确的代码进行释放。

2.你的缓存是否在进行分布式或反向代理操作时使用的？
例如：你的系统里面配置了N多个Tomcat（web容器），这些web容器需要统一为所有的用户服务，为了操作方便可以将图片或视频等内容暂时保存在自己本地服务器上，一般保存在本地服务器上的数据都可以进行手工清空处理。

3.你的缓存是否采用了缓存数据库完成？
Memcached、Redis，这个里面数据保存的内容往往不会是显示的数据，对于缓存的数据库，里面保存的内容往往都是一些高并发的数据信息统计，对于这些信息统计处理操作，往往会结合大数据的开发工具完成，或者在进行集群设计的时候使用缓存数据库进行更加方便的协调处理操作，保存分布式服务器上的公共数据。例如：session。

更多专业知识，面试技巧就在面试一点通，持续更新中……
本内容来源于[阿里云大学-Java面试技巧