【系统分析师之路】第十三章 软件体系结构

【系统分析师之路】第十三章 软件体系结构

软件架构这章节主要的考点有:软件架构的概念,4+1视图,五种软件架构风格(数据流,调用返回,虚拟机,构件,仓库),2层3层CS架构,BS架构,产品线,中间件,软件架构评估(ATAM,SAAM),分布式架构SOA,WebService,开发平台J2EE和.NET,MVC模式,MVP模式。

1.软件体系结构的概念和发展历史,软件体系结构风格,软件体系结构评估方法,软件产品线。
软件架构设计的位置应该在需求分析之后和设计之前做的事情。业务需求和技术实现通过SRS连接起来,所以说文档就是项目中的一种沟通工具。
软件体系结构建模:软件体系结构的模型一共分为五类。其中动态模型和结构模型最为常用。软件体系结构设计的一个核心问题是能否使用重复的体系结构模式,及能否达到体系结构级的软件重用。

No 模型名称 说明
1 结构模型 最直观和普遍的建模方法,它以体系结构的构件和连接件和其他概念刻画结构,并力图通过结构来反应系统的重要语义内容。
2 框架模型 近似于结构模型,但更侧重于整体的结构。
3 动态模型 研究系统大颗粒行为性质。
4 过程模型 研究构造系统的步骤和过程。
5 功能模型 一组功能构件按层次组成。下层向上层提供服务。

4+1视图模型:一共有五个视图,每一个视图只关心系统的一个侧面。UML的4加1视图应该和架构结合起来。
关键字:逻开进物景。逻辑视图和开发视图描述系统的静态结构,进程和物理视图描述的是动态结构。

【系统分析师之路】第十三章 软件体系结构_第1张图片

No 视图名称 说明
1 逻辑视图 支持系统的功能需求。
2 开发视图 也叫模块视图,侧重软件模块的组织和管理(软件管理)
3 进程视图 侧重于系统的运行特征(性能,可扩充性,吞吐量)。
4 物理视图 主要考虑如何把软件映射到硬件上(系统安装通信等)
5 场景 重要系统活动的抽象

通用体系结构的五种风格:

【系统分析师之路】第十三章 软件体系结构_第2张图片

架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。 
架构风格反映了众多系统所共有的结构和语义特征,并指导如何将各个构件有效地组织成一个完整的系统。
软件架构设计的一个核心问题是能否达到架构级的软件复用,也就是能否在不同的系统中使用同一框架。

数据流风格 批处理序列,管道/过滤器
调用返回风格 主程序/子程序,面向对象,层次结构
独立构件风格 进程通信,事件系统
虚拟机风格 解释器,基于规则的系统
仓库风格 数据库系统,超文本系统,黑板系统

批处理整个流程中都是没有和用户的交互的。管道过滤器和批处理结构都是一样的。 管道过滤器支持流式的数据处理。批处理必须一个处理完才可以处理下一个,而管道过滤器则没有这个限制。DOS系统命令的操作方式就是管道过滤器的应用。管道过滤器强调一棒一棒的传递。编译过程也是管道过滤器的应用,批处理系列数据必须是完整的。
调用返回风格-使用的最多。分层结构会让效率变得低下。Java因为有虚拟机,所以可以支持跨平台的运行。
仓库风格也叫做以数据为中心的风格。黑板系统强调以数据源为驱动的。也就是说都是通过黑板上知识源变化来控制的。数据库系统就是仓库的典型代表。
进程通信和事件驱动系统都是独立构件风格的代表。
虚拟机屏蔽了操作系统上不同的内容,构建了一个给程序运行的平台。

五种风格的详细介绍:

