软件体系结构基础

1软件体系结构基础《软件设计与体系结构》主要内容1.1为什么需要“软件体系结构”？——从“软件危机”谈起1.2什么是软件体系结构——起源于建筑学的“体系结构”1.3软件体系结构的目标与作用1.4软件体系结构的发展与演化1.5软件体系结构研究的内容1.6软件体系结构的设计原则1.1为什么需要“软件体系结构”为什么需要“软件体系结构”最早指出SA的重要性的是大师EdsgerDijkstra(1930-2002)

“..thelargertheproject,themoreessentialthestructuring!”(1968)

为什么需要“软件体系结构”软件体系结构的产生软件体系结构日益作为软件工程师所遵循的重要原则浮现（emerging）与传统的学科不同，作为软件系统的新概念，它并非成型的、有精确定义的而是在软件工程师们面对日益复杂的系统的设计与构造问题寻求理解软件系统的更好的方法寻求构造更大更复杂的软件系统的更有效的方法的过程中，作为设计抽象的自然演化而出现的。程序=？程序=算法+数据结构（1960’s）程序=子程序+子程序（1970’s）对象=算法+数据结构

程序=对象+对象（1980’s）程序=组件+连接件（1990’s）系统=服务+服务总线(2000’s)软件规模大到什么程度某大型ERP软件软件功能模块>1000个数据表>1000张软件用户>1000人并发用户>50人Windows操作系统代码量Windows95:1500万行Windows98:1800万行WindowsXP:3500万行WindowsVista:5000万行天猫2014.11.11的交易情况软件规模大到什么程度QQ在线人数软件规模大到什么程度为什么需要软件体系结构

随着社会的巨大进步,计算机系统的整体发展,新技术的不断涌现,使计算机应用的需求迅速增加。而软件费用的增加,高可靠性能下降,维护工作量增大,出现了严重的“软件危机”。软件危机已经持续了三十多年，表现为：软件的产品质量难以保障软件的开发效率难以提高软件危机随着计算机应用的逐渐扩大，软件需求量逐渐增加，规模也日益增长，软件规模的快速增长，也带来了软件的复杂程度的增加和程序代码的剧增。即使是富有经验的程序员，也难免会对较大软件的程序代码顾此失彼。其结果是软件开发的费用经常超支，而且常常延长软件的开发时间。软件生产的重点在于开发和维护，对于这些在软件开发和维护过程中遇到的一系列严重问题，计算机科学家称之为“软件危机”。软件危机”于1968年在原西德Garmish召开的国际软件工程会议上首次提出软件危机是指计算机软件开发和维护过程中所遇到的一系列严重问题。(1)能否满足对软件日益增长的需求？(2)能否维护数量日益增长的现有软件？开发时间呈指数上升、进度难以控制；智力开发，无法“三班倒”；用户需求变化；增加人员也未必能加快速度；软件质量不可靠；软件系统复杂度增加；缺乏工程化思想指导；软件体系结构发展相对滞后；软件危机表现用户不满意；开发初期用户需求表达不清；与用户沟通有问题；软件维护困难；早期设计存在问题；缺乏系统的文档资料；维护费用已高达40~75%。软件危机表现年代19551970197519801985软件成本比重18%60%72%80%85%软件危机表现软件成本日益增长；硬件越来越便宜，软件越来越复杂；1950’s10~20%1960’s50%;美国空军计算系统：软件危机表现软件质量问题对经济的影响：美国NIST（国家商业标准和技术）报告，“由于软件bug的普遍存在，使美国经济每年损失$590.5亿美元”，而Standish组织的数据是每年2000亿美元改进软件质量已经成为取得高投资回报率的直接途径，质量低的公司只会被遗忘软件质量问题对生命安全的威胁：1963年,美国金星探测火箭飞行失败,造成经济损失达一千万美元，因为控制程序中的一个极小的错误,即将一逗号误写为一小数点！由于着陆系统的高度报警程序问题部分导致了1997年发生在关岛的韩国客机空难，228人遇难。1996年,欧洲耗资高达7亿美元的Ariane5火箭发射后解体爆炸,究其原因是惯性参考系统中的一个软件设计错误,并由于认为这个软件不会发生错误而缺乏充分的测试。......软件规模越来越大；随着软件应用范围的增广，软件规模愈来愈大。大型软件项目需要组织一定的人力共同完成，而多数管理人员缺乏开发大型软件系统的经验，而多数软件开发人员又缺乏管理方面的经验。各类人员的信息交流不及时、不准确、有时还会产生误解。软件项目开发人员不能有效地、独立自主地处理大型软件的全部关系和各个分支，因此容易产生疏漏和错误。软件危机的原因软件复杂程度越来越高；软件不仅仅是在规模上快速地发展扩大，而且其复杂性也急剧地增加。软件产品的特殊性和人类智力的局限性，导致人们无力处理“复杂问题”。所谓“复杂问题”的概念是相对的，一旦人们采用先进的组织形式、开发方法和工具提高了软件开发效率和能力，新的、更大的、更复杂的问题又摆在人们的面前。软件危机的原因用户需求不明确；在软件开发完成之前，用户不清楚软件的具体需求；用户对软件需求的描述不精确，可能有遗漏、有二义性、甚至有错误；在软件开发过程中，用户还提出修改软件功能、界面、支撑环境等方面的要求；开发人员对用户需求的理解与用户本来愿望有差异。软件危机的原因用户需求不明确；软件危机的原因缺乏正确的理论指导；缺乏有力的方法学和工具方面的支持。由于软件不同于大多数其他工业产品，其开发过程是复杂的逻辑思维过程，其产品极大程度地依赖于开发人员高度的智力投入。由于过分地依靠程序设计人员在软件开发过程中的技巧和创造性，加剧软件产品的个性化，也是发生软件危机的一个重要原因。软件危机的原因人们面临的不光是技术问题，更重要的是管理问题。管理不善必然导致失败。要提高软件开发效率，提高软件产品质量，必须采用工程化的开发方法与工业化的生产技术。在技术上，应该采用基于重用的软件生产技术；在管理上，应该采用多维的工程管理模式。如何克服软件危机如何克服软件危机解决问题的想法更好的管理（Bettermanagement）出众的团队组织（Differentteamorganizations）更好的语言和工具（Betterlanguages&tools）统一的编程规范（Uniformcodingconventions）工程化方法（Engineeringmethod）

