软件体系结构复习修改版Word格式.docx

软件体系结构复习修改版Word格式.docx

《软件体系结构复习修改版Word格式.docx》由会员分享，可在线阅读，更多相关《软件体系结构复习修改版Word格式.docx（16页珍藏版）》请在冰点文库上搜索。

模式名称、问题、解决方案、效果。

“4+1”模型：

“4”代表逻辑视图、进程视图、物理视图、开发视图，“1”代表场景。

传统的软件过程包括需求分析、概要设计、详细设计、编码、测试、维护阶段。

体系结构的软件过程包括体系结构的需求、设计、文档化、复审、实现、演化等6个子过程。

UML用例图：

捕获用户能够看到的系统功能，类图：

捕获系统的词汇表，对象图：

捕获实例和连接，顺序图：

捕获系统的动态行为（面向时间的），协作图：

捕获系统的动态行为（面向消息的），状态图：

捕获系统动态行为（面向事件的），活动图：

捕获动态行为（面向活动的），组件图：

捕获实现的物理结构，分布图：

捕获系统硬件的拓扑结构。

B/S&

C/S:

B/S是对C/S体系结构的进一步发展，用户界面通过浏览器实现交互服务；

B/S体系结构主要是利用较成熟的浏览器技术，结合浏览器的多种脚本语言，实现了专用软件才能完成的功能，降低开发成本，是一种全新的软件体系结构。

二、简答题&

论述题

软件体系结构研究内容：

软件体系结构设计的核心思想是描述构件（连接子），以及构件之间的联系的。

从软件系统整体结构出发，设计软件的组织结构、控制结构、存储结构、物理部署等。

具体讲，就是描述软件系统的整体架构，架构由哪些构造块（构件）组成，以及说明构造块（构件）之间的关联关系。

意义：

（1）体系结构是风险承担者进行交流的手段；

（2）体系结构是早期设计决策的体现；

（3）软件体系结构是可传递和可重用的模型。

作用：

（1）基于体系结构设计思想，有助于设计者面临复杂领域问题时，做出正确的选择，最大限度地避免软件设计的结构性错误;

（2）体系结构设计文档成为设计人员、用户及其他风险参与者一致的沟通文本，以保证软件产品开发的成功率;

（3）体系结构有助于发现和提取可重用构件或模式。

基于体系结构的软件过程是在体系结构指导下的软件开发过程。

首先设计体系结构，软件系统的开发过程可描述为软件的演化与组装过程。

具体过程可划分为体系结构的需求、设计、文档化、复审、实现、演化等6个子过程。

体系结构需求：

需求获取、标识构件。

体系结构设计是一个迭代过程，若从已有系统中能重用大部分，则可以在基础上演化。

体系结构必须文档化，作为设计、开发人员以及参与者交流媒介，也是验证、提炼或修改体系结构的基础。

体系结构的复审：

复审的目的是标识潜在的风险，早期发现缺陷和错误。

包括能否满足功能需求和质量需求，层次是否清晰、构件的划分是否合理、文档表述是否明确等等。

体系结构的实现：

实现过程是以复审后的文档化为基础，描述构件的实现功能、按规定方式交互，以及满足与其他构件的联系等等。

体系结构的演化：

体系结构必须支持演化，以适应需求变化。

因为，随着系统复杂度的提高，需求的变化是普遍存在的。

体系结构设计思想的最大优势就是能适应需求的变化，演化是适应需求变化的具体办法。

设计模式：

创建型模式（FactoryMethod、AbstractFactory、Builder、Prototype、Singleton）：

创建型模式抽象了实例化过程。

它们帮助一个系统独立于如何创建、组合和表示它的那些对象。

类创建型模式使用继承改变被实例化的类。

对象创建型模式将实例化委托给另一个对象。

结构型模式（Adapter、Bridge、Composite、Decorator、Facade、Flyweight、Proxy）：

结构型模式涉及到如何组合类和对象以获得更大的结构。

结构型类模式采用继承机制来组合接口或实现。

结构型对象模式不是对接口或实现进行组合，而是描述了如何对一些对象进行组合，从而实现新功能的一些方法。

由于可在运行时刻改变对象组合关系，因此对象组合方式具有更大的灵活性。

行为型模式（Interpreter、TemplateMethod、ChainofResponsibility、Command、Iterator、Mediator、Memento、Observer、State、Strategy、Visitor）：

行为模式涉及到算法和对象间职责的分配。

行为模式不仅描述对象或类的模式，还描述它们之间的通信模式。

行为类模式使用继承机制在类间分派行为，包括TemplateMethod和Interpreter。

行为对象模式使用对象复合而不是继承。

一些行为对象模式描述了一组对等的对象怎样相互协作以完成其中任一个对象都无法单独完成的任务。

描述软件设计模式的作用和构成：

设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。

使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

四个基本要素：

描述设计模式：

模式名和分类、意图、别名、动机、参与者、协作、效果、实现。

