软件架构(SA)

软件架构(SA)（精选6篇）

软件架构(SA) 篇1

摘要：随着IT技术的不断发展,越来越多的人把关注目光投入到了计算机软件领域,而软件构架凭借其在软件设计过程中的重要地位更是得到了大家的重视。本文以软件构架为研究对象进行分析,从软件架构与软件框架的概念谈起,阐述了软件架构的发展历程,并总结了软件架构的现状及其局限性。

关键词：软件构架,概念,发展历程,局限性

1 概念

在计算机发展的早期,大型计算机系统主要是被设计应用于非常狭窄的军事领域。在这个时期,研制计算机的费用主要由国家财政提供,研制者很少考虑到研制代价问题。随着计算机市场化和民用化的发展,代价和成本就成为投资者考虑的最重要的问题之一。

20世纪50年代,软件成本在整个计算机系统成本中所占的比例为10%———20%。但随着软件产业的发展,软件成本日益增长。相反,计算机硬件随着技术的进步、生产规模的扩大,价格却不断下降。这样一来,软件成本在计算机系统中所占的比例越来越大。到20世纪60年代中期,软件成本在计算机系统中所占的比例已经增长到50%左右。

60年代的软件危机使得人们开始重视软件工程的研究。起初,人们把软件设计的重点放在数据结构和算法的选择上,随着软件系统规模越来越大、越来越复杂,整个系统的结构和规格说明显得越来越重要。软件危机的程度日益加剧,现有的软件工程方法对此显得力不从心。对于大规模的复杂软件系统来说,对总体的系统结构设计和规格说明比起对计算的算法和数据结构的选择己经变得明显重要得多。在此种背景下,人们认识到软件架构的重要性,并认为对软件架构的系统、深入的研究将会成为提高软件生产率和解决软件维护问题的新的最有希望的途径。

1.1 软件架构

软件架构,亦称软件体系结构,它是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。它是一个系统的草图,描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通信。

在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口来实现。直到今天,软件架构还没有一个统一的定义。本文引用IEEE Working Group on Architecture的解释:“系统在其环境中的最高层概念”。从这个定义上考虑,架构不仅仅是结构,它还应包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑,而且还在系统的用户环境和开发环境中对系统进行整体考虑,即同时注重对外部的考虑。

鉴于软件架构的特殊地位,在设计一个系统之前就必须对它的软件架构进行详细设计及构造,以软件架构作为后续工作的基石。一旦这个架构决定下来就不应轻易地进行更改,这是关系到整个系统设计的成败。因此,软件架构的设计,必须经过非常慎重的研究和考察。

1.2 软件框架

说到架构,有必要提一下软件框架。框架的定义是:它是一组相互协作的类,对于特定的一类软件,框架构成了一种可重用的设计。软件框架是项目软件开发过程中提取特定领域软件的共性部分形成的体系结构,不同领域的软件项目有着不同的框架类型。框架的作用在于:因为提取了特定领域软件的共性部分,因此在此领域内新项目的开发过程中代码不需要从头编写,只需要在框架的基础上进行一些开发和调整便可满足要求。对于开发过程而言,这样做会提高软件的质量,降低成本,缩短开发时间,使开发越做越轻松,效益越做越好,形成一种良性循环。

框架不是现成可用的应用系统。它只是一个半成品,需要后来的开发人员进行二次开发,实现具体功能的应用系统。框架不是“平台”,平台概念比较模糊,它可以是一种操作系统,一种应用服务器,一种数据库软件,一种通信中间件等。因此,平台在应用中主要指提供特定服务的系统软件,而框架更侧重了设计,开发过程,或者可以说,框架通过调用平台提供的服务而起的作用。

框架不是构架。架构确定了系统整体结构、层次划分、不同部分之间的协作等设计考虑。框架比架构更具体,更偏重于技术细节。确定框架后,架构也随之确定,而对于同一架构(比如Web开发中的MVC),可以通过多种框架来实现。

2 发展历程

早在19世纪60年代,诸如E·W·戴克斯特拉就已经涉及“软件架构”这个概念了。自90年代以来,由于在Rational Software Corporation和Microsoft公司内部的相关活动,“软件架构”这个概念开始越来越流行起来。

卡内基梅隆大学和加州大学埃尔文分校在这个领域作了很多研究。卡内基·梅隆大学的Mary Shaw和David Garland于1996年写了一本叫做“Software Architecture Perspective on an Emerging Discipline”的书,提出了软件架构中的很多概念,例如软件组件、连接器、风格等等。加州大学埃尔文分校的软件研究院所做的工作则主要集中于架构风格、架构描述语言以及动态架构。从学者们所关注的角度不同,逐渐出现了逻辑架构、物理架构、系统架构等软件架构的分类。多层的软件架构逐渐成为主流,一个典型的软件系统都分为表现层、业务层、数据层等多个层次,来满足不断发展的软件系统的业务需求。随着现代企业对IT基础设施的依赖增大,整个企业的业务可能都会基于Internet或Intranet进行运作,因此,出现了MIS、ERP、SCM等应用系统。在这些复杂的应用系统中,软件架构至关重要,它必须保证软件系统的后期扩展性,来延长系统的生命周期,并与其它系统通过EAI或其它方式进行集成。同时还出现了“企业软件总线(Enterprise software Bus,ESB)”的架构,它试图通过确立软件模块间的、独立于技术、统一的企业级通信标准,从根本上解决应用程序的集成问题。与此同时,一些软件架构开始尝试使用CORBA等中间件解决系统异质问题,这些都为后来软件架构的研究提供了很好的路线图。

3 现状及其局限性

