1785人阅读
&系统架构与软件架构
&&& 再深一层分析，无论是建筑工程领域，还是其他工程领域（包括计算机科学），从它们的演化历史来看，直觉上我们似乎能够发现其共同点：即从哲学的角度上来说，它们都是人类为了克服与生俱来的恐惧而进行的创造、演化和发展。人类到底恐惧什么呢？&&& 我们可以注意到，人类本能当中有这样一个重要的共同点：对不确定的、感觉到威胁的事物具有强烈的不安全感。这就激发了人类尽量把这些恐惧的因素控制在最小范围内的愿望。这也就是各个工程学科（包括系统及软件工程领域）在日积月累的发展历程中，逐步规范化、科学化、系列化以及统一化，最终保证人类在复杂环境中，当不确定的因素存在时，依然能够进行有效的控制和协调。&&& 基于同样的目的，计算机科学中也诞生了一个重要的概念，即&系统架构（System Architecture）&。1997年，Eberhardt Rechtin与MarkW.Maier在其著名的研究论著中，为计算机科学界总结了人类在系统架构方面的实践成果，从而奠定了系统科学和系统架构在计算机科学中的基石。他们通过实践总结，列举了一系列系统架构的应用领域：工业系统、航空系统、软件与信息技术系统等。无论是什么样的系统架构应用领域，应用系统架构原理的目的都是一样的，即完整地、高一致性地、综合全面地、平衡各种利弊地、有技术和市场前瞻性地设计系统和实施系统。Eberhardt Rechtin 与MarkW. Maier这样的方法论级的实践总结，当然立即受到了工程界的热烈欢迎。因为本能的不安全感，会让我们不由自主地摒弃那些不确定的、不系统化的架构经验。&&& 我们平常还能看到这样一种现象：有的行业的架构设计从业人员把自己叫做&系统架构师&（System Architect）；有的软件工程领域的架构人员把自己也叫做&系统架构师&，而不是&软件架构师&。从比尔&盖茨称呼自己为&软件架构师&（Software Architect）来看，他非常明白这两个词的联系和区别。严格地讲，Eberhardt Rechtin与MarkW.Maier提出的&系统架构&或&系统设计&，与我们平时所谈到的&软件架构&或&软件设计&既有千丝万缕的联系，又有比较明显的区别。&&& 当我们把软件技术与其他技术（例如物理技术、化学技术、机械技术、电子技术等）一起放在历史的河流中进行比较时，我们就会发现：为了开发和生产一个产品，其他相关技术的投入和花费的逐年增长率，要远远低于软件设计与开发投入的逐年增长率。&&& 在软件技术方面投入的增长率高于在其他技术方面投入的增长率，其主要原因是系统或产品不像过去那样严重受制于硬件或其他技术，而是更加依赖那些非功能方面的要求，这体现在更加依赖于系统对软件及其架构品质的要求。&&& 我们可以以一个医疗行业的CT机（Computed Tomography，计算机X线断层摄影机）系统为例来进行分析。CT机是现代医学诊断中不可缺少的设备。通过X线束对人体的某一部分按一定厚度的层面进行扫描，由于人体各种组织的疏密程度不同，X线的穿透能力也不同，所以检测器接收到的射线就有了差异。由此产生的信号转变为数字信息后由计算机进行处理，并输出到显示屏上，显示出人体组织的图像，以发现病变并确定病变的相对空间位置、大小、数目等。&&& 由于CT机的关键部件包括X线系统、高压发生器、检测器、成像系统、机架与床等，涉及电子、机械、图像处理、计算机等学科。综合考虑，针对CT机质量方面的系统级要求（CT机系统级的要求其实很多，仅列出部分作为参考）如下：& 安全性（Safety）& 保密性（Security）& 可靠性（Reliability）& 健壮性（Robustness）& 可制造和装配性（Manufacturability and Assembly，机械设计的人员对这个词不会陌生）& 可测试性（Testability）& 可服务性（Serviceability）& 可配置性（Configurability）& 可安装性（Installability，你可以在国际软件测试资质认证委员会ISTQB提供的软件测试标准术语表里找到这个词）& 可演化性（Evolvability）& 可移植性（Portability）& 可升级性（Upgradeability）& 可扩展性（Extendability）& 可维护性（Maintainability）& 可处置性（Disposability，环境工程的人员对这个词不会陌生）&&& 除了CT机系统级的质量要求外，我们还可以列出CT机在其他非功能性方面的要求，例如：& 可用性（Useability）& 有吸引力的图像界面& 强吞吐量的生产能力（Throughput or Productivity）& 快速的响应时间（Response Time）& 高质量的图像处理& 状态可重现性（Reproduceability）& 状态可预测性（Predicatability）& 高精度计算& 低廉的成本& 低廉的运行操作成本& 与周边环境的强交互能力（CT机操作人员、病人、维护人员等）& 耗电低& 较低的其他资源消耗（水、空气、化学药剂等）& CT机的大小和重量适中& 资源利用率高& 运输和移动方便& CT机市场技术领先性& CT机设计与行业标准吻合&&& 如果把上述所有CT机系统的非功能性要求做一下汇总和分析，我们就能发现：这些要求都是系统级的设计要求；如果加上CT机的功能要求，就能够代表要生产的CT系统是什么样子、未来会如何运作；这些非功能性的要求，有些是与机械和电子设计相关的，但绝大多数是与软件架构和设计相联系的。这也就意味着，一个完整的CT机系统的非功能性指标要求是由多个子系统和多种技术结合在一起才能得以实现，即一个系统往往是软硬结合的。&&& 从CT机系统这个例子，我们可以清晰地看到：一个系统的实现是结合了各种子系统和各种技术的实现。系统架构的主要任务是界定系统级的功能与非功能的要求、规划要设计的整体系统的特征、规划并设计实现系统级的各项要求的手段，同时利用各种学科技术完成各子系统的结构构建。而&&& 软件架构首先要理解系统架构，并从软件架构学科的视角对系统架构提出相应的意见，同时从软件的视角协助规划、设计那些实现系统级的各项要求的手段，并最终为各软件子系统提供架构和设计。&&& 从中可以看出，在系统架构活动中，由于对软件越来越深入的依赖，软件架构的任务也显现出重要的作用。而且系统架构与软件架构是紧密联系和互相依赖的。本书的重点将主要集中在&软件架构&，而非&系统架构&上。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：3073324次
积分：43783
积分：43783
排名：第70名
原创：1374篇
转载：82篇
评论：1784条
(9)(13)(21)(15)(14)(4)(21)(4)(5)(4)(6)(9)(4)(6)(4)(7)(7)(5)(8)(13)(3)(7)(4)(9)(10)(8)(7)(23)(16)(4)(17)(13)(8)(29)(23)(4)(21)(23)(14)(23)(11)(12)(16)(12)(22)(20)(25)(26)(31)(47)(33)(7)(11)(7)(14)(27)(26)(14)(19)(32)(20)(19)(19)(30)(27)(5)(20)(19)(20)(17)(18)(38)(26)(44)(40)(38)(30)(21)(24)(52)(30)(15)(10)(1)(2)(10)(7)
() () () () () () ()软件体系结构的概念
软件体系结构的概念
一 从软件危机谈起　　软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。20世纪60年代末至20世纪70年代初，"软件危机"一词在计算机界广为流传。事实上，几乎从计算机诞生的那一天起，就出现了软件危机，只不过到了1968年在原西德加密施（Garmish）召开的国际软件工程会议上才被人们普遍认识到。1 软件危机的表现（1）软件成本日益增长　　在计算机发展的早期，大型计算机系统主要是被设计应用于非常狭窄的军事领域。在这个时期，研制计算机的费用主要由国家财政提供，研制者很少考虑到研制代价问题。随着计算机市场化和民用化的发展，代价和成本就成为投资者考虑的最重要的问题之一。20世纪50年代，软件成本在整个计算机系统成本中所占的比例为10%-20%。但随着软件产业的发展，软件成本日益增长。相反，计算机硬件随着技术的进步、生产规模的扩大，价格却不断下降。这样一来，软件成本在计算机系统中所占的比例越来越大。到20世纪60年代中期，软件成本在计算机系统中所占的比例已经增长到50%左右。　　而且，该数字还在不断地递增，下面是一组来自美国空军计算机系统的数据：1955年，软件费用约占总费用的18%，1970年达到60%，1975年达到72%，1980年达到80%，1985年达到85%左右。（2）开发进度难以控制　　由于软件是逻辑、智力产品，软件的开发需建立庞大的逻辑体系，这是与其他产品的生产不一样的。例如：工厂里要生产某种机器，在时间紧的情况下可以要工人加班或者实行"三班倒"，而这些方法都不能用在软件开发上。　　在软件开发过程中，用户需求变化等各种意想不到的情况层出不穷，令软件开发过程很难保证按预定的计划实现，给项目计划和论证工作带来了很大的困难。　　BROOK曾经提出："在已拖延的软件项目上，增加人力只会使其更难按期完成"。事实上，软件系统的结构很复杂，各部分附加联系极大，盲目增加软件开发人员并不能成比例地提高软件开发能力。相反，随着人员数量的增加，人员的组织、协调、通信、培训和管理等方面的问题将更为严重。　　许多重要的大型软件开发项目，如IBM OS/360和世界范围的军事命令控制系统（WWMCCS），在耗费了大量的人力和财力之后，由于离预定目标相差甚远不得不宣布失败。（3）软件质量差　　软件项目即使能按预定日期完成，结果却不尽人意。1965年至1970年，美国范登堡基地发射火箭多次失败，绝大部分故障是由应用程序错误造成的。程序的一些微小错误可以造成灾难性的后果，例如，有一次，在美国肯尼迪发射一枚阿脱拉斯火箭，火箭飞离地面几十英里高空开始翻转，地面控制中心被迫下令炸毁。后经检查发现是飞行计划程序里漏掉了一个连字符。就是这样一个小小的疏漏造成了这支价值1850万美元的火箭试验失败。　　在"软件作坊"里，由于缺乏工程化思想的指导，程序员几乎总是习惯性地以自己的想法去代替用户对软件的需求，软件设计带有随意性，很多功能只是程序员的"一厢情愿"而已，这是造成软件不能今人满意的重要因素。（4）软件维护困难　　正式投入使用的软件，总是存在着一定数量的错误，在不同的运行条件下，软件就会出现故障，因此需要维护。但是，由于在软件设计和开发过程中，没有严格遵循软件开发标准，各种随意性很大，没有完整的真实反映系统状况的记录文档，给软件维护造成了巨大的困难。特别是在软件使用过程中，原来的开发人员可能因各种原因已经离开原来的开发组织，使得软件几乎不可维护。　　另外，软件修改是一项很"危险"的工作，对一个复杂的逻辑过程，哪怕做一项微小的改动，都可能引入潜有资料表明，工业届为维护软件支付的费用占全部硬件和软件费用的40%-75%。2 软件危机的原因　　从软件危机的种种表现和软件作为逻辑产品的特殊性可以发现软件危机的原因： （1）用户需求不明确　　在软件开发过程中，用户需求不明确问题主要体现在四个方面：　　◇ 在软件开发出来之前，用户自己也不清楚软件的具体需求；　　◇ 用户对软件需求的描述不精确，可能有遗漏、有二义性、甚至有错误；　　◇ 在软件开发过程中，用户还提出修改软件功能、界面、支撑环境等方面的要求；　　◇ 软件开发人员对用户需求的理解与用户本来愿望有差异。（2）缺乏正确的理论指导　　缺乏有力的方法学和工具方面的支持。由于软件不同于大多数其他工业产品，其开发过程是复杂的逻辑思维过程，其产品极大程度地依赖于开发人员高度的智力投入。由于过分地依靠程序设计人员在软件开发过程中的技巧和创造性，加剧软件产品的个性化，也是发生软件危机的一个重要原因。 （3）软件规模越来越大　　随着软件应用范围的增广，软件规模愈来愈大。大型软件项目需要组织一定的人力共同完成，而多数管理人员缺乏开发大型软件系统的经验，而多数软件开发人员又缺乏管理方面的经验。各类人员的信息交流不及时、不准确、有时还会产生误解。软件项目开发人员不能有效地、独立自主地处理大型软件的全部关系和各个分支，因此容易产生疏漏和错误。（4）软件复杂度越来越高　　软件不仅仅是在规模上快速地发展扩大，而且其复杂性也急剧地增加。软件产品的特殊性和人类智力的局限性，导致人们无力处?复杂问题"。所谓"复杂问题"的概念是相对的，一旦人们采用先进的组织形式、开发方法和工具提高了软件开发效率和能力，新的、更大的、更复杂的问题又摆在人们的面前。3 如何克服软件危机　　人们在认真地研究和分析了软件危机背后的真正原因之后，得出了"人们面临的不光是技术问题，更重要的是管理问题。管理不善必然导致失败。"的结论，便开始探索用工程的方法进行软件生产的可能性，即用现代工程的概念、原理、技术和方法进行计算机软件的开发、管理和维护。于是，计算机科学技术的一个新领域--软件工程诞生了。　　软件工程是用工程、科学和数学的原则与方法研制、维护计算机软件的有关技术及管理方法。软件工程包括三个要素：　　（1）方法。软件工程方法为软件开发提供了"如何做"的技术，是完成软件工程项目的技术手段；　　（2）工具。软件工具是人类在开发软件的活动中智力和体力的扩展和延伸，为软件工程方法提供了自动的或半自动的软件支撑环境；　　（3）过程。软件工程的过程则是将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。　　迄今为止，软件工程的研究与应用已经取得很大成就，它在软件开发方法、工具、管理等方面的应用大大缓解了软件危机造成的被动局面。二 构件和软件重用1 软件重用　　软件重用是指在两次或多次不同的软件开发过程中重复使用相同或相近软件元素的过程。软件元素包括程序代码、测试用例、设计文档、设计过程、需求分析文档甚至领域知识。通常，把这种可重用的元素称作软构件，可重用的软件元素越大，我们就说重用的粒度越大。　　使用软件重用技术可以减少软件开发活动中大量的重复性工作，这样就能提高软件生产率，降低开发成本，缩短开发周期。同时，由于软构件大都经过严格的质量认证，并在实际运行环境中得到校验，因此，重用软构件有助于改善软件质量。此外，大量使用软构件，软件的灵活性和标准化程度也可望得到提高。 　　在这里，我们只是为了后面的行文方便，简单地介绍了软件重用技术的概念和作用。软件重用本身是一门博大精深的技术，有兴趣的读者可以进一步查阅有关资料和书籍。2 构件　　一般认为，构件是指语义完整、语法正确和有可重用价值的单位软件，是软件重用过程中可以明确辩识的系统；结构上，它是语义描述、通讯接口和实现代码的复合体。简单地说，构件是具有一定的功能，能够独立工作或能同其它构件装配起来协调工作的程序体，构件的使用同他的开发、生产无关。从抽象程度来看，面向对象技术已达到了类级重用(代码重用)，它以类为封装的单位。这样的重用粒度还太小，不足以解决异构互操作和效率更高的重用。构件将抽象的程度提到一个更高的层次，它是对一组类的组合进行封装，并代表完成一个或多个功能的特定服务，也为用户提供了多个接口。整个构件隐藏了具体的实现，只用接口提供服务。　　近年来，构件技术发展迅速，已形成三个主要流派，分别是IBM的CORBA 、Sun的Java平台和Microsoft的COM+。 如果把软件系统看成是构件的集合，那么从构件的外部形态来看，构成一个系统的构件可分为5类：　　（1）独立而成熟的构件。独立而成熟的构件得到了实际运行环境的多次检验，该类构件隐藏了所有接口，用户只需用规定好的命令进行使用。例如，数据库管理系统和操作系统等。　　（2）有限制的构件。有限制的构件提供了接口，指出了使用的条件和前提，这种构件在装配时，会产生资源冲突、覆盖等影响，在使用时需要加以测试。例如，各种面向对象对象程序设计语言中的基础类库等。　　（3）适应性构件。适应性构件进行了包装或使用了接口技术，把不兼容性、资源冲突等进行了处理，可以直接使用。这种构件可以不加修改地使用在各种环境中。例如ActiveX等。　　（4）装配的构件。装配的构件在安装时，已经装配在操作系统、数据库管理系统或信息系统不同层次上，使用胶水代码（Blue Code）就可以进行连接使用。目前一些软件商提供的大多数软件产品都属这一类。　　（5）可修改的构件。可修改的构件可以进行版本替换。如果对原构件修改错误、增加新功能，可以利用重新"包装"或写接口来实现构件的替换。这种构件在应用系统开发中使用得比较多。　　基于构件的软件开发通常包括构件获取、构件分类和检索、构件评估、适应性修改以及将现有构件在新的语境下组装成新的系统。构件获取可以有多种不同的途径：　　（1）从现有构件中获得符合要求的构件，直接使用或作适应性修改，得到可重用的构件；　　（2）通过遗产工程，将具有潜在重用价值的构件提取出来，得到可重用的构件；　　（3）从市场上购买现成的商业构件，即COTS构件；　　（4）开发新的符合要求的构件。　　一个企业或组织在进行以上决策时，必须考虑到不同方式获取构件的一次性成本和以后的维护成本，做出最优的选择。三 软件体系结构1 软件体系结构的兴起　　六十年代的软件危机使得人们开始重视软件工程的研究。起初，人们把软件设计的重点放在数据结构和算法的选择上，随着软件系统规模越来越大、越来越复杂，整个系统的结构和规格说明显得越来越重要。软件危机的程度日益加剧，现有的软件工程方法对此显得力不从心。对于大规模的复杂软件系统来说，对总体的系统结构设计和规格说明比起对计算的算法和数据结构的选择已经变得明显重要得多。在此种背景下，人们认识到软件体系结构的重要性，并认为对软件体系结构的系统、深入的研究将会成为提高软件生产率和解决软件维护问题的新的最有希望的途径。　　自从软件系统首次被分成许多模块，模块之间有相互作用，组合起来有整体的属性，就具有了体系结构。好的开发者常常会使用一些体系结构模式作为软件系统结构设计策略，但他们并没有规范地、明确地表达出来，这样就无法将他们的知识与别人交流。软件体系结构是设计抽象的进一步发展，满足了更好地理解软件系统，更方便地开发更大、更复杂的软件系统的需要。　　事实上，软件总是有体系结构的，不存在没有体系结构的软件。体系结构（Architecture）一词在英文里就是"建筑"的意思。把软件比作一座楼房，从整体上讲，是因为它有基础、主体和装饰，即操作系统之上的基础设施软件、实现计算逻辑的主体应用程序、方便使用的用户界面程序。从细节上来看每一个程序也是有结构的。早期的结构化程序就是以语句组成模块，模块的聚集和嵌套形成层层调用的程序结构，也就是体系结构。结构化程序的程序（表达）结构和（计算的）逻辑结构的一致性及自顶向下开发方法自然而然地形成了体系结构。由于结构化程序设计时代程序规模不大，通过强调结构化程序设计方法学，自顶向下、逐步求精，并注意模块的耦合性就可以得到相对良好的结构，所以，并未特别研究软件体系结构。　　我们可以作个简单的比喻，结构化程序设计时代是以砖、瓦、灰、沙、石、预制梁、柱、屋面板盖平房和小楼，而面向对象时代以整面墙、整间房、一层楼梯的预制件盖高楼大厦。构件怎样搭配才合理？体系结构怎样构造容易？重要构件有了更改后，如何保证整栋高楼不倒？每种应用领域需要什么构件（医院、工厂、旅馆）？有哪些实用、美观、强度、造价合理的构件骨架使建造出来的建筑（即体系结构）更能满足用户的需求？如同土木工程进入到现代建筑学一样，软件也从传统的软件工程进入到现代面向对象的软件工程，研究整个软件系统的体系结构，寻求建构最快、成本最低、质量最好的构造过程。　　软件体系结构虽脱胎于软件工程，但其形成同时借鉴了计算机体系结构和网络体系结构中很多宝贵的思想和方法，最近几年软件体系结构研究已完全独立于软件工程的研究，成为计算机科学的一个最新的研究方向和独立学科分支。软件体系结构研究的主要内容涉及软件体系结构描述、软件体系结构风格、软件体系结构评价和软件体系结构的形式化方法等。解决好软件的重用、质量和维护问题，是研究软件体系结构的根本目的。2 软件体系结构的定义　　虽然软件体系结构已经在软件工程领域中有着广泛的应用，但迄今为止还没有一个被大家所公认的定义。许多专家学者从不同角度和不同侧面对软件体系结构进行了刻画，较为典型的定义有：　　（1）Dewayne Perry和A1ex Wo1f曾这样定义：软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组组合连接起来。这一定义注重区分处理构件、数据构件和连接构件，这一方法在其他的定义和方法中基本上得到保持。 　　（2）Mary Shaw和David Garlan认为软件体系结构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计。体系结构问题包括总体组织和全局控制、通讯协议、同步、数据存取，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案间进行选择等。软件体系结构处理算法与数据结构之上关于整体系统结构设计和描述方面的一些问题，如全局组织和全局控制结构、关于通讯、同步与数据存取的协议，设计构件功能定义，物理分布与合成，设计方案的选择、评估与实现等　　（3）Kruchten指出，软件体系结构有四个角度，它们从不同方面对系统进行描述：概念角度描述系统的主要构件及它们之间的关系；模块角度包含功能分解与层次结构；运行角度描述了一个系统的动态结构；代码角度描述了各种代码和库函数在开发环境中的组织。　　（4）Hayes Roth则认为软件体系结构是一个抽象的系统规范，主要包括用其行为来描述的功能构件和构件之间的相互连接、接口和关系。　　（5）David Garlan和Dewne Perry于1995年在IEEE软件工程学报上又采用如下的定义：软件体系结构是一个程序／系统各构件的结构、它们之间的相互关系以及进行设计的原则和随时间进化的指导方针。　　（6）Barry Boehm和他的学生提出，一个软件体系结构包括一个软件和系统构件，互联及约束的集合；一个系统需求说明的集合；一个基本原理用以说明这一构件，互联和约束能够满足系统需求。　　（7）1997年，Bass，Ctements和Kazman在《使用软件体系结构》一书中给出如下的定义：一个程序或计算机系统的软件体系结构包括一个或一组软件构件、软件构件的外部的可见特性及其相互关系。其中，"软件外部的可见特性"是指软件构件提供的服务、性能、特性、错误处理、共享资源使用等。　　总之，软件体系结构的研究正在发展，软件体系结构的定义也必然随之完善。在以后的文章里，如果不特别指出，我们将使用软件体系结构的下列定义：　　软件体系结构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。软件体系结构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理。
&&&主编推荐
H3C认证Java认证Oracle认证
基础英语软考英语项目管理英语职场英语
.NETPowerBuilderWeb开发游戏开发Perl
二级模拟试题一级模拟试题一级考试经验四级考试资料
软件测试软件外包系统分析与建模敏捷开发
法律法规历年试题软考英语网络管理员系统架构设计师信息系统监理师
高级通信工程师考试大纲设备环境综合能力
路由技术网络存储无线网络网络设备
CPMP考试prince2认证项目范围管理项目配置管理项目管理案例项目经理项目干系人管理
职称考试题目
招生信息考研政治
网络安全安全设置工具使用手机安全
生物识别传感器物联网传输层物联网前沿技术物联网案例分析
Java核心技术J2ME教程
Linux系统管理Linux编程Linux安全AIX教程
Windows系统管理Windows教程Windows网络管理Windows故障
数据库开发Sybase数据库Informix数据库
&&&&&&&&&&&&&&&
希赛网 版权所有 & &&