设计模式可以解决设计问题：

寻找合适的对象、决定对象的粒度、指定对象接口、描述对象的实现、运用复用机制、关联运行时刻和编译时刻的结构、设计应支持变化。

解决重新设计问题：

通过显式地指定一个类来创建对象、对特殊操作的依赖、对硬件和软件平台的依赖、对对象表示或实现的依赖、算法依赖、紧耦合、通过生成子类来扩充功能、不能方便地对类进行修改。

描述PAC模式：

表示-抽象-控制模式。

以合作Agent的层次形式定义了交互式软件系统的一种结构；

每个Agent负责应用程序的某个特定方面；

每个Agent由表示，抽象，和控制三个组件组成；

将Agent的人机交互部分与其内核和它与其他Agent的通信分隔开来。

动态特性：

场景Ⅰ：

用户要求视图协调程序agent的表示组件打开一个新的直方图。

视图协调程序agent的控制组件实例化用户所期望的直方图agent；

视图协调程序agent发送一个open事件到新的直方图agent的控制组件；

直方图agent的控制组件检索来自顶层agent的数据；

视图协调程序agent协调底层和顶层的agent。

返回到直方图的数据被存放到他的抽象组件。

直方图agent的控制组件调用表示组件显示直方图；

表示组件在屏幕上创造窗口，通过控制组件发出请求检索从抽象组件得到的数据并显示。

场景Ⅱ:

说明了新的选举数据输入后系统的行为。

用户向电子数据表录入新数据。

电子数据表agent的控制组件将数据输送到顶层agent；

顶层agent的控制组件更新所有依赖于这些新数据的agent；

视图协调程序agent的控制组件把更新通知提交给他所负责协调的所有视图PACagent；

与以前场景一样，所有视图PACagent都更新他们的数据并且恢复他们展示的图像。

描述MVC模式：

该模式将一个交互式应用程序分成3个组件。

模型：

包含核心功能和数据。

视图：

向用户显示信息。

控制器：

处理用户输入。

视图和控制器组成了用户接口。

变更-传播机制保证了模型和用户接口之间的一致性。

场景Ⅰ用户输入导致模型变化，并触发变更-传播机制。

控制器接受到事件，解释事件并且启动模型的服务过程；

模型执行相应的过程，并导致内部状态的变化；

模型调用其更新过程，向所有登记请求了变更-传播机制的视图和控制器发出通知；

每个视图从模型中读取新数据并且重新显示；

每个控制器修改自己的行为，比如禁用某个功能；

最初的控制器恢复控制并从事件处理过程返回。

场景Ⅱ初始化过程。

创建模型实例，并初始化其数据；

创建视图对象，并用对模型的引用作为初始化参数之一；

视图通过调用附属过程支持变更-传播机制；

视图创建控制器，此时将模型和视图的引用作为参数传递给控制器初始化过程；

控制器通过调用附属过程来支持变更-传播机制；

初始化完成，应用程序开始处理事件。

简述“4+1”软件体系结构建模过程：

逻辑视图、进程视图、物理视图、开发视图和场景，统称“4+1”视图模型。

逻辑视图：

侧重于描述体系结构的静态特征，在面向对象设计方法中的类图就可以看作逻辑视图。

开发视图侧重于描述软件模块开发的组织和管理，考虑易用性、重用性和通用性；

进程视图侧重于描述体系结构的运行特征，关注其非功能性需求；

物理视图描述软件与硬件的映射关系，考虑系统性能、规模和可靠性；

场景是最重要的需求抽象，用对象交互图来描述。

两个作用：

一是发现构件；

二是验证SA设计。

ChainOfResponsibility：

使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。

将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

适用性：

有多个对象可以处理一个请求，哪个对象处理该请求由运行时刻自动确定；

你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求；

可处理一个请求的对象集合应被动态指定。

参与者：

Handler：

定义一个处理请求的接口。

（可选）实现后继链。

ConcreteHandler：

处理它所负责的请求；

可访问它的后继者；

如果可处理该请求，就处理，否则转发给后继者。

Client：

向链上的具体处理者对象提交请求。

Strategy：

定义一系列的算法,把它们一个个封装起来,并且使它们可相互替换。

本模式使得算法可独立于使用它的客户而变化。

许多相关的类仅仅是行为有异；

需要使用一个算法的不同变体；

算法使用了客户不应该知道的数据；

一个类定义了多种行为,并且这些行为在这个类的操作中以多个条件语句的形式出现。

Strategy定义所有支持的算法的公共接口，Context使用这个接口来调用某ConcreteStrategy定义的算法；

ConcreteStrategy：

以Strategy接口实现某具体算法。

Context：

用一个ConcreteStrategy对象来配置；

维护一个对Strategy对象的引用；

可定义一个接口来让Strategy访问它的数据。

Proxy：

使一个组件的客户机与一个组件的代表而不是组件本身通信。