体系结构 详细介绍
数据流风格 构件为一系列固定顺序的计算单元,构件之间只通过数据传递交互,每一个处理步骤是一个独立的程序,每一步必须在前面的一步结束前才能开始,数据必须是完整的,以整体的方式传递。它区别于管道过滤器的是,批处理必须一个处理完才可以处理下一个,而管道过滤器则没有这个限制。
这里的构件被称作过滤器,连接件就是数据流传输的管道,将一个过滤器的输出传到另一个过滤器的输入。通过对输入数据流的变换或计算来完成。
调用返回风格 单线程控制,把问题划分为若干个处理步骤,构件即为主程序和子程序,子程序通常可合成为模块。过程调用作为交互机制,即充当连接件的角色。调用关系具有层次性,主程序的正确性取决于子程序的正确性。
显式调用。构件是对象,对象是抽象数据类型的实例。对象的行为体现在其接受和请求的动作。连接件即是对象间交互的方式,对象是通过函数和过程的调用来交互的。
构件组成一个层次结构。每一层为上一层提供服务,只能见到与自己相邻的层,通过层次结构,可以将大的问题分解为若干个渐进的小问题,逐步解决,可以隐藏问题的复杂度。修改某一层最多允许其相邻的两层。(只能影响上层)
独立构件风格 独立构件,连接件是消息传递。构件通常是命名过程,消息传递的方式可以是点对点,异步或同步方式,以及远程过程方法调用等。
隐式调用。构件不直接调用一个过程,而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册,当某个事件被触发时,系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。它的优点就是为构件的维护和演化带来了方便;其缺点是构件放弃了对系统计算的控制。
虚拟机风格 包括一个完成解析工作的解析引擎,一个包含将被解释的代码的存储区,一个记录当前引擎工作状态的数据结构,具有解析器风格的软件中含有一个虚拟机,可以仿真硬件的执行过程和一些关键应用,其缺点是执行效率比较低。
基于规则的系统:包括规则集,规则解释器,规则/数据选择器和工作内存,一般用在人工智能领域和DSS中
仓库风格 特点就是数据共享。构件主要有两大类,一类是中央共享数据源,保存当前系统的数据状态;另一类是多个独立处理单元处理单元对数据进行操作。它包括知识源,黑板和控制三个部分。
黑板是一个全局性数据库,包含问题域解空间的全部状态,是知识域相互作用的唯一媒介。
黑板风格:应用在对于解决问题没有确定性算法的软件中。(信号处理,问题规划和编译器优化)
构件以网状链接方式相互连接,用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件,超文本是一种非线性的网状信息组织方法,它以结点为基本单位,链作为结点之间联想式样关联。超文本系统通常应用在互联网领域。

五种风格的特点和优缺点:

No 名称 特点 优缺点
1 管道/过滤器 每个构件都有一组输入和输出,构件读输入的数据流,经过内部处理,然后产生输出数据流。UnixShell程序,批处理系统,传统的编译器就是例子。 缺点:导致批处理结构,不适合处理交互,在数据传输上没有通用标准,每个过滤器都增加了解析和合成数据的工作。
2 面向对象风格 数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。基于组件的软件开发是面向对象的典型应用。 优势:可以改变一个对象表示,而不影响其他的对象。设计者可将一些数据存取操作问题分解成一些交互的代理程序的集合。劣势:必须要知道对象的标示才可通信。必须显示调用,必须修改显式调用它的其他对象。
3 基于事件的隐式调用 构件不直接去调用一个过程,而是触发或广播一个或多个事件。当一个事件被触发,系统自动调用在这个事件中注册的所有过程。它的特点是事件的触发者不知道有哪些事件会被它调用。典型的有图形界面工具:Word和Excel。 优点:为软件重用提供了强大的支持,为改进系统带来了方便。缺点:放弃了对系统计算的控制,事件的触发者不确定事件的接受者是否可以接收到。数据交换的问题,基于事件系统必须依靠一个共享的仓库进行交互。正确性推理存在问题,过程的语义必须依靠上下文约束。
4 分层系统 每一层为上层服务,并作为下层的客户。其典型的应用是分层通信协议,如ISO/OSI的七层网络协议。内部的层只对相邻的层可见。这样一个复杂的问题可以分解成一个增量步骤序列的实现,每一层只给相邻层提供接口。
层次结构最广泛的应用就是分层通信协议,每一层提供一个抽象的功能,最底层通常是硬件物理层连接。
优势:支持抽象程度递增的系统设计;支持功能增强,功能的改变最多影响相邻的上下层;支持重用。劣势:并不是每个系统都可以很容易划分为分层的模式,而且很难找到一个合适的,正确的抽象方法。
5 仓库系统及知识库 中央数据结构说明当前状态,独立构件在中央数据存储上执行。 若输入流中某类时间触发进程执行的选择,则仓库是一传统型数据库;若中央数据结构的当前状态触发进程执行的选择,则仓库是一黑板系统。
6 C2风格 通过连接件绑定在一起的按照一组规则运作的并行构件网络。构件之间没有直接连接,而是通过连接件连接在一起,一个构件可以连接多个连接件。当两个连接件直接连接的时候,必须由一个连接件的底部到另一个的顶部。 它的特点是构件之间依赖性较少,能将任意复杂的功能封装在一起。

