软件系统架构,软件系统架构有哪几种

软件中系统架构有哪些啊

如果是软件思想那就是泛指三层架构即B-L-D

什么是系统架构?

系统构架,是对已确定的需求的技术实现构架、作好规划,运用成套、完整的工具,在规划的步骤下去完成任务. 架构的分类第一种是基础架构的设计规划,例如:OS,硬件,网络,各种应用服务器等等. 第二种是软件开发设计的架构师,他们负责规划程序的运行模式,层次结构,调用关系,规划具体的实现技术类型,甚至配合整个团队做好软件开发中的项目管理.

请问软件三层架构是如何架构的,用什么工具开发?

MVC架构模式基于Java的Web应用系统采用MVC架构模式,即model(模型)、view(视图)、control(控制)分离设计.这是目前WEB应用服务系统的主流设计方向.Model:即处理事务逻辑的模块,每一种处理一个模块.View:视图负责页面显示,负责显示MODEL处理结果给用户,主要实现数据到页面转换过程.Control:控制负责每个请求request的分发dispatch,把FORM数据传递给MODEL处理,把处理结果的数据传递给VIEW显示.Eclipse、WebLogic、WebSphere都是基于MVC设计模式的J2EE开发工具

软件体系结构的建模是怎样的？

一、软件体系结构和框架的定义

软件体系结构的英文单词是“architecture”. Architecture的基本词义是建筑、建筑学、建筑风格。

软件体系结构虽然根植于软件工程，但还处于一个研究发展的阶段，迄今为止还没有一个为大家所公认的定义。

《设计模式》中对框架的定义是框架就是一组相互协作的类，对于特定的一类软件，框架构成了一种可重用的设计。

软件框架是项目软件开发过程中提取特定领域软件的共性部分形成的体系结构，不同领域的软件项目有着不同的框架类型。框架的作用在于：由于提取了特定领域软件的共性部分，因此在此领域内新项目的开发过程中代码不需要从头编写，只需要在框架的基础上进行一些开发和调整便可满足要求；对于开发过程而言，这样做会提高软件的质量，降低成本，缩短开发时间，使开发越做越轻松，效益越做越好，形成一种良性循环。

框架不是现成可用的应用系统。是一个半成品，需要后来的开发人员进行二次开发，实现具体功能的应用系统。框架不是“平台”，平台概念比较模糊可以是一种操作系统，一种应用服务器，一种数据库软件，一种通讯中间件等地那个，因此平台在应用平台主要指提供特定服务的系统软件，而框架更侧重了设计，开发过程，或者可以说，框架通过调用平台提供的服务而起的作用。

框架不是工具包或者类库，调用API并不就是在使用框架开发，紧紧使用API是，开发者完成系统的主题部分，并不时地调用类库实现特定任务。而框架构成了通用的、具有一般性的系统主体部分，二次开发人员只是像做填空一样，根据具体业务，完成特定应用系统中与众不同的特殊部分。

二、框架与架构之间的关系

框架不是构架（即软件体系机构）。体系结构确定了系统整体结构、层次划分，不同部分之间的协作等设计考虑。框架比架构更具体。更偏重于技术涉嫌。确定框架后，软件体系结构也随之确定，而对于同一软件体系结构（比如Web开发中的MVC），可以通过多种框架来实现。

三、框架与设计模式之间的关系

设计模式和框架在软件设计中是两个不同的研究领域。设计模式研究的是一个设计问题的解决方法，一个模式可应用于不同的框架和被不同的语言所实现；而框架则是一个应用的体系结构，是一种或多种设计模式和代码的混合体虽然它们有所不同，但却共同致力于使人们的设计可以被重用，在思想上存在着统一性的特点，因而设计模式的思想可以在框架设计中进行应用。

框架和设计模式存在着显著的区别，主要表现在二者提供的内容和致力应用的领域。

1)从应用领域上分，框架给出的是整个应用的体系结构；而设计模式则给出了单一设计问题的解决方案，并且这个方案可在不同的应用程序或者框架中进行应用。

2)从内容上分，设计模式仅是一个单纯的设计，这个设计可被不同语言以不用方式来实现；而框架则是设计和代码的一个混合体，编程者可以用各种方式对框架进行扩展，进而形成完整的不同的应用。

3)以第二条为基础，可以得出设计模式比框架更容易移植：框架一旦设计成形，虽然还没有构成完整的一个应用，但是以其为基础进行应用的开发显然要受制于框架的实现环境；而设计模式是与语言无关的，所以可以在更广泛的异构环境中进行应用。

总之，框架是软件，而设计模式是软件的知识体，提升框架的设计水平。

Feedback

# re: 软件体系结构（构架）、架构、设计模式之间的关系回复更多评论

2005-11-18 13:08 by 非鱼

FRAMEWORK和ARCHITECTURE属于不同的设计层次。DP和FRAMEWORK、ARCHITECTURE分属不同的领域，DP只能和ARCHITECTURAL PATTERN相提并论。

