软件体系结构习题复习

第一章

1、根据上述实践体会，用自己的话给软件架构下一个定义；

软件架构是：由结构和功能各异、相互作用的构件集合，按照一定的结构方式构成的系统。它包含了系统的基础构成单元、它们之间的作用关系、在构成系统时，它们的集成方法以及对集成约束的描述等。

2、在网上搜索一下有关软件架构的定义，比较一下它们之间的差别；

软件架构是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口_(计算机科学)来实现。

3、在“欢迎”程序架构中，构件、连接、连接关系分别完成了那些功能，起到了什么作用？创建新按钮是创建新的构件；建立消息映射是建立构件之间的连接；处理函数则根据对按钮、消息、处理三者之间的“协议”，编写相应代码。创建架构的过程，即使这么简单的程序，也包括了架构构成三要素的“构件”、“连接”、“连接关系”的全部内容。

4、从架构三要素的角度，说明“欢迎”程序的架构与“计算器”程序的架构，有什么相同

和不同？

从“编程”实现者的角度看，二者其实差别不是很大。“计算器”多做的工作，不是在接收到按钮消息后，简单地显示一条“欢迎”信息，而是实现“根据用户按下的按钮和四则运算规则计算并显示结果”。看一下代码就可以知道，从程序实现的角度看，后者与前者相比，不但逻辑复杂度和编程量差别并不大，更重要的，其架构基本相同。

5、在实践题2中，老师希望同学们在“欢迎”程序的基础上，再实现一个“时间”按钮，并

把“欢迎”与“时间”按钮的实际效果“对调”一下，有同学就把二个相应的处理函数中的代码对调了一下，更有同学把按钮的名子对调了一下，这是非常错误的。请从架构师的角度仔细想想为什么错，应该怎么实现“对调”？

第二章

1、通过使用VSTS，你体会架构描述与需求描述（例如：需求树）有什么相同和不同的地方？

架构描述表达了系统必须实现的需求，架构描述表达了软件系统的实现结构架构描述的第一个目的，就是在架构设计层次上，而不是需求层次上，表达系统的功能需求。架构描述的最主要的任务是，记录了系统的设计想法，具体表现为，将这些想法，按实现模块（而不是按功能），分解为具体的构件，并将这些构件的连接方式、连接关系，描述出来，让使用者知道未来系统的架构。

2、为满足关键质量属性而添加的内容，在VSTS中是如何表现的？

关键质量需求因素很多，视不同的应用系统而不同。如果按开发期和运行维护期划分，可以归纳如下：（1）开发期质量要素：易理解性；可扩展性；可重用性；可修改性；可移植性；可集成性；可测试性。（2）运行期质量要素：功能；性能；安全性；易用性；持续可用性；可伸缩性；互操作性；可靠性；健壮性。

3、基于架构的迭代，在VSTS中是如何表现的？

为了更好地理解架构在软件迭代中的作用，首先需要理解软件开发的产品特性。

1)软件产品和产品线的基本概念：当今市场，任何一款符合市场周期长、专业技术知识要求高、用户群庞大、产品功能复杂、安全和可靠性高、需要长期维护等特征的产品，一般都采

取产品线管理的方式，进行管理。所谓产品线的一般定义是：满足特定市场或用户需求的、有一组公共的、可管理的产品特性的、符合上述2个条件的产品的组合。

2)软件产品管理的基本概念：软件产品线管理的三大基本活动是：核心资源开发、利用核心资源的产品开发、核心资源和产品开发的技术和管理。

3)软件产品线核心资源的转化；

4）基于核心资源的软件产品开发

4、基于架构的关键构件，在VSTS中如何被定义为基线?

一般地，以软件架构作为阶段成果和迭代基础，过程管理不但需要架构描述作为软件过程文档，来记录和跟踪软件演化过程，而且，作为生命周期的重要环节，并贯穿始终，需要关注：架构与需求的对应（架构对需求的满足程度）；架构实现的验证（遵守架构约束）；架构与迭代开发维护（增量开发）；架构与项目管理的对应（如检查点、里程碑、关键交付成果等）；架构本身的变更历程等。