经过几十年的发展,软件架构的研究取得了一定的成果。然而,在研究中仍然面临着很多不易解决的问题,在面对统一的软件架构这个问题时一时还缺少标准的答案。在过去的软件系统中,由于设计不合理,接口不规范等问题,造成系统与系统间甚至是子系统与子系统间的相互通信困难,资源共享不顺畅,整合困难,容易出现所谓的“信息孤岛”和“应用孤岛”。软件架构的设计中通常都缺乏灵活性,产生了“Monolithic”设计,在设计与灵活的应用需求脱节。但在上世纪九十年代后期,这个问题逐渐被学者们所重视,一个好的软件架构应能提供灵活的扩展机制、丰富的接口、共享应该共享的信息等,这是一个良好设计的软件架构的规范,但由于技术间差异性的普遍存在,大多数系统间即便有良好定义的接口也难以得到其他系统的使用。CORBA、DCOM、EJB等中间件的出现为统一接口层的出现提供了可能。但抛开某些中间件的灵活性易用性不谈,这些异构的中间件之间的统一访问又产生了新的问题,即中间件的异构性问题。又由于新旧系统混杂,异构系统、不同的平台、开发技术、开发商、多个版本并存等问题,使得软件系统很难被重用,不可避免地需要被重写。此时,统一的软件架构得到前所未有的关注。

SOA是一种较新的软件架构,它最早在1996年被提出,但是由于当时软件实现相关技术的不足,一直未能获得发展。后来由于在分布式技术、程序设计方法学、业务计算能力等方面的长足发展,使得SOA作为“现代应用开发领域最重要的课题”被提了出来,许多研究机构、大学、软件企业都将其作为研究重点。IBM、BEA、微软等公司和机构都提出了实现SOA的新技术。尤其是一些机构联合提出以Web Service Architecture作为实现SOA的标准,这使得SOA在标准化之路上迈出了一大步,但还有很长的路要走。SOA仍远没有达到成熟的地步,甚至还没有一个获得公认的定义,研究工作大都处于理论研究阶段。

在国内,SOA还是一个新鲜的事物,虽然近两年来关于SOA的报道经常见诸各种媒体,但是炒作概念的成分居多,并没有多少实用成果。研究中,面向服务、面向组件、面向对象的理论研究成果也并不多,关于SOA的著作更是少见。在实践领域,虽然有一些国内企业提出了SOA的概念性产品,但仍很少看到其SOA系统的成熟应用的案例。由此可见,国内对SOA的研究还处于初级阶段。

然而,由于企业用户业务需求的不断变化,要求企业IT系统必须成为一个适应力强的竞争体,能随着企业环境的变化而改变,并具备柔性扩展、随时支持业务流程变化的基础功能。因此目前的很多行业,例如政府、电信、金融、医疗等等,都需要实施SOA。

SOA作为一种方兴未艾的技术,虽然很不成熟,而且具有一定的不确定性,然而这并没有阻碍SOA技术的不断发展,已有大量的国际软件公司和标准化组织对其投入了大量的资源进行研究。作为一种新型的软件开发架构,SOA具有非常大的优势,它放弃了极易带来技术差异性的“以技术为中心”的细粒度实体,而转向“以业务为中心”的服务,这符合按需计算的发展潮流,尤其适用于大规模的企业级应用开发。随着互联网络的进一步发展,分布式应用的不断普及,SOA的应用会更加的普遍并被人们所接受,成为一种最重要的软件架构。可以预见,SOA的发展会对软件设计思想产生非常大的影响并对分布式企业应用的不断普及起到巨大的推动作用。

参考文献

[1]李莉.基于自适应构件的软件架构研究[J].惠州学院学报(自然科学版),2008;3

[2]龚爱斐.基于虚拟化架构的软件开发与测试环境自动化[J].自动化与信息工程,2008;2

[3]曾仁京.集群负载的分布式软件构架分析与设计[J].福建电脑,2008;7

[4]万芳.基于Web服务与Agent的软件架构[J].计算机工程与设计,2008;10

基于软件架构的回归测试 篇2

首先由于软件总在时刻变化着, 软件的不断演化, 例如软件的开发、维护、升级都需要修改一些软件的结构和代码, 而人类对软件的要求也从未停止过。软件的每次改变都会引入潜在的风险, 这是软件演化的缺陷。其次, 人类对软件变化有了一些新的要求, 关心软件修改后的功能是否达到预期以及原有的功能是否被损害[1,2,3]。

针对以上要求, 选择使用回归测试来解决。回归测试是一种验证已变更系统的完整性与正确性的测试技术。

2 回归测试的定义及意义

回归测试是对之前已测试过、经过修改的程序进行重新测试, 以保证该修改没有引入新的错误或者由于更改而发现之前没有发现的错误。

回归测试的意义是: (1) 保证软件维护时未更改的代码功能不会受到影响。 (2) 保证软件模块区域和持续维护过程与回归测试的协作关系, 使得回归测试成为一个每月、每周、每日的常规活动。 (3) 实现软件整个生命周期的测试。

3 回归测试

首先简单介绍传统的基于代码的回归测试选择方法的作用, 以便了解软件架构回归测试选择方法的基础。关注于选择性的回归测试方法, 然后再重新采用相同的逻辑步骤来提出一种基于软件架构的回归测试方法 (在第四部分提出) 。

回归测试的目的在于验证修改的软件并确定不会在先前测试的代码中出现新的错误。传统的方法是把它分解为两个阶段。 (1) 测试软件P相对于一种指定的测试集T。 (2) 当推行了一种新版本P′时, 对已修改的版本P′的回归测试提出P′相对于测试组T′是正确的可靠性。