软件体系结构评估:
在体系结构评估过程中,评估人员所关注的是系统的质量属性。
敏感点:一个或多个构件的特征。在搞清楚质量目标时要注意什么。输入或变化点很小,但对结果的影响很大的地方。一个或多个构件的特性,意思是一旦有改变就会影响到结果。
权衡点:影响多个质量属性的特征。是多个质量属性的敏感点。修改加密级别必然安全性往上走,但必然性能就会往下走。这就是一个权衡点。
风险点:架构设计中潜在的存在问题的一种风险隐患。在某些位置需求没有达成一致,这有可能就会引发风险。
非风险点:就是没有风险的位置

软件主要的评估方式:基于调查问卷或检查表的方式基于场景的方式基于度量的方式
软件架构度量:基于度量的,基于调查问卷的和基于场景的方式,这三种方法用得最多的是基于场景的方式。基于调查问卷主观性太强,一般依赖于专家的经验和判断。

【系统分析师之路】第十三章 软件体系结构_第3张图片

1)基于调查问卷或检查表的方式
 CMU/SEI(卡耐基梅隆大学的软件工程研究所)的软件风险评估过程采用了这一方式。这一类的评估很大程度上来自评估人员的主观判断,因此不同的评估人员可能会产生不同甚至截然相反的结果。虽然主观但它仍然是系统的主要评估方式

调查问卷 是一系列可以应用到各种体系结构评估的相关问题。
检查表 包含一系列比调查问卷更细节和具体的问题

2)基于场景的方式
基于场景的方式主要包括:架构权衡分析法(ATAM),软件架构分析法(SAAM),成本效益分析法(CBAM)基于场景的方式最为常用。
有序的使用或修改系统的步骤,在体系结构中一般采用刺激(stimulus),环境(environment)和响应(response)三个方面来对场景进行描述。

刺激 stimulus 解释在场景中或描述项目干系人怎样引发与系统的交互部分。
环境 environment 刺激发生时的情况。
响应 response 如何通过体系结构对刺激作出反应。

3)基于度量的方式
度量是指软件产品的某一属性所赋予的数值。如代码行数,方法调用层数,构件个数。对代码的度量很传统,近年来也出现了对高层设计的度量。

【系统分析师之路】第十三章 软件体系结构_第4张图片

【系统分析师之路】第十三章 软件体系结构_第5张图片

这六个步骤有局部的迭代在里面。这个过程可能跟我们做测试的思路有点接近,还要看架构和场景的匹配度如何。

缩写 软件评估方式 说明
ATAM 体系结构权衡分析方法 揭示了体系结构如何满足特定的质量目标,还提供这些质量属性目标是如何交互的。
评估步骤 描述ATAM方法,描述业务动机,描述体系结构,确定体系结构方法,生成质量属性效用树,分析体系结构方法,讨论和对场景的分级,分析体系结构方法,描述评估结果(顺序可变)
SAAM 软件体系结构分析方法 是最早形成文档并得到广泛使用的软件体系机构分析方法。最初是用来分析体系结构的可修改性。它的特点是比较简单,进行培训和准备工作较少。
评估步骤 形成场景,形成体系结构,对场景进行分类和优先级选择,对间接场景的单个评估,评估场景的相互作用,形成总体评估

【系统分析师之路】第十三章 软件体系结构_第6张图片

质量属性效益树:用树的形式表达出来的,在树的旁边写上这个质量属性如何。由评估小组,设计小组,管理人员,客户代表共同去决定。对于场景也会涉及到权衡。投票时票数和场景是不对等的,这样可以更有针对性的投票。

其中ATAM(架构权衡分析法)和SAAM(软件架构分析法)。用得是比较多的。ATAM分为四个阶段来做的,描述介绍阶段,调查与分析阶段;测试阶段;报告阶段。
参加ATAM不仅是开发,还包括用户方的用户代表,由首席设计师来进行架构方面的描述。在测试阶段需要对场景进行优先度的分级。项目干系人投票也是在这个场景中。
描述业务动机:为什么要做该项目,通过该项目想要解决一个什么样的问题。
SAAM分了六个步骤,这六个步骤有相应的迭代在里面。他和测试的思路比较相近,在测试的时候会先测单个模块,然后再测模块和模块之间;

软件架构评估--质量属性