必须意识到：“软件”≠编程，它有自己的生命周期(lifecycle)。大型软件系统的开发与其它工程项目如建造桥梁、制造飞机、轮船等的开发是同理的。因为…随着软件系统规模越来越大、越来越复杂用户需求(功能性)越来越复杂，变化越来越频繁；用户对软件质量(非功能性)的要求也越来越高；如何将成百上千个功能组合起来，同时满足用户质量需求，变得越来越困难。因为…随着软件系统规模越来越大、越来越复杂用户需求(功能性)越来越复杂，变化越来越频繁；用户对软件质量(非功能性)的要求也越来越高；如何将成百上千个功能组合起来，同时满足用户质量需求，变得越来越困难。此时，整个系统的全局结构和设计显得越来越重要。很多质量需求主要体现在体系结构中而非功能模块内部的实现中。结论：对于大规模的复杂软件系统来说，对系统全局结构的设计比起对算法的选择和数据结构的设计明显重要得多。

研究背景我们需要的是软件符合质量要求！！软件需求是进行“质量”度量的基础，与需求不符就是质量不高。通常有一组“隐含需求（implicitrequirements）”是不被提及的（如对维护性的需求）。如果软件符合了明确的需求却没有满足隐含需求，软件质量仍然值得怀疑。性能Performance可用性Usability可靠性Availability可扩展性Extensibility安全性Security功能性Functionality研究背景如果有什么东西可以在软件开发之前用于描述软件，并能进行质量分析，从而保证软件质量就好了~软件体系结构解决软件危机告诉人们如何设计软件、开发软件、管理软件软件工程方法/软件体系结构/软件设计模式的合理应用提高软件产品的质量!降低软件开发的成本!

我们的目标1.2

