软件体系结构习题复习

第一章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、在需求过程中，架构师与需求分析师的角色，有什么不同？请举例说明。

需求谈判的一个难点，是对需求实现的优先次序，进行排序，甚至要进行“割舍”，讨价还价。

如何对用户进行“价值引导”，并最终“搞定”用户，非常重要。

能够引导用户的前提，是需求分析师比用户更熟悉业务、同时，还熟悉用户并不太懂的“系统”，因此，才有资格“引导”用户的需求，这是一名资深“需求分析师”的价值所在。