系统架构是什么意思

1. 系统架构是什么意思

系统架构（Framework 或Architecture）或软件架构的定义很难明确，仁者见仁智者见智。
在面向对象范畴中，我认为就是通过若干类、抽象类及其接口有机组成的软件系统，其中类起的作用好比建筑物中的砖瓦钢筋水泥楼板，而接口和抽象类中没有实现的方法好比其中的一个个空间，包括大厅，走廊，房间，厨房,卫生间....，架构使用者的任务就是往这些空间中填充东西，也就是实现那些接口和抽象方法，从而可以创建一座定制了的建筑物。进一步，可以对这个建筑进行修饰使其外观更加漂亮。当然也可以进行改动，以便结构更加合理。
在《Rational 统一过程实践者指南》（RUP）认为，系统架构为：1. 系统中最重要的组成部分和它们的接口，以及做出的创建、购买或是重用这些组成部分的决定；2.描述这些组成部分在运作时如何交互来实现系统中最重要的脚本；3.实现并测试系统架构的原型，以验证架构是否可行、是否化解了重大风险，以及验证它是否打到了重要的质量指标：性能、可扩展性和成本等。

2. 什么是系统架构

问题一：“系统架构”是什么意思？都有哪些架构？  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 公司，一般只有系统分析员而没有技术专家。系统分析员固然是对特定系统进行分析、设计。所以他的任务、目标是明确的。他只是去执行任务，完成系统的最终设计。系统架构师应该和系统分析员分开，但架构师必须具备系统分析员的所有能力，同时还应该具备设计员所没有的很多能力。 系统架构师是指导、检督系统分析员的工作，要求系统分析员按什么标准，什么工具，什么模式，什么技术去设计系统的。同时，系统架构师应该对系统分析员所提出的问题，碰到的难题及时地提出解决的方法。并检查、评审系统分析员的工作。

3. 什么是架构？

  第66篇 
   极客时间《从0开始学架构》课程笔记。
   要理解什么是架构，需要先搞明白系统、子系统、组件、模块的定义，再区分出框架，然后才能真的理解什么是架构（设计）。
   系统无处不在。   地球是系统，太阳系也是系统；手机是系统，运行在手机里的APP是系统；电脑是系统，运行在电脑里的软件程序也是系统；浏览器是系统，打开某个网站也是系统。   似乎明白系统是什么，又似乎无法准确定义它。   维基百科上定义如下：
   关键词： 个体关联、运作规则、群体工作
   关联代表多个个体，不是一个。规则代表有指定要求和顺序，不是随意组合。群体工作则突出能力的变化，不是个体的能力累加，而是形成新能力：『系统能力』。
   子系统定义与系统一样，只是突出表达是一个大系统的组成部分，大系统由多个子系统组成。   系统=子系统A+子系统B……+子系统N
   在平时工作中，这两个概念一直没区分，仅仅是哪个用着顺手就用哪个，基本认为是一个相同的概念了。   但实际上，两个概念是有区别的，但不是正确与错误的那种区别，而是描述角度的差异而已。
   1、模块和组件都是系统的组成部分，只是从不同的角度拆分系统而已。   2、从逻辑的角度来拆分系统后，得到的单元就是“模块”；划分模块的主要目的是职责分离；模块偏业务。   3、从物理的角度来拆分系统后，得到的单元就是“组件”；划分组件的主要目的是单元复用；组件偏技术。   4、模块是对系统进行横向拆分，为了便于分工协作；而组件是纵向切分，站在成本角度，目的是为了复用，具备独立可替换特点。
   1、框架是一套规范或者规则（思想），或者提供基础功能的产品。   2、架构是结构与组件的抽象描述，是系统整体的顶层设计，用来处理软件高层次结构的设计和实施。   3、框架关注『规范』，架构关注『结构』。   4、同一个框架可以用在不同系统的软件架构中。   5、同一个系统的架构可以通过不同角度进行描述，如『4+1视图』
   1、个体=子系统或模块或组件；系统 = 一群关联个体根据规则运行   2、架构需要明确：个体包含哪些『个体』、个体运作和协作的规则   3、顶层结构突出『顶层』，区分系统和子系统，关注整体而不是个体
    软件框架     软件架构     软件架构 "4+1" 视图模型     运用RUP 4+1视图方法进行软件架构设计 

4. 常见系统架构有哪几种？