以上述目标为出发点，将系统合适的构件，作为工作项（工作项还包括其他内容），将架构的关键构件的状态变化，定义为基线，是比较合适的。因为，这些工作项的状态变化（设计、实现、测试、交付）将成为项目阶段目标设定、交付成果检验、计划进度考察和控制的“直接对象”和“标的物”。

5、在VSTS上，架构的四个作用达到了较好的统一，体现在什么地方？

架构“为什么”

架构描述对需求实现的作用和意义

第三章

1、通过架构分析，再进行二次开发（实现联网对弈），是否使二次开发的目标更明确？

从五子棋二次开发需求和任务划分（新增“局域网”模块以及如何添加到系统中去）的角度，分析了已有的系统架构。

2、原有的Five1-Five3的五子棋系统架构有什么问题？

从功能上看，Five1只能画棋盘，Five2只能人与人对弈，Five3可以人机对弈。这三套系统在功能上，每一个都比前一个、一步步地增加了很大一块“新功能”。但是，新增加的部分，居然在开发架构上没有变化。因为“新功能”在逻辑上，与以前的系统，有很大的不同，具有

一定的独立性，如果具有理想的开发架构设计的话，“新功能”最好放在一个单独的代码文件中，这样便于开发、调试和维护。很显然，原系统开发架构不能很好地帮助架构师分析三套系统之间的差异

3、如果重新设计五子棋的架构，你需要如何重新规划？为什么？

分析五子棋逻辑架构的时候，总结到：Five1的功能是画棋子、Five2的功能是人人下棋、Five3的功能是人机下棋。并且找到Five2为人人下棋新增的方法是Judge和Ring两个方法，Five3 为人机下棋新增的方法是UrgentPoint。那么，局域网五子棋的二次开发在“理论上”只要写一个新的“局域网”模块，加在“走下一步”的Case选择中，就可以了。而这个Case选择，一定就在OnLButtonDown代码中。

4、VS2010所提供的架构分析工具为架构分析带来什么好处？

VS2010在软件应用生命周期管理中，在架构方面，是通过新的（相比VS2005 ）架构浏览器和架构层图，以图形化的方式描述系统架构，从而使得项目中的技术人员或非技术人员,都能以模型、透过图形化的方式进行协作，以及定义企业与系统功能。另外，VS2010也同时支持统一建模语言UML及特定领域语言(DSL)，架构设计人员在VS2010中可以更有效率的进行.Net架构设计工作。

VS2010架构工具可以让架构师了解应用程序的功能设计，并帮助验证设计与执行过程中是否偏离开发目的。它除了支持一般系统分析设计流程（即需求向实体转化）外，也支持另一类的流程——逆向工程。

5、你现在对“架构设计文档规范”是否有了新的理解？

作为架构设计的阶段交付成果，编写构架设计文档的目的是让不同的风险承担者都能快速找到和理解他们所需要的信息，知道系统的目标和约束、关键质量需求是否可以满足，以及为了满足这些需求所做出的架构设计决策。包括：系统是否被有效地分离、分离的各个部分是如何连接、协调配合的等等。这是下一步进行详细设计和实现的基础。因此，只有这些工作很好地完成，架构设计才能够成为下一阶段工作的基础和出发点。而架构文档则是这些工作成果的具体表现形式，而不是目的。

编写架构文档的根本原则是：一定要从使用者的角度出发，而不是为架构而架构、为文档而文档。在这个方面，学校学生的毛病特别明显，而造成这个问题的原因，可能是教这门课的老师，自己也没有什么架构设计的实际体验，只能教给学生一大堆架构概念和模型，不知道这些架构模型到底能解决什么问题，更不知道针对特定需求，可以采用哪些架构设计策略和方法更好。

架构发展过程：

