摘要：软件架构定义是怎样的？ 软件架构定义：将软件系统划分为多个模块，明确各模块间的相互作用，组合起来实现系统的全部特性。 软件架构不仅确定了系统的组织结构和拓扑结构，还显示了系统需求和构成系统各要素间的对...

软件架构定义是怎样的？

软件架构定义：将软件系统划分为多个模块，明确各模块间的相互作用，组合起来实现系统的全部特性。

软件架构不仅确定了系统的组织结构和拓扑结构，还显示了系统需求和构成系统各要素间的对应关系，提供了一些设计决策的基本原则。

以上是我对于这个问题的回答，希望能够帮到大家。

软件架构设计的三个维度是什么？

构设计是一个非常大的话题，不管写几篇文章，接触到的始终只是冰山一角，更多的是实践中去体会。

这篇文章主要介绍面向对象OO、面向方面AOP和面向服务SOA这三个要素在架构设计中的位置与作用。

架构设计有三个维度，或者说是我们在考虑架构时需要思考三个方向。

这三个维度分别为面向对象、面向方面、面向服务。

这三个维度可以看作是正交的，但不同维度会互相印证，互相支撑，整个架构的示意图如图所示。

图：架构三维度结构图 面向对象 面向对象技术最初是从面向对象的程序设计开始的，它的出现以上世纪60年代Simula语言为标志，并在Smalltalk语言的完善和标准化过程中得到更多的扩展和对以前思想的重新注解。

上世纪80年代中后期，面向对象程序设计逐渐成熟，被计算机界理解和接受，人们又开始进一步考虑面向对象的开发问题。

直到现在，面向对象已经成为一种非常流行的编程方式，以及软件设计的架构。

面向对象提出有三个主要目标：重用性、灵活性和扩展性，强调对象的“抽象”、“封装”、“继承”和“多态”。

它能让人们以更加接近于现实世界的方式来思考程序，这点可以说是面向对象最大的进步。

在OO思想的运用上，业界出现了很多好的经验与技巧，从而涌现出大量的设计模式，可以说面向对象是系统分析与设计时的一个很重要的方面。

面向方面 面向方面最初来源于hook技术，本质上就是满足扩展的需求，可以在程序中自由扩展功能。

面向方面不仅仅是一门编程技术，同样也是一种架构设计的思路。

如果说OO是纵向地分析、切割整个系统，那么可以认为AOP是横向地对系统作切片。

简单地理解，OO与AOP分别从两个不同的角度给我们提供了分析系统的思路。

面向方面可以弥补面向对象的缺陷，两种方式有机的结合在一起，可以更加有效地对系统进行分析。

我们认为OO是接近于人类认识自然的思维方式，但对于东方而言却并不一定是这样的。

当西方人看到一个复杂系统的时候，只会有一种思路，就是“分解”，将系统分解成一块一块，然后每个部分进行研究。

当东方人看到一个复杂系统的时候，更多地会关注系统中存在的关系，将系统作为一个有机的整体进行研究，这也是东方和西方在事物看法上存在的差异。

这两种思维方式都没有问题，如果结合起来分析问题，解决问题会更好。

面向对象与面向方面也同样如此，都能对应到人类认识自然的思维方式上。

面向服务 面向服务可以说是最近炒得比较火热的概念。

包括现在提到的SaaS(Softwae as a sevice)，软件即服务。

准确而言，面向服务不仅仅是软件行业的概念，这个要从社会的产业结构说起。

社会产业总共分为三个，第一产业农业，第二产业工业，第三产业服务业。

最早社会的主要产业是第一产业农业，将近有几万年的历史。

十八世纪下半叶在英国开始的工业革命，对人们的生活产生了根本性的影响，社会的主要产业成了第二产业工业。

现在仍然属于工业时代，或者有人说的“后工业时代”。

而在后工业时代，社会的经济体制必定要向第三产业服务业逐渐转型。

面向服务其实是社会经济体制重心的一种迁移。

还是说回到软件行业，社会的主要产业将转变成服务业，自然软件行业也会出现对应的变化，那就是这里提到的面向服务。