# re: 软件体系结构（构架）、架构、设计模式之间的关系回复更多评论

2005-11-18 17:59 by publisher luo

ARCHITECTURE是描述系统整体的一种结构（C/S架构,B/S架构，三层架构等），使用框架开发的web系统也是一种体系结构，而架构是系统中的一部分具体实现。框架的设计也使用了很多设计模式。设计模式只是一个问题解决域，而框架可以利用设计模式来解决客观存在的问题。不知道这么说是否好理解一点。

祝你生活愉快

谢谢

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

软件架构（software

architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系

统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向

对象领域中，组件之间的连接通常用接口_(计算机科学)来实现。

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

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

在“软件构架简介”中，David Garlan 和 Mary Shaw

认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结

构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。

但构架不仅是结构；IEEE Working Group

on Architecture 把其定义为“系统在其环境中的最高层概念”。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注

重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。

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

从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管

理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑

和流程。

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

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

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

详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。

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

联结器完成某一项需求。

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

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

软件开发一般比较会关注设计模式而不是架构设计，欢迎追问。

软件体系结构SAAM是什么意思？

SAAM法是把一个物体最主要的属性（特征）列举出来，再用检查表法把各个项目加以变化，并将其加以重新组合，然后再找出其中可以实行而且也有效果的项目。

　　在使用检查表法的时候，我们会发现被检查的事物范围太大了，如用”替换”来变更设计时，是变更哪一部分的设计就没有具体确定。SAAM法则解决了这一问题。

　　SAAM法实质上对检查表法的进一步完善，它首先把要检查的事物的属性列举出来，再对各个属性进行”检查”，使思路更广，目标更明确。

　　SAAM法实质上是将列举法和检查表法互相配合使用的一种方法，它也叫”属性改良配列法”。这种方法对于改良事物性质等方面，有极大的功效。

软件件架构分析方法’( Software Architecture Analysis Method －简称SAAM )，成为本领域的先驱。

java软件开发的架构设计

软件架构作为一个概念，体现在技术和业务两个方面。

从技术角度来说：软件架构随着技术的革新不断地更新其内容，软件架构建立于当前技术和一些基本原则的基础之上。

先说一些基本原则：

分层原则：分层是为了降低软件深度复杂性而使用的关键思想，就像社会有了阶级一样，软件有了层次结构。

模块化原则：模块化是化解软件广度复杂的必然手段，模块化的目的就是让软件分工。

接口实现分离原则随着软件模块化的不断深入改进，面向接口编程而不是面向实现编程可以让复杂度日趋增高的软件降低模块之间的耦合度，从而让各模块更轻松改进。从这个原则出发，软件也从微观进行了细致的规范化。

还有两个比较小但很重要的原则：

细节隐藏原则很显然把复杂问题简化，把难看的细节隐去，能让软件结构更清晰。其实这个原则使用很普遍，java/c++语言中的封装原则以及设计模式中的Facade(外观)模式就很能体现这个原则的精神。

依赖倒置原则随着软件结构的进一步发展,层与层之间、模块与模块之间的依赖逐渐加深，而层、模块的动态可插拔要求不端增大。依赖倒置原则可看视为接口实现分离原则的深化，根据此原则的精神，软件进入了工具时代。这个原则有点类似于知名的好莱坞法则：Don’t call us, we’ll call you。

以上这些原则奠定了我们的软件架构的价值指标。但软件架构毕竟是建立在当前技术之上的。而每一代技术都有架构模式。过去的不再说了，让我们就来看一下当前流行的技术，以及当前我们能采用的架构。

因为面向对象是当前最流行开发技术，且设计模式的大量使用使面向对象的走向成熟，而数据库是当前最有效的存储结构、web界面是当前最流行的用户接口，所以当前最典型的三层次架构就架构在以上几项技术的基础之上，用数据库作存储层、用面向对象来实现业务层、用web来作为用户接口层。我们从三层次架构谈起：

因为面向对象技术和数据库技术不适配，所以在标准三层次架构的基础上，我们增加了数据持久层，来管理O-R双向映射，但目前一直没有最理想的实现技术。cmp和entity bean技术因为其实现复杂，功能前景有限，已接近被淘汰的边缘。JDO及hibernate作为o-r映射的后期之秀，尤其是hibernate，功能相当完备。推荐作为持久层的首选

在业务层，因为当前业务日趋负载，且变动频繁，所以我们必须有足够敏捷的技术来保证我们的适应变化的能力，在标准j2ee系统中session bean负责业务处理，且有不错的性能表现，但采用ejb系统对业务架构模式改变太大，且其复杂而昂贵，业务代码移植性差。而spring 作为一个bean配置的轻量级架构，漂亮的IOC模式实现，对业务架构影响小，所以推荐作为中间层业务框架。

在用户结构层,虽然servlet/jsp/jstl/javaBean 能够实现MVC架构，但终究过于粗糙。struts对MVC架构的实现就比较完美，Taperstry也极好地实现MVC架构，且采用基于事件的方式，非常诱人，惜其不够成熟，我们仍旧推荐struts作为用户接口层基础架构。