架构里面要是要分类的话,往往是可用性而不是可靠性。
可修改性:你的软件要修改,它的困难程度有多高。它是你维护工作的核心因素。
功能性:系统能完成期望工作的能力。
可变性:如果要进行扩充,从而形成一个新的体系,这样的能力强不强就是可变性。它比可修改性高了一个层次。
互操作性:软件往往难以独善其身。那么系统之间的互操作性和兼容性就是要考虑的内容。

【系统分析师之路】第十三章 软件体系结构_第7张图片

【系统分析师之路】第十三章 软件体系结构_第8张图片

软件产品线:

【系统分析师之路】第十三章 软件体系结构_第9张图片

卡耐基、梅隆大学软件工程研究所(CMU/SEI)定义为:产品线是一个产品集合,这些产品共享一个公共的、可管理的特征集,这个特征集能满足选定的市场或任务领域的特定要求。这些系统遵循一个预描述的方式,在公共的核心资源(core assets)基础上开发。
他由两部分组成:核心资源和产品集合。
核心资源:产品构造的基础。包含产品线中所有的产品共享的产品线体系结构,和在产品线中重用的软件构件。
软件产品线开发有4个基本特点:过程驱动,特定领域,技术支持,以体系结构为中心。
产品线过程模型:双生命周期模型,SEI模型,三生命周期模型。
产品线划分的依据有两个:第一是该组织是用演化方式还是革命方式引入产品线开发过程。第二个是基于现有产品还是开发全新的产品线。
1)双生命周期模型:
分成两个重叠的生命周期分别是领域工程和应用工程。领域工程是其中的核心部分。这种产品线方法综合了软件体系结构和软件重用的概念,目的是提高软件生产效率,可靠性和质量,降低开发成本,缩短开发时间。
领域工程主要有:领域分析,领域设计,领域实现
应用工程:在领域工程结果的基础上,构造新产品。它也包括三部分:需求分析,系统设计,系统实现。

【系统分析师之路】第十三章 软件体系结构_第10张图片
2)SEI模型
每个旋转代表一个基本活动,3个环连接在一起,不停的运动着。3个活动交互连接,高度重叠。

【系统分析师之路】第十三章 软件体系结构_第11张图片
3)三生命周期模型
它对双生命周期模型进行了改进。在应用领域工程中增加了商务市场分析和规划。在领域工程中增加了产品线确定作为起始阶段,还为领域工程增加了市场分析的任务。

【系统分析师之路】第十三章 软件体系结构_第12张图片

它是多种技术的综合体,是一种复杂的技术。它包括软件架构技术,领域工程,DSSA。双生命工程很好的诠释了领域工程。

将现有的产品演化为产品线。用软件产品线去替换现有产品集。全新软件产品线的开发。全新软件产品线的演化。

2.WEB计算:WebServer的体系结构和三种不同角色;SOAP,WSDL,UDDI的概念和技术。
Web Service的体系结构:解决应用程序之间通信的一种技术,是描述一系列操作的接口,它使用标准的XML描述接口,可以实现跨平台的通信解决异构的问题。WebService是面向计算机的,是实现SOA架构的技术。它是一种面向服务的体系结构。它是一种技术规范。统一构件下产生的构件是可以通用的。服务是基于XML,相关的协议也是基于XML发展而来的。
WebService的优点:高度的通用性和易用性;完全的平台语言独立性;高度集成性;容易部署和发布。

高度的通用性和易用性 Web服务利用标准的因特网协议,解决了面向Web的分布式计算模型。而COBRA,DCOM和EJB等使用私有协议,只能解决企业内部的对等实体间的分布式计算。
完全的平台语言独立性 Web服务使用XML作为信息交换格式,厂商之间的信息很容易实现沟通。
高度的集成性 它实质上是通过服务的组合来完成业务逻辑的。Web 服务还提供动态接口来实现动态的集成,这也是传统的EAI解决方案所不能提供的
容易部署与发布 Web服务体系结构方案通过UDDI,WSDL和SOAP等技术协议,很容易实现系统的部署。

WebService模型的三种不同角色:服务请求者,服务提供者,服务注册中心。

服务注册中心:什么地方有什么样的服务,可供服务请求者进行检索。
静态绑定:一开始就明确了谁是我的服务提供者并建立绑定关系。

【系统分析师之路】第十三章 软件体系结构_第13张图片