在最简单的回归测试方法中, 有一种叫做复制所有的测试。T′中包含T中的所有在T中的测试用例, 并且P′运行在T′上。在回归测试选择方法上, T′被选出作为一种跟T相关的子集, 假设有t∈T, t包含于T′, 如果它有可能在P′中生成的结果与在P中不同。对不同回归测试选择方法的实证研究和分析在文献[4]中提出, 加上对不同行为的识别需求。

本文着重研究如何为P′选择一种相关的测试用例子集, 又叫做回归测试选择问题, 描述一种回归测试选择方法, 它是在软件架构层面上而不是在代码层面上。换句话说, 用选择架构化的层面测试用例代替选择代码层面的测试用例。

4 基于软件架构的回归测试

基于软件架构的回归测试包含以下两个阶段: (1) 基于软件架构的测试。特别地, 应用一种基于软件架构的一致性测试方法。 (2) 基于软件架构的回归测试选择。这个阶段被分解以满足目的1和目的2。

图1总结了基于软件架构一致性和回归测试所需要的行为。本文主要研究基于软件架构的回归测试。

4.1 基于软件架构的一致性测试

这项工作是基于软件架构一致性测试的一般框架的, 目的是测试已给出的软件架构实施的一致性。

这个框架分为5个步骤, 如图1中间的部分所示。

第0步:它开始于软件架构规范的拓扑学和行为学, 这里的行为通过一种基于机器的形式体系状态来模仿。下面, 利用标签的过渡 (LTS) 来模仿组件的行为。

第1步:提出了一个通过观测得到的方法为了实现一种测试标准, 这种标准来源于与测试目的相关视角在软件架构中, 而是把无关的行为从这个视角中隐藏起来。标签的过渡 (LTS) 模型被提取出来, 就产生了一种抽象标签的过渡 (ALTS) , 用来说明只有这样高层的行为/组件是需要测试的。

第2步:一种基于架构层面的测试用例 (ATC) 以架构事件的有序序列被定义了, 这种事件是当一个确定的初始事件执行的时候期望发生的架构事件。此定义分解为两个关键词:行为序列, 它代表了所期望的行为和初始事件, 它是允许发生的结构化输入。获得一个ATCs充分集合需要得到一个合适的包含了ALTS完整路径的集合[5]。

第3步:自然地, 这样的ATCs与可执行的代码层面测试用例截然不同, 因为在软件架构和代码之间的差距。处理这个问题通过一种“绘图”方法, 它能够将软件层面函数的测试转化为代码层面测试用例。

第4步:最后, 代码运行在可识别的测试用例上。通过分析执行的踪迹来决定系统在所选择的结构测试中实施得是否正确, 采用结构化的模型作为一种测试数据库来识别代码用例成功或失败。

这样的方法已经得到公认, 但是重复的测试行为对于系统的发展而言无疑花销太大了, 因此需要以更少花销开发一种基于软件架构的测试方法。本文提出一种方法来处理系统的发展, 重复使用原始的测试结果来重新测试已修改的结构并以更少的花销来完成。

4.2 目的1:测试对于初始软件架构P′的一致性

让假设基于软件架构一致性的测试已经提出P符合已给出的软件架构的一致性。当P进化到P′之后, 如何来测试P′对于相同架构的一致性。采用的方法是将基于软件架构测试方法和现存的基于代码的回归测试方法相融合的。通过一种行为图表, 代码层面的回归测试能够与基于软件层面的一致性测试相融合来选择一个新的测试套组T′:

A:产生图表P, 大多数普通的用于代码回归测试的方法是为了通过图表来结构化地表达P。在修改之后, P′也被描述成一张图表。在软件架构中, 图表也通过组合成分行为的LTS模型来获得, 同时在结构中结构化那些成分组织。

B:把GP和GP′相比较, 在基于回归测试的传统代码中, 通过比较P和P′的代码图表, 识别代码的改变怎样影响到图表中。在软件架构中, 这种改变根据在LTS中节点和边来识别。

C:记录覆盖范围, 通过测试用例的执行测试历史记录被构建出来。通过测试用例在P上执行代码的过程, 记录一连串的节点/电弧。

D:测试用例选择P′。从测试历史和图表比较中积累的信息被应用于识别将要在P′中再次运行的T中的测试用例。如果在t∈T中P的执行包含了在P′中修改的节点, 那么t需要在P′中重新运行。

一旦T′被选择了, t′∈T′就在P′中运行并把结果收集起来, 然后和一种数据库相比较来确定测试是失败还是成功。与基于传统代码方法的一种主要的区别是, 在基于软件架构回归测试的数据库是软件结构自己本身。事实上, 当t′在P′中运行的时候, 如果它的执行不允许所期望的情况再次出现, 那么测试会失败。更多情况, 代码层面的测试用例总是被形式化的函数和结构化的需求驱动得很好。

期望从这个方法中得到的好处有两层: (1) 作为传统的回归测试, 为P′减少了测试套组的规模, 剪掉了所有在P′中不需要被再次应用的那些测试。 (2) 当发现了一致性错误的时候, 能够搜集关于如何来适应初始架构的信息。

4.3 目的2:测试进化得到的架构的一致性

让再次假设基于软件架构一致性测试已经声明了P的实施应符合已给出的软件架构。采用的方法是根据比较两者的架构的规范来识别软件结构改变/未改变的位置。结构和行为的改变都被考虑在内。特别的, 对于S和S″的LTSs被比较之后的区别通过两张图表 (利用一种“diff”算法) 来识别。在一次与基于回归测试传统代码相似的改革中, 无论什么时候一个ATC在S″中被修改的LTS软件架构中遍历一次的时候, 它需要在S″中重新测试。图1 (最左边) 总结了目的2如何通过不同的行为被意识到。

