软件架构设计（软件的架构与设计模式之什么是架构）

本文目录

• 软件的架构与设计模式之什么是架构
• 用什么工具画 软件架构设计图
• 软件架构的设计
• 什么是软件系统架构设计
• 如何进行软件架构设计
• 什么是软件架构
• 有什么比较好的软件架构和软件工程的书

软件的架构与设计模式之什么是架构

一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。具体地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。所谓架构元素，也就是组成系统的核心“砖瓦“，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。·建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行具体设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。计算机软件的历史开始于五十年代，历史非常短暂，而相比之下建筑工程则从石器时代就开始了，人类在几千年的建筑设计实践中积累了大量的经验和教训。建筑设计基本上包含两点，一是建筑风格，二是建筑模式。独特的建筑风格和恰当选择的建筑模式，可以使一个独一无二。下面的照片显示了中美洲古代玛雅建筑，Chichen-Itza大金字塔，九个巨大的石级堆垒而上，九十一级台阶（象征着四季的天数）夺路而出，塔顶的神殿耸入云天。所有的数字都如日历般严谨，风格雄浑。难以想象这是石器时代的建筑物。 图1、位于墨西哥Chichen-Itza（在玛雅语中chi意为嘴chen意为井）的古玛雅建筑。（摄影：作者）软件与人类的关系是架构师必须面对的核心问题，也是自从软件进入历史舞台之后就出现的问题。与此类似地，自从有了建筑以来，建筑与人类的关系就一直是建筑设计师必须面对的核心问题。英国首相丘吉尔说，我们构造建筑物，然后建筑物构造我们（We shape our buildings, and afterwards our buildings shape us）。英国下议院的会议厅较狭窄，无法使所有的下议院议员面向同一个方向入座，而必须分成两侧入座。丘吉尔认为，议员们入座的时候自然会选择与自己政见相同的人同时入座，而这就是英国政党制的起源。Party这个词的原意就是“方“、“面“。政党起源的要害就是建筑物对人的影响。在软件设计界曾经有很多人认为功能是最为重要的，形式必须服从功能。与此类似地，在建筑学界，现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能（Forms follows function）。几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。最为闻名的，当然就是模式理论和XP理论。架构的目标是什么正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：·可靠性（Reliable）。软件系统对于用户的商业经营和治理来说极为重要，因此软件系统必须非常可靠。·安全行（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。·可扩展性（Scalable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。 ·可定制化（Customizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。·可扩展性（Extensible）。在新技术出现的时候，一个软件系统应当答应导入新技术，从而对现有系统进行功能和性能的扩展·可维护性（Maintainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费·客户体验（Customer Experience）。软件系统必须易于使用。·市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。架构的种类根据我们关注的角度不同，可以将架构分成三种：·逻辑架构、软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。比如下面就是笔者亲身经历过的一个软件系统的逻辑架构图 图2、一个逻辑架构的例子从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。每一个层次都含有多个逻辑元件。比如WEB服务器层次中有Html服务元件、session服务元件、安全服务元件、系统治理元件等。·物理架构、软件元件是怎样放到硬件上的。比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。 图3、一个物理架构的例子·系统架构、系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。 首先，一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。其次，进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。根据作者的经验，一个基于数据库的系统架构，有多少个数据表，就会有多少页的架构设计文档。比如一个中等的数据库应用系统通常含有一百个左右的数据表，这样的一个系统设计通常需要有一百页左右的架构设计文档。 架构师软体设计师中有一些技术水平较高、经验较为丰富的人，他们需要承担软件系统的架构设计，也就是需要设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定的作出。这样的人就是所谓的架构师（Architect）。在很多公司中，架构师不是一个专门的和正式的职务。通常在一个开发小组中，最有经验的程序员会负责一些架构方面的工作。在一个部门中，最有经验的项目经理会负责一些架构方面的工作。但是，越来越多的公司体认到架构工作的重要性，并且在不同的组织层次上设置专门的架构师位置，由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。

用什么工具画 软件架构设计图

1、Microsoft Office Visio

Office Visio 是office软件系列中的负责绘制流程图和示意图的软件，是一款便于IT和商务人员就复杂信息、系统和流程进行可视化处理、分析和交流的软件。

2、ProcessOn

是一款网页版的在线作图工具，优点是无需下载安装、破解这些破事，同时支持在线协作，可以多人同时对一个文件协作编辑，而且上手比较容易，它提供很多流程图模版，可以方便的画出流程图、思维导图、原型图、UML图。

3、OmniGraffle

OmniGraffle可以用来绘制图表，流程图，组织结构图以及插图，也可以用来组织头脑中思考的信息，组织头脑风暴的结果，绘制心智图，作为样式管理器，或设计网页或PDF文档的原型。只能于运行在Mac OS X和iPad平台之上。