服务提供者 Service Provider 从企业的角度来看,这是服务的所有者。从体系结构的角度看,这是托管被访问服务的平台
服务请求者 Service Requestor 从企业的角度来看,这是要求满足特定要求的企业。从体系结构的角度来看,这是寻找并调用服务、或启动与服务交互的应用程序。服务请求者角色可以由浏览器来担当,有人或这无界面的应用程序来控制。
服务注册中心 Service Registry 这是可搜索的服务描述注册中心。服务提供者在此发布他们的服务描述。在静态绑定开发或动态绑定执行阶段,服务请求者在这里查找服务并获取服务的绑定信息(在服务描述中)。对于静态绑定的服务请求者,服务注册中心是可选的,因为服务提供者可以把服务描述直接发送给服务请求者。同样服务请求者也可以从服务注册中心以外的其他来源中获得服务描述。

三个工作角色之间的交互和操作构成了Web Service的体系结构。 

WebServiceä½ç³»ç»æ模å
Web Service服务的典型技术包括:

1 SOAP Simple Object Access Protocol 用于传递信息的简单对象访问协议,它基于XML,通过使用SOAP,应用程序可以在网络中进行数据交换和远程调用。我们可以将它理解为HTTP+XML+RPC。由于SOAP采用XML和HTTP封装通信消息,所以SOAP需要增加响应的额外开销。
2 WSDL Web Services Description Language 网页服务描述语言,用于描述Web Service及其参数和返回值,将Web服务描述为能够进行消息交换的服务访问点的集合。WSDL的目标是描述如何使用程序来调用Web服务。可以把它理解为Web服务的SDK标准,或者是Web服务的接口定义。
3 UDDI Universal Description, Discovery and Integration 用于Web服务注册的统一描述,发现及集成。可以理解为一组目录服务,它定义了一种Web服务的发布方式。它集描述检索与集成为一体,其核心是注册机制。
4 XML Extensible Markup Language 用于数据交换的可扩展标记语言。它是一套定义语义标记的规则,它也是元标记语言
5 XSD  XML Schemas Definition  定义标准数据类型。用于约束XML文档的格式。
6 SOA Service-Oriented Architecture 面向服务的体系结构:是一个组件模型,是一种粗粒度,松耦合的服务架构。

适用Web Service的情况:跨越防火墙,应用程序集成,B2B集成,软件重用。
不适用WebService的情况:单机应用程序,局域网上的同构应用程序。

【系统分析师之路】第十三章 软件体系结构_第14张图片
互联网内部对象请求代理协议(IIOP)是公用对象请求代理程序结构CORBA中至关重要的一个部分。
XML的特点:
*实现不同数据的集成
*使用于多种应用环境
*客户端数据处理与计算
*数据显示多样化
*局部数据更新
XML相关的技术主要还有三个:Schema,XSL和XLL。

CSS和XSL 是用来定义XML文档显示格式的。
DFD 文档类型定义。用来对文档格式进行定义的语言。DFD和Schema决定文档的内容应该是什么样的。
XLink XML标准的一部分,用于定义对XML的链接。它可以在XML中插入元素,类似于HTML中的a标签。它必须与Xpath和Xpointer配合使用。
Xpath 可用来定位XML文档树的任意节点。
XPointer 是XML语言的指针。它是对Xpath的扩展。可以确定节点的位置与范围。
XQL XML查询语言,是对XSL的一种自然扩充,并在XSL的基础上提供筛选操作。
DOM和SAX DOM使用树状结构来表示XML文档,以便更好的看出层次关系。在使用DOM处理XML的时候,需要在处理前对整个文档进行分析。
SAX 是事件驱动的,每当他发现一个新的XML标记时,就用一个SAX解析器注册句柄,激活回调函数。
XMLparser XML解释器。一个用与处理XML文档的软件包。
Metadata 元数据。有关数据的数据和有关信息的信息。
RDF 资源描述框架。用于编译,交换和重新使用结构化元数据的W3C指令的XML应用程序。它能使软件更容易理解Web站点的内容。

WebServices与WebService的区别:
初看,似乎一个是复数形式,一个是单数形式。然而,WebServices指的是用于架构WebService的整体技术框架,WebService表示使用WebServices技术框架而创建的应用实例。 

面向服务的体系结构SOA