面向服务今后会影响到软件的交付模式，会对整个软件行业的体制产生影响。

而说到架构层面，面向服务是系统发布功能的一种方式。

并且基于这种方式下不同的系统之间能有效地通信、协作。

常见的实现技术就是We Sevice。

软件全局观 软件架构设计的三个维度：面向对象、面向方面、面向服务。

最年长的一个维度就是面向对象，发展了好几十年，也是相对而言比较成熟的一个维度。

它解决的问题是系统内部结构的设计。

面向方面思想的提出能够弥补面向对象的缺陷。

面向对象的方式不能实现横切关注点的分离，而面向方面正是为了解决这个问题。

面向方面与面向对象一样都是解决系统内部结构的设计。

面向服务更多的是涉及到系统的外部，简单地说就是发布功能。

它并不关注系统内部结构的实现，所以说面向服务与面向对象或者面向方面并不冲突。

这三个维度并不是绝对孤立的，它们之间会互相影响、制约，相互发展的。

我们在分析架构的时候需要同时考虑到这三个维度的问题，这样有助于我们设计出更加优秀的架构。

什么是软件架构？

模式名 环境 问题 影响，描述应考虑的不同问题方面 解决方案 基本原理 结果环境 示例 模式名 层 环境 需要进行结构分解的大系统。

问题 必须处理不同抽象层次的问题的系统。

例如：硬件控制问题、常见服务问题和针对于不同领域的问题。

最好不要编写垂直构件来处理所有抽象层次的问题。

否则要在不同的构件中多次处理相同的问题（可能会不一致）。

影响 系统的某些部分应当是可替换的 构件中的变化不应波动 相似的责任应归为一组 构件大小 -- 复杂构件可能要进行分解 解决办法 将系统分成构件组，并使构件组形成层叠结构。

使上层只使用下层（决不使用上层）提供的服务。

尽量不使用非紧邻下层提供的服务（不跳层使用服务，除非中间层只添加通过构件）。

示例： 1. 通用层 严格的分层构架规定设计元素（类、构件、包、子系统）只能使用下层提供的服务， 服务可以包括事件处理、错误处理、数据库访问等等。

相对于记录在底层的原始操作系统级调用，它包括更明显的机制。

2. 业务系统层 上图显示了另一个分层示例，其中有垂直特定应用层、水平层和基础设施层。

注意：此处的目标是采用非常短的业务“烟囱”并实现各种应用程序间的通用性。

否则，就可能有多个人解决同一问题，从而导致潜在的分歧。

软件架构有哪些过程？

本文来自于 Rational Edge：软件架构被公认为软件开发领域的一门新兴学科。

作为软件架构系列文章的第三篇，本文描述的是在软件工程的生命周期里软件架构师正在进行的各类活动。

在这个系列里，我的 第一篇文章描述的是什么是软件架构， 第二篇文章 讲述软件架构师这个角色的特征。

第三部分是建立在以前讨论的基础之上，而且所考虑的主题或者特征都是在软件架构过程这个框架下。

软件架构活动：定义及范围 根据IEEE标准，软件架构活动代表了 这样一系列活动：定义、记录、维持、改进一个软件构架并确保其正确执行。

软件架构的范围相当宽泛。

图1展示的模型详细地说明了软件架构过程的各个方面。

这个模型来自IEEE标准1471，架构师所关注的软件架构各个方面都可以此模型作为参考。

图1：软件架构相关术语的模型 图1中阴影框里的元素直接来自于IEEE标准1471，它们之间的相互关系阐明的是一个系统及其构架的诸多特征： 一个系统有一个构架。

一个系统完成一项任务。

一个系统存于一个环境中，并受这个环境的影响。

一个系统有一个或多个涉众。

一个构架对应一条构架描述。

一条构架描述识别一个或多个涉众。

一条构架描述识别一条或多条关联。

一条构架描述提供理由。

一个涉众有一条或多条关联，一条关联对一个或多个涉众都很重要。

软件体系结构与软件架构有哪些区别？

软件体系结构与软件架构的中文翻译都是英文Softwae Achitectue。

