软件设计及体系结构课后题答案.docx
《软件设计及体系结构课后题答案.docx》由会员分享，可在线阅读，更多相关《软件设计及体系结构课后题答案.docx（23页珍藏版）》请在冰点文库上搜索。
软件设计及体系结构课后题答案
【题型】
1.选择20道
2.填空10道
3.简答5或6道
4.编程题2道
【重点】
1.软件危机的表现
软件开发进度难以预测
软件开发成本难以控制
用户对产品功能难以满足
软件产品质量无法保证
软件产品难以维护
2.引发软件危机的原因
用户需求不明确
缺乏正确的理论指导
软件开发规模越来越大
软件开发复杂度越来越高
3.体系结构概念
构件、构件之间的关系、集成构件的模式及约束条件
4.构件的概念
构件是指语义完整、语法正确和有可重用价值的单位软件，是软件重用过程中可以明确辨识的系统；结构上，它是语义描述、通讯接口和实现代码的复合体。
5.引入体系结构使得开发过程发生什么变化？
好处是什么？
软件再工程、逆工程的概念？
软件设计质量的量度
【变化】
在引入了体系结构的软件开发之后，应用系统的构造过程变为“问题定义—>软件需求—>软件体系结构—>软件设计—>软件实现”，可以认为软件体系结构架起了软件需求及软件设计之间的一座桥梁。
【好处】
克服软件危机
【再工程】
是指对既存对象系统进行调查，并将其重构为新形式代码的开发过程。
最大限度的复用既存系统的各种资源是再工程的最重点特征之一。
如何开发可复用软件和如何构造采用可复用软件的系统体系结构是两个关键问题。
【逆工程】
是指分析软件系统，确定其构成成分及各成分间的关系，提取并生成系统抽象和设计信息的工程。
【量度】
面向对象软件质量的度量重点在于对类的分析上。
应从类的以下方面考虑：
耦合内聚度继承性复杂度
6.5个设计原则概念
【单一职责原则】就一个类而言，应该仅有一个引起它变化的原因。
【开闭原则】软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。
（也就是老婆常说的对扩展开放，对修改关闭）
【依赖倒转】抽象不应该依赖于细节，细节应该依赖于抽象。
要针对接口编程，不要对实现编程。
【里氏代换】在软件里面，把父类都替换成它的子类，程序行为没有变化。
简单地说，子类型必须能够替换掉它们的父类型。
【迪米特】如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。
如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
7.软件设计目标（健壮性等）概念
正确性、健壮性、可复用性、可维护性、高效性
8.17个模式（包含简单工厂方法）的概念、结构图、类的关系、代码、什么时候采用、优缺点
【简单工厂】简单工厂模式是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类（这些产品类继承自一个父类或接口）的实例。
结构图：
优点：
工厂类是整个模式的关键.包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象.通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。
而不必管这些对象究竟如何创建及如何组织的．明确了各自的职责和权利，有利于整个软件体系结构的优化。
缺点：
由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。
当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求．这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利；
何时采用：
工厂类负责创建的对象比较少；客户只知道传入工厂类的参数，对于如何创建对象（逻辑）不关心；由于简单工厂很容易违反高内聚责任分配原则，因此一般只在很简单的情况下应用。
【策略模式】它定义了算法家族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户
结构图：
优点：
1.Strategy类层次为Context类定义了一系列可供重用的算法或行为。
继承有助于析取出这些算法中的公共功能。
2.简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试。
修改其中任一个时，也不会影响其他算法。
3.当不同的行为堆砌到一个类中时，就很难避免使用条件语句来选择合适的行为——最开始的程序，不得不在客户端代码中判断使用哪个算法。
4.将这些行为封装在一个独立的Strategy类中，可以在使用这些行为的类中消除条件语句。
缺点：
CashContext还是用到了switch分支语句，若增加算法，需更改CashContext中的代码
何时采用：
策略模式就是用来封装算法的，可以用它来封装几乎任何类型的规则，只要在分析过程中听到需要在不同时间应用不同的业务规则，就可以考虑用使用策略模式处理这种变化的可能性。
【装饰模式】动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活
结构图：
优点：
1.把类的装饰功能从类中搬移去除，这样可以简化原有的类。
2.有效的将类的核心职责和装饰功能区分开。
而且可以去除相关类中重复的装饰逻辑。
缺点：
多层的装饰比较复杂
何时采用：
1.需要扩展一个类的功能，或给一个类增加附加功能
2.需要动态地给一个对象增加功能，这些功能可以再动态地撤销
3.需要为一批的兄弟类进行改装或加装功能
【工厂方法】定义一个用于创建对象的接口，让子类决定实例化哪一个类。
结构图:
优点：
1．工厂方法克服了简单工厂违背开闭原则的缺点，又保持了封装对象创建过程的优点。
2.使得更换对象时，不需要做大的改动，降低了客户程序及产品对象的耦合。
3.工厂方法模式是简单工厂模式的进一步抽象和推广。
4.由于使用了多态，工厂方法模式保持了简单工厂模式的优点，而且克服了缺点。
缺点:
1.由于每加一个产品，就需要加一个产品工厂的类，增加了额外的工作量。
2.没有避免修改客户端的代码。
3.反射→避免分支判断问题
何时采用：
工厂方法模式是new一个对象的替代品，所以在所有需要生成对象的地方都可以使用，但是需要慎重地考虑是否要增加一个工厂类进行管理，增加代码的复杂度。
其次，需要灵活的、可扩展的框架时，可以考虑用工厂方法模式。
【原型模式】指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
原型模式其实就是从一个对象再创建另外一个可定制的对象，而且不需要知道任何创建的细节。
结构图:
优点：
1．性能优良：
原型模型是在内存二进制流的拷贝，要比直接new一个对象性能好很多，特别是要在一个循环体内产生大量的对象时，原型模型可以更好地体现其优点。
2．逃避构造函数的约束：
这既是它的优点也是缺点，直接在内存中拷贝，构造函数是不会执行的，优点就是减少了约束，缺点也是减少了约束，需要大家在实际应用时考虑。
何时采用：
1．资源优化场景:
类初始化需要消化非常多的资源，这个资源包括数据、硬件资源等。
2．性能和安全要求的场景：
通过new产生一个对象需要非常频繁的数据准备或访问权限，则可以使用原型模式。
3．一个对象多个修改者的场景：
一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用
【模版方法】定义一个操作中的算法骨架，而将一些步骤延迟到子类中。
模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤
结构图:
优点：
1.模板方法模式是通过把不变行为搬移到超类，去除子类中的重复代码。
2.模板方法模式提供了一个很好的代码复用平台。
遇到由一系列步骤构成的过程，这些过程从高层次上看是相同的，但有些步骤的实现不同，考虑用模板方法模式。
3.当不变和可变的行为在方法的子类实现中混合在一起的时候，不变的行为就会在子类中重复出现。
通过模板方法模式把这些行为搬移到单一的地方，这样就帮助子类摆脱重复的不变行为的纠缠。
缺点:
按照我们的设计习惯，抽象类负责声明最抽象、最一般的事物属性和方法，实现类完成具体的事物属性和方法。
但是模版方法模式却颠倒了，抽象类定义了部分抽象方法，由子类实现，子类执行的结果影响了父类的结果，也就是子类对父类产生了影响，这在复杂的项目中，会带来代码阅读的难度，而且也会让新手产生不适感。
何时采用：
1．多个子类有公有的方法，并且逻辑基本相同时。
2．重要、复杂的算法，可以把核心算法设计为模版方法，周边的相关细节功能则由各个子类实现
【外观模式】为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
结构图:
优点：
1.减少系统的相互依赖
2.提高了灵活性
3.提高安全性
缺点:
不符合开闭原则
何时采用：
1.在设计初期阶段，应该要有意识的将不同的两个层分离，层及层之间建立外观类（Facade），这样就可以为复杂的子系统提供一个简单的接口，使得耦合大大降低。
2.在开发阶段，子系统往往因为不断的重构演化而变的越来越复杂，给外部调用它们的用户带来困难。
增加外观类可以提供一个简单的接口，减少它们之间的依赖。
3.在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了，但新的需求开发必须依赖它。
为新系统开发一个外观类，来提供设计粗糙或高度复杂的遗留代码的比较清晰的简单接口，让新系统和Facade对象交互，Facade及遗留代码交互所有复杂的工作。
【建造者】将一个复杂对象的构建及它的表示分离，使得同样的构造过程可以创建不同的表示。
结构图:
优点：
使得建造代码及表示代码分离，由于建造者隐藏了该产品是如何组装的，所以若需要改变一个产品的内部表示，只需要再定义一个具体的建造者就可以了。
何时采用：
主要用于创建一个复杂的对象，这些对象内部构建间的构造顺序通常是稳定的，但对象内部的构建通常面临着复杂的变化。
【观察者】定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。
这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己
结构图:
优点：
将一个系统分割成一系列相互协作的类有一个很不好的副作用，那就是需要维护相关对象间的一致性。
我们不希望为了维持一致性而使各类紧密耦合，这样会给维护、扩展和重用都带来不便。
缺点:
开发效率和运行效率不高
何时采用：
1．个对象的改变需要同时改变其他对象的时候。
而且它不知道具体有多少对象有待改变时，应该考虑使用观察者模式。
2.抽象模型有两个方面，其中一方面依赖另一方面，这时用观察者模式可以将这两者封装在独立的对象中使它们各自独立的改变和复用。
【抽象工厂】提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
结构图:
优点：
1．交换产品系列，由于具体工厂类，在一个应用中只需要初始化的时候出现一次，这就使得改变一个应用的具体工厂变得非常容易，它只需要改变具体工厂即可使用不同的产品配置。
2.体的创建实例过程及客户端分离，客户端是通过它们的抽象接口操纵实例，产品的具体名也被具体工厂的实现分离，不会出现在客户代码中。
缺点:
1.加功能→增加一个项目表Project
2.三个类→IProject、SqlserverProject、AccessProject
3.三个类→IFactory、SqlserverFactory、AccessFactory（增加创建方法）
4.端程序类→类似这样的类，即需要调用数据库访问的类，不会仅有一个，有很多地方都在使用IUser或是IDepartment。
5.用到数据库访问的时候，都要声明IFactoryfactory=newSqlserverFactory（），若有100个调用数据库访问的类，需要修改100次。
6.大批量的改动。
何时采用：
一个对象群都有相同的约束，则可以采用抽象工厂模式
【状态模式】当一个对象的内在状态改变时允许改变其行为，这个对象看起来像改变了其类。
结构图:
优点：
将及特定状态相关的行为局部化，并且将不同状态的行为分割开来。
即将特定状态的相关行为都放入一个对象中（ConcreteState），由于所有及状态相关的代码都存放在某个ConcreteState中，所以通过定义新的子类可以很容易地增加新的状态和转换。
消除庞大的条件分支。
状态模式通过把各种状态转移逻辑分布到State的子类之间，来减少相互间的依赖。
缺点:
子类太多
何时采用：
1.个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时。
2.某项业务有多个状态，通常都是一些枚举常量，状态的变化都是依靠大量的多分支判断语句来实现，此时应该考虑将每一种状态定义为State的子类。
这样这些对象就可以不依赖于其他对象而独立变化，也可以很好的面对需求的改变。
【适配器模式】将一个类的接口转换成客户希望的另外一个接口。
Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
结构图:
优点：
1.适配器模式可以让两个没有任何关系的类在一起运行，只要适配器这个角色能够搞定他们就行。
2.增加了类的透明性
3.提高了类的复用度
4.灵活性非常好：
某一天，突然不想要适配器，没问题，删除掉就ok,其他的代码不用修改。
何时采用：
1.一个已经存在的类，但若它的接口，也就是它的方法和你的要求不相同时，就应该使用适配器模式
2.类所做的事情相同或相似，但是具有不同的接口时要使用它
3.代码可以统一调用同一接口，使得客户端更简单、更直接、更紧凑。
【备忘录】在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
这样以后就可将该对象恢复到原先保存的状态。
结构图:
何时采用：
1．适用于功能比较复杂的，但需要维护或记录属性历史的类，或者需要保存的属性只是众多属性中的一小部分时，Originator可以根据保存的Memento信息还原到前一状态。
2.式也有类似的撤销作用。
若在某个系统中使用命令模式时，需要实现命令的撤销功能，可以使用备忘录模式来存储可撤销操作的状态。
3.有时一些对象的内部信息必须保存在对象以外的地方，但是必须要由对象自己读取，这时，使用备忘录可以把复杂的对象内部信息对其他的对象屏蔽起来，从而恰当的保持封装的边界。
【组合】将对象组合成树形结构以表示“部分—整体”的层次结构。
组合模式使得用户对单个对象和组合对象的使用具有一致性
结构图:
优点：
1.高层模块调用简单
2.节点自由增加
缺点:
违反了依赖倒转原则
何时采用：
1.中体现部分及整体层次的结构时。
2.用户可以忽略组合对象及单个对象的不同，统一地使用结构中的所有对象时。
【迭代器】提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露该对象的内部表示。
结构图:
何时采用：
平时编程的for就是迭代器模式，还有Iterable接口，其实平时我们就在用这个模式，有没有感觉棒棒的
【单例】保证一个类仅有一个实例，并提供一个访问它的全局访问点。
结构图:
优点：
1．保证唯一的实例。
2.因为Singleton类封装它的唯一实例，这样它可以严格地控制客户怎样访问它以及何时访问它。
简单地说，就是对唯一实例的受控访问。
缺点:
1.单例模式一般没有接口，扩展很困难。
2.单例模式对测试是不利的。
3.单例模式及单一职责原则有冲突
何时采用：
1．要求生成唯一序列号的环境
2．在整个项目中需要一个共享访问点或共享数据
3．创建一个对象需要消耗的资源过多
4．需要定义大量的静态常量和静态方法的环境
【代理模式】为其他对象提供一种代理以控制对这个对象的访问。
结构图:
优点：
1．职责清晰：
真实的角色就是实现实际的业务逻辑，不用关心其他非本职责的事物，通过后期的代理完成一件事务，附带的结果就是编程简洁清晰。
2．高扩展性：
具体主题角色是随时都会发生变化的，只要它实现了接口，不管它如何变化，都逃不出如来佛的手掌（其实就是接口啦），那我们的代理类完全就可以在不做任何修改的情况下使用。
9.会画核心模型
软件体系结构的建模元素：
构件，连接件，配置，端口，角色
10.4+1模型的区别
11.3种工厂模式的相同点及不同点
老师说不同点就是分别把这三个工厂的定义写出来（简单工厂、工厂方法、抽象工厂）
相同点就是都集中封装了对象的创建，使得要更换对象时不需要做大的改动就可实现，降低了客户端程序及产品对象的耦合。
12.代理模式、外观模式、适配器模式的相同点及不同点
不同点就写三者的定义即可（代理模式、外观模式、适配器模式）
相同点是作用于用户和实际调用类中间
13反射、委托
反射的Java代码实现：
配置文件：
事件委托：
升级会员 