服务是一种为了满足某项需求的操作,规格等逻辑组合,它包含一系列有序活动的交互,为实现用户目标提供支持。
基于服务的架构标准高度统一。构件技术就是一种标准化的产生。服务都是基于XML,相关协议也都是基于XML发展而来的。
SOA可以很好的应对信息孤岛的问题。因为它可以把遗留系统封装成一个一个的服务。服务一个一个是独立的,所以它有松散耦合的特征。服务其实就是对下面的构件进行高度标准化的过程。
它有三个特点:松散耦合,粗粒度,标准接口。而WebService和ESB是SOA的两个主要实现方式。服务构件粗粒度,传统构件细粒度居多。
服务构件的接口是标准的,主要是WSDL接口,传统构件常以具体API形式出现。
服务构件与实际的语言无关,传统构件绑定某种特定语言。
服务构件可以通过构件容器提供Qos的服务,传统构件直接由代码控制。

【系统分析师之路】第十三章 软件体系结构_第15张图片
本质上是服务的集合,服务间彼此通信,采用的是客户端/服务器的软件设计方法,但相比于C/S模式,它着重强调软件构件的松散耦合,并使用独立的标准接口。所有服务通过服务总线或流程管理器来连接服务和提高服务请求的路径。它的服务之间通过简单,精确定义接口进行通信,不涉及底层编程接口和通信模型。

【系统分析师之路】第十三章 软件体系结构_第16张图片
它的三个特征:松散耦合,粗粒度服务,标准化接口。统一构件下产生的构件是可以通用的。服务是基于XML,相关的协议也是基于XML发展而来的。

1 松散耦合 将服务提供者和服务使用者在服务实现和客户如何使用服务方面隔离开来。
2 粗粒度服务 服务所公开功能的范围,粗粒度服务是指那些能够提供高层商业逻辑的可用性服务。
3 标准化接口 SOA通过服务接口的标准化描述,使得该服务可以提供给在任何异构平台和任何用户接口中使用。

SOA必须遵循的原则:

SOA原则 说明
业务驱动服务,服务驱动技术 服务位于业务和技术之间,业务处于主导地位。需要设计好的服务动态组合来应对多变的业务逻辑。
业务敏捷是最基本的业务需求 SOA的目的就是应对变化,其最高准则是以不变应万变,具体来说就是通过现有的可重用性服务的重新组合来应对新的需求。

面向服务的分析与设计从基础设计层(采用OOA和OOD),体系结构层(采用EA体系结构),业务组织层(采用BPM方法)
在采用Web服务作为SOA实现技术时,系统至少可分为六个层次:

No SOA实现层次 协议
1 底层传输层 HTTP,JMS,SMTP
2 服务通信协议层 SOAP,REST
3 服务描述层 WSDL
4 服务层 包装遗留系统
5 业务逻辑层 WS-BPEL
6 服务注册层 UDDI

3.C/S与B/S结构,分布式系统;理解多层C/S与B/S体系结构在对系统功能进行划分时的依据与原则,各层之间的关系;理解分布式系统的原理,概念,设计原则。

【系统分析师之路】第十三章 软件体系结构_第17张图片

【系统分析师之路】第十三章 软件体系结构_第18张图片

二层C/S结构 定义 基于资源不对等,且为实现共享而提出来的。服务器后台负责数据管理,客户机前台完成与用户的交互任务。它的特点是胖客户机瘦服务器的体系结构,适合单一服务器局域网的使用。C/S架构软件有一个特点,就是如果用户要使用的话,需要下载一个客户端,安装后就可以使用。比如QQ,OFFICE软件等。
优势 易于对系统进行扩充和减小,将大的应用处理任务分布到许多网络连接的低成本计算机上,以节约大量的费用;模型思想简单,易于人们接受理解。由于只有一层交互,因此响应速度较快。因为只有两层的传输,安全性能可以很容易保证。
劣势 开发维护成本高,客户端程序设计复杂,信息内容和形式单一,用户界面风格不一,软件移植困难,升级维护困难,新技术不能轻易使用。
三层C/S结构 定义 与两层C/S相比,三层模式增加了一个应用服务器。它将应用功能分成表示层,功能层和数据层。它比两层的C/S好维护的多,但其他问题并没有得到解决,客户机的负荷太重。三层C/S结构是分两类服务器(数据库服务器和应用服务器)和用户。
优势 使整个逻辑结构更加清晰,提高系统的可维护性和可扩展性。可以并行开发,未认证授权用户无法绕过功能层而直接访问数据层。数据和功能分开,分别放入数据库服务器和应用服务器中,这样对数据加一层保护,安全性更高。
劣势 跨平台性差,难以扩展到广域网或Internet上,且较难维护。
B/S结构 定义 Web浏览器,极少数事务逻辑在前端实现,但主要事务逻辑在服务器端实现。B/S架构的系统无须特别安装,只有Web浏览器即可。
优势 基于B/S的信息系统比C/S的信息系统更容易维护。
劣势 安全性差。建立在广域网之上, 对安全的控制能力相对弱, 面向是不可知的用户群。

