什么是软件架构图

㈠ 什么是结构图

结构图是指以模块的调用关系为线索，用自上而下的连线表示调用关系并注明参数传递的方向和内容，从宏观上反映软件层次结构的图形，结构图分建筑图和组织结构图。

组织结构图（Organization Chart）又称组织架构图。是最常见的表 现雇员、职称和群体关系的一种图表，它形象地反映了组织内各机构、岗 位上下左右相互之间的关系。组织结构图是组织结构的直观反映，也是对 该组织功能的一种侧面诠释。

(1)什么是软件架构图扩展阅读：

一般建筑的结构平面图，均应有各层结构平面图及屋面结构平面图。具体内容为：

1）绘出定位轴线及梁、柱、承重墙，抗震构造柱等定位尺寸，并注明其编号和楼层标高；

2）注明预制板的跨度方向、板号、数量及板底标高，标出预留洞大小及位置；预制梁、洞口过梁的位置和型号、梁底标高；

3）现浇板应注明板厚、板面标高、配筋（亦可另绘放大比例的配筋图，必要时应将现浇楼面模板图和配筋图分别绘制），标高或板厚变化处绘局部剖面，有预留孔、埋件、已定设备基础时应示出规格与位置，洞边加强措施，当预留孔、埋件、设备基础复杂时亦可放大另绘；

4）有圈梁时应注明位置、编号、标高，可用小比例绘制单线平面示意图。

5）楼梯间可绘斜线注明编号与所在详图号；

6）电梯间应绘制机房结构平面布置（楼面与顶面）图，注明梁板编号、板的厚度与配筋、预留洞大小与位置、板面标高及吊钩平面位置与详图；

7）屋面结构平面布置图内容与楼层平面类同，当结构找坡时应标注屋面板的坡度、坡向、坡向起终点处的板面标高，当屋面上有留洞或其他设施时应绘出其位置、尺寸与详图，女儿墙或女儿墙构造柱的位置、编号及详图；

8）当选用标准图中节点或另绘节点构造详图时，应在平面图中注明详图索引号。

㈡ 什么是系统架构

问题一：“系统架构”是什么意思？都有哪些架构？ JDE属于分布式架构,人和系统恕我孤陋寡闻,没听过阿

问题二：软件架构和系统架构到底是什？生活中有哪些东西可以比喻？ 软件架构是指软件整体的组织结构，是在较高层次上的分析设计，体现了软件系统总体的规化、决策、控制等。
系统架构包括软件、硬件、网络等多方面的组织结构。架构是分析设计的高层阶段，不会涉及到技术实现的细节，是蓝图，是规化，是决策。
现实生活中可比喻为高楼大厦的设计图纸。

问题三：什么是架构 架构一般指软件架构

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

问题四：什么是系统工程师、系统架构工程师？ 系统工程师资格就是具备较高专业技术水平，能够分析商业需求，并使用各种系统平台和服务器软件来设计并实现商务解决方案的基础架构。
系统架构师是大型项目的技术领导者,总体负责系统的体系结构设计和指导。

问题五：什么是分布式系统架构 ke./view/9914海9 网络

问题六：架构，系统架构，技术架构，应用架构都是什么关系 架构
是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。
系统架构
是对已确定的需求的技术实现构架、作好规划,运用成套、完整的工具,在规划的步骤下去完成任务。
技术架构
通过合理的完善的评估途径对组织、网络、程序的组成框架、模型进行评价和分析,并对其进行完善。
应用架构
以架构图的方式描述系统的组成和框架，一般从系统功能和系统技术层次两个架构视角进行设计。

问题七：请问系统架构设计师的职责是什么 系统架构师的职责主要有如下4条：
1、确认需求
在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。
2、系统分解
依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。
软件架构师的功力基本体现于此，这是一项相对复杂的工作。
3、技术选型
架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。
Web Server运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是Mysql？需要不需要采用MVC或者Spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？类似的工作，都需要在这个阶段提出，并进行评估。
架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。
4、制定技术规格说明
架构师在项目开发过程中，是技术权威。他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照它的架构意图去实现各项功能。
架构师不仅要保持与开发者的沟通，也需要与项目经理、需求分析员，甚至与最终用户保持沟通。所以，对于架构师来讲，不仅有技术方面的要求，还有人际交流方面的要求。

