谁知道什么是系统架构设计?

1. 谁知道什么是系统架构设计?

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

2. 什么是软件系统架构设计

3. 什么是系统架构

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

4. 如何进行系统的架构设计

如何进行系统的架构设计
方法/步骤一个软件项目在需求确定后，就可以开始系统的架构设计了。架构设计不同于编写代码，需要遵循严格的语法和编程规范。它没有规范可遵循，存在即合理，适合系统开发和运行的架构就是最合理的系统架构。
系统的架构设计是在业务需求已经清晰的前提下进行的，假定在系统需求分析阶段已经确定了系统的功能和业务范围，也明确了系统运营需求。在上述需求还没有确定的情况下，不适宜开展系统的架构设计，需要回到需求分析阶段完善上述需求后再开展系统的架构设计。
系统架构就是一些模型图，模型图是人们用来理解系统和沟通的工具。这些模型图需要提供给系统相关干系人来理解系统，系统相关干系人有项目经理、产品经理、开发人员、系统运营维护人员、客户、项目投资人等。这些干系人有不同的知识背景，对同一架构模型图也会有不同的认知和理解：如果把开发架构模型图给产品经理或客户看，他们定然看不懂也不能理解；同样的道理，如果只把逻辑架构图给开发人员看，就不能正确地指导开发人员构建开发环境。
因此架构设计师在进行系统架构设计时，需要从系统的不同维度进行设计，以满足系统相关干系人理解系统架构的需求。架构设计模型主要有逻辑架构、开发架构、数据架构、物理架构和运行架构五种模型图。一般来说需要设计的系统架构模型有逻辑架构、开发架构和物理架构三种架构模型图。数据架构模型一般放在数据库中进行设计，运行架构和物理架构基本相近，只是在物理架构中加了数据的流向，因此一些系统设计使用物理架构代替了运行架构。
设计逻辑架构模型
逻辑架构模型主要是确定系统的功能范围和系统划分。在设计逻辑架构模型时，可以抓住两个关键点：一个关键点是对系统进行逻辑划分，将一个大系统划分为多个子系统；另外一个关键点是明确各子系统之间的协作和调用关系。
绘制逻辑架构的模型图有系统流程图和系统结构图：系统流程图描述了系统各子系统、相关文件和数据之间的关系，记录了整个系统的体系结构；系统结构图也称为层次图，它以层次方式描述了系统从顶层到最底层的功能分解。
下图分别是人脉系统的系统流程图和系统结构图。
上面的人脉系统流程图和人脉系统结构图就是依据人脉系统需求规格说明书给出的功能和业务范围绘制的。
设计开发架构模型
开发架构模型图是给开发人员看的，开发架构模型指导开发人员如何来架构系统的开发环境。开发环境包括系统开发框架的选型、开发工具和编程语言、模块划分等内容。下图是人脉系统开发架构模型图。
开发架构模型图给出了技术体系是B/S结构，开发框架选择SSM，开发语言是JavaEE。系统采用三层结构，分别是表示层、WEB应用层和数据层。表现层是JSP页面，在浏览器中运行，表现层是MVC的View。WEB应用层的控制层是MVC的Controller，业务逻辑层是MVC的Service，实体层是MVC的POJO。数据层由MyBaits数据库开发框架组成。
设计物理架构模型
物理架构模型是给系统部署人员和运营维护人员看的，主要给出系统的部署环境模型，包括网络环境、硬件环境和软件环境。下图是系统部署网络环境模型图。
从上面网络环境模型图中可以看出，系统部署只需要一台主机，要求支持HTTP协议和远程桌面协议。系统可以考虑部署到阿里云或腾讯云。
系统的架构设计主要涉及到三种模型图，分别是逻辑架构模型、开发架构模型和物理架构模型。逻辑架构模型一般采用系统流程图和系统结构图建模；开发架构模型没有标准的模型图，可以使用PPT或Visio绘图工具进行绘制；物理架构模型主要是由网路环境、硬件和软件环境组成。

5. 系统架构设计模式