两层C/S架构缺点:开发成本较高;客户端程序设计复杂;信息内容和形式单一;用户界面风格不一;软件移植困难;软件维护和升级困难;新技术不能轻易应用。

C/S结构可以是两层的,也可以是三层的。C/S架构在不同的客户端有不同的架构。如果部署了10万个客户端,那么在升级时需要升级10万个客户端。因为界面的变化往往不多,所以就有了三层CS架构。业务逻辑部署在应用服务器上,这样只要更新在具体应用过程中可以把3层C/S架构部署为两层。各个层次可以使用不同的语言开发。三层C/S架构中多了一个功能层,它可以部署在应用服务器上,来减少客户端的修改负担。功能层有效地隔离表示层与数据层,为严格的安全管理奠定了坚实的基础,整个系统的管理层次也更加合理和可控制。

但3层C/S架构设计生不逢时,提出来没有多久就有了B/S架构。3层B/S与C/S最大的区别就在于客户端。B/S可以说是零客户端。所有业务逻辑的职能都在B/S结构中的WEB服务器上完成,连界面的代码也是在Web服务器上完成。但是B/S架构缺乏对动态页面的支持的能力,没有集成有效的数据库处理功能;它的安全性难以控制;在数据查询和响应速度上,要远远低于C/S架构;它的数据提交一般以页面为单位,数据的动态交互性不强,不利于OLTP应用。

而富互联网等于把B/S架构拉入了下一个时代。因为它维护方便界面维护能力也相当强。
Flex:普遍应用在网游中
AJAX异步JavaScript和XML可支持局部刷新;
Mushup:是一种信息杂凑技术或者叫聚合技术。
RIA结合了C/S架构反应速度快,交互性强的优点,以及B/S架构传播范围广及容易传播的特征。
RIA简化并改进了B/S架构的用户交互。数据能被缓存到客户端,从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面。

【系统分析师之路】第十三章 软件体系结构_第19张图片

【系统分析师之路】第十三章 软件体系结构_第20张图片
为了解决C/S模式的客户端问题,发展形成了浏览器服务器模式;为了解决服务器端的问题,发展形成了三层或多层C/S模式。
微信平台属于胖服务器,瘦客户端模式。该模式降低了客户端系统开销,而后台系统将承受巨大的并发访问吞吐量,存储,内存,CPU等利用率超高等的开销。

【系统分析师之路】第十三章 软件体系结构_第21张图片

分布式系统架构:
C/S和B/S结构就属于分布式系统。它的难点在于其组件的异构性,开放性,安全性,可伸缩性,故障处理以及组件的并发性和透明性。
分布式系统倾向于大粒度的设计方式,往往在一个方法中包含了许多参数,每个方法基本上代表了一个独立的功能。
分布式系统用两种完全不同的方式来进行协同和合作:基于实例的协作和基于服务的协作。基于服务的协作通常采用层次式体系结构,高层的应用依赖于低层的对象。
分布式对象技术是指采用面向对象技术开发的两个或多个软件互相共享信息。可以将分布式对象技术和传统的BS结构结合起来,构建分布网络环境下的系统。

  • 富互联网应用

【系统分析师之路】第十三章 软件体系结构_第22张图片
RIA结合了C/S结构反应速度快,交互性强的优点与B/S结构传播范围广及容易传播的特征。RIA简化并改进了B/S架构的用户交互。富互联网是BS架构的进一步改善。它结合了CS架构反应速度快,交互性强的优点,以及BS架构传播广以及容易传播的特征。
RIA的优势:利用相对健壮的客户端引擎,提供内容密集,响应速度快,和图形丰富的用户界面。它的数据能够缓存在客户端,响应速度更快,数据往返于服务器次数更少。
数据能够被缓存在客户端,从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器次数更少的用户界面。

【系统分析师之路】第十三章 软件体系结构_第23张图片
支持RIA的技术平台:FLASH/Flex;Bindows;Java;Ajax;Laszlo;XUL;Avalon

