软件工程(软件实现).pptVIP

编码原则 简单性原则 使用简单的程序结构（顺序、判定、循环，避免使用递归）。 使用简单的数据结构（数组、列表，避免使用树和图）。 使用简单的算法（使用常规算法） 可读性原则 变量命名有意义（匈牙利命名法） 程序入口出口有注释 判定结构和循环结构有注释 函数和子程序调用有注释 自顶向下，逐步求精 注释编程法（先用注释描述程序结构，然后针对每个注释添加代码） 滚雪球法（先完成基本代码，调试成功后，在进行其他代码编写） 可调试原则 增加断言 处理异样 增加调试信息 输出日志 编码的任务 两个相关概念 实现：体现“如何做”的程序文本称为实现。 规范：“做什么”的形式化描述通常称为规范。 编码阶段的任务： 编写源程序（source code)； 编写文档（document)； 单元测试（unit testing)。 软件质量主要取决于设计的质量，但不能忽略编码和程序设计语言的影响 编码需要遵循一定的标准，形成编码风格。 编码任务的流程 微软开发的经验—注重标准 标准有助于交流，讨论问题，解决问题。 微软要求各自的小组收集一系列测试结果，包括出错信息和发现的潜在和修改了的错误。当继续开发产品时，这些测试结果指导将来的决策。 标准有助于把设计转化为代码和软件重用。 按照标准把代码结构化，你可以保留代码和设计中的相同部分。因此，设计的变化很容易在代码中体现。 程序设计语言 结构化语言和面向对象语言 C C++ Java C# 泛性编程 强类型和弱类型 类型转换（Vector） 脚本 JavaScript 计算机语言的发展 描述性 交互方式多样化 自动生成和自动查错与纠错 选择编程语言 使用自己最熟悉的语言。使用熟悉语言比不熟悉语言效率要高30% 尽量使用高级语言 使用集成度高的开发工具 使用适宜的语言 程序设计风格 编写程序方法与步骤 编码风格 程序内部的文档 数据说明的次序标准化 语句结构应该简洁明了 效 率 满足human-engineering的I/O风格 其它的风格 程序内部的文档 程序内部的文档包括意义明确的标识符、适当的注释和标准化的书写格式等。 变量名、函数名、数据结构名等具有明显的意义，可以提高程序的可读性，便于测试、维护。 注释要简明、适当和正确。序言性注释主要描述模块的功能、主要算法、接口特点，重要的数据结构说明等；与程序代码有关的注释要插在程序中对应的位置，解释有关代码的作用和必要性。 程序清单的布局要有层次性，要求结构清晰。 数据说明的次序标准化 按照数据结构或数据类型确定说明的次序 对多个变量说明应该按照字母顺序排列 变量定义要其中 数值变量化 常量 语句结构应该简洁明了 尽量使用三种基本结构，允许使用扩展的结构化设计，尽量不用GOTO语句（或局部性使用）。 每行只写一条语句。 尽量避免复杂的条件判断和对“非”条件的判断。 避免大量使用循环嵌套和条件嵌套。 善于使用括号使表达式次序清晰直观。 效率 程序运行时间 时间复杂度 存储器效率 空间复杂度 输入/输出的效率 从效率第一到清晰第一（对大多数模块清晰第一，个别模块效率第一） 满足human-engineering的I/O风格 对输入数据进行有效性检验，防止对程序的破坏。 对多个相关输入项进行组合检查，剔除似是而非的输入值。 使用数据结束标记，不要要求用户用数据的数目来控制。 交互式输入的提示清楚，尽量说明可用的选择或边界数值。 程序设计语言对格式有严格要求时，应保持输入格式一致。 为输出数据加标志或加以必要的说明以提醒读者。 保持输入格式简单；设计良好的输出报表。 其它的风格 对用户提供在线帮助。 对可能产生重大后果请求给出醒目提示，待用户再次确认。 使程序具有“防弹bulletproof”功能，不至于因用户的偶然错误使程序发生非正常的中断。 数据输入界面设计 明确的输入：只有当用户按下输入的确认键时，才确认输入。 明确的动作：要使用TAB键或回车键控制在表格项间的移动。 明确的取消：如果用户中断了一个输入序列，已经输入的数据不要马上丢弃。 确认删除：为避免错误的删除动作可能造成的损失，在键入删除命令后，必须进行确认，然后才执行删除操作。 提供反馈：若一个屏幕上可容纳若干输入内容，可将用户先前输入的内容仍保留在屏幕上，以便用户能够随时察看，明确下一步应做的操作。 数据输入界面设计（续） 允许编辑：在一个文件输入过程中或输入完成后，允许用户对其编辑 提供复原 (Undo)：应允许用户恢复输入以前的状态。 自动格式化：用户可以采用自由格式进行输入。 提示输入的范围：应当显示有效回答的集合及其范围。 数据显示界面设计 只显示必需的数据。与用户需求无直接关系的一律省略。 在一起使用的数据应显示在一起 显示出的数据应与用户执