两者都使用一样的定义，如IEEE的“一个系统的基础组织，包含各个构件、构件互相之间与环境的关系，还有指导其设计和演化的原则。

”[IEEE-2000]为了找到两者的区别，得先从应用的环境入手。

我们利用网站搜索引擎对这个领域的常用关键词进行了检索，搜索区域分为开发者网站、所有网站、学术网站，结果如下（检索日期2007-04-08）： ① http:www-128.im.comdevelopewokscn ② http:www.miscosoft.comchina ③ google.com 采用精确匹配。

“架构师”改为“软件架构师”，“架构设计师”改为“软件架构设计师”减少领域差异 ④ aidu.com 采用精确匹配。

“架构师”改为“软件架构师”，“架构设计师”改为“软件架构设计师”减少领域差异 ⑤ http:www.cnki.netindex.htm采用精确匹配。

中国期刊全文数据库（2000-2007） 结果表明，在软件开发者和软件应用者来说，倾向于使用“软件架构”，在一定程度上接受“软件体系结构”。

大家对软件架构的设计人员，“架构师”得到广泛的认同。

对于学术界，普遍使用“软件体系结构”，对架构师几乎没有关注。

Softwae Achitectue是一个实践性非常强的领域，统计表明理论和实践的鸿沟还是存在的。

其次，我们从词源探讨“体系”“结构”“架构”的解释[字典-2001]。

体系：若干事物互相联系而构成的一个整体。

例思想~ | 工业~ 结构：①建筑物承受重量和外力的部分及其制造。

按材料分有钢结构、木结构、砖石结构、框架结构、砖混结构等。

按形式分有悬索结构、拱结构等。

②构成整体的各个部分及其结合方式。

例经济~│文章~。

③文艺作品的内部构造。

即作品的各部分（包括内容和形式）之间有机的组织联系。

架构：①建造；构筑。

②框架；支架。

③比喻事物的组织、结构、格局。

例市场~│故事~庞大 通过以上分析，我们不难看出学术界为什么用“软件体系结构”。

首先，体系结构的中文定义完全符合IEEE等的定义。

强调整体与部分，部分与部分的关系；研究系统构成的方法学；提倡多角度研究系统。

其次，从学科地位讲，作为一门独立软件子学科，和硬件学科（计算机组织与体系结构）直接对应。

从工程实践需要看，软件架构更能体现系统构成与相关技术。

RUP过程或软件生产线关注的软件架构并不注重原理及表示，而是由结构和技术相结合的形成框架。

软件架构在中文中很容易与软件框架（Softwae Famewok）混淆，对于一个应用的软件框架通常称为应用程序框架（Application Famewok）。

框架是为了构建完整的应用而必须详细阐述的一种程序结构[Johnson-88]。

框架在RUP和软件产品线开发过程中是一个非常重要的过程。

RUP中框架是细化阶段的一个制品，软件产品生产线中是一组应用共享的程序框架。

目前，没有文献表明软件体系结构与软件架构的差别。

如果你强调方法论，应使用软件体系结构。

强调软件开发实践，应使用软件架构。

【杂志制作软件】个性杂志册制作软件哪个最好

软件架构 软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。

软件架构是一个系统的草图。

软件架构描述的对象是直接构成系统的抽象组件。

各个组件之间的连接则明确和相对细致地描述组件之间的通讯。

在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。

在面向对象领域中，组件之间的连接通常用接口_（计算机科学）来实现。

软件体系结构是构建计算机软件实践的基础。

与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。

特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。

在“软件构架简介”中，David GArlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。

结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。

”[GS93] 但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”[IEEE98]。

构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。

它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。

在 Rational Unified ProcESs 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。

从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。

一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管理软件产品的高级设计。

软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。

什么是软件系统架构设计

软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。

软件架构是一个系统的草图。

软件架构描述的对象是直接构成系 统的抽象组件。

各个组件之间的连接则明确和相对细致地描述组件之间的通讯。

在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。

在面向 对象领域中，组件之间的连接通常用接口_（计算机科学）来实现。

软件体系结构是构建计算机软件实践的基础。

与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。

特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。

在“软件构架简介”中，David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。

结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。

