软件构架、架构、框架区别是什么?
引言 软件架构是一门学科,开始于 20 世纪 70 年代。
面对不断增加的复杂性和开发复杂实时系统的压力,作为主流系统工程和软件开发的基本构造,软件架构应运而生。
与任何其他久经考验的学科一样,软件架构在诞生之初也面临许多挑战。
软件架构表示系统的结构和行为方面。
在早期为软件架构编写文档说明时,所使用的文本和图解表达常常不足或者不够精确。
所需的是某种一致并得到充分理解的伪(或元)语言,以便将对软件架构进行表示和编写文档说明的不同方式统一起来。
在学术研究的推动下,在用于开发有效软件架构文档说明的最佳实践和指导原则方面,工程和计算机科学领域已取得了长足的发展。
在本系列中,您将了解如何编写软件架构文档说明。
了解编写文档说明的不同方面:系统上下文、体系结构概述、功能体系结构、操作体系结构和体系结构决策。
在这第一篇文章中,了解软件架构是什么,以及为该学科的不同方面编写文档说明的重要性。
回页首软件架构不同的研究人员已解释了软件架构是什么,并且他们对有关如何最好地表示软件系统的体系结构具有不同的观点。
其中没有哪一种解释是错误的;每种解释都具有自己的价值。
Bass L 等人抓住了软件架构的本质: “程序或计算系统的软件架构是该系统的结构,包括软件组件、那些组件的外部可见的属性,以及那些组件之间的关系” 。
此定义重点关注由粗粒度的构造(软件组件)所构成的体系结构,可以将这些构造看作是体系结构的构建块。
每个软件组件或体系结构构建块具有某些外部可见的属性,这是它向其他体系结构构建块公开的属性。
软件组件的内部设计和实现细节不是系统的其他部分所关心的内容,系统的其他部分只是将某个特定组件视为一个黑盒。
该黑盒具有某些所公开的属性,其他软件组件可以使用这些属性来共同实现业务或 IT 目标。
软件架构在恰当的粒度级别标识体系结构构建块。
软件架构还标识那些构建块如何彼此相关,并进行文档记录。
与软件工程相关的体系结构涉及到将单个系统分解或划分为一组可迭代地、渐进地和独立地构造的部分。
各个部分彼此具有显式的关系。
当组合在一起时,各个部分就形成了系统、企业或应用程序的体系结构。
关于体系结构与设计之间的区别,存在一些混淆。
正如 Clements P 等人 所指出的,所有体系结构都是设计,但不是所有设计都是体系结构。
需要绑定以使系统满足其功能性和非功能性需求和目标的设计本质上是体系结构。
体系结构将体系结构构建块视为黑盒,而设计则处理体系结构构建块的配置、自定义和内部工作。
体系结构将软件组件与其外部属性绑定在一起。
设计通常要比体系结构松散得多,因为它允许以更多的方式遵守组件的外部属性。
设计还考虑用于实现组件内部细节的各种方法。
软件架构可以递归地使用。
请考虑一个属于某个系统的软件架构组成部分的软件组件 (C1)。
软件架构师将该组件及其应该公开的属性、功能和非功能特性及其与其他软件组件的关系交给系统设计人员。
设计人员在分析软件组件 C1 之后,决定将该组件分解为更细粒度的组件(C11、C12 和 C13),其中每个组件提供可重用的功能,这些功能将用于实现 C1 的要求属性。
设计人员详细设计了 C11、C12、C13 及其接口。
此时,对设计人员来说,C11、C12 和 C13 是体系结构构造(或组件);其中每个构造具有显式定义的外部接口。
对设计人员来说,C11、C12 和 C13 是软件组件 C1 的体系结构,并且这些构造需要进一步的改进和设计,以处理它们的内部实现。
通过将大型、复杂的系统划分为小型的构成部分并集中于每个部分,可以递归地使用体系结构。
体系结构使用共同满足行为和质量目标的体系结构构建块将系统绑定在一起。
参与者必须能够理解体系结构。
因此必须为体系结构编写足够的文档说明,下一个部分将对此进行讨论。
回页首编写体系结构文档说明的重要性参与者:体系结构的下游设计和实现用户。
为体系结构的定义、维护和增强功能进行投资的人。
向参与者传达您正在构建的系统蓝图的关键是为系统体系结构编写文档说明。
软件架构通过不同的视图进行表示——功能、操作、决策等等。
没有任何单一视图能够表示整个体系结构。
并非所有视图都需要表示特定企业或问题领域的系统体系结构。
架构师将确定足以表示所需软件架构范畴的视图集。
通过编写不同视图的文档说明并捕获每个部分的开发,您可以向开发团队和业务及 IT 参与者传达有关该不断发展的系统的信息。
软件架构具有一组其预期要满足的业务和工程目标。
体系结构的文档说明可以向参与者传达这些目标将如何实现。
为体系结构的各个方面编写文档说明,有助于架构师弥补用白板描述解决方案(使用框线图方法)与以对下游设计和实现团队有意义的方式表示解决方案之间众所周知的差距。
体系结构的框线图留下了大量有待解释的空间。
需要揭示的细节通常隐藏并令人混淆地固守在那些框线背后。
文档说明还可以促进创建切合实际并且可以系统开发(例如遵循标准模板)的体系结构构件。
作为一门学科,软件架构是非常成熟的。
您可以利用最佳实践和指导...
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语义模型的标志性的语言,也很难想象能在当前业务架构发挥太大影响。
但如果真如它所声称那样,广泛地改变着信息的结构。
那么对软件架构也会有深远影响。
门户网站的技术架构怎样设计方案
架构师的职责主要有如下4条:1、确认需求在项目开发过程中,架构师是在需求规格说明书完成后介入的,需求规格说明书必须得到架构师的认可。
架构师需要和分析人员反复交流,以保证自己完整并准确地理解用户需求。
2、系统分解依据用户需求,架构师将系统整体分解为更小的子系统和组件,从而形成不同的逻辑层或服务。
随后,架构师会确定各层的接口,层与层相互之间的关系。
架构师不仅要对整个系统分层,进行“纵向”分解,还要对同一逻辑层分块,进行“横向”分解。
软件架构师的功力基本体现于此,这是一项相对复杂的工作。
3、技术选型架构师通过对系统的一系列的分解,最终形成了软件的整体架构。
技术选择主要取决于软件架构。
WebServer运行在Windows上还是Linux上?数据库采用MSSql、Oracle还是Mysql?需要不需要采用MVC或者Spring等轻量级的框架?前端采用富客户端还是瘦客户端方式?类似的工作,都需要在这个阶段提出,并进行评估。
架构师对产品和技术的选型仅仅限于评估,没有决定权,最终的决定权归项目经理。
架构师提出的技术方案为项目经理提供了重要的参考信息,项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡,最终进行确认。
4、制定技术规格说明架构师在项目开发过程中,是技术权威。
他需要协调所有的开发人员,与开发人员一直保持沟通,始终保证开发者依照它的架构意图去实现各项功能。
架构师不仅要保持与开发者的沟通,也需要与项目经理、需求分析员,甚至与最终用户保持沟通。
所以,对于架构师来讲,不仅有技术方面的要求,还有人际交流方面的要求。
设计人员在做软件架构设计的时候易忽略哪些重要问题呢?
很多的设计人员在做软件架构设计的时候忽略了几个重要的问题: 1.软件的架构在大的方向上是固定的 这种固定依据某些基本固定的软件模式(包括设计模式、编码模式或者某些特定的约定)来强化和固定。
这使得软件开发在某种程度上具有某些可以明显看得到的风格,这个风格被整个的项目贯穿和坚持,这样当我们进入通常可怕的维护或者调整的时候,我们不会害怕我们在很多种不同的实现中常常迷失了方向。
2.软件的架构在具体的应用中可以适度的可控灵活 毫无疑问,软件设计开发不可能没有例外,在某种程度上保留一些适度的灵活时必要的。
一方面,它符合软件开发的实际;一方面,适度的可控灵活体现了一种对实现者的尊重和信任。
然而,如何实现可控的灵活呢?通常,我认为可以考虑有限种类的设计选择并通过有色彩的图形来表明这种可选择性。
但即便如此,设计者很重要的要考虑这些不同选择之间的关系,以及这些选择和整体设计的兼容性,这个时候,面向接口的设计和适度的“粘合”设计是必要的。
来源:www.examda.com 3.架构设计的支撑 架构设计通常会涉及到一些支撑设计,这些设计和实现水准直接的体现了系统的最有价值的部分,更细的划分我们应该可以看到性能和结构相关的部分,以及必要的基础类。
通常,作为设计人员,我们应该能够设计并实现系统的性能、结构、扩展、粘合等部分的工作,这部分的工作通常不应该离开设计人员的控制和把握,这些代码的书写或者至少积极的关注是设计人员必要的素质.我们不应该让更多的看到我们无法写出代码来(我也反对没有分工什么都做的设计人员!),实际上,这是软件最困难也是最有乐趣的地方。
特别是在测试结果中发现这些设计实现带来的性能的极大提高的时候是非常有成就感的事情。
至于基础类,应该是尽可能的减少依赖和耦合的。
架构设计的支撑要尽可能的对客户程序员隐藏不必要的中间细节,对基础类要尽量简单、稳定并真正需要。
通常,新兴的技术会用在架构设计的支撑设计里面并被封装以隐藏具体的实现,而通盘应用新兴技术的风险是巨大的,并且对人员的获得也是问题。
有些技术是可以提供替代技术的,一些新兴的技术实现也是可以参考的(但未必采用她的实现)。
要记住软件开发是需要速度、质量、可维护而不是技术表演,这个度应该由分析设计人员负责任的来把握。
软件架构的艺术之软件架构的误区是什么呢?
误区一:不知道架构与设计的区别 虽然许多从业人员的头衔为“架构师”,但是他们并不能回答下面的一些问题: 系统架构与设计有区别吗?区别在哪里呢? 什么样的人能满足系统架构师的要求? 什么样的人能满足设计人员的要求? 一般地,架构师都是技术出身,他们可能长期从事过编码、设计领域的工作。
很自然,他们可能认为设计、编码工作就是软件架构的一切。
但是真正的架构师必须有长期设计的工作经验,并在系统化的提升之后才可能成为合格的架构师。
他们需要考虑商业概念、商业运作、系统结构、结构优化等这些更为宏观的方面,然后选择那些最经典的实践参考模型,才能构建出合格的软件架构。
误区二:不知道系统架构该如何做 让我们回到日常的软件系统活动中来。
其实通过一些实践,我们已经逐步建立起一些对软件架构及设计活动的认知。
直觉和经验告诉我们,一个软件系统或软件架构在构建之初就给架构师留下了充分的创作空间。
但是,一个单纯为了一系列功能的实现而构建的架构,还不能称作严格意义上的软件架构。
一个真正意义上的软件架构,是需要考虑如下的一些系统要求: 好的系统,一定是一个架构灵活的系统。
我们需要一个方便维护的系统来满足可维护性的要求。
当系统用户数量随着业务的扩展而增加,我们的架构还能应对。
架构设计人员能够确定当前运行系统的下一个时刻的状态。
最大峰值时,系统还能保持运行,系统性能不会明显下降。
我们的系统能够与其他系统进行集成。
但是许多架构师并不知道在系统架构构建时期,他们应该完整考虑哪些因素,应该采用怎样的手段,应该完成什么任务,才能够构建出一个久经考验的系统架构。
误区三:只盲目追随业界通用框架 事实上,我们在工作中,也许还会听到这样一些声音: 我们要解决一个分布式的问题,CORBA很好而且还很标准化,用这个架构就行了。
我们要做一个电子政务的应用,J2EE框架不就很流行嘛,就选这个架构吧。
我们要做一个车载电子系统平台,OSGI就是一个好的嵌入式平台,就用它吧。
上述只不过是我们经常能见到的一种对框架或中间件的依赖现象。
如果我们每开发一个应用或产品,都要自己手工设计一个框架,确实是一件令人痛苦的事。
当然,我们承认现在有很多产品化的、很成熟的框架或中间件,确实极大方便了我们的应用及产品开发。
这似乎给人们一种错觉,以为应用和产品开发是一件很容易的事。
但是,我们也要清醒地认识到这些框架或中间件背后实际上隐藏了很多技术、设计、应用场景,也就是说为设计开发人员隐藏了很多系统设计开发的复杂性。
于是当产品开发或项目结束时,你就可能听到这样的抱怨: 我们应用CORBA架构的系统在运行时速度很慢,而且很复杂,出了问题却不知道症结在哪里。
我们的J2EE架构让我们使用了大量的EJB和JavaBean,简直就是构件的海洋,太难维护了。
我们的车载电子系统根本就不工作,打开汽车车门,插入车钥匙,点火,需要等上几十秒,电子系统都没有反应。
所以,系统架构并不是简单地应用一个流行的、通用的、看似很唬人的某某通用框架,从而使自己的系统过分地依赖流行的框架或中间件,同时把所有的系统级质量要求统统扔给这些框架或中间件,以寄希望于这些通用框架代替你去思考和处理你应该解决的问题。
实际上,我们应该寄希望于自己来构建系统架构,使其能够做到: 即便是最大峰值运行时,系统也要有很好的性能。
当系统面对大量并发事件时,能够很好地进行调度和并行处理。
当系统资源使用频繁且负荷增加时,系统能够很好地协调资源的运用。
当我们设计的重要实时系统(例如航空管制系统)出现错误时,能快速实现系统的自我恢复。
这些都是软件架构及设计人员自己应该动手解决的问题。
引用Frederick P在1986年《No Silver Bullets》一文中说过的一句经典名言"Silver bullets do not exist",即"世上没有万能的解药"。
Frank Buschmann也曾经说过"Any framework or middleware can only help you in doing your job, but it cannot do your job for you",即"框架或中间件是用来帮助你的,而不是代替你去思考和工作的"。
所以我们必须根据现实的系统要求(功能和非功能要求),自己去构建适合现状的软件架构!
用什么工具画 软件架构设计图
UIDesigner是腾讯用户研究与体验设计部(CDC)设计研发的一款设计类软件,打造一款可以让设计师统一平台和团队协作的平台型设计工具,经过1.0和2.0版本的经验沉淀,我们决定对3.0版本进行全新的架构设计。
开发一个软件系统,前期的架构设计承载着整个软件的设计思想和关键决策,可以说是重中之重。
根据软件架构设计思想,关注分割和交互,好的架构必须使每个关注点相互分离。
我们进行了最基本的需求分析,得出两个关注点:一是工具,二是设计绘图,关系如图1所示。
得到最基本的两个关注点后,接着将提取关键需求(包括:关键功能需求、关键质量需求和关键商业需求),根据两个关注点进行架构的细化设计。
一、关注点——工具这里我们结合UIDesigner的实际需求,提取出属于“工具”范畴的关键功能需求、关键质量需求和关键商业需求。
首先,“工具”的关键功能需求,必须包括:磁盘文件读写、异常捕捉、日志记录、安全性管理;非工具所必须,但是UIDesigner本身所要求的,包括:配置管理、缓存管理、线程服务、服务器和客户端通讯管理、国际化服务。
其次,“工具”的关键质量需求,质量需求包括开发期质量需求和运行期质量需求两部分,经过分析和权衡,UIDesigner的性能主要取决于设计绘图,而稳定性、可扩展性和可维护性才是决定“工具”本身发展的质量需求,因此,对“工具”的质量需求设计将以稳定性、可扩展性和可维护性为主。
最后,“工具”的关键商业需求,因为UIDesigner本身并没有很复杂的业务需求,因此关键商业需求是在设计流程的优化和规范上得到体现,这方面的设计已经属于高层模块和使用流程的设计,对架构的影响非常小,可以暂时性的忽略。
经过关键需求的提取,我们得到了“工具”的设计目标——可以提供通用功能(关键功能需求)的高稳定性、扩展性和维护性的客户端应用。
根据此目标,我们采取了DI(Dependency-Injection)和MVP(Model-View-Presenter)结合的架构,概念架构设计如图2所示。
软件构架,架构和框架的区别
适应性,可理解性设计模式比框架更为抽象设计模式在碰到具体问题后,部分代码重用,部分设计重用,在特定领域基于体系结构的可重用的设计。
也可以认为框架是体系结构在特定领域下的应用。
框架的例子如MVC。
设计模式 在一定的环境中解决某一问题的方案 构件通常是代码重用,而设计模式是设计重用,行为模式,协作关系等体系问题的决策总和:它是对软件系统的系统组织,是对构成系统的构件的接口:程序功能实现的逻辑框架是整个或部分系统的可重用设计,而且还涉及到系统的使用,框架则介于两者之间,重用性。
它不仅涉及到结构与行为:框架中可以包括多个设计模式简单点说结构,有时分析也可重用. 构架是architecture,才能产生代码;框架已经可以用代码表示设计模式是比框架更小的体系结构元素,功能,性能,表现为一组抽象构件及构件实例间交互的方法;另一方面也可以说框架是可被应用开发者定制的应用骨架。
框架亦可称为应用架构...