1、计科 08软件工程材料名词解释（ 5*3 =15）填空题 （ 10*1 =10）简答题 （ 5*8 =8）解答题 （ 2*10 =20）建模 （ 1*15 =15）1. 软件 ： 软件是与计算机系统操作有关的程序 、 规程及任何与之相关的文档和数据 。 软件是逻辑产品而不是物理产品 。 软件是能够完成预定功能和性能 ， 并对相应数据进行加工的程序和描述程序及其操作的文档。软件 = 程序 +数据 +文档2. 软件工程 ： 是用工程 、 科学和数学的原则和方法研制 、 维护计算机软件的相关技术及管理方法。3. 软件工程的目标：在给定成本、进度的前提下，开发出具有可修改性、有效性、可靠性 、 可理解
2、性 、 可维护性 、 可重用性 、 可适应性 、 可移植性 、 可追踪性 、 和可互操作性并满足用户需求的软件产品。4. 软件工程的目标是 ， 在给定成本 、 进度的前提下开发出高质量的 、 满足用户需求的软件产品 。5. 软件危机 ： 落后的软件生产方式无法满足迅速增长的计算机软件需求 ， 从而导致软件开发与维护过程中出现一系列严重问题的现象。6. 软件危机的原因：1 软件的规模加大、复杂性提高、性能增强2 软件是逻辑产品 , 尚未完全认识其本质和特点3 缺乏有效的、系统的开发、维护大型软件项目的技术手段和管理方法4 用户对软件需求的描述和软件开发人员对需求的理解往往存在差异 ， 用户经常要
3、求修改需求，开发人员很难适应5 技术人员和管理人员缺乏软件工程化的素质和要求，对工程化的开销认识不足6 缺乏有力的方法学和工具方面的支持7 开发人员不能有效的独立自主的处理大型软件的全部关系和各个分支 ， 因而容易出错7. 软件开发模型：是指软件开发的全部过程、活动和任务的结构框架。8. 软件开发模型是软件开发全过程、软件开发活动以及它们之间关系的结构框架9. CAD 系统成本 效益分析图（ P95）系统分析员为手工设计系统和 CAD 目标系统进行成本效益分析T: 绘一幅图的平均时间，单位是小时。 d : 每小时绘图的平均成本，单位是元。 n : 每年绘图的数目。 r : 用 CAD 系统绘图
4、减少的绘图时间比例。 p : 用 CAD 系统绘图的百分比。 利用 CAD 系统绘图每年可以节省的经费为： B r T n d p 当 r =1/4， T=4 小时， n=8000/年， d=20元 / 小时， p 60%代入上式计算得 B=96000元 / 年。用 CAD 绘图比用手工系统绘图平均每年约节省 96000元。系统开发成本 、 节省的经费与时间的关系如图所示 。 盈亏平衡点对应的 时间坐标是 3.1 年，系 统应用 3.1 年后可 以收回成本 。投资成本包括软硬件降价、税收的影响和其他潜在的因素。计科 08软件工程材料10. 提高效益与追加成本之间的关系（ P96）曲线 AB 段
5、表明， 系统在完成用户需 求的条件下尚有 一定潜力支持附加的功能和性能。曲线 BC 段表示， 再增加功能和性 能附加成本会急剧 增加，这时系统没有能力 再支持新的功能和性能，要做到这 点必须 增加新的软、硬件资源。例 ： 将单用户操作系统 的计算机系统改造成多用户系统。 系统效益明显增加 ， 成本增加不多 。 当用户增加到一定数量时 ，系统扩充成本迅速增长。11. 需求分析的任务可分为问题分析、需求描述及需求评审 3 个阶段。a. 问题分析 ： 分析人员应了解问题及环境 ， 应与用户合作清除用户需求的模糊性 、 岐义性和不一致性，并对相互冲突的需求进行折衷。b. 需求描述 ： 以需求模型为基础
6、 ， 考虑到软件问题的可解性 ， 生成需求规格说明和初步的用户手册。c . 需求评审 ： 分析人员对需求规格说明和初步的用户手册进行评审 ， 确保软件需求的完全性 、 精确性和一致性 ， 并使用户和软件设计人员对需求规格说明及用户手册的理解达成一致。12. UML 需求分析步骤：利用用例及用例图表示需求；利用包图及类图表示目标软件系统的总体框架结构。13. 用例 ： 从外部用户的视角看 ， 一个用例是执行者与目标软件系统之间的一次典型的交互作用 ；从软件系统内部的视角看 ， 一个用例代表系统执行的一系列动作 ， 动作执行的结果能够被外部的执行者所察觉。14. 几种重要的架构模式 ： 客户 /
7、服务器模式 ； 模型 视图 控制器模式 （ MVC） 模式 ； 分层模式。 P16015. （ MVC） 模式 ： 由模型 M、 视图 V和控制器 C 三部分组成 。 模型负责维护并保存具有持久性的业务数据 ， 实现业务处理功能 ， 并将业务数据的变化情况及时通知视图 。 视图负责呈现模型中包含的业务数据 ， 响应模型变化通知 ， 更新呈现形式 ， 向控制器传递用户的界面动作 。控制器负责将用户的界面动作映射为模型中的业务处理功能并实际调用之 ， 然后根据模型返回的业务处理结果选择新的视图。16. 分层模式 大概思想 ： 将整个软件系统分为若干层次 ， 最顶层直接面向用户提供软件系统的操作界面
8、，其余各层为紧邻其上的层次提供服务。17. 分层模式层次划分的主要原则 ：a) 易变化的部分，如用户界面、与业务逻辑紧密相关的部件，置于高层b)稳定部分，如公共的技术服务部件，置于低层；c ) 每层都尽量访问紧邻的下层 ， 避免越级访问 ， 尤其要避免逆向访问即 ， 上层模块为下层模块提供服务；d)将目标软件系统的外部接口置入较低层次 ， 系统其余部分对外部系统的访问或操作通过这些外部接口提供的服务来完成。18. 抽象 ： 要求人们将注意力集中在某一层次上考虑问题 ， 而忽略那些低层次的问题 。 软件设计过程中 ， 首先在最高抽象级别上用面向问题域的语言叙述 “ 问题 ” ， 概括 “ 问题解
9、 ” 的形式 ，而后不断地具体化 ， 不断地用面向过程的语言描述问题 ， 最后在最低的抽象级别上给出可直接实现的 “ 问题解 ” ，即程序。抽象分为过程抽象和数据抽象。19. 抽象：关注事物基本、重要的部分，忽略不相关成分 抽象可以使我们的思维聚焦于问题本质，从而简化问题，控制问题复杂度，支持复杂、庞大软件系统的开发计科 08软件工程材料20. 逐步求精 ： 是一种自顶向下设计策略 ， 针对某个功能的宏观描述 ， 用逐步求精的方法不断地分解，逐步确立过程细节，直至该功能用程序语言描述的算法实现为止。21. 模块化 ： 把软件划分为可独立命名和编址的部件 ， 每个部件称为一个模块 ， 当把所有模
10、块组装到一起时，便可获得问题需要的一个解。22. 模块化是 , 将复杂的系统分 解为一个个相对独立的模块来加以 实现，有助于抽象和信息隐藏以及表示复杂的系统23. 信息隐蔽 ： 信息隐蔽是指在设计和确定模块时 ， 使得一个模块内包含的信息 （ 过程和数据 ） ，对于不需要这些信息的其他模块来说是不能访问的。24. 信息隐蔽：模块中的软件设计决策信息封装起来的技术，只知道它的功能以及对外的接口 ，而不知它的内部细节 , 有助于软件开发人员的注意力集中于更高的抽象层次25. 扇出率：该模块直接控制的其他模块数。26. 扇入率：能直接控制该模块的模块数。27.软件测试： 软件测试就是利用测试工具按照
11、测试方案和流程对产品进行功能和性能测试 ， 甚至根据需要编写不同的测试工具 ， 设计和维护测试系统 ， 对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。28. 测试阶段的信息流程图 （右图）a) 软件配置由需求说明书、设计说明书和源代码组成 ;b)测试配置中包含测试计划 、 测试工具 、 测试用例和期望结 果 , 有时 测试配 置亦作 为软件 配置的 一个组 成部分。c ) 测 试人员 根据 上述 输入 信息 测试 程序 并评价 测试 结果 , 当 测 试结 果 与 期 望结 果 存 在 差异 时 , 往 往 程序 有错。此时可采用排错技术定位错
12、误并改正之。d)通过 对测试 结果的 收集和 评价 , 软件 质量和 软件可 靠性的一些定性指标即能逐步确定下来。29. 黑盒测试：已知产品应该具有的功能，通过测试检验每个功能是否都能正常使用。30. 白盒测试 ： 已知产品内部工作过程 ， 通过测试检验产品内部动作是否按照规格说明的规定正常进行。31. 软件维护的分类 ： 纠错性维护 、 适应性维护 、 改善性维护和预防性维护 。 （ 每类的定义 P335）a) 改正性维护是为诊断和改正软件系统中潜藏的错误而进行的活动。b) 适应性维护是为适应环境的变化而修改软件的活动。c ) 改善性维护是根据用户在使用过程中提出的一些建设性意见而进行的维护
13、活动。d) 预防性维护是为进一步改善软件系统的可维护性和可靠性 , 并为以后的改进奠定基础。32. 软件重用：是指在两次或多次不同的软件开发过程中重复使用相同或相似元素的过程。33. 软件总体结构设 计的目标是：产生一个模块化的程 序结构并明确各模块之间的控制关 系 , 此外还要通过定义界面 , 说明程序的输入输出数据流 , 进一步协调程序结构和数据结构。34. 详细设计 任务 : 细化概要设计所生成的各个模块 , 并详细描述程序模块的内部细节 ( 算法 ， 数据结构等 ) ，形成可编程的程序模块，制订单元测试计划 。35. 系统总体结构设计任务：建立软件系统的总体结构。36. 详细根本目标
14、： 是确定应该怎样具体地实现所要求的系统 , 得出对目标系统的精确描述。大题：1 DFD图（ 0 层， 1 层， 2 层 ） ，给出相应的数据字典，及写出类图 。 （建模题 P120） （ 15分）参考题目 ： 阅读下列说明和 数据流图 ， 回答问题 1 至问题 3， 将解答填入答题 纸的对应栏内 。 说明 某图书馆管理系统的主要功能是图书管理和信息查询。对于初次借书的读者 ， 系计科 08软件工程材料统自动生成读者号，并与读者基本信息（姓名、单位、地址等）一起写入读者文件。系统的图书管理功能分为四个方面：购入新书、读者借书、读者还书以及图书注销。1 购入新书时需要为该书编制入库单。入库单内容
15、包括图书分类目录号、书名、作者 、 价格 、 数量和购书日期 ， 将这些信息写入图书目录文件并修改文件中的库存总量 （ 表示到目前为止，购入此种图书的数量 ） 。2 读者借书时需填写借书单 。 借书单内容包括读者号和所借图书分类目录号 。 系统首先检查该读者号是否有效 ， 若无效 ， 则拒绝借书 ； 若有效 ， 则进一步检查该读者已借图书是否超过最大限制数（假设每位读者能同时借阅的书不超过 5 本 ） ，若已达到最大限制数，则拒 绝3 读者还书时需填写还书单 。 系统根据读者号和图书分类目录号 ， 从借书文件中读出与该图书相关的借阅记录 ， 标明还书日期 ， 再写回到借书文件中 ， 若图书逾期
16、 ， 则处以相应的罚款。4 注销图书时，需填写注销单并修改图书目录文件中的库存总量。系统的信息查询功能主要包括读者信息查询和图书信息查询 。 其中读者信息查询可得到读者的基本信息以及读者借阅图书的情况 ； 图书信息查询可得到图书基本信息和图书的借出情况 。 图书 管理系统 的顶层图 如图 1-1 所示 ；图书管 理系统的 第 0 层 DFD 图如 图 1-2所示，其中加工 2 的细图如图 1-3 所示。【数据流图 1-1】 问题 1（ 2分）数据流图 1-2中有两条数据流是错误的，请指出这两条数据流的起点和终点。 问题 2（ 6分）数据流图 1-3中缺少三条数据流，请指出这三条数据流的起点和终
17、点。计科 08软件工程材料 问题 3（ 7分）根据系统功能和数据流图填充下列 数据字典 条目中的（ 1）和（ 2） ：查询请求信息 = 查询读者请求信息 | 查询图书请求信息 读者情况 =读者号 +姓名 +所在单位 +借书情况 管理工作请求单 = （ 1）入库单 = （）解答： 问题 1（ 1） “2处理查询请求 ”到 “ 读者文件 ”的数据流；（ 2）从 “读者文件 ”到 “ 3登记读者信息 ”的数据流。 问题 2（ 1）从 “借书文件 ”到 “ 2.1读者信息查询 ”的数据流；（ 2）从 “借书文件 ”到 “ 2.2图书信息查询 ”的数据流；（ 3）从 “图书目录文件 ”到 “ 2.2图书
18、信息查询 ”的数据流。 问题 3（ 1） 入库单 | 借书单 | 还书单 | 注销单 ；（ 2）分类目录号 +书名 +作者 +价格 +数量 +购书日期。一些说明：定义数据流、数据元素和数据存储如下规定符号：= 表示 “定义为 ”+ 表示 “与 ” 如，学生情况学号 +姓名 +地址；I 表示 “或 ” 如 , 性别男 I 女；( ) 表示 “ 可选 ” ， 如 , 存款单 =储户帐号 +存款额 +日期 +(密码 ) ，表示存款时可以不带密码；m . . n 表示值域 如 , 星期 =1 7，月份 =1 12； 表示重复若干次。例如，学生情况学号 +姓名 +电话 ； 表示重复自 m 次至 n 次；
19、例如，学生情况学号 +姓名 +电话 ； 表示 “多选一 ”。例如，如 , 政治面貌 团员 I 党员 I 民主人士 ；数 据 流 图 有 四 种 基 本 图 形 符 号 ： “ ” 箭 头 表 示 数 据 流 ； “ ” 圆 或 椭 圆 表 述 加 工 ； “ = ” 双 杠 表 示 数 据 存 储 ；“ ” 方 框 表 示 数 据 的 源 点 或 终 点 。 ( 如 上 图 )2 是 能读懂顺序图、协作图等面向对象设计方法中的图 。 （解答题 P232）计科 08软件工程材料简单消息 ( Si mpl e Message) 以一种简单 、 抽象的函数表示对象之间的信息传递 ， 不考虑通信过程的
20、内部细节。简单消息在 UML 顺序图中用普通的有向箭头表示。同步 消息 ( Synchronous Message) 消息源 发出消息后 必须等待消 息处理过程 完毕并返回处理结果后 ， 消息源才可继续执行后续操作 。 同步消息的表示图元与简单消息相同 ， 这表 明UML 在缺省情形下认为简单消息即为同步消息。异步消息 ( Asynchronous Message) 表示 ， 消息源发出消息后不必等待消息处理过程的返回 ，即可继续执行自己的后续操作。异步消息主要用于描述实时系统中的并发行为。返回消息 ( Ret urn message) 表示前面发送的消息的处理过程完结之后的返回结果 。 返回
21、消息应该是同步的。在许多情况下，可以隐藏返回消息，但也可显式标出返回消息以示强调。以上是 协作图 的两种等价表示“ 1.1 m s g2 ” 表明 m s g2 是 “ 对象 1” 为了处理 “ 1. m s g1 ” 而发送的第一条消息“ 1.2 m s g4 ” 是 “ 对象 1” 为了处理 “ 1. m s g1 ” 而发送的第二条消息“ 1.1.1 m s g3 ” 表明 m s g3 是 “ 对象 2” 为了处理 “ 1.1 m s g2 ” 而发送的第一条消息，依此类推。精化类图 ：在 UML 交互图中，可以利用交互图精化分析模型中的类图，将交互图中出现的新类添加到原有类图中 ，
22、并且对相关的类进行精化 ， 定义其属性和操作 。 原则上 ， 类的一个操作可能具有响应多条消息的能力 ； 两个类之间的一条连接关系也可以为多条消息提供传递通道 。 为了简化设计模型 ，应该尽量使用已有的操作来响应新消息 ， 并尽量使用已存在的连接路径作为消息传递的通道 。 如果两个类之间存在明确 、 自然的聚合或组合关系 ， 则可以在类图中直接用相应的 UML 图元符号表示类间的聚合和组成关系，这两个关系均可提供消息传递通道 。 （图在下方）状态图用来描述一个特定类的对象的所有可能状态以及因事件而引起的状态转移。状态图的结点包含状态名和活动 ( ac t i vit y)两部分内容。活动是可选
23、的，它们又分为四种：( 1)entr y 活动：一旦对象进入该状态，相应的活动被触发执行。( 2) exit 活动：一旦对象离开该状态，相应的活动被触发执行。( 3)do活动：当对象位于该状态时，执行相应的活动，对象的状态不变。( 4)on-event活动：当对象位于该状态并且接收到某一事件后，执行相应的事件响应活动。计科 08软件工程材料一张状态图可以包含一个初态，一到多个终态。计科 08软件工程材料“ proces s ” 状 态 由“ Chec king” 、 “Wai t i ng”和“ Di s pat ching” 三个子状 态经过 or合成构成“ auth” 状 态 由“ Aut
24、hori zi ng” 、 和“ Authori zed ” 两 个 子 状 态经过 or合成构成。状 态 图 适于 表 示 跨 越 多 个 用例 的 单 个对象的行为。在面向对象的设计过程中 ， 只要针对具有明显的状态特征 、 并且具有比较复杂的状态 - 事件 - 响应行 为的类设计 状态图即可。在 “ 家庭保安系统 ” 中， “监测器 ”类的对象具有比较明显的状态特征 ， 其状态图表示如图 10.16所示。活动 图适 于表示 用例 中的事 件流和 过程 ，也可 以用 来表示 复杂的算法以及并发处理进程。在 面 向 对 象 的 详 细 设 计 过 程中， 只要 针对具 有比 较复杂 的处理 过程 、并且 比较 重要的 方法设 计活 动图即 可。 此外， 如果 需 要 强 调 处 理 过 程 中 并 行性，应该使用活动图。在 “ 家庭保安系统 ”中， “用户命令 处 理 ” 类 中 的 procCm d 方 法和 “ 监 测 器 ” 类 中 的anal yseSensorDat a 方 法 相 对 比较复 杂， 它们的 活动 图分别 见图 10.17和图 10.18。