在软件发展过程中，对架构的认识，经历了三个层次的过程：

●执行级

以针对存储器的映射、数据地址的安排、堆栈和寄存器的分配等为中心。在这个阶段，架构的构件是硬件，集成和行为规则是这些硬件单元的非常具体明确的组合集成方法。

●代码级

以针对算法和数据结构的选择等为中心。在这个阶段，架构的构件是程序设计语言的字符、指针、进程控制等，集成的是记录、数组和过程等。集成和行为规则是以程序设计方法、数据结构方法为核心。

●架构级

以针对与构件相关联的系统总体性能为中心。在这个阶段，构件是模块、模块的相互关系等，它重点研究从模块到子系统、到系统的集成规则。

软件架构的作用

体现为4个方面：在系统设计层面上（1）表达系统的功能需求是如何被实现的；（2）表达关键需求和设计约束的实现方案；（3）作为迭代开发的基础；（4）成为过程管理的依据。前3点反映的是对软件系统本身的作用，最后一点，反映的是对软件开发过程的作用。

第四章

1、架构师为什么要参与需求过程，架构师在参与需求过程中，主要关注什么？

站在架构师的角度，“反观”需求过程，了解需求分析师是如何完成需求的获取、描述，处理、记录和评审过程的，他们（包括用户）关心什么，不太关心什么。架构师应该如何解读需求阶段结束后，项目团队所提交的阶段交付物成果——“需求文档”等。通过对这些过程的回顾，可以帮助架构师更进一步地从需求文档、需求分析师的行为和心理等层面，更深入地了解和理解“需求”，这样，才能够更好地理解架构设计的“起点”，以实现架构设计的目标。在需求的开发过程中，需求的获取、分析、处理和验证是需求开发过程的四个核心过程域和四个关键阶段。前一个阶段是后一个阶段的前提和基础，每个阶段的目标、活动、交付物成果、利益相关者各不相同，因此，架构师的关注也会有所不同。

关注点：

(1) 需求分析阶段架构师的关注点：当前的用户需求与产品线的关系（用户的具体需求与产品的总体发展路线的关系）、用户需求与开发平台的关系（在哪个平台上继续进行迭代和二次开发）等等。

(2)需求处理阶段架构师的关注点：a该阶段所产生的最后需求文档中所记录和确定的需求边界、范围等内容。b业务领域模型反映了现在、以致未来一段时间（产品生命周期内）软件系统的需求。因此,架构师在关注需求的时候，针对做什么和不做什么，应该有基于更广泛的业务模型的考虑。c开发平台的限制、重用限制、接口限制等。 d架构师也应关注需求基线。

(3)需求评审阶段架构师的关注点：从需求评审以上活动看，架构师的角色要“简单”一些，他就是项目经理的“技术助手”和具体执行者，他关注构成项目关键点的那些“要素”是什么、在那里、是否合适等。

2、在需求过程中，架构师与需求分析师的角色，有什么不同？请举例说明。

需求谈判的一个难点，是对需求实现的优先次序，进行排序，甚至要进行“割舍”，讨价还价。如何对用户进行“价值引导”，并最终“搞定”用户，非常重要。能够引导用户的前提，是需求分析师比用户更熟悉业务、同时，还熟悉用户并不太懂的“系统”，因此，才有资格“引导”用户的需求，这是一名资深“需求分析师”的价值所在。例如：用户往往是“强势”的，但这种情况下，不单需要用户能够明确确认他们提出的需求（用户有时希望“模糊”，这对他们更有利），另一方面，对于在现有资源（时间、成本、技术条件等）情况下，只能安排实现有限的功能，而不能满足所有的功能要求

在需求评审阶段，架构师与被评审者——需求分析师的角度显然是不同的。前者是审查者（站在接收者的角度），后者是被审查者（交付者）。但由于架构师也部分参与了需求过程，因此，架构师不可能与需求分析师完全站在对立的“战壕”里。从这个意义上说，需求评审不仅仅是需求分析师与架构师之间的“交接”，还有很多“第三者”参与和监督。