因为业务层是三层次架构中最有决定意义的，所以让我们回到业务层细致地分析一下，在复杂的业务我们常常需要以下基础服务的一种或几种：事务一致性服务acid(tool:jta/jts)、并发加锁服务concurrent&&lock、池化管理服务cache、访问控制服务(tool:jaas)、流程控制服务workflow、动态实现服务IOC，串行化消息服务(tool:jms)、负载平衡服务blance等。如果我们不采用重量级应用服务器(如weblogic,websphere,jboss等)及重量级组件(EJB)，我们必须自己实现其中一些服务。虽然我们大多情况下，不需要所有这些服务，但实现起来却非易事。幸运的是我们有大量的开源实现代码，但采用开源代码却常常是件不轻松的事。

随着xml作为结构化信息传输和存储地位日渐重要,一些xml文档操作工具(DOM,Digester,SAX等)的使用愈发重要，而随着 xml schema的java binding工具(jaxb,xmlbean等)工具的成熟，采用xml schema来设计xml文档格式，然后采用java binding来生成java bean 会成为主要编程模式,而这又进一步使数据中心向xml转移，使在中小数据量上,愈发倾向于以xquery为查询语言的xml数据库。现还有一个趋势， microsoft,ibm等纷纷大量开发中间软件如(microsoft office之infopath)，可以直接从xml schema 生成录入页面等非常实用的功能。还有web service 的广泛应用，都将对软件的架构有非常重大的影响。至于面向服务架构(SOA)前景如何，三层次架构什么时候走入历史，现还很难定论。

aop的发展也会对软件架构有很深的影响，但在面向对象架构里，无论aspectJ还是jboss-aop抑是aspectWerks、 nanning都有其自身的严重问题：维护性很差，所以说它将很难走远。也许作为一个很好的思想，它将在web service里大展身手。

rdf,owl作为w3c语义模型的标志性的语言，也很难想象能在当前业务架构发挥太大影响。但如果真如它所声称那样，广泛地改变着信息的结构。那么对软件架构也会有深远影响。

软件体系结构和软件架构是一个意思吗

我理解是一样的,软件架构包括物理架构和逻辑架构,前者指各子系统如何部署,后者是分成几个子系统/模块以及它们之间的接口/交互关系.

什么是软件架构？

当你去了解一个东东的时候，第一步要做的，就应该去知道这个东东的定义，对于软件架构也是如此，经过网上查询和书籍的帮助，我大概理清了一个轮廓。

软件行业是一个热衷于制造‘名词’的行业，如果退回15年，估计没几个人知道‘软件架构’是什么，在上个世纪80年代，随着软件开发的规模不断扩大，软件开发成为一个行业，初期，随之而来的是越来越多的软件项目的失败，造成项目失败的原因很多，但主要集中在开发过程，所以软件工程应运而生，CMMI等流程标准也是一茬接着一茬的冒个不停。

在软件工程初具规模的时候，软件开发还是以数据结构+算法的形式存在，进入20世纪最后10年，随着面向对象技术、设计模式等在开发过程中的成功应用，软件架构也走进了大家的视野。

软件架构在定义上分为‘组成派’和‘决策派’两大阵营，分别描述如下：

’组成派‘认为软件架构是将系统描述成计算组件及组件之间的交互

。它有两个非常明显的特点：

关注架构实践的客体——软件，以软件本身作为描述对象。

分析了软件的组成，说明软件不是一个‘原子’意义上的整体，而是有不同的部分经过特定的接口进行连接组成的一个整体，这对软件开发来说很重要。

‘决策派’认为

软件架构包含了一系列的决策

，主要包括：

软件系统的组织

选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为

用于指导这个系统组织的架构风格：这些元素以及它们的接口、协作和组合

软件架构并不仅仅关注软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解、经济以及技术的限制和权衡等。

‘决策派’有以下两个显著的特点：

关注软件架构中的实体——人，以人的决策为描述对象。

归纳了软件架构决策的类型，指出架构决策不仅包括关于软件系统的组织、元素、子系统和架构风格等几类决策，还包括关于众多非功能性需求的决策。

按照‘组成派’的观点，软件架构关注的是软件整体的分割和交互，之所以分割，是因为不同的部分在逻辑或物理上相对独立，通过‘分而治之’的原则进行分割可以更好的理解整个系统，把握用户的需求，但是虽然整个软件可以分割成多个模块或子系统，但是模块和子系统之间的通信和交互也是很重要的，我想按照这种观点，架构师的主要任务是将软件分割成不同的模块，并定义模块之间的接口。

按照‘决策派’的观点，软件是一个在很多限制下产生的产品，这些限制包括用户和技术两方面，用户方面包括功能需求、性能需求、硬件需求等，技术方面包括技术选择、可扩展性、可重用性、可维护性等。我想按照这中观点，架构师的主要任务就是作出上述个各种限制作出选择或决策。《软件架构设计》温昱