RSS 一种用于对网站内容进行描述和同步的格式,是目前最广泛的Web资源发布方式。
REST 从资源的角度看待整个网络,各处的资源由URI决定,客户端的应用通过URI获取资源的表示。
SOAP 一种基于XML的数据格式定义,用来进行Web服务调用过程中的参数调用和返回。
ATOM 一种基于XML的文档格式和基于HTTP的协议,用来聚合网络内容。
Avalon 是Vista的一部分,是一个图形和展示的引擎。
XUL 可用于建立窗体应用程序。
Laszlo 是一个开源的RIA开发环境。
Ajax 用来描述一组技术,它使浏览器可以为用户提供更为自然的浏览体验。使用JavaScript和DHTML可以更新用户界面,而且不用刷新整个界面,用户不知道打印机正在于服务器进行通信,AJAX包含XHTML和CSS标准的表示,使用DOM进行动态显示和交互。使用XMLHttpRequest与服务器进行异步通信,使用JavaScript绑定一切。
Java 开发人员可以用Java编写Applet的代码。
Bindows 是用JavaScript和DHTML开发的Web窗体框架。
Flex 为满足希望开发RIA的企业级程序员的需求而推出的表示服务器和应用程序框架。它的框架由MXML和ActionScript2.0及Flex类库组成。

【系统分析师之路】第十三章 软件体系结构_第24张图片

  • 企业服务总线ESB

ESB强调提供一条总线,把遗留系统封装成一个一个的服务给连接起来。通过服务总线的连接,,把使用到的部件高度标准化的过程,可以降低耦合程度
WebService强调对各种服务的封装;ESB强调利用一条总线,把所有的服务连接起来。ESB提供位置透明的消息路由和寻址服务。

【系统分析师之路】第十三章 软件体系结构_第25张图片
是由中间件技术实现并支持SOA的一组基础体系结构,支持异构环境中的服务,消息以及基于事件的交互。并且具有适当的服务级别和可管理性。它以一种无缝的非入侵方式使企业已有的系统具有全新的服务接口,并能够在部署环境中支持任何标准。
ESB的概念是从SOA发展而来的,它是一种为进行连接服务提供的标准化的通信基础结构。
ESB是传统中间件技术与XML,Web服务等技术结合的产物。使用ESB可在不改变现有基础结构的基础情况下让几代技术实现互操作。
ESB体系结构中强有力的构件:通信,连接,转换,可移植性和安全。

  • 中间件技术

中间件可以把几个不能互联互通的系统连接起来。在数据库和应用程序之间搭建起的桥梁就是数据库中间件。ODBC和JDBC是数据库中间件。远程过程调用,对象请求代理也属于中间件。使两台不在一起的计算机可相互交互。由中间件这个翻译来完成信息的扭转和转化的问题。业务中间件负责作一些负载均衡。中间件可以帮助分布式应用软件在不同的技术之间共享资源。

【系统分析师之路】第十三章 软件体系结构_第26张图片

【系统分析师之路】第十三章 软件体系结构_第27张图片

 【系统分析师之路】第十三章 软件体系结构_第28张图片

  • J2EE和.NET 

【系统分析师之路】第十三章 软件体系结构_第29张图片

Struts是一个基于J2EE平台的MVC框架,主要采用Servlet和JSP技术来实现。在Struts中,M由实现业务逻辑的Javabean构成;C由ActionServlet和Action来实现,V由JSP文件构成。 
通用语言运行环境其实就是Java体系中的虚拟机。NET框架里面就包含了虚拟机。ADO.NET是用来做数据库相关的操作的;而基础类库它是一种复用的机制,它把常用的职能做成了标准的类。
两者都是大同小异,但NET的移植性不如J2EE,因为J2EE有非常好的跨平台性。但NET支持的语言要多一些,其他方面相差无几。

【系统分析师之路】第十三章 软件体系结构_第30张图片

  • MVC和MVP

ASP开发相对比较简单,但是没有分层的概念只有View层,所以有人就提出了MVC
MVC模型跟分层模型非常的相似。分为主动和被动MVC模式。
主动MVC在变化的时候,将变化以消息从Model推送给View,而被动MVC则没有这个机制。主动MVC有观察者模式。
MVP是MVC的一个变种。所有的M和V的交互都要通过P。可以将业务逻辑放到P层。MVP比MVC更加方便进行测试。

【系统分析师之路】第十三章 软件体系结构_第31张图片

【系统分析师之路】第十三章 软件体系结构_第32张图片

你可能感兴趣的:(#,系统分析师---初见系分,系统分析师之路,软考系分)