软件工程技术与设计第二讲学生

软件工程技术与设计第二讲学生第一页，共五十七页，编辑于2023年，星期三正确性资源结构工程用法解的完全性和正确性；静态类和动态类的安全性；多线程的安全性；容错性处理能力；保密性和鲁棒性。执行效率，时间复杂度、消息数、带宽要求等；空间消耗，包括存储单元、对象、线程、过程、通信通道。处理器等的使用情况；增加的资源，一些随选信息；动态策略，包括公正性、平衡性、稳定性等。模块性、封装、耦合、独立性；可延展性，包括子类、可协调性、发展性、可维护性等；可重用性、开放性、可组合性。便携性、可插入性；前后依赖性；互用性；等等。可理解性、简单、高雅；执行中的易错性；与其他软件的共存性；系统可维护性；开发过程的影响；开发队伍结构及动态特性的影响；用户参与的影响；生产力、时间安排、成本的影响；等等。使用规范；人为因素，如可学习性、恢复能力等；对不断变化的环境的适应性；艺术性；医学和环境的影响；社会、经济、政治的影响；等等。设计过程中，针对设计目标约束冲突给出的非功能性需求判断准则。第二页，共五十七页，编辑于2023年，星期三核心共同思想原则：重点解决软件系统可维护性和复用性矛盾。普遍基本单纯隐藏重现第三页，共五十七页，编辑于2023年，星期三可维护性好的系统应有性质(PerterCoad)

可扩展性容易加入新的性能灵活性代码修改少波及其他模块可插入性容易抽出加入类第四页，共五十七页，编辑于2023年，星期三传统的复用代码的剪贴复用算法的复用数据结构的复用程序１程序４程序３程序２代码/算法/数据结构第五页，共五十七页，编辑于2023年，星期三传统的复用的风险：影响可扩展性——过于僵硬修改多个软件成分中复用源代码时，需要独立地修改检测每一拷贝。很难在一个软件系统里加入一个新功能。影响灵活性——过于脆弱对一个地方的修改会导致另一个地方发生故障，难以跟踪代码的变异和使用。模块A和B同时使用模块C的功能。那么当A需要C增加一个新的行为的时候，B有可能不需要、甚至不允许C增加这个新行为。影响可插入性——粘度过高代码、函数、模块对系统的依赖，改动意味着破坏原始意图和框架第六页，共五十七页，编辑于2023年，星期三面向对象设计的重要语言特性数据抽象继承封装多态性实现概念和定义复用，促进系统的可维护性。第七页，共五十七页，编辑于2023年，星期三接口（interface)：对象全部操作(对象可以处理的所有请求)的特征（操作的名称、参数和返回值）的集合。声明对象的类型（Type)——接口标记（signature)

