系统分析师的工作内容，依阶段划分大致可分为下述几个阶段：

系统分析：分析现行系统:确定系统的功能需求;确定系统的资源:保护及绩效需求，发展系统架构确定使用单位将面临的环境及组织变迁。

初步设计：划分作业子系统．拟定子系统的输入、输出、接口及作业处理流程:子系统人工操作规格:逻辑质料库设计:开列系统软、硬件规格。

细步设计：设计实体数据库:设计人工操作程序;设计文件表格及输出、入格式;拟订程序规格及组步流程:确定公用例程与共享程序。

系统测试：根据分析阶段所订定的各种功能．加以测试，错误资料收集与分析。

资料转换：整理及汇编文件．指派工作人员及进行训练．进行资料转换。

系统维护：更正系统内潜伏的错误:因适应环境的改变而做适度的调整。

一个机构的分析师因工作性质的关系，一方面需要与作业单位有关人员讨论系统需求，另一方面亦要随时了解程序设计人员工作进度，以掌握系统开发进度．因而时常往来于不同的单位间，但是大多数的时间均为独自作业:不希望有太多的外在干扰．因此，通常都会有固定而较幽静的办公处所。

软件架构师的主要任务不是从事具体的软件程序的编写，而是从事更高层次的开发构架工作。他必须对开发技术非常了解，并且需要有良好的组织管理能力。可以这样说，一个架构师工作的好坏决定了整个软件开发项目的成败。

⒈领导与协调整个项目中的技术活动（分析、设计和实施等）。

⒉推动主要的技术决策，并最终表达为软件构架。

⒊确定和文档化系统的相对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”。

⒋确定设计元素的分组以及这些主要分组之间的接口。

⒌为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效的传达和贯彻。

⒍理解、评价并接收系统需求。

⒎评价和确认软件架构的实现 专业技能。

什么是系统架构设计?

简单一点，系统架构设计就是一个系统的草图，描述了构成系统的抽象组件，以及各个组件之间的是如何进行通讯的，这些组件在实现过程中可以被细化为实际的组件比如类或者对象。在面向对象领域中，组件之间的联通通常面向于接口实现的。

是人们对一个结构内的元素及元素间关系的一种主观映射的产物。架构设计是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。

“架构”一词最早来自建筑学，原意为建筑物设计和建造的艺术。但是在软件工程领域，软件架构不是一个新名词，只是在早期的著作中人们将软件架构称为软件体系架构。这就是架构的概念。所谓架构，就是人们对一个结构内的元素及元素间关系的一种主观影射的产物。

无论何种系统架构应用领域，目的都是一样的，即完整地、高一致性的、平衡各种利弊的、有技术和市场前瞻性的设计系统和实施系统。

扩展资料

系统架构的主要任务是界定系统级的功能与非功能要求、规划要设计的整体系统的特征、规划并设计实现系统级的各项要求的手段，同时利用各种学科技术完成子系统的结构构建。

在系统架构中，由于对软件越来越深入的依赖，软件架构的任务也体现出重要的作用。而且系统架构与软件架构是紧密联系和相互依赖的。

1997年，Eberhadrt Rechtin 与MarkW Maier 在其论著中，为计算机科学总结了系统架构方面的实践成果，从而奠定了系统科学和系统架构在计算机科学中的基石。

参考资料：百度百科：系统架构设计

软件行业里常说的 “架构”，究竟是什么东西

通常所说的MVC和MVVM都是软件架构，这只是软件开发的架构，这些都是一种抽象模式，是人为想象出来的一种开发规范，是软件开发中的一门艺术。

简介

定义

软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。

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

目标

正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：

可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。

安全性（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。

可伸缩性（SCAlable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。

可定制化（CuSTomizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。

可扩展性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展。

可维护性（MAIntainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费。

客户体验（Customer Experience）。软件系统必须易于使用。

市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。

历史

编辑

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

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

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

