1、东南大学 软件系统设计与体系结构复习第一章：概述1、 软件危机2、 软件架构的作用：软件架构在高级层次上对软件进行描述，便于软件开发过程中各个视角的统一，能够及早发现开发中的问题并支持各种解决方案的评估和预测3、 什么是软件架构？ 软件架构是一个软件系统的设计图，并不仅限于软件系统的总体结构，还包含一些质量属性以及功能和结构之间的映射关系，即设计决策。4、软件架构的两个主要焦点：系统的总体结构、需求和实现之间的对应。5、*软件架构的主要思想：将注意力集中在系统总体结构的组织上。6、软件架构的实现的手段：运用抽象方法屏蔽错综复杂的模块间连接，使人们的认知提升并保持在整体结构的部件“交互”层次；进
2、一步将交互从计算中分离出来，建立“组件+连接件+配置”的软件系统高层结构组织方式。7、*软件架构的特征：（1）注重可重用性组件及架构级重用（2）利益相关者较多平衡需求（3）关注点分离模块化、分而治之（4）质量驱动关注非功能属性（5）提倡概念完整性强调设计决策是一个持续的过程（6）循环风格用标准方法来处理反复出现的问题8、软件架构的发展阶段（1）基础研究阶段（1968-1994）：提出“软件架构”，开始尝试模块化的实践（2）概念体系和核心技术形成阶段（1991-2000）：软件架构作为一个独立的领域出现；软件架构核心技术的发展；软件组件技术（3）理论体系丰富发展阶段（1996-1999）（4）理
3、论完善和普及应用阶段（1999至今）第二章：软件架构定义1、 *组成派定义依据：软件架构主要反映系统是由哪些部分组成的，以及这些部分是如何组成的，强调软件系统的整体结构和配置。软件架构=元素，组成，原理l 架构元素：具有一定形式的结构化元素，包括处理元素、数据元素和连接元素l 架构组成：由加权的属性和关系构成。属性用来约束架构元素的选择，关系用来约束架构元素的放置。l 架构原理：捕获在选择架构风格、架构元素和架构形式的选择动机软件架构包括组件、连接件和约束三大要素。l 组件：可以是一组代码，也可以是独立的程序l 连接件：过程调用、管道和消息等，用于表示组件之间的相互关系l 约束：一般为组件连接
4、时的条件软件架构是某一系统的基本组织结构，其内容包括软件组件、组件间的联系、组件与其环境间的联系，以及指导上述内容设计和演化的原理。2、 *决策派定义依据：软件架构设计是软件设计的一部分，软件设计实际上是开发人员意志和决策在软件开发过程中的体现，软件架构更是高层领导和架构师意志和决策的体现，强调设计决策，更加注重架构风格和模式的选择。软件架构是一系列重要决策的集合，这些决策关于：软件系统的组织；组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为；如何组合这些元素，使它们逐渐合成为更大的子系统；架构风格；这些元 素以及它们的接口、协作和组合。软件架构是架构层次上所有设计决策
5、的集合体，这些设计决策与以下内容有关：架构改造的影响、原理、设计准则、设计约束以及附加需求。软件架构是“设计决策+设计”，这里的设计是指设计决策的推理过程。3、 组成拍和决策派的区别：组成派关注于软件本身，将软件架构看作组件和交互的集合；决策派关注于软件架构中的实体（人），将软件架构视为一系列重要设计决策的集合。（可以再把两者的定义依据答一下）4、 *参考定义框架（一般性定义）： 软件架构由：组件、连接件、配置、端口和角色五种元素组成。 组件：具有某种功能的可重用的软件模块单元，表示了系统中主要的计算单元和数据存储。组件有两种：复合组件和原子组件。复合组件由其他复合组件和原子组件通过连接而成。
6、 连接件：表示了组件之间的交互。 配置：表示了组件和连接件的拓扑逻辑和约束。 端口：组件作为一个封装的实体，只能通过其接口与外部交互，组件的接口由一组端口组成，每个端口表示了组件和外部环境的交汇点。 角色：连接件作为建模软件体系结构的主要是提，同样也有接口，连接件的接口由一组角色组成，连接件的每个角色定义了该连接件表示的交互的参与者。第三章：软件架构模型1、 软件架构模型：对架构设计决策的具象化和文档化。2、 软件架构模型的意义（为什么要有软件架构模型？）： 软件架构模型能够将软件架构某些关键或关注的方面剥离出来，使用统一的图形、文档和数据进行描述，达到直观、便捷地理解、分析和交流。3、 *软
7、件架构建模的五类方法：基于非规范的图形表示的建模方法基于UML的建模方法 各个图分别对系统的哪些方面进行了建模？l 用例图从概念上描述了系统的逻辑功能；l 类图反映了架构中的静态关系；l 顺序图反映了系统的同步和并行逻辑；l 活动图表现了一定的并发行为；l 组件图反映了系统的逻辑结构；l 部署图描述了物理资源的分布情况。 4+1 view：逻辑视图：关注功能，可以采用UML用例图来实现开发视图：关注软件的静态组织结构，使用UML的类图、对象图和组件图来表示模块，用包来表示子系统，利用连接表示模块和子系统之间的关联。过程视图：关注软件的流程特征，可以采用UML的状态图、顺序图和活动图来实现。物理
8、视图：关注功能单元的分布状况，可以使用UML的配置图来实现场景试图：关注用户需求，可以使用用例或场景来描述。 基于形式化的建模方法 基本思想：利用一些已知特性的数学抽象来为目标软件系统的状态特征和行为特征构造模型。基于UML形式化的建模方法 基本思想：利用形式化与UML结合的建模方法研究成果，对UML图形赋予形式化语义，然后就可以利用已有的形式化语言和工具对UML模型进行推理验证。其他建模方法：文本语言建模方法、模型驱动的架构建模方法4、 *软件架构建模方法的发展趋势：第一层次：文本模型 从原始的自然语言文档化到以XML为代表的由固定规范、结构的文档化。第二层次：图形可视化模型 （什么是可视化
9、？）将软件架构按照图形的方式进行表达，需要便于涉众阅读、理解和交流，使之不会因图形过于复杂而难以把握软件架构的概况。第三层次：UML模型 使用单一的集成的表示法来对系统的多个方面进行建模，模型范畴包括从系统的静态结构到动态行为特征、从系统的逻辑功能到物理部署。第四层次：形式化模型 （什么是形式化？） 面向模型的方法，利用一些已知特性的数学抽象来为目标软件系统的状态特征和行为特征构造模型。 代数方法，它为目标软件系统的规格说明提供了一种特殊的机制，包括描述抽象概念并进行进程联接和推理的方法。第五层次：未来模型 只是一种设想，需要前四层技术都发展到相当成熟的阶段。只有将各个层次的先进技术结合在一起
10、，才能建立完备、精确的模型，才能利用模型直接生成全部代码。第四章：软件架构风格1、 什么是软件架构风格？ 软件架构风格又称软件架构惯用模式，是描述某一特定应用领域中系统组织方式的惯用模式，作为“可复用的组织模式和习语”，为设计人员的交流提供了公共的术语空间，促进了设计复用与代码复用。2、 使用架构风格的好处： 可以极大地促进设计的重用性和代码的重用性，并且使得系统的组织结构易被理解。 使用标准的架构风格可较好地支持系统内的互操作性以及针对特定风格的分析。*经典的软件架构风格*1、 管道过滤器风格（1）特点： 在管道过滤器风格下，每个功能模块都有一组输入和输出。功能模块称作过滤器；功能模块间的连
11、接可以看作输入、输出数据流之间的通路，称作管道。 管道-过滤器风格的特性之一在于过滤器的相对独立性，即过滤器独立完成自身功能，相互之间无需状态交互。 从解耦的角度：每个过滤器之间都是解耦的，每个过滤器都专注于自己的职责。 过滤器是独立运行的组件； 过滤器对其处理上下连接的过滤器“无知”； 结果的正确性不依赖于各个过滤器运行的先后次序。（解耦的好处）解耦能够保持组件之间的自主和独立。它的直接结果就是改动成本低，维护成本低，可读性高。（2） 优点： 由于每个组件行为不受其他组件的影响，整个系统的行为易于理解。 管道-过滤器风格支持功能模块的复用。（任何两个过滤器，只要它们之间传送的数据遵守相同的规
12、约，就可以相连接。） 基于管道-过滤器风格的系统具有较强的可维护性和可扩展性。 支持一些特定的分析，如吞吐量计算和死锁检测等。（3） 缺点： 管道-过滤器风格往往导致系统处理过程的成批操作。 根据实际设计的需要，设计者需要对数据传输进行特定的处理（如加密），导致过滤器必须对输入、输出管道中的数据流进行解析和反解析，增加了过滤器具体实现的复杂性。 交互式处理能力弱。（4） 实例：传统的编译器，一个阶段的输入是另一个阶段的输出。Unix和DOS中的管道操作符|：将符号|之前的命令的输出作为|之后命令的输入。2、 事件驱动风格（1） 基本思想：不直接调用一个过程，而是发布或广播一个或多个事件。系统中
13、的其它组件通过注册与一个事件关联起来的过程，来表示对某一个事件感兴趣。当这个事件发生时，系统本身会调用所有注册了这个事件的过程。这样一个事件的激发会导致其它模块中过程的隐式调用。（2） 从解耦的角度： 系统组件松耦合。在系统执行的过程中，可以并行处理不可预期的事件发生。观察者模式：让多个观察者对象同时监听某一主题对象，当该对象状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。（3） 特点： 事件发布者不知道哪些组件会受到事件的影响；组件不能对事件的处理顺序，或者事件发生后的处理结果做任何假设。 从架构上来说，事件驱动系统的组件提供了一个过程集合和一组事件。过程可以使用显示的方法进行
14、调用，也可以由组件在系统事件中注册。当触发事件时，会自动引发这些过程的调用。连接件既可以是显示过程调用，也可以是一种绑定事件声明和过程调用的手段。（4） 优点：事件声明者不需要知道哪些组件会影响事件，组件之间关联较弱。 提高软件复用能力。只要在系统事件中注册组件的过程，就可以将该组件集成到系统中。系统便于升级。只要组件名和事件中所注册的过程名保持不变，原有组件就可以被新组件替代。（5） 缺点： 组件放弃了对计算的控制权，完全由系统来决定。 存在数据交换问题。 该风格中，正确性验证成为一个问题。3、 黑板风格（1） 特点： 黑板系统是传统上被用于信号处理方面进行复杂解释的应用程序，以及松散耦合的
15、组件访问共享数据的应用程序。 黑板架构实现的基本出发点是已经存在一个对公共数据结构进行协同操作的独 立程序集合。黑板系统的命于它反映的是一种信息共享系统如同教室的黑板一样，有多个人读，也有多个人写。数据驱动或状态驱动的控制机制。系统在运行时，每当有新输入、新结果和新状态写入黑板时，中心控制组件就对黑板上的信息进行评价，并据此协调各专门程序进行工作。组成部分：知识源、黑板数据结构、控制器。（2） 优点：便于多客户共享大量数据，他们不关 心数据何时有的、谁提供的、怎样提供的。 既便于添加新的作为知识源代理的应 用程序，也便于扩展共享的黑板数据结构。知识源可重用。支持容错性和健壮性。（3） 缺点：不
16、同的知识源代理对于共享数据结构 要达成一致，而且，这也造成对黑板数据 结构的修改较为困难要考虑到各个代 理的调用。需要一定的同步/加锁机制保证数据 结构的完整性和一致性，增大了系统复杂度。4、 C2风格（1） 特点： 是一种层次体系架构风格。 C2架构风格可以概括为：通过连接件 绑定在一起的按照一组规则运作的并行组件网络。该规则规定了所有组件之间 的交互必须通过异步消息机制来实现 C2是一种基于组件和消息的架构风格， 适用于GUI软件开发，构建灵活和可扩展的应用系统。（如游戏）C2架构的内部，通信和处理是分开完成的。（2） 优点：可使用任何编程语言开发组件，组件重 用和替换易实现；由于组件之间
17、相对独立，依赖较小，因 而该风格具有一定扩展能力，可支持不同粒度 的组件；组件不需共享地址空间；可实现多个用户和多个系统之间的交互；可使用多个工具集和多种媒体类型，动 态更新系统框架结构。（3） 缺点：不太适合大规模流式风格系统，以及对数 据库使用比较频繁的使用。5、 客户机/服务器风格（1） 特点： 主要针对资源不对等问题而提出的一种共享策略。 客户机和服务器是两个相互独立的逻辑 系统，为了完成特定的任务而形成一种 协作关系。一般的，客户机为完成特定的工作向服 务器发出请求；服务器处理客户机的请 求并返回结果。 客户机程序和服务器程序配置在同一台 计算机上时：采用消息、共享存储区和 信号量等
18、方法实现通信连接。 客户机程序和服务器程序配置在分布式 环境中时：通过远程调用（Remote Produce Call，RPC）协议来进行通信。（2） 两层C/S架构： 组成：客户机、数据库服务器 优点：客户机组件和服务器组件分别运行在不同 的计算机上，有利于分布式数据的组织和处理。 组件之间的位置是相互透明的 客户机程序和服务器程序可运行在不同的 操作系统上，便于实现异构环境和多种不同开 发技术的融合。软件环境和硬件环境的配置具有极大的灵 活性，易于系统功能的扩展。将大规模的业务逻辑分布到多个通过网络 连接的低成本的计算机上，降低了系统的整体开销。缺点：开发成本较高（客户机的软硬件要求高）。
19、客户机程序的设计复杂度大，客户机负荷 重。信息内容和形式单一。C/S架构升级需要开发人员到现场更新客 户机程序，对运行环境进行重新配置，增加了 维护费用。两层C/S结构采用了单一的服务器，同时 以局域网为中心，难以扩展到Internet。数据安全性不高。（3） 三层C/S架构 组成：客户机、应用服务器、数据库服务器 相比于两层C/S架构的优点： 合理地划分三层结构的功能，可以使 系统的逻辑结构更加清晰，提高软件的可维 护性和可扩充性。 在实现三层C/S架构时，可以更有效地 选择运行平台和硬件环境，从而使每一层都 具有清晰的逻辑结构、良好的负荷处理能力 和较好的开放性。 在C/S架构中，可以分别
20、选择合适的编 程语言并行开发。 系统具有较高的安全性。使用时需要注意的问题：如果各层之间的通信效率不高，即使 每一层的硬件配置都很高，系统的整体性能 也不会太高。 必须慎重考虑三层之间的通信方法、 通信频率和传输数据量，这和提高各层的独 立性一样也是实现三层C/S架构的关键性问 题。6、 浏览器/服务器风格（1） 特点： 组成：浏览器，Web服务器、数据库服务器 与三层C/S结构的解决方案相比，B/S架 构在客户机上采用了WWW浏览器， 将Web服务器作为应用服务器。 B/S架构核心是Web服务器，数据请求、 网页生成、数据库访问和应用程序执行 全部由Web服务器来完成。 在B/S架构中，系统
21、安装、修改和维护 全在服务器端解决，客户端无任何业务 逻辑。（2） 优点 客户端只需要安装浏览器，操作简单， 能够发布动态信息和静态信息。 运用HTTP标准协议和统一客户端软 件，能够实现跨平台通信。 开发成本比较低，只需要维护Web服 务器程序和中心数据库。客户端升级可以 通过升级浏览器来实现。（3） 缺点 个性化程度比较低，所有客户端程序的 功能都是一样的。 客户端数据处理能力比较差，加重了 Web服务器的工作负担，影响系统的整体性能。 在B/S架构中，数据提交一般以页面为单 位，动态交互性不强，不利于在线事物处理。 B/S架构的可扩展性比较差，系统安全性 难以保障。 B/S架构的应用系统
22、查询中心数据库，其 速度要远低于C/S架构。7、 面向服务架构风格SOA（1） 特点： SOA 是一个组件模型，它将应用程序的不 同功能单元（服务）通过这些服务之间定 义良好的接口和契约联系起来。 基本过程：发布（发布到服务注册中心）-发现-绑定和调用 面向服务软件架构风格在于具有基于标 准、松散耦合、共享服务和粗粒度等优 势，表现为易于集成现有系统、具有标 准化的架构、提升开发效率、降低开发 维护复杂度等。 通过采用SOA架构，在进行一次开发成 本急剧减少的同时，由于系统具有松散 耦合的特征使得维护成本也大大减少。（2） 优点： 灵活性，根据需求变化，重新编排服 务。 对IT资产的复用。 使
23、企业的信息化建设真正以业务为核 心。业务人员根据需求编排服务，而不必 考虑技术细节。（3） 缺点： 服务的划分很困难。 服务的编排是否得当。 如果选择的接口标准有问题，如主流的 Web service之类，会带来系统的额外开销和不 稳定性。 对IT硬件资产还谈不上复用。 目前主流实现方式接口很多，很难统一。 目前主流实现方式只局限于不带界面的 服务的共享。8、 模型-视图-控制器风格（MVC）（1） 特点： 主要是针对编程语 言Smalltalk 80所提出的一种软件设计模 式。MVC被广泛的应用于用户交互程序的设 计中。 MVC结构主要包括模型、视图和控制器三部分。 模型(Model, M)
24、：模型是应用程序的 核心，它封装了问题的核心数据、逻辑关 系和计算功能，提供了处理问题的操作过 程。视图(View,V)：视图是模型的表示， 提供了交互界面，为用户显示模型信息。控制器(Controller, C)：控制器负责处 理用户与系统之间的交互，为用户提供操 作接口。（2） 优点： 多个视图与一个模型相对应。变化传播机制确保了所有相关视图都能够及时地获 取模型变化信息，从而使所有视图和控制器同 步，便于维护。 具有良好的移植性。由于模型独立于视 图，因此可以方便的实现不同部分的移植。 系统被分割为三个独立的部分，当功能 发生变化时，改变其中的一个部分就能满足要 求。（3） 缺点： 增加
25、了系统设计和运行复杂性。 视图与控制器连接过于紧密，妨碍了 二者的独立重用。 视图访问模型的效率比较低。由于模 型具有不同的操作接口，因此视图需要多 次访问模型才能获得足够的数据。 频繁访问未变化的数据，也将降低系统的性能。第六章：软件架构与敏捷开发1、 *敏捷开发的基本理念： 强调个体和互动比强调过程和工具更好 强调获得可运行的软件比强调完成详尽的文档好 强调与客户合作比强调进行详细的合同谈判好 强调响应变化比强调遵循既定的计划好2、 *敏捷开发与架构设计的关系 软件架构与敏捷开发的出发点是一致的。都是一个权衡的过程目的都是为了提高软件开发效率、提高软件质量、降低软件成本，将开发团队的价值最
26、大化。 敏捷开发也需要重视软件架构。两者在软件开发实践中能够共同存在，且互相促进。 敏捷开发改变了软件架构的设计方式。重视软件的架构设计，但是轻架构的详细设计。将传统的架构设计分成：种子架构设计+详细架构设计。3、*敏捷开发中如何改变了软件架构的设计方式？敏捷开发重视软件的架构设计，但是轻架构的详细设计。将传统的架构设计分成：种子架构设计+详细架构设计。种子架构设计关注软件系统的骨架或轮廓的设计。把传统软件开发前期的详细架构设计分散到了整个敏捷开发软件过程中，以达到提高效率、减少风险的目的。敏捷开发中详细设计的原则：重要、关键的设计决策必须在软件开发前确定，对于其他详细的设计决策，则需要时再做
27、。开发过程中，所有的利益相关者都必须全程在一起，便于充分的交流和权衡。 将需求文档化，重视需求，明确表示出不同需求之间的权衡过程。开发人员要及时的验证架构。 如果必须要进行修改，改动越早越好。 不要突发奇想的修改架构，修改架构需要大家一起深思熟虑。4、敏捷开发在实践中表现为一种迭代、增量和持续集成的开发方法。 迭代反映了项目的开发节奏，是一个多周期的开发过程。 增量说明了项目的实际进展，整个项目就是由很多增量构成的。 持续集成反映了集成增量的过程是持续进行的。5、 敏捷开发的设计理念：团体设计（群体决策，全部人员参与）、简单设计（表达形式的简单化和现实抽象的简单化）6、 优秀的敏捷软件架构的设
28、计过程一般同时包含规划式设计和演进式设计，具体体现为初始阶段设计和迭代过程中的设计。第七章：架构驱动的软件开发1、 *架构驱动的软件开发步骤和开发流程 架构需求获取架构的需求源于：系统的质量目标、系统的业务目标、软件的利益相关者。架构设计、文档化和评估是一个迭代过程也是架构驱动的软件开发的核心所在。 基本架构设计 通过获得的架构需求信息，架构师对架构进行设计并通过文档进行记录。 架构记录文档化 软件系统架构结构的唯一体现方式。旨在方便程序员和分析师的 工作。它可以加强软件系统的利益相关者之 间的联系，从而确定出满足需求的软件架构 。 架构评估 评估的目的是分析架构以识别潜在风险并验证设计中已经
29、满足的质量需求。 架构实现 架构维护2、 *质量场景抽象场景：根据软件的使用进行一定层面 的分类（如：软件流水线方式、三层结构 等），这些分类就会对相应软件提出一定 的需求，此类需求即为架构需求的抽象场景。对于架构师和领域专家来说，需要做的是从抽象 场景描述中获得特定的质量属性场景。组成：源、触发、环境、制品、响应、响应测试、完整的质量场景描述的对象：架构需求 应用：在架构需求获取步骤中用来描述架构需求 作为基本架构设计的依据和目标 在架构评估时根据质量场景来验证架构是否满足质量需求第八章：软件架构设计和实现1、*成功的软件架构应具有的品质：（1）良好的模块化（2）适应功能需求的变化，适应技术的变化（3）对系统的动态运行有良好的规划（4）对数据的良好规划（5）明确、灵活的部署规划2、*架构设计原则：软件架构设计原则有一般设计原则和关键设计原则两类。l 一般原则：包含商业原则、数据原则、应用程序原则、技术原则等；l 关键设计原则：关注分离点、单一职责原则、最少知识原则等。3、 *将软件架构的概念和原则引入软件需求阶段有什么好处？不引入可能会引起什么问题？用