a:新的软件架构规则。演变的系统S″被结构化的规则提出。

b:测试标准。测试标准 (之前应用在S中) 被用在S″上。

c:比较。架构的规则与识别出的拓扑改变相比较 (也就是增加的/删除的组件或修改的配置) 和行为的改变 (也就是经过改变的部件)

d:为S″选择结构化的测试用例。那些来自于软件架构的被结构的改变影响的ATCs被选择在P″上重新测试, 为了S″的实施。注意到任何在这步丢弃的ATC都可以代表很多被消除的代码层面的测试用例, 因此很大程度上减少了重复测试的花销。

e:识别代码层面测试用例。一旦已经识别了需要用在S″中的回归测试ATCs, 为了S″需要把架构的测试用例转化到代码层面的测试用例, 以便为了P″选择T″。这一步类似于在第三步中基于软件架构的测试。

f:测试执行。在T″已经被S″选择之后, 需要在P″中运行T″然后评估执行基于软件架构回归测试的结果。这一步跟第四步中基于软件架构的测试很相似。

摘要：当对可靠的系统结构化的时候, 除了通过构建的方式来改善系统的可靠性 (如容错和多余的机制) 外, 对于系统的评估也同样重要, 并由此来认可系统的可靠性。现有很多不同的方法来评估系统的可靠性, 测试因而成为一种重要的方式。目前关于软件结构测试的工作表明, 应用一致性测试技术产生可信度是可能的, 这种可信度是在软件架构中可期望的行为, 指定了架构描述语言。这项工作中, 探讨了为了减少重复测试而修改系统的费用, 回归测试可以怎样被系统化地应用在软件架构层面上, 评估了进化的系统的回归测试性。考虑了评估“自顶向下”和“自底向上”等进化方法, 是否通过简单修改就能够符合初始的架构, 这样的修改是否能够符合进化的架构。将回归测试应用在软件架构层面上将有助于评估和认定其是否具有更高的可信度。

关键词：软件架构 (SA) ,可靠性系统,回归测试,分析

参考文献

[1]R J Allen, R Douence, D Garlan.Specifying and Analyzing Dynamic Software Architectures[C]//Proceedings of the1998Conference on Fundamental Approaches to Software Engineering (FASE’98) , March 1998.

[2]S Beydeda, and V Gruhn.Integrating White-and Black-Box Techniques for Class-Level Regression Testing[C]//Proceedings COMPSAC2001, 2001:357-362.

[3]A Bucchiarone, H Muccini, P Pelliccione, and P Pierini.Model-Checking Plus Testing:From Software Architecture Analysis to Code Testing[C]//Proceedings International Work on Integration of Testing Methodologies (ITM’04) , October2004.

[4]UCI.The C2Style[EB/OL].http://www.ics.uci.edu/pub/arch/c2.html.

软件定义网络架构和应用分析 篇3

1 软件定义网络 (SDN) 的概念

软件定义网络, 又称为可编程网络, 就是将网络设备配置平面从嵌入式节点独立出来到软件平台、由软件驱动的中央控制节点自动化控制的网络架构。软件定义网络以开放软件模式替代传统的基于嵌入系统的、不够灵活的控制平面。软件定义网络是新的网络控制平面实现方法, 它适应了降低网络复杂度、虚拟化和云计算的网络需求。它的发展对专有控制平面技术产生的破坏性创新, 将对网络变革产生巨大影响。控制平面和转发平面分离, 转发平面特性专注而简单, 减少了设备硬件, 降低了成本。

2 软件定义网络架构分析

2.1 SDN架构的特点

SDN的核心理念是使网络软件化并充分开放, 从而使得网络能够像软件一样便捷、灵活, 以此提高网络的创新能力。通常意义上来讲, SDN是指从发展而来的一种新型的网络架构, 其前身是斯坦福的用于企业集中安全控制的Ethane项目。图1描述了SDN架构的逻辑视图。

SDN架构分为三层, 包括应用层、控制层和基础设施层。SDN控制层是基于软件的控制器, 负责维护全局网络视图, 并且向上层应用提供用于实现网络服务的可编程接口;应用层运行在控制层之上, 通过控制层提供的全局网络视图, 控制应用程序可以把整个网络定义成为一个逻辑的交换机, 同时, 利用控制器提供的应用编程接口, 网络人员能够灵活地编写多种网络应用, 如路由、多播、安全、接入控制等;基础设施层位于控制层之下, 通过控制数据平面接口与控制层相连, 主要提供网络设备硬件。

与传统的路由及交换协议相比, SDN的最大特点是使用集中式的方式来转发数据。传统路由协议, 致力于建立一个分布式的网络, 即使有一个或多个路由设备因各种原因 (如故障、战争等) 不能正常工作, 数据包也可以依靠其它路由设备进行转发, 网络不会因少数设备的下线而发生瘫痪。SDN倾向于通过集中式来解决数据流的路由问题, 控制器需为进入SDN网络的每一条流选择一条数据通道, 其复杂度是非常大的。

同时, SDN在进行路径选择时更为灵活, 从而为互联网业务的部署及网络优化创造了有利条件。传统路由协议能在一定程度上实现网络流量的负载均衡, 因为这类路由协议在选择网络路径时, 总是会尽量选择比较空闲的链路而避开拥堵的链路。这类协议的好处是能提高链路的利用率, 其缺点是不易对互联网业务进行优先级管理。而SDN可以通过为业务流指派链路来方便地实现不同业务的优先级管理。