包括：变量的类型声明参量的类型声明方法的返还类型声明数据类型的转换等第八页，共五十七页，编辑于2023年，星期三接口和类的区别：接口——只描述方法的特征，而不给出方法的实现，接口把方法的特征和实现分割开来。类——不仅给出方法的特征，面且给出方法的实现。接口常常代表一个角色（role)，它包装与该角色相关的操作和属性，而实现这个接口的类使是扮演这个角色的演员。一个角色可以由不同的演员来演．而不同的演员之间除了扮演一个共同的角色之外，并不要求有任何其他的共同之处。第九页，共五十七页，编辑于2023年，星期三类、类型和对象之间区别和联系:类(class)——定义了一类对象的共性实现，即对象的内部数据与其操作的实现。类型(type)——只涉及接口（即对象能作出反应的请求的集合）。类定义了一类对象可执行的操作，也定义了对象的类型。一个对象是一个类的实例指这个对象支持该类定义的接口。第十页，共五十七页，编辑于2023年，星期三同一种类型的对象共享接口部分同一类型接口的对象可以有不同实现，即不同类的对象可以有相同的类型。一个角色可以由不同的演员来演一个对象可以有多种类型。一个类可以同时实现几个接口。一个演员可以演不同的角色子类型包含(继承)了超类型的接口接口是实现构件可插入性的关键。第十一页，共五十七页，编辑于2023年，星期三抽象类——为子类定义通用接口。将实现由子类定义的操作完成。——可以拥有实例变量，以及一个或多个构造子(函数)。——构造子不能被调用来创建实例，抽象类不可以实例化。——构造子可以被子类调用，所有子类都可以有共有的实现抽象类通常代表一个抽象概念提供一个继承的出发点。由于抽象类不可以实例化，因此一个抽象类一定是用来继承的。第十二页，共五十七页，编辑于2023年，星期三抽象类和接口的区别抽象类允许有所有派生类公共的状态和行为。是一种相关实体聚集的方式。关注如何设计实现并封装这些具体实体（派生类），而不会与任何特定于实现的细节相耦合。接口关注点派生类或实现类的对象的使用。派生类或实现类的对象为了完成其功能应该有什么样的接口。没有实例变量和构造子(函数)第十三页，共五十七页，编辑于2023年，星期三抽象类的作用：用较少的冗余实现一组具有公共状态或行为的对象设计一个接口找出已定义对象的公共状态或行为用一个抽象类实现该接口从这个抽象类派生具有公共状态或行为的对象优点：使实现类更简单，更容易维护。第十四页，共五十七页，编辑于2023年，星期三具体类非抽象的类称为具体类，实现由自身完成。具体类可以实例化。可以实例化，给出一个有逻辑实现的对象模版。具体类不是用来继承的。（可以继承）第十五页，共五十七页，编辑于2023年，星期三混合类向其他类提供接口，也提供部分接口实现。与抽象类相似，不能用实例说明。可以继承第十六页，共五十七页，编辑于2023年，星期三假设蛋代表抽象，而鸡代表具体。蛋决定鸡的性伏，鸡是蛋的“实现”，蛋的类型决定了鸡的类型。从这个角度来讲，先有蛋，后有鸡。第十七页，共五十七页，编辑于2023年，星期三类继承和接口继承:继承：一个类是另一个类的子类类继承（实现继承）：——根据某个原有对象的实现来定义另一个新的对象的实现。——从已有类继承必要的需求。——共享编码和表示方法。接口继承：——是一个类实现了另一个类的一个接口——何时可用一个对象替换另一个对象。——共享类型。——只继承抽象类。第十八页，共五十七页，编辑于2023年，星期三[问题]：加入一个新的类,与现有具体类行为有不同的实现——动态的具体类可插入性问题1.使用超类继承：在类结构中增加一个超类,声明出子类要提供的行为为这个抽象超类提供多个具体子类，以不同的方法实现了超类所声明的行为。客户端动态地决定使用哪一个具体子类。第十九页，共五十七页，编辑于2023年，星期三如何在具体类继承结构中增加一个抽象超类：单继承的语言，一个类只能有一个超类。当具体类可能已经有了一个超类，不可能加上新的超类。加新的超类到已有的超类上面，形成超超类。或者继续向上移动，直到类等级结构的最顶端。——一个具体类的可插入性设计．就变成了对整个等级结构中所有的类的修改。可插入性没有保证。具体类超类新超超类新具体类。。。。。。与现有具体类行为有不同的实现第二十页，共五十七页，编辑于2023年，星期三2.使用接口概念在一个类等级结构中的任何类都是实现一个接口这个接口会影响到此类的所有子类，但是不会影响到此类的任何超类。此类将实现这个接口所规定的方法，而其子类则可以从此类自动继承到这些方法，子类可以选择置换其中的某一些方法或所有方法。这时候，子类就具有了可插入性。接口类具体类新具体类第二十一页，共五十七页，编辑于2023年，星期三关联的可插入性关联：一个对象知道其他对象针对接口的关联：不是针对具体类任何实现这个接口的类都可以满足关联要求。可以动态地将关联从一个具体类转换到另一个具体类第二十二页，共五十七页，编辑于2023年，星期三调用的可插入性对象调用其他对象的方法。针对接口的调用：不是针对具体类,而是一个接口。任何实现这个接口的类都可以被当前对象调用。可以动态地决定当前对象调用哪一个具体类的实例接口提供了方法调用上的可插入性。第二十三页，共五十七页，编辑于2023年，星期三软件系统的规模越大，生命周期越长，接口的重要性就越大。接口使得软件系统在灵活性和可扩展性，可插入性得到保证。第二十四页，共五十七页，编辑于2023年，星期三相同接口具有不同的实现，对象的行为具有多种形态的特性。简化了客户定义。使客户对象除了支持特定接口外，不做其他设定。相同接口的对象具有了可替换性。复用对象的实现和应用第二十五页，共五十七页，编辑于2023年，星期三继承和对象合成的关系继承：根据一个类定义另一个类的执行过程。在编译时静态定义，直接被程序设计语言支持，使用直接。便于修改正在复用的实现。