3、以数据流为核心的面向过程的需求转换为什么不能适应需求的变化？

通过教科书里两个案例的分析可以看到，在基于数据流的架构设计案例中，变换流分析和系统架构设计是基于数据流图（DFD）进行转换，因此，转换的结果将必然导致系统的架构与DFD数据流的走向，保持完全对应和一致。在基于U/C矩阵的案例中，系统子系统的

划分是根据系统的功能模块和模块的输入/输出数据关系，实际上，本质上依据的还是数据流，只不过不是基于数据流的架构设计案例的一条数据流主线，而可能是（功能模块）点对点（输出对应输入）的数据流。上述二种架构设计方法，导致设计出来的系统架构，完全受制于原系统的数据流。不论是DFD的数据流，还是U/C的功能模块之间的数据流。当数据流的流向发生变化的时候，系统架构也要发生相应变化。

如果系统是按数据流设计的，则因为流程变量，带来数据流的变化，这一变化可能是“巨大”和“颠覆”性的，那么，系统架构就要大变，甚至完全不能适应新的需求。不但如中国电信这样的“巨变”，就是平时经常发生的“小的”需求变更，对于一个用户系统而言，也是不可避免的，有时甚至新系统还没有上线，需求就变了，这就是面向过程方法的致命弱点。

基于数据流的系统架构，当数据流变化的时候，已有的架构不能适应变化，经常需要修改，甚至“架构重组”，这对项目团队带来了巨大的开发成本和时间压力。相比而言，面向对象的方法，不是从需求模型的数据流“导出”来的，而是根据“对象”和对象关系分析得到的，因此，与业务系统的数据流，保持了相对的独立性。

4、针对需求变化，面向对象的需求转换为什么具有很强的适应性？

在一个用户组织中，由于组织的目标随时间、外部环境、内部需要等因素，时常发生变化。为了适应组织目标的变化，必然会导致组织结构发生变化、组织结构的变化，导致组织的业务流程发生变化。例如：中国电信因改革开放和市场竞争的需要，将其过去一个主要基于计划经济方式运作的企业，向市场化转化，甚至邀请国外著名咨询公司，来做“流程重组”。这就导致其内部组织结构、工作岗位设置和业务流程，发生很大变化，大量“后台”业务和管理向支持“一线”工作这个大目标转变。这一变化，体现到内部业务和管理系统上，就是大量的需求变更。

5、ATM扩展项目中，另加的故障处理方案和“反冲”方案的最主要不同是什么，各有什么利弊？

银行针对ATM故障进行的处理，在“有效性”方面，是不存在问题的，问题仅仅存在于“实时性”上。不能满足“实时性”的根本原因，是这类故障，必须等到当日系统“清算”的时候，才进行处理。而故障当时，只做“封帐”处理。

第六章

1、尽量详细地画出电梯控制系统的架构图；

2、描述各子系统的主要责任和功能、子系统相互之间的协同与联系；

根据需求分析的结果，将电梯控制系统划分为三个子系统，每一个也是满足构成子系统的要素定义：（1）问题域；（2）交互（内外）；（3）数据。

电梯子系统包括：

?问题域：升降、门开关；交互：楼层的位置显示；数据：无。

按扭子系统包括：

?问题域：电梯/楼层按扭；交互：按下/显示；数据：无。

控制子系统包括：

问题域：接收/处理请求；交互：电梯/按扭；数据：状态、请求队列等

子系统的各个设计元素（类与对象、关系、行为和功能）具有一些共同的特征：

具有某些对象的一致特性；

用来协同完成同一个或一组功能；

位于同一个硬件中；

用于管理相同的资源等。

?方法：实现一个具体的处理操作；

?类：实现一类对象的处理；

?模块（组件）：由一个或多个类协同完成一组对象操作和功能；

?子系统（包）：完成相对独立特性和功能的多个模块构成；