4、亿图

是一款基于矢量的绘图工具，包含大量的事例库和模板库。可以很方便的绘制各种专业的业务流程图、组织结构图、商业图表、程序流程图、数据流程图、工程管理图、软件设计图、网络拓扑图等等。

5、Axure RP

Axure RP是美国Axure Software Solution公司旗舰产品，是一个专业的快速原型设计工具，让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。

软件架构的设计

为了讨论和分析软件构架，必须首先定义构架表示方式，即描述构架重要方面的方式。在 Rational Unified Process 中，软件构架文档记录有这种描述。架构描述语言(ADL)用于描述软件的体系架构。已有多种架构描述语言，如Wright (由卡内基梅隆大学开发)，Acme (由卡内基梅隆大学开发)，C2 (由UCI开发)， Darwin (由伦敦帝国学院开发)。ADL的基本构成包括组件、连接器和配置。 构架构架视图的图形描述称为构架设计图。对于以上描述的各种视图，设计图由以下统一建模语言图组成 [UML99]：逻辑视图：类图、状态图和对象图。进程视图：类图与对象图（包括任务 - 进程与线程）。实施视图：构件图。部署视图：配置图。用例视图：用例图描述用例、主角和普通设计类；顺序图描述设计对象及其协作关系。 软件设计师中有一些技术水平较高、经验较为丰富的人，他们需要承担软件系统的架构设计，也就是需要设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定的作出。这样的人就是所谓的架构师（Architect）。在很多公司中，架构师不是一个专门的和正式的职务。通常在一个开发小组中，最有经验的程序员会负责一些架构方面的工作。在一个部门中，最有经验的项目经理会负责一些架构方面的工作。但是，越来越多的公司体会到架构工作的重要性，并且在不同的组织层次上设置专门的架构师位置，由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。

什么是软件系统架构设计

　　软件架构（software　　architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系　　统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向　　对象领域中，组件之间的连接通常用接口_(计算机科学)来实现。　　软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。　　软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。　　在“软件构架简介”中，David Garlan 和 Mary Shaw　　认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。　　但构架不仅是结构；IEEE Working Group　　on Architecture 把其定义为“系统在其环境中的最高层概念”。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。　　在Rational Unified Process 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。　　从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管　　理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。　　一般而言，软件系统的架构（Architecture）有两个要素：　　它是一个软件系统从整体到部分的最高层次的划分。　　一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。　　详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。　　所谓架构元素，也就是组成系统的核心“砖瓦“，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。　　建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。　　建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。

如何进行软件架构设计