2.2 Open Flow架构分析

Open Flow是由斯坦福大学开发的一种协议, 可简化和统一路由和交换。它通过路由和交换设备的“控制层面”的抽象来实现这一目标。通过将控制层面抽象到一个Open Flow控制器组件, 集中化智能并为基于Open Flow交换机上运行的数据层面组件提供一个通用接口。图2是Open Flow架构图。

Openflow网络设备维护一个流查找表并且只按照流查找表进行转发, 流查找表本身的生成、维护、下发完全由外置的控制机来实现, 事实上Open Flow 1.0定义了包括端口号、VLAN、L2/L3/L4信息的10个关键词, 但是每个字段都是可以通配的, 网络的运营商可以决定使用何种粒度的流, 比如运营商只需要根据目的IP进行路由, 那么流表中就可以只有目的IP字段是有效的, 其它全为通配。

这种控制和转发分离的架构对于L2交换设备而言, 意味着MAC地址的学习由控制机来实现, V-LAN和基本的L3路由配置也由控制机下发给交换机。对于L3设备, 各类IGP/EGP路由运行在控制机之上, 控制机根据需要下发给相应的路由器。流表的下发可以是主动的, 也可以是被动的, 主动模式下, 控制机将自己收集的流表信息主动下发给网络设备, 随后网络设备可以直接根据流表进行转发;被动模式是指网络设备收到一个报文没有匹配的流查找表记录时, 将该报文转发给控制机, 由后者进行决策该如何转发, 并下发相应的流表。被动模式的好处是网络设备无需维护全部的流表, 只有当实际的流量产生时才向控制机获取流表记录并存储, 当老化定时器超时后可以删除相应的流表, 故可以大大节省空间。当一个控制机同时控制多个交换机/路由器设备时, 它们看起来就像一个大的逻辑交换机, 各个交换机/路由器硬件就如同这个逻辑网络设备的远程线卡。

Open Flow规范实际上是一整套软件应用程序接口, 控制网络数据如何转发, 可基于硬件实现, 增加了定制转发数据的控制程度, 减少了支撑复杂控制所需的硬件成本。网络控制节点可以通过规范与支持Open Flow的交换节点沟通配置信息, 决定数据转发平面的转发表, 控制器与转发节点间通过SSL加密传输。支持定义的“信息流”主要是从1层到4层的关键信息包括端口号、VLAN、MAC、以太网包头、IP地址、IP协议号、TCP端口号等。配置信息通常包括“信息流”和与之对应的动作。每个“信息流”有符合某种特征的数据包及动作组成, 比如源IP/源Port、目的IP/目的Port、5种不同转发动作, 如图3所示。

3 软件定义网络应用分析

SDN能够应用于多种网络环境, 包括数据中心、企业网络、云计算等。

首先, 在云计算时代, 在数据中心网络环境中使用SDN, 实现高弹性数据中心、优化物理资源利用率, 让用户能整合各种计算、存储和网络资源, 在数据中心内部, 利用SDN的优势, 可以有效地进行数据中心的路径优化和负载均衡, 提高数据中心资源利用率以及降低数据中心的能量消耗。另一方面, 在多个数据中心之间利用SDN网络虚拟化技术以及逻辑上集中式的控制技术, 可以轻松地实现应用到虚拟专用网 (VPN) 的映射以及虚拟机的迁移, 快速建立和运营虚拟数据中心。

其次, 软件定义网络能简化大型企业网络的管理。在企业网络中利用SDN技术, 能够极大地减轻网络管理的复杂度, 企业网络管理人员只需要通过定义整网的管理策略就能够直接对企业网络进行控制, 而不需要进行逐个设备的配置, 提高了企业网络的可靠性。

最后, 软件定义网络能大大促进云计算的发展, 因为软件定义网络技术大大简化了虚拟环境的资源分配。基于控制器的负载均衡应用程序能够利用控制器中关于各个网络设备的大量容量信息, 自动地在虚拟机之间迁移工作负载。基于控制器的应用程序与部署在虚拟机上的虚拟网络服务设备很相似, 但是与使用物理设备的常规模型相比, 它们具有更高的可扩展性、灵活性、效率和可管理性。

4 结论

通过控制与转发的分离, 软件定义网络能够降低网络管控的复杂度, 提高网络的可靠性及安全性, 提供多种粒度的网络控制。未来网络将越来越依赖于软件, 软件定义网络这种新颖的、动态的网络架构将得到更广泛的应用, 进而促进网络技术的不断创新应用。

参考文献

[1]温熙华.全业务模式下OSS的建设思路[J].电信技术, 2009 (4) :12-13.

软件架构中的关键因素 篇4

对于每一个软件项目组织来说,开发和使用软件架构的能力变得越来越重要,软件架构已经成为影响软件项目成败的最主要因素之一。尽管软件架构的定义、描述、建立与评估等还缺乏统一性,但软件架构的研究已经渗透到软件生命周期的各个阶段,各种标准、技术成果的整合将有效提升软件架构总体应用水平。

自从软件架构被提出以来,人们对于软件架构的本质认识一直在不断深入,比较典型的有注重组件构成与交互的观点[1],以及注重问题重要决策的观点[2]。IEEE1471-2000[3]专门制定了与软件构架相关的国际标准,给出了一个概念模型。CMU/SEI的BASS[4]等人在给出的软件架构定义中,阐述了软件元素的构成及其外部可见属性。

2. 概念模型

本文给出了一个软件架构的概要描述,综合了上述主要思想,这个概念模型在结构上更加完整,对软件架构的建立、分析与评估具有指导意义。