?系统：多个子系统相互配合才能满足一个完整应用的需求，从而构成了软件“系统”；

集成系统：一个大型企业往往使用多套系统，多套系统通过互操作形成“集成系统”

?当进行高一抽象层次（需求、系统级）分析和架构设计时，子系统是具有特定属性、

完成特定功能一个原子单元、一个黑盒；

?当进行子系统本身的设计时（本章讨论的内容），子系统是一个结构复杂的白盒；

?当子系统作为第三方组件被运用时，只需要关心其对外的接口，此时，将子系统看

成提供服务的外部不可见组件。

?当使用第三方的成熟框架作为某一系统或子系统的架构基础时，则应当仔细研究其

框架架构，并选择其何时的位置，进行继承和扩展。这是因为此时是使用它的结构

而不仅仅是服务。

3、在已有的三个子系统之间，当发生竞争的时候，是如何进行“仲裁”的，依据什么进行

仲裁；

4、是否还可以提出另外一种与上述划分方法不同的子系统划分方法，说明不同的理由、优劣是什么；

虑电梯控制的分布、实时和并发特性，以请求、状态、运行控制为主要对象，兼顾系统设计的可扩展性，以满足新的需求，将子系统划分如下：

（1）请求子系统：

问题域：接受来自楼层和电梯轿厢内的请求，可以是单独电梯的，也可以是集

中式的，甚至是来自控制室人为的临时指令；支持并发、实时的请求。将所有

请求按预定规则排序，支持多种排序策略和优先级。接受请求后点亮相应的指

示灯，完成请求后熄灭相应的指示灯；

交互：与运行控制交互，提出请求；支持多种请求提交优先等级策略，以提高

特殊情况的响应实时性；获得运行状态，熄灭相应的指示等；

数据：记录请求并按请求到达时间等规则排序，请求已被执行则删去队列中的

请求；

扩展：支持楼层安全性扩展，输入选择楼层按钮时，可与客人的房卡号码进行

比对验证；支持智能选题提示扩展，在客人选择要去的楼层后，提示可最快达

到提供服务的电梯号和预计等待时间等；

（2）状态子系统：

问题域：接受来自电梯的运行状态传感器的信息并显示运行方向和到达楼层；

交互：与运行控制交互，接受运行方向和到达楼层指令；接受实际运行状态传

感器信息并显示；通知请求队列删除已满足请求；

数据：电梯运行状态；

扩展：暂无。

（3）运行控制子系统：

问题域：接受来自请求队列的请求并根据运行状态、调度策略和参考其他因素，

决定当前电梯运行方向和到达楼层，向电梯下达运行指令；接受控制室的调度

计划、策略和直接扩展指令；允许控制室可视化地编辑、修改和调整当前的调

度计划和调度策略；

交互：接收请求和运行状态，根据调度结果，发出运行指令；

数据：记录请求和状态、调度策略、其他信息等；

扩展：有紧急、安全、消防、VIP、运行效率优先、等待优先、省电低耗等多套

临时计划和对策；调度策略和计划可预定和临时取消；支持当前运行状态评价

并提示更换调度策略（例如：上班时间段改为正常时间段）；可设置电梯运行参

数，模拟演示预定的计划并根据效果修改；开放一定的权限，支持远程访问和

控制；支持远程报警和预警；支持神经网络、多目标规划等高级排队策略；

在电梯控制系统实际运行架构中，上述三个子系统实际上对应三个（组）并发的进程，各自独立并相互联系。

在这样的划分之下，确定了各子系统之间的任务责任、连接方式和协同关系。而按钮、显示灯、门、马达模块等，都分别归属各自对象，成为其内部数据（逻辑）或外部执行模块（物理）。

在电梯控制职能化和未来可灵活扩展的考虑下，这样的划分把握了系统的关注点和分离点，职责界限明晰，修改和扩展方便。

第七章

1、在采用WMP组件实现的播放器项目中，哪些功能属于业务逻辑层、哪些属于业务

