⑴ 什么是应用架构
应用架构,系统架构,软件架构三者含义基本一致。
从1985年开始,在过去的二十多年里,关于什么是“软件架构(Software Architecture)”已经基本得到了软件工程领域普遍的认同。其中一些重要的定义介绍如下。
“软件架构代表了系统的组织结构。这包括将系统分解为不同的部分、界定它们之间的连接、确定它们之间的交换机制、并且为后续的设计提供指导性的原则” ---出自UML的著名原创者James Rumbaugh、Grady Booch 及 Ivar Jacobson (即架构界俗称的“三个火枪手”)。
“软件架构表述了一个系统的一个或一系列组织结构。这包扩了软件构件、这些构件的外部可见特征,以及这些构件之间的关系。” ---出自Bass Len、Paul Clements、Rick Kazman 在2003年出版的经典的《架构的实践》一书。
IEEE在2004年4月公布的“IEEE Standard 1471”中,提出了IEEE自己对软件架构的定义:“软件系统架构是根据具有参考意义的实践而定义出来的。主要表述了有一个系统的基本组织结构、基本组成构件和互相的关系,以及构件于外部环境间的关系。同时,软件系统架构为后续的设计和架构演化提供了指导性原则” 。IEEE Standard 1471也澄清了架构领域的许多其他感念,例如架构描述、架构标准等。
可以看出,上述诸多不同用词的“软件架构”的定义,其实都表达了近乎一致的思想。我们可以引用Frank Buschmann 的经典论述来定义一个架构师:“一个软件系统的架构师是一个要担负起软件系统的定义、架构的实现、系统的实施、系统架构演化和系统演化的人。换句话说,是一个要为系统整个生命周期负责的人 。”
但有意思的是,软件工程领域基本上没有一致的有关“软件架构师(Software Architecture)”的定义。很多公司也没有这样的职位;有些公司虽然有这样的职位,但却说不清楚这个职位所要求的技能和工作职责;另外但我们对比不同公司关于该职位的描述时,也能看到其中的不一致,例如Microsoft公司与Motorola公司对架够师的职位表述就很不一样。更常见的是这些职位描述严重混淆了很多概念,例如:当年的Rational公司就混淆了“软件架构师”与“高级程序员”的概念。
这样的现象,无论是在国内还是国外都很相似。这也导致了我们可以见到大量的不同职位名称出现在软件工程行业中的观象,例如有解决方案架构师、系统架构师、软件架构师、企业架构师、总工、首席架构师、Java架构师、微软架构师及.NET架构师。
⑵ 什么是软件架构
当你去了解一个东东的时候,第一步要做的,就应该去知道这个东东的定义,对于软件架构也是如此,经过网上查询和书籍的帮助,我大概理清了一个轮廓。
软件行业是一个热衷于制造‘名词’的行业,如果退回15年,估计没几个人知道‘软件架构’是什么,在上个世纪80年代,随着软件开发的规模不断扩大,软件开发成为一个行业,初期,随之而来的是越来越多的软件项目的失败,造成项目失败的原因很多,但主要集中在开发过程,所以软件工程应运而生,CMMI等流程标准也是一茬接着一茬的冒个不停。
在软件工程初具规模的时候,软件开发还是以数据结构+算法的形式存在,进入20世纪最后10年,随着面向对象技术、设计模式等在开发过程中的成功应用,软件架构也走进了大家的视野。
软件架构在定义上分为‘组成派’和‘决策派’两大阵营,分别描述如下:
’组成派‘认为软件架构是将系统描述成计算组件及组件之间的交互
。它有两个非常明显的特点:
关注架构实践的客体——软件,以软件本身作为描述对象。
分析了软件的组成,说明软件不是一个‘原子’意义上的整体,而是有不同的部分经过特定的接口进行连接组成的一个整体,这对软件开发来说很重要。
‘决策派’认为
软件架构包含了一系列的决策
,主要包括:
软件系统的组织
选择组成系统的结构元素和它们之间的接口,以及当这些元素相互协作时所体现的行为
用于指导这个系统组织的架构风格:这些元素以及它们的接口、协作和组合
软件架构并不仅仅关注软件本身的结构和行为,还注重其他特性:使用、功能性、性能、弹性、重用、可理解、经济以及技术的限制和权衡等。
‘决策派’有以下两个显著的特点:
关注软件架构中的实体——人,以人的决策为描述对象。
归纳了软件架构决策的类型,指出架构决策不仅包括关于软件系统的组织、元素、子系统和架构风格等几类决策,还包括关于众多非功能性需求的决策。
按照‘组成派’的观点,软件架构关注的是软件整体的分割和交互,之所以分割,是因为不同的部分在逻辑或物理上相对独立,通过‘分而治之’的原则进行分割可以更好的理解整个系统,把握用户的需求,但是虽然整个软件可以分割成多个模块或子系统,但是模块和子系统之间的通信和交互也是很重要的,我想按照这种观点,架构师的主要任务是将软件分割成不同的模块,并定义模块之间的接口。
按照‘决策派’的观点,软件是一个在很多限制下产生的产品,这些限制包括用户和技术两方面,用户方面包括功能需求、性能需求、硬件需求等,技术方面包括技术选择、可扩展性、可重用性、可维护性等。我想按照这中观点,架构师的主要任务就是作出上述个各种限制作出选择或决策。《软件架构设计》 温昱
⑶ 请问软件架构与软件体系结构有什么关系
软件架构:整个软件系统的各个模块之间的结构设计,是软件工程范畴的概念,就象设计一栋房子由几个什么样的板块组成一样。
软件体系结构:是软件编程风格范畴的一个通俗概念,比如说用C++、PoworBuild、Delphi等来进行软件设计是面向对象的编程语言体系结构,而Basic、C、Foxbase的软件体系结构特点是面向任务流程的(不是面向对象的编程语言)。
⑷ 什么是软件系统架构设计
“架构”一词最早来自建筑学,原意为建筑物设计和建造的艺术。但是在软件工程领域,软件架构不是一个新名词,只是在早期的著作中人们将软件架构称为软件体系架构。这就是架构的概念。所谓架构,就是人们对一个结构内的元素及元素间关系的一种主观影射的产物。
系统架构的主要任务是界定系统级的功能与非功能要求、规划要设计的整体系统的特征、规划并设计实现系统级的各项要求的手段,同时利用各种学科技术完成子系统的结构构建。
在系统架构中,由于对软件越来越深入的依赖,软件架构的任务也体现出重要的作用。而且系统架构与软件架构是紧密联系和相互依赖的。
1997年,Eberhadrt Rechtin 与MarkW Maier 在其论著中,为计算机科学总结了系统架构方面的实践成果,从而奠定了系统科学和系统架构在计算机科学中的基石:
无论何种系统架构应用领域,目的都是一样的,即完整地、高一致性的、平衡各种利弊的、有技术和市场前瞻性的设计系统和实施系统。
⑸ 软件工程中总体设计阶段中的系统架构是什么,架构图是指功能模块图吗各位能手快快回答,江湖救急
网上订餐系统的总体设计和详细设计报告我帮助 给撰稿啊~原创的.
⑹ 请问“软件工程师”与“系统架构师”还有“项目经理”这三个职位有什么区别,分别要求要什么
系统架构设计师考试合格人员能够根据系统需求规格说明书,结合应用领域和技术发展的实际情况,考虑有关约束条件,设计正确、合理的软件架构,确保系统架构具有良好的特性;能够对项目的系统架构进行描述、分析、设计与评估;能够按照相关标准编写相应的设计文档;能够与系统分析师、项目管理师相互协作、配合工作;具有高级工程师的实际工作能力和业务水平。
软件设计师考试的合格人员能根据软件开发项目管理和软件工程的要求,按照系统总体设计规格说明书进行软件设计,编写程序设计规格说明书等相应的文档;组织和指导程序员编写、调试程序,并对软件进行优化和集成测试,开发出符合系统总体设计要求的高质量软件;具有工程师的实际工作能力和业务水平。
系统集成项目经理考试合格人员能够掌握系统集成项目管理的知识体系;具备管理系统集成项目的能力;能根据需求组织制订可行的项目管理计划;能够组织项目实施,对项目进行监控并能根据实际情况及时做出调整,系统地监督项目实施过程的绩效,保证项目在一定的约束条件下达到既定的项目目标;能分析和评估项目管理计划和成果;能对项目进行风险管理,制定并适时执行风险应对措施;能协调系统集成项目所涉及的相关单位和人员;具有工程师的实际工作能力和业务水平。
⑺ 软件工程中软件结构图和层次图的异同
两者之间没有区别。两者指的均是软件构架,为软件系统的草图。
软件工程中软件结构图和层次图均是为了反映软件系统中组件之间相互关系和约束的体系结构设计图,属于一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。
软件结构图(又被叫做软件构架)一般通过分层次或分时间段等方式说明体系结构的各个组成部分的组合关系。描述的对象是直接构成系统的抽象组件,各个组件之间的连接则明确和相对细致地描述组件之间的通讯关系。
(7)软件工程系统架构扩展阅读:
其他介绍:
软件结构图包括架构元件、联结器、任务流。所谓架构元素,也就是组成系统的核心砖瓦,而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果,任务流则描述系统如何使用这些元件和联结器完成某一项需求。
通过一个软件结构图建造一个系统所作出的最高层次的、以后难以更改的,商业的和技术的决定。在建造一个系统之前会有很多的重要决定需要事先作出,而一旦系统开始进行详细设计甚至建造,这些决定就很难更改甚至无法更改。显然,这样的决定必定是有关系统设计成败的最重要决定,必须经过非常慎重的研究和考察。
⑻ 软件工程中的主要体系结构有哪些,并说明区别
20世纪60年代的软件危机使得人们开始重视软件工程的研究。起初,人们把软件设计的重点放在数据结构和算法的选择上,然而随着软件系统规模越来越大,对总体的系统结构设计和规格说明变得异常重要。随着软件危机程度的加剧,软件体系结构(software architecture)这一概念应运而生。软件体系结构着眼于软件系统的全局组织形式,在较高层次上把握系统各部分之间的内在联系,将软件开发的焦点从成百上千的代码上转移到粒度较大的体系结构元素及其交互的设计上。与传统软件技术相比,软件体系结构理论的提出不仅有利于解决软件系统日益增加的规模和复杂度的问题,有利于构件的重用,也有利于软件生产率的提高。面向方面软件开发(AOSD)认为系统是由核心关注点(corn concern)和横切关注点(cross-cutting concern)有机地交织在一起而形成的。核心关注点是软件要实现的主要功能和目标,横切关注点是那些与核心关注点之间有横切作用的关注点,如系统日志、事务处理和权限验证等。AOSD通过分离系统的横切关注点和核心关注点,使得系统的设计和维护变得容易很多。
Extremara大学的Navasa等人[1]在2002年提出了将面向方面软件开发技术引入到软件体系结构的设计中,称之为面向方面软件体系结构(aspect oriented software architecture,AO-SA),这样能够结合两者的优点,但是并没有给出构建面向方面软件体系结构的详细方法。
尽管目前对于面向方面软件体系结构这个概念尚未形成统一的认识,但是一般认为面向方面软件体系结构在传统软件体系结构基础上增加了方面构件(aspect component)这一新的构成单元,通过方面构件来封装系统的横切关注点。目前国内外对于面向方面软件体系模型的研究还相对较少,对它的构成单元模型的研究更少,通常只关注方面构件这一构成单元。方面构件最早是由Lieberherr等人[2]提出的,它是在自适应可插拔构件(adaptive plug and play component,APPC)基础之上通过引入面向方面编程(AOP)思想扩展一个可更改的接口而形成的,但它关于请求接口和服务接口的定义很模糊,未能给出一个清晰的方面构件模型。Pawlak等人[3]提出了一个面向方面的框架,该框架主要包含了一个方面构件模型———Java方面构件(Java aspect component,JAC),但该方面构件模型仅包含了切点(pointcut),并把AOP中装备(advice)集成到了切点的表达式中,它主要从实现的角度进行了阐述,并没有给出详细的方面构件模型。本文没有只关注面向方面软件体系结构中方面构件这一构成单元模型,还详细分析了它的另外两个构成单元,即构件和连接件,因为面向方面软件体系结构各部分之间是相互关联的。
1面向方面软件体系结构相关概念
面向方面软件体系结构涉及诸多概念,以下将分别介绍。软件体系结构在软件工程领域有着广泛的影响,但当前仍未形成一个统一的、标准的定义。目前国内外普遍认可的看法是软件体系结构包含构件、连接件和约束[4]。其中约束描述了体系结构配置和拓扑的要求,确定了体系结构的构件与连接件的连接关系。这样就可以把软件体系结构写成
软件体系结构(software architecture)=构件(components)+
连接件(connectors)+约束(constraints)
构件是软件体系结构的基本元素之一。一般认为,构件是指具有一定功能、可明确辨识的软件单位,并且具备语义完整、语法正确、有可重用价值的特点,然而目前对于构件的具体结构及构成并没有一个统一的标准[5],而且一些主要的构件技术也没有使用相同的构件类型。另外,当前被广泛接受的构件定义并不包含具体的软件构件模型(software component model)。例如,Szyperski等人[6]给出了软件构件一个很有名的定义:软件构件是一个仅带特定契约接口和显式语境依赖的结构单位,它可以独立部署,易于第三方整合。但是关于软件构件模型有一个被普遍接受的观点是:软件构件是一个具有服务提供和服务请求功能的软件单元[7]。
连接件是软件体系结构另一个基本的构成元素,是用来建立构件间交互以及支配这些交互规则的构造模块。连接件最先是由Shaw[8]提出来的,她建议把连接件作为软件体系结构中第一类实体,用来表示普通构件之间的交互关系。目前对于连接件尚未形成统一的认识,尽管在软件体系结构中强调了连接件存在的必要性,但是关于连接件模型的研究还很少,连接件的实际应用还不成熟。
面向方面软件体系结构在传统软件体系结构的基础上增加了方面构件单元。通常认为,方面构件是封装了系统横切关注点的一类特殊的构件。目前关于方面构件模型的研究还处于起步阶段。
2面向方面软件体系结构模型
由于传统软件体系结构模型包含构件、连接件和约束,而面向方面软件体系结构是在传统软件体系结构的基础之上扩展了方面构件,所以面向方面软件体系模型结构包含构件、连接件、方面构件和约束。其中约束描述了面向方面体系结构配置和拓扑的要求,确定了体系结构的构件、连接件和方面构件之间的连接关系,而构件、连接件、方面构件是它的三个基本的构成单元。以下对这三个构成单元的模型进行详细的设计。
⑼ 软件构架师与软件工程师的区别
软件架构师是软件行业中一种新兴职业,工作职责是在一个软件项目开发过程中,将客户的需求转换为规范的开发计划及文本,并制定这个项目的总体架构,指导整个开发团队完成这个计划。主导系统全局分析设计和实施、负责软件构架和关键技术决策的人员
软件工程师是从事软件开发相关工作的人员的统称。它是一个广义的概念,包括软件设计人员、软件架构人员、软件工程管理人员、程序员等一系列岗位,工作内容都与软件开发生产相关。
⑽ 什么是系统架构设计
简单一点,系统架构设计就是一个系统的草图,描述了构成系统的抽象组件,以及各个组件之间的是如何进行通讯的,这些组件在实现过程中可以被细化为实际的组件比如类或者对象。在面向对象领域中,组件之间的联通通常面向于接口实现的。
是人们对一个结构内的元素及元素间关系的一种主观映射的产物。架构设计是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。
“架构”一词最早来自建筑学,原意为建筑物设计和建造的艺术。但是在软件工程领域,软件架构不是一个新名词,只是在早期的著作中人们将软件架构称为软件体系架构。这就是架构的概念。所谓架构,就是人们对一个结构内的元素及元素间关系的一种主观影射的产物。
无论何种系统架构应用领域,目的都是一样的,即完整地、高一致性的、平衡各种利弊的、有技术和市场前瞻性的设计系统和实施系统。
(10)软件工程系统架构扩展阅读
系统架构的主要任务是界定系统级的功能与非功能要求、规划要设计的整体系统的特征、规划并设计实现系统级的各项要求的手段,同时利用各种学科技术完成子系统的结构构建。
在系统架构中,由于对软件越来越深入的依赖,软件架构的任务也体现出重要的作用。而且系统架构与软件架构是紧密联系和相互依赖的。
1997年,Eberhadrt Rechtin 与MarkW Maier 在其论著中,为计算机科学总结了系统架构方面的实践成果,从而奠定了系统科学和系统架构在计算机科学中的基石。