————白盒复用“白盒”指可见性，通过继承，父类的内部可被子类所见。第二十六页，共五十七页，编辑于2023年，星期三问题：1)实际运行时不能改变在编译时所定义继承的执行过程2)子类的依赖性：继承把父类执行过程的细节暴露给子类，破坏了封装。子类的物理表示、执行过程与父类有密切关系父类执行过程的任何改变都会强迫子类发生改变。这种依赖性限制了适应性，最终也限制了可复用性。第二十七页，共五十七页，编辑于2023年，星期三动态连接：在运行时将请求连接到一个对象和该对象的一个操作上。——意味着请求不需指定特定的实现。任何有适当接口的对象都会接收请求。相同接口的对象可以互相替换。第二十八页，共五十七页，编辑于2023年，星期三对象合成：通过组合对象得到新的更复杂的功能。要求被组合对象有定义好的接口。特点：对象合成在运行时动态地通过对象请求访问其他对象。组合要求对象考虑相互的接口，精心设计接口。任何一个对象都可在运行时被另一个有相同的类型对象替代。黑盒复用————对象的内部细节不可见，对象显得像一个黑盒。

第二十九页，共五十七页，编辑于2023年，星期三优点：对象只能由其接口访问，不破坏封装。对象的实现根据接口编写，依赖性减少。有助于类的封装，使每个类集中于一个任务。 缺点：系统的行为不是在类中定义，而依赖于对象的相互关系。采用对象合成优于采用类继承（合成/聚合复用原则）。第三十页，共五十七页，编辑于2023年，星期三委托（delegation)：对象合成的特例。一个控制请求的执行：继承方法：子类将请求交给父类执行。委托方法：接收操作的对象把操作委托给它的代理对象。接收操作的对象把自己本身也传给委托者，以使被委托操作指向接收对象。第三十一页，共五十七页，编辑于2023年，星期三[例]窗口类的实现继承方法：使窗口类成为矩形的子类，继承其操作。窗口类将请求交给矩形父类执行代理方法：产生一个矩形实例，并代理复用矩形的行为窗口将请求传给此矩形实例把操作委托给矩形实例把自己本身也传给矩形实例，以使被委托操作指向接收对象让窗口好像是一个矩形在运行中用圆实例代替矩形实例就适用圆形窗口窗口矩形窗口矩形第三十二页，共五十七页，编辑于2023年，星期三窗口类对矩型类实例的引用第三十三页，共五十七页，编辑于2023年，星期三优点：容易组合运行时的行为，改变行为组合的方式。缺点：难理解、运行效率低。依赖具体情况及设计者经验。在标准模式中使用效果较好。第三十四页，共五十七页，编辑于2023年，星期三参数化类型。定义类时不规定它所用的数据元素类型。这些类型在使用时作为参数提供。[例]：列表类——将元素的类型提供给列表的类型参数，实现时为列表类建立每种元素的可定制形式。整数列表——把类型“整数”作为参数。字符串列表——类型“字符串”作为参数。第三十五页，共五十七页，编辑于2023年，星期三设计模式：更高的层次上的可复用性（宏观逻辑的抽象层次复用）解决：1．合适的对象（类）的寻找2．对象（类）粒度的确定：如何分解粒度合适的类3.对象（类）接口的确定：如何定义类接口和继承体系4．对象（类）实现的确定5.复用机制的处理：如何建立类（类）的关键联系6．运行结构和编译结构的处理7．设计中变动的处理第三十六页，共五十七页，编辑于2023年，星期三1．寻找合适的对象系统分解为对象的困难：多种矛盾因素兼顾：封装、粒度、依赖性、灵活性、性能、发展、可重用性。多种分解对象方法优劣的确定：（1）问题陈述→找出名词和动词→构造相应的对象和操作；（2）集中考虑系统中的协作和职责；（3）构造现实世界模型，把分析得到的对象转换到设计中。现实世界+非现实世界的类，如数组、抽象类等。解决办法：用设计模式帮助确定设计抽象和相应的对象。第三十七页，共五十七页，编辑于2023年，星期三2．确定对象的粒度设计模式帮助确定在存在大小和数量差别的事物第三十八页，共五十七页，编辑于2023年，星期三3.确定对象的接口设计模式帮助确定：（1）接口定义。识别关键元素和由接口取得的数据的类型。（2）规定接口间的关系和接口限制。第三十九页，共五十七页，编辑于2023年，星期三4．确定对象实现对象的实现由它的类来定义。a.类的表示抽象类/具体类/混合类b.类的实现类继承/接口继承第四十页，共五十七页，编辑于2023年，星期三5.处理复用机制理想情况下，应该只通过对象合成来得到所需的功能。但限于可用部件的集合不够丰富。继承和对象合成可以互相补充。第四十一页，共五十七页，编辑于2023年，星期三一个设计可以用三种组合行为技术中的任一种来实现。区别：继承——允许提供操作的缺省实现并允许子类超越父类操作。对象合成——允许运行时改变被组合的行为，但间接完成，效率不高。参数化类型——允许改变一个类可用的类型。但不能在运行中改变。哪种方法最好取决于设计和实现约束。第四十二页，共五十七页，编辑于2023年，星期三6．运行结构和编译结构编译结构（代码结构）——编译时即被冻结，由具有固定继承关系的类组成。编译结构代码不能显示出一个系统工作的全部情况。运行结构——由迅速变化的通信对象网组成。系统运行结构的优劣主要由设计者设计的对象及其类型之间的关系来决定，而不是由语言来决定的。第四十三页，共五十七页，编辑于2023年，星期三[例]：运行结构和编译结构不同聚集（aggregation）和关联（acquaintance）关系。聚集——对象包含另一个对象或对另一对象负责，或为另一个对象的一部分，具有相同生命期。关联——一个对象只知道另一个对象。关联对象之间可互相请求操作，但不对对方负责。是比聚集弱的联系，提供了对象间的松耦合。——运行结构不同