但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”。

构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。

它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。

在Rational Unified Process 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。

从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。

一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管 理软件产品的高级设计。

软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。

一般而言，软件系统的架构（Architecture）有两个要素： 它是一个软件系统从整体到部分的最高层次的划分。

一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。

详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。

所谓架构元素，也就是组成系统的核心＂砖瓦＂，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。

建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。

建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。

显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。

进行软件架构设计有什么样的益处？

一般来说，软件架构设计是降低成本，改进质量，按时交付产品和按需交付产品的关键因素。

在这篇文章中，我将会把讨论的焦点放在实现这些目标所能带来的好处上面。

作为一个构架师，证明我们的存在是没有任何意义的。

这个部分将会提供一些方法，这些方法对于把处理架构设计作为一个软件开发过程的关键部分是很有用处的。

架构设计能够满足系统的品质 系统的功能性是软件构架师通过组成体系架构的多种元素之间的交互作用来支持的。

然而，架构设计的一个关键特性是，系统的品质是通过某些手段来实现的。

软件的品质，例如性能，安全性和可维护性等，它们在缺少统一的架构设计视图时是无法实现的，因为这些品质并不是被限制在一个单一的架构设计元素中，而是渗透在整个架构设计体系中的。

例如，为了满足性能要求，可能需要考虑体系架构中的每一个组件的实现时间，同时还要考虑各组件之间通讯所花费的时间。

同样地，为了满足安全性要求，可能需要考虑两个组件之间自然的通讯，并且要在需要的特定的地方引入安全性提示组件。

所有的这些关系都属于体系架构，在上面的例子中，这些关系包括组件自身的和组件之间的。

Java软件架构如何设计？

开始之初的架构设计决定着软件产品的生死存亡。

“好的开始相当于成功一半”。

开始的架构设计也是最难的，需要调研同类产品的情况以及技术特征，了解当前世界上对这种产品所能提供的理论支持和技术平台支持。

再结合自己项目的特点（需要透彻的系统分析），才能逐步形成自己项目的架构蓝图。

比如要开发网站引擎系统，就从Yahoo的个人主页生成工具 到虚拟主机商提供的网站自动生成系统，以及IBM Wephee Potal的特点和局限 从而从架构设计角度定立自己产品的位置。

好的设计肯定需要经过反复修改，从简单到复杂的循环测试是保证设计正确的一个好办法 由于在开始选择了正确的方向，后来项目的实现过程也验证了这种选择，但在一些架构设计的细部方面，还需要对方案进行修改，属于那种螺旋上升的方式，显然这是通过测试第一的思想和XP工程方法来实现的。

如果我们开始的架构设计在技术平台定位具有一定的世界先进水平，那么，项目开发实际有一半相当于做实验，是研发，存在相当的技术风险。

因此，一开始我们不可能将每个需求都实现，而是采取一种简单完成架构流程的办法，使用最简单的需求将整个架构都简单的完成一遍（加入人工干预），以检验各个技术环节是否能?髋浜瞎ぷ？非常优秀先进的两种技术有时无法在一起工作），同时也可以探知技术的深浅，掌握项目中的技术难易点。

这个过程完成后，我们就对设计方案做出上面的重大修改，丰富完善了设计方案。

设计模式是支撑架构的重要组件 架构设计也类似一种工作流，它是动态的，这点不象建筑设计那样，一开始就能完全确定，架构设计伴随着整个项目的进行过程之中，有两种具体操作保证架构设计的正确完成，那就是设计模式（静态）和工程项目方法（RUP或XP 动态的）。

设计模式是支撑架构的一种重要组件，这与建筑有很相象的地方，一个建筑物建立设计需要建筑架构设计，在具体施工中，有很多建筑方面的规则和模式。

我们从J2EE蓝图模式分类http:java.sun.comluepintspattenscatalog.html中就可以很清楚的看到J2EE这样一个框架软件的架构与设计模式的关系。

架构设计是骨架，设计模式就是肉 这样，一个比较丰富的设计方案可以交由程序员进一步完成了，载辅助以适当的工程方法，这样就可保证项目的架构设计能正确快速的完成。