什么是“软件体系结构”软件体系结构的本意对于大规模的，分布的，需要协作的，需要交互的，需要监测的，需要扩展的，需要演化的复杂软件系统的规划。软件体系结构从字面上理解，软件体系结构=软件的体系结构SoftwareArchitecture(SA)=Software’sArchitecture(S’A)什么是“体系结构”(Architecture)词典的定义：Theartandscienceofdesigninganderectingbuildings(建筑学：设计和建造建筑物的艺术与科学)；Astyleandmethodofdesignandconstruction(设计及构造的方式和方法)；Orderlyarrangementofparts;structure(部件的有序安排；结构)；Theoveralldesignorstructureofacomputersystem,includingthehardwareandthesoftwarerequiredtorunit,especiallytheinternalstructureofthemicroprocessor(计算机系统的总体设计或结构，包括其硬件和支持硬件运行的软件，尤其是微处理器内部的结构)。起源于建筑学的“体系结构”“体系结构(Architecture)”一词起源于建筑学如何使用基本的建筑模块构造一座完整的建筑？包含两个因素：基本的建筑模块：砖、瓦、灰、沙、石、预制梁、柱、屋面板…建筑模块之间的粘接关系：如何把这些“砖、瓦、灰、沙、石、预制梁、柱、屋面板”有机的组合起来形成整体建筑？建筑设计原则坚固实用美观建筑设计不仅是一门科学，而且是一项艺术!起源于建筑学的“体系结构”如何克服软件危机解决问题的想法更好的管理（Bettermanagement）出众的团队组织（Differentteamorganizations）更好的语言和工具（Betterlanguages&tools）统一的编程规范（Uniformcodingconventions）工程化方法（Engineeringmethod）

必须意识到：“软件”≠编程，它有自己的生命周期(lifecycle)。大型软件系统的开发与其它工程项目如建造桥梁、制造飞机、轮船等的开发是同理的。软件体系结构起源结构设计师：设计图纸管理人员：施工计划施工人员：建造建筑物软件体系结构思想来源于建筑业计算机硬件系统的“体系结构”如何将设备组装起来形成完整的计算机硬件系统？包含两个因素：基本的硬件模块：控制器、运算器、内存储器、外存储器、输入设备、输出设备、…硬件模块之间的连接关系：总线计算机体系结构的风格：以存储程序原理为基础的冯·诺依曼结构存储系统的层次结构并行处理机结构流水线结构多核CPU……业界中的软件架构，定义归结而言可分为：组成派和决策派两大流派软件架构概念的分类软件架构是一组关于下述问题的重要决定，软件系统的组织构成系统的结构化元素和它们接口的选择这些模型元素之间的协作所描述的行为这些结构化和行为元素的组装，以形成更大的子系统指导这种组织（静态和动态元素，以及它们的接口、协作和组装）的架构风格软件架构不仅关注结构和行为，也关注使用、功能、性能、弹性、复用、可理解性、经济和技术约束与折衷、审美考虑——Booch、Rumbaugh和Jacobson，1999一个软件系统的架构定义了组成系统的计算构件和构件之间相互作用的关系软件架构层次的设计主要包括以下方面：

组成系统的构件描述构件之间的交互指导构件交互的模式，以及施加在模式上的约束——Garlan和Shawn，1996