引入这样一个占位符有许多用途，包括提高效率、易于存取和防止越权访问等。

若一个对象需很长时间才能加载完成；

若对象位于远程主机上，从网络进行加载可能会很慢；

若对象具有受限的存取权限，则代理可验证用户存取特权的有效性。

保存一个引用使得代理可以访问实体；

提供一个与Subject的接口相同的接口，这样代理就可以用来替代实体；

控制对实体的存取，并可能负责创建和删除它；

其他功能依赖于代理的类型。

Subject：

定义RealSubject和Proxy的共用接口，这样就在任何使用RealSubject的地方都可以使用Proxy。

RealSubject：

定义Proxy所代表的实体。

AbstractFactory：

提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类；

抽象工厂是一个能从几组类中返回其中一某一组的工厂对象。

一个系统要独立于它的产品的创建、组合和表示时；

一个系统要由多个产品系列中的一个来配置时；

当你要强调一系列相关的产品对象的设计以便进行联合使用时；

当你提供一个产品类库，而只想显示它们的接口而不是实现时。

AbstractFactory：

声明一个创建一系列抽象产品对象的操作接口。

ConcreteFactory：

实现创建具体产品对象的操作。

AbstractProduct：

为一类产品对象声明一个接口。

ConcreteProduct：

定义一个将被相应的具体工厂创建的产品对象；

实现AbstractProduct接口。

仅使用由AbstractFactory和AbstractProduct类声明的接口。

23种设计模式：

提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

Builder：

将一个复杂对象的构件与它的表示分离，使得同样的构建过程可以创建不同的表述。

FactoryMethod：

定义一个用于创建对象的接口，让子类决定将哪一个类实例化。

FactoryMethod使一个类的实例化延迟到其子类。

Prototype：

用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。

Singleton：

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

Adapter：

将一个类的接口转换成客户希望的另外一个接口。

Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

Bridge：

将抽象部分与它的实现部分分离，使它们都可以独立地变化。

Composite：

将对象组合成树型结构以表示“部分－整体”的层次结构。

Composite使得客户对单个对象和复合对象的使用具有一致性。

Decorator：

动态地给一个对象添加一些额外的职责。

就扩展功能而言，Decorator模式比生成子类方式更为灵活。

Facade：

为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

Flyweight：

运用共享技术有效地支持大量细粒度的对象。

为其他对象提供一个代理以控制对这个对象的访问。

ChainofResponsibility：

为解除请求的发送者和接受者之间耦合，而使多个对象都有机会处理这个请求。

将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。

Command：

将一个请求封装为一个对象，从而使你可以用不同的请求对客户进行参数化；

对请求排队或记录请求日志，以及支持可取消的操作。

Interpreter：

给定一个语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。

Interator：

提供一种方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部表示。

Mediator：

用一个中介对象来封装一系列的对象交互。

中介者使各对象不需要显式地相互引用，从而使器耦合松散，而且可以独立地改变它们之间的交互。

Memento：

在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。

这样以后就可以将该对象恢复到保存的状态。

Observer：

定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动刷新。

State：

允许一个对象在其内部状态改变时改变它的行为。

对象看起来似乎修改了它所属的类。

定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。

本模式使得算法的变化可独立于使用它的客户。

TemplateMethod：

定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。

TemplateMethod使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

Visitor：

表示一个作用于某对象结构中的各元素的操作。

它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

1.软件体系结构的研究内容、意义和作用。

研究内容：

2.简述基于体系结构的软件开发过程。

3.简述创建型、结构型、行为型模式。

创建型模式：

随着系统演化得越来越依赖于对象复合而不是类继承，创建型模式变得更为重要。

重心从对一组固定行为的硬编码（hard-coding）转移为定义一个较小的基本行为集，这些行为可以被组合成任意数目的更复杂的行为。

在这些模式中有两个不断出现的主旋律：

第一，它们都将关于该系统使用哪些具体的类的信息封装起来；

第二，它们隐藏了这些类的实例是如何被创建和放在一起的。

整个系统关于这些对象所知道的是由抽象类所定义的接口。

创建型模式在什么被创建，谁创建它，它是怎样被创建的，以及何时创建这些方面给予你很大的灵活性。

创建型模式允许你用结构和功能差别很大的“产品”对象配置一个系统。

配置可以是静态的（即在编译时指定），也可以是动态的（在运行时）。

结构型模式：

行为型模式：

行为类模式使用继承机制在类间分派行为。

包括TemplateMethod和Interpreter。

4.描述软件设计模式的作用和构成。

四个基本要素：

模式名称、问题、解决方案、效果

模式名和分类、意图、别名、动机、参与者、协作、效果、实现

5.描述PAC（或MVC）（主要是动态特征（场景I、II））。

6.简述“4+1”软件体系结构建模过程。

7.简述策略设计模式，代理设计模式（或职责链设计模式）。

三、设计题

UML图