上述概要描述中,三个组成部分及其相互关系覆盖了SA定义的主要方面,其中的连线具有稳定的作用关系,明确了组成部分各自的责任范围,实线体现了软件架构创建与演化的主要行为结果。结构中,架构师部分关联的边数最多,体现了架构师作为体系架构守护者的核心作用。SA内部元素构成及其关系是由架构师直接决定,架构师的最基本活动是架构设计,架构设计的结果表达为两个可追溯方面,一个是从架构师部分输出的“决策”,一个是从软件架构内部元素构成及其关系部分输出的“SA外部视图”。架构师的另外一个活动是“交流”(图1中上方虚线),即架构师作为催化剂,为实现架构而必须做好信息沟通工作。这个沟通包括多个方面,在这里抽象为与涉众的沟通、与组织的沟通以及与环境的作用。IEEE标准[3]已经给出了涉众的定义,对于组织的认识还亟待业界重视,文献[5]详细介绍了VRAPS5项原则模型,该模型中体现了组织管理原则与软件生产技术的有机结合,把组织上升到与软件过程、软件架构同等重要的地位。SA内部元素构成及其关系部分没有以通常的组件与组件间关系,或组件、连接件、约束来表达,而是代之以更为一般化的元素概念。组件有时传递的是运行时信息,而更一般化的元素可以兼有动态和静态属性,甚至可以递归定义为子元素以表达子系统、子架构的情形。

3. 影响因素

在构建SA过程中,只关注提取质量属性的方法是不全面的,本文认为软件架构中影响因素应该涉及功能属性、质量属性、组织属性、商业属性、环境属性等多个方面,只有综合平衡各方面影响因素,进行关键影响因素分析,才可能提取关键属性,并为做出正确的、平衡的、可追溯的决策创造条件。

关于功能属性和质量属性的关系,本文对于两者的正交性报怀疑态度。功能属性对质量属性的影响举例:某些网络功能的增加将降低安全性,降低可伸缩性等。有文章论及一些功能的改变使某些质量属性不能处于某种级别[4],本文认为这正是该功能属性和该质量属性相互之间有影响的反映,两者之间是非正交的。IEEE对于质量属性中属于功能性的部分进行了分类[3],从另一个侧面承认某些质量属性之功能性因素,如适合性、准确性、互操作性、安全保密性等。实践中稳妥的做法是,对重要功能必须关联质量属性分析,尽管有些需求分析中在某些功能方面中没有关联质量属性,但架构师有责任回溯需求分析,把影响因素揭示出来,毕竟没有任何质量属性要求的重要功能几乎是没有的。这也是要求架构师应参与需求阶段主要工作的原因之一,架构师应对质量属性中的一些属性进行功能转化与影响分析。

影响因素中,属性的捕获和涉众中需求分析人员的工作关系密切。在软件架构之前的工作中,领域模型是对问题领域的内在深入研究,软件需求则是对问题领域的外在功能捕捉。相比其他属性,架构师可以直接得到的是需求分析和领域分析中的结果。在对组织属性、商业属性、环境属性的看法上,众多软件架构过程常常忽略上述属性对架构的影响,实际上这些影响可能是非常关键的,可能变成架构成功与否的决定性因素之一。本文推荐采用的方法是:即把组织属性、商业属性、环境属性先行分析,转化为功能和质量属性的分析或约束。

总之,对影响因素中属性的捕获和平衡折中是软件架构的重中之重,因其是架构的依赖,影响因素分析不到位必然对决策阶段产生影响,应增加除功能属性、质量属性之外的属性的提取和控制,形成联合分析。

4. 决策

决策是软件架构设计的结果,这个结果属于架构归档的一部分,这些决策可能在SA外部视图中直接表达出来,或者通过其他的形式详细表达。较好的架构决策归档会对软件架构中多个环节起到重要作用,如软件架构评估以及架构的迭代与回溯。决策的很大的一部分存在于从需求分析向架构过渡的阶段,如功能属性和质量属性的确定过程中。架构师对于功能属性和质量属性不能简单拿来,而是需要在繁多的属性中确定关键功能属性和关键质量属性,方法是通过关键用例以及用例简述、用例规约进行认真识别,引入鲁棒性分析和“属性-场景-决策”方法。领域分析中建立的领域模型,用于帮助确定建立普遍使用的概念以及寻找主要问题的解决途径。对于捕获到的约束部分,可能一部分转化到功能属性上,一部分转化到质量属性上去,一部分成为必须遵守的限制条件,这些决策也应该记录下来。

5. SA外部视图

软件架构视图是架构设计中非常重要的概念。不同的涉众需要不同的视图,视图体现软件架构的多维性,同时视图作为软件架构过程的“产品”在软件架构评估以及软件架构复用中起到了核心作用,成为软件架构中的归档方法。1995年,Philippe Kruchten在一篇论文中介绍了“4+1”视图方法[6],即通过逻辑视图、进程视图、物理视图、开发视图、场景视图来描述体系架构,该方法在RPU中得到推广运用。

当前,软件架构的描述在很大程度上还停留在非形式化的基础上,形式化的描述对体系架构的设计和验证非常重要。通常,软件架构形式化的程度随着软件系统重要性程度的增大而增大。然而,形式化描绘往往困难较大,在软件开发时间要求紧迫的情况下很难有效果,同时多视图之间的一致性、多种软件架构风格的通用性都是难题。软件架构的描述可以分解为各类视图的描述,先立足非形式化的描述,到建立重点视图的形式化描述,再到建立一般视图的形式化描述。另外,从软件开发方法及软件架构验证的角度看,演进原型法是常用而有效的手段。

6. 结束语