聚集和关联常用相同的方法编译实现：在Smalltalk中：都是其他对象的引用。聚集和关联没有区别。在C++中：都用指针和引用来实现。

——编译结构相同由此可见：关联和聚集关系主要由设计含义决定，而不是由语言机制决定。在编译结构中，关联和聚集之间的差别小，在源代码中难以辨认。差别：聚集关系往往会比关联关系少而更稳定。关联关系出现频繁，有时只在一个操作持续的时间中存在。动态性更强。第四十四页，共五十七页，编辑于2023年，星期三7．处理设计中的变动达到最大复用程度的关键：设计中预先考虑生命期内新需求和现有需求的变化。包括：类的重定义和重新实现、客户修改和重新测试。设计模式的作用：确保系统只用特定的方式发生改变。允许系统结构的某些部分的变化独立于另外部分，因此有较高的健壮性。封装变化第四十五页，共五十七页，编辑于2023年，星期三应用系统、工具包、框架设计难度:应用系统＜工具包＜框架第四十六页，共五十七页，编辑于2023年，星期三（1）设计模式在应用系统中的作用：设计模式的松散耦合，封装使操作、算法、和表示的依赖性减少，提高了对象类与其他类互操作的可能性——增加了内部复用可能。减少对平台依赖性——系统的可维护性变强。利用类继承关系和对象合成，使类耦合减少，一个类不依赖于其他类——提高可扩展性。第四十七页，共五十七页，编辑于2023年，星期三（2）设计模式在工具包中的作用：工具包——类库中预先定义的相关的可复用的类的集合，面向对象的子程序库。——只为应用系统提供某些通用功能。如列表、联合表、栈等，C++的I/O流库等。——强调代码复用，没有特定的设计要求。第四十八页，共五十七页，编辑于2023年，星期三设计特点：比应用系统的设计难。要在多种应用系统中工作。设计者不知应用系统情况和特殊要求。要求：避免假设和依赖性，依赖性会限制工具包的适应性，进而限制可利用性和效率。设计模式有助于工具包的适用性。

第四十九页，共五十七页，编辑于2023年，星期三（3）设计模式在框架中的作用：框架——为特定要求的软件构成的可复用的设计。框架强调设计复用而不仅是代码复用。特定应用的框架是框架抽象类的特定应用子