软件架构设计的几个步骤 1、分析需求和理解业务模型（或领域建模），并选定关键Use case。 软件的需求，可以分为从用户视角和开发人员视角来看，从用户的角度看，又可以分为功能性和非功能性需求，我们必须从不同的视角和级别去全面的认识需求并分析需求，理解业务模型。实践表明，常常被我们忽视的非功能性需求常常会导致整个项目失败。 理解业务需求最好的方式莫过于进行领域建模，领域建模与需求分析往往是交替穿叉进行的，领域建模主要有以下三个方面的作用： ◆探索复杂问题，弄清领域知识。Martin Fowler曾经说过，他采用面向对象方法最大的好处就是它有助于解决更为复杂的问题。领域建模本身作为辅助思维的工具，帮助我们将注意力始终保持在最为重要的业务概念及其关系上，使我们能够不断深入地，系统的对需求进行分析和认识。领域建模往往是一个从模糊到清晰，从零散到系统的过程。 ◆决定功能范围，影响可扩展性。任何模型都是对现实世界某种程序的抽象，这种抽象就会忽略某一些东西，例如忽略对象的属性和对象间的关系，而这些忽略往往都是带有一定的目的性的，这种忽略就决定了功能的范围。模型揭示了各种功能背后的结构，如果说定义功能相当于“拍照片”的话，那么领域建模就相当于“做透视”，更加关注问题领域的内在结构，相当于对问题领域进行了一定的抽象，良好的领域模型不仅能很好的支持现有的功能，而且还可以在一定程度上支持未来可能出现的新需求，体现良好的可扩展性。 ◆提供交流基础，促进有效沟通。领域建模通常会使用UML图作为呈现的方式，这样为我们的沟通提供了方便。当然，有时候文字在描述某些特定领域的问题时可能更适合，可以灵活运用。 在我们公司的实际软件开发流程中，往往领域建模缺少这一环节，这可能是在以后的工作中需要进一步提高之处。 虽然我们总是期望架构设计师能全面掌握需求，但由于时间和精力的限制，摆在我们面前的现实就是架构设计师没有时间对所有需求进行深入分析，所以我们的策略就是“把好钢用在刀刃上”，即把大部分时间和精力花在对决定架构最重要的关键需求上。在选择关键需求时要注意：高优先级的需求往往是从用户的角度来看的，可能并不是真正的关键需求。在《RUP实践者指南》一书中向我们讲述了如何确定关键功能需求？A.作为应用程序的核心或实现了系统的主要接口的功能，B.必须被实现的功能，即如果这些功能不被实现，则开发出来的软件就失去了价值，C.覆盖了系统架构的一些方面，但没有被其他重要的Use case覆盖到的功能。 2、分别从各个视角来考虑软件架构的方方面面。 软件的架构设计必须考虑到各方面，根据前期工作确立的领域模型，关键需求，系统约束等进行设计，必须从系统用户，开发人员，系统管理员，部署管理员，数据管理员等人员的角度去分析并解决问题。比如说，如果我们的运行架构采用Cluster方式时，就必须小心Cache和Session等的使用；如果我们的业务逻辑要求我们要操作多个数据库时，就要考虑采用支持二阶段事务提交的方式。 只有将这些方方面面的问题都考虑到了，这样的架构设计才是完整的。至于每一个视图中，我们应该设计到什么细节这一问题，实际上与整个项目的过程定义有关。例如，如果我们有专门安排数据库概要设计的活动，那我们在架构设计的过程中就可以只需要关注更高层次的数据库特性及数据库之间的关系，而每一张表的数据字典可以在后续的相关活动中进行设计，但如果没有这样的活动，那我们就要细化到每一张表的每一个栏位，以及表之间的关系。 3、解决技术面的重点问题和难题 在软件架构设计的过程中，我们往往会需要攻克一些技术面的重点问题和难题，这完全是一项极其需要扎实的理论知识和丰富的实践经验支撑的工作。例如，我们如何提高整个系统的性能？如何能很好的导出极其复杂的“中国式报表”（一般比西方国家产出的报表要复杂很多，而且很多开源的BI类的框架并不能完全解决问题）？ 当遇到确实是很困难的问题，可以去百度一下或Google一下，也可以去请教公司的资深技术人员或专家，或者召开小范围的技术专题讨论会议，采用脑力激荡的方法试着找找答案，这样才能提高工作的效率。 4、召开架构设计评审会议进行同行评审。 架构设计评审是极其重要的一环，我曾将其形容为“七种武器”中的离别钩，就是因为在会议上，同行们可能会提很多问题或意见，而且很多意见很尖锐，所以一定要虚心接受，并做好记录，正所谓“良药苦口利于病，忠言逆耳利于行”。 在评审会议之前，我们要完成很多准备工作，最好是能准备一份简明扼要的电子简报，把最重要的问题列出来，这样在进行评审会议时，就不会漫无目的，在会议前就将这些资料发给与会人员，请他们抽空先了解一下，在会议进行时，要学会控制会议的进度，提高会议的效率。 5、针对关键Use case在设计的架构上实现功能来验证架构。 对于架构设计的验证也是一项十分重要的工作，其验证技术有很多种，在我们公司通常会采用Sample的形式，即XP中所说的迭代0，RUP中所说的切片。这样做的好处是既可以从实际的产品角度出发来有效的验证架构是否满足要求，又可以比抛弃型原型验证技术节省成本。 这个Sample绝不是我们在解决架构设计中的问题时拿来做实验的一些代码的拼凑，而是完整的实现某一关键Use case的符合架构设计和一系列规范的可交付的代码及相关文档。同时，这个Sample可以作为你在给大家讲解或培训架构时的教材，也可以作为开发人员使用此架构进行开发的蓝本，甚至是只需要复制粘贴，加上简单的修改即可。 6、交付给客户Review。 这一环节，在很多公司可能并不存在，因为他们的软件架构并不一定需要客户Review，但像我们这种做服务的公司，最重要的就是客尊，落实到软件架构设计这一活动，就是让客户理解并接受你的架构设计方案，同时，客户也会起到帮你验证架构的作用。通常，我们的架构得到客户的认可后，便可进入大规模的开发。 在交付给客户Review时，通常

什么是软件架构

软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

有什么比较好的软件架构和软件工程的书

