34软件体系结构课后习题第三章作业 软件体系结构
34软件体系结构课后习题第三章作业 软件体系结构
题1.层次系统结构和基于消息的层次系统结构有什么区别?答：层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见。这样的系统中构件在一些层实现了虚拟机（在另一些层次系统中层是部分不透明的）。连接件通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约束。这种风格支持基于可增加抽象层的设计。允许将一个复杂问题分解成一个增量步骤序列的实现。由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件重用提供了强大的支持。而在基于消息的层次系统结构中构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其它构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。这种风格的构件是一些模块，模块既可以是一些过程，又可以是一些事件的集合。过程可以用通用的方式调用，也可以在系统事件中注册一些过程，当发生这些事件时，过程被调用。这种风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这样不能假定构件的处理顺序，甚至不知道哪些过程会被调用，因此，许多隐式调用的系统也包含显式调用作为构件交互的补充形式。题2.分析比较B/S、二层C/S和三层C/S，指出各自的优点和缺点。二层C/S结构的优点：◆C/S 体系结构具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。 ◆系统的客户应用程序和服务器构件分别运行在不同的计算机上，系统中每台服务器都可以适合各构件的要求，这对于硬件和软件的变化显示出极大的适应性和灵活性，而且易于对系统进行扩充和缩小。◆在C/S体系结构中，系统中的功能构件充分隔离，客户应用程序的开发集中于数据的显示和分析，而数据库服务器的开发则集中于数据的管理，不必在每一个新的应用程序中都要对一个DBMS进行编码。将大的应用处理任务分布到许多通过网络连接的低成本计算机上，以节约大量费用二层C/S结构的缺点：◆ 开发成本较高◆客户端程序设计复杂◆信息内容和形式单一◆ 用户界面风格不一，使用繁杂，不利于推广使用◆软件移植困难◆ 软件维护和升级困难◆ 新技术不能轻易应用三层C/S结构的优点：◆允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，能提高系统和软件的可维护性和可扩展性。◆允许更灵活有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层；并且这些平台和各个组成部分可以具有良好的可升级性和开放性。◆应用的各层可以并行开发，可以选择各自最适合的开发语言。◆利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，为严格的安全管理奠定了坚实的基础。三层C/S结构的缺点：◆三层C/S结构各层间的通信效率若不高，即使分配给各层的硬件能力很强，其作为整体来说也达不到所要求的性能。◆ 设计时必须慎重考虑三层间的通信方法、通信频度及数据量。这和提高各层的独立性一样是三层C/S结构的关键问题。B/S体系结构的优点：◆基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决。用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。◆B/S体系结构还提供了异种机、异种网、异种应用服务的联机、联网、统一服务的最现实的开放性基础。B/S体系结构的缺点：◆ B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。 ◆B/S体系结构的系统扩展能力差，安全性难以控制。◆ 采用B/S体系结构的应用系统，在数据查询等响应速度上，要远远地低于C/S体系结构。 ◆ B/S体系结构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理(OLTP)应用。题3.组织或参与一个采用B/S和C/S混合体系结构的软件项目的开发，总结开发经验。首先，开发者根据一定的原则，将系统的所有子功能分类，决定哪些子功能适合采用C/S，哪些适合采用B/S。适合采用C/S的子功能应具备以下特点：1安全性要求高；2要求具有较强的交互性；3使用范围小，地点固定；4要求处理大量数据。例如，仓库管理系统中的入库单、领料单的输入功能，财务系统中的凭证输入功能等等。而适合采用B/S的子功能应具备以下特点：1使用范围广，地点灵活；2功能变动频繁；3安全性、交互性要求不同。例如：企业内部信息发布功能，意见箱输入功能，公司财务分析表的查询功能，总裁决策支持系统中的查询功能等等。相对于单独采用C/S或B/S，这种方案的优点在于：1保证敏感数据的安全性，特别是对数据库的修改和新增记录加强了控制；2经济有效地利用企业内部计算机的资源，简化了一部分可以简化的客户端；3既保证了复杂功能的交互性，又保证了一般功能的易用与统一；4系统维护简便，布局合理；5网络效率最高。如果系统开发者在系统设计阶段决定采用这种C/S与B/S相结合的模式，那么在系统开发生命周期的如下各个阶段相对这种新模式都应有所响应。在系统设计阶段主要考虑的是MIS系统平台选择问题。在详细设计阶段，系统开发者需要根据企业自身的业务特点，以及一定的选择原则，来决定各个子功能采用哪一种模式并在系统说明书上分别注明。在编码设计阶段，系统开发者需要针对采用不同模式的子功能，选用不同的编码方式(例如：C/S可以采用VB编程环境，而B/S采用ASP方法)，然后编译生成不同的客户应用及Web服务程序。在安装调试阶段，其特点主要体现在系统的物理结构上，即特定的客户应用程序将被安装在特定的使用者的客户端上，Web服务程序需要被安装在Web服务器上，而每个客户端上都将被安装上浏览器，同时，客户应用的使用者必须接受一定的培训。在软件维护阶段，针对不同模式的子功能应采取不同维护方式。题4.在软件开发中，采用异构结构有什么好处，其负面影响有哪些？答：所有的体系结构不仅有很紧密的联系，而且在大多数情况下是被一起使用的。对于一个实际的系统，甚至不能判断它是A风格、B风格还是C风格，因为没有足够的理由把它归为任何一种独立的体系结构风格。这种系统类型被称为异构结构。上图展示了一个虚拟系统，它整合了许多体系结构风格。可以把整个系统当成一个分层系统。这样它可以被分成两层：第1层是原始数据生成层，第2层是解释层。在第1层，主要的组成部分是管道－过滤器子系统。(1)第1个过滤器中的数据能够被送到第2个过滤器中。(2)当第2个过滤器收到数据时，将会产生相应的信息，然后将此信息传送到事件队列构件和服务提供对象构件中。(3)当事件队列不为空时，它将会激发相应的对象来处理这个事件，并完成任务。这是一个典型的事件驱动体系结构风格的例子。(4)当服务提供对象构件接收到由第2个过滤器传来的信息时，它将把这些信息记录在信息库里。它就像是在数据共享风格中的黑板。在这个信息库中，所有的信息、知识和规则被记录下来。当“事件驱动”部分想要完成某些任务时，它可能需要从这个信息库里获取一些有用的信息，然后根据其中的规则完成正确的行动。这部分可以被看成数据共享与反馈控制环风格的结合。因为所有的数据在构成的信息库里被共享，其他部分能够从信息库中存储和获取数据。用户可以通过向信息库中记录新的数据来更新它。这也具有反馈控制环风格的特点。在第2层解释器中，来自第1层中的数据被解释。当解释数据时，构件必须知道上下文、解释规则和解释器的状态。因此这部分具有状态构件、规则构件和数据构件。当解释时产生的所有错误和程序缺陷被记录在数据库里。最后，输出解释完毕的数据。 从这个例子中，可以看出一个完善的系统可能由各种各样的体系结构风格组成，具体的组成方法要依据系统需求和各种体系结构风格的优势来确定。所设计的最好的系统不是特意包含“所谓的”结构体系风格，而是能够恰当运用体系结构风格的系统。设计出的系统要满足需要的质量属性。负面影响就是结构可能更加复杂，不易于设计与维护。5． 通过查资料然后分析，给出下列体系结构Windows7，Android，P2P，web service，要求：1.模块划分和功能描述。2.模块间的关系。3.典型功能模块的调用关系。4.各自优缺点。答：Android操作系统的架构图如下：Android系统架构由5部分组成，分别是：Linux Kernel、Android Runtime、Libraries、Application Framework、Applications。第二部分将详细介绍这5个部分。架构详解现在我们拿起手术刀来剖析各个部分。其实这部分SDK文档已经帮我们做得很好了，我们要做的就是拿来主义，然后再加上自己理解。下面自底向上分析各层。1、Linux KernelAndroid基于Linux 2.6提供核心系统服务，例如：安全、内存管理、进程管理、网络堆栈、驱动模型。Linux Kernel也作为硬件和软件之间的抽象层，它隐藏具体硬件细节而为上层提供统一的服务。2、Android RuntimeAndroid包含一个核心库的集合，提供大部分在Java编程语言核心类库中可用的功能。每一个Android应用程序是Dalvik虚拟机中的实例，运行在他们自己的进程中。Dalvik虚拟机设计成，在一个设备可以高效地运行多个虚拟机。Dalvik虚拟机可执行文件格式是.dex，dex格式是专为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。Dalvik虚拟机依赖于Linux 内核提供基本功能，如线程和底层内存管理。3、LibrariesAndroid包含一个C/C++库的集合，供Android系统的各个组件使用。这些功能通过Android的应用程序框架（application framework）暴露给开发者。下面列出一些核心库：34软件体系结构课后习题第三章作业_软件体系结构系统C库——标准C系统库（libc）的BSD衍生，调整为基于嵌入式Linux设备媒体库——基于PacketVideo的OpenCORE。这些库支持播放和录制许多流行的音频和视频格式，以及静态图像文件，包括MPEG4、 H.264、 MP3、 AAC、 AMR、JPG、 PNG界面管理——管理访问显示子系统和无缝组合多个应用程序的二维和三维图形层LibWebCore——新式的Web浏览器引擎,驱动Android 浏览器和内嵌的web视图SGL——基本的2D图形引擎3D库——基于OpenGL ES 1.0 APIs的实现。库使用硬件3D加速或包含高度优化的3D软件光栅FreeType ——位图和矢量字体渲染SQLite ——所有应用程序都可以使用的强大而轻量级的关系数据库引擎4、Application Framework通过提供开放的开发平台，Android使开发者能够编制极其丰富和新颖的应用程序。开发者可以自由地利用设备硬件优势、访问位置信息、运行后台服务、设置闹钟、向状态栏添加通知等等，很多很多。开发者可以完全使用核心应用程序所使用的框架APIs。应用程序的体系结构旨在简化组件的重用，任何应用程序都能发布他的功能且任何其他应用程序可以使用这些功能（需要服从框架执行的安全限制）。这一机制允许用户替换组件。所有的应用程序其实是一组服务和系统，包括：视图（View）——丰富的、可扩展的视图集合，可用于构建一个应用程序。包括包括列表、网格、文本框、按钮，甚至是内嵌的网页浏览器 内容提供者（Content Providers）——使应用程序能访问其他应用程序（如通讯录）的数据，或共享自己的数据资源管理器（Resource Manager）——提供访问非代码资源，如本地化字符串、图形和布局文件通知管理器（Notification Manager）——使所有的应用程序能够在状态栏显示自定义警告活动管理器（Activity Manager）——管理应用程序生命周期,提供通用的导航回退功能5、ApplicationsAndroid装配一个核心应用程序集合，包括电子邮件客户端、SMS程序、日历、地图、浏览器、联系人和其他设置。所有应用程序都是用Java编程语言写的。更加丰富的应用程序有待我们去开发！二、P2P系统的架构图如下：P2P网络大概可划分为纯分散式P2P网络和混合式P2P网络两大类。纯分散式P2P网络，其拓扑如图2所示。网络中没有服务器，链状的节点之间构成一个分散式网络。通过基于对等网协议的客户端软件搜索网络中存在的对等节点．节点之间不必通过服务器，可直接建立连接。这种P2P网络模型优点在于允许用户设定自己的规则和建立自己的网络环境；为与Internet合作，提供近似的即插即用特性；不仅能够在Internet下有效地工作，而且对于LAN也非常有用。但是，由于没有中心管理者，网络节点难以发现，不易管理且安全性较差。图2 纯分散式P2P网络拓扑（2）混合式P2P网络混合式P2P网络其拓扑如图3所示。各节点之间可以直接建立连接，但网络的构建需要服务器，通过集中认证，建立索引机制。然而这里的服务器仅用于辅助对等节点之间建立连接，一旦连接成功，服务器不再起作用，对等节点之间直接进行通信。这不同于C／S模式中的服务器，也可以认为是弱化了服务器的作用。这种P2P网络模型和纯分散式P2P网络相比，易于发现网络节点、易于管理且安全性较好，但也有类似C／S模式的缺陷，如容错性差等。目前P2P技术的应用大多为这种模式。P2P网络系统的优缺点：P2P网络系统的开发面临着许多问题亟待解决，比如：在P2P共享网络中普遍存在侵犯版权问题；在一个无中心的环境中如何选择可靠的资源，即如何建立节点之间的信誉问题；P2P带来的新型网络病毒传播模式防阻断问题；基于P2P的隐蔽通讯与隐私保护问题；P2P网络服务健壮性与抗毁能力等。三、Windows7的体系结构如下：1.硬件抽象层（HAL）HAL=Hardware Abstraction LayerHAL是一个核心态模块（HAL.DLL），它为运行Windows 2000/XP的硬件平台提供低级接口。2.设备驱动程序可加载的核心态模块I/O系统和相关硬件之间的接口WDM=Windows Driver Model3.内核NTOSKRNL.EXE的下层(Microsoft Boot Up Kernel)内核是对处理器体系结构的抽象，将执行体与处理器体系结构的差异相隔离，保证系统的可移植性。大多数代码用C编写，部分依赖于硬件体系结构的代码用汇编编写.内核实现了一组简单的对象，称为内核对象，以帮助内核控制中心处理并支持执行体对象的创建。控制对象——包括异步过程调用（APC，asynchronous procedure call）对象、延迟过程调用（DPC，deferred procedure call）对象和几个由I/O系统使用的对象，例如中断对象。调度程序对象——负责同步操作并影响线程调度。调度程序对象包括内核线程、互斥体（Mutex）、事件（Event）、内核事件对、信号量（Semaphore）、定时器和可等待定时器4.执行体提供的函数调用从用户态导出并且可以调用的函数。这些函数的接口在NTDLL.DLL中。通过Win32API或一些其他的环境子系统可以对它们进行访问。从用户态导出并且可以调用的函数，但当前通过任何文档化的子系统函数都不能使用。 在Windows 2000 DDK中已经导出并且文档化的核心态调用的函数。在核心态组件中调用但没有文档化的函数。例如在执行体内部使用的内部支持例程。 组件内部的函数。5.环境子系统将基本的执行体系统服务的某些子集以特定的形态展示给应用程序三种环境子系统：POSIX、OS/2和Win32（OS/2 只能用于x86系统）Windows体系结构的优缺点：优点◆结构紧密，接口简单直接，系统效率高缺点◆模块间转接随便◆数据基本上作为全程量处理常常关中断，系统的并发性难以提高四、Web servers的体系结构如下：其中，绿色部分是先前已经定义好的并且广泛使用的传输层和网络层的标准：IP、HTTP、SMTP等。而蓝色部分是目前开发的Web服务的相关标准协议，包括服务调用协议SOAP、服务描述协议WSDL和服务发现/集成协议UDDI，以及服务工作流描述语言WSFL。而橙色部分描述的是更高层的待开发的关于路由、可靠性以及事务等方面的协议。黄色部分是各个协议层的公用机制，这些机制一般由外部的正交机制来完成。Web servers的体系结构的优缺点：优点：◆使得开发人员可以只关注整个结构中的其中某一层，当然这里是在铺设界定好了各层接口的前提下；◆可以很容易的用新的实现来替换原有层次的实现，也就是各层间的服务透明性，层内部可以进行灵活的替换；◆可以降低层与层之间的依赖；◆有利于标准化，这里明确各层的职责范围，成为开发人员共同的背景语言，也利于各种技术接口的界定；◆利于各层逻辑的复用，Web的开发将会针对之前的案例灵活的复用已有的单元。缺点：◆降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成，本来是数据可以直接通过DataSource穿透到表现层，现在必须通过层次包装上下传递，牺牲了暂时的灵活性，实际上还是赢的了长远的灵活性。◆有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码，这也是在设计时需要注意的，如何在早期的模型架构阶段考虑周全来避免。
上一篇：下一篇：&什么是软件架构？未显示需要 JavaScript 的文档选项级别: 初级, 高级 IT 架构师, IBM2006 年
15 日本文来自于 Rational Edge：这篇关于软件架构的较新规则的介绍，是一个关于“架构”的四篇系列文章的的第一篇。作者以定义规则的关键术语开始，继续探索设计出色的架构对于架构所部署的环境所起的作用。
我们毫不怀疑世界正变得越来越依靠软件。软件是诸如无处不在的手机，和复杂的空中控制系统的核心元素。事实上，如果没有软件，例如eBay 和 Amazon等我们理所当然认为是创新的企业将不可能存在。甚至那些金融业，零售业和公共部门等传统行业也相当的依赖于软件。在当今的时代，某种程度上，我们很难发现一个企业完全与软件不相关。高新企业为了生存，因此他们所依靠的软件必须能提供其所需的功能；所需的高质量；所承诺的可用性，和可接受的价格。这篇文章的主题就是关于可以影响这些属性的软件架构。我所关注的是“强软件系统”，在IEEE中定义如下：
一个软件集成系统就是软件对于设计，构建，配置和整个系统的发展具有深入影响的系统[来自 IEEE 1471，"架构的定义" 部分]在本文中，“架构”与“软件架构”是相同的含义。虽然这篇文章关注于软件集成系统，但是应该注意，软件集成系统仍然需要硬件来运行，并且诸如可靠性和性能等品质是通过软硬件的结合实现的。所以解决方案中的硬件部分不能被忽略。文中后面将更详细的讨论这部分内容。我们对于“架构”的定义没有缺陷。甚至存在支持定义集的网站。 文中的定义来自IEEE标准 1472000，IEEE对强软件系统的架构描述的推荐实践，参见IEEE 1471。 定义如下，其中重要部分用粗体字表示。架构是在组件，彼此间和与环境间的关系，引导设计发展原则中体现的系统的基本结构。[IEEE 1471]这些标准还定义了以下相关概念：系统是为实现某个（些）特殊作用的组件的集合。专用系统包括个人应用，传统概念上的系统，子系统，系统中的系统，产品线，产品系列，整个企业和其他利益集团。一个系统是为了实现一个或多个任务而存在。[IEEE 1471]环境决定了开发，操作，策略和其他影响系统的设置和条件。[IEEE 1471]任务是指系统为了实现对对象设置的使用或操作。[IEEE 1471]涉众是对于系统有利益关系或关注的个人，团队或组织。[IEEE 1471]正如我们所见，“组件”贯穿于这些定义。正如有意留下一个模糊的概念来解释，大部分架构定义没有提到“组件”，IEEE 1471也不例外。组件也许是逻辑上的或物理存在的，技术上独立的或特定的，规模大的或规模小的。由于文章的原因，我使用了UML 2.0规范的组件定义；并且我相当宽松的使用这个概念来包含各种所遇到的架构成分，包括了对象，技术组件（例如Enterprise JavaBean），服务，程序模块，遗留系统，包应用程序等。这些是 UML 2.0中对“组件”的定义：[组件]是包括内容的系统模型部分，且它的显示是可替换的。组件定义了所需接口的行为。例如，组件类似类型(type)，它与所需接口行为一致。（包括静态和动态语义）这里的定义包括了多种不同的概念，文中后面将有更详细的介绍。虽然工业界对于“架构”的概念没有普遍的共识，但是有必要考虑一些其他的定义使得他们可以被遵照。参照一下下面的定义，重点处我已经用粗体表示。架构是对软件系统组织，结构部分和系统包含接口的选择，集合部分的特定行为，较大子系统部分的构成和架构风格的重大决定的设置。[Kruchten]系统或计算系统的软件架构是包含软件部分，外部可见特性部分，和他们之间的关系的系统的结构。[Bass et al.][架构]是系统的组织结构和相关行为。架构可被重复分解为通过接口，互联部分的关系和结合部相互作用的部分。通过接口相互作用的部分包括类，组件和子系统。[UML 1.5]软件架构或系统由组成系统的结构的相互作用和软件结构的重要设计决定组成。设计决定应成功实现所期望支持的质量。设计决定为系统开发，支持和维护提供概念上的基础。 [McGovern]虽然在某些方面定义有些区别，但我们可以看到大部分是相同的。例如，大部分定义都指出一个架构关注于结构和行为，仅关注于重要决定，可以与架构风格一致，受涉众和环境的影响，体现基于原因的决定。所有这些方面，都在下面提到。如果你要求人们为你描述“架构”，十分之九的人都会参照结构来解释。这在关于构建或其他土木工程结构（例如桥梁）中非常常见。虽然这些条目中的其他属性（例如行为，目的适当性和美学观念）也存在，但是结构的属性是最熟悉的和最经常被提到的。我们对你会让某人来描述一下他所工作的软件系统架构一点也不会感到奇怪，他们将会给你展示一份系统结构方面的图表——无论这些内容是否是架构层，组件，或是分布结点。事实上，结构是架构的基础属性。架构会以各种形式展示他们自己，且大部分架构的定义是非常模糊的。一个结构组件可能是一个子系统，进程，库，数据库，计算结点，馈赠系统，按需产品等等。 许多架构的定义不但承认了他们自己的结构元素，而且还有结构元素的组成，关系（任何连接部分都需支持这样的关系），接口。这些部件都以不同方式被提供。例如，连接段可以是套接字，同步的或异步的，与某个协议相关等。图1提供了结构元素的例子。这幅图显示了包含展示顺序进程系统的结构部分的UML类图。我们看到有三个类——OrderEntry，CustomerManagement，和AccountManagement。OrderEntry类与CustomerManagement和AccountManagement类相连。图1：UML类图显示了结构元素与定义结构元素一样，架构定义了这些结构元素的相互作用。这些作用可以实现所期望的系统行为。
图2展示了允许系统支持在顺序进程系统中的次序定义的UML顺序图。在这里我们能看到五个交互作用。第一，Sales Clerk使用OrderEntry类创建了一个顺序。OrderEntry使得客户得到使用CustomerManagement类的细节。然后OrderEntry使用 AccountManagement类创建一个次序，用次序条目构建顺序。
图2：UML是序列图显示了行为元素 图2与图1相连，因为我们能从图2中的关于交互作用的定义得到图1中的相关内容。例如，OrderEntry事例在被执行中要依靠CustomerManagement事例，正如在图2中所示的一样。这种依赖就如OrderEntry和CustomerManagement间通信所反映的依赖关系一样。当一个架构定义了结构和行为，它不会在意所有的结构和行为的定义。它只在意那些被认为是重要的元素。重要的元素是那些有持久影响的，例如结构部分的主要部分，与核心行为相关的元素，和对诸如可靠性和可测量性等重要品质相关的元素。总的来说，架构不关心这些元素的细节。架构的重要性还可以以经济的重要性来表达，因为某些元素的主要驱动者是创建的成本和变更的成本。由于架构仅关注于重要元素，它给我们提供了在考虑中的系统的一个特殊透视图——与架构最相关的透视图。在这种含义下，一个架构是一个系统的抽象，可以帮助架构师管理复杂性。我们仅仅应注意重要元素的设置不是静态的。作为一个需要被提炼，确定风险，可执行的软件构建和经验总结的结果，重要元素的设置可能会改变。但是，面对改变的架构的稳定性是好的架构，好的可执行架构进程，好的架构师的标志。如果架构需要根据变化不断作出调整，那么这不是一个好的标志。但是，如果架构相对稳定，那么相反的也对。架构是为了实现涉众的需要而创造的。但是，一般来说不可能满足所有的需求。例如，涉众可能会问特定的时间框的功能，但是这两方面（功能和时间框）是互斥的。或者为了满足时间表而减少范围或者所有的功能可以扩展时间框实现。类似的，不同的涉众之间可能有相互冲突的需求，所以应满足适当的平衡性。所以作折中是构建进程的主要方面，且妥协是架构的重要属性。仅仅提供一个任务的例子，考虑如下涉众群各自的所需：最终用户关心直觉，正确的行为，性能，可靠性，可用性，有效性和安全性。系统管理员关注直觉行为，管理和辅助监测。业务人员关注有竞争力的特性，市场的时效性，对于其他产品的定位和开销。客户关注开销，稳定性和计划性。开发者关注清晰的需求和简单而一致的设计方法。项目经理关注追踪项目，计划，资源的生产使用和预算的可预见性。维护人员关注易理解性，一致性，和文档化的设计方法，与易修改性。正如表中可看到的，对于架构师的另一个挑战是涉众群不仅仅关注系统所提供的需求功能。他们所关注的在实际中是不起作用的，因为在系统中他们不发生作用。（例如，关于成本和计划的关注）但是这些关注体现了系统质量或局限。非功能需求经常是架构师所关注的最重要的需求。一个架构的重要部分不仅仅是最终结果，架构本身，而是他为什么是如此的原因。因此，确信你已把使用这个架构和原因文档化就非常重要了。这个信息与许多涉众都有关系，尤其是那些维护系统的人。这些信息对需要参考设计理由的架构师来说非常有价值，因为他们可以省去不必要的步骤。例如，当需要重复架构和架构师重新审视所做的决定时，这些信息非常有用。 大部分的架构来源于有相似关注的共享系统。这些相似性可被描述成某种特殊模式的架构风格，虽然经常是复杂和组合模式（由许多模式共同作用）。一种架构风格展示一个经验法典，并且有利于架构师重复使用类似经验。架构风格的例子包括分布式的风格，管道和过滤器风格，数据中心风格，基于规则的风格等。一个系统可以包含多于一个架构风格。Shaw和Garlan的描述如下：[架构风格] 按照结构组织的模式定义了系统。更具体的，架构风格定义了组件和连接型的语法，和连接的方法。在 UML 中的定义:[模式] 是对于普遍问题的普遍解决方案。除了重复经验，由于一种风格以文档的形式保存了使用它的理由和它的结构与行为，所以架构风格的应用使类似架构师的工作变得容易起来。系统贮存于环境中，且环境影响架构。这就是有时所提到的“环境中的架构”。基本上，环境决定了系统运行的范围，这些又决定了架构。影响架构的环境的因素包含架构所支持的商务环境，系统涉众群，内部技术限制（例如需要符合组织标准），和外部技术限制（例如对外部系统的接口或遵守外部规则的标准）。相反的，如在Bass, Clements, 和Kazman所描述的，架构可能还影响它的环境。不但是从技术前景的架构创新改变了环境--例如它可能对拥有组织的可重复使用价值有贡献——架构的创新可能在技术方面改变环境。当提到软件集成系统，有一个必须被提到的关于环境的特殊部分。为了软件的有用性，它必须执行。为了执行，软件运行在硬件之上。所以最终系统是软硬件的结合，与诸如可靠性和性能等完美结合的实现。软件不能在单独的硬件条件下实现这些功能。IEEE 标准 ，IEEE 信息技术标准 －－ 软件生命周期过程，定义了与之前IEEE1471不同的系统（关注于软件集成系统），但与在系统工程方面定义的相同：[系统]是包含了一个或多个进程，硬件，软件，工具与可以满足需求的人的集合。 [IEEE 12207]
Systems Engineering (RUP SE)的Rational Unified Process配置包含一个类似的定义。
[系统]是提供为企业执行商业目的或任务的服务资源。系统组件包括硬件，软件，数据和工作人员。在系统工程方面，根据软件，硬件和人的使用定义事务。例如，如果性能为重，那么可能决定某一个系统元素的硬件实现，而不是软件或人。另一个例子是为了给客户提供可用系统，所以要给客户提供接口。更复杂的情况需要通过软硬件和人的结合实现系统功能。我们非常有趣的注意到系统工程特别关注于对待软件和硬件，因此避免把硬件和软件相比作为第二级，或是执行软件的载体，或是反过来。架构定义了一组连贯的相关元素。例如，顺序进程系统架构可能已定义了一组次序入口，计数管理，客户管理，实现，外部系统集成，持续性和安全性。每一组都会要求不同的技术。因此，一旦被定义好，统一软件开发小组结构就非常有意义了。但是，情况经常是最初的小组结构影响了构架，而不是相反情况。因为结果通常都是一个不太理想的架构。“康威规律” 规定“如果你有4个编译小组，那你会有4路编译器”。 实际上，我们经常会无意识地创建架构，以反映创建架构的组织。但是，完全从实际出发，事实上这种有点理想的观点经常是不实际的，因为当前小组结构和技术都有实际可能的限制，并且架构师必须考虑在内。每个系统都有一个架构，即使这个架构没有被文档化，或者如果系统非常简单且包含单一元素。对架构文档化很有价值。文档化的架构比没有的考虑的更周全——因此也更有效，所以根据架构的进程可以更细致的考虑。相反地，如果架构没有文档化，那么很困难来证明满足了诸如可维护性，最佳适应性等的需求。似乎大部分现今存在的无文档的架构都有些随意性而不是目的性。有许许多多种架构，最著名的是与建筑和其他工程相关的。甚至在软件工程领域，我们经常会遇到不同形式的架构。例如，除了软件构架的概念，我们会遇到诸如企业架构，系统架构，组织架构，信息架构，硬件架构，应用架构，基础设施架构等。你会见到其他类型的，每种类型都定义了一个架构的具体范围。不幸的是，产业界没有相互形式间的协定，所以导致了对同一形式的不同意思。但是，从图3中可以推断出这些形式的范围。当你们在考虑和讨论下面这张图的时候，你肯定会发现很多你不同意的元素或是在你们的组织中不同的使用方法。但是重要的是——这些形式的确存在，却没有一致的观点。图3：不同领域的范围图3展示的元素有：软件架构——这篇文章主要的关注点。硬件架构——包括CPU, 内存，硬盘，周边设备例如打印机，与连接这些元素的部分。组织架构——是一些关于商业进程，组织结构，规则和职责，与组织核心能力的部分。信息架构——包含组织好的信息结构。软件架构，硬件架构，组织架构和信息架构是全部系统架构的子结构。企业架构，与系统架构很相似，包括硬件，软件，人员等。但是，企业架构与商业有很强的联系，因为它专注于商业对象的联系，专注于商业敏捷性和组织效率。企业架构可能穿插于公司间。正像人们期盼的那样，有相应形式的架构师（例如软硬件架构师等）和架构（例如，软硬件架构等）。现在我们已浏览过这些定义了，但还有很多未回答的问题。企业架构与系统架构间有什么不同？一个企业是一个系统？信息架构与数据集成软件应用中的数据架构是一样的？不幸的是，没有对这些问题的一致的答案。对现在来说，你会意识到这些不同，但是产业界不存在对这些内容的一致定义。因此，对你的建议只是选择那些与你的组成相似的形式并且合适的定义他们。至少你会获得某些一致性，并减少错误传达的可能。这篇文章关注于定义软件架构的核心特性。但是，仍然有很多未被解答的问题。什么是软件架构师的角色？架构师最重要的活动是什么？从“建立架构”中能得到什么好处？这些问题将在后续文章中被解答。这篇文章的内容来源于一本即将出版的新书，暂时叫做“软件架构建立过程”。最后，我衷心的感谢对内容提出宝贵意见的人们，他们是Grady Booch，Dave Braines，Alan Brown，Mark Dickson，Holger Heuss，Kelli Houston，Luan Doan-Minh，Philippe Kruchten，Nick Rozanski，Dave Williams，和Eoin Woods。1 软件工程研究所（SEI）架构Web站点 －－ 架构定义，提供了一个好的例子。参见 2 IEEE Computer Society，强软件系统的架构描述的IEEE推荐实践：IEEE 标准 00。3 对象管理组织，UML 2.0 结构规格说明：文档号 03-09-15。2003年九月。4 Philippe Kruchten，Rational统一过程：介绍，第三版。Addison-Wesley Professional 2003。5 Len Bass，Paul Clements 和 Rick Kazman，软件架构实践，第二版。Addison Wesley 2003。6 对象管理组织，OMG 统一建模语言规格 1.5版，文档号 03-03-01。2003年三月。7 James McGovern等，企业架构的实践指南。Prentice Hall 2004
8 一个在本系列的后续文章中所涵盖的角色。9 Mary Shaw 和 David Garlan，软件架构 -- 关于一个正在形成的学科的观察。 Prentice Hall 1996，10 Grady Booch，James Rumbaugh 和 Ivar Jacobson，统一建模语言用户指南。Addison Wesley 1999。11 Bass 等，前面引用的书。12 IEEE Computer Society，IEEE 信息技术标准 －－软件生命周期过程。IEEE 标准 。13 Murray Cantor，“系统工程的Rational统一过程”。The Rational Edge，2003年八月。
您可以参阅本文在 developerWorks 全球站点上的 。
Peter Eeles 为 IBM Rational 和 IBM Software Group 工作，他的工作专注于大型分布式系统的架构和运行。在英国，他协助一些组织使用Rational统一过程和IBM软件开发平台。他是“使用Rational统一过程构建J2EE应用程序”（Addison-Wesley，2002），“构建业务对象”（John Wiley and Sons，1998）的合著者之一，并且是“软件架构”（Springer-Verlag，1999）的作者之一。太差！ (1)需提高 (2)一般；尚可 (3)好文章 (4)真棒！(5)建议？其他公司、产品或服务的名称可能是其他公司的商标或服务标志。}