软件系统架构简介
转自:http://wanghf0218.iteye.com/blog/258084软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面..
转自:http://wanghf0218.iteye.com/blog/258084
软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口_(计算机科学)来实现。
软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。
软件构架是一个容易理解的概念,多数工程师(尤其是经验不多的工程师)会从直觉上来认识它,但要给出精确的定义很困难。特别是,很难明确地区分设计和构架:构架属于设计的一方面,它集中于某些具体的特征。
在“软件构架简介”中,David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次:“在计算的算法和数据结构之外,设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构;通信、同步和数据访问的协议;设计元素的功能分配;物理分布;设计元素的组成;定标与性能;备选设计的选择。
但构架不仅是结构;IEEE Working Group onArchitecture把其定义为“系统在其环境中的最高层概念”。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑,而且还在系统的用户环境和开发环境中对系统进行整体考虑,即同时注重对外部的考虑。
在Rational Unified Process 中,软件系统的构架(在某一给定点)是指系统重要构件的组织或结构,这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
从和目的、主题、材料和结构的联系上来说,软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管理软件产品的高级设计。软件架构师定义和设计软件的模块化,模块之间的交互,用户界面风格,对外接口方法,创新的设计特性,以及高层事物的对象操作、逻辑和流程。
一般而言,软件系统的架构(Architecture)有两个要素:
它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的,而这些元件如何形成、相互之间如何发生作用,则是关于这个系统本身结构的重要信息。
详细地说,就是要包括架构元件(ArchitectureComponent)、联结器(Connector)、任务流(Task-flow)。所谓架构元素,也就是组成系统的核心"砖瓦",而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果,任务流则描述系统如何使用这些元件和联结器完成某一项需求。
建造一个系统所作出的最高层次的、以后难以更改的,商业的和技术的决定。
建造一个系统之前会有很多的重要决定需要事先作出,而一旦系统开始进行详细设计甚至建造,这些决定就很难更改甚至无法更改。显然,这样的决定必定是有关系统设计成败的最重要决定,必须经过非常慎重的研究和考察。
架构的目标是什么
正如同软件本身有其要达到的目标一样,架构设计要达到的目标是什么呢?一般而言,软件架构设计要达到如下的目标:
可靠性(Reliable)。软件系统对于用户的商业经营和管理来说极为重要,因此软件系统必须非常可靠。
安全行(Secure)。软件系统所承担的交易的商业价值极高,系统的安全性非常重要。
可扩展性(Scalable)。软件必须能够在用户的使用率、用户的数目增加很快的情况下,保持合理的性能。只有这样,才能适应用户的市场扩展得可能性。
可定制化(Customizable)。同样的一套软件,可以根据客户群的不同和市场需求的变化进行调整。
可扩展性(Extensible)。在新技术出现的时候,一个软件系统应当允许导入新技术,从而对现有系统进行功能和性能的扩展
可维护性(Maintainable)。软件系统的维护包括两方面,一是排除现有的错误,二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费
客户体验(Customer Experience)。软件系统必须易于使用。
市场时机(Time to Market)。软件用户要面临同业竞争,软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。
架构的种类
根据我们关注的角度不同,可以将架构分成三种:
逻辑架构:软件系统中元件之间的关系,比如用户界面,数据库,外部系统接口,商业逻辑元件,等等。
物理架构:软件元件是怎样放到硬件上的。
系统架构:系统的非功能性特征,如可扩展性、可靠性、强壮性、灵活性、性能等。
系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识,这一工作无疑是架构设计工作中最为困难的工作。
此外,从每一个角度上看,都可以看到架构的两要素:元件划分和设计决定。
首先,一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上,以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献,是非常重要的信息。
其次,进行软件设计需要做出的决定中,必然会包括逻辑结构、物理结构,以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出,就很难更改的。
根据作者的经验,一个基于数据库的系统架构,有多少个数据表,就会有多少页的架构设计文档。比如一个中等的数据库应用系统通常含有一百个左右的数据表,这样的一个系统设计通常需要有一百页左右的架构设计文档。
构架描述
为了讨论和分析软件构架,必须首先定义构架表示方式,即描述构架重要方面的方式。在 Rational Unified Process 中,软件构架文档记录有这种描述。
我们决定以多种构架视图来表示软件构架。每种构架视图针对于开发流程中的涉众(例如最终用户、设计人员、管理人员、系统工程师、维护人员等)所关注的特定方面。
构架视图显示了软件构架如何分解为构件,以及构件如何由连接器连接来产生有用的形式,由此记录主要的结构设计决策。这些设计决策必须基于需求以及功能、补充和其他方面的约束。而这些决策又会在较低层次上为需求和将来的设计决策施加进一步的约束。
构架由许多不同的构架视图来表示,这些视图本质上是以图形方式来摘要说明“在构架方面具有重要意义”的模型元素。在 Rational Unified Process 中,您将从一个典型的视图集开始,该视图集称为“4+1 视图模型”。它包括:(1)、用例视图:包括用例和场景,这些用例和场景包括在构架方面具有重要意义的行为、类或技术风险。它是用例模型的子集。(2)、逻辑视图:包括最重要的设计类、从这些设计类到包和子系统的组织形式,以及从这些包和子系统到层的组织形式。它还包括一些用例实现。它是设计模型的子集。(3)、实施视图:包括实施模型及其从模块到包和层的组织形式的概览。 同时还描述了将逻辑视图中的包和类向实施视图中的包和模块分配的情况。它是实施模型的子集。(4)、进程视图:包括所涉及任务(进程和线程)的描述,它们的交互和配置,以及将设计对象和类向任务的分配情况。只有在系统具有很高程度的并行时,才需要该视图。在 Rational Unified Process 中,它是设计模型的子集。(5)、配置视图:包括对最典型的平台配置的各种物理节点的描述以及将任务(来自进程视图)向物理节点分配的情况。只有在分布式系统中才需要该视图。它是部署模型的一个子集。(6)、构架视图记录在软件构架文档中。您可以构建其他视图来表达需要特别关注的不同方面:用户界面视图、安全视图、数据视图等等。对于简单系统,可以省略 4+1 视图模型中的一些视图。
构架重点
虽然以上视图可以表示系统的整体设计,但构架只同以下几个具体方面相关:
模型的结构,即组织模式,例如分层。
基本元素,即关键用例、主类、常用机制等,它们与模型中的各元素相对。
几个关键场景,它们表示了整个系统的主要控制流程。
记录模块度、可选特征、产品线状况的服务。
构架视图在本质上是整体设计的抽象或简化,它们通过舍弃具体细节来突出重要的特征。在考虑以下方面时,这些特征非常重要:
系统演进,即进入下一个开发周期。
在产品线环境下复用构架或构架的一部分。
评估补充质量,例如性能、可用性、可移植性和安全性。
向团队或分包商分配开发工作。
决定是否包括市售构件。
插入范围更广的系统。
构架模式
构架模式是解决复发构架问题的现成形式。构架框架或构架基础设施(中间件)是可以在其上构建某种构架的构件集。许多主要的构架困难应在框架或基础设施中进行解决,而且通常针对于特定的领域:命令和控制、MIS、控制系统等等。
转自:http://interhb.cnhubei.com/2010-06/02/cms363247article.shtml
软件系统架构(Software Architecture)是关于软件系统的结构、行为、属性、组成要素及其之间交互关系的高级抽象。任何软件开发项目,都会经历需求获取、系统分析、系统设计、编码研发、系统运维等常规阶段,软件系统架构设计就位于系统分析和系统设计之间。做好软件系统架构,可以为软件系统提供稳定可靠的体系结构支撑平台,还可以支持最大粒度的软件复用,降低开发运维成本。
软件系统架构设计方法步骤
基于体系架构的软件设计模型把软件过程划分为体系架构需求、设计、文档化、复审、实现和演化6个子过程,现逐一简要概述如下。
体系架构需求。即将用户对软件系统功能、性能、界面、设计约束等方面的期望(即“需求”)进行获取、分析、加工,并将每一个需求项目抽象定义为构件(类的集合)。
体系架构设计。即采用迭代的方法首先选择一个合适的软件体系架构风格(如C/S、B/S、N层、管道过滤器风格、C2风格等)作为架构模型,然后将需求阶段标识的构件映射到模型中,分析构件间的相互作用关系,最后形成量身订做的软件体系架构。
体系架构文档化。即生成用户和研发人员能够阅读的体系架构规格说明书和体系架构设计说明书。
体系架构复审。即及早发现体系架构设计中存在的缺陷和错误,及时予以标记和排除。
体系架构实现。即设计人员开发出系统构件,按照体系架构设计规格说明书进行构件的关联、合成、组装和测试。
体系架构演化。如果用户需求发生了变化,则需相应地修改完善优化、调整软件体系结构,以适应新的变化了的软件需求。
以上6个子过程是软件系统架构设计的通用方法步骤。但由于软件需求、现实情况的变化是难以预测的,这6个子过程往往是螺旋式向前推进。
软件系统架构设计常用模式
目前软件领域广泛使用的软件系统架构模式,主要有层次化架构设计、企业集成架构设计、嵌入式架构设计和面向服务的架构设计模式。
层次化架构设计模式。分层设计是一种最为常见的架构设计方案,能有效地使系统结构清晰、设计简化。MVC模式是当今最为流行的多层设计模式。该模式把一个应用的输入、处理、输出流程进行分离并抽象为控制器(Controller)、模型(Model)、视图(View)三个模块,实现了业务逻辑层、数据库访问层和用户界面层之间在彼此分离的同时仍保持松散的耦合关系,增加了灵活性和可扩展性。我们常见的C/S架构、B/S架构、N层架构都是层次化架构设计的表现形式。
企业集成架构设计模式。该模式不仅为企业在异构分布式环境下(操作系统、网络、数据库)的业务应用提供了一致的信息访问和交互手段,而且为各类业务应用提供了有效的通信、信息集成、应用集成、维护开发、运行管理等服务。目前最著名的企业集成架构设计包括:CORBA、COM+、J2EE、WebService等。
嵌入式架构设计模式。该模式具备良好的可配置性、可管理性、可扩展性、时效性等性能指标。目前业界主流的嵌入式操作系统都是特定领域专用的,其中包括:WinCE、Linux、ECOS、EPOC、LynxOS、VxWorks等。
面向服务的架构设计模式。该模式将业务应用按照一定的粒度和原则划分成为统一标准和统一格式的服务,使企业可以按照模块化的方式添加新服务或更新现有服务,有助于打破信息孤岛,促进企业系统集成、资源共享。该模式包括服务注册表模式和企业服务总线模式两类。
软件系统架构设计实践
软件系统架构设计是一项非常复杂的工作任务。如何才能做好软件系统架构设计呢?笔者认为需要做好以下几项工作:
树立软件系统架构的意识。设计人员不能局限在算法和数据结构上,而是要树立和不断强化软件系统整体架构的意识,学会运用多层架构的视角和观念去分析设计软件。在多层架构的实践上,通过MVC模式实现软件多层结构,层和层之间要做到职责清晰、互相独立、耦合关系松散;在模块设计原则上,要尽量体现“高内聚、低耦合”的思想。
高度重视软件设计模式。软件设计模式是设计人员在长期开发实践中总结出来的,其他设计人员可借助这些模式加快软件设计进程,降低开发风险。所以,设计人员应高度重视设计模式思想,切勿滞留在编码的层面,应不断总结经验,积极尝试运用软件设计模式的思想去提出问题、分析问题、解决问题,提高自身开发软件的水平。
形成自身的软件架构风格。软件系统架构设计的核心目标是实现体系架构级别的软件复用。这就需要设计人员一方面不断学习钻研不同应用领域中软件架构的惯用模式、思维、风格;另一方面要借鉴吸收先进理念,积极探索实践,最终形成自身独特的软件架构风格。
充分了解用户需求,做好全局架构设计。要做好软件系统的架构设计,不能急于求成,首先,要全面准确地收集到用户需求,对整个系统功能形成清晰完整的认识;其次,针对整个软件系统做好全局架构设计工作,从而避免因考虑不周或片面理解带来的失误。
转自:http://space.itpub.net/12639375/viewspace-167399
系统设计架构应考虑的因素
一、与构架有关的几个基本概念:
1、模块(module):一组完成指定功能的语句,包括:输入、输出、逻辑处理功能、内部信息、运行环境(与功能对应但不是一对一关系)。
2、组件(component):系统中相当重要的、几乎是独立的可替换部分,它在明确定义的构架环境中实现确切的功能。
3、模式(pattern):指经过验证,至少适用于一种实用环境(更多时候是好几种环境)的解决方案模板(用于结构和行为。在 UML 中:模式由参数化的协作来表示,但 UML 不直接对模式的其他方面(如使用结果列表、使用示例等,它们可由文本来表示)进行建模。存在各种范围和抽象程度的模式,例如,构架模式、分析模式、设计模式和代码模式或实施模式。模式将可以帮助我们抓住重点。构架也是存在模式的。比如,对于系统结构设计,我们使用层模式;对于分布式系统,我们使用代理模式(通过使用代理来替代实际的对象,使程序能够控制对该对象的访问);对于交互系统,我们使用MVC(M模型(对象)/V视图(输出管理)/C控制器(输入处理))模式。模式是针对特定问题的解,因此,我们也可以针对需求的特点采用相应的模式来设计构架。
4、构架模式(architectural pattern):表示软件系统的基本结构组织方案。它提供了一组预定义的子系统、指定它们的职责,并且包括用于组织其间关系的规则和指导。
5、层(layer):对模型中同一抽象层次上的包进行分组的一种特定方式。通过分层,从逻辑上将子系统划分成许多集合,而层间关系的形成要遵循一定的规则。通过分层,可以限制子系统间的依赖关系,使系统以更松散的方式耦合,从而更易于维护。(层是对构架的横向划分,分区是对构架的纵向划分)。
6、系统分层的几种常用方法:
1)常用三层服务:用户层、业务逻辑层、数据层;2)多层结构的技术组成模型:表现层、中间层、数据层;3)网络系统常用三层结构:核心层、汇聚层和接入层;4)RUP典型分层方法:应用层、专业业务层、中间件层、系统软件层;5)基于Java的B/S模式系统结构:浏览器端、服务器端、请求接收层、请求处理层;6) 某六层结构:功能层(用户界面)、模块层、组装层(软件总线)、服务层(数据处理)、数据层、核心层;
7、构架(Architecture,愿意为建筑学设计和建筑物建造的艺术与科学): 在RUP中的定义:软件系统的构架(在某一给定点)是指系统重要构件的组织或结构,这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互;《软件构架实践》中的定义:某个软件或者计算系统的软件构架即组成该系统的一个或者多个结构,他们组成软件的各个部分,形成这些组件的外部可见属性及相互间的联系;IEEE 1471-2000中的定义:the fundamental organization of a system emboided in its components,their relationships to each other,and to the enviroment and the principles guiding its design and evolution,构架是系统在其所处环境中的最高层次的概念。软件系统的构架是通过接口交互的重要构件(在特定时间点)的组织或结构,这些构件又由一些更小的构件和接口组成。(“构架”可以作为名词,也可作为动词,作为动词的“构架”相当于“构架设计”)
8、构架的描述方式:“4+1”视图(用例视图、设计视图、实现视图、过程视图、配置视图)是一个被广为使用的构架描述的模型;RUP过程的构架描述模板在“4+1”视图的基础上增加了可选的数据视图(从永久性数据存储方面来对系统进行说明);HP公司的软件描述模板也是基于“4+1”视图。
9、结构:软件构架是多种结构的体现,结构是系统构架从不同角度观察所产生的视图。就像建筑物的结构会随着观察动机和出发点的不同而有多种含义一样,软件构架也表现为多种结构。常见的软件结构有:模块结构、逻辑或概念结构、进程或协调结构、物理结构、使用结构、调用结构、数据流、控制流、类结构等等。
二、构架设计应考虑的因素概揽:
模块构架设计可以从程序的运行时结构和源代码的组织结构方面考虑。
1、程序的运行时结构方面的考虑:1)需求的符合性:正确性、完整性;功能性需求、非功能性需求;2) 总体性能(内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响);3)运行可管理性:便于控制系统运行、监视系统状态、错误处理;模块间通信的简单性;与可维护性不同;4)与其他系统接口兼容性;5)与网络、硬件接口兼容性及性能;6)系统安全性;7)系统可靠性;8)业务流程的可调整性;9)业务信息的可调整性10)使用方便性11) 构架样式的一致性
注:运行时负载均衡可以从系统性能、系统可靠性方面考虑。
2、源代码的组织结构方面的考虑:1)开发可管理性:便于人员分工(模块独立性、开发工作的负载均衡、进度安排优化、预防人员流动对开发的影响)、利于配置管理、大小的合理性与适度复杂性;2)可维护性:与运行可管理性不同;3)可扩充性:系统方案的升级、扩容、扩充性能;4)可移植性:不同客户端、应用服务器、数据库管理系统;5)需求的符合性(源代码的组织结构方面的考虑)。
其它参考:
1、http://space.itpub.net/12639375/viewspace-167396
2、http://space.itpub.net/12639375/viewspace-167394
3、http://space.itpub.net/12639375/viewspace-167393
4、http://space.itpub.net/12639375/viewspace-167388
5、http://space.itpub.net/12639375/viewspace-167378
更多推荐
所有评论(0)