软件架构概念的分类决策派软件架构是在一些重要方面所作出的决策的集合关注架构实践中的主体——人，以人的决策为描述对象归纳了架构决策的类型，指出架构决策不仅包括关于软件系统的组织、元素、子系统和架构风格等几类决策，还包括关于众多非功能需求的决策组成派MaryShaw：软件系统的架构将系统描述为计算组件及组件之间的交互“组成派”软件架构概念有如下两个显著特点：关注架构实践中的客体——软件，以软件本身为描述对象分析了软件的组成，即软件由承担不同计算任务的组件组成，这些组件通过相互交互完成更高层次的计算组成派Garlan和Shaw的定义架构包括组件、连接件和约束三大要素。组件可以是一组代码(例如程序模块)，也可以是独立的程序(例如数据库服务器)。连接件可以是过程调用、管道和消息等，用于表示组件之间的相互关系。“约束”一般为组件连接时的条件Perry和Wolf的定义软件架构是一组具有特定形式的架构元素，这些元素分为三类：负责完成数据加工的处理元素、作为被加工信息的数据元素及用于把架构的不同部分组合在一起的连接元素组成派(续)Boehm的定义软件架构包括系统组件、连接件和约束的集合，反应不同涉众需求的集合，以及原理的集合。其中的原理，用于说明由组件、连接件和约束所定义的系统在实现时，是如何满足不同涉众需求的IEEE的定义架构是以组件、组件之间的关系、组件与环境之间的关系为内容的某一系统的基本组织结构，以及指导上述内容设计与演化的原理Bass(SEI)的定义某个软件或计算机系统的软件架构是该系统的一个或多个结构，每个结构均由软件元素、这些元素的外部可见属性、这些元素之间的关系组成观点总结组成派的观点更关注软件，倾向于“组件+交互”的思想决策派的观点更关注人，倾向于重大决策集合的思想，除了结构和行为，还关注一些非功能的因素组成派和决策派软件架构概念并不矛盾，它们只不过是所站的角度不同罢了在具体的软件架构实践中，总是同时体现着这两“派”的架构概念总结与强调将软件架构的概念总体上分为组成派和决策派，有利于我们理解软件架构概念的精髓两个架构概念流派虽然角度不同，但却相辅相成。我们既应从“架构=组件+交互”的观点中获益，又应运用“架构=重要决策集”的实践经验，这一点对于软件业界的实践者（而不仅仅是理论研究者）尤其重要SA的定义(1)1994年(D.GarlanandM.Shaw)Structuralissuesincludetheorganizationofasystemasacompositionofcomponents;globalcontrolstructures;theprotocolsforcommunication,synchronization,anddataaccess;theassignmentoffunctionalitytodesignelements;thecompositionofdesignelements;physicaldistribution;scalingandperformance;dimensionsofevolution;andselectionamongdesignalternatives.SA={components,connectors,constrains}构件(component)可以是一段代码，如程序的模块，也可以是一个独立的程序，如数据库的SQL服务器。连接器(connector)表示构件之间的相互作用。一个软件体系结构还包括某些限制(constrain)。SA的定义(2)2000年(IEEE1471–2000)Architecture={component,connector,environment,principle}.thefundamentalorganizationofasystemembodiedinitscomponents,theirrelationshipstoeachother,andtotheenvironment,andtheprinciplesguidingitsdesignandevolution体系结构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织结构，以及指导上述内容设计与演化的原理。SA的定义(3)1992年(D.PerryandA.Wolf)SA={elements,form,rational}软件体系结构是由一组具有一定形式的元素(elements)构成：这组元素分成3类：处理元素(processingelements)、数据元素(dataelements)和连接元素(connectingelements)；处理元素负责对数据进行加工，数据元素是被加工的信息，连接元素把体系结构的不同部分组合连接起来。软件体系结构形式(form)是由专有特性(properties)和关系(relationship)组成。专有特性用于限制软件体系结构元素的选择，关系用于限制软件体系结构元素组合的拓扑结构。在多个体系结构方案中选择合适的体系结构方案往往基于一组准则(rational)。SA的定义“Thereisnostandard,universally-accepteddefinitionoftheterm,forsoftwarearchitectureisafieldinitsinfancy,althoughitsrootsrundeepinsoftwareengineering.”很多人都试图给”软件架构”下定义，而这些定义本身却很难统一。

MartinFowler，《企业应用架构模式》“体系结构”的共性共性：一组基本的构成要素——构件这些要素之间的连接关系——连接件这些要素连接之后形成的拓扑结构——物理分布作用于这些要素或连接关系上的限制条件——约束质量——性能类推：软件体系结构软件体系结构(SoftwareArchitecture,SA)：构件：各种基本的软件构造模块(函数、对象、模式等)；连接件：将它们组合起来形成完整的软件系统；物理分布约束质量归纳：SA的定义软件体系结构(SA)：提供了一个结构、行为和属性的高级抽象从一个较高的层次来考虑组成系统的构件、构件之间的连接，以及由构件与构件交互形成的拓扑结构这些要素应该满足一定的限制，遵循一定的设计规则，能够在一定的环境下进行演化。反映系统开发中具有重要影响的设计决策，便于各种人员的交流，反映多种关注，据此开发的系统能完成系统既定的功能和性能需求。体系结构=构件+连接件+拓扑结构+约束+质量Architecture=Components+Connectors+Topology+Constraints+Performance你已经知道的SA分层（网络协议,OS）客户/服务器模式浏览器/服务器模式P2P......“软件体系结构”你早就知道...软件体系结构描述SA描述的现状：非正式、抽象通常用在长期的实践中非正式的浮现【即：没有通过理论抽象与统一的形式化描述】的特殊模型来描述通常用线/框图与一些文字描述线框体现出形象的结构，文字则描述符号的含义并提供在部件与其间的交互中所做的特定选择的理由软件体系结构描述不规范的体系结构描述Wehavechosenadistributed,object-orientedapproachtomanaginginformationTheeasiestwaytomakethecanonicalsequentialcomplierintoconcurrentcomplieristopipelinetheexecutionofthecompilerphasesovernumberofprocessors...基于自然语言的描述，有效但是不正式不严格。软件体系结构描述问题为什么为产生这样非正式、抽象的描述？这样的体系结构的描述对软件工程是否有用？软件体系结构描述【关于非正式】：对软件系统的组织而言，经过长期的积累，已有一系列习惯用语、模式、风格，构成共享的、语义丰富的（体系结构用）词汇例如，说一个系统是pipe-filter结构的风格，即该系统主要涉及流，且系统的功能可由构成系统的过滤器构成，系统延迟与吞吐量可相对直接的得到。即：该非正式的描述对软件工程师具有相当的系统结构信息。软件体系结构描述【关于抽象】：虽然体系结构相对于具体的实现与组件构造的细节要抽象，但提供了更广的、结构层上理解系统层上的问题的自然的骨架这个骨架在系统没有形成的时候就已经在起作用例如：系统可能的演化轨迹、可扩展性、通讯的模式、数据组织模式等通过对主要系统需求（此时主要是非功能需求，以及功能需求的共性构件）对应描述，展现系统满足全部需求的能力软件体系结构描述总体现状没有完整的软件体系结构理论现有软件体系结构的基本内容一些体系结构描述的基本成分（需要描述什么内容）一些体系结构模式、风格、习惯语等1.3软件体系结构的目标与作用软件体系结构的目标软件体系结构关注的是：如何将复杂的软件系统划分为模块如何规范模块的构成,如何将这些模块组织为完整的系统,以及保证系统的质量要求。主要目标：建立一个一致的系统及其视图集，并表达为最终用户和软件设计者需要的结构形式，支持用户和设计者之间的交流与理解。分为两方面：外向目标：建立满足最终用户要求的系统需求；内向目标：建立满足系统设计者需要以及易于系统实现、维护和扩展的系统构件构成。SA的作用交流的手段：