本文尝试给出了一个软件架构概念模型,对其中的主要部分进行了描述和探讨。在研究工作中以及工程实践中,人们已经越来越认识到SA的创建不是一劳永逸的事情,而是增量式循环,是不断改进的动态过程。软件架构模型的建立和完善对SA的创建有很大的影响,体现在软件生命周期中各个阶段。随着更多研究与实践工作的开展,对软件架构模型的认识将越来越透彻。

摘要：软件架构是当前软件工程的一个主要研究领域。给出了一个新的软件架构概念模型,分析了其中的组成部分和关系,详细探讨了影响因素、决策和软件架构外部视图。

关键词：软件架构,概念模型,分析

参考文献

[1]Shaw M,Garlan D.Software Architecture:Perspectives on an E-merging Discipline[M].New Jersey:Prentice-Hall,1996.

[2]Kruchten,P.The Rational Unified Process:An Introduction,Second Edition[M].Addison-Wesley,2000.

[3]IEEE.IEEE recommended practice for architectural description of software-intensive systems[S].IEEE,IEEE Std1471-2000,2000.

[4]Bass L,Clements P,Kazman R.Software Architecture in Practice.2nd ed[M].Boston:Addison Wesley,2003.

[5]Dikel,D.M.Software Architecture:Organizational Principles and Patterns[M].New Jersey:Prentice-Hall,2001.

浅论基于架构的软件设计 篇5

随着社会的发展, 软件应用规模和应用领域的不断扩大, 作为相应支撑的各种软件系统将与之相适应, 使得软件开发成了一项的系统工程, 而这对软件开发方式也提出了更大的挑战。基于架构的软件设计方法着重于在软件开发的设计阶段即按照业务特点及软件设计原则, 在软件设计方法上采用一定的方法隔离业务关注点, 设计及代码局部化, 为需求变更及业务逻辑变化, 采用递归分解的方法将大的业务分解, 增加程序的可扩展性、可修改性, 并将设计元素归类管理, 在可预测范围内预留可变空间, 应对需求变更及业务逻辑变化。

基于架构的软件设计根据业务需求隔离关注点, 它可以在可预见的范围内考虑可变性, 为应对变化预留空间。信息技术的发展改变了人们的工作方式, 由于软件工程管理的出现, 促进了制造业等传统产业的发展, 而软件开发也面临着现实的问题, 即业务逻辑的易变性。如何将变化缩小到最小范围, 业务功能的隔离无疑可以起到一定的作用。从另一方面讲, 软件开发方式自身也存在一定的问题, 开发过程中某些环节需要细化。

软件架构是软件设计阶段的产物, 具体地说, 软件架构包含了结构、协作和技术等方面的重要决策, 它对后期的软件维护, 为系统的开发活动建立基础, 对改动力度比较大的软件升级都起着重要的作用。现在, 大多数企业都开始注重产品线的开发, 完成从面向业务到面向技术的转换, 因此要为整个产品线设计软件架构。一般内容是:上承业务目标、下接技术决策、.控制复杂性、组织开发、利于迭代开发和增量交付、提高质量。

软件开发方法随着软件系统的规模增大而不断变化, 20世纪70年代以前, 软件开发基本上都是汇编程序设计;70年代中后期, 软件开发中出现了概要设计与详细设计;90年代中期, 是面向对象开发方法;90年代以后则是基于构件的软件开发。纵观软件体系结构技术发展过程, 架构设计得到了充足的发展, 并成为软件工程领域的研究热点。基于架构的软件设计方法能更好地隔离业务关注点及决策, 可以更好地应对需求变更, 以及更好地采用模块化设计方法。

二、基于架构的软件设计方法的理论

基于架构的设计 (简称ABD) 方法是由卡内基梅隆大学软件工程学院提出的, 主要用于为产品线工程及长生命系统设计架构提供方法上的指导。基于架构的设计提供了一个系统化的步骤, 此方法在发展中不断在完善, 用于设计概念性软件架构, 包含了一些基础的理论概念, 如设计元素、所采用的视图、用例及质量场景等。

架构设计包括共性与可变性, 软件模板与系统基础设施, 架构驱动元组需求, 质量属性、功能及架构模型。其中基于架构的设计关注对架构设计有影响的变化粒度, 共性是指变化中的不变部分, 可变性可以发生在功能、平台或环境中;软件模板与特定的设计元素相对应, 包括设计元素与公共服务的交互模式、设计元素与基础设施的交互模式、自身职责功能。软件模板作用具体为有助于集成、对于系统中可重用的组件是一个库, 并为构成系统架构提供基础。而对于一些质量属性建模技术, 软件模板的定义决定了交互模式;架构驱动元组包括功能需求、质量属性及业务需求。架构驱动元素依赖抽象的功能需求, 确定架构驱动元素要进行特定方面需求的详细调查, 架构驱动元素满足了, 设计就可以开始;架构模型包括组件类型集合及它们互操作模式, 确定操作数量及功能的标准将会不同于驱动需求, 架构风格就是实时计划策略。

需求阶段结果包括功能需求、质量属性、业务需求及约束, 运用基于架构的设计方法进行设计, 为考虑决策跟踪, 需要重新审视决策。基于架构的设计方法包括:

抽象功能需求。基于架构的设计假定需求输出是抽象的功能需求, 各种终端用户与特定系统相关联, 理解需求间的相关性对设计来说是很重要, 抽象功能的需求捕获可以对详细需求提供分类;

用例。用例是终端用户与系统间互操作的具体描述;

质量属性及业务目标。每个质量需求应当包括具体的输入及设想的应答, 而业务目标与质量属性的区别不是很明晰。

