软件构造中的设计

*软件构造中的设计

DesigninConstruction621*提纲引言设计中的挑战关键的设计概念——管理复杂度启发式的设计方法——如何管理设计实践总结622*引言在不同的项目中，很多设计工作都是程序员在构造过程中完成的在小型项目中，设计常常被作为构造活动的一部分在中型项目中，正规的构架只解决了系统级的事项，而大部分的设计工作留在了构造活动中在大型项目中，程序员通常对部分程序进行设计623*项目规模和生产率的关系表项目规模和生产率624序号项目大小（行数）每人年的代码行数11K2500~25000（4000）210K2000~25000（3200）3100K1000~20000（2600）41000K700~10000（2000）610000K300~5000（1600）讲课线索*设计具有挑战性原因：系统的复杂性如何减少系统复杂性理想的设计特征减少复杂性的实践方法625*1.设计中的挑战设计就是把需求分析和编码调试连在一起的活动软件设计意味着去构思、创造或发明一套方案，把一份计算机软件的规格说明书转变为可实现运行的软件软件设计中存在大量的不确定性，面临具体的挑战626*1.1设计是一个险恶的问题险恶的问题就是那种只有通过解决或部分解决才能被明确的问题进一步说，你必须首先把这个问题解决一遍以便能够明确地定义它，然后再次解决该问题，从而形成一个可行的方案627*1.2设计是个了无章法的过程软件设计的过程往往是了无章法的，在这个过程中经常会采取很多错误步骤，犯错正是设计的关键所在，如能在设计阶段改正错误则可以节约成本优、劣设计之间的差异往往非常微妙另外，也很难判断设计何时完成，很多时候是到没有时间为止628*1.3设计是不确定的对于同一个软件程序（功能相同），让不同的人进行设计，会得出完全不同的设计结果，而这些设计都可以完成软件比如：我们的Chart项目，要求一样，但几十个学生就会得出不同的设计方法再比如：类之间通信的方式有多种，方法调用，消息发送…629*1.4设计是一个启发式的过程由于设计过程充满不确定性，设计技术也就趋于探索性，“经验法则”或者“试试没准能行的办法”是可行的，设计过程总会有实验和犯错误在现实世界里，设计工作者的一个关键内容便是去衡量彼此冲突的各项设计特征，并尽力在其中寻求平衡6210*1.5设计是自然而然形成的设计不是在头脑中直接跳出来的，它是不断的设计评估、非正式讨论、写试验代码以及修改实验代码中演化和完善的几乎所有的系统在开发的起始阶段经历过某种程度的设计变更，而当它们进入后续版本后通常会进行更大的改变6211*2.关键的设计概念软件的复杂度理想的设计特征设计层次6212*2.1管理复杂度软件的首要技术使命便是管理复杂度当项目由技术因素导致失败时，其原因通常就是失控的复杂度Dijkstra指出，没有谁的大脑能容得下一个现代的计算机程序，也就是说，作为软件开发人员，我们不应该试着在同一时间把整个程序都塞进大脑中6213*2.1.1偶然的问题和本质的问题Brooks指出，两类不同的问题导致软件开发变得困难——本质的问题和偶然的问题本质的属性是一件事物必须具备的属性偶然的属性是一件事物碰巧具有的属性，没有这些属性不会影响事物本身相对而言，软件开发中大部分偶然性难题得以解决，而本质性的难题进展缓慢6214*2.1.2本质的难题来自多个方面本质上说软件开发就是不断去发掘错综复杂、相互连接的整套概念的所有细节，其本质性难题来自多个方面：必须面对复杂，无序的现实世界精确而完整地识别出各种依赖关系与例外情况设计出完全正确而不是大致正确的解决方案6215*2.1.3本质复杂性举例准确的中长期天气预报带方言的自然语言识别汽车自动驾驶技术自主医疗诊断系统…6216*问题你如何解决各种复杂性的问题6217*2.1.4如何应对复杂度可以用两种方法来管理复杂度：把任何人在同一时间需要处理的本质复杂度减到最少，比如系统分解不要让偶然性的复杂度无限地快速增长，比如保持子程序的短小精悍6218*2.2理想的设计特征高质量的设计具有很多常见的特征，如果实现这些目标，那就是高质量的设计但这些目标有可能是相互冲突的：最小的复杂度(Minimalcomplexity)易于维护(Easeofmaintenance)松散耦合(Loosecoupling)可扩展性(Extensibility)可重用性(Reusability)6219*2.2.1理想的设计特征（续）高扇入(highfan-in)低扇出(lowfan-out)可移植性(Portability)精简性(Leanness)层次性(Stratification)标准技术(Standardtechniques)6220*2.3设计的层次通常需要在一个软件系统的若干不同层次上进行设计：软件系统子系统类子程序程序内部6221*2.3.1软件系统系统代表要构建的整个软件，比如学籍管理系统，心电监护系统，飞机控制系统等等系统代表完成软件的整个功能，质量要求，但不包含实现的细节，因此只有分解后才利于理解和设计6222*2.3.2分解为子系统或包在这一层次上主要成果是识别出所有主要的子系统，比如：数据库，用户界面，业务规则，命令解释器，报表引擎等6223用户界面图形数据存贮业务规则企业级工具应用程序级的类一个有六个子系统的系统示例*2.3.2.1简化子系统的交互简化子系统之间的交互关系便于系统维护：最简单的交互关系是一个子系统调用另一个子系统中的子程序复杂一点的交互关系是一个子系统中包含另一个子系统的类最复杂的交互关系是让一个子系统中的类继承自另一个子系统的类6224*2.3.2.2不同的子系统交互方式6225用户界面图形数据存贮业务规则企业级工具应用程序级的类用户界面图形数据存贮业务规则企业级工具应用程序级的类不限制通讯限制通讯*2.3分解为类在这一层次上的设计包括识别出系统中所有的类定义好类与系统其余部分打交道的细节，尤其重要的是确定好接口另外就是要区分类和对象6226*2.4分解成子程序这一层的设计包括把每个类细分为子程序第3层定义了接口，第4层设计将细化出类的私有子程序完整地定义类内部的子程序，常常有助于更好地理解类的接口6227*2.5子程序内部的设计在子程序层次上进行设计就是为每个子程序布置详细的功能子程序内部的设计工作通常是由负责该子程序的开发人员来完成的，这里的工作包括：编写伪代码，选择算法、组织子程序内部的代码块以及用编程语言编写代码等6228*3启发式设计方法找出现实世界中的对象形成一致的抽象封装实现细节当继承能简化设计时就继承信息隐藏找出容易改变的区域保持松散耦合查阅常用的设计模式其它启发式的设计方法6229*3.1找出现实世界中的对象面向对象设计的步骤：辨识现实世界中的对象和人造对象辨别对象的属性确定对象的操作确定对象的可见属性定义每个对象的公开接口6230*3.2形成一致的抽象抽象是关注某一概念的同时忽略其中一些细节的能力基类是一种抽象，它关注一组派生类所具有的共同特性接口也是一种抽象，它关注于接口本身而不是其内部工作方式抽象是处理现实世界复杂度的一种好的方法6231*3.3封装实现细节封装填补了抽象的空白，抽象关注外部，封装关注内部封装将对象的复杂性隐藏在内部，对外部则不可见6232*3.4信息隐藏信息隐藏是结构化程序设计与面向对象设计的基础隐藏的内容包括：隐藏复杂度隐藏变化源，将变化源的影响限制在局部6233问题抽象、封装和信息隐藏之间是什么关系？6234**3.4.1信息隐藏的障碍信息隐藏的障碍如下：信息过度分散，比如在程序中到处使用数值常数：100，20等等循环依赖，比如A调用B，B又调用A把类内数据误认为全局数据可以察觉的性能损耗6235*3.5找出容易改变的区域好的设计就是要适应变化，目标是隔离易变区域，方法如下：找出看起来容易变化的项目把容易变化的项目分离出来把看起来容易变化的项目隔离开来6236问题你认为你的程序中哪些部分容易改变？6237**3.5.1容易变化的区域程序中容易变化的区域如下：业务规则，比如银行利率对硬件的依赖性，更换硬件输入输出非标准的语言特性困难的设计区域和构建区域状态变量（使用枚举或判定函数）数据量的限制（比如数组大小）6238*3.6保持松散耦合耦合度表示类与类之间，子程序与子程序之间关系的紧密程度耦合度的设计目标是创建出小的、直接的、清晰的类或子程序，使它们与其它类或子程序之间关系尽可能地灵活，即“松散耦合”模块之间好的耦合关系会松散到恰好能使一个模块很容易被其它模块使用6239*3.6.1耦合标准衡量耦合度的标准如下：规模 模块之间的连接数，比如接口数，子程序的参数数等可见性 可见性指的是两个模块之间的连接显著程度，比如直接传递参数而非全局量进行耦合灵活性 灵活性指模块之间的连接是否容易改动6240*3.6.1.1可见性举例下面代码为什么要调用Set_Status()函数？///1.------------------实时状态下的暂停标志为真，简单设置暂停标志为假即可.if((m_System_Status.Get_Status()==SYSTEM_REAL_TIME_SAMPLE)&&(m_System_Status.Get_Pause_Flag())){///1.1------------设置系统暂停标志.--------------------------------m_System_Status.Set_Pause_Flag(false);///1.2------------告知显示类系统暂停.------------------------------m_pWaveRightView->PostMessage(WM_SYSTEM_PAUSE,0,(LPARAM)(false));m_System_Status.Set_Status(SYSTEM_REAL_TIME_SAMPLE);return(true);}6241*3.6.1.2