Itisavehicleforcommunicationamongstakeholders.在软件设计者、最终用户之间方便的交流；可传递的、可复用的模型：Itisareusable,transferableabstractionofasystem.可重复利用的、可转移的系统抽象).canbeappliedtoothersystemsexhibitingsimilarrequirements(用到其它的项目)canpromotelarge-scalereuseandsoftwareproductlines(提高大规模重复利用率)关键决策的体现

Itistherepresentationoftheearliestdesigndecisionsthathasthemostsignificantinfluenceonsystemqualities.Itshowsthetradeoffs(折衷)betweenperformanceandsecurity,betweenmaintainabilityandreliability,andbetweenthecostofthecurrentdevelopmenteffortandthecostoffuturedevelopmentsinthearchitecture.SA的重要意义SA是软件开发过程初期的产品，在开发的早期阶段就考虑系统的正确设计与方案选择，为以后开发、测试、维护各个阶段提供了保证；与其他后期的设计活动相比，SA设计的成本和代价要低得多；正确有效的SA设计会给软件开发带来极大的便利；在大型软件系统中，质量属性更多的是由系统结构和功能划分来实现的，而不再仅仅依靠所选择的算法或数据结构。SA在软件生命周期中的作用项目规划需求分析软件设计软件实现测试与评审维护与升级考虑项目的规模、复杂度、可行性等；利用SA，支持用户、项目负责人、系统架构师、程序员、测试人员之间进行交流和协商；从不同视角审查备选的SA，对得出的意见进行综合，找出合理的平衡方案；从用户角度考虑未来的需求会发生什么变化，并使SA能够提前支持这些变化；参考经典SA风格，设计系统体系结构模型，推敲其存在的缺陷和替代方案，并进行评估；进而逐步细化SA，并对定型后的SA作文档化工作；各开发团队按照SA规定的“构件及其之间的相互关系”进行开发，保证最终得到的系统与最初的SA一致；根据SA的约束条件，对软件的质量属性进行测试。把SA文档作为维护和升级的重要依据。与其他软件设计活动的比较起点模糊在用户需求尚没有明确定义、用户对其所期望的系统功能、行为和性能尚未确定的情况下就要进行SA设计；——故而需要交流与反复；高抽象层次SA分析处理的是高层次的系统构件或子系统之间的关系，而非变量、函数等低层次的概念；分布决策来自用户、架构师、测试人员等多方面；贯穿全局SA设计活动在项目开始时进行，但其作用则贯穿整个项目周期，越往后越显出重要性。1.4软件体系结构的发展与演化软件体系结构的演化史功能函数对象构件框架设计模式服务面向过程的分析与设计面向对象的分析与设计基于构件的软件开发面向服务的计算面向服务的体系结构SOA软件即服务SaaS细粒度粗粒度IT技术商务过程封闭开发个人企业内企业间全球体系结构风格面向模式的体系结构软件体系结构的发展与演化系统=算法+数据结构(1960’s)系统=子程序+子程序(1970’s)系统=对象+对象(1980’s)系统=构件+连接件(1990’s)系统=服务+服务总线(2000’s)简单复杂系统规模与复杂度封闭开放系统开放度细粗模块粒度模块连接件关注层面软件体系结构的演化“无体系结构”设计阶段萌芽阶段以汇编语言进行小规模应用程序开发为特征以描述系统的高层抽象结构为中心，不关心具体的建模细节，划分了体系结构模型与传统软件结构的界限，该阶段以Kruchten提出的“4+1”模型为标志出现了从不同侧面描述系统的结构模型，以UML为典型代表。出现了程序结构设计主题，以控制流图和数据流图构成软件结构为特征高级阶段初期阶段1.5体系结构研究