问题八：系统架构师是干什么的啊？ 属于项目的高级分析、规划、管理人员
系统架构师（System Architecture）系统架构师是负责设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单等等。
全文见网络
ke./view/905154?fr=ala0_1_1

问题九：系统架构师的角 *** 别 系统构架师与产品经理的关系及区别产品经理通常是指负责产品设计的“专人”。一个优秀的理想的产品经理，应同时具备较高的商业素质和较强的技术背景。产品经理要有深厚的领域经验，也就是说，对该软件系统要应用到的业务领域非常之熟悉。比如，开发房地产销售软件的产品经理，应该对房地产公司的标准销售流程了如指掌，甚至比大多数销售人员还要清楚。如果开发的是通用产品，他/她还具备对市场、潜在客户需求的深刻洞察力。 那么，系统架构师与产品经理有什么不同呢？我们不应该把二者混为一谈，这是不少论述和实践常犯的错误。我看来，如果把开发软件比作摄制电影，产品经理之于系统架构师，就正像编剧之于导演。产品经理虽然要有一定技术背景，但仍应属于“商业人士（business people）”，而系统架构师则肯定是一个技术专家。二者看待问题的立场、角度和出发点完全不同。系统构架师与项目经理的关系及区别软件项目经理是指对项目控制/管理，关注项目本身的进度、质量，分配、调动、协调、管理好人、财、物等资源的负责人。对于软件项目经理来讲，包括项目计划、进度跟踪/监控、质量保证、配置/发布/版本/变更管理、人员绩效评估等方面。优秀的项目经理需要的素质，并不仅在于会使用几种软件或是了解若干抽象的方法论原则，更重要的在于从大量项目实践中获得的宝贵经验，以及交流、协调、激励的能力，甚至还应具备某种个性魅力或领袖气质（Chari *** a）。由此可见，项目经理和系统架构师在职责上有很大差异。混同这两个角色，往往也会导致低效、无序的开发。特别是，从性格因素上讲，单纯的技术人员倾向于忽视“人”的因素，而这正是管理活动的一个主要方面。另外，就像战争中的空军掩护（Air Cover）一样，专职的项目经理能够应付开发过程中大量的偶发事件和杂务，对于一个规模稍大的项目，这些杂务本身就能占用一个全职工作者的几乎全部时间。在一个项目中，推动项目发展的是系统构架师，而不是项目经理。项目经理的职责只是配合系统构架师，提供各个方面的支持。主要职责是与内外部沟通和管理资源（包括人）。系统构架师提出系统的总体构架，给出开发指导。一个项目中，项目经理的角色什么？如果他即使管理人员又是设计人员，则必须比别人强，能够有让别人服的东西。如果他只是项目管理人员，系统构架师有专门人员，就可以不用精通或者说了解 it 各个方面的知识，如果了解更好。另外，如果在一个项目没有人在技术构架上和开发指导上负全部责任，而是每个人都负责一快的架构、分析、设计、代码和实施等，最后肯定会失去管理。系统构架师与系统分析员的关系及区别系统分析员（System *** yst）是指对系统开发中进行分析、设计和领导实施的人。一般意思上讲，系统分析员的水平将影响系统开发的质量，甚至成败。但在一个完善的系统开发队伍中，还需要有业务专家，技术专家和其他辅助人员。所以，系统分析员只是其中的角色之一。但我国许多的 IT 公司，一般只有系统分析员而没有技术专家。系统分析员固然是对特定系统进行分析、设计。所以他的任务、目标是明确的。他只是去执行任务，完成系统的最终设计。系统架构师应该和系统分析员分开，但架构师必须具备系统分析员的所有能力，同时还应该具备设计员所没有的很多能力。 系统架构师是指导、检督系统分析员的工作，要求系统分析员按什么标准，什么工具，什么模式，什么技术去设计系统的。同时，系统架构师应该对系统分析员所提出的问题，碰到的难题及时地提出解决的方法。并检查、评审系统分析员的工作。