软件与人类的关系是架构师必须面对的核心问题，也是自从软件进入历史舞台之后就出现的问题。与此类似地，自从有了建筑以来，建筑与人类的关系就一直是建筑设计师必须面对的核心问题。英国首相丘吉尔说，我们构造建筑物，然后建筑物构造我们（We shape our buildings, and afterwards our buildings shape us）。英国下议院的会议厅较狭窄，无法使所有的下议院议员面向同一个方向入座，而必须分成两侧入座。丘吉尔认为，议员们入座的时候自然会选择与自己政见相同的人同时入座，而这就是英国政党制的起源。Party这个词的原意就是"方"、"面"。政党起源的关键就是建筑物对人的影响。

在软件设计界曾经有很多人认为功能是最为重要的，形式必须服从功能。与此类似地，在建筑学界，现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能（FORMs follows function）。

几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。最为著名的，当然就是模式理论和XP理论。

相互关系

编辑

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

软件架构是指在一定的设计原则基础上，从不同角度对组成系统的各部分进行搭配和安排，形成系统的多个结构而组成架构，它包括该系统的各个组件，组件的外部可见属性及组件之间的相互关系。组件的外部可见属性是指其他组件对该组件所做的假设。

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

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

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

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

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

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

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

种类

编辑

根据我们关注的角度不同，可以将架构分成三种：

逻辑架构

软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。

比如下面就是笔者亲身经历过的一个软件系统的逻辑架构图

图2、一个逻辑架构的例子

从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。每一个层次都含有多个逻辑元件。比如WEB服务器层次中有HTML服务元件、Session服务元件、安全服务元件、系统管理元件等。

物理架构

软件元件是怎样放到硬件上的。

比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。

系统架构

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

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

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

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

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

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

视图

编辑

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