的内容从建筑体系结构看起基本的建筑单元都有哪些？有哪些实用、美观、强度、造价合理、可复用的大粒度建筑单元，使建造出来的建筑更能满足用户的需求？建筑模块怎样搭配才合理？有哪些典型的建筑风格？每种典型建筑(医院、工厂、旅馆)的典型结构是什么样子？需要什么样的构件？如何绘制建筑体系结构的图纸？如何根据图纸进行质量评估？如何快速节省的将图纸变为实物(即施工过程)？建筑完成之后，如何对其进行恰当程度的修改？重要模块有了更改后，如何保证整栋建筑质量不受影响？软件体系结构要解决的问题软件的基本构造单元是什么？这些构造单元之间如何连接？最终形成何种样式的拓扑结构？每个典型应用领域(例如CAD、ERP)的典型体系结构是什么样子？如何进行软件体系结构的设计与实现？如果对已经存在的软件体系结构进行修改？使用何种工具来支持软件体系结构的设计？如何对软件的体系结构进行描述，并据此进行分析和验证？软件体系结构研究的内容当前，软件体系结构已经成为软件工程研究者和实践者的一个重要研究领域，主要包括以下几个方面：软件体系结构的建模与表示软件体系结构风格的研究体系结构描述语言(ArchtecturalDescriptionLanguage,ADL)软件体系结构的评价方法软件产品线及特定领域软件框架的研究......1.6软件体系结构的设计原则分解人们面对复杂性有一个常见的做法：即分而治之，将大问题分解为多个小问题，将复杂问题分解为多个简单问题。抽象更高层次来讲，人们处理复杂性有一个通用的技术，即抽象。由于不能掌握全部的复杂对象，我们选择忽视它的非本质细节，而去处理泛化和理想化了的对象模型。示例：如何解决复杂性？在多年的软件开发实践中，对软件体系结构的设计总结出一些带有普遍性的原则，这些原则和策略独立于具体的软件开发方法，一直被广泛地运用着。抽象封装（信息隐藏）模块化

（分而治之）关注点分离耦合和内聚充分性、完备性和简单性策略和实现的分离接口和实现的分离层次性软件体系结构的设计原则抽象是人们用来处理复杂问题的基本原理之一。抽象有多种形式，如数据抽象、对象抽象、实体抽象、行为抽象、过程抽象等。数据、实体的抽象使得软件操作的对象和参数针对逻辑结构，而非存储结构。行为、过程的抽象使得操作的指派是依据标识而非地址，由此产生了操作的接口和动态约束描述。在处理系统复杂性方面，抽象起到了重要的作用，减少构件耦合、接口与实现的分离等都得益于抽象。抽象在面向对象程序设计当中,封装是一种重要的机制。所谓对象的概念就是属性（数据）及其操作(行为）的封装体。封装的机制并不局限于面向对象领域，在结构化程序设计中封装在函数和子程序当中也得到了体现。封装有利于提高抽象的层次，有利于结枸和实现的分离，最终提高了软件的可维护性、可复用性和可靠性。封装信息隐藏是软件工程的最基本和最重要的原理之一。信息隐藏对用户隐藏了构件的实现细节，用来更好地处理系统的复杂性和减少各构件之间的耦合。为了更好地应用，用户不需要知道的细节都应该由构件封装起来。封装原理经常被用来作为实现,信息隐藏的方法，信息隐藏也可以通过接口与实现分离的原理来实现。信息隐藏模块化关心的是如何将一个软件系统分