软件体系结构复习样本.doc

软件体系结构(绝密)
一、 填空题&选择题( 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个子过程。体系结构需求: 需求获取、 标识构件。体系结构设计是一个迭代过程, 若从已有系统中能重用大部分, 则能够在基础上演化。体系结构必须文档化, 作为设计、 开发人员以及参与者交流媒介, 也是验证、 提炼或修改体系结构的基础。体系结构的复审: 复审的目的是标识潜在的风险, 早期发现缺陷和错误。包括能否满足功能需求和质量需求, 层次是否清晰、 构件的划分是否合理、 文档表述是否明确等等。体系结构的实现: 实现过程是以复审后的文档化为基础, 描述构件的实现功能、 按规定方式交互, 以及满足与其它构件的联系等等。体系结构的演化: 体系结构必须支持演化, 以适应需求变化。因为, 随着系统复杂度的提高, 需求的变化是普遍存在的。体系结构设计思想的最大优势就是能适应需求的变化, 演化是适应需求变化的具体办法。
设计模式: 创立型模式( Factory Method 、 Abstract Factory、 Builder、 Prototype、 Singleton) : 创立型模式抽象了实例化过程。它们帮助一个系统独立于如何创立、 组合和表示它的那些对象。类创立型模式使用继承改变被实例化的类。对象创立型模式将实例化委托给另一个对象。结构型模式( Adapter、 Bridge、 Composite、 Decorator、 Facade、 Flyweight、 Proxy) : 结构型模式涉及到如何组合类和对象以获得更大的结构。结构型类模式采用继承机制来组合接口或实现。结构型对象模式不是对接口或实现进行组合, 而是描述了如何对一些对象进行组合, 从而实现新功能的一些方法。由于可在运行时刻改变对象组合关系, 因此对象组合方式具有更大的灵活性。
行为型模式( Interpreter、 Template Method 、 Chain of Responsibility、 Command、 Iterator、 Mediator、 Memento、 Observer、 State、 Strategy、 Visitor) : 行为模式涉及到算法和对象间职责的分配。行为模式不但描述对象或类的模式, 还描述它们之间的通信模式。行为类模式使用继承机制在类间分派行为, 包括Template Method和Interpreter。行为对象模式使用对象复合而不是继承。一些行为对象模式描述了一组对等的对象怎样相互协作以完成其中任一个对象都无法单独完成的任务。
描述软件设计模式的作用和构成: 设计模式是一套被重复使用、 多数人知晓的、 经过分类编目的、 代码设计经验的总结。使用设计模式是为了可重用代码、 让代码更容易被她人理解、 保证代码可靠性。 四个基本要素: 模式名称、 问题、 解决方案、 效果。描述设计模式: 模式名和分类、 意图、 别名、 动机、 参与者、 协作、 效果、 实现。设计模式能够解决设计问题:
寻找合适的对象、 决定对象的粒度、 指定对象接口、 描述对象的实现、 运用复用机制、 关联运行时刻和编译时刻的结构、 设计应支持变化。解决重新设计问题: 经过显式地指定一个类来创立对象、 对特殊操作的依赖、 对硬件和软件平台的依赖、 对对象表示或实现的依赖、 算法依赖、 紧耦合、 经过生成子类来扩充功能、 不能方便地对类进行修改。
描述PAC模式: 表示-抽象-控制模式。以合作Agent的层次形式定义了交互式软件系统的一种结构; 每个Agent负责应用程序的某个特定方面; 每个Agent由表示, 抽象, 和控制三个组件组成; 将Agent的人机交互部分与其内核和它与其它Agent的通信分隔开来。动态特性:
场景Ⅰ: 用户要求视图协调程序agent的表示组件打开一个新的直方图。视图协调程序agent的控制组件实例化用户所期望的直方图agent; 视图协调程序agent发送一个open事件到新的直方图agent的控制组件; 直方图agent的控制组件检索来自顶层agent的数据; 视图协调程序agent协调底层和顶层的agent。返回到直方图的数据被存放到她的抽象组件。直方图agent的控制组件调用表示组件显示直方图; 表示组件在屏幕上创造窗口, 经过控制组件发出请求检索从抽象组件得到的数据并显示。场景Ⅱ:说明了新的选举数据输入后系统的行为。用户向电子数据表录入新数据。电子数据表agent的控制组件将数据输送到顶层agent; 顶层agent的控制组件更新所有依赖于这些新数据的agent; 视图协调程序agent的控制组件把更新通知提交给她所负责协调的所有视图PAC agent; 与以前场景一样, 所有视图PAC agent都更新她们的数据而且恢复她们展示的图像。
描述MVC模式: 该模式将一个交互式应用程序分成3个组件。模型: 包含核心功能和数据。视图: 向用户显示信息。控制器: 处理用户输入。视图和控制器组成了用户接口。变更-传播机制保证了模型和用户接口之间的一致性。
场景Ⅰ 用户输入导致模型变化, 并触发变更-传播机制。控制器接受到事件, 解释事件而且启动模型的服务过程; 模型执行相应的过程, 并导致内部状态的变化; 模型调用其更新过程, 向所有登记请求了变更-传播机制的视图和控制器发出通知; 每个视图从模型中读取新数据而且重新显示; 每个控制器修改自己的行为, 比如禁用某个功能; 最初的控制器恢复控制并从事件处理过程返回。场景Ⅱ初始化过程。创立模型实例, 并初始化其数据; 创立视图对象, 并用对模型的引用作为初始化参数之一; 视图经过调用附属过程支持变更-传播机制; 视图创立控制器, 此时将模型和视图的引用作为参数传递给控制器初始化过程; 控制器经过调用附属过程来支持变更-传播机制; 初始化完成, 应用程序开始处理事件。
简述”4+1”软件体系结构建模过程: 逻辑视图、 进程视图、 物理视图、 开发视图和场景, 统称”4+1”视图模型。逻辑视图: 侧重于描述体系结构的静态特征, 在面向对象设计方法中的类图就能够看作逻辑视图。开发视图侧重于描述软件模块开发的组织和管理, 考虑易用性、 重用性和通用性; 进程视图侧重于描述体系结构的运行特征, 关注其非功能性需求; 物理视图描述软件与硬件的映射关系, 考虑系统性能、 规模和可靠性; 场景是最重要的需求抽象, 用对象交互图来描述。两个作用: 一是发现构件; 二是验证SA设计。
Chain Of Responsibility: 使多个对象都有机会处理请求, 从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链, 并沿着这条链传递该请求, 直到有一个对象处理它为止。适用性: 有多个对象能够处理一个请求, 哪个对象处理该请求由运行时刻自动确定; 你想在不明确指定接收者的情况下, 向多个对象中的一个提交一个请求; 可处理一个请求的对象集合应被动态指定。参与者: Handler: 定义一个处理请求的接口。( 可选) 实现后继链。ConcreteHandler: 处理它所负责的请求; 可访问它的后继者; 如果可处理该请求, 就处理, 否则转发给后继者。Client: 向链上的具体处理者对象提交请求。
Strategy: 定义一系列的算法,把它们一个个封装起来, 而且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。适用性: 许多相关的类仅仅是行为有异; 需要使用一个算法的不同变体; 算法使用了客户不应该知道的数据; 一个类定义了多种行为, 而且这些行为在这个类的操作中以多个条件语句的形式出现。参与者: Strategy定义所有支持的算法的公共接口, Context使用这个接口来调用某Concrete Strategy定义的算法; Concrete Strategy: 以Strategy接口实现某具体算法。Context: 用一个Concrete Strategy对象来配置; 维护一个对Strategy对象的引用; 可定义一个接口来让Strategy访问它的数据。
Proxy: 使一个组件的客户机与一个组件的代表而不是组件本身通信。引入这样一个占位符有许多用途, 包括提高效率、 易于存取和防止越权访问等。适用性: 若一个对象需很长时间才能加载完成; 若对象位于远程主机上, 从网络进行加载可能会很慢; 若对象具有受限的存取权限, 则代理可验证用户存取特权的有效性。参与者: Proxy: 保存一个引用使得代理能够访问实体; 提供一个与Subject的接口相同的接口, 这样代理就能够用来替代实体; 控制对实体的存取, 并可能负责创立和删除它; 其它功能依赖于代理的类型。Subject: 定义RealSubject和Proxy的共用接口, 这样就在任何使用RealSubject的地方都能够使用Proxy。RealSubject: 定义Proxy所代表的实体。
Abstract Factory: 提供一个创立一系列相关或相互依赖对象的接口, 而无需指定它们具体的类; 抽象工厂是一个能从几组类中返回其中一某一组的工厂对象。适用性: 一个系统要独立于它的产品的创立、 组合和表示时; 一个系统要由多个产品系列中的一个来配置时; 当你要强调一系列相关的产品对象的设计以便进行联合使用时; 当你提供一个产品类库, 而只想显示它们的接口而不是实现时。参与者: Abstract Factory : 声明一个创立一系列抽象产品对象的操作接口。Concrete Factory: 实现创立具体产品对象的操作。Abstract Product: 为一类产品对象声明一个接口。Concrete Product: 定义一个将被相应的具体工厂创立的产品对象; 实现Abstract Product接口。Client: 仅使用由Abstract Factory和Abstract Product类声明的接口。

23种设计模式:
Abstract Factory: 提供一个创立一系列相关或相互依赖对象的接口, 而无需指定它们具体的类。
Builder: 将一个复杂对象的构件与它的表示分离, 使得同样的构建过程能够创立不同的表述。
Factory Method: 定义一个用于创立对象的接口, 让子类决定将哪一个类实例化。Factory Method使一个类的实例化延迟到其子类。
Prototype: 用原型实例指定创立对象的种类, 而且经过拷贝这个原型来创立新的对象。
Singleton: 保证一个类仅有一个实例, 并提供一个访问它的全局访问点。
Adapter: 将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类能够一起工作。
Bridge: 将抽象部分与它的实现部分分离, 使它们都能够独立地变化。
Composite: 将对象组合成树型结构以表示”部分－整体”的层次结构。Composite使得客户对单个对象和复合对象的使用具有一致性。
Decorator: 动态地给一个对象添加一些额外的职责。就扩展功能而言, Decorator模式比生成子类方式更为灵活。
Facade: 为子系统中的一组接口提供一个一致的界面, Facade模式定义了一个高层接口, 这个接口使得这一子系统更加容易使用。
Flyweight: 运用共享技术有效地支持大量细粒度的对象。
Proxy: 为其它对象提供一个代理以控制对这个对象的访问。
Chain of Responsibility: 为解除请求的发送者和接受者之间耦合, 而使多个对象都有机会处理这个请求。将这些对象连成一条链, 并沿着这条链传递该请求, 直到有一个对象处理它。
Command: 将一个请求封装为一个对象, 从而使你能够用不同的请求对客户进行参数化; 对请求排队或记录请求日志, 以及支持可取消的操作。
Interpreter: 给定一个语言, 定义它的文法的一种表示, 并定义一个解释器, 该解释器使用该表示来解释语言中的句子。
 Interator: 提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。
Mediator: 用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用, 从而使器耦合松散, 而且能够独立地改变它们之间的交互。
Memento: 在不破坏封装性的前提下, 捕获一个对象的内部状态, 并在该对象之外保存这个状态。这样以后就能够将该对象恢复到保存的状态。
Observer: 定义对象间的一种一对多的依赖关系, 以便当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并自动刷新。
State: 允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。
Strategy: 定义一系列的算法, 把它们一个个封装起来, 而且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。
Template Method: 定义一个操作中的算法的骨架, 而将一些步骤延迟到子类中。Template Method使得子类能够不改变一个算法的结构即可重定义该算法的某些特定步骤。
Visitor: 表示一个作用于某对象结构中的各元素的操作。它使你能够在不改变各元素的类的前提下定义作用于这些元素的新操作。

1. 软件体系结构的研究内容、 意义和作用。
研究内容: 软件体系结构设计的核心思想是描述构件( 连接子) , 以及构件之间的联系的。从软件系统整体结构出发, 设计软件的组织结构、 控制结构、 存储结构、 物理部署等。具体讲, 就是描述软件系统的整体架构, 架构由哪些构造块( 构件) 组成, 以及说明构造块( 构件) 之间的关联关系。
意义: ( 1) 体系结构是风险承担者进行交流的手段; ( 2) 体系结构是早期设计决策的体现; ( 3) 软件体系结构是可传递和可重用的模型。
作用: ( 1) 基于体系结构设计思想, 有助于设计者面临复杂领域问题时, 做出正确的选择, 最大限度地避免软件设计的结构性错误; ( 2) 体系结构设计文档成为设计人员、 用户及其它风险参与者一致的沟通文本, 以保证软件产品开发的成功率; ( 3) 体系结构有助于发现和提取可重用构件或模式。
2. 简述基于体系结构的软件开发过程。
基于体系结构的软件过程是在体系结构指导下的软件开发过程。首先设计体系结构, 软件系统的开发过程可描述为软件的演化与组装过程。具体过程可划分为体系结构的需求、 设计、 文档化、 复审、 实现、 演化等6个子过程。
3. 简述创立型、 结构型、 行为型模式。
创立型模式: 创立型模式抽象了实例化过程。它们帮助一个系统独立于如何创立、 组合和表示它的那些对象。类创立型模式使用继承改变被实例化的类。对象创立型模式将实例化委托给另一个对象。随着系统演化得越来越依赖于对象复合而不是类继承, 创立型模式变得更为重要。重心从对一组固定行为的硬编码( hard - coding) 转移为定义一个较小的基本行为集, 这些行为能够被组合成任意数目的更复杂的行为。在这些模式中有两个不断出现的主旋律: 第一, 它们都将关于该系统使用哪些具体的类的信息封装起来; 第二, 它们隐藏了这些类的实例是如何被创立和放在一起的。整个系统关于这些对象所知道的是由抽象类所定义的接口。创立型模式在什么被创立, 谁创立它, 它是怎样被创立的, 以及何时创立这些方面给予你很大的灵活性。创立型模式允许你用结构和功能差别很大的”产品”对象配置一个系统。配置能够是静态的( 即在编译时指定) , 也能够是动态的( 在运行时) 。
结构型模式: 结构型模式涉及到如何组合类和对象以获得更大的结构。结构型类模式采用继承机制来组合接口或实现。结构型对象模式不是对接口或实现进行组合, 而是描述了如何对一些对象进行组合, 从而实现新功能的一些方法。由于可在运行时刻改变对象组合关系, 因此对象组合方式具有更大的灵活性。
行为型模式: 行为模式涉及到算法和对象间职责的分配。行为模式不但描述对象或类的模式, 还描述它们之间的通信模式。行为类模式使用继承机制在类间分派行为。包括Template Method和Interpreter。行为对象模式使用对象复合而不是继承。一些行为对象模式描述了一组对等的对象怎样相互协作以完成其中任一个对象都无法单独完成的任务。
4. 描述软件设计模式的作用和构成。
设计模式是一套被重复使用、 多数人知晓的、 经过分类编目的、 代码设计经验的总结。使用设计模式是为了可重用代码、 让代码更容易被她人理解、 保证代码可靠性。
四个基本要素: 模式名称、 问题、 解决方案、 效果
描述设计模式: 模式名和分类、 意图、 别名、 动机、 参与者、 协作、 效果、 实现

5. 描述PAC( 或MVC) ( 主要是动态特征( 场景I 、 II) ) 。
6. 简述”4+1”软件体系结构建模过程。
7. 简述策略设计模式, 代理设计模式( 或职责链设计模式) 。

三、 设计题
UML图