构架视图显示了软件构架如何分解为构件，以及构件如何由连接器连接来产生有用的形式 [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 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。

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

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

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

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

影响

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

示例：

1. 通用层

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

2. 业务系统层

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

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

模式名黑板

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

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

影响

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

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

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

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

示例：

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

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

逻辑视图：类图、状态机和对象图。进程视图：类图与对象图（包括任务 - 进程与线程）。实施视图：构件图。部署视图：配置图。

设计

编辑

描述语言

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

架构描述语言(ADL)用于描述软件的体系架构。已有多种架构描述语言，如Wright (由卡内基梅隆大学开发)，Acme (由卡内基梅隆大学开发)，C2 (由UCI开发)， Darwin (由伦敦帝国学院开发)。ADL的基本构成包括组件、连接器和配置。

视图

构架

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

逻辑视图：类图、状态图和对象图。

进程视图：类图与对象图（包括任务 - 进程与线程）。

实施视图：构件图。

部署视图：配置图。

用例视图：用例图描述用例、主角和普通设计类；顺序图描述设计对象及其协作关系。

流程

在 Rational Unified Process 中，构架主要是分析设计工作流程的结果。当项目再次进行此工作流程时，构架将在一次又一次迭代中不断演化、改进、精炼。由于每次迭代都包括集成和测试，所以在交付产品时，构架就相当强壮了。构架是精化阶段各次迭代的重点，构架的基线通常会在此阶段结束时确定。

架构师

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

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

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

[1]

实践

编辑

实践中的理解

软件架构是对软件系统运行时元素的抽象，软件系统可能有很多层抽象，或由多重业务流程所组成，每层抽象或每个业务流程都有自己的软件架构。

软件架构是平衡的艺术。

软件系统架构师必修内容是什么？

对于任何一个软件开发人员来说，架构师都是一个令人向往的角色。就连世界首富比尔盖茨在2000年卸任公司CEO的同时，也担任了微软公司的荣誉角色“首席软件架构师”，可见“架构师”这一称谓的吸引力。架构师是公司的“金领”，有着非常高的收入，很少需要考虑生存的问题，从而有更多的精力思考关键技术问题，形成“强者愈强”的良性循环。部分优秀的开发人员在工作了一定时间后，就要开始考虑自己的未来到底向哪个方向发展。如果开发人员的沟通能力强过技术能力，在补充一定的项目管理知识后，可以向技术管理的方向转型。如果其对技术一直很感兴趣，而沟通能力也不弱，则可以试着进一步加强技术修养，以期向架构师的方向发展，最终“修成正果”。

那么，到底什么是架构师呢？所谓的架构师，应该是一个技术企业的最高技术决策者。他主要负责公司软件产品或软件项目的技术路线与技术框架的制订。好的架构师都是善良的独裁者，具有很强的技术、良好的写作能力、良好的口头表达能力，能够在各个层次进行沟通。从开发人员到架构师的成长应该是阶梯式的，一般来讲开发人员在刚刚开始工作时只能开发简单的独立软件模块，慢慢的随着经验的增长，他开始接触一些相互之间有信息传递的模块，而后来，他会发现自己接到的开发任务已经不是一个独立的单体，这些任务由一些专门的软件部分组成，可能包含数据库，工作流引擎，消息服务等等各种功能模块，可能分布在不同的服务器上，所有的部分协同起来，完成软件功能。而这时候，体系结构的好坏将直接决定了系统的性能和可扩展性，而就在这时候，这名优秀的开发人员也开始思考架构师应该思考的问题了，或者说，他向成长为架构师的道路迈出了一大步。

什么是架构师最具价值的技能呢？就是要了解不同的知识，做一个“杂家”或者说“博学家”。当然，如果你的数据库技术非常棒，或者你在工作流引擎方面具有不可超越的专家知识，那也是很不错的。好的架构师有好多都是从专家成长过来的。但是，这不是架构师应该做的事情，架构师应该做的是了解所有的东西，既了解技术的宏观面，又了解技术的细节。真正的架构师不仅仅要了解软件，也要了解硬件，在关键的部位使用合适的硬件来取代软件，可以成倍甚至成百倍的提高整个系统的效率。下面我将会以互联网行业对的架构师的要求为例，向大家讲解作为架构师应该具备的知识。

互联网行业是当前最激动人心的行业之一，很多的创新都来自于这个行业，而每一个大型的网站如Google，Yahoo，Myspace等都需要解决一个非常复杂的问题，就是网站的分布式向外扩展(Scale Out)的问题。解决这个问题，需要最优秀的架构师对业务进行剖析，利用软硬件将网站进行重构，甚至根据业务研发相应的分布式技术，解决网站复杂的分布式计算的问题。如果你想在这个行业中成为一名架构师的话，需要至少掌握网络知识，硬件，软件，网站优化等方方面面的知识：

网络知识

当前的软件已经绝对不是那种仅仅跑在一台单机上的孤立应用了。不仅仅是在互联网行业，任何一个行业的软件，都要求其具有网络功能。因此，网络知识是架构师必备的知识。我们所说的网络知识，不仅仅包括TCP/IP，http等互联网行业常用的软件协议，也包括网络规划，甚至更具体的说，根据网站应用所处的地理环境进行网络规划。比如人们常说：“这世界上最远的距离不是生与死的距离，而是电信到网通的距离”（笑）如果应用是建立在中国的，就要考虑电信用户和网通用户访问网站的速度应该都比较快才可以。这时候的解决方案可能有多种，比如采用CDN（Content Delivery Network内容分发网络）使得网站的内容发布到离用户最近的服务器，又可以采用把服务器放在一些所谓的双线机房中，甚至将几种方案结合起来使用。这些都统统归到网络知识中。做为公司的架构师，要对这些知识都有所了解，才有助于在遇到问题时找到最佳答案。

硬件知识

了解硬件的极限，是架构师的基本功。我见过一些人，他们的眼中软件硬件都是没有极限的，需要资源就申请，系统性能下降了就买更高级的设备。然而，硬件的性能有很大一部分取决于I/O设备。而这些I/O设备依靠的都是机械物理运动，这种运动是有极限的。因此当资源访问量增大到一定的程度时，这种物理运动将成为瓶颈。比如说，在开发网站的过程中，记录访客的状态是一件很重要的事情，一般来说可以使用HttpSession来记录。而HttpSession的存储问题将是一个很大的挑战，尤其是多机共享Session时，将HttpSession存成文件并通过多机共享或网络备份的方式来解决分布式的问题是常用的方案，然而，架构师必须考虑到这种方案是有I/O极限限制的，很难扩展到超过一定规模的大型网络。同时，架构师应该了解目前最近的硬件发展是否对软件系统会造成一定的影响，比如在多核的条件下是否对软件编程有新的要求，是否会对运行在虚拟机和非虚拟机上的程序有影响等等。

软件知识

软件知识所包含的范围就更加广泛了。对于互联网行业来讲，架构师要了解操作系统，数据库，应用服务器等各方面的知识。比如说，如果网站使用的操作系统是Linux，就要了解这个Linux版本的性能与局限性，比如说最多可以存放的单个文件为多大。有的数据库的数据是以单个文件来存放的，虽然我们很少见到数据库中的数据多到不能再放入一条记录的情况，但是作为架构师，请时刻注意，这种可能性是有的。而且如果你有幸在一家高速成长的互联网企业中，而你所负责的应用又没有经过优化的话，可能你会很快见到这种现象。这种现象的发生可能是由于操作系统不支持大文件的原因，也可能是数据库不支持大文件。不论如何，架构师应该在这种现象发生之前就把一切都准备好。对数据库中表的拆分是架构师应该遇到的另外一个困难。一般来说增加应用服务器比较简单而增加数据库服务器则是比较复杂的问题，如果一个站点由多个数据库支持，架构师需要考虑如何在保证数据一致的情况下，让多个数据库分担压力。有些解决方案是将数据库的读写分开，使得大多数的查询sql不经过核心数据库，而只是访问数据库的副本，但事实上，这种方式也只能维护规模不大的网站。对于大型的网站来说，把业务分散到不同的数据库中，只共享必要的数据，才是合理的提高网站扩展性的解决方案。

其他知识

作为系统架构师，可能还需要对分布式系统，负载均衡，网络安全，数据监控等等各方面都有所了解。不仅仅是了解理论知识，也要对相关的产品和业界进展有一定的认识。比如说做负载均衡最好的产品是那种。目前最常用的备份策略是什么，有什么缺点。如何使用缓存，如何做好日志分析等等。

刚刚谈到的是架构师需要掌握的知识，然而，冰冻三尺非一日之寒。这个过程需要我们慢慢的积累。如果你已经进入到公司进行软件开发，请时刻关注你所开发软件的性能与可扩展性，而不仅仅局限在功能上，时刻想着任何一个简单的问题：我开发的模块如果放在多人并发的环境下会怎样，慢慢的就会有所心得。如果你还是一个在校学生，不要想着自己离架构师这个职位还很遥远。要知道，成为架构师的修炼之路是很长的，甚至可以说是终身的，因此早点进入学习状态，不断修炼自己。在学校期间学好离散数学，数据结构，操作系统，编译原理，体系结构，数据库原理等关键课程，并积极寻找机会到外面实习，增长自己的工作经验。如果有机会去到一些技术主导的公司中工作，就一定不要放弃这种机会，慢慢就会成长起来。最重要的，你会养成关注技术，勤于思考的好习惯。当有一天你发现自己对任何技术难题都可以一眼看到其本质，并能够将其分解为一个个可轻松解决的模块，你会由衷的感觉到知识给你带来的快乐，或许那一天，你已经是一个架构师了。

有没有全国性的,国家认可的软件（或系统）架构师资格证书?

目前这个方面的全国性资格认证就是计算机技术与软件专业技术资格（水平）考试的高级几个认证，包括：系统分析师、系统架构设计师、系统规划与管理师。

这几个考试由国家人力资源和社会保障部（原人事部）、工业和信息化部（原信息产业部）领导的国家级考试，其目的是，科学、公正地对全国计算机与软件专业技术人员进行职业资格、专业技术资格认定和专业技术水平测试。

所以从权威性和认可程度上来说都是最高的。

软件开发的架构设计指的是什么？

主要指的是你所开发的总体结构框架，你说实现的那些功能，和功能的结构图什么的。还要写需求分析等等

架构师的职责是什么

系统架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的人。

确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员。

主要着眼于系统的“技术实现”。因此他/她应该是特定的开发平台、语言、工具的大师，对常见应用场景能马上给出最恰当的解决方案，同时要对所属的开发团队有足够的了解，能够评估自己的团队实现特定的功能需求需要的代价。

系统架构师负责设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单等。

扩展资料：

架构师认可需求规格说明书后，架构师已明确用户需求是是什么，这时候便看架构师的分解能力了。

一般分为纵向分解和横向分解，纵向分解是将整个系统分层，从而将整体系统分解成下一级的子系统与组件。横向分解是在系统分解成不同的逻辑层或服务后，对逻辑层进行分块，确定层与层之间的关系。

架构师首先要将代码写的清晰易懂，要能够实现功能，做到没有Bug，这要求架构师必须具备至少熟练掌握一门语言。

参考资料：百度百科-架构师

编写软件架构文档说明，第 1 部分: 什么是软件架构，为什么为软件架构编写文档说明非常重要

引言 软件架构是一门学科，开始于 20 世纪 70 年代。面对不断增加的复杂性和开发复杂实时系统的压力，作为主流系统工程和软件开发的基本构造，软件架构应运而生。 与任何其他久经考验的学科一样，软件架构在诞生之初也面临许多挑战。软件架构表示系统的结构和行为方面。在早期为软件架构编写文档说明时，所使用的文本和图解表达常常不足或者不够精确。所需的是某种一致并得到充分理解的伪（或元）语言，以便将对软件架构进行表示和编写文档说明的不同方式统一起来。在学术研究的推动下，在用于开发有效软件架构文档说明的最佳实践和指导原则方面，工程和计算机科学领域已取得了长足的发展。 在本系列中，您将了解如何编写软件架构文档说明。了解编写文档说明的不同方面：系统上下文、体系结构概述、功能体系结构、操作体系结构和体系结构决策。 在这第一篇文章中，了解软件架构是什么，以及为该学科的不同方面编写文档说明的重要性。 回页首软件架构不同的研究人员已解释了软件架构是什么，并且他们对有关如何最好地表示软件系统的体系结构具有不同的观点。其中没有哪一种解释是错误的；每种解释都具有自己的价值。Bass L 等人抓住了软件架构的本质： “程序或计算系统的软件架构是该系统的结构，包括软件组件、那些组件的外部可见的属性，以及那些组件之间的关系” 。 此定义重点关注由粗粒度的构造（软件组件）所构成的体系结构，可以将这些构造看作是体系结构的构建块。每个软件组件或体系结构构建块具有某些外部可见的属性，这是它向其他体系结构构建块公开的属性。软件组件的内部设计和实现细节不是系统的其他部分所关心的内容，系统的其他部分只是将某个特定组件视为一个黑盒。该黑盒具有某些所公开的属性，其他软件组件可以使用这些属性来共同实现业务或 IT 目标。软件架构在恰当的粒度级别标识体系结构构建块。软件架构还标识那些构建块如何彼此相关，并进行文档记录。 与软件工程相关的体系结构涉及到将单个系统分解或划分为一组可迭代地、渐进地和独立地构造的部分。各个部分彼此具有显式的关系。当组合在一起时，各个部分就形成了系统、企业或应用程序的体系结构。 关于体系结构与设计之间的区别，存在一些混淆。正如 Clements P 等人 所指出的，所有体系结构都是设计，但不是所有设计都是体系结构。需要绑定以使系统满足其功能性和非功能性需求和目标的设计本质上是体系结构。体系结构将体系结构构建块视为黑盒，而设计则处理体系结构构建块的配置、自定义和内部工作。体系结构将软件组件与其外部属性绑定在一起。设计通常要比体系结构松散得多，因为它允许以更多的方式遵守组件的外部属性。设计还考虑用于实现组件内部细节的各种方法。 软件架构可以递归地使用。请考虑一个属于某个系统的软件架构组成部分的软件组件 (C1)。软件架构师将该组件及其应该公开的属性、功能和非功能特性及其与其他软件组件的关系交给系统设计人员。设计人员在分析软件组件 C1 之后，决定将该组件分解为更细粒度的组件（C11、C12 和 C13），其中每个组件提供可重用的功能，这些功能将用于实现 C1 的要求属性。设计人员详细设计了 C11、C12、C13 及其接口。此时，对设计人员来说，C11、C12 和 C13 是体系结构构造（或组件）；其中每个构造具有显式定义的外部接口。对设计人员来说，C11、C12 和 C13 是软件组件 C1 的体系结构，并且这些构造需要进一步的改进和设计，以处理它们的内部实现。通过将大型、复杂的系统划分为小型的构成部分并集中于每个部分，可以递归地使用体系结构。 体系结构使用共同满足行为和质量目标的体系结构构建块将系统绑定在一起。参与者必须能够理解体系结构。因此必须为体系结构编写足够的文档说明，下一个部分将对此进行讨论。 回页首编写体系结构文档说明的重要性参与者：体系结构的下游设计和实现用户。为体系结构的定义、维护和增强功能进行投资的人。向参与者传达您正在构建的系统蓝图的关键是为系统体系结构编写文档说明。软件架构通过不同的视图进行表示——功能、操作、决策等等。没有任何单一视图能够表示整个体系结构。并非所有视图都需要表示特定企业或问题领域的系统体系结构。架构师将确定足以表示所需软件架构范畴的视图集。通过编写不同视图的文档说明并捕获每个部分的开发，您可以向开发团队和业务及 IT 参与者传达有关该不断发展的系统的信息。软件架构具有一组其预期要满足的业务和工程目标。体系结构的文档说明可以向参与者传达这些目标将如何实现。 为体系结构的各个方面编写文档说明，有助于架构师弥补用白板描述解决方案（使用框线图方法）与以对下游设计和实现团队有意义的方式表示解决方案之间众所周知的差距。体系结构的框线图留下了大量有待解释的空间。需要揭示的细节通常隐藏并令人混淆地固守在那些框线背后。 文档说明还可以促进创建切合实际并且可以系统开发（例如遵循标准模板）的体系结构构件。作为一门学科，软件架构是非常成熟的。您可以利用最佳实践和指导原则来为每种视图创建标准模板，以表示体系结构的某个部分或范畴。模板可以为架构师提供有关需要实际产生什么结果的训练。并且模板还可以帮助架构师执行强化训练——超越框线图技术。模板以更具体的术语定义体系结构，因此可直接追溯到解决方案预期要满足的业务和 IT 目标。 由于复杂性，典型的系统开发活动可能要花 18 个月左右的时间。人员缩减在设计和开发团队是司空见惯的事情，从而导致疯狂寻找恰当的替换人员。新的团队成员通常阻碍进度，因为他们必须经历一个学习过程才能成为高效的参与者。具有良好文档说明构件的软件架构可以提供： 对新团队成员进行有关解决方案需求教育的完美平台。有关解决方案如何满足业务和工程目标的说明。特定于问题领域的各种解决方案体系结构视图。对个人将处理的视图的重点关注。请考虑一个名为“体系结构决策”的假想构件（后续部分还将对此进行讨论）。此构件确定要解决的问题，并评估备选机制以解决该问题。此构件对为什么选择某种备选机制而不选择其他机制提供了论证。所确定的问题涉及到访问大型机 IBM DB2?? 表的机制。对两种备选机制进行了评估：使用 IBM MQSeries??，或者使用 NEON Shadow Direct 适配器（一种供应商适配器）。尽管 MQSeries 具备相关功能并且花费较少，但是后者要稳定得多，并且在制定决策时，后者具有一定的优势。现在设想原架构师在一年后离开了该项目，新的架构师粉墨登场。新的架构师质问该团队为什么不使用 IBM MQSeries 来访问大型机 DB2 表。该团队很快返回到体系结构决策构件，并指出了做出该选择的原因。由于 IBM MQSeries 已在过去一年中经测试证明与另一个解决方案不相上下，并且由于其价格较低，于是对该决策进行了重新审视并做出更改以反映更新后的解决方案。 这个示例说明了为什么对系统软件架构的各个方面编写文档说明，是教育新团队成员和在最少的停机情况下帮助他们入门所必需的。 回页首体系结构的不同视图您已经了解到可以通过不同的视图来表示体系结构，每种视图集中于该体系结构的特定方面或范畴。正如 Bass L 等人 所指出的，视图 是由系统参与者编写和读取的体系结构元素或构造以及它们之间关系的内聚集合。 体系结构的功能 视图描述各个体系结构构建块、构建块之间的关系，以及如何将它们分配到体系结构中的不同层。操作 视图（也称为技术视图）描述各个基础结构和中间件软件组件，这些组件为将要部署的功能体系结构组件提供运行时平台。对应用程序架构师而言，功能视图具有第一位的重要性。对基础结构架构师而言，操作视图是要重点关注的视图。 这两种视图采用不同的方法解决相同的问题，两种视图都需要从概念体系结构推进到物理实现。视图用于强调特定的体系结构范畴，同时有意地抑制其他范畴。 自从20 世纪 90 年代以来，已经存在许多不同的视图集。Perry 和 Wolf 提出，关于构建具有多种视图的体系结构（包括软件架构），存在一些非常有趣的要点。发表软件架构的 4 + 1 视图的 Kruchten 认为存在五种视图，这些视图组合起来可以表示软件架构。下面将描述前四种视图。 视图描述逻辑视图处理静态设计模型流程视图处理设计的动态视图物理视图处理如何将软件组件映射到硬件基础设施开发视图表示软件组件在开发时环境中的静态组织 第五种视图更多的是一种 Litmus Test 视图。它采用一组在体系结构上非常重要的用例（业务场景），并说明如何将四种视图的每一种视图中的体系结构元素集与针对那些元素的体系结构约束和决策结合起来，用于实现那些用例。 由Soni 等人 在Applied Software Architecture 中发表的另一种视图由四种构成软件架构的主要视图组成：视图描述概念体系结构视图从主要设计元素及元素间的关系方面描述系统模块互连体系结构视图描述功能分解和如何在不同的层中安排软件模块执行体系结构视图描述系统的动态结构代码体系结构视图描述如何在开发环境中组织源代码、二进制文件和库 软件架构出版物中描述了许多其他视图，但是介绍所有这些视图超出了本文的范围。对软件架构的不同视图进行仔细分析后表明，不同的研究结果之间存在大量的相似性。我们拥有一个最常用于表示系统软件架构的最优视图集合。 下一个部分将提供一些构件的概述，建议将这些构件用作可在软件开发生命周期的体系结构阶段生成的体系结构文档的最小集。 回页首文档说明对象 可以对软件架构的许多不同视图或方面做文档说明。对于任何中大型软件开发项目，建议您至少为以下体系结构构件集编写文档说明：系统上下文系统上下文对表示为黑盒的整个系统如何与外部实体（系统和最终用户）交互做文档说明。它还定义系统与外部实体之间的信息和控制流。系统上下文用于对系统所在的操作环境进行澄清、确认和编写文档说明。外部系统的性质、其接口以及信息和控制流对体系结构中的技术构件的下游规范有帮助。体系结构概述体系结构概述通过简单的图示表示形式说明体系结构中的主要概念元素和关系。您可以产生包括企业视图和 IT 系统视图的体系结构概述关系图。概述帮助表示组织所需要的业务和 IT 功能。功能体系结构从以下方面描述 IT 系统的结构：IT 系统的软件组件的职责、接口、静态关系和协作来交付组件所需功能的方式。此构件在各个细化阶段中迭代地进行开发。操作体系结构操作体系结构构件表示计算机系统的网络，这些系统支持解决方案的某些性能、可伸缩性和容错等需求。此构件还运行中间件、系统软件和应用程序软件组件。此构件在各个细化阶段中迭代地进行开发。体系结构决策体系结构决策构件提供了对所有在体系结构上相关的决策编写文档说明的单一位置。决策通常涉及到但不限于： 系统的结构。标识中间件组件以支持集成需求。将功能分配到每个体系结构组件（体系结构构建块）。将体系结构构建块分配到体系结构中的各个层。遵守标准。选择技术以实现特定的体系结构构建块或功能组件。 对任何视为在体系结构上与满足业务和工程目标相关的决策编写文档说明。文档说明通常包括： 问题的确定。各种解决方案的评估，包括优点和缺点。选定的解决方案，包括足够的论证和其他将对下游设计和实现有帮助的相关详细信息。 本系列的其余部分将讨论如何对软件架构中的这五个构件编写文档说明。 回页首结束语 软件架构已经存在 30 多年了。过去几十年已见证了软件工程方面的大量工作。软件架构师在设计满足企业的业务、工程和 IT 目标的解决方案中起着中流砥柱的作用。为软件架构编写文档说明是极其重要的。您可以使用文档说明，就某个正在发展的系统与参与者进行交流。文档说明对于使新的团队成员迅速投入工作也是非常有用的，因为新的团队成员可以在实现解决方案时使用体系结构透视图作为上下文和边界前提。 关于什么在性质上是体系结构，什么在性质上不是体系结构，以及应该对系统的哪些方面做文档说明，一直存在大量的混淆。体系结构模板定义并标准化每种类型的构件中的内容，支持采用一致的方法来对软件架构编写文档说明。 在本文中，您了解了作为一门学科的软件架构，并了解了对体系结构的基本元素编写文档说明的重要性。您还阅读了建议作为文档说明最小集的体系结构构件的概述。请继续关注本系列的其他文章，它们将详述如何使用一组指导原则，以及如何对每个构件编写文档说明。参考资料 学习您可以参阅本文在 developerWorks 全球网站上的 英文原文。阅读已发布的软件架构定义的纲要。D. Perry 和 A. Wolf 撰写的“Foundations for the Study of Software Architecture”是关于软件架构的经典文章。阅读P. Kruchten 撰写的“Architectural Blueprints - The "4+1" View Model of Software Architecture”。Applied Software Architecture 提供了用于产生高质量软件设计的实用指导原则和技术。在developerWorks 的 Architecture 架构专区中，获取用以提高您在体系结构方面的技能的各种资源。浏览技术书店，以了解有关这些技术主题及其他技术主题的相关书籍。讨论参与论坛讨论。访问developerWorks Blog，从而加入到 developerWorks 社区中来。关于作者Tilak Mitra 是 IBM 的一名高级认证执行 IT 架构师。他擅长 SOA，在 SOA 的业务策略和方向方面为 IBM 提供帮助。他还是一位 SOA 主题专家，帮助客户进行基于 SOA 的业务转换，并重点关注复杂和大型的企业架构。他目前的工作重点是围绕组合业务服务（Composite Business Services，CBS）构建可重用的资产，这些资产能够在多种平台上运行，例如 IBM、SAP 等的 SOA 堆栈。他生活在阳光明媚的南佛罗里达，闲暇时，他非常喜欢参加板球和乒乓球活动。Tilak 在印度加尔各答的 Presidency 学院获得了物理学学士学位，并且已经在班加罗尔的印度科学学院获得了电子工程学学士和硕士学位。访问 Tilak 的 blog，了解关于 SOA 的更多信息。您可以在 LinkedIn 上查看 Tilak Mitra 的个人简介。 关闭[x]关于报告滥用的帮助报告滥用谢谢! 此内容已经标识给管理员注意。关闭[x]关于报告滥用的帮助报告滥用报告滥用提交失败。 请稍后重试。关闭[x]developerWorks：登录IBM ID：需要一个 IBM ID？忘记IBM ID？密码：忘记密码？更改您的密码 保持登录。单击提交则表示您同意developerWorks 的条款和条件。 使用条款 当您初次登录到 developerWorks 时，将会为您创建一份概要信息。您在developerWorks 概要信息中选择公开的信息将公开显示给其他人，但您可以随时修改这些信息的显示状态。您的姓名（除非选择隐藏）和昵称将和您在 developerWorks 发布的内容一同显示。所有提交的信息确保安全。关闭[x]请选择您的昵称：当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。昵称：（长度在 3 至 31 个字符之间）单击提交则表示您同意developerWorks 的条款和条件。 使用条款. 所有提交的信息确保安全。为本文评分评论回页首

转载请注明出处51数据库 » 软件构建化架构师 系统分析师于软件架构师的区别