怎样简单的解释软件架构的概念及其作用?
当你去了解一个东东的时候,第一步要做的,就应该去知道这个东东的定义,对于软件架构也是如此,经过网上查询和书籍的帮助,我大概理清了一个轮廓。
软件行业是一个热衷于制造‘名词’的行业,如果退回15年,估计没几个人知道‘软件架构’是什么,在上个世纪80年代,随着软件开发的规模不断扩大,软件开发成为一个行业,初期,随之而来的是越来越多的软件项目的失败,造成项目失败的原因很多,但主要集中在开发过程,所以软件工程应运而生,CMMI等流程标准也是一茬接着一茬的冒个不停。
在软件工程初具规模的时候,软件开发还是以数据结构+算法的形式存在,进入20世纪最后10年,随着面向对象技术、设计模式等在开发过程中的成功应用,软件架构也走进了大家的视野。
软件架构在定义上分为‘组成派’和‘决策派’两大阵营,分别描述如下:'组成派‘认为软件架构是将系统描述成计算组件及组件之间的交互。
它有两个非常明显的特点:关注架构实践的客体——软件,以软件本身作为描述对象。
分析了软件的组成,说明软件不是一个‘原子’意义上的整体,而是有不同的部分经过特定的接口进行连接组成的一个整体,这对软件开发来说很重要。
'决策派'认为软件架构包含了一系列的决策,主要包括:软件系统的组织选择组成系统的结构元素和它们之间的接口,以及当这些元素相互协作时所体现的行为用于指导这个系统组织的架构风格:这些元素以及它们的接口、协作和组合软件架构并不仅仅关注软件本身的结构和行为,还注重其他特性:使用、功能性、性能、弹性、重用、可理解、经济以及技术的限制和权衡等。
'决策派'有以下两个显著的特点:关注软件架构中的实体——人,以人的决策为描述对象。
归纳了软件架构决策的类型,指出架构决策不仅包括关于软件系统的组织、元素、子系统和架构风格等几类决策,还包括关于众多非功能性需求的决策。
按照‘组成派’的观点,软件架构关注的是软件整体的分割和交互,之所以分割,是因为不同的部分在逻辑或物理上相对独立,通过‘分而治之’的原则进行分割可以更好的理解整个系统,把握用户的需求,但是虽然整个软件可以分割成多个模块或子系统,但是模块和子系统之间的通信和交互也是很重要的,我想按照这种观点,架构师的主要任务是将软件分割成不同的模块,并定义模块之间的接口。
按照‘决策派’的观点,软件是一个在很多限制下产生的产品,这些限制包括用户和技术两方面,用户方面包括功能需求、性能需求、硬件需求等,技术方面包括技术选择、可扩展性、可重用性、可维护性等。
我想按照这中观点,架构师的主要任务就是作出上述个各种限制作出选择或决策。
《软件架构设计》 温昱
软件架构设计中,dll什么意思
“架构”一词最早来自建筑学,原意为建筑物设计和建造的艺术。
但是在软件工程领域,软件架构不是一个新名词,只是在早期的著作中人们将软件架构称为软件体系架构。
这就是架构的概念。
所谓架构,就是人们对一个结构内的元素及元素间关系的一种主观影射的产物。
系统架构的主要任务是界定系统级的功能与非功能要求、规划要设计的整体系统的特征、规划并设计实现系统级的各项要求的手段,同时利用各种学科技术完成子系统的结构构建。
在系统架构中,由于对软件越来越深入的依赖,软件架构的任务也体现出重要的作用。
而且系统架构与软件架构是紧密联系和相互依赖的。
1997年,Eberhadrt Rechtin 与MarkW Maier 在其论著中,为计算机科学总结了系统架构方面的实践成果,从而奠定了系统科学和系统架构在计算机科学中的基石: 无论何种系统架构应用领域,目的都是一样的,即完整地、高一致性的、平衡各种利弊的、有技术和市场前瞻性的设计系统和实施系统。
...
在应用软件开发架构中,多层设计的的含义是什么?
B/S结构:(Browser/Server,浏览器/服务器模式):是WEB兴起后的一种网络结构模式,WEB浏览器是客户端最主要的应用软件。
这种模式统一了客户端,将系统功能实现的核心部分集中到服务器上,简化了系统的开发、维护和使用。
客户机上只要安装一个浏览器(Browser),如Netscape Navigator或Internet Explorer,服务器安装Oracle、Sybase、Informix或 SQL Server等数据库。
浏览器通过Web Server 同数据库进行数据交互。
B/S最大的优点就是可以在任何地方进行操作而不用安装任何专门的软件。
只要有一台能上网的电脑就能使用,客户端零维护。
系统的扩展非常容易 分层也就分为客户端跟服务器吧!
企业的IT 架构是什么意思
1. 企业的IT 架构就是指支持企业业务运营的一整套信息系统的架构,完整的IT架构应该包括:各业务应用系统,比如PDM、SCM、CRM等;各管理应用系统,比如OA、ERP、HR等;支持与运行上述各应用系统的中间件软件、数据库软件、操作系统等;上述各软件系统运行的硬件设施,比如服务器、存储设备等;支持上述系统被正常访问的各种网络设备、机房环境设施等;保障上述软硬件系统安全运行的安全设施,包括各种软硬件级别的防火墙、防病毒、攻击工具,安保措施、供电保障等;保障上述所有设备与措施正常运转运营的一整套IT组织与IT管控体系。
2. 企业架构是对真实世界企业的业务流程和IT设施的抽象描述,它是包括企业战略、组织、职能、业务流程、IT系统、数据、网络部署等的完整、一体化描述,企业架构反映了企业业务的状况,并体现了业务与IT的映射关系,能明确各类IT设施对业务的支撑关系。
3. 企业架构领域原则上的关注点是企业范围内的业务需求的识别、规范、及优先级划分,企业架构如同战略规划,可以帮助企业执行业务战略规划及IT战略规划。
在业务战略方面,定义企业愿景/使命、目标/目的/驱动力、组织架构、职能及角色;在IT战略方面,定义企业的业务架构、数据架构、应用架构、和技术架构。
数据结构的起源作用和意义
数据结构的起源作用和意义:1、一般认为,一个数据结构是由数据元素依据某种逻辑联系组织起来的。
对数据元素间逻辑关系的描述称为数据的逻辑结构;数据必须在计算机内存储,数据的存储结构是数据结构的实现形式,是其在计算机内的表示;此外讨论一个数据结构必须同时讨论在该类数据上执行的运算才有意义。
一个逻辑数据结构可以有多种存储结构,且各种存储结构影响数据处理的效率。
2、在许多类型的程序的设计中,数据结构的选择是一个基本的设计考虑因素。
许多大型系统的构造经验表明,系统实现的困难程度和系统构造的质量都严重的依赖于是否选择了最优的数据结构。
许多时候,确定了数据结构后,算法就容易得到了。
有些时候事情也会反过来,我们根据特定算法来选择数据结构与之适应。
不论哪种情况,选择合适的数据结构都是非常重要的。
3、选择了数据结构,算法也随之确定,是数据而不是算法是系统构造的关键因素。
这种洞见导致了许多种软件设计方法和程序设计语言的出现,面向对象的程序设计语言就是其中之一。
4、数据结构是计算机存储、组织数据的方式。
数据结构是指相互之间存在一种或多种特定关系的数据元素的集合。
通常情况下,精心选择的数据结构可以带来更高的运行或者存储效率。
数据结构往往同高效的检索算法和索引技术有关。
...
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语义模型的标志性的语言,也很难想象能在当前业务架构发挥太大影响。
但如果真如它所声称那样,广泛地改变着信息的结构。
那么对软件架构也会有深远影响。
编写软件架构文档说明,第 1 部分: 什么是软件架构,为什么为软件...
引言 软件架构是一门学科,开始于 20 世纪 70 年代。
面对不断增加的复杂性和开发复杂实时系统的压力,作为主流系统工程和软件开发的基本构造,软件架构应运而生。
与任何其他久经考验的学科一样,软件架构在诞生之初也面临许多挑战。
软件架构表示系统的结构和行为方面。
在早期为软件架构编写文档说明时,所使用的文本和图解表达常常不足或者不够精确。
所需的是某种一致并得到充分理解的伪(或元)语言,以便将对软件架构进行表示和编写文档说明的不同方式统一起来。
在学术研究的推动下,在用于开发有效软件架构文档说明的最佳实践和指导原则方面,工程和计算机科学领域已取得了长足的发展。
在本系列中,您将了解如何编写软件架构文档说明。
了解编写文档说明的不同方面:系统上下文、体系结构概述、功能体系结构、操作体系结构和体系结构决策。
在这第一篇文章中,了解软件架构是什么,以及为该学科的不同方面编写文档说明的重要性。
回页首软件架构不同的研究人员已解释了软件架构是什么,并且他们对有关如何最好地表示软件系统的体系结构具有不同的观点。
其中没有哪一种解释是错误的;每种解释都具有自己的价值。
Bass L 等人抓住了软件架构的本质: “程序或计算系统的软件架构是该系统的结构,包括软件组件、那些组件的外部可见的属性,以及那些组件之间的关系” 。
此定义重点关注由粗粒度的构造(软件组件)所构成的体系结构,可以将这些构造看作是体系结构的构建块。
每个软件组件或体系结构构建块具有某些外部可见的属性,这是它向其他体系结构构建块公开的属性。
软件组件的内部设计和实现细节不是系统的其他部分所关心的内容,系统的其他部分只是将某个特定组件视为一个黑盒。
该黑盒具有某些所公开的属性,其他软件组件可以使用这些属性来共同实现业务或 IT 目标。
软件架构在恰当的粒度级别标识体系结构构建块。
软件架构还标识那些构建块如何彼此相关,并进行文档记录。
与软件工程相关的体系结构涉及到将单个系统分解或划分为一组可迭代地、渐进地和独立地构造的部分。
各个部分彼此具有显式的关系。
当组合在一起时,各个部分就形成了系统、企业或应用程序的体系结构。
关于体系结构与设计之间的区别,存在一些混淆。
正如 Clements P 等人 所指出的,所有体系结构都是设计,但不是所有设计都是体系结构。
需要绑定以使系统满足其功能性和非功能性需求和目标的设计本质上是体系结构。
体系结构将体系结构构建块视为黑盒,而设计则处理体系结构构建块的配置、自定义和内部工作。
体系结构将软件组件与其外部属性绑定在一起。
设计通常要比体系结构松散得多,因为它允许以更多的方式遵守组件的外部属性。
设计还考虑用于实现组件内部细节的各种方法。
软件架构可以递归地使用。
请考虑一个属于某个系统的软件架构组成部分的软件组件 (C1)。
软件架构师将该组件及其应该公开的属性、功能和非功能特性及其与其他软件组件的关系交给系统设计人员。
设计人员在分析软件组件 C1 之后,决定将该组件分解为更细粒度的组件(C11、C12 和 C13),其中每个组件提供可重用的功能,这些功能将用于实现 C1 的要求属性。
设计人员详细设计了 C11、C12、C13 及其接口。
此时,对设计人员来说,C11、C12 和 C13 是体系结构构造(或组件);其中每个构造具有显式定义的外部接口。
对设计人员来说,C11、C12 和 C13 是软件组件 C1 的体系结构,并且这些构造需要进一步的改进和设计,以处理它们的内部实现。
通过将大型、复杂的系统划分为小型的构成部分并集中于每个部分,可以递归地使用体系结构。
体系结构使用共同满足行为和质量目标的体系结构构建块将系统绑定在一起。
参与者必须能够理解体系结构。
因此必须为体系结构编写足够的文档说明,下一个部分将对此进行讨论。
回页首编写体系结构文档说明的重要性参与者:体系结构的下游设计和实现用户。
为体系结构的定义、维护和增强功能进行投资的人。
向参与者传达您正在构建的系统蓝图的关键是为系统体系结构编写文档说明。
软件架构通过不同的视图进行表示——功能、操作、决策等等。
没有任何单一视图能够表示整个体系结构。
并非所有视图都需要表示特定企业或问题领域的系统体系结构。
架构师将确定足以表示所需软件架构范畴的视图集。
通过编写不同视图的文档说明并捕获每个部分的开发,您可以向开发团队和业务及 IT 参与者传达有关该不断发展的系统的信息。
软件架构具有一组其预期要满足的业务和工程目标。
体系结构的文档说明可以向参与者传达这些目标将如何实现。
为体系结构的各个方面编写文档说明,有助于架构师弥补用白板描述解决方案(使用框线图方法)与以对下游设计和实现团队有意义的方式表示解决方案之间众所周知的差距。
体系结构的框线图留下了大量有待解释的空间。
需要揭示的细节通常隐藏并令人混淆地固守在那些框线背后。
文档说明还可以促进创建切合实际并且可以系统开发(例如遵循标准模板)的体系结构构件。
作为一门学科,软件架构是非常成熟的。
您可以利用最佳实践和指导...