㈢ 软件体系结构图怎么画啊

软件体系结构参考图如下：

正如上面提到的，不同的受众，比如用户、客户、开发人员、测试人员、运维人员，需要从各自工作的角度去理解和使用架构。所以回答这个问题，需要首先了解这幅架构图画出来是给谁看，你想从那个维度去入手。
确定了这个问题之后，再来了解架构视图有哪些维度和组成要素：
1. 架构视图
最经典的当属4+1视图：

• 逻辑视图
  
• 开发视图
  
• 过程视图
  
• 物理视图
  
• 场景视图
  

4+1视图提出后，业界也有其它的观点提出，诸如SEI(模块视图、组建和连接件视图、分配视图)、西门子4种视图（概念、模块、代码、执行视图）、以及RM-ODP(企业视图、信息视图、计算视图、工程师图）等。
常见的视图除了上述4+1视图外还包括：数据视图、安全视图、实现视图等。

2. 了解架构视图的四要素

• 图示化主要元素和元素之间的关系
  
• 具有明确的图例、定义和说明元素
  
• 每个元素具备明确的接口和行为规范
  
• 设计原理和设计决策的信息
  

3. 简单说一下几个视图针对的角色和维度：
逻辑视图一般针对客户、用户、业务人员、开发组织，主要从系统的功能元素、以及它们的接口、职责、交互维度入手。主要元素包括系统、子系统、功能模块、子功能模块、接口等。

开发视图一般针对开发和测试相关人员，主要描述系统如何开发实现；主要元素包括描述系统的分层、分区、框架、系统通用服务、业务通用服务、类和接口、系统平台和大基础框架。用途是知道开发设计和实现。

物理视图一般针对系统运维人员、集成人员，它是系统逻辑组件到物理节点的映射，节点与节点间的物理网络配置等，主要关注非功能性需求，诸如性能（吞吐量）、可伸缩性、可靠性，可用性等，从而得出相关的物理部署结构图。

㈣ 软件系统结构图怎么画

问题一：软件系统架构图 用visio画 怎么新建？ 5分 朋友，采用visio画软件系统架构图一般是选择其中的包图，非常简单。

问题二：系统架构图怎么画的? 系统架构常用软件:
1. MindManager 画思维导图
2. Microsoft Office Visio 内有uml建模工具, 上图也可以用此软件画出来
3. Axure RP Pro 可以用来画产品原型
各软件怎么用还是要实践中去熟悉

问题三：怎么画此图的软件结构图？ 5分 你自己下载这个工具吧
Diagram Designer
直接网络搜索这个。。。

问题四：visio软件系统架构图怎么画 1 新建 选择模板
2 插入需要的形状
3 双击形状，填写内容
4 插入动态连接线，连接上下级
5 调整总体结构
6 完成

问题五：软件体系结构图怎么画 uml图吗。。。。

问题六：怎么在word中画功能结构图？ 首先,想好结构布局图,然后选择工具栏上的插入选择形状,选择直线.
在文本需要的地方画一条合适的直线,然后将这条直线复制多个,如复制三个,共四个,
接着选择一根直线,利用键盘上的上下左右方向按钮对直线位置调整,摆放整齐.
然后再选择选择工具栏上的插入选择形状,选择流程图里的方形.
在文本合适的地方画上一个大小合适的长方形图.然后再复制三个.
接着选择四边形图一个一个利用键盘上的上下左右方向按钮对直线位置调整,摆放整齐.
然后选择文本档,添加文字或编辑文字内容即可.

问题七：什么是系统结构图？？ 系统结构图是对软件系统结构的总体设计的图形显示，在需求分析阶段,已经从系统开发的角度出发,把系统按功能逐次分割成层次结构,使每一部分完成简单的功能且各个部分之间又保持一定的联系,这就是功能设计.在设计阶段,基于这个功能的层次结构把各个部分组合起来成为系统.(3)处理方式设计:确定为实现软件系统的功能需求所必需的算法,评估算法的性能.确定为满足软件系统的性能饥求所必需的算法和模块间的控制方式(性能设计).确定外部信号的接收发送形式.
用Microsoft Visio Trial来画系统结构图

问题八：win8系统用什么软件画组织结构图 可以用Edraw max，专业的组织结构图软件，可以插入照片，可以绘制复杂的组织结构图。能够导出PDF，jpg，PPT，word，png等多种格式，方便分享和打印。

问题九：网络系统架构图 用什么画（什么软件） visio或亿图都可以

㈤ 软件工程中软件结构图和层次图的异同

两者之间没有区别。两者指的均是软件构架，为软件系统的草图。

软件工程中软件结构图和层次图均是为了反映软件系统中组件之间相互关系和约束的体系结构设计图，属于一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。

软件结构图（又被叫做软件构架）一般通过分层次或分时间段等方式说明体系结构的各个组成部分的组合关系。描述的对象是直接构成系统的抽象组件，各个组件之间的连接则明确和相对细致地描述组件之间的通讯关系。

(5)什么是软件架构图扩展阅读：

其他介绍：

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

通过一个软件结构图建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。

㈥ 什么是软件架构有没有具体解释

软件架构
软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口_(计算机科学)来实现。

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

软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。

在“软件构架简介”中，David GArlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。”[GS93]

但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”[IEEE98]。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。

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

从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。

是一般而言，软件系统的架构（ArchitECture）有两个要素：

·它是一个软件系统从整体到部分的最高层次的划分。

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

详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（TASk-flow）。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。

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

在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。

历史
早在1960年代，诸如E·W·戴克斯特拉就已经涉及软件架构这个概念了。自1990年代以来，部分由于在 Rational Software Corporation 和MiCROSoft内部的相关活动，软件架构这个概念开始越来越流行起来。

卡内基梅隆大学和加州大学埃尔文分校在这个领域作了很多研究。卡内基·梅隆大学的Mary Shaw和David Garlan于1996年写了一本叫做 Software Architecture perspective on an emerging DIscipline的书，提出了软件架构中的很多概念，例如软件组件、连接器、风格等等。 加州大学埃尔文分校的软件研究院所做的工作则主要集中于架构风格、架构描述语言以及动态架构。

计算机软件的历史开始于五十年代，历史非常短暂，而相比之下建筑工程则从石器时代就开始了，人类在几千年的建筑设计实践中积累了大量的经验和教训。建筑设计基本上包含两点，一是建筑风格，二是建筑模式。独特的建筑风格和恰当选择的建筑模式，可以使一个独一无二。

下面的照片显示了中美洲古代玛雅建筑，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、一个物理架构的例子

·系统架构、系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。

系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。

此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。

首先，一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。

其次，进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。

根据作者的经验，一个基于数据库的系统架构，有多少个数据表，就会有多少页的架构设计文档。比如一个中等的数据库应用系统通常含有一百个左右的数据表，这样的一个系统设计通常需要有一百页左右的架构设计文档。

构架描述

为了讨论和分析软件构架，必须首先定义构架表示方式，即描述构架重要方面的方式。在 Rational Unified Process 中，软件构架文档记录有这种描述。

构架视图

我们决定以多种构架视图来表示软件构架。每种构架视图针对于开发流程中的涉众（例如最终用户、设计人员、管理人员、系统工程师、维护人员等）所关注的特定方面。

构架视图显示了软件构架如何分解为构件，以及构件如何由连接器连接来产生有用的形式 [PW92]，由此记录主要的结构设计决策。这些设计决策必须基于需求以及功能、补充和其他方面的约束。而这些决策又会在较低层次上为需求和将来的设计决策施加进一步的约束。

典型的构架视图集

构架由许多不同的构架视图来表示，这些视图本质上是以图形方式来摘要说明“在构架方面具有重要意义”的模型元素。在 Rational Unified Process 中，您将从一个典型的视图集开始，该视图集称为“4+1 视图模型”[KRU95]。它包括：

用例视图：包括用例和场景，这些用例和场景包括在构架方面具有重要意义的行为、类或技术风险。它是用例模型的子集。
逻辑视图：包括最重要的设计类、从这些设计类到包和子系统的组织形式，以及从这些包和子系统到层的组织形式。它还包括一些用例实现。它是设计模型的子集。
实施视图：包括实施模型及其从模块到包和层的组织形式的概览。 同时还描述了将逻辑视图中的包和类向实施视图中的包和模块分配的情况。它是实施模型的子集。
进程视图：包括所涉及任务（进程和线程）的描述，它们的交互和配置，以及将设计对象和类向任务的分配情况。只有在系统具有很高程度的并行时，才需要该视图。在 Rational Unified Process 中，它是设计模型的子集。
配置视图：包括对最典型的平台配置的各种物理节点的描述以及将任务（来自进程视图）向物理节点分配的情况。只有在分布式系统中才需要该视图。它是部署模型的一个子集。
构架视图记录在软件构架文档中。您可以构建其他视图来表达需要特别关注的不同方面：用户界面视图、安全视图、数据视图等等。对于简单系统，可以省略 4+1 视图模型中的一些视图。

构架重点

虽然以上视图可以表示系统的整体设计，但构架只同以下几个具体方面相关：

模型的结构，即组织模式，例如分层。
基本元素，即关键用例、主类、常用机制等，它们与模型中的各元素相对。
几个关键场景，它们表示了整个系统的主要控制流程。
记录模块度、可选特征、产品线状况的服务。

构架视图在本质上是整体设计的抽象或简化，它们通过舍弃具体细节来突出重要的特征。在考虑以下方面时，这些特征非常重要：

系统演进，即进入下一个开发周期。
在产品线环境下复用构架或构架的一部分。
评估补充质量，例如性能、可用性、可移植性和安全性。
向团队或分包商分配开发工作。
决定是否包括市售构件。
插入范围更广的系统。

构架模式

构架模式是解决复发构架问题的现成形式。构架框架或构架基础设施（中间件）是可以在其上构建某种构架的构件集。许多主要的构架困难应在框架或基础设施中进行解决，而且通常针对于特定的领域：命令和控制、MIS、控制系统等等。

构架模式示例

[BUS96] 根据构架模式最适用的系统的特征将其分类，其中一个类别处理更普遍的结构问题。下表显示了 [BUS96] 中所提供的类别和这些类别所包含的模式。

类别 模式
结构 层
管道和过滤器
黑板
分布式系统 代理
交互系统 模型-视图-控制器
表示-抽象-控制
自适应系统 反射
微核

软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。

在“软件构架简介”中，David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。”[GS93]

但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”[IEEE98]。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。

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

为阐明其含义，下面将详述其中的两个；完整说明请参见 [BUS96]。模式以下列广泛使用的形式来表示：

模式名
环境
问题
影响，描述应考虑的不同问题方面
解决方案
基本原理
结果环境
示例
模式名
层

环境
需要进行结构分解的大系统。

问题
必须处理不同抽象层次的问题的系统。例如：硬件控制问题、常见服务问题和针对于不同领域的问题。最好不要编写垂直构件来处理所有抽象层次的问题。否则要在不同的构件中多次处理相同的问题（可能会不一致）。

影响

系统的某些部分应当是可替换的
构件中的变化不应波动
相似的责任应归为一组
构件大小 -- 复杂构件可能要进行分解
解决办法
将系统分成构件组，并使构件组形成层叠结构。使上层只使用下层（决不使用上层）提供的服务。尽量不使用非紧邻下层提供的服务（不跳层使用服务，除非中间层只添加通过构件）。

示例：

1. 通用层

严格的分层构架规定设计元素（类、构件、包、子系统）只能使用下层提供的服务， 服务可以包括事件处理、错误处理、数据库访问等等。 相对于记录在底层的原始操作系统级调用，它包括更明显的机制。

2. 业务系统层

上图显示了另一个分层示例，其中有垂直特定应用层、水平层和基础设施层。注意：此处的目标是采用非常短的业务“烟囱”并实现各种应用程序间的通用性。 否则，就可能有多个人解决同一问题，从而导致潜在的分歧。

有关该模式的深入讨论，请参见指南：分层。

模式名
黑板

环境
没有解决问题的确定方法（算法）或方法不可行的领域。例如 AI 系统、语音识别和监视系统。

问题
多个问题解决顾问（知识顾问）必须通过协作来解决他们无法单独解决的问题。各顾问的工作结果必须可以供所有其他顾问访问，使他们可以评估自己是否可以参与解决方案的查找并发布其工作结果。

影响

知识顾问参与解决问题的顺序不是确定的，这可能取决于问题解决策略

不同顾问的输入（结果或部分解决方案）可能有不同的表示方式

各顾问并不直接知道对方的存在，但可以评估对方发布的工作

解决办法
多名知识顾问都可访问一个称为“黑板”的共享数据库。黑板提供监测和更新其内容的接口。控制模块/对象激活遵循某种策略的顾问。激活后，顾问查看黑板，以确定它是否能参与解决问题。如果顾问决定它可以参与，控制对象就可以允许顾问将其部分（或最终）解决方案放置于黑板上。

示例：

以上显示了使用 UML 建模的结构或静态视图。 它将成为参数化协作的一部分，然后会绑定到实参上对模式进行实例化。

构架风格
软件构架（或仅是构架视图）可以具有名为构架风格的属性，该属性减少了可选的形式，并使构架具有一定程度的一致性。样式可以通过一组模式或通过选择特定构件或连接器作为基本构件来定义。对给定系统，某些样式可作为构架描述的一部分记录在构架风格指南（Rational Unified Process 中设计指南文档的一部分）中。样式在构架的可理解性与完整性方面起着主要的作用。

构架设计图
构架视图的图形描述称为构架设计图。对于以上描述的各种视图，设计图由以下统一建模语言图组成 [UML99]：

逻辑视图：类图、状态机和对象图。
进程视图：类图与对象图（包括任务 - 进程与线程）。
实施视图：构件图。
部署视图：配置图。
用例视图：用例图描述用例、主角和普通设计类；顺序图描述设计对象及其协作关系。
构架设计流程
在 Rational Unified Process 中，构架主要是分析设计工作流程的结果。当项目再次进行此工作流程时，构架将在一次又一次迭代中不断演化、改进、精炼。由于每次迭代都包括集成和测试，所以在交付产品时，构架就相当强壮了。构架是精化阶段各次迭代的重点，构架的基线通常会在此阶段结束时确定。

架构师

软体设计师中有一些技术水平较高、经验较为丰富的人，他们需要承担软件系统的架构设计，也就是需要设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定的作出。

这样的人就是所谓的架构师（Architect）。在很多公司中，架构师不是一个专门的和正式的职务。通常在一个开发小组中，最有经验的程序员会负责一些架构方面的工作。在一个部门中，最有经验的项目经理会负责一些架构方面的工作。

但是，越来越多的公司体认到架构工作的重要性，并且在不同的组织层次上设置专门的架构师位置，由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。

㈦ 软件结构图的作用是什么有哪些构成成分

软件结构图是进行软件结构设计的一种工具，是用来描述软件结构的图形工具，这里有张软件结构图，直观启建你可以看看http://www.studycity.cn/kj/X520400004/course/chapter4/re/
表示软件模块的方框可由箭头或直线联接，按照惯例软件结构图中上方的方框调用下方的，因此用直线仍然可分清调用关系。
带注视的箭头（该图中的红色箭头）表示模块调用种来回传递的信息。
菱形代表一个判定，如果为真则调用左边的模块，假则调用右边的模块。
还有一种弧形箭头这图中没有，它画在上层模块与代表调用关系的箭头或直线的联接处，穿越每条代表调用关系的箭头或直线，它表示循环调用下层模块。

㈧ 软件结构图的介绍

软件结构图是为了反映软件系统中组件之间相互关系和约束的体系结构设计图，称为软件体系结构图更为合适，一般通过分层次或分时间段等方式说明体系结构的各个组成部分的组合关系。在结构化设计方法中，软件结构图主要分为变换型软件结构图和事务型软件结构图两种。