什么是系统架构
问题一：“系统架构”是什么意思？都有哪些架构？ JDE属于分布式架构,人和系统恕我孤陋寡闻,没听过阿
问题二：软件架构和系统架构到底是什？生活中有哪些东西可以比喻？ 软件架构是指软件整体的组织结构，是在较高层次上的分析设计，体现了软件系统总体的规化、决策、控制等。
系统架构包括软件、硬件、网络等多方面的组织结构。架构是分析设计的高层阶段，不会涉及到技术实现的细节，是蓝图，是规化，是决策。
现实生活中可比喻为高楼大厦的设计图纸。
问题三：什么是架构 架构一般指软件架构
（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口(计算机科学)来实现。 软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。
软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。
在“软件构架简介”中，David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。”【GS93】
但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”【IEEE98】。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。
在 Rational Unified Process 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。
一般而言，软件系统的架构（Architecture）有两个要素：
・它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。
详细地说，就是要包括架构元件（Architecture ponent）、联结器（Connector）、任务流（Task-flow）。所谓架构元素，也就是组成系统的核心砖瓦，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。
・建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。
在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。
详情参考
......>>
问题四：什么是系统工程师、系统架构工程师？ 系统工程师资格就是具备较高专业技术水平，能够分析商业需求，并使用各种系统平台和服务器软件来设计并实现商务解决方案的基础架构。
系统架构师是大型项目的技术领导者,总体负责系统的体系结构设计和指导。
问题五：什么是分布式系统架构 baike.baidu/view/9914海9 百度百科
问题六：架构，系统架构，技术架构，应用架构都是什么关系 架构
是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。
系统架构
是对已确定的需求的技术实现构架、作好规划,运用成套、完整的工具,在规划的步骤下去完成任务。
技术架构
通过合理的完善的评估途径对组织、网络、程序的组成框架、模型进行评价和分析,并对其进行完善。
应用架构
以架构图的方式描述系统的组成和框架，一般从系统功能和系统技术层次两个架构视角进行设计。
问题七：请问系统架构设计师的职责是什么 系统架构师的职责主要有如下4条：
1、确认需求
在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。
2、系统分解
依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。
软件架构师的功力基本体现于此，这是一项相对复杂的工作。
3、技术选型
架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。
Web Server运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是Mysql？需要不需要采用MVC或者Spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？类似的工作，都需要在这个阶段提出，并进行评估。
架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。
4、制定技术规格说明
架构师在项目开发过程中，是技术权威。他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照它的架构意图去实现各项功能。
架构师不仅要保持与开发者的沟通，也需要与项目经理、需求分析员，甚至与最终用户保持沟通。所以，对于架构师来讲，不仅有技术方面的要求，还有人际交流方面的要求。
问题八：系统架构师是干什么的啊？ 属于项目的高级分析、规划、管理人员
系统架构师（System Architecture）系统架构师是负责设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单等等。
全文见百科
baike.baidu/view/905154?fr=ala0_1_1
问题九：系统架构师的角 *** 别 系统构架师与产品经理的关系及区别产品经理通常是指负责产品设计的“专人”。一个优秀的理想的产品经理，应同时具备较高的商业素质和较强的技术背景。产品经理要有深厚的领域经验，也就是说，对该软件系统要应用到的业务领域非常之熟悉。比如，开发房地产销售软件的产品经理，应该对房地产公司的标准销售流程了如指掌，甚至比大多数销售人员还要清楚。如果开发的是通用产品，他/她还具备对市场、潜在客户需求的深刻洞察力。 那么，系统架构师与产品经理有什么不同呢？ 我们不应该把二者混为一谈，这是不少论述和实践常犯的错误。我看来，如果把开发软件比作摄制电影，产品经理之于系统架构师，就正像编剧之于导演。产品经理虽然要有一定技术背景，但仍应属于“商业人士（business people）”，而系统架构师则肯定是一个技术专家。二者看待问题的立场、角度和出发点完全不同。系统构架师与项目经理的关系及区别 软件项目经理是指对项目控制/管理，关注项目本身的进度、质量，分配、调动、协调、管理好人、财、物等资源的负责人。对于软件项目经理来讲，包括项目计划、进度跟踪/监控、质量保证、配置/发布/版本/变更管理、人员绩效评估等方面。优秀的项目经理需要的素质，并不仅在于会使用几种软件或是了解若干抽象的方法论原则，更重要的在于从大量项目实践中获得的宝贵经验，以及交流、协调、激励的能力，甚至还应具备某种个性魅力或领袖气质（Chari *** a）。 由此可见，项目经理和系统架构师在职责上有很大差异。混同这两个角色，往往也会导致低效、无序的开发。特别是，从性格因素上讲，单纯的技术人员倾向于忽视“人”的因素，而这正是管理活动的一个主要方面。另外，就像战争中的空军掩护（Air Cover）一样，专职的项目经理能够应付开发过程中大量的偶发事件和杂务，对于一个规模稍大的项目，这些杂务本身就能占用一个全职工作者的几乎全部时间。在一个项目中，推动项目发展的是系统构架师，而不是项目经理。项目经理的职责只是配合系统构架师，提供各个方面的支持。主要职责是与内外部沟通和管理资源（包括人）。系统构架师提出系统的总体构架，给出开发指导。一个项目中，项目经理的角色什么？如果他即使管理人员又是设计人员，则必须比别人强，能够有让别人服的东西。如果他只是项目管理人员，系统构架师有专门人员，就可以不用精通或者说了解 it 各个方面的知识，如果了解更好。另外，如果在一个项目没有人在技术构架上和开发指导上负全部责任，而是每个人都负责一快的架构、分析、设计、代码和实施等，最后肯定会失去管理。系统构架师与系统分析员的关系及区别系统分析员（System *** yst）是指对系统开发中进行分析、设计和领导实施的人。一般意思上讲，系统分析员的水平将影响系统开发的质量，甚至成败。但在一个完善的系统开发队伍中，还需要有业务专家，技术专家和其他辅助人员。所以，系统分析员只是其中的角色之一。但我国许多的 IT 公司，一般只有系统分析员而没有技术专家。系统分析员固然是对特定系统进行分析、设计。所以他的任务、目标是明确的。他只是去执行任务，完成系统的最终设计。系统架构师应该和系统分析员分开，但架构师必须具备系统分析员的所有能力，同时还应该具备设计员所没有的很多能力。 系统架构师是指导、检督系统分析员的工作，要求系统分析员按什么标准，什么工具，什么模式，什么技术去设计系统的。同时，系统架构师应该对系统分析员所提出的问题，碰到的难题及时地提出解决的方法。并检查、评审系统分析员的工作。
什么是系统架构设计_什么是系统架构设计师
简单一点，系统架构设计就是一个系统的草图，描述了构成系统的抽象组件，以及各个组件之间的是如何进行通讯的，这些组件在实现过程中可以被细化为实际的组件比如类或者对象。在面向对象领域中，组件之间的联通通常面向于接口实现的。是人们对一个结构内的元素及元素间关系的一种主观映射的产物。架构设计是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。“架构”一词最早来自建筑学，原意为建筑物设计和建造的艺术。但是在软件工程领域，软件架构不是一个新名词，只是在早期的著作中人们将软件架构称为软件体系架构。这就是架构的概念。所谓架构，就是人们对一个结构内的元素及元素间关系的一种主观影射的产物。无论何种系统架构应用领域，目的都是一样的，即完整地、高一致性的、平衡各种利弊的、有技术和市场前瞻性的设计系统和实施系统。扩展资料系统架构的主要任务是界定系统级的功能与非功能要求、规划要设计的整体系统的特征、规划并设计实现系统级的各项要求的手段，同时利用各种学科技术完成子系统的结构构建。在系统架构中，由于对软件越来越深入的依赖，软件架构的任务也体现出重要的作用。而且系统架构与软件架构是紧密联系和相互依赖的。1997年，EberhadrtRechtin与MarkWMaier在其论著中，为计算机科学总结了系统架构方面的实践成果，从而奠定了系统科学和系统架构在计算机科学中的基石。：百度百科：系统架构设计
系统结构设计
一、用户需求分析全面深入地了解掌握用户需求是作出一个优良的系统设计的关键，也是系统生命力的保证。在需求分析阶段，系统设计者应当完全确定用户的工作范围与流程。据此，确定系统的全部数据及相应处理，绘出系统数据流图，从而产生整个评价系统的逻辑模型。针对地质灾害灾情评估的特点，可以归纳为五个方面的需求，即：①数据维护；②物理系统（孕灾环境危险性）分析；③社会经济系统（承灾区易损性）分析；④风险分析；⑤防治效益评价。二、设计需求1.地质灾害系统自组织体系地质灾害系统作为一个开放的自组织体系，在内外界持续干扰的作用下，该体系形成涨落，从而体系状态发生质变，形成一种更加稳定有序的结构。地质灾害系统是由孕灾环境、致灾因子与承灾体共同组成的地球表层变异系统。灾情则是这一体系涨落作用的产物。2.系统硬软件环境的选择（1）各种与IBM兼容的PC机（需带有80387浮点运算器），1兆以上内存，100兆以上硬盘，VGA以上彩色图形显示器（卡）。（2）输入、输出设备，包括分辨率为0.1×0.1（mm）、带有国际标准数据交换格式的扫描仪（便于弧段跟踪、数据矢量化处理和数据格式转换），CALCOMP、HP系列或与之兼容的数字化仪和绘图仪。（3）软件环境系统采用美国环境系统研究所（ESRI）研制的PC版ARC/INFO（V3.4-PLUS）系统为基础软件。该系统是两个系统的结合，即描述地图特征和拓扑关系的ARC系统和记录属性数据的关系型数据管理INFO系统。这种混和数据模型兼顾了空间数据和非空间数据两种不同性质的数据特点，便于有效地管理这两种基本的空间数据：描述空间坐标的点、线、面特征和拓扑结构数据以及这些特性的属性数据。3.数据库的组织结构计算机作业较之于手工作业，在其精确度、可靠性方面具有很大的优越性。但这一切基于一个先决条件，那便是数据源的准确性。地质灾害风险评价系统涉及到的数据源较复杂，既包括自然物理数据，又包含社会经济发展数据。根据这些数据特点分为：属性库、图形库和图像库三类数据库。通过分析评价区内各灾种成灾特点、社会经济构成，收集各类数据源的数据，评价其精确度、可靠性、可利用性及相互关系，确定入库的数据项，并给出各数据项的详细定义，编辑数据词典。在各相关数据库之间建立公共特征码字段，将有助于提高数据的检索查询效率。根据系统的基本要求和地质灾害的基本规律，系统数据库组织如下：图9-1 GDRES数据库组织图4.系统总体设计地质灾害灾情评估系统是一类专业性的地理信息系统。其总体结构可作如下划分（图9-2）：系统运行时，用户在应用子系统中工作，由应用子系统调用系统功能模块从而完成对系统数据的处理。用户应用子系统是系统的用户界面。此层的缺失或划分不当，系统的用户友好性无从谈起。一般而言，应用子系统对应于用户某一需求的共同作业，此层面的设计与划分一定要从用户需求出发，面向地质灾害灾情评估的实际工作程序，以系统数据流图为基础进行。图9-2 系统总体设计图应用子系统建立在对系统功能模块的调用基础之上。系统功能模块可由支撑软件直接提供。许多支撑软件虽然功能强大，但一般都是从通用性入手考虑，具体到某一类专业应用系统，开发者仍具有一定工作量的二次开发任务，需要对系统功能模块进行扩充以满足特定需求。这类功能扩充定义又来源于上层应用子系统的操作分解，从中抽象出多个子系统中共同的操作，在此基础上开发扩充功能模块满足应用子系统的操作并优化系统整体结构。5.GDRES结构（1）系统组织结构的设计 从实用性入手，系统组织结构必须面向实际工作内容。为此，我们结合DBMS和GIS设计的概念和原理，将系统分为如下图所示的三个层次的七个子系统：①孕灾区灾害分布分析；②孕灾区危险程度分析；③承灾区受损范围分析；④承灾区价值易损性分析；⑤灾害发生概率分析；⑥灾害强度分析；⑦灾害风险分析。灾害强度是综合考虑孕灾区危险性强度及承灾区价值易损性的结果，灾害风险分析则建立在对中间层两因素的综合分析之上。图9-3 GDRES组织结构图（2）系统功能结构设计 我们以属性数据库、空间数据库为基础，设计出面向灾害风险分析的用户应用子系统。各应用子系统都具有以下功能模块，其中包括属性数据库维护、空间数据库维护、数据检索查询、统计查询、矩阵判断、空间分析模块。所有模块以GIS、DMBS类软件支撑并根据面向任务扩展产生。模块处理结果用文本、报表及图件三种方式输出，为地质灾害的管理和防治提供决策依据。系统功能结构图如下：图9-4 GDRES功能结构图
系统总体结构设计
（一）系统设计思路地下水系统三维可视化软件是一个庞大的软件系统，涉及到了一系列的软件开发技术和地下水系统概化与表示方案，在系统设计上要充分考虑现有的数据库基础，以提高对地下水系统的可视性与可操作性为目标，总体设计思路如下：（1）地下水系统三维可视化软件运行的基础是地下水资源数据库系统，系统运行的所有原始数据均来源于地下水资源数据库，二者之间需要实现紧密的有机结合。（2）地下水系统三维可视化软件运行的核心数据是地下水系统的三维结构数据，它以数据库的形式存储。本系统的各个子系统均是围绕该数据库进行操作。（3）地下水系统三维可视化软件按功能的不同划分为几个子系统或称为组件，这些组件可根据需要集成到不同的系统中，其本身可以集成为一个完整的可视化软件系统。（4）地下水系统三维可视化软件所处理的数据对象锁定为含水层系统，从面到体体现为含水层界面和含水层/隔水层本身，具有空间查询和管理功能，并对这些面和体可进行数据查询操作。（5）地下水流体的可视化依据含水层系统动态生成，其数据基础是地下水的动态观测数据。（6）为体现地下水系统三维可视化软件的独立性，研制开发相关原始性数据的数据库管理软件，作为独立的组件集成到整个可视化软件中。（二）系统结构与组织地下水系统三维可视化软件采用组件方式处理，按照研究内容给出的划分方案，共包括8个软件组件和一个网络服务体系，作为一个集成结构，这些组件之间的关系如图4-1所示。整个系统可以划分为四个组成部分，分别具有相对独立的软件功能，但又相互联系、互相依托。图4-1 地下水系统三维可视化软件的结构与组织1.地下水系统基础数据库管理子系统实现对地下水系统三维结构基础水文地质数据信息的管理，原则上采用大型数据库作为数据存储，利用数据引擎进行开发。2.地下水系统三维模型生成编辑工具子系统地下水三维系统生成辅助编辑工具能够为用户提供一个进行地下水三维系统动态生成和编辑的工作环境，并为地下水数值模拟提供单元剖分功能以及水文地质参数的空间配准。3.地下水三维系统可视化系统利用生成的三维水文地质模型数据信息，系统可提供多种形式的地下水系统三维可视化显示，并可将这些成果用于输出。4.地下水三维系统的网络服务体系三维可视化服务的对象是含水层结构，可基于含水层结构提供多种形式的WEB服务，通过用户的请求而取得可视化结果。（三）系统组件与关联地下水系统三维可视化软件的四个子系统又可以划分为8个程序组件和一个网络服务体系，实现地下水系统三维结构的生成、维护和服务过程。系统包括的8个组件为单机模式，服务于水文地质专业技术人员，实现地下水系统三维结构的生成和显示，为开展地下水资源评价工作提供一种有效的工作环境。具体组件如下：（1）地下水系统基础数据管理组件（组件1）；（2）地下水系统基础数据预处理组件（组件2）；（3）地下水系统三维模型生成编辑环境组件（组件3）；（4）地下水系统三维空间剖分组件（组件4）；（5）地下水系统空间面可视化飞行组件（组件5）；（6）地下水系统三维结构可视化组件（组件6）；（7）地下水流体运移动态仿真组件（组件7）；（8）地下水流场动态模拟组件（组件8）。网络服务体系是基于INTERNET提供的社会化服务，提供地下水系统三维结构的各种显示服务，并可根据用户的需要提供真实的三维结构数据服务。
软体设计中系统架构设计包括哪些内容
软体设计中系统架构设计包括哪些内容 架构师的职责主要有如下4条： 1、确认需求 在专案开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解使用者需求。 2、系统分解 依据使用者需求，架 面向物件的设计中，系统架构设计的内容有哪些 面向物件程式设计中的概念主要包括：物件、类、资料抽象、继承、动态系结、资料封装、多型性、讯息传递。通过这些概念面向物件的思想得到了具体的体现。 1）物件（Object) 可以对其做事情的一些东西。一个物件有状态、行为和标识三种属性。 2）类（class) 一个共享相同结构和行为的物件的集合。 类（Class）定义了一件事物的抽象特点。通常来说，类定义了事物的属性和它可以做到的（它的行为）。举例来说，“狗”这个类会包含狗的一切基础特征，例如它的孕育、毛皮颜色和吠叫的能力。类可以为程式提供模版和结构。一个类的方法和属性被称为“成员”。 系统架构设计师，难考吗 系统架构师属于软考的高阶，考试肯定是有有一定的难度的，但是如果自身基础好，通过考试自然是没问题；如果自身基础较为薄弱，参加培训通过系统的学习架构的知识体系，再做相关的试题，想要通过考试也是不难的。 系统架构设计师应学哪些书籍 《软体体系结构原理、方法与实践》 《系统架构设计师教程（第2版）》 《系统架构设计师考试全程指导》 《系统架构设计师考试试题分类精解与题型练习》 《系统架构设计师考试串讲视讯教程》 《新技术与新方法串讲视讯教程（3课时）》 《数学与经济管理视讯教程（7课时）》 《系统分析师技术指南（2009版）》 《系统分析师考试培训视讯教程（88课时）》 《Beautiful Architecture》? 《Beautiful Code》的姐妹作，里面有三成的架构是自己感兴趣的，已经有国内出版社拿下了，架构师的唐诗三百首------O'reilly新书Beautiful Architecture(InfoQ)?。 《97 Things Every Sofare Architect Should Know 》? 一个开放的wiki?，O'Reilly 将它释出成书，不知道有没人在翻，架构公理的书(InfoQ)?。 《Pattern-Oriented Sofare Architecture, Volume 4 - A Pattern Language forDistributed Computing》? 架构模式的集大成者，号称有人在翻但等了一年中文版还是没翻出来啊，面向模式软体架构第4、5卷出版(InfoQ)?。 架构技术类 云端计算已经开始代替SOA成为新一代Buz Word，回顾一下整个SOA出版风潮，自己觉得值得一读不忽悠的居然只有一本《SOA in Practic - SOA实践指南-分散式系统设计的艺术》?。 在热潮彻底退却前，SOA的书还在继续出著，OSGI与SCA的书也开始出现： 《SOA Design Patterns》? 又是Thomas Erl的书，很奇怪的连电子版都找不到，SOA设计模式出版啦(InfoQ)?。 还 没出版的呀一大堆 --《SOA Patterns》、《ESB Architecture for SOA》、《SOA with Java》、《Open Source SOA》、《OSGi in Action》、《SpringSource dm Server in Action》、《Modular Java: Creating Flexible Applications with OSGi and Spring》、《Understanding SCA》、《Apache Tuscany in Action》... 程式设计匠师类 立志做一个匠师的人今年比较幸福，可以看的书很多： 《Beautiful Code - 程式码之美》 ? 很有经典潜质的一本，去年没有读完今年继续，《程式码之美》的精选版(InfoQ)?。 《Produtive Programmer - 卓有成效的程式设计师》? Thoughorks中国翻译的，看了下样章，熊节(透明)的翻译依然是这么好， 《卓有成效的程式设计师》推荐序：做一个懒人(InfoQ)?。 《Clean Code: A Handbook of Agile Sofare Craft *** anship》? Rober。C大叔的书，不知道谁在翻，应该很容易翻啊，到后面大段大段都是程式码。 《Effective Java中文版(第2版)》? 怎么理解"软体概要设计是系统总体结构设计或系统架构设计 概要设计的目标是描述软体模组的外观以及处理逻辑.模组对外暴露的服务介面,以及需要引用的介面,介面标识,介面的访问协议,介面描述都属于模组的外观,其他的模组通过这些介面和模组打交道,自然需要在概要设计阶段对介面做细致的刻画,初此之外,对于关键的模组,外观还应该说明模组的非功能属性,比如并发处理能力,资料吞吐量以及介面呼叫的反馈时长等等.处理逻辑是指模组从输入到输出的转换过程,描述其转换演算法.无论通过何种图例和表现形式,只要能够清晰地说明模组外观和处理逻辑描述,就是好的概要设计. 系统架构设计师怎么复习比较好？系统架构设计师含金量。 系统架构设计师含金量。考了两次系统分析师都没有通过，下半年没开考，所以想考系统架构设计师，考了几次都没通过，着实没太多信心了，不知道怎么办才好。 满意答案颠沛流离德小0级2011-07-13系统架构设计师，既然是架构设计，其实质是偏软，走的是纯技术专家路线。当然此处的偏软并非程式的设计，而是整个软体的体系架构的设计，架构设计的好坏将直接影响到软体的质量，从这点看，其技术含量是非常高的，其职业定位应该是纯软体技术专家的角度，职业选择可以主要是企业内的高阶软体设计者或IT公司技术经理或技术总监一类的职位。 系统架构设计师考试 武汉不报考le 系统架构设计师复习哪些重点？ 既然你男朋友要考的话，应该他自己是知道这个证是有说明作用。像系统架构设计设考的重点是资料库系统、嵌入式系统、资料通讯与计算机网路、系统配置与效能评价、企业资讯化与电子商务、分散式系统设计具体我建议你去看一些考试大纲，希赛教育的网站上就有关于系统架构设计师的考纲，复习的资料希赛的网站上也有，你去那里看就全明白了。 系统架构设计师能挂靠吗 系统架构设计师属于软考高阶工程师级别， 完全可以挂靠，一年8000以上，这要看是哪些城市。
框架结构的设计方法是什么？
框架结构的主梁截面高度hb可按（1/10～1/18）lb确定，lb为主梁计算跨度；梁净跨与截面高度之比不宜小于4。梁的截面宽度不宜小于200mm，梁截面的高宽比不宜大于4。1、矩形截面柱的边长，非抗震设计时不宜小于250mm，抗震设计时不宜小于300mm；圆柱截面直径不宜小于350mm；2、柱剪跨比宜大于2；3、柱截面高宽比不宜大于3。设计方法：建筑结构常规设计是将上部结构、基础与地基三者分离出来作为独立的结构体系进行力学分析。分析上部结构时用固定支座来代替基础，并假定支座没有任何变形，以求得结构的内力和变形以及支座反力。然后将支座反力作用于基础上，用材料力学的方法求得线形分布的地基反力，进而求得基础的内力和变形；再把地基反力作用于地基或桩基上来验算承载力和沉降。但是这种方法忽视了地基、基础和上部结构在接触部位的变形协调条件，其后果是底层和边跨梁柱的实际内力大于计算值，而基础的实际内力则比计算值小很多。因此，合理的设计方法应将三者作为一个整体，考虑接触部位的变形协调来计算其内力和变形。以上内容参考：百度百科——上部结构
结构设计的具体步骤
1.熟悉项目情况，包括建筑图；地质勘查报告等。
2.按照建筑图和所学知识进行结构构件的布置和荷载施加，如柱，梁，墙等，这里面包括构件的截面估算。
3.如果采用PKPM等结构计算软件对结构构件布置图，即模型进行计算，应按规范或经验对软件中的参数进行选取。
4.计算结构检验，计算结果当均满足规范要求时意味着此结构方案可行，至于优化方案和方案是否符合建筑等专业要求是个渐渐积累的过程。
5.CAD按照计算结果进行施工图的绘制。