内核是操作系统最基础的构件，因而，内核结构往往对操作系统的外部特性以及应用领域有着一定程度的影响。尽管随着理论和实践的不断演进，操作系统高层特性与内核结构之间的耦合有日趋缩小之势，但习惯上，内核结构仍然是操作系统分类之常用标准！
内核的结构可以分为单内核、微内核、混合内核、外内核等。
单内核（Monolithic kernel），又称为宏内核。单内核结构是操作系统中各内核部件杂然混居的形态，该结构于1960年代（亦有1950年代初之说，尚存争议），历史最长，是操作系统内核与外围分离时的最初形态。
微内核（Microkernel），又称为微核心。微内核结构是1980年代产生出来的较新的内核结构，强调结构性部件与功能性部件的分离。20世纪末，基于微内核结构，理论界中又发展出了超微内核与外内核等多种结构。尽管自1980年代起，大部分理论研究都集中在以微内核为首的“新兴”结构之上，然而，在应用领域之中，以单内核结构为基础的操作系统却一直占据着主导地位。
混合内核（Hybrid kernel）像微内核结构，只不过它的组件更多的在核心态中运行，以获得更快的执行速度。
外内核（Exokernel）的设计理念是尽可能的减少软件的抽象化，这使得开发者可以专注于硬件的抽象化。外核心的设计极为简化，它的目标是在于同时简化传统微内核的讯息传递机制，以及整块性核心的软件抽象层。
在众多常用操作系统之中，除了QNX和基于Mach的UNIX等个别系统外，几乎全部采用单内核结构，例如大部分的Unix、Linux，以及Windows（微软声称Windows NT是基于改良的微内核架构的，尽管理论界对此存有异议）。 微内核和超微内核结构主要用于研究性操作系统，还有一些嵌入式系统使用外核！

5. 架构 是什么意思

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

6. 架构，系统架构，技术架构，应用架构都是什么关系

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

7. 架构是什么意思

架构意思是间架结构；构筑，建造。把一个整体（完成人类生存的所有工作）切分成不同的部分（分工），由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动，这就是架构。1、边界划分：根据要解决的问题，对目标系统的边界进行界定。2、能力划分：对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。3、交互机制：并对这些切分出来的部分，设立沟通机制。4、根据3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。架构可以分为：业务架构、应用架构、数据架构和技术架构。业务（逻辑）架构：使用一套方法论对产品（项目）所涉及到的需求的业务进行业务边界划分，简单的讲就是根据一套逻辑思路进行业务的拆分，总体原则是对业务进行业务边界的划分，比如做一个企业订购服务网站，你需要把商品类目、商品、订单、订单服务、支付、退款很清晰的划分出来，而业务架构不需要考虑诸如我用什么技术开发、我的并发大怎么办、我选择什么样的硬件等等。应用架构：应用是介于业务语言与技术语言之间，是对整个系统实现的总体上的架构，他需要指出系统的层次、系统开发的原则、系统各个层次的应用服务，例如，上述系统中可以分为、数据层（资源层）、数据服务层、中间构建服务层、业务逻辑层、表现层，并写明每个层次应用服务。应用架构是要说明产品架构分哪些应用系统，应用系统间是如何集成的，考虑两个事情：第一、考虑的是子系统间的关系。第二、考虑将可复用的组件或模块进行下沉，沉淀到平台层，为业务组件提供统一的支撑。数据（持久化）架构：对存储数据（资源）的架构方法论，其架构原则同应用架构大同小异，即考虑到各个系统应用场景、不同时间段的应用场景对数据进行诸如数据异构、读写分离、数据库或NOSQL的策略、缓存的使用、分布式数据（数据库）策略等等。数据架构主要解决三个问题：第一，系统需要什么样的数据；第二，如何存储这些数据；第三，如何进行数据架构设计。技术架构：应用架构本身只关心需要哪些应用系统，哪些平台来满足业务目标的需求，而不会关心在整个构建过程中你需要使用哪些技术。技术架构是应接应用架构的技术需求，并根据识别的技术需求，进行技术选型，把各个关键技术和技术之间的关系描述清楚。技术架构解决的问题包括：如何进行纯技术层面的分层、开发框架的选择、开发语言的选择、涉及非功能性需求的技术选择。总体来看，首先需要熟悉业务，形成业务架构，根据业务架构，做出相应的数据架构和应用架构，最后通过技术架构落地实施。业务架构是战略，应用架构是承上启下，一方面承接业务架构的落地，另一方面影响技术架构的选型。如何针对当前需求，选择合适的架构，如何面向未来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都需要深入思考的问题。没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往是空中楼阁。

8. 架构是什么意思

架构一般指软件架构

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