系统架构设计模式大全
                   
    　　目前系统架构大约有110多种设计模式，模式不是教条，模式仅仅是经验的总结，下面我为大家整理了一些系统架构设计模式，一起来看看吧：
   
    　　Domain Model：定义了一个应用领域结构和工作流的精确模型，其中还包括它们的变化。
   
    　　Layers：解决系统合理分层的问题。
   
    　　Model-View-Controller：解决对用户界面变化的支持问题。支持某一特定用户界面的变化。
   
    　　Presentation-Abstraction-Control：解决相同业务具有多种表现形式问题。
   
    　　Microkernel：解决业务具有多种不同业务方法的问题。
   
    　　Refelection：解决需要动态改变软件系统结构和行为的问题。
   
    　　Pipes and Filters：解决算法的结构化并可以重新构建的问题。
   
    　　Shared Repository：适用于网络管理和控制系统领域。
   
    　　Blackboard：解决运行中智能化改进处理方法的问题。
   
    　　Domain Object：表现为已经将自我完备的连贯功能和基础性责任封装成定义良好的实体，通过一个或多个”显示接口”提供功能，并隐藏内部结构和实现。
   
    　　Messaging：由一系列相互连接的MessageChannel和Message Router管理着跨网络的不同服务间的消息交换。
   
    　　Message Channel：解决如何把彼此协作的客户端和服务连接起来的问题。
   
    　　Message Router：解决如何根据条件接受”信道”消息的问题。
   
    　　Message Translator：解决如何转换消息格式的问题。
   
    　　Message Endpoint：解决把数据转换为消息中间件能够理解的形式的问题。
   
    　　Publisher-Subscriber：为了在应用中更好的把彼此关注的事件通知给其它领域对象。
   
    　　Broker：通过一个代理管理器管理领域对象间远程互操作的各个关键方面。
   
    　　Client Proxy：解决客户端应用与网络基础设施相互屏蔽的问题。
   
    　　Requestor：解决应用代码被基础设施的代码污染而影响可移植性的问题。
   
    　　Invoker：解决服务代码被基础设施的代码污染而影响可移植性的问题。
   
    　　Client Request Handler：解决客户端应用与通信相互影响的问题，它封装了客户端在统一的接口背后进行的进程间通信的细节。
   
    　　Server Request Handler：解决服务端应用与通信相互影响的问题，封装了服务器端在统一的接口背后进行的进程间通信的细节。
   
    　　Reactor：解决在应用中避免使用多线程的问题。
   
    　　Proactor：解决在多线程的背景下出现性能问题的缺陷。
   
    　　Acceptor-Connector：把事件初始化与具体处理方法分离，从而提高可维护性。
   
    　　Asynchronous Completion Token：解决异步到达的事件仍然能按一定顺序处理的问题。
   
    　　Explicit Interface：解决如何正确设计接口的问题。
   
    　　Extension Interface：随着时间的推移，组件的接口是会膨胀的，一个胖的接口将更脆弱。解决防止”胖”接口并分离接口。
   
    　　Introspective Interface：解决公开内部信息接口的问题。
   
    　　Dynamic Invocation Interface：解决同一个接口允许客户端调用多种方法的问题。
   
    　　Proxy：解决在同一个接口下通过代理屏蔽某些实现的问题。
   
    　　Business Delegate：由本地业务代表来完成所有网络任务，分离了应用和网络处理的业务，减少了开发难度、提高了可理解性和可维护性。
   
    　　Facade：解决屏蔽子系统的变化辐射到高层应用的问题。
   
    　　Combined Method：解决多种相互关联的方法不合理的分布的问题。
   
    　　Iterator：解决分布式元素能够方便迭代的问题。
   
    　　Enumeration Method：解决减少外部迭代方式多次对聚合中的元素进行独立访问开销的问题。
   
    　　Batch Method：解决多次访问加大网络开销的问题。
   
    　　Encapsulated Implementation：解决对象划分的基本原则和方法问题。
   
    　　Composite：建立一种结构灵活的树状结构对象组织形式，形成“整体/部分”层级结构。
   
    　　Half-Object plus Protocol：通过在分布式系统中合理布局对象，以减少不合理的网络流量和服务器压力。
   
    　　Replicated Component Group：解决分布式系统容错的问题，复制的组件实现位于不同的网络节点，并组成一个组件组。
   
    　　Half-Sync/Half-Async：对并发系统中的异步和同步服务处理解耦合以简化编程，但又不会过度地影响性能。
   
    　　Leader/Followers：解决大批量小处理的环境下减少并发线程应用的问题。
   
    　　Active Object：为了减少服务器并发线程应用。
   
    　　Monitor Object：解决并发业务相互协调的问题。
   
    　　Guarded Suspension：在并发性程序中，当某个线程对一个资源进行访问的时候，首先需要判断这个资源的警戒条件是否成立。
   
    　　Future：并发调用的服务可能需要向客户端返回结果。
   
    　　Thread-Safe Interface：避免自死锁和加锁开销。
   
    　　Strategized Locking：在创建或声明时，为组件配置适当类型的锁实例。使用该锁实例来保护组件中的所有临界区。
   
    　　Scoped Locking：解决复杂繁琐代码中的疏忽发生漏释放造成死锁的问题。
   
    　　Thread-Specific Storage：解决频繁使用对象造成反复加锁解锁造成的性能问题。
   
    　　Copied Value：解决共享的值对象必须锁定带来的性能问题。
   
    　　Immutable Value：解决共享的值对象必须锁定带来的性能问题。
   
    　　Observer：定义一个特定的更新接口，通过该接口，Observer获得Subject状态变更的通知。
   
    　　Double Dispatch：根据运行时多个对象的类型确定方法调用的过程。
   
    　　Mediator：封装集合中所有对象的聚合协作行为，从而将这些对象解耦合。
   
    　　Command：为这些对象定义一个通用接口，来执行它们所代表的请求。
   
    　　Memento：解决在不破坏封装性的前提下正确存储和读取分布式对象状态的问题。
   
    　　Context Object：解决在松耦合系统中共享与程序执行上下文相关的通用信息的问题。
   
    　　Data Transfer Object：解决细粒度调用多次访问远程对象单个属性所带来的巨大开销问题。
   
    　　Message：解决网络协议只支持比特流这种最简单的数据传输形式，并不能识别服务调用和数据类型的问题。
   
    　　Bridge：解决在下层稳定的业务中嵌入上次变化部分的问题。
   
    　　Object Adapter：解决接口变化导致的不兼容问题。
   
    　　Chain of Responsibility：解决对象结构和请求分发逻辑上的变化影响到客户端的问题。
   
    　　Interceptor：解决构建一个可插拔的框架变化模型的问题。
   
    　　Visitor：解决将服务的实现分散在定义对象结构的各个类中难以进行集中处理的问题。
   
    　　Decorator：解决在稳定的核心功能外围添加扩展的问题。
   
    　　Template Method：解决在下层稳定的业务中嵌入上次变化部分的问题。
   
    　　Strategy：解决在一个或多个方法中根据不同的情况执行不同行为的问题。
   
    　　Wrapper Facade：主要解决应用代码使用底层API所提供的服务但代码难以理解的问题，需要对底层API进行面向对象的封装，通过提供一个简洁的'、健壮的、可移植的、内聚的面向对象的接口，来达到封装函数和数据的目的。
   
    　　Declarative Component Configuration：建立需要安装各类插件的宿主基础设施，使其能够正确管理运行时环境，可靠运用系统资源和服务的问题。
   
    　　Container：解决领域对象直接处理平台环境造成它与平台紧密耦合并增加实现的复杂性的问题。
   
    　　Component Configurator：解决在组件生命周期后期和升级时重新配置组件的问题。
   
    　　Object Manager：解决客户端依赖对象管理增加应用内部的耦合度和复杂度的问题。
   
    　　Virtual Proxy：解决从一个巨大数据库中把所有的对象全部加载进来消耗大量资源的问题。
   
    　　Resource Pool：解决获取和释放资源(网络连接、线程或者内容)引入一定的性能开销问题。
   
    　　Resource Cache：解决几个有限的资源用户频繁创建和释放资源带来不必要的性能开销问题。
   
    　　Automated Garbage Collection：解决不能及时将不再使用的内存收回可能耗尽内存的问题。
   
    　　Counting Handles：解决确保在堆上创建的共享对象能够可靠地、安全地、及时地回收的问题。
   
    　　Abstract Factory：解决一批对象用统一的方法进行创建和销毁的问题。
   
    　　Builder：解决对需要多步完成对象的创建时，简化创建过程的复杂性和多样性问题。
   
    　　Factory Method：解决直接创建对象可能导致代码的混乱并影响调用端代码的独立性问题。
   
    　　Disposal Method：解决销毁对象时可能需要多个步骤而引人过度的耦合问题。
   
    　　Database Access Layer：它通过在两种之间引人一个映射层将面向对象应用设计同关系型数据库分离开。
   
    　　Data Mapper：解决数据模型和持久化的表结构之间完全的解耦合的问题。
   
    　　Row Data Gateway：解决更细致的数据模型和持久化的表结构之间完全解耦的问题。
   
    　　Table Data Gateway：解决更细致的数据模型和持久化的表结构之间完全解耦的问题。
   
    　　Active Record：解决降低应用中面向对象数据模型与数据库中表结构之间的耦合的问题。    ;