实体层？

业务逻辑层：媒体文件名的组织和选择

业务实体层：媒体文件的解码、播放、快进快退、解码、输出流控制等与媒体有关的基本操作

2、COM组件与一般的动态链接库DLL的区别是什么？在播放器的例子中体现在什么

地方？

基于COM组件的开发和使用，最主要的特点，就是由于组件接口的标准和规范化，使得开发和使用都变得非常简单。COM的重要性质之一是位置透明性。相对而言，以往在调用普通动态链接库中的输出函数时，必须要将此动态链接库放到应用程序的同级目录下，或将动态库的位置信息硬编码到程序中的做法，其实都说明了普通动态库的位

置不透明性。当客户程序调用COM对象时，会更轻松一些，因为调用方不需要考虑COM 组件所处的位置，不论它在哪个目录下，或是否在当前工作站上，一切都由系统提供的机制来保障对COM对象的定位，这就是位置无关性。COM也可以有两种类型的载体，一种是动态链接库（DLL），另一种是标准可执行文件（EXE）。前者由于可以在被本地客户程序加载时，与客户程序共存一个地址空间，而被称为进程内服务器（in-process server）；后者由于在运行时与客户程序处于不同的地址空间中，因此也被称为进程外服务器（out-process server）。使用COM组件比使用普通的DLL，要简单得多。你只要知道组件的对象是什么，该对象的属性和方法是什么？，组织好自己的“业务流程”，也就是什么时候放什么曲子，放第几首，是顺序播放还是随机播放，然后直接用这个对象就可以了。用架构师的眼光看，就是：表现层需要自己设计，业务逻辑层要自己组织，到业务实体层，就可以直接调用COM组件了。

3、如果希望播放器要能够支持外挂，需要做什么？

第八章

1、在医药管理系统中，MVC的控制器层的作用体现在什么地方？有何改进的空间？

控制（Controller）：处理用户的输入（如：鼠标、键盘等），转化成用户对模型或视图的服务请求，并把信息的变化，传递给视图。用户仅通过控制器与系统交互。

控制可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。 Struts 的作用就是一个典型的控制器，在SSH架构中，这一点看得更明显。

2、在医药管理系统中，Spring层的作用体现在什么地方？如何能更好地发挥Spring层的作用？

在医药管理系统中，Spring分为二层。UserAccountManager接口封装了所有的、与用户权限管理有关的模块，包括授权。角色、部门管理、验权都可以通过这个接口，访问相应的方法。UserRoleService接口封装具体的验权操作，可以提供如授权模块使用（授权前检查是否已授权）。

Spring也可以运用于接口，提高接口实现的灵活性。

Spring 能有效地组织J2EE应用各层的对象。不管是Struts层的Action对象，还是Spring 层的Service对象，还是Hibernate层的DAO对象，都可在Spring的管理下有机地协调、运行。如果说接口提供的是多方向、多通道的立交跨接，而Spring则提供了可根据需要“开启/改变连接”的通道，而非固定不变的立交。

Spring将各层的对象以松耦合的方式组织在一起，Action对象无须关心Service对象的具体实现，Service对象无须关心持久层对象的具体实现，各层对象的调用完全面向接口。当系统需要重构时，代码的改写量将大大减少。这是Spring层的最大特色。

Spring是依赖控制反转IoC（Inversion of Control）技术，来实现上述松耦合的。

3、当数据库改为SQL2008时，Hibernate层的好处体现在哪里？

Hibernate是基于Java的对象/关系数据库映射(ORM)工具，它是对象模型（JavaBean实体类）与关系模型（关系数据库表）之间交互的桥梁。Hibernate对JDBC进行了非常轻量级的对象封装，使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。Hibernate 并不是唯一为SSH架构准备的，它可以应用在任何使用JDBC的场合，它既可以在Java的客户端程序使用，也可以在Servlet/JSP的Web应用中使用。它支持各种关系数据库，从一对一到多对多的各种复杂关系。