像学写⽂章⼀样，在学会字、词、句之后，就应上升到段落，就应追求⽂章的“布局谋篇”，这就是架构。通俗地讲，软件架构设计就是软件系统的“布局谋篇”。 ⼈们在软件⼯程实践中，逐步认识到了软件架构的重要性，从⽽开辟了⼀个崭新的研究领域。软件架构的研究内容主要涉及软件架构描述、软件架构设计、软件架构风格、软件架构评价和软件架构的形成⽅法等。
软件设计⼈员学习软件架构知识旨在站在较⾼的层⾯上整体地解决好软件的设计、复⽤、质量和维护等⽅⾯的实际问题。
1 软件架构概述
软件架构是软件抽象发展到⼀定阶段的产物，从编程的⾓度，可以清晰地看到软件抽象层次和表达⼯具的发展历史。
20 世纪 60 年代是⼦程序的年代：出现了原始的软件架构，即⼦程序，并以程序间的调⽤为连接关系。
20 世纪 70 年代是模块化的年代：出现了数据流分析、实体—关系图（E-R 图）、信息隐藏等⼯具和⽅法，软件的抽象层次发展到了
模块级。
20 世纪 80 年代是⾯向对象的年代：基于模块化的编程语⾔进⼀步发展成⾯向对象的语⾔，继承性地增加了⼀种新元素之间的连接关
系。
20 世纪 90 年代是框架的年代：标准的基于对象的架构以框架的形式出现了。如电⼦数据表、⽂档、图形图像、⾳频剪辑等可互换的
⿊箱对象，可以相互嵌⼊。
当前（最近 10 年来）：中间件和 IT 架构作为标准平台出现，⽤可购买可复⽤的元素来构建系统，同时，基于架构的开发⽅法和理论不断成熟。 1 软件架构的定义
软件架构仍在不断发展中，还没有形成⼀个统⼀的、公认的定义，这⾥仅举出⼏个较权威的定义。
定义 1：软件或计算机系统的软件架构是该系统的⼀个（或多个）结构，⽽结构由软件元素、元素的外部可见属性及它们之间的关系组成。
定义 2：软件架构为软件系统提供了⼀个结构、⾏为和属性的⾼级抽象，由构成系统的元素的描述、这些元素的相互作⽤、指导元素集成的模式及这些模式的约束组成。
定义 3：软件架构是指⼀个系统的基础组织，它具体体现在：系统的构件，构件之间、构件与环境之间的关系，以及指导其设计和演化的原则上。（IEEE1471- 2000）
前两个定义都是按“元素—结构—架构”这⼀抽象层次来描述的，它们的基本意义相同，其中定义 1 较通俗，因此，本章采⽤这⼀定义。该定义中的“软件元素”是指⽐“构件”更⼀般的抽象，元素的“外部可见属性”是指其他元素对该元素所做的假设，如它所提供的服务、性能特征等。
为了更好地理解软件架构的定义，特作如下说明：
（1）架构是对系统的抽象，它通过描述元素、元素的外部可见属性及元素之间的关系来反映这种抽象。因此，仅与内部具体实现有关的细节是不属于架构的，即定义强调元素的“外部可见”属性。
足摩
（2）架构由多个结构组成，结构是从功能⾓度来描述元素之间的关系的，具体的结构传达了架构某⽅⾯的信息，但是个别结构⼀般不能代表⼤型软件架构。
（3）任何软件都存在架构，但不⼀定有对该架构的具体表述⽂档。即架构可以独⽴于架构的描述⽽存在。如⽂档已过时，则该⽂档不能反映架构。
（4）元素及其⾏为的集合构成架构的内容。体现系统由哪些元素组成，这些元素各有哪些功能（外部可见），以及这些元素间如何连接与互动。即在两个⽅⾯进⾏抽象：在静态⽅⾯，关注系统的⼤粒度（宏观）总体结构（如分层）；在动态⽅⾯，关注系统内关键⾏为的共同特征。
（5）架构具有“基础”性：它通常涉及解决各类关键的重复问题的通⽤⽅案（复⽤性），以及系统设计中影响深远（架构敏感）的各项重要决策（⼀旦贯彻，更改的代价昂贵）。
（6）架构隐含有“决策”，即架构是由架构设计师根据关键的功能和⾮功能性需求（质量属性及项⽬相关的约束）进⾏设计与决策的结果。不同的架构设计师设计出来的架构是不⼀样的，为避免架构设计师考虑不周，重⼤决策应经过评审。特别是架构设计师⾃⾝的⽔平是⼀种约束，不断学习和积累经验才是摆脱这种约束⾛向⾃由王国的必经之路。
金地九珑璧在设计软件架构时也必须考虑硬件特性和⽹络特性，因此，软件架构与系统架构⼆者间的区别其实不⼤。但是，在⼤多情况下，架构设计师在软件⽅⾯的选择性较之硬件⽅⾯，其⾃由度⼤得多。因此，使⽤“软件架构”这⼀术语，也表明了⼀个观点：架构设计师通常将架构的重点放在软件部分。
将软件架构置于商业背景中进⾏观察，可以发现软件架构对企业⾮常重要。
（1）影响架构的因素。软件系统的项⽬⼲系⼈（客户、⽤户、项⽬经理、程序员、测试⼈员、市场
⼈员等）对软件系统有不同的要求开发组织（项⽬组）有不同的⼈员知识结构、架构设计师的素质与经验、当前的技术环境等⽅⾯都是影响架构的因素。
这些因素通过功能性需求、⾮功能性需求、约束条件及相互冲突的要求，影响架构设计师的决策，从⽽影响架构。
（2）架构对上述诸因素具有反作⽤，例如，影响开发组织的结构。架构描述了系统的⼤粒度（宏观）总体结构，因此可以按架构进⾏分⼯，将项⽬组为⼏个⼯作组，从⽽使开发有序；影响开发组织的⽬标，即成功的架构为开发组织提供了新的商机，这归功于：系统的⽰范性、架构的可复⽤性及团队开发经验的提升，同时，成功的系统将影响客户对下⼀个系统的要求等。这种反馈机制构成了架构的商业周期。
2 软件架构的重要性
从技术⾓度看，软件架构的重要性表现为如下⼏⽅⾯。
（1）项⽬关系⼈之间交流的平台。软件系统的项⽬关系⼈分别关注系统的不同特性，⽽这些特性都由架构所决定，因此，架构提供了⼀个共同语⾔（公共的参考点），项⽬关系⼈以此作为彼此理解、协商、达成共识或相互沟通的基础。架构分析既依赖于⼜促进了这个层次上的交流。
土耳其式开局
（2）早期设计决策。从软件⽣命周期来看，软件架构是所开发系统的最早设计决策的体现，主要表现为：
剧本杀成社交新潮流
架构明确了对系统实现的约束条件：架构是架构设计师对系统实现的各⽅⾯进⾏权衡的结果，是总体设计的体现，因此，在具体实现时必须按架构的设计进⾏。
苏武留胡节不辱架构影响着系统的质量属性：要保证系统的⾼质量，具有完美的架构是必要的（虽然不充分）。
架构可以⽤来预测系统的质量，例如，可以根据经验对该架构的质量（如性能）作定性的判断。
架构为维护的决策提供根据。在架构层次上能为⽇后的更改决策提供推理、判断的依据。⼀个富有⽣命⼒的架构，应该是在最有可能更改的地⽅有所考虑（架构的柔性），使其在此点最容易进⾏更改。
架构有助于原型开发。可以按架构构造⼀个⾻架系统（原型），例如，在早期实现⼀个可执⾏的特例，确定潜在的性能问题。
借助于架构进⾏成本与进度的估计。
（3）在较⾼层⾯上实现软件复⽤。软件架构作为系统的抽象模型，可以在多个系统间传递（复⽤），特别是⽐较容易地应⽤到具有相似质量属性和功能需求的系统中。产品线通常共享⼀个架构。 产品线的架构是开发组织的核⼼资产之⼀，利⽤架构及其范例进⾏多系统的开发，在开发时间、成本、⽣产率和产品质量⽅⾯具有极⼤的回报。基于架构的开发强调对各元素的组合或装配。系统开发还可以使⽤其他组织开发的元素，例如购买商业构件。
（4）架构对开发的指导与规范意义不容忽略。架构作为系统的总体设计，它指导后续的详细设计和编码。架构使基于模板的开发成为可能，有利于开发的规范化和⼀致性，减少开发与维护成本。架构可以作为培训的基础，有利于培养开发团队和培训相关⼈员。
从软件开发过程来看，如果采⽤传统的软件开发模型（⽣命周期模型），则软件架构的建⽴应位于概要设计之前，需求分析之后。
基于架构的软件开发模型则明确地把整个软件过程划分为架构需求、设计、⽂档化、评审（评估）、实现、演化等 6 个⼦过程。本章各节将分别对这些⼦过程进⾏讨论。
3 架构的模型
trus软件架构作为⼀个有机的整体，可以分解成多个侧⾯来认识，每个侧⾯强调它的不同⽅⾯的特征，从⽽使架构设计师能整体地把握它的重点。我们可以将软件架构归纳成 5 种模型：结构模型、框架模型、动态模型、过程模型和功能模型。最常⽤的是结构模型和动态模型。
（1）结构模型。这是⼀个最直观、最普遍的建模⽅法。这种⽅法以架构的构件、连接件和其他概念来刻画结构，并⼒图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质。研究结构模型的核⼼是架构描述语⾔。
（2）框架模型。框架模型与结构模型类似，但它不太侧重描述结构的细节⽽更侧重于整体的结构。框架模型主要以⼀些特殊的问题为⽬标建⽴只针对和适应该问题的结构。
（3）动态模型。动态模型是对结构或框架模型的补充，研究系统“⼤颗粒”的⾏为性质。例如，描述系统的重新配置或演化。动态可能指系统总体结构的配置、建⽴或拆除通信通道或计算的过程。
（4）过程模型。过程模型研究构造系统的步骤和过程。因⽽结构是遵循某些过程脚本的结果。
（5）功能模型。该模型认为架构由⼀组功能构件按层次组成，且下层向上层提供服务。它可以看作是⼀种特殊的框架模型。
这 5 种模型各有所长，也许将 5 种模型有机地统⼀在⼀起，形成⼀个完整的模型来刻画软件架构更合适。即将软件架构视为这些模型的统⼀体，通过这些模型的表述（⽂档）来完整反映软件架构。例如，Kruchten 在 1995 年提出了⼀个“4+1”的视图模型。“4+1” 视图模型从 5 个不同的视⾓包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件架构。每⼀个视图只关⼼系统的⼀个侧⾯，5 个视图结合在⼀起才能反映系统的软件架构的全部内容。“4+1”视图模型如图 9-1 所⽰。 （1）逻辑视图：主要⽀持系统的功能需求，即系统提供给最终⽤户的服务。在逻辑视图中，系统分解成⼀系列的功能抽象，这些抽象主要来⾃问题领域。这种分解不但可以⽤来进⾏功能分析，⽽且可⽤作标识在整个系统的各个不同部分的通⽤机制和设计元素。在⾯向对象技术中，通过抽象、封装和继承，可以⽤对象模型来代表逻辑视图，⽤类图来描述逻辑视图。逻辑视图中使⽤的风格为⾯向对象的风格，逻辑视图设计中要注意的主要问题是要保持⼀个单⼀的、内聚的对象模型贯穿整个系统。
（2）开发视图：也称为模块视图，主要侧重于软件模块的组织和管理。软件可通过程序库或⼦系统进⾏组织，这样，对于⼀个软件系统，就可以由不同的⼈进⾏开发。开发视图要考虑软件内部的需求，如软件开发的容易性、软件的重⽤和软件的通⽤性，要充分考虑由于具体开发⼯具的不同⽽带来的局限性。开发视图通过系统输⼊输出关系的模型图和⼦系统图来描述。可以在确定了软件包含的所有元素之后描述完整的开发⾓度，也可以在确定每个元素之前，列出开发视图原则。
（3）进程视图：侧重于系统的运⾏特性，主要关注⼀些⾮功能性的需求，例如系统的性能和可⽤性。
进程视图强调并发性、分布性、系统集成性和容错能⼒，以及逻辑视图中的主要抽象的进程结构。它也定义逻辑视图中的各个类的操作具体是在哪⼀个线程中被执⾏的。进程视图可以描述成多层抽象，每个级别分别关注不同的⽅⾯。
（4）物理视图：主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。当软件运⾏于不同的节点上时，各视图中的构件都直接或间接地对应于系统的不同节点上。因此，从软件到节点的映射要有较⾼的灵活性，当环境改变时，对系统其他视图的影响最⼩。
（5）场景：可以看作是那些重要系统活动的抽象，它使四个视图有机地联系起来，从某种意义上说，场景是最重要的需求抽象。在开发架构时，它可以帮助设计者到架构的构件和它们之间的作⽤关系。同时，也可以⽤场景来分析⼀个特定的视图，或描述不同视图构件间是如何相互作⽤的。场景可以⽤⽂本表⽰，也可以⽤图形表⽰。
逻辑视图和开发视图描述系统的静态结构，⽽进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说，侧重的⾓度也有所不同。例如，对于管理信息系统来说，⽐较侧重于从逻辑视图和开发视图来描述系统，⽽对于实时控制系统来说，则⽐较注重于从进程视图和物理视图来描述系统。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议