1.软件架构设计作者： 温昱内容简介：本书紧紧围绕“软件架构设计”这一主题，立足实践解析了软件架构的概念、阐述了切实可行的软件架构设计方法、提供了可操作性极强的完整的架构设计过程。另外，本书从思维方式的突破、面向对象设计、UML建模、过程与管理等关键过渡环节，为广大程序员的成长提供了切中肯綮的指导。本书可作为计算机软件专业本科生、研究生和软件工程硕士的软件架构设计教材，也可作为软件开发高级培训、软件开发管理培训的培训教材，更是第一线高级开发人员和开发管理人员的必备参考书。作译者介绍温昱，资深咨询顾问，CSAI特聘高级顾问，软件架构专家，软件架构思想的传播者和积极推动者。十年系统规划、架构设计和研发管理经验，在金融、航空、多媒体、网络管理、中间件平台等领域负责和参与多个大型系统的规划、设计、开发与管理。在《程序员》杂志、IBM DeveloperWorks等媒体发表了《图论思想与UML应用》、《敏捷设计从理论到实践》、《随需而变的RUP》等文章数十篇。译著有《应用框架的设计与实现——NET平台》等。作者: 温昱 温昱 资深咨询顾问，CSAI特聘高级顾问，软件架构专家。软件架构思想的传播者和积极推动者，中国软件技术大会杰出贡献专家。千年系统规划、架构设计和研发管理经验，在金融、航空、多媒体、电信、中间件平台等领域负责和参与多个大型系统的规划、设计、开发与管理。作为资深咨询顾问，已为众多知名企业提供了卓有成效的架构培训与咨询服务。 同作者作品软件架构设计(09年度畅销榜TOP50) SQL语言艺术 (china-pub首发) (08年度畅销榜TOP50) 一线架构师实践指南(中大型系统架构设计指南) 2. 架构实战—软件架构设计的过程 原书名： The Process of Software Architecting 作者： （英）Peter EelesPeter Peter Cripps 译者： 蔡黄辉 马文涛 内容简介:本书从基本原理入手，介绍软件架构设计过程中涉及的一些概念、流程、方法、用到的工作产品及可重用的资源，从第6章开始，通过介绍一个具体的案例来阐述如何定义需求、创建逻辑架构、创建物理架构。在第10章“进阶”中，作者补充说明了架构师和软件开发项目其他方面的关系，后面又说明了各种软件开发项目可能存在的困难及相应的处理方法。本书理论结合实践，介绍了一些可以应用到整个或部分的架构设计流程中的最佳方法。不管你是一位资深的架构师还是一位有志于成为架构师的初级使用者，通过阅读本书都能从中获益。 作译者介绍Peter Eeles 是IBM的高级IT架构师，他就职于IBM的Rational品牌软件组。在这个职位上，他帮助组织提高软件开发能力，尤其关注和致力于改进架构流程。Peter从1985年开始从事软件行业，其主要工作是进行架构设计和实现大规模、分布式的系统。Peter是《Building J2EE Applications with the Rational Unified Process》（Addison?Wesley，2002）和《Building business Objects》（John Wiley & Sons，1998）的合著者。他还是英国计算机协会高级会员（FBCS）、工程技术协会（FIET）会员、IBM技术人员、Open Group 3. 面向模式的软件架构.第4卷,分布式计算的模式语言(经典POSA系列的第4卷) 原书名： Pattern-Oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing 作者： (德)Frank Buschmann (英) Kevlin Henney (美)Douglas C. Schmidt 译者： 肖鹏 陈立 内容简介：本书关注分布式计算系统软件的设计和实现。书中首先介绍理解本书内容所需的核心的模式概念，分布式计算的好处和挑战；然后描述如何使用分布式计算模式语言，设计真实世界中仓库管理流程控制系统；最后重点讲述分布式计算模式语言，该语言陈述了创建分布式系统相关的技术主题。作译者介绍Fralk Buschmann是德国慕尼黑西门子技术公司的高级总工程师。他的研究领域包括对象技术、软件架构、产品线、模型驱动软件开发和模式。他在该领域著作甚多，其中最引人注目的便是POSA系列的前两卷[POSA1][POSA2]和最近的两卷：本书和[POSA5]。Frank在1992年至1996年曾是ANSIC++标准化委员会X3J16的成员，于1996年发起了首届EuroPLoP会议，与人合作汇编了数本模式方面的书籍[PLoPD3][SFHBS06]，现任Wiley软件设计模式丛书的主编。译者: 肖鹏 肖鹏，ThoughtWorks高级咨询师，敏捷过程教练，面向对象分析和面向对象设计专家。拥有6年以上软件开发实践经验，多次担任国内大中型企业敏捷流程改进、面向对象分析和面向对象设计咨询和培训。他长期关注于设计模式、架构模式、敏捷软件开发等领域，并致力于软件开发最佳实践的推广和应用。同作者作品Visual Studio 2005技术大全(使.NET程序员事半功倍的利器) Visual Studio 技术大全（微软技术大师力作） 面向模式的软件架构.第4卷,分布式计算的模式语言(经典POSA系列的第4卷)

架构