架构可选方案。方案的列举, 逻辑上属于基于架构的设计阶段, 它针对每, 一个质量属性及业务目标, 作为需求阶段的一个一输出, 并将凡是满足需求的架构都应当列出来。

质量场景。质量场景也可以具体化质量需求, 应当对它们分优先级进行管理。

约束。约束是预先指定的设计决策, 约束来自于业务还是技术并没有关系, 其设计过程就是做决策。很少有系统设计时无需考虑现存系统, 遗留系统将影响当前系统的设计。

三、基于架构的软件设计方法

首先要定义设计元素。它包括概念子系统、概念组件、具体组件、软件模板、基础设计的应用。基于架构的软件设计方法是对整个系统的分解。

其次是设计元素的生成顺序。随着理解的深入, 要对前期的决策重新考虑, 必须在适当的地方给以予记录。要考虑相关领域知识、新知识的融合应用和架构组人员的素质。

第三是设计元素内部的活动。它包括功能拆分, 选择基础架构, 功能分配。在功能分解中要基于功能一致性、数据或基于数据之上的操作行为模式相似、相似的抽象层和功能局部化标准;设计元素应有一个首要的架构风格模型, 确定的架构方案必须满足质量需求, 在设计记录中与设计元素相关联;架构模型的选择产生了组件类型集合, 每个设计元素的概念性接口也应当确定, 依据质量属性进行权衡;设计元素都有一个依附于它软件模板, 对于模板中的每一个功能, 要考虑是传递到子设计元素还是保留在当前位置, 并对子设计元素的功能也将进行核对。在这个过程中输出一个子设计元素列表, 表现带反馈循环的拆分设计元素的顺序步骤, 每执行一步都要对系统的更深入理解。用例可以用来对所选择的架构进行校验, 用例检验设计对需求的覆盖度, 然后生成生成并发视图、生成部署视图、校验质量场景以及校验约束。

最后, 按项目不同, 基于架构的软件设计依据一定的优先级顺序, 执行相应过程后生成设计元素的集合。

摘要：架构设计随着计算机技术的发展已经成为软件工程领域重要的内容, 提高了软件开发效率和软件开发期间质量属性及运行期间质量属性。

关键词：基于架构,软件,设计

参考文献

车载GPS系统软件架构设计 篇6

关键词：通讯,时钟,时序,容错能力

1 前言

汽车制造商在设计初期, 就开始考虑增加车载GPS导航的配置, 并逐渐成为车上的基本装备。GPS导航产品的稳定性和可靠性, 决定车辆品味及质量的关键要素。

2 导航系统参数

本文中的机型在设计的状态如下:主机与导航地图采用分离式, 地图为SD卡存储, EBOOT时钟频率32MHz, TFT显示屏, 显示屏主控芯片 (GDC) 采用Mstar776。

3 导航系统设计常见问题及注意事项

GPS导航系统, 与空间、地面控制部分进行数据交换, GPS车载设备需要对数据进行大量运算, 故系统涉及范围广, 更需要性能稳定、运行可靠, 下面就设计开发过程中经常遇到的问题, 进行详细阐述:

3.1 导航停止响应, 复位后进入黑屏状态;

但主机能切换到其他界面, AM, FM, DVD, 蓝牙等其它功能正常;若多次出现, 需对系统匹配方面进行检查;检查导航系统与SD卡通信状态, 即考虑SD卡数据交换、时钟通讯频率的情况:

地图SD卡通讯频率上限为25MHz, 数据显示, EBOOT CLK时钟频率超出SD卡通讯频率, 这样会引起SD卡初始化不能完成, 系统内核无法加载, 表现为主机黑屏, 不能进入导航工作状态;可优化EBOOT CLK时钟频率, 使之与地图SD卡的通讯频率保持一致。

3.2 手写输入或设置目的地时, 存在较小概率导航不响应触摸屏操作, 导致导航无法工作, 但主机能够切换到其他界面, AM, FM, DVD, 蓝牙等其它功能正常。

检查软件容错处理能力, 主机MCU与导航系统通讯异常, 导航软件无法接受MCU发出的触摸屏坐标信息, 查看导航系统接收MCU串口协议消息中是否有错误信息, 导致导航运行错误。

检查步骤如下:

(1) 检测导航系统停止响应状态时MCU与导航之间的串口通信, 包括触摸指令和相关交互协议, 是否存在MCU有指令发出, 导航没有回应的现象。

(2) 检测从MCU发过来的数据, 人为在串口通讯的收发段间歇短路加入干扰。检查导航系统是否存在停止响应概率加大, 干扰或者错误数据容易引起导航系统运行不正常的现象。

(3) 上述无异常时, 分析通讯异常处理部分程序, 是否存在发生数据异常后的数据指针未按设计要求进行加一操作 (及调的下一帧数据, 而是继续判断有错误的帧的数据, 形成死循环) , 通讯线程死锁。正确的通讯协议帧是由“帧头+长度+数据+校验和”组成的, 当外加干扰, 或其它数据异常发生时有可能发生数据错位, 此时数据指针应该丢弃错误的数据, 再寻找正确的帧头。

我们可以通过修改导航系统的串口容错机制, 确保数据异常时能够自动从错误状态恢复, 不引起线程死锁。

3.3 USB状态关机 (POWER OFF) , ACC断电后再上电, 开机后TFT屏正常显示USB的UI界面和歌曲信息, 0.5秒后UI界面变为LO-GO (USB歌曲信息维持正常) , 随后USB的UI界面立刻恢复正常。

软件架构流程中的显示logo背景的部分程序存在冗余现象。最终优化后的软件程序如下图所示:

4 总结