Set_Status函数内部Set_Status()函数中包含不可见的耦合关系voidCSystem_Status::Set_Status(shortshStatus){

///1.------------------修改状态.----------------------------------------m_shStatus=shStatus;

///2.------------------通知注册窗口系统状态发生变化.----------Notify();}6242*3.6.2耦合的种类从松耦合到紧耦合：简单数据参数耦合 两个模块之间传递简单数据类型的参数，这种耦合关系是正常的简单对象耦合 一个模块实例化一个对象，这种耦合关系也是正常的6243*3.6.3耦合的种类（续）对象参数耦合 以对象为参数在模块之间传递称为对象参数耦合，这种耦合关系比较紧密，要求了解传入对象的情况语义上的耦合 一个模块不仅使用了另一个模块的语法元素，还需要使用其内部工作细节的语义知识，这是最紧密的耦合，也非常危险，需要尽量避免6244*3.6.4语义耦合的方式语义耦合的例子如下Module1向Module2传递了一个控制标志Module2在Module1修改了某个全局数据之后使用该全局数据Module1把Object传给Module2，但Module1自认为Module2只使用部分Object的功能，因此也只部分初始化，形成假设耦合Module1把BaseObject传给Module2，但Module2认为传入的是DerivedObject模块之间函数调用顺序的依赖6245*3.7查阅常用的设计模式设计模式是对已有问题的标准解决方案，有以下好处设计模式通过提供现成的抽象来减少复杂度设计模式通过把常见方案的细节予以制度化来减少出错设计模式通过提供多种设计方案而带来启发性的价值设计模式通过把设计对话提升到一个更高的层次来简化交流6246*3.7.1设计模式的陷阱应用设计模式的一个陷阱是强迫代码适用于某个设计模式应用设计模式的另一个陷阱是为了模式而模式6247*3.8其它的启发式设计方法高内聚性构造分层结构严格描述类契约（保证前条件和后条件正确）分配对象职责为测试而设计避免失误（充分考虑失败模式）有意识地选择绑定时间创建中央控制点（错误处理）考虑使用蛮力突破（神经网络）画一个图保持设计的模块化6248*3.9管理复杂度的方法在构架层将系统划分为多个子系统，以便某段时间只专注于系统的一部分仔细定义类接口，从而可以忽略类内部的工作机理保持类接口的抽象性，从而不必记住不必要的细节避免全局变量避免深层次的继承避免深度嵌套的循环或条件判定6249*3.9.1管理复杂度的具体方法续不要让类过度膨胀，最终占据整个程序子程序应保持短小精悍使用清楚、不言自明的变量名传递给子程序的参数数据应尽量少用规范和约定摆脱随意性和偶然性错误小心定义错误处理方法以系统观点对待内置的异常机制6250*4设计实践迭代分而治之自上而下和自下而上的设计方法建立实验原型合作设计要做多少设计才够记录你的设计成果6251*4.1迭代设计是一种迭代过程可以同时从高层和底层的不同角度去审视问题。高层视角中得出的大范围途径有助于低层细节的考虑，而底层视角中获得的细节也为高层的决策奠定基础对于不同层次的方案通过迭代逐渐完善6252*4.2分而治之分而治之的方法是一种降低复杂度的方法通过将系统在不同层次上的分解，使某一个时刻只关注于系统的某一层次或某一方面的细节，使得系统更容易理解6253*4.3自上而下和自下而上的设计方法自上而下从某个高层的抽象开始，向细节扩展；自上而下的分解通过迭代的方式完成系统的分解，直到设计思路已经显而易见并且易于理解为止自下向上的设计始于细节，向一般性扩展6254*4.3.1自上而下和自下而上是融合的自上而下的设计是分解，自下而上的设计是合成，在设计中，两种方法通常会同时考虑同时使用自上而下的方法通常更易于理解，推迟细节的设计，对细节的把控不利，自下而上的正好弥补其不足6255*4.3.2自上而下和自下而上举例62