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

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

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

软件体系结构复习修改版

软件体系结构（绝密）

一、填空题&选择题（50分）

软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。

软件重用是指在两次或多次不同的软件开发过程中重复使用相同或相近软件元素的过程。

构件重用包括：

代码重用、设计重用、需求重用和软件体系结构重用（抽象级别最高）。

建模是开发优秀软件的所有活动中的核心部分，其目的是把所要设计的结构和系统的行为沟通起来，并对系统的体系结构进行可视化控制。

三种软件体系结构评估方法：

体系结构权衡分析法（或：

基于场景的权衡分析法）（ATAM方法）、体系结构结构分析方法（SAAM方法）、中间设计的积极评审（ARID方法）。

ATAM

分为：

第一阶段以体系结构为中心，重点是获取体系结构信息并进行分析；第二阶段以风

险承担者为中心，重点是获取风险承担者的观点，验证第一阶段的结果。

体系结构风格是一些软件设计框架、设计模式、惯用方法在体系结构设计思想指导下形成可复用的结构样式。

体系结构风格可大致划分为经典样式和派生样式两大类。

UML是一种用于对软件密集型系统进行可视化、详述、构造和文档化的建模语言，主要适用于分析和设计阶段的系统建模。

UML的扩展机制包括：

构造性、特征值、约束。

软件体系结构是早期设计决策的体现，代表了系统的公共的高层次的抽象。

消息总线风格（HMB）构件根据需要发出消息，总线把该消息分派到系统中对此消息感兴趣的构件，完成构件之间的通讯。

正交软件体系风格其正交性体现在：

线索是相互独立的，即不同线索中的构件之间没有相互调用，是正交的。

它是一中垂直线索构件族为基础的层次化结构。

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

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

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

软件设计模式四个基本要素：

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

“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：

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

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

适用性：

若一个对象需很长时间才能加载完成；若对象位于远程主机上，从网络进行加载可能会很慢；若对象具有受限的存取权限，则代理可验证用户存取特权的有效性。

参与者：

Proxy：

保存一个引用使得代理可以访问实体；提供一个与Subject的接口相同的接口，这样代理就可以用来替