第一章程序设计回顾及软件设计导论

软件设计和体系结构谢兄信息科学技术学院[e-mail]教学内容软件过程设计原则设计模式应用示例体系结构实际设计案例研究软件进化再工程和逆向工程教学内容软件过程设计原则设计模式应用示例体系结构实际设计案例研究软件进化再工程和逆向工程你可以学到……武林高手扎马步武功招式武功秘诀编程高手编程语言设计模式设计原则实验实验内容：设计模式实验学时：10学时实验时间：软件工程（第14-18周周二7-8节实验地点：1，2班在201室，3，4班在205室实验报告：实验目的、实验要求、实验步骤、实验结果、总结参考书籍软件设计——从程序设计到体系结构，EricJ.Braude著，李仁发等译，电子工业出版社参考书籍HeadFirst设计模式，EricFreeman,ElisabethFreeman等著，中国电力出版社设计模式——可复用面向对象软件的基础，ErichGamma等著，李英军等译，机械工业出版社参考书籍软件体系结构，MaryShaw著，牛振东等译，清华大学出版社软件体系结构，张友生等著，清华大学出版社考试闭卷笔试70分实验成绩20分实验作业15分实验报告5分平时成绩10分课堂小测8分出勤2分软件危机(softwarecrisis)是指在计算机软件的开发(development)和维护(maintenance)过程中所遇到的一系列严重问题。1968年在原西德加密施(Garmish)召开的国际软件工程会议上开始被人们普遍认识到。软件危机如何克服软件危机如何克服软件危机人们面临的不光是技术问题，更重要的是管理问题。管理不善必然导致失败。要提高软件开发效率，提高软件产品质量，必须采用工程化的开发方法与工业化的生产技术。在技术上，应该采用基于重用的软件生产技术；在管理上，应该采用多维的工程管理模式。为了解决软件危机，既要有技术措施，又要有必要的组织管理措施。软件工程正是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。软件过程需求分析：定义程序必须做什么做什么？设计：定义每部分将是什么以及它们将如何协调如何做？实现（编码）：编写代码测试：以测试数据作为输入来执行应用程序维护：修补缺陷和增强功能动手做检验维修软件过程示例—个人理财需求分析：文本“…应用将显示用户银行账户的收支余额…”设计：图表和文本“…设计将包含类CheckingAccount…”实现：源代码和目标代码测试：整理测试数据，测试程序的执行结果“…测试示例：存款＄44.92/取款＄32.00…”维护：修改设计、代码和文本，纠错、功能增强软件过程的风格瀑布过程：一个基本的软件过程，其中需求分析、设计、编码、测试和维护都是按顺序完成的，但是各个阶段有一些重叠。维护软件过程的风格需求分析设计主要事件(s)阶段(活动性)实现测试维护发布产品X对于一个较短的周期，这两个阶段可能同时进行纯瀑布过程通常不实际的原因预先不知道所想要的和需要的通常很难提前给出所有细节仅能估计实现需求的成本为了准确估计，需要设计和精确实现各个部分，尤其是风险最大的部分可能需要修改需求常常需要执行中间件风险承担者要有信心设计者和开发者必须证实他们需要和想要构建的内容当需求处理快要完成时，小组成员要继续进行下一步的工作特别要让相关成员马上进行其他阶段的处理软件过程的风格螺旋过程：将几次遍历瀑布阶段，每一次通过瀑布阶段，将产生一个功能更强的中间产物，直到生成可传递的结果。时间1需求分析设计编码测试1迭代#11222333已发布的产品X中间版本*完整的X重要事件23231程序设计回顾及软件设计导论软件设计含义本书如何介绍软件设计目标软件设计符号函数的说明文档函数的编写习惯软件设计的含义表达的是应该怎样构造应用程序，描述所用到的各个部分，以及如何将它们组合起来。是一套文档，通常是各种示意图以及对这些图的具体含义的解释。在此基础上程序员能设计出软件应用程序类似于建筑物的蓝图从需求中产生，不包含代码UML是设计文档的一个非常有用的表示方法。软件需求分析软件需求软件设计软件实现软件设计实现框架需求分析体系结构详细设计设计原则工具:UML组件+组件关系可重用类型设计模式类+类间算法第一部分第二部分第三部分第四部分第1.2节函数的说明文档编码标准分类注释分析规范实例变量通过this.引用本书使用的编码标准例如：classCar{intmilesDriven;…}引用：this.milesDriven静态变量通过类名引用例如：classCar{StaticintnumCarsSold;…}引用：Car.numCarsSold参数前加前缀a/an例如：public…getVolume(intaLength){…}前置条件(precondition)：方法代码假设的非局部变量的条件包括参数方法本身没有提供这些条件的验证后置条件(postcondition)：执行后非局部变量的值包括参数注释：x’代表x执行后的值不变式(invariant)：函数执行后没有改变的非局部变量的关系在前置条件和后置条件中都相等在局部变量中也有不变式说明函数功能的分类注释返回(return)方法的返回值已知问题(knownissue)真实描述要做的内容，未被纠正的缺陷等限于所知道的说明函数功能的分类注释classRectangle{…//前置条件：长度10,宽度10//返回：长度×宽度…publicdoublearea(doubleaLength,doubleaBreadth)…}N流程图姓名无效?姓名截短姓名赋值姓名取默认值姓名太长?输出到控制台YYNprotectedfinalvoidsetName(stringaName){//检查姓名是否有效if((aName==null)||(maxNumCharsInName()=0)||(maxNumCharsInName()alltimeLimitOfNameLength())){name=newString(“defaultName”);System.out.printin(“defaultNameselectedbyGameCharacter.setName()”);}else//若姓名太长，则姓名截短if(aName.length()maxNumCharsInName())name=newString(aName.getBytes(),0,maxNumCharsInName());//若姓名不长，则姓名赋值elsename=newString(aName);}图1.5FOR操作员操作时间的微秒数IF操作时间超过临界值ENDFORENDIFIF功率超过临界值ENDIFIF(正确检查病人&正确安放防护物&机器自检通过）ENDIF需要得到管理者的允许IF管理者未允许ENDIF中止并提示“管理者未允许的异常值”中止并提示“功率过大”以功率p应用X射线伪代码流程图和伪代码的优点•算法清晰化•具体设计文档的过程更严格化•提供检查执行的补充标准–有助于在生成代码前捕获错误–提高可靠性•降低整体花费流程图和伪代码的缺点•要维护额外的说明文档•带来转换为代码时出错的可能性•需要产生伪代码和绘制流程图的工具函数/参数/变量的命名要具有表现力用传递参数代替全局变量防止错误数据:异常处理/默认处理/返回特殊值不要将参数作为方法变量给数字命名限制参数个数在6个或7个之内在临近使用变量时才定义它们初始化所有变量检查循环计数器避免3次以上的嵌套循环确保不是死循环编译前先检查编码好习惯manipulate(floataFloat,intanInt)getBaseRaisedToExponent(floataBase,intanExponent)函数/参数/变量的命名应该说明其用途(图1.9)extract(intanEntry){table=…}避免使用全局变量:考虑使用传递参数来代替extract(intanEntry,EmployeeTableanEmployeeTable)for(i=0;i8927;++i)给数字命名intNUM_CELLS=8927for(cellCounter=0;cellCounterNUM_CELLS;++cellCounter)软件设计的目标正确性、充足性、模块性和可读性确保代码按照需求执行健壮性设计和实现能处理各种各样的异常情况（如数据错误、用户错误、环境条件）灵活性适应各种改变，易于修改对已存在的操作增加适当的功能范围增加新功能改变功能软件设计的目标可重用性对象代码类（以源代码形式）相关类的聚合类聚合模式高效性利用可用的机器时间周期和内存尽可能快地创造设计和实现可靠性可用性软件设计准则•软件设计的重要性表现在软件的质量。如何设计才能保证质量？这里，我们给出软件设计的一般原则：（1）要有分层的组织结构，便于对软件各个构件进行控制；（2）应形成具有独立功能特征的模块（模块化）；（3）应有性质不同、可区分的数据和过程描述（表达式）；（4）应使模块之间和与外部环境之间接口的复杂性尽量地减小；（5）应利用软件需求分析中得到的信息和可重复的方法。