软件工程习题及解答

软件工程习题及解答内容摘要：

得到 Jones 记录。 现在事务记录关键字与旧的主文件记录关键字相同，正如从事务文件中看到的那样，先修改旧的主文件记录（ Jones记录），然后把它删除，以便读取下一个事务记录（ Smith）和下一个旧的主文件记录 （也是 Smith）。 遗憾的是，事务类型是 1（插入），但是在旧的主文件中已经有 Smith记录了，因此，在输入数据中有错误，将 Smith记录写入异常报告中。 更确切地说，将 Smith事务记录写入异常报告，而把Smith旧的主文件记录写入新的主文件。 总结上述例子中揭示出的处理过程，得到表。 表 处理规则 根据表 ，可以对图 “处理”框求精，得图 二步求精结果。 为减少连线（特别是为了减少交叉线），在这张流程图中用标有相同字母（例如，字母 A） 的圆代表应该连在一起的点。 图中连到“输入”和“输出”方框的虚线表示把如何处理输入和输出的设计决定推迟到较晚的求精步骤中再做出，该图其余部分是实现“处理”的流程图，或者说是对处理事务的算法的初步求精结果。 正如刚才讲过的，已把对输入和输出问题的考虑推迟了，此外，还没有规定文件结束的条件，也没有规定遇到出错条件时应该怎么处理。 逐步求精方法的优点就在于可以把这类问题推迟到后面的求精步骤中去解决。 图 第二步求精 下一步设计步骤是求精图 中的“输入”和“输出”两个处理框，得到图 ，在这个设计 步骤中仍然没有处理到文件结束的条件，也没有写入工作结束的信息，这些设计工作可以在后面的求精步骤中完成。 使用逐步求精方法设计软件时，每完成一个求精步骤都必须对这个求精步骤得出的设计结果仔细审查，没有发现错误才能进行下一个求精步骤的设计工作，如果发现了错误则应该及时纠正。 审查图 ，该设计包含一个严重错误。 考虑图。 假设当前的事务是 2Jones，也就是修改 Jones记录，也就是修改 Jones记录，并且当前的旧的主文件记录是 Jones。 在图 ，因为事务记录 的关键字与旧的主文件记录的关键字相同，沿最左边的路径到底“测试事务类型”判定框。 因为当前的事务类型是“修改”，所以修改旧的主文件记录并把修改后的记录写入新的主文件。 然后读取下一个事务记录，该记录是 3Jones，也就是删除 Jones 记录，但是，已经把修改后的 Jones记录写入新的主文件记录了。 在用逐步求精方法设计软件的过程中对每个求精步骤得出的设计结果都进行严格审查的好处是，一旦发现错误，不必从头开始重做一遍，只需回到前一步的设计结果，从那里开始重新设计即可。 在本设计中，第二步求精的结果（见图 ）是正 确的，可以把它作为第三步求精的基础。 图 第三步求精（有严重错误） 正如刚才讲过的，图 ，当事务类型为 2（修改）时没有考虑下一个事务的影响，就把修改后的主文件记录写入新的主文件中。 为了改正上述错误，我们采用“前瞻一步”的策略，也就是说，只有在分析了一个事务类型的下一个事务记录之后，才能处理该事务记录。 更具体地说，当一个事务记录的类型为“修改”时，修改缓冲区中的旧主文件记录，然后读取下一个事务记录，如果刚读出的事务记录的关键字与缓冲区中的旧文件记录的关键字不相同，则把缓冲 区中已经修改过的旧主文件记录写入新的主文件；如果新读出的事务记录的关键字与主文件记录关键字相同，则依据新的事务记录的类型来处理缓冲区中的旧主文件记录。 由于事务文件是预先排好序的，当新读出的事务记录与主文件记录有相同的关键字时，也就是新读出的事务记录与前一个事务记录是针对同一个订户的事务的，新读出的事务记录的类型只可能是“修改”或“删除”（已知前一个事务记录的类型是“修改”）。 采用“前瞻一步”的设计策略，得出图。 图 改正错误后的第三步求精 为简单起见，当针对同一个订户有多个事务时，仅考虑了在修改事务之后又有修改事务或删除事务的情况。 实际上，如果对事务文件先进行预处理，使得针对每位订户最多只有一个事务，则更新顺序主文件的算法可大大简化。 下面列出对事务文件可能做的一些预处理：如果针对同一个订户有多个修改事务，则仅保留最后一个修改事务（本问题中的主文件记录仅有订户姓名和地址两项信息，多次修改地址则以最后一次修改为准）；若插入一位新订户记录后，又有零或多个修改事务，最后是一个删除事务，则略去这一系列事务；若对一个订户记录既有修改事务又有删除事务，则略 去修改事务，仅保留删除事务；若针对一位订户既有插入事务又有修改事务，则用修改事务的内容（地址信息）更正插入事务的内容（地址信息），然后删去这个修改事务。 在第 4次求精的过程中，应该考虑迄今为止被忽略的诸如打开和关闭文件这样的细节问题。 采用逐步求精方法设计软件时，这样的细节问题是在基本算法被完全设计出来之后，最后处理的。 显然，不打开和关闭文件，程序是不可能正常运行的，也就是说，这些问题是必须处理的，但是，重要的是，处理这类细节问题应该在设计的最后阶段进行。 在设计的早期阶段，设计者集中精力关注的 7 个左右问题是不 应该包括打开和关闭文件这样的细节问题的。 打开和关闭文件与特定软件的设计无关，它们只是作为任何设计的一部分的实现细节。 然而，在后面的求精步骤中，打开和关闭文件变得重要起来，必须加以处理。 从前述设计过程可知，可以把逐步求精方法看作是建立在某个阶段内需要解决的各种问题的优先级的一种技术。 逐步求精方法能够确保每个问题都得到解决，并且是在合适的时间解决，在任何时刻都不需要同时考虑 7个以上的问题。 ：从图 ，这个程序的功能是计算若干个指定地点的每日平均温度。 变量 sum保存某地一天之内在指 定的时间取样点的温度之和。 程序运行时首先初始化变量 sum并打开文件，然后读取地点、时间和温度等原始数据，创建用于保存这些数据的温度记录，接下来计算特定地点的日平均温度，存储温度记录。 重复调用“读取地点、时间和温度”、“创建新的温度记录”、“计算特定地点的日平均温度”和“存储温度记录”等模块，直至计算出并保存好所有指定地点的日平均温度。 最后，打印平均温度并关闭文件。 从上述叙述可知，“计算多个地点的日平均温度”、“读取地点、时间和温度”、“创建新的温度记录”、“计算特定地点的日平均温度”和“存储温度记录”等 5个模块，每个都完成一个单一的功能，模块内所有元素都为完成同一个功能服务，彼此结合的十分紧密，因此，这 5个模块的内聚类型都是功能内聚。 初看起来，由于初始化变量 sum和打开文件这两个操作都是在程序运行的初始阶段完成的，“初始化变量 sum和打开文件” 这个模块的内聚类型似乎是时间内聚。 但是，初始化变量 sum是本程序特有的操作，而打开文件是硬件要求的操作，是任何使用文件的程序都包含的一个操作，并非本程序特有的操作。 当可以分配两个或更多个不同级别的内聚类型给一个模块时，规则是分配最低级别的内聚类型给该模块。 因此，“ 初始化变量 sum和打开文件”这个模块的内聚类型都是偶然内聚。 同理，“关闭文件并打印平均温度” 这个模块的内聚类型也是偶然内聚。 ：综合分析图。 例如，当模块 p调用模块 q时（接口 1），它传递一个参数 飞机类型。 当模块 q把控制返还给模块 p时，它传回一个状态标志。 某些模块之间的耦合类型是明显的，例。