6. 系统架构设计

WEB发布的系统具有交互性强、更新快捷、方便等优点，基于WEBGIS的河北地质遗迹系统采用Browse/Server体系结构，在逻辑上分为3层:客户机、应用服务器、Web服务器(图6-5)。并在GIS软件支持下开发出了系统应用查询分析模型。客户机负责数据结果的显示和用户请求的提交，IIS-Web服务器负责处理用户的HTML请求，而WEB-GIS地图应用服务器负责响应用户的地图请求。所有的地图数据和应用程序都放在服务器端，客户端只是提出请求，所有的响应都在服务器端完成，只需在服务器端进行系统维护即可。

图6-5系统总体结构图

7. 系统构架的系统构架

UML与系统构架UML对系统架构的定义是：系统的组织结构，包括系统分解的组成部分，它们的关联性，交互，机制和指导原则，这些提供系统设计的信息。具体的说，就是包括五个系统视图：1. 逻辑视图：以问题域的词汇组成的类和对象的集合2. 进程视图：可执行线程和进程作为活动类的建模，它是对逻辑视图的一次执行实例3. 实现视图：对组成基于系统的物理代码的文件和组件进行建模4. 部署视图：把组件物理的部署到一组物理的，可计算的节点上 　　5.用例视图：是参与者与系统之间，为达到某个目的而进行的一系列活动，是对系统功能的一种描述。

8. 系统架构是什么意思

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