软件体系结构范文
时间：2023-03-20 08:48:00
软件体系结构范文第1篇
摘要:在分析软件体系结构课程特点及面临的挑战的基础上,讨论了该课程的教学目的,提出了以学生为中心、基于案例的教学方法。教学实践证明提出的教学模式能够激发学生的学习兴趣,帮助学生更好地掌握本课程的理论和方法。
关键词:软件体系结构;软件案例;教学方法
中图分类号:G642文献标识码:A文章编号:1009-3044(2009)28-7974-03
Software Architecture Teaching Research
SHU Yong-an1, LUO Bin1, ZHU Fang-yi2
(puter Science and Technology Institute, Anhui University, Hefei 230039, China; 2.Management Institute, Hefei University of Technology, Hefei 230009, China)
Abstract: On the basis of analyzing the characteristics of software architecture course and the challenges faced, this paper discussed the teaching goals and proposed student-centric and case-based teaching methods. The teaching process proved that the teaching mode can stimulate students' learning interest and help them master the theories and methods of the course.
Key words: software architecture; software case; teaching method
随着信息产业的发展,软件系统规模越来越大、越来越复杂,对整个软件系统的结构和规格的说明比起对计算的算法和数据结构的选择显得更加重要。这使得软件体系结构日益成为软件工程领域的一个主要热点。早期的研究人员如Mary Shaw[1]等认为体系结构类似于全局设计。这种观点强调设计模式、体系结构模式和用某种体系结构描述语言(ADL:Architectural Description Language)对最终的体系结构进行描述。另一种广义观点认为,软件体系结构主要是对不同风险承担者的不同质量目标进行权衡。这样,软件体系结构设计就变成一种平衡行为,对涉及到的所有风险承担者的功能和质量需求的集合进行协调,最终形成一个满足这些需求的全局设计。这种观点正被越来越多的人所接受[2]。
软件体系结构在设计大型复杂软件系统中的重要作用是软件体系结构课程产生的主要原因。“软件体系结构”作为高等学校软件工程专业的一门核心课程,是对软件开发、研究过程中形成的软件体系结构理论成果和实践经验的总结。
1 课程特点及面临的挑战
1.1 软件体系结构课程特点
1) 软件体系结构的概念、原理和方法较为抽象。本课程使用文献[2]中的软件体系结构定义:一个程序或计算系统的软件体系结构是该系统的结构,包括软件的元素,这些元素的外部可视属性以及这些元素间的关系。由于软件体系结构主要处理算法与数据结构之上关于整体系统结构设计和描述方面的一些问题,如全局组织和全局控制结构,关于通讯、同步与数据存取的协议,设计构件功能定义,物理分布与合成,设计方案的选择、评估与实现等[3],因此它的原理和方法较为抽象。
2) 软件体系结构是降低开发复杂软件系统风险的工具。传统的软件开发过程可以划分为从概念直到具体实现的若干个阶段,包括问题定义、需求分析、软件设计、软件实现及软件测试等。软件体系结构的建立在需求分析之后,软件设计之前。软件体系结构设计是尽早地做出体系结构方面的重要决策,这些决策在后来的软件开发过程中很难更改。尽早做出正确的决策的目的是为了降低后来改变它们的风险。软件体系结构的目标是建立满足关键需求的系统,而不是设计一个完美的体系结构。这样,产业中的软件体系结构师必须决定哪些体系结构关注点需要仔细处理,哪些关注点可以少注意,以及如何在冲突的关注点间进行平衡。
3) 软件产业环境同软件体系结构教学中的典型练习有很大差别。软件体系结构师不能简单把某种体系结构风格或模式应用于系统变化。软件体系结构师应理解已有的体系结构及其局限性,找出可行的方法去解决新的需求或存在的问题,并评价该方法对体系结构的影响。
4) 一个软件项目涉及很多软件体系结构师和开发人员,与其他软件体系结构师交流并作出共同的决策是常见的工作模式。软件体系结构师和软件体系结构课程学生都应学会如何在一个软件体系结构设计过程中共同承担责任以及在其他人设置很多体系结构约束条件的环境中工作。
1.2 软件体系结构课程教学面临的挑战
一般来说,软件体系结构教学面临以下挑战:学生对现实生活中的软件体系结构挑战没有较多的经验,他们对较难的高层设计任务接触较少。另外,学生对应用领域的熟悉程度还不足以设计该领域的软件体系结构。因此,由于有限的能力和时间,大学课程的设计问题往往从零开始。这与产业环境形成鲜明对照。在产业环境中,体系结构师需要考虑很多已有的软件和系统。与大学的课程练习相比,实际应用中的体系结构决策往往预先受到严格的约束。另外,学生常常有一种心理模式,期望对明确描述的问题去寻找清晰的答案。当遇到松散描述的问题或模糊的问题时,他们往往感到困惑。因此,在大学的软件体系结构课程中开放性问题的解决难度较大。
2 软件体系结构课程的目的
1)学生应该掌握软件体系结构的有关概念,如视图,软件体系结构风格,设计模式等。通过理论和实验教学,使学生具有一定的体系结构设计经验,提高学生处理复杂软件体系结构设计问题的能力。
2)本课程要求教学中提出和要解决的问题对学生具体明确。本课程更多的是通过“做”来学习,“做”主要是构建一个背景来讨论和理解教学内容。
3)本课程在教学过程中强调软件体系结构设计是一个团队活动而不是单个软件体系结构师的个人任务。
4)学生应该知道如何开发一个软件体系结构的不同软件体系结构视图,解决不同风险承担者的关注点,我们使用文献[4]作为模型。
5)学生应懂得软件体系结构的特性。一个软件体系结构从来没有对错之分,至多是能够更好地满足某些环境,它需要在不同风险承担者的关注点间做出大量的平衡。也许存在不同的可接受的解决方案,但最终选择的解决方案依赖于如何在不同风险承担者的关注点间做出平衡[5]。
6)学生应该学会如何评价一个软件体系结构。这给予学生学习和评价一组体系结构决策和平衡的机会。评价活动有助于学生深入了解不同体系结构方案的边界。在评价过程中,学生会理解其它关注点被选中时对该体系结构造成的影响,形成对体系结构描述的质量目标的整体印象。由于评估涉及到要向各风险承担者解释软件体系结构以及导致该软件体系结构的各个决策,这进一步强调了软件体系结构中沟通交流的重要性。
3 基于案例的软件体系结构教学
3.1 课程主要内容
对于大学四年级学生,本课程主要强调概念、原理、方法和实验。课程内容框架如下[6-7]:1)软件体系结构概论;2)软件体系结构建模;3)软件体系结构风格;4)软件体系结构模式;5)软件体系结构描述;6)动态软件体系结构;7)Web服务体系结构;8)基于体系结构的软件开发;9)软件体系结构评估。
根据上述框架,我们首先分析了软件体系结构在软件开发周期中的作用。鉴于目前软件体系结构还没有一个精确的定义,我们讨论了几个有代表性的软件体系结构定义,对它们之间主要区别进行比较。然后我们介绍了如何对软件体系结构进行建模,通过实例重点强调“4+1”模型。
本课程占用较多课时讨论了一些经典的和流行的软件体系结构风格和模式,通过教学案例的讲解和实验,学生应掌握并能够应用这些风格和模式。
为对很多有用的体系结构范例(过程控制、客户机/服务器等)进行统一的描述,需要建立形式化的、规范的描述来对软件体系结构进行表示和推理。我们介绍了多种软件体系结构描述语言,重点介绍基于UML的软件体系结构描述语言并要求学生能够使用该类语言描述一些经典的软件体系结构。
动态软件体系结构是软件体系结构重要研究方向之一,主要研究那些具有特殊使命且需要长期运行的软件系统在运行时刻体系结构的变动。我们主要讨论基于构件的动态系统结构模型和动态体系结构描述语言。
Web服务体系结构是当前流行的软件体系结构之一。我们通过实例详述如何调用Google公司的Web Service接口进行基于Web服务体系结构的软件开发。
在掌握上述内容之后,我们导入基于体系结构的软件开发模型,该模型把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现、演化等六个子过程。
通过具体的实例来评价软件体系结构是本课程教学的重要环节之一。我们主要讨论体系结构权衡分析方法(architecture tradeoff analysis method,ATAM)。通过分析软件体系结构对系统的使用或修改活动的支持程度来判断该体系结构对相关的质量需求的满足程度。例如,用一系列对用户需求的变动来反映易维护性方面的需求,用一系列攻击性操作来代表安全性方面的需求等。
3.2 教学案例
由于本课程内容较为抽象,而学生的设计经验不足,仅根据教材内容授课难以取得较好的效果。为此我们采取以案例为主的方法,将抽象的理论和具体的案例结合起来。案例的选取遵循以下原则:一是案例的选取来源于实际的应用系统。一个应用系统往往较为庞大,我们对其进行加工提炼,以适合课堂教学,学生掌握后,能应用于实际,提高软件开发能力。二是案例的选取紧紧围绕教学内容和当前软件行业发展的状况。本课程围绕软件体系结构设计模式、风格以及当前流行的软件体系结构等教学重点选取案例。三是案例能进行功能扩充。我们在每个案例中留置接口,要求学生在实验课中结合其它课程知识,对教学案例进行扩充。这样不仅有助于学生对教学内容的掌握,而且能够培养学生的动手能力。
我们在教学过程中使用的典型案例有:
1)设计模式案例:MVC、Observer、Singleton和Proxy。以MVC为例,我们在JAVA JDK及Netbeans环境下实现如下功能:当用户在图形化用户界面输入一个圆的半径时,图形用户界面画出该圆,程序显示该圆的半径、周长和面积;当用户在图形化用户界面上拖动表示圆半径的滑块时,自动显示圆的半径、周长和面积,并在图形界面上画出图形。该案例把交互系统的组成分解成模型(M)、视图(V)、控制(C)三种构件。通过该案例的学习,学生能很快领会基于MVC的程序设计思想。
2)软件体系结构风格案例:客户机/服务器(C/S)、浏览器/服务器(B/S)风格。以B/S风格为例,我们在Java JDK、Myeclipse及Tomcat环境下实现计算机学院学生学籍管理系统。通过本案例的学习,要求学生掌握C/S、B/S风格的应用。
3)Web Service案例:Googlesearch。本案例调用Google公司的web service,使得程序可以发送查询,并且接受和打印查询得到的结果。通过该案例的学习,要求学生掌握调用Web service的方法。
4) 体系结构评估案例:文章中查找和重组关键词系统(Key Word In Context,KWIC)。
KWIC系统的基本功能是,输入一些句子,KWIC系统把这些句子中的词循环移位转变为新的句子,然后按字母顺序进行输出。本案例采用共享内存、抽象数据类型、隐式调用和管道过滤器四种方案分别实现,要求学生对上述方案进行比较,进行体系结构评估。
4 教学方法
1)激发学生的学习兴趣。本课程的对象是大学高年级学生,他们面临就业和考研的压力。教师在课堂上灌输抽象的概念和模型会使学生觉得枯燥无味,课堂气氛沉闷。我们在重点章节首先讨论有特色的案例,引导学生对案例的源代码进行逆向工程,然后得到软件体系结构。例如,在讲解Web服务体系结构时,我们通过分析Googlesearch案例来分析Web服务体系结构模型,使用Googlesearch来搜索“安徽大学”相关信息并与Google公司搜索平台的结果相比较,从一开始就引起学生的浓厚兴趣。
2)更新教学内容。由于教材内容往往不能及时反映软件体系结构理论和实践的最新进展,我们在教学过程中穿插最新的学术论文,引导学生关注一些热点问题,使得教学内容与时俱进。我们还同有关高校实验室和具有一定规模的IT公司保持联系,借鉴它们的实践经验充实教学案例。
3)分组案例研究。我们将学生分为多个小组,每组3到4人。我们将从工程项目和书籍中收集的案例集中起来,供每组学生选择。每组学生可以从案例的源代码中抽象出软件体系结构,也可以分析某些案例的体系结构风格或模式,或者对有些案例提出其它的解决方案等。在此过程中,小组中的每个学生担任一个或多个风险承担者。每个小组作为其它小组工作的评价者。最后每组就相关内容以PPT形式作一个报告,时间为20分钟,老师和其它小组成员给出评定成绩。实践表明该方法能充分调动学生的学习积极性。
4)实验平台建设。本课程的教学应使学生通过这门课的学习,能够综合运用其它专业知识,在实际工作中进行基于体系结构的软件开发。为此我们设计几个规模较大、结构较为完整的软件项目作为实验平台,比如客户机/服务器(C/S)、浏览器/服务器(B/S)和Googlesearch等,此类项目包括体系结构需求、体系结构设计、体系结构文档化、体系结构复审、体系结构实现和体系结构演化。我们要求学生以团队形式在平台上自定应用领域实践自己的设计方案或对已有的方案进行扩充。通过让学生开发他们自己的体系结构视图和视点,让他们决定要解决的关注点,对同一问题,得出一系列不同的解决方案。学生可以从不同的解决方案中吸取教训,从质量优先级的角度评价不同解决方案的差别。实验课程结束,要求每个团队提交规定的文档,向全班演示实验结果,由老师和同学集体进行评价,给出成绩。实践表明,实验课的教学培养了学生的团队精神,进一步加强了学生对基于体系结构软件开发过程的掌握。
5 结论
针对软件体系结构课程的特点和学生的状况,我们在教学内容、教学方式等方面进行改进,逐步形成以案例为导引、以学生为中心的教学模式,充分调动学生的学习积极性。通过本课程的学习,学生能够很好地掌握软件体系结构的理论、方法和技术,具备一定的基于体系结构软件开发能力。
参考文献:
[1] Shaw M. Toward Higher Level Abstractions for Software Systems[J]. Data & Knowledge Engineering. Netherland:Elsevier Science Publishers B. V.1990,5(2): 119-128.
[2] Bass L, Clements P, Kazman R. Software Architecture in Practice[M]. New Jersey,second edition.USA: Addison Wesley, 2003.
[3] Shaw M, Garlan D. Software Architecture: Perspectives on an Emerging Discipline[M].New York: Prentice Hall,1996.
[4] IEEE Recommended Practice for Architecture Description[J]. IEEE Standard 1471, IEEE, 2000.
[5] M?]nnist?i T, Savolainen J, Myll?]rniemi V. Teaching Software Architecture Design[C]. Seventh Working IEEE/IFIP Conference on Software Architecture. Vancouver, BC, Canada. Feb 18-21, 2008.117-124.
[6] 张友生.软件体系结构[M].2版.北京:清华大学出版社,2006.
软件体系结构范文第2篇
关键词 软件体系结构；UML；建模
中图分类号TP31 文献标识码A 文章编号 1674-6708（2010）33-0230-02
0引言
软件体系结构（Software Architecture）是近年来软件工程领域中的一个热点研究方法。它的出现为软件复用特别是设计方案的复用带来了新的前景。体系结构并非可运行的软件，确切的说，它是一种表示，这种表示使得软件工程师能够分析设计在满足需求方面的效力，也能够在在改变仍然相对容易的阶段考虑体系结构可能的选择，还能够减少和软件构造相关联的风险。软件体系结构不包括硬件、网络或物理体系结构。软件体系结构不是整个系统的描述，而仅仅是系统内的软件和创建软件所需环境的描述。
UML（Unified Modeling Language）统一建模语言,是用来对软件密集系统进行可视化建模的一种语言。UML为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。UML作为一种模型语言，它使开发人员专注于建立产品的模型和结构，而不是选用什么程序语言和算法实现。当模型建立之后，模型可以被UML工具转化成指定的程序语言代码。
UML的出现及其与体系结构研究结论的结合，为体系结构的应用带来了新的契机。
1软件体系结构视点
软件体系结构视点是通过把UML图的类型运用到具体的体系结构开发任务而确定的。每一个视点有具体的建模目标和系统相关者。
表1所列的视点提供了一组高度概括的软件描述。环境视图提供了对系统边界及系统发生交互的外部实体集合的概述。分析视图提供了一个以建模为中心的实体的抽象集合。
表2给出了一个以描述软件设计为目的的视点的集合。构件、构件交互及构件状态视图提供了一个对于逻辑运行结构及其功能，以及它们之间通信的映射。子系统结构依赖视图提供了一个子系统依赖关系和接口的图形表示。分层子系统视图提供了一个所有子系统高度抽象的视图。逻辑数据视图提供了构件共有的数据模型描述。
通常，大型软件系统的整体视图时及其重要的。而一些视图会被同时使用。例如，在构件接口的设计中，通常要创建构件视图、设计交互视图和构件状态视图。
2实例系统
为了阐明大型系统的各方面的概念和视图，选择一银行系统为范例。这个实例说明了一个完整的银行系统。系统中的遗留部分，可以支持传统的结算、存款和贷款业务。这部分包括用户记录存储、交易历史记录和交易管理，也支持银行职员和用户查询。遗留部分还包括和外部银行、其他分支机构、旧式ATM、银行职员及客户电话查询的接口。新添加的部分，可以支持基于Web的用户接口、双向寻呼接口、移动电话浏览器访问接口、增强型ATM和连接分支结构的增强型接口。网络用户和移动电话和浏览器接口不仅支持传统的账目查询，还可以支持股票证挂历，资金电子过户，支票付款和账目转账。出纳员、账户经理和信贷员接口属于基于企业网的新式接口。
2.1系统环境和领域分析
在系统环境和领域分析中需要构件最高层次的体系结构所需的几种整体来表示，包括环境视图、概念图和整体分析视图。概念图比较随意也不稳定，没有特定的建模方式。
环境视点包括系统和系统有接口的外部实体及系统和这些实体的接口，目的是使用一个视图来描述所有外部实体及它们之间的接口信息。环境视图往往是体系结构组创建的第一个系统视图，包括系统和外部系统之间的接口及系统和人的接口。图1描述了银行系统的环境视图。
环境视图中，操作者的名字应该与定义的角色相匹配货相互映射，操作者的角色可以有不同的等级。例如，网络操作者可以进一步细分为ATM网络操作者和局域网设备操作者。
整体分析视点提供了一个关于问题领域的一致看法，独立于任何细节之外。该视点提供实体集以及对它们之间的关系、属性和行为的表示方法，可以用来构造分层子系统视图和子系统接口以来试图，主要用来帮助理解系统中的关键实体，用来构建系列化的部件。
2.2 事物和数据设计
图2逻辑数据模型
逻辑数据体系结构描述了实体的结构或形式、数据关系，以及约束。逻辑数据体系结构通常被称作为数据框架或者逻辑数据模型。数据框架采用的带有属性的UML类来表述。
逻辑数据视点概括了系统中所有主要数据实体，是一个关注于属性和关系的UML视图。在该视图中只包括由多个构件或者子系统共享的数据实体。图2描述了银行系统的逻辑数据模型。
3结论
本文以银行系统的分析和设计为例，介绍了如何利用UML的视点建模。使用了用例图描述说明外部系统角色和设计中的系统，使用类图描述了实体集的关键数据视图。
设计软件的过程中应通过一系列视图展开，并在单一的结算中直接实现所有的内容。体系结构是系统的映射，它定义了系统的不同组成部分、它们之间的关系和交互、通信机制、以及如何修改系统组件、如何添加新组件等整体规则。好的体系结构强调系统的功能和非功能两个方面。使用UML的过程是以体系结构为中心的，并且在过程的早期就要建立这个体系结构。
参考文献
[1]Booth G, Rumbaugh J, Jacobson I.The Unified Modeling Language User Guide[M],1999.
[2]JosephSchmuller.UML基础案例与应用[M].李虎，王美英，万里威，译.北京：人民邮电出版社，2002，6.
[3]Young Joon Yang,Soon Yong Kim,Gui Ja Choi,Eun Sook Cho,Chul JinKi,Soo Dong Kim.A UML-based object-orientedframework development methodology[J].Software Engi neering Conference, 1998. Proceedings.1998 Asia Pacific，1998，12：2-4.
[4]马重明，张学旺，范时平.基于UML的软件体系结构开发方法[J].计算机工程与应用，2006，42(4)：118-120.
软件体系结构范文第3篇
关键词：软件体系结构；重用；模式
中图分类号：TP311文献标识码：A文章编号：1009-3044(2008)35-2519-02
A Comprehensive Introduction to the Study of Software Architecture
WANG Qiang
(AnHui Technical College of Mechanical and Electrical Engineering, Wuhu 241000, China)
Abstract: Software architecture is the hotspot in software engineering research. This article discusses about the purpose and current situation of software architecture researching.
Key words: software architecture; reuse; mode
1 引言
随着计算机技术的发展和应用的不断深入，软件系统的规模和复杂度日益增加，在软件设计过程中人们所面临的问题不仅仅是考虑软件系统的功能问题，而是面临要解决更难处理的可修改性，性能，可靠性等非功能性问题。特别是80年代以来，对软件适应变更的要求越来越高，所以对软件整体的设计已经超过了算法和数据结构，成为系统开发关注的主要问题。软件开发最大的风险来自需求变更，但一蹴而就搞定需求不现实，好的体系结构是易改动的基础。 能否复用很重要，设计复用比代码复用更有用更难。因此，研究软件体系结构研究的能提高软件生产率和简化维护。提高软件生产率的关键在于软件相关部分的复用，而简化维护的关键是减少软件理解的成本和提高软件的质量，这就是研究软件体系结构的目的。
2 软件体系结构的概念
软件系统的规模在迅速增大的同时，软件开发方法也经历了一系列的变革.在此过程中，软件体系结构也由最初模糊的概念发展到一个渐趋成熟的技术。
1) 1992年Perry 和Wo1f 在他们早期关于软件体系结构的论文中指出:软件体系结构是一组具有一定形式的结构化元素或称为设计元素组成。
2) 1993年Shaw 和Garlan 认为软件体系结构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计。
3) 1994年Hayes Roth 则认为软件体系结构是一个抽象的系统规范，主要包括用其行为来描述的功能构件和构件之间的相互连接、接口和关系。
4) 1995年Garlan 和Perry 在IEEE 软件工程学报上又采用如下的定义：软件体系结构是一个程序各构件的结构、它们之间的相互关系以及进行设计的原则和随时间进化的指导方针。
5) 1996年Boehm 和他的学生提出，一个软件体系结构包括一个软件和系统构件，互联及约束的集合。
6) 1997年Ctements 和Kazman在《使用软件体系结构》一书中给出如下的定义：一个程序或计算机系统的软件体系结构包括一个或一组软件构件、软件构件的外部的可见特性及其相互关系。
3 软件体系结构的现状
下面介绍几种常见的体系结构。
模型-视图-控制结构是交互式应用程序广泛使用的一种体系结构。它有效地在存储和展示数据的对象中区分功能模块以降低它们之间的连接度，这种体系结构将传统的输入、处理和输入模型转化为图形显示的用户交互模型，或者换一种说法，是多层次的Web商业应用；MVC体系结构具有三个层面：模型（Model）、视图(View)和控制(Controller)，每个层面有其各自的功能作用。
模型层负责表达和访问商业数据，执行商业逻辑和操作。也就是说，这一层就是现实生活中功能的软件模拟；在模型层变化的时候，它将通知视图层并提供后者访问自身状态的能力，同时控制层也可以访问其功能函数以完成相关的任务。
视图层负责显示模型层的内容。它从模型层取得数据并指定这些数据如何被显示出来。在模型层变化的时候，它将自动更新。另外视图层也会将用户的输入传送给控制器。控制层负责定义应用程序的行为。它可以分派用户的请求并选择恰当的视图以用于显示，同时它也可以解释用户的输入并将它们映射为模型层可执行的操作；在一个图形界面中，常见的用户输入包括点击按钮和菜单选择。在Web应用中，它包括对Web层的HTTP GET和POST的请求；控制层可以基于用户的交互和模型层的操作结果来选择下一个可以显示的视图，一个应用程序通常会基于一组相关功能设定一个控制层的模块，甚至一些应用程序会根据不同的用户类型具有不同的控制层设定，这主要是由于不同用户的视图交互和选择也是不同的。
在模型层、视图层和控制层之间划分责任可以减少代码的重复度，并使应用程序维护起来更简单。同时由于数据和商务逻辑的分开，在新的数据源加入和数据显示变化的时候，数据处理也会变得更简单。
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。它反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。按这种方式理解，软件体系结构风格定义了用于描述系统的术语表和一组指导构件系统的规则。
对软件体系结构风格的研究和实践促进了对设计的复用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。体系结构风格的不变部分使不同的系统可以共享同一个实现代码。只要系统是使用常用的、规范的方法来组织，就可使别的设计者很容易地理解系统的体系结构。例如，如果某人把系统描述为"客户／服务器"模式，则不必给出设计细节，我们立刻就会明白系统是如何组织和工作的。
下面是Garlan和Shaw对通用体系结构风格的分类：
1) 数据流风格：批处理序列；管道/过滤器
2) 调用/返回风格：主程序/子程序；面向对象风格；层次结构
3) 独立构件风格：进程通讯；事件系统
4) 虚拟机风格：解释器；基于规则的系统
5) 仓库风格：数据库系统；超文本系统；黑板系统
设计模式使人们可以更简单方便地复用成功地设计和体系架构。将以证实的技术表述成设计模式也会使新系统开发者更容易理解其设计思路。设计模式帮助你做出有利于系统复用的选择，避免设计损害了系统复用性。通过提供一个显示类和对象作用关系以及它们之间潜在联系的说明规范，设计模式甚至能够提高已有系统的文档管理和系统维护的有效性。简而言之，设计模式可以帮助设计者更快更好地完成系统设计。
一个设计模式描述了对于特定设计问题被验证的解决方案，它综合了所有开发者对这个问题所在领域的知识和见解；同时也是对于常见问题的可重用方案，它们一般适用于单个问题，但是组织在一起就可以提供整个企业系统的解决方案。J2EE平台就用到很多设计模式，列举如下：
1) 前控制器。
2) 控制器
3) 视图
4) 视图帮助
5) 会话面
6) 数据访问对象
7) 值对象或传输对象
8) 截取过滤器
随着软件体系结构的不断发展，出现了一种新型的体系结构即SOA。SOA被称为软件体系结构的划时代革命。
SOA是一种结构模型，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件交互的人为依赖性。SOA的关键是“服务”的概念，W3C将服务定义为：“服务提供者完成一组工作，为服务使用者交付所需的最终结果。最终结果通常会使使用者的状态发生变化，但也可能使提供者的状态改变，或者双方都产生变化”。将SOA定义为：“本质上是服务的集合。服务间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数。” 将SOA定义为：“按需连接资源的系统。在SOA中，资源被作为可通过标准方式访问的独立服务，提供给网络中的其他成员。与传统的系统结构相比，SOA规定了资源间更为灵活的松散耦合关系。” Gartner则将SOA描述为：“客户端/服务器的软件设计方法，一项应用由软件服务和软件服务使用者组成……SOA与大多数通用的客户端/服务器模型的不同之处，在于它着重强调软件组件的松散耦合，并使用独立的标准接口。” Gartner相信BPM和SOA的结合对所有类型的应用集成都大有助益――“SOA极大的得益于BPM技术和方法论，但是SOA面临的真正问题是确立正确的企业意识，即：强化战略化的SOA计划（针对供应和使用）并鼓励重用。”虽然不同厂商或个人对SOA有着不同的理解，但是我们仍然可以从上述的定义中看到SOA的几个关键特性：一种粗粒度、松耦合服务结构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。
4 软件体系结构存在的不足
尽管软件体系结构研究领域取得了若干成果，但在应用方面，软件体系结构仍然有很多可以改进的地方。N. Medvovonic认为，目前对软件体系结构的理解还仅限于直观、或当作稀奇事、或当作民间传说；语义丰富但不严谨。体系结构似乎没有解决实际问题。由此可见，若要有效地指导软件工程实践、为软件开发提供一个好的结构及其设计结构的指导原则，软件体系结构研究还有若干问题需要解决。比如缺乏统一的软件体系结构的概念，各种软件体系结构的不易操作性，ADL繁多，缺乏统一的ADL支持等等。
5 前景展望
目前，软件体系结构领域研究非常活跃。随着研究的不断深入，软件复用的层次越来越高，人们在开发新的系统时不必总是重复别人已经创造的东西，而是可在软件开发中复用已有成果，这样可以把注意力投入到软件新增功能上，提高软件开发效率。
针对软件体系结构发展趋势，Clements预测在未来的5~10年内软件体系结构研究将围绕如下5个方向展开:体系结构创建与选择；体系结构表示；体系结构分析；基于体系结构开发；体系结构演化.而Perry在IFIP 2000 年世界计算机大会主题演讲中认为，最为重要的3个研究方向是:体系结构风格、体系结构连接件和动态体系结构。
参考文献：
[1] 王霞俊.浅谈软件体系结构[J].常州轻工职业技术学院学报,2007(1).
[2] 邓伦丹,罗丹,汪伟.几种主要的软件体系结构风格的分析[J].科技信息,2007(32):102.
[3] 孙昌爱,金茂忠,刘超.软件体系结构研究综述[J].软件学报,2002(13)
[4] 秦建超,杜友福,孟珍伟.浅谈软件体系结构科技信息[J],2007(2)
[5] Michale Kircher.面向模式的软件体系结构[M].1版.北京:机械工业出版社,2005:5-6.
[6] The Boeing Company-Defense and Space Group.STARS conceptual framework for reuse processes,lockheed martin tactical defense system.STARS Program Technical Report,1994.
软件体系结构范文第4篇
一、软件体系结构风格分析
最初的软件体系结构是Mainframe结构——客户、数据和程序都被集中在主机上,通常只有少量的GUI界面,对远程数据库的访问比较困难。随着PC的广泛应用,该结构逐渐被淘汰。在20世纪80年代中期出现了Client/Server分布式计算结构,应用程序的处理在客户机和服务器之间分担。随着大型软件系统的开发,这种结构在系统的部署和扩展性方面暴漏出不足。随着Internet的发展,一个更灵活的体系结构“三层/多层计算”体系结构应运而生。
Garlan和Shaw将通用软件体系结构风格总结为以下几类:
1.数据流风格:批处理序列;管道/过滤器。2.调用/返回风格:主程序/子程序;面向对象风格;层次结构。3.独立构件风格:进程通讯;事件系统。4.虚拟机风格:解释器;基于规则的系统。5.仓库风格:数据库系统;超文本系统;黑板系统。
下面将介绍几种主要和经典的体系结构风格和它们的优缺点。
1.C2风格。C2体系结构风格可以概括为:通过连接件绑定在一起的按照一组规则运作的并行构件网络。图1中构件与连接件之间的连接体现了C2风格中构建系统的规则。
C2风格是最常用的一种软件体系结构风格。从C2风格的组织规则和结构图中,我们可以得出,C2风格具有以下特点:
(1)系统中的构件可实现应用需求,并能将任意复杂度的功能封装在一起;(2)所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的;(3)构件相对独立,构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行,或某些构件共享特定控制线程之类的相关性假设。
2.数据抽象和面向对象风格。目前软件界已普遍转向使用面向对象系统,抽象数据类型概念对软件系统有着重要作用。这种风格的构件是对象,或者说是抽象数据类型的实例。对象是一种被称作管理者的构件,因为它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。图2是数据抽象和面向对象风格的示意图。
面向对象的系统有许多的优点:
(1)因为对象对其他对象隐藏它的表示,所以可以改变一个对象的表示,而不影响其他的对象。(2)设计者可将一些数据存取操作的问题分解成一些交互的程序的集合。面向对象的系统也存在着某些问题:①为了使一个对象和另一个对象通过过程调用等进行交互,必须知道对象的标识。只要一个对象的标识改变了,就必须修改所有其他明确调用它的对象。②必须修改所有显式调用它的其他对象,并消除由此带来的一些副作用。
3.基于事件的隐式调用风格。基于事件的隐式调用风格的思想是构件不直接调用一个过程,而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册,当一个事件被触发,系统自动调用在这个事件中注册的所有过程,这样,一个事件的触发就导致了另一模块中的过程的调用。基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这样不能假定构件的处理顺序,甚至不知道哪些过程会被调用。隐式调用系统的主要优点有:(1)为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时,只需将它注册到系统的事件中。(2)为改进系统带来了方便。当用一个构件代替另一个构件时,不会影响到其他构件的接口。隐式调用系统的主要缺点有:①构件放弃了对系统计算的控制。一个构件触发一个事件时,不能确定其他构件是否会响应它。而且即使它知道事件注册了哪些构件的构成,它也不能保证这些过程被 调用的顺序。②数据交换的问题。有时数据可被一个事件传递,但另一些情况下,基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下,全局性能和资源管理便成了问题。③既然过程的语义必须依赖于被触发事件的上下文约束,关于正确性的推理存在问题。
[1] [2] 下一页
4.管道/过滤器风格。在管道/过滤器风格的软件体系结构中,每个构件都有一组输入和输出,构件读输入的数据流,经过内部处理,然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成,所以在输入被完全消费之前,输出便产生了。因此,这里的构件被称为过滤器,这种风格的连接件就象是数据流传输的管道,将一个过滤器的输出传到另一过滤器的:请记住我站域名输入。
图3是管道/过滤器风格的示意图。
管道/过滤器风格的软件体系结构的优点:
(1)使得软构件具有良好的隐蔽性和高内聚、低耦合的特点;(2)支持软件重用。重要提供适合在两个过滤器之间传送的数据,任何两个过滤器都可被连接起来;(3)系统维护和性能增强简单;(4)支持并行执行。每个过滤器是作为一个单独的任务完成,因此可与其他任务并行执行。管道/过滤器风格的主要缺点:①通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据,但它们是独立的,所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。②不适合处理交互的应用。当需要增量地显示改变时,这个问题尤为严重。③因为在数据传输上没有通用的标准,每个过滤器都增加了解析和合成数据的工作,这样就导致了系统性能下降,并增加了编写过滤器的复杂性。
5.批处理风格。批处理风格的每一步处理都是独立的,并且每一步是顺序执行的,只有当前一步处理完后,后一步处理才能开始,数据传送在步与步之间作为一个整体。批处理的典型应用是经典数据处理和程序开发。
批处理风格与管道过滤器风格的共同点是把任务分解成一系列固定顺序的计算单元(组件),组件间只通过数据传递交互。区别表现在以下几个方面:批处理是全部的、高潜伏性的、输入时可随机存取、无合作性、无交互性,管道过、滤器是递增的、数据结果延迟小、输入时处理局部化、有反馈、可交互。
6.仓库风格。在仓库风格中,有两种不同的构件:中央数据结构说明当前状态,独立构件在中央数据存贮上执行,仓库与外构件间的相互作用在系统中会有大的变化。
若输入流中某类时间触发进程执行的选择,则仓库是一传统型数据库;另一方面,若中央数据结构的当前状态触发进程执行的选择,则仓库是一黑板系统。
二、三层C/S软件体系结构分析
C/S软件体系结构是20世纪90年代成熟起来的技术,它将应用一分为二,服务器(后台)负责数据管理,客户机(前台)完成与用户的交互任务。
传统的二层C/S结构存在以下几个局限:1.二层C/S结构是单一服务器且以局域网为中心的,所以难以扩展至大型企业广域网或Internet;2.软、硬件的组合及集成能力有限;3.客户机的负荷太重,难以管理大量的客户机,系统的性能容易变坏;4.数据安全性不好。因为二层C/S有这么多缺点,三层C/S结构应运而生。三层C/S结构是将应用功能分成表示层、功能层和数据
层三个部分,如下图所示。
表示层是应用的用户接口部分,它担负着用户与应用间的对话功能。表示层一般使用图形用户接口,操作简单、易学易用。功能层相当于应用的本体,它是将具体的业务处理逻辑编入程序中。功能层的程序多半是用可视化编程工具开发的。数据层就是数据库管理系统,负责管理对数据库数据的读写。数据库管理系统必须能迅速执行大量数据的更新和检索。因此,一般从功能层传送到数据层的要求大都使用SQL语言。
对二层C/S结构的局限,三层C/S的解决方案是:对这三层进行明确分割,并在逻辑上使其独立。与传统的二层结构相比,三层C/S结构具有以下优点:
1.允许合理地划分三层结构的功能,使之在逻辑上保持相对独立性,从而使整个系统的逻辑结构更为清晰,能提高系统和软件的可维护性和可扩展性。2.允许更灵活有效地选用相应的平台和硬件系统,使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层;并且这些平台和各个组成部分可以具有良好的可升级性和开放性。3.三层C/S结构中,应用的各层可以并行开发,各层也可以选择各自最适合的开发语言。使之能并行地而且是高效地进行开发,达到高的性能价格比;对每一层的处理逻辑的开发和维护也会更容易些。4.允许充分利用功能层有效地隔离开表示层与数据层,未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层,这就为严格的安全管理奠定了坚实的基础;整个系统的管理层次也更加合理和可控制。
软件体系结构范文第5篇
[关键词] 软件体系结构 软件体系结构风格 三层C/S软件体系结构
20世纪60年代中期的软件危机使得人们开始重视软件工程的研究。起初,人们把软件设计的重点放在数据结构和算法的选择上。随着软件系统规模越来越大、越来越复杂,整个系统的结构显得越来越重要。
一、软件体系结构风格分析
最初的软件体系结构是Mainframe结构——客户、数据和程序都被集中在主机上,通常只有少量的GUI界面,对远程数据库的访问比较困难。随着PC的广泛应用,该结构逐渐被淘汰。在20世纪80年代中期出现了Client/Server分布式计算结构,应用程序的处理在客户机和服务器之间分担。随着大型软件系统的开发,这种结构在系统的部署和扩展性方面暴漏出不足。随着Internet的发展,一个更灵活的体系结构“三层/多层计算”体系结构应运而生。
Garlan和Shaw将通用软件体系结构风格总结为以下几类:
1.数据流风格:批处理序列;管道/过滤器。2.调用/返回风格:主程序/子程序;面向对象风格;层次结构。3.独立构件风格:进程通讯;事件系统。4.虚拟机风格:解释器;基于规则的系统。5.仓库风格:数据库系统;超文本系统;黑板系统。
下面将介绍几种主要和经典的体系结构风格和它们的优缺点。
1.C2风格。C2体系结构风格可以概括为:通过连接件绑定在一起的按照一组规则运作的并行构件网络。图1中构件与连接件之间的连接体现了C2风格中构建系统的规则。
C2风格是最常用的一种软件体系结构风格。从C2风格的组织规则和结构图中,我们可以得出,C2风格具有以下特点:
(1)系统中的构件可实现应用需求,并能将任意复杂度的功能封装在一起;(2)所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的;(3)构件相对独立,构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行,或某些构件共享特定控制线程之类的相关性假设。
2.数据抽象和面向对象风格。目前软件界已普遍转向使用面向对象系统,抽象数据类型概念对软件系统有着重要作用。这种风格的构件是对象,或者说是抽象数据类型的实例。对象是一种被称作管理者的构件,因为它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。图2是数据抽象和面向对象风格的示意图。
面向对象的系统有许多的优点:
(1)因为对象对其他对象隐藏它的表示,所以可以改变一个对象的表示,而不影响其他的对象。(2)设计者可将一些数据存取操作的问题分解成一些交互的程序的集合。面向对象的系统也存在着某些问题:①为了使一个对象和另一个对象通过过程调用等进行交互,必须知道对象的标识。只要一个对象的标识改变了,就必须修改所有其他明确调用它的对象。②必须修改所有显式调用它的其他对象,并消除由此带来的一些副作用。
3.基于事件的隐式调用风格。基于事件的隐式调用风格的思想是构件不直接调用一个过程,而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册,当一个事件被触发,系统自动调用在这个事件中注册的所有过程,这样,一个事件的触发就导致了另一模块中的过程的调用。基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这样不能假定构件的处理顺序,甚至不知道哪些过程会被调用。隐式调用系统的主要优点有:(1)为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时,只需将它注册到系统的事件中。(2)为改进系统带来了方便。当用一个构件代替另一个构件时,不会影响到其他构件的接口。隐式调用系统的主要缺点有:①构件放弃了对系统计算的控制。一个构件触发一个事件时,不能确定其他构件是否会响应它。而且即使它知道事件注册了哪些构件的构成,它也不能保证这些过程被 调用的顺序。②数据交换的问题。有时数据可被一个事件传递,但另一些情况下,基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下,全局性能和资源管理便成了问题。③既然过程的语义必须依赖于被触发事件的上下文约束,关于正确性的推理存在问题。
4.管道/过滤器风格。在管道/过滤器风格的软件体系结构中,每个构件都有一组输入和输出,构件读输入的数据流,经过内部处理,然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成,所以在输入被完全消费之前,输出便产生了。因此,这里的构件被称为过滤器,这种风格的连接件就象是数据流传输的管道,将一个过滤器的输出传到另一过滤器的输入。
图3是管道/过滤器风格的示意图。
管道/过滤器风格的软件体系结构的优点:
(1)使得软构件具有良好的隐蔽性和高内聚、低耦合的特点;(2)支持软件重用。重要提供适合在两个过滤器之间传送的数据,任何两个过滤器都可被连接起来;(3)系统维护和性能增强简单;(4)支持并行执行。每个过滤器是作为一个单独的任务完成,因此可与其他任务并行执行。管道/过滤器风格的主要缺点:①通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据,但它们是独立的,所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。②不适合处理交互的应用。当需要增量地显示改变时,这个问题尤为严重。③因为在数据传输上没有通用的标准,每个过滤器都增加了解析和合成数据的工作,这样就导致了系统性能下降,并增加了编写过滤器的复杂性。
5.批处理风格。批处理风格的每一步处理都是独立的,并且每一步是顺序执行的,只有当前一步处理完后,后一步处理才能开始,数据传送在步与步之间作为一个整体。批处理的典型应用是经典数据处理和程序开发。
批处理风格与管道过滤器风格的共同点是把任务分解成一系列固定顺序的计算单元(组件),组件间只通过数据传递交互。区别表现在以下几个方面:批处理是全部的、高潜伏性的、输入时可随机存取、无合作性、无交互性,管道过、滤器是递增的、数据结果延迟小、输入时处理局部化、有反馈、可交互。
6.仓库风格。在仓库风格中,有两种不同的构件:中央数据结构说明当前状态,独立构件在中央数据存贮上执行,仓库与外构件间的相互作用在系统中会有大的变化。
若输入流中某类时间触发进程执行的选择,则仓库是一传统型数据库;另一方面,若中央数据结构的当前状态触发进程执行的选择,则仓库是一黑板系统。
二、三层C/S软件体系结构分析
C/S软件体系结构是20世纪90年代成熟起来的技术,它将应用一分为二,服务器(后台)负责数据管理,客户机(前台)完成与用户的交互任务。
传统的二层C/S结构存在以下几个局限:1.二层C/S结构是单一服务器且以局域网为中心的,所以难以扩展至大型企业广域网或Internet;2.软、硬件的组合及集成能力有限;3.客户机的负荷太重,难以管理大量的客户机,系统的性能容易变坏;4.数据安全性不好。因为二层C/S有这么多
缺点,三层C/S结构应运而生。三层C/S结构是将应用功能分成表示层、功能层和数据层三个部分,如下图所示。
表示层是应用的用户接口部分,它担负着用户与应用间的对话功能。表示层一般使用图形用户接口,操作简单、易学易用。功能层相当于应用的本体,它是将具体的业务处理逻辑编入程序中。功能层的程序多半是用可视化编程工具开发的。数据层就是数据库管理系统,负责管理对数据库数据的读写。数据库管理系统必须能迅速执行大量数据的更新和检索。因此,一般从功能层传送到数据层的要求大都使用SQL语言。
对二层C/S结构的局限,三层C/S的解决方案是:对这三层进行明确分割,并在逻辑上使其独立。与传统的二层结构相比,三层C/S结构具有以下优点:
1.允许合理地划分三层结构的功能,使之在逻辑上保持相对独立性,从而使整个系统的逻辑结构更为清晰,能提高系统和软件的可维护性和可扩展性。2.允许更灵活有效地选用相应的平台和硬件系统,使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层;并且这些平台和各个组成部分可以具有良好的可升级性和开放性。3.三层C/S结构中,应用的各层可以并行开发,各层也可以选择各自最适合的开发语言。使之能并行地而且是高效地进行开发,达到较高的性能价格比;对每一层的处理逻辑的开发和维护也会更容易些。4.允许充分利用功能层有效地隔离开表示层与数据层,未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层,这就为严格的安全管理奠定了坚实的基础;整个系统的管理层次也更加合理和可控制。
软件体系结构风格为大粒度的软件重用提供了可能。然而,对于应用体系结构风格来说,由于视点的不同,系统设计师有很大的选择空间。要为系统选择或设计某一个体系结构风格,必须根据特定项目的具体特点,进行分析比较后再确定。不同的结构有不同的处理能力的强项和弱点,一个系统的体系结构应该根据实际需要进行选择,以解决实际问题。
参考文献:
[1]Shaw M, Garlan D, Software Architecture Perspectives on an emerging discipline, Prentice Hall, 1996
[2]冯 冲 江 贺 冯静芳编着:软件体系结构理论与实践.人民邮电出版社
[3]Mary Shaw. Making Choices:A comparison of styles forsoftware architecture[J].IEEE Software,special issue onsoftware architecture,1995
软件体系结构范文第6篇
关键词：可信体系结构；可信环境的构造与评估；可信体系结构的评估方法；信任度；可信计算环境测评
中图分类号：TP311文献标识码：A文章编号：1009-3044(2011)21-5124-02
1 概述
近年来，软件的可信性成为软件质量的焦点，对软件可信性的分析、度量和应用支撑成为热点问题．可信软件是指正确、安全和可靠的软件．目前软件的可靠性和安全性不能令人满意．软件设计缺陷、软件系统被恶意攻击都给计算机系统的正常运行带来了不良的影响．如何在软件的开发和运行中保证软件具有高可信性，已成为软件理论和技术的重要研究方向。
可信软件体系结构的研究。
所谓计算机系统可信性是对系统所提供服务的信任度，应该具有如下属性：
可用性：系统随时可用；
可靠性：系统服务具有连续性；
防危性：不会给环境带来灾难性的后果；
保密性：不会发生非法的信息泄露；
完整性：不会发生不适当修改信息的现象；
可维护性：进行修改和进入正常态的能力， 在上述属性中有时把可用性、完整性和保密性综合考虑统称为安全性。
计算机系统可信性研究已有较长的历史但主要集中在可靠性和安全性研究方面，可靠性研究起步早成果丰富，如计算机系统软件和硬件的可靠性评价模型、提高计算机系统可靠性的容错技术和测试技术等，计算机系统的安全性研究主要表现在恶意软件的入侵防御以及信息保密等环节，对软件系统可信性评价研究主要集中在软件系统可靠性度量方面，采用的方法往往直接使用计算机硬件系统的评价模型如Jlinski和Moranda提出的基于指数失效时间模型。Goel和Okumoto 提出的非齐次泊松过程的软件可靠性模型。然而软件系统中各成分还不能像硬件那样彼此可拆分其耦合度一般比较高所以不能直接根据各个构成元素的可信性评价系统的可信度。
在可信软件技术研究中，建立完善的可信软件的形式化理论体系将为量化、推导和验证软件系统的可信性提供理论基础，建立有效的可信软件工程方法学将为构造高可信的软件系统提供高效的开发技术，而研发功能完备的高可信软件开发和运行支撑平台将为可信软件的开发、运行、以及监测和评估提供技术支持。
2 可信环境的构造与评估
2.1 可信环境的数学理论与信任传递理论
研究支持可信计算的数学模型、形式化模型，构建可信计算的理论体系；研究可信网络计算的形式化模型，形成完整性保护的理论体系；研究信任链的建立与信任的传递机理，重点研究支持信任链建立与扩展的无干扰模型。
2.2 可信计算环境构造机理及方法
研究基于可信硬件层灵活扩展信任边界的体系结构，以及可信计算平台的完整性收集、度量、验证的体系结构和网络连接与认证的体系结构；研究可信计算与虚拟技术结合的新型可信虚拟平台架构，重点探索基于可信平台模块的虚拟平台安全体系结构以及可信平台模块的虚拟化技术；研究可信的安全多方计算环境的构造方法。
2.3 可信计算环境测评
研究适用于可信计算平台的安全评估模型；研究可信平台模块协议检测方法，包括可信计算平台安全功能测试、标准符合性测试、穿透性测试等技术，对认证、授权和平台证明协议的正确性、安全性和性能的验证提供支持。
3 几种软件系统可信性评价方法
3.1 SOA软件系统可信性评价方法
所谓面向服务的软件体系结构（SOA）是一种充分利用Internet技术来满足企业对不断增长的业务运营模式需求的应用框架，该模式需要具有灵活、安全和无逢地处理异构、异质的内、外资源的能力，基于SOA代数模型，讨论如何通过建立SOA的可信范式对SOA可信属性建模。如果一个服务代数表达式中没有出现“活锁”和“死锁”，则称该服务是可信服务，所形成的代数表达式称为协同可信范式．进程代数对可信SOA的建模方法进行研究，通过对传统的进程代数扩展，提出多种服务组合运算，建立SOA的代数模型，并在此基础上研究SOA的可信设计问题，为可信SOA设计提供理论支持。
3.2 协同推荐机制来评估并选取可信软件服务
基于互联网的软件开发模式为构建面向用户日常生活的软件系统提供了极大的便利。开放的、动态的在线开发方式允许具备一定专业知识的软件开发者从网络中自行选取能够满足相应功能需求的软件服务，进行组合、协作，以完成既定的任务网构软件，就是这样一类开放软件系统。它是动态网络环境下分布式系统的一种抽象，以软件构件技术为支撑，通过自主的分布式软件动态组合以及在线演化来构筑，能够满足不同的用户需求。为了保障这类开放软件系统的可靠性，使用户获得较为满意的结果，选择可信组件是首要的步骤。而由于系统集成方和组件开发者角色和利益分离，集成方常常无法通过获得组件的开发源码进行完备测试来度量软件可靠性;并且，当系统无法满足当前用户需求而进行动态的在线演化时，也没有足够的时间可以在进行组件替换之前进行大量的性能测试。协同推荐机制提供了一种相对灵活的软件可靠性评估策略，其基本思想是:考虑到开放环境中可能缺乏完整的信息来确认(verification)软件服务的可靠性，在对目标软件进行可信评估时，可以通过收集大量历史用户的使用信息反馈来验证(validation)其质量。它适用于使用日常应用软件系统的用户，不需要软件能够绝对地按照软件工程的需求规约运行，而是只要“足够好”地满足个性化需求即可，即允许系统在满足功能需求的基础上，在可容忍的范围内达到非功能的需求。基于此思想，已有一些相关工作通过设计合理的协同推荐机制来评估并选取可信软件服务。
3.3 支持软件可信演化软件可信是指软件行为符合用户预期、满足用户的需求
传统的形式化证明、测试等软件可信保证手段均在部署前实施，需要基于对未来运行环境的某些假设。然而，随着软件应用模式的变革，软件的环境不再是封闭静态的，它有可能超出开发阶段的预期。例如，对于具备长生命周期的超大规模软件系统以及许多与物理世界紧耦合的分布式实时嵌入(distributed real-time embedded，简称DRE)系统，很难在开发阶段即对其未来运行环境做出精确预测。 环境是动态变化的，软件需要具备适应能力;对于开发阶段未预期的环境及停机维护代价高昂的系统，这种环境适应能力更需要能够在线调整。我们称以可信为目标的软件演化为可信演化，而环境适应能力的在线调整是可信演化的重要内容。期望软件完全自主地实施这种演化尚不现实，它往往需要维护人员、其他软件实体等第三方的参与，如何在软件工程层面为适应能力在线调整提供使能机制。软件的环境适应能力可细分为感知、决策及执行的能力在感知到环境发生变化后，软件做出相应决策，进而执行方法调用、参数改变或者结构调整等动作。在许多情况下，为了调整软件的适应能力，我们只需对上述过程作部分修改。
3.4 基于反馈的信任形成及决策机制
从网构软件的基本元素“软件服务”出发，借助信任评估的思想来探讨软件的可信性问题的解决途径:在协同方式的层次上，提出一种面向网构软件体系结构的信任驱动的服务选取机制ISAOT 在协同方式上支持服务的动态绑定和选取，在服务的选取上以信任为基础进行决策。ISAOT 基于一类可动态连接软件服务的智能连接子――虚服务工作，提供一个通用的基于ontology 的应用需求及信任演化策略描述规范，用于解决多样化应用需求难以描述的问题，使得连接子可理解动态变化的应用需求，并触发信任演化行为，利用开放协同环境中广泛使用的信任概念及其相关技术，采用一种基于反馈的信任形成及决策机制，并通过一个信任驱动的服务选取算法，促使连接子动态选取最为可信的服务，满足系统的动态需求;以信任为通用的驱动机制，给出了一个面向网构软件体系结构的实现框架。ISAOT 将阐述网构软件随应用需求变化自主选取服务所需的相关原理、模型和方法，展示一个清晰的可信网构软件开发模型，并详细讨论其相关支撑设施的功能与实现机制。
4 结论
总之对软件可信性的进行系统综合的度量评估，在软件设计开发过程中有效地跟踪和控制软件可信度是一个重要且亟待解决的研究课题。
参考文献：
[1] 赵会群,孙晶.一种SOA软件系统可信性评价方法研究[J].计算机学报,2010,,33(5):2-9.
[2] 赵会群,孙晶.面向服务的可信软件体系结构代数模型[J].计算机学报,2010,3(11):3-10.
[3] 文静,王怀民,应时,等.支持运行监控的可信软件体系结构设计方法[J].计算机学报,2010,33(12):1-14.
[4] 潘静,徐锋,吕建.面向可信服务选取的基于声誉的推荐者发现方法[J].软件学报,2010,21(2):1-14.
[5] 丁博,王怀民,史殿习,等.一种支持软件可信演化的构件模型[J].软件学报,2011,21(1):1-13.
[6] 王远,吕建,徐锋,等.一种面向网构软件体系结构的信任驱动服务选取机制[J].软件学报,2008,19(6):2-10.
[7] 曾晋,孙海龙,刘旭东,邓婷,等.基于服务组合的可信软件动态演化机制[J].软件学报,2010,21(2):1-16.
软件体系结构范文第7篇
【关键词】C/S、B/S、C/S结合B/S
1 C/S体系结构
随着计算机应用和计算机网络的发展，Client/Server模式（客户机/服务器模式，简称C/S模式）逐渐流行起来，用来管理各种各样的信息资源。早期的C/S模式是两层结构，第一层结构在客户机的系统上结合了业务逻辑和形式逻辑，前端的可执行代码由菜单、按钮、SQL语句、GUI窗体流和数据验证等元素组成；第二层结构通过计算机网络结合数据库（如Oracle、Sybase、Informix等数据库系统）服务器，后端的数据内容包括数据表、触发器、安全策略、引用一致性定义等元素。它将多个网络应用的用户交互界面处理程序与数据库的访问及处理分离，客户端与服务器之间通过消息传递机制来进行对话，先由客户端先将请求发送给服务器，服务器接收到请求后进行相应的，再将处理后的信息传递给客户端。C/S模式的结构图如图1所示。
C/S结构的优点主要体现在以下几个方面：
（1）C/S结构合理地将任务分配到Client（客户）端和Server（服务器）端，充分地利用两端硬件环境的优势，减少了整个软件系统的通讯开销。
（2）C/S结构具有很强的交互性，在客户端的电脑上有一套完成的应用程序，可以在子程序中自由切换，在线帮助和出错提示也有强大的功能。
（3）C/S结构采用点对点的结构，采用局域网中安全性较好的协议（如：NetBEUI协议等），即保证了数据的完整性约束，又保证了数据的安全。
（4）C/S结构到目前为止已经非常成熟，有大量的开发工具支持。
（5）C/S结构要求各种应用必须通过前羰的应用程序完成，系统安全可靠。
随着计算机网络规模的不断扩大，应用程序复杂程度不断提高，C/S模式的缺点也逐渐显露出来，这些缺点具体体现在以下几个方面：
（1）一但客户端与服务器建立的连接后，这个连接就会保持，直到客户端主动放弃时连接才被销毁，这样就会造成可建立的服务数目有限，进而使用户数目受到限制。
（2）客户端即要完成用户数据的交互及表示，又要处理应用程序与数据的交互，用户的界面必须要与应用逻辑在统一平台上，这样就会造成软件系统的可伸缩性差，对数据的管理不够灵活，软件系统的维护和升级费用高。
（3）客户端上的程序的代码重用机会少，客户端需要处理数据，如果这些逻辑需求发生变化，则每上客户端上的程序都要进行相应的修改。
（4）客户端上的应用程序庞大，软件需要特定的开发平台决定，造成了客户端软件系统跨平台不理想。
C/S结构一般建立在局域网中，再通过特定的服务器提供与英特网的连接和数据交换服务，面向固定的用户群，有较强的控制能力，高度机密的软件系统采用C/S结构比较合适。
2 B/S体系结构
随着IT产业的迅速发展，C/S体系结构暴露出了许多不足，客户端程序过于庞大、客户需求千变万化等问题尤为突出。在止其间，Internet技术不断发展，基于Web（HTTP、HTML）的和检索技术，导致了软件体系结构从C/S结构向灵活的多层分布式结构演化，这种新型的多层分布式结构就是B/S（Browser/Server，即浏览器/服务器）结构。
B/S结构由Browser（浏览器）和Server（服务器，主要是Web服务器）组成。客户机与服务器通常都不在同一个局域网中，数据库服务器与应用服务器往往在高速局域网，应用程序和数据都放在服务器上，浏览器通过下载服务器上的程序得到动态扩展。B/S结构是三层体系结构，用户首先通过浏览器（如IE、Firefox等）向网络上的服务器（如Web服务器）发出请求，服务器如果接收到了浏览器的请求，就会对这些请求进行处理（如数据的加工、结果的返回以及动态网页的生成等工作都由Web服务器完成），再将用户所需要的信息传送到浏览器上。B/S结构的运行模式，简化了客户机的工作，客户机上只需要配置少量的相关软件，更多的工作负担是由服务器来承受，这样就减轻了客户机的压力，更适合千变万化的客户需求。B/S结构图2所示：
B/S结构的优点主要体现在以下几个方面：
（1）B/S结构容易实现跨平台工作，各种平台上的用户均可通过浏览器访问及获取所需的信息。
（2）在B/S结构中，用户只需在客户机安装浏览器就可以有交互界面，系统的升级和维护工作大部分都在服务器上进行，在客户端上极少需要甚至不需要进行改动，这样大大降低了开发及维护成本。
（3）浏览器在下Web服务器交互时采用的协议主要是HTTP协议，该协议是无连接协议，浏览器只在有请求时才与Web服务器连接，当浏览器获取到所需结果后马上会结束连接，这样服务器可以同时为几千、几万甚至更大数量的并发请求服务。
（4）当应用服务器无法满足客户的需求量，可以通过增加应用服务器的数目，由多台应用服务器同时为终端客户服务，实现负载均衡，消除数据的瓶颈。
（5）因为B/S结构中，服务器接受用户请求后会将结果一次返回，B/S三层结构消耗的时间大大小于C/S二层结构消耗的时间。
B/S体系结构经过多年的应用，也暴露出许多不足的地方，具体表现在以下几个方面：
（1）B/S体系结构中虽然可以用Java、ActiveX等技术开发应用脚本，但如果是开发复杂的应用程序，这些技术相对没有C/S的一系列开发工具成熟。
（2）客户端的浏览器大多是为了进行Web浏览而设计开发的，当B/S体系结构应用于非Web系统时，许多功能实现起来比较困难。
（3）数据库的客户端实际上是Web服务器成为对数据库的唯一的客户，所有对数据库的连接及信息传递都是通过Web服务器来实现，这样Web服务器就要同时处理客户的请求以及数据库的连接，当访问量大时，Web服务器端负载过重。
（4）对于管理者来说，采用浏览器方式进行系统的维护和管理是非常不方便与不安全的。
（5）由于源代码开放性，使得商业规则很容易暴露，而商业规则对应用程序来说则是非常重要的。
3 C/S与B/S混合的体系结构
通过前面的分析，可知C/S体系结构并非一无是处，B/S体系结构也并不是十全十美，如果将这两种体系结构结合起来，就能使它们的优劣互补，形成C/S与B/S混合的软件体系结构。在这种体系结构中，一些能够满足大多数客户请求的信息采用B/S结构，这些信息用Web服务器进行处理，如数据库管理维护这些交互性强、安全性要求高、数据查询灵活、数据处理量大，管理员之类的少数人使用的功能应用采用C/S结构。C/S与B/S混合的软件体系结构图3所示。
以学生管理系统为例，教学管理系统主要分为系统后台管理模块、学籍信息管理模块、成绩管理模块、信息模块、查询模块等子系统组成。系统的硬件平台主要有：客户机、Web服务器及校园网等资源；系统的软件平台主要有：
（1）C/S结构模块部分：选用C#开发的客户端及SQL Server数据库管理工具。
（2）B/S结构模块部分：选用IE浏览器的客户机、选用IIS及开发的Web服务器及选用SQL Server数据库管理工具。工作时，客户机的浏览器向Web服务器发出请求，Web服务器将请求交给IIS服务器，IIS接受请求并调用ASP程序，ASP程序通过ADO接口与SQL Server数据库连接并进行数据库操作，数据库将处理后的数据返回给Web服务器，Web服务器通过ASP程序处理后再将操作结果以HTML文本的形式发送给客户机的浏览器。对系统进行管理时，客户机通过C/S结构中的ODBC接口向SQL服务器发送SQL语句请求，SQL数据库服务器根据SQL语句生成所需的数据结果集，并将这些结果信息传递给客户机相关的C#程序，并生成管理者所需的结果界面。
在C/S与B/S混合的软件体系结构中，信息采用了B/S结构，这样保证了客户机软件简单通用，客户机上的软件可以统一采用WWW浏览器，由于WWW浏览器有固定的标准，因此其可以在所有的平台上完成相应的工作；数据库管理采用了C/S结构，这部分只涉及到数据更新与系统维护等特定的工作，可在专用的客户机上安装相关的客户端软件，并且在客户机上可以构造非常复杂的应用程序，这样只需要维护少量的客户端，解决了完全采用C/S结构带来的客户端维护及更新工作量大等缺点，从安全角度讲，达到封装源代码，保护数据的目的。。这样便充分发挥了C/S与B/S体系结构的优势，进而弥补了二者不足，即充分考虑用户的方便与利益，又保证了系统管理者查询、维护与更新操作的简单灵活。
如果原有的系统采用的是C/S体系结构，我们也可以非常容易地升级到这种C/S与B/S混合的软件体系结构，只需要开发用于的WWW客户机界面，保留原有C/S结构的某些子系统用于管理与维护。
4 结束语
C/S与B/S混合的软件体系结构，充分发挥了两种模式各自的优点，保证了系统的可实现性和安全性，简化了客户端，即满足了不同用户的需求，又使系统便于维护。在软件开发中，只要找到C/S结构与B/S结构的契合点，就能使软件系统在具备优良的性能。
参考文献
[1]王丽平.基于C/S与B/S混合体系结构的教务管理系统设计[J]；科技情报开发与经济，2008.
[2]王伟伟.软件体系结构模式探析[J].科技传播，2011.
[3]黄沛.基于B/S体系结构以及ActiveX技术的计算机应用系统开发[J].技术与市场，2008.
[4]李云云.浅析B/S和C/S体系结构[J].科学之友，2011.
[5]宋涛.CS体系的传统二层结构与流行三层结构的比较分析[J].硅谷，2012.
作者简介
陈俊斌，男，大学本科学历，学士学位。现为广东省高级技工学校计算机科学与技术讲师。
作者单位
软件体系结构范文第8篇
关键词：软件体系结构；案例教学；实践教学平台
中图分类号：G642 文献标识码：B
建大厦必须进行设计，而建平房则不需要设计。传统观点认为需求分析是项目开发成败的一个关键，项目的失败或夭折主要是由于需求分析不充分造成的，但对如何做好需求分析却苦无良策。在软件开发的早期，软件代码量不大，对设计重要性的认识也不充分，程序员可以设计、编码一肩挑，但随着软件规模的扩大，人们在大型软件的开发面前显得力不从心，因而产生了软件体系结构理论。现代观念认为通过需求与设计之间的迭代，并根据设计建立系统原型，能够较为充分地理解需求并得到满足需求的设计。
软件体系结构的设计在中大型软件项目中更易于显示它的意义，这也是软件体系结构课程产生的原因。“软件体系结构”作为高等学校软件工程专业的一门核心课程，是根据人们的软件设计经验总结出来的理论与实践相结合的课程。“上梁不正下梁歪”，体系结构的设计是现代软件开发中最为重要的一环，它设计得是否合理直接关系到软件的成败。随着软件规模变得越大越复杂，软件开发对软件架构师提出了更高的要求。
1课程特点与面临的问题
1.1软件体系结构课程的特点
(1) 软件体系结构的设计原则、技术、方法较为抽象
软件体系结构的设计原则、技术、方法可以应用在不同的软件项目中，其目的是为了在给定的时间、经费等条件限制下设计出高质量的软件，它们位于所有具体项目之上，针对全体软件项目，因而是抽象的。
(2) 软件设计的效果体现在软件开发的后续阶段中
软件生命周期包括可行性分析、需求分析、设计、编码、测试、运行维护等多个阶段，设计对软件成败的影响往往在这个阶段反映不出来。设计阶段做出的一个决定，可能要到编码、测试甚至是后续的维护阶段才能显现它的效果。
(3) 软件体系结构的设计往往是折衷与权衡的产物
软件中的一些质量要素经常是相互冲突的，即软件的质量要素之间既有正相关，也有负相关，因此在实际的软
件系统设计过程中，必须根据具体情况对各种要素进行折衷与权衡，从而得到总体上满足用户要求的软件。怎么折衷和权衡，必须结合具体项目，根据项目的实际情况去把握。
1.2教学中面临的问题
(1) 软件体系结构的抽象理论容易使学生感到枯燥乏味
由于授课对象是大三学生，项目开发经验有限，学生很难在头脑中将软件体系结构的抽象理论和实际联系起来，因此较难对这门课产生兴趣。在接受抽象的理论时，容易产生枯燥乏味的感觉。
(2) 学生缺乏完整项目的体验
学生参与的课程设计实践一般仅限于小型项目，很少有机会参与软件开发和运行的全过程，难以体会到软件体系结构设计中关于正反经验的总结。例如，可维护性是软件的一个重要质量指标，但学生很少有机会去参与真正的软件维护，所开发的系统大多只是给任课教师大概地检查一下，一般不会交付使用，没有经受用户的真正检验，设计里的很多错误被隐藏起来了。但学生看不到错误，就不能对这些错误进行维护，也就不能体会到设计阶段工作对可维护性造成的影响。而且对于经验欠缺的多数学生来说，软件设计中的折衷与权衡难以想象，不容易理解和把握，包括各种质量属性之间以及与很多非技术因素的折衷与权衡。
如何搞好这门课的教学，是摆在教师面前的一道紧迫课题，对教学方法、手段和个人经验都提出了很高的要求。我们提出通过本课程学习要达到以下三个目标：
(1) 帮助学生了解软件架构的基本概念，初步掌握中大型软件系统构架的分析与设计方法。
(2) 使学生了解软件系统的成败不仅取决于用户的功能需求是否被满足，还和各种外部约束条件有关，如设计师的素质与经验、开发组织的目标以及政策法规限制等，从而提高软件设计的基本素养。
(3) 引导学生认识系统的性能、可用性、安全性等质量属性都是受软件构架制约的，或者说这些属性的实现影响着设计师的设计选择。
2强化案例教学，建设符合学生接受能力的案例
本课程较为抽象，要求学生有一定的软件设计经验，为了弥补学生在设计经验上的不足，我们在本课程中采用以案例教学为主的方法和手段，尽量将理论讲授和实际案例结合起来。案例选取有三方面的要求：一是要选取学生能听得懂、能理解的案例，案例本身不能过于复杂，超出学生的可接受范围；二是案例不能太简单，应稍高于学生的现有经验，这样才能提高学生的学习兴趣并帮助学生提高；三是案例要和每阶段的教学内容相匹配。经过几年的教学积累，我们以实际系统为基础，建立了多个符合学生理解和接受能力的案例，如软件学院的研究生选课系统、软件学院的图书管理系统、学生宿舍管理系统、订票系统、软件学院校友管理系统、超市进销存系统等。这些系统都是真实的，也是学生经常接触的，有很强的参照性，学生容易接受。我们还把这些系统作为课程实践的选题，提供原有设计方案和源代码，让学生使用并提出意见，找出原先设计的不足并改进，大大提高了学生实践的感知能力。
在学时分配方面也做到向案例教学倾斜，本课程总共48学时，除了8个学时的专门案例分析和8个学时的上机实践，在课堂理论教学时还穿插大量案例，案例教学占课堂授课比例的40%左右。我们还采用启发式教学手段，在课堂上留有一定时间专门就案例展开讨论，鼓励学生通过争论来比较和掌握软件构架设计方。例如，学生都实际使用过选课系统，选取该系统作为案例，学生就很乐意参与讨论并给出建议。这些手段的采用取得良好的教学效果，加深了学生对抽象的软件架构设计思想的理解。
3教学内容与教学手段
(1) 激发学习兴趣和热情
我们从课堂气氛、内容选择、语言表达三个方面入手。在营造课堂气氛方面，讲解时尽量营造探究气氛，鼓励学生参与讨论，避免学生被动地听，增强教师与学生的交流互动。在内容选择方面，选一些容易引起学生兴趣的素材。例如，在讲到架构风格时，我拿了一个自己编写的对战游戏程序给学生看，由于这种游戏学生普遍都感兴趣，因此在讲解架构风格时，学生注意力都很集中，收到了较好的教学效果。语言表达方面，在讲课时多用一些形象、有趣的事例或类比来说明或代替那些抽象、枯燥的理论陈述。例如，在谈到满足不同质量属性需要权衡时，列举了斑马为什么有黑白条纹的例子。
(2) 注意与其他课程的衔接
软件体系结构的教学内容与软件工程、软件项目管理以及软件文档写作等课程紧密相关、甚至有部分重叠，我们针对不同课程的特点进行了妥善安排，在教学内容上注意相关课程内容的相互渗透。大三上学期首先讲授软件工程，使学生对软件工程有一个初步认识，紧接着是软件文档写作的训练。大三下学期软件体系结构和软件项目管理同步讲授，要求学生运用软件体系结构的理论、技术和方法进行软件设计和评审，同时运用项目管理的知识组织项目开发，最终验证软件设计的合理性。设计和实现的题目鼓励沿用软件工程课程上所用的项目、人员组成也鼓励保持一致，使学生对某个项目能保持一个学年左右的长期接触。
(3) 建立以设计师为主的开发团队
以小组(四人为一组)为单位开展课程实验，每个人扮演不同角色。首先他们是一个设计师团队，但其中要有一人负责，这也是软件设计的一条重要原则；其次，还有项目经理、需求分析师、程序员和测试员等角色需要担当，也就是说每个人要承担多个角色。实验综合运用软件工程、软件体系结构设计、软件文档写作、软件项目管理以及其它课程的知识，来体会如何围绕软件体系结构进行开发，体会软件体系结构设计的原则和方法。
(4) 建立实践教学平台
软件体系结构的教学应使学生通过对这门课的学习，加上对其他专业知识的综合运用，能够在实际工作中应付真正的项目设计，因此有必要让学生参与一个长期(不少于一学年)的软件项目。为此我们设计多个规模较大的、完整的软件项目作为实践教学平台，这种项目包括分析、设计、实现、软件维护、软件重用、对现有软件的扩展，以及团队合作、项目管理等等。让学生长期接触某个项目，使他们可以在这个平台上观察和动手实践自己的软件设计方案，或者对现有方案进行改进，这样既有机会获得正面成功经验，也有机会得到反面失败的教训。
实验与教学进度保持匹配，使学生在实验中主动运用所学设计理论，并和传统设计方法进行对比，帮助学生迅速地把所学知识转换成实际的软件设计能力。设计过程要求采用Raional等工具进行分析和设计。
课程结束时，安排专门的时间，由每个团队向全班同学演示自己的实验成果，并由学生和教师共同对实验结果进行评价和给分，极大地调动了学生的积极性，评分过程中的议论则帮助学生进一步加深了对软件架构设计方法的理解。
团队提交的实践结果：需求说明书、体系结构设计说明书、体系结构评审报告、个人总结报告、演示Demo，要求说明每个人的角色和工作量。
评分标准：项目文档描述60%；个人总结报告20%；Demo20%。
上述评分标准以团队为基础，改变了传统的针对个人实践结果的考评模式，避免了相互抄袭。通过以团队评分为主，个人表现为辅的评价方式，达到培养学生学会与他人合作，培养团队精神的目的；通过以软件文档评分为主，以实践结果为辅的评分体系，达到学生对软件设计过程和方法的掌握。
其次，让学生参与教师的研究课题，加强实践基地建设，构建课程实训环境，鼓励学生到社会上的软件公司去实习、兼职。学院已与国内外多家软件领域的著名公司和研发基地建立了合作关系，建立了全方位、多层次的课程实践教学环境。
(5) 构建高素质的师资队伍
根据国家示范性软件学院工程型人才的培养目标，考虑软件体系结构设计课程实践性很强的突出特点，构建了三三制的师资队伍结构，即专职教师、IT公司教师和境外教师。完善了校内专任教师到软件企业一线参与实际软件项目研发和交流、软件企业的工程技术和项目管理人员到学校兼职授课的制度和机制，形成了一支了解行业需求、教学经验丰富、专兼结合、国内国外、校企联合的高素质的教师队伍。
4教学效果
我院针对软件体系结构课程教学中存在的不足，从教学方法、手段等方面提出了改进方案，融理论、案例与实践为一体，系统地阐述了软件体系结构的设计过程，体系结构设计师的主要工作和职责，辅助以实际案例向学生传授软件架构的理论、方法和技巧，并以小组为单位完成课程实验。通过本课程学习，学生可以在较短时间内掌握软件体系结构的基本知识和实践能力。
参考文献
[1] 裴小兵. 基于软件开发团队的软件工程教学实践研究[J]. 计算机教育,2008,(2):55-56.
软件体系结构范文第9篇
关键词:化学抽象机;软件体系结构信息科学
1概述软件体系结构是当前软件工程领域的一个研究热点,是大型软件开发中必须解决的核心技术。无数的论文软件工程实践证明:一个成功的软件系统往往都有一个好的软件体系结构。但是在软件设计、开发、测试、运行以及升级的各个阶段,体系结构都不可避免地会发生变化,如何把运行时适应性机制加到复杂的大规模软件系统中就成为一个重要的工程问题。然而要通过软件体系结构的研究实现这一目标,首先必须用某种方式描述动态体系结构。
目前已定义的adl超过20种,具有代表性的adl包括c2、darwin、rapide、unicon、wright、d-adl和acme等[1];国内包括xyz/adl、abc/adl、fradl和a-adl等。但这些语言大多注重软件系统结构静态特性的描述,而对其动态特性描述不足。paola inverardi和alexxander l wolf[2]首先将cham应用于描述和分析软件体系结构。他们充分利用cham擅长描述系统动态性和并行性的优点,用cham形式化方法描述和分析了软件体系结构动态操作性语义,在软件体系结构动态特性描述方面进行了有效的扩展,主张用cham模型描述软件体系结构,并例举描述了编译器的体系结构,包括顺序多阶段编译器和并行、共享存贮库的多阶段编译器。基于cham的体系结构描述,运用重写技术和结构归纳证明方法,能够对体系结构的部分行为属性进行形式化或半形式化的证明。
2化学抽象机化学抽象机cham主要用于异步并行计算模型的建模[3],通过将化学反应和抽象机概念有机结合描述系统状态变化,它将一个系统的状态看成化学溶液,溶液由分子组成,分子根据一定的反应规则相互反应又引起新的系统状态变化。溶液中不同分子可按反应规则平行地进行反应,只要各自反应的分子集不重叠。因cham在描述系统动态性、并行性方面的优良特性,所以可较好描述异步并行计算模型,尤其擅长描述如λ计算和ccs进程计算模型[4]。一个化学抽象机由一组分子m0,m1,m2…、溶液s0,s1,s2…和变换规则组成,分子是cham的基本元素,由一个常数集和操作符集派生而成的句法代数定义;溶液是由有限多个分子的集合,它反映了系统的某种状态,溶液中的分子根据变换规则进行反应。
变换规则从应用范围可分为:通用规则,即在整个cham中通用的规则;专用规则,适用于某些特定分子的规则。从反应作用可分为:加热规则,把大分子分解成小分子的规则;冷却规则,小分子合成大分子的规则。从反应涉及的分子可分为:自反应规则,只有单一分子的状态变化;互反应规则,反应过程中至少有两个分子参加反应。本质上,cham可看成一种有限状态机,因此它具有一般状态机特征,与其他以状态机为转换模型的技术相比,cham利用化学反应这一隐喻,因此在刻画系统的动态性特征方面比较自然。cham规格说明是一个基于操作的系统框架,这种框架不会把所描述的系统曲解为某种特定的计算模型。cham描述不仅可以描述系统静态特征,还能从系统操作动态性方面进行描述,通过对各单元的描述、引入的转换规则及项重写描述和分析体系结构的动态行为,因而可使软件开发人员很快地了解系统功能和行为,适用于多种层次的用户。在cham中,膜是一种封装结构,任何溶液可以被看作一个关于其它溶液的单一分子,膜内的溶液可以独立进化。膜具有半可渗透性,允许某些分子进入和离开,通过膜上的气孔,可以有选择地从膜中抽取分子,同时,气孔的可逆性允许分子被重新吸收到原始溶液中,膜表示了复合构件,实际上提供了一种刻画系统模块化的途径。
3在sa中的应用3.1描述sa。用于描述sa的cham可表示成一个三元组cham=(m,e,r),其中:3.1.1分子集m={m|m∈ms∨mi},ms={ms1,…,msn}为稳定状态分子集,处于稳定状态的分子不吸收或释放电子,mi={mi|mi∈{ms(.p)+,(p.)+ms(.p)+,(p.)+ms}∧ms∈ms}为离子状态分子集,处于离子状态的分子准备进行吸收或释放电子操作,其中p={i(e),o(e)}为分子上的操作集,i(e)为吸收电子,o(e)为释放电子,操作符“.”表示操作顺序。3.1.2电子集e={e1,…,ek},分子可根据自反应规则准备进行进行收或释放电子,当溶液中有两种互补电子,即一对释放-吸收电子时,可根据互反应规则进行反应。3.1.3规则集r=rs∪rm,rs={r|r∈{ms1=mi1,…,msj=mij}∪{ms1=ms1*,…,msj=msj*},msj∈ms∧mij∈mi,j=1,2,…}是分子自身从吸收电子到释放电子的过程或分子复制自身过程规则集,msj*表示由msj复制与msj性质、状态完全相同的分子,rm={r|r∈{m11,m21,…=m11,m21,…},mij,mij∈mi,i,j=1,2,…}是电子在分子间流动过程的规则集,rp∈rm,rq∈rm,p≠q,若{mp1,…,mpj}∩{mq1,…,mqj}=",则rp,rq可并行反应。3.2描述构件、连接件。用cham描述软件连接件或构件,可表示成一个四元组(mc,eci,eco,rc):3.2.1连接件或构件的分子集mc;3.2.2连接件或构件的前置条件,即输入电子集eci;3.2.3连接件或构件的后置断言,即输出电子集eco;3.2.4连接件或构件分子集的反应规则集rc。连接件或构件的分子集反映了连接件或构件的角色集及在角色上进行的输入输出操作,相对来说是静态的,是一种实现上的结构,属于语法层。输入电子集是使用该连接器或构件前必须具备的条件,输出电子集后映的是使用该连接件或构件后的状态。反应规则集说明了连接件或构件如何运用反应规则从而发生状态的演变,实质上是连接件或构件的动态行为,是相对动态的,属于语义层。如管道-过滤器体系结构风格的cham描述如下:定义过滤器:mc:pipe_filtereci:readereco:writerrc1:pipe_filter=pipe_filter.i(reader)rc2:pipe_filter.i(reader)=i(reader).pipe_filter,pipe_filter.o(writer)rc3:pipe_filter.o(writer)=o(writer).pipe_filter定义管道:mc:pipe_conneci:readereco:writerrc1:pipe_conn=pipe_conn.i(reader)rc2:pipe_conn.i(reader)=i(reader).pipe_conn,pipe_conn.o(writer)rc3:pipe_conn.o(writer)=o(writer).pipe_conn由过滤器和管道构造一个系统:sys_m:pipe_filter,pipe_connsys_e:reader,writersys_r1:pipe_filter.o(writer),pipe_conn.i(reader)=o(writ-er).pipe_filter,i(reader).pipe_conn
4展望目前基于构件的软件工程正逐渐成为软件开发的新趋势,但是也给基于构件的软件系统测试带来了新的问题,而cham不仅可用于描述动态软件体系结构,还可用于测试体系结构,因为cham这种对系统状态变化的描述特别适合于测试系统的行为和功能,bertolino[5]等人提出从软件体系结构描述中导出实现层的测试用例,以指导构件系统的集成测试的思想,随着对cham的深入研究,必将有新的应用被提出。
参考文献
[1]medvidovic n,taylor r n,a classification andcomparison framework for software architecturedescription languages[j].ieee trans.on softwareengi.,2000,26(1):70-93.
[2]inverardi p,wolf a l.formal specification andanalysis of software architectures using thechemical abstract machine model[j].ieee trans.on software engi.,1995,21(4):373-386.
[3]berry g.,boudol g.the chemical abstract ma-chine[j].theoretical computer science,1992,(96):217-248.
[4]berry g,boudol g.,the chemical abstract ma-chine[a].in conference record of the seventeenthannual acm synmposium on principles of pro-gramming language[c].1990.
软件体系结构范文第10篇
关键词:软件体系结构;多视图;模型;UML
1 引言
在描述软件体系结构时,不仅要考虑系统功能方面,实际上系统的物理分布、过程通讯等问题也要加以考虑。UML提供了可视化的图形表示方法及语义化的元模型描述规范,提供了静态和动态两种建模机制。利用UML的半形式化特性及嵌入的扩充机制,可以从多个视图描述软件体系结构。本文利用UML的“4+1”视图模型,分别从概念、过程、构件、物理、场景等五个不同的视角来描述钢材库管理系统的软件体系结构,5个视角结合在一起反映钢材库系统的体系结构的全部内容。
2 “4+1”视图的体系结构模型
对一个软件体系结构的描述可以从不同的视角来描述。“4+1”视图模型中的5个体系结构视角反映了系统构造的主要方面,能够全面系统地描述一个软件系统的体系结构。
“4+1”模型从逻辑、开发、过程、物理和场景5个不同的视角来描述软件体系结构的全部内容,如图1所示。对比软件体系结构各个视角与软件开发的各阶段,逻辑视角、开发视角、过程视角和物理视角分别对应于软件开发的需求分析、总体设计、详细设计和实现阶段。
“4+1”视图模型反映了系统构造的几个方面,体现体系结构构造的抽象特征,体现系统的体系结构风格;反映了基于构件的软件开发方法的一些特征;对于“体系结构模型的实现”,“如何构造这些视图以及视图之间的映射关系”给予指导。
逻辑视角:描述系统的功能需求及它们之间的相互关系;按照应用领域的概念描述体系结构。这些概念与实现它们的代码有关系,但并不总有直接映射的关系。体系结构在该视图中设计系统的功能特性。例如,概念视图的一个普通目标是组织体系结构以便能够方便的增加、删除及修改系统的功能。这对于系统演化非常重要,同时能支持体系结构的重用。
过程视角:过程角度侧重于系统的运行性;从系统的行为出发,考察各个构件之间的协作/交互/通讯关系,反映系统的行为结构。该视图基于系统的需求场景,同时遵循框架视图的制约,是系统核心结构之一。
开发视角:开发角度负责软件模块的组织和管理;该视图以构件为着眼点,是系统开发的核心结构之一,是框架视图的设计模式,是对框架视图的细化。
物理视角:物理角度解决系统的拓扑结构、系统安装及通信等问题;描述系统的软件与硬件之间的映射关系并反映其分布特性,展示软件在生命周期的不同阶段中所必须的物理环境或硬件配置以及分布状况。
场景:场景则对应于用户需求和系统功能实例的抽象,设计者通过分析如何满足每个场景所要求的约束来分析软件的体系结构。场景是整个体系结构设计的依据,是以上六个视图构造的着眼点。它对应于重要的用户需求和系统功能实例的抽象,设计者通过分析“如何满足每个场景所要求的约束”来设计软件的体系结构。
综上所述,概念视图定义系统的目标;构件视图、过程视图提供详细的解决方法;物理视图解决系统的拓扑结构、系统安装及通信等问题;场景反映完成上述任务的组织结构。概念视图是高层体系结构;构件视图、过程视图构成体系结构的核心,是系统开发的关键结构,为低层体系结构;物理视图则为辅助体系结构。
3 基于UML的钢材库管理系统体系结构“4+1”
视图描述
3.1 “4+1”视图体系结构的构造
“4+1”视图体系结构模型的构造涉及多种角色,并且分别完成不同的任务:
(1)用户与系统分析师通过需求工程获得待开发系统的功能和非功能需求,将其转化为功能场景与质量场景,即“4+1”视图模型中的场景。
(2)体系结构设计师完成如下任务:
①将功能场景转化为概念视图,并征求用户的确认,得到待解决问题的定义;
②根据已有的体系结构知识,选择和确定构件视图、过程视图;
③在得到核心体系结构模型后,开发物理视图;
(3)构件工程师依据构件视图、过程视图、数据视图开发相应的构件;
(4)集成工程师依据构件视图集成部署构件;
(5)组织管理者按照场景分配开发任务。
对于体系结构的构造而言,只考虑体系结构设计师相应的工作,即如何得到上述四个视图。下面具体讨论各个视图的构造与基于UML的描述方法。
3.2 场景描述
场景可以采用UML中的用例图来描述。用例图包含的主要实体有:用例、参与者和系统边界。用例通过系统与一个或多个参与者之间的一系列消息来描述系统中的交互作用,用于表示系统的一项外部功能需求,即从用户角度分析所得的需求;参与者用于描述与系统功能有关的外部实体,可以是用户,也可以是外部系统;系统边界用于界定系统功能范围。
钢材库管理系统的软件体系结构图中,共涉及九个用例,分别对应九个基本的系统功能。外部角色有四个,分别是:客户、业务人员、供应商、系统管理员。在场景描述中,分别从四个外部角色的角度对系统提出功能需求。钢材库管理系统体系结构的场景描述如图2所示。
3.3 概念视图描述
在概念视图中,组件是角色和用例,连接件是角色和用例之间的关系以及多个用例之间的关系。在构造概念视图时,着眼点是功能场景,考虑系统的功能分解,但不考虑其实现。具体来说,将需求工程得到的功能场景抽取为视图中的一个功能组件;进而考虑这些功能组件之间的关系。 概念视图可以采用UML用例图来表示,从所有参与者的角度出发,通过用例来描述他们对系统概念的不同理解,每一个用例名相当于一个概念功能的名称。
在钢材库管理系统体系结构的概念视图中,给出了该体系结构的系统功能需求的抽象描述,即系统提供给最终用户的服务。钢材库管理系统主要完成对供应商的开户,对货物的质检、入库、出库等功能。钢材库管理系统体系结构中的概念视图如图3所示。
3.4 过程视图描述
过程视图主要通过对过程动态模型建模来实现,用UML中的活动图来描述。过程视图帮助设计人员更细致的分析概念视图和场景中的用例,分析
视图和场景中用例工作流之间的交互。大型软件系统非常复杂,很多过程可能是并行的,活动图支持并行的行为。
钢材库管理系统体系结构中的过程视图如图4所示,包括权限检查、开户、质检、入库、出库、查询、异常处理等组件。
3.5 构件视图描述
构件视图用于描述软件开发中程序模块的静态组织结构,由程序库或子系统组成,用UML中的构件图来表示。它考虑软件内部的特性,描述软件开发以及软件的组织,显示系统结构的划分。在构件视图中,组件就是程序模块,程序模块之间的关系是连接件。
在钢材库管理系统中,包含这样一些组件:完成质检功能的质检组件、对入库货物进行信息录入与出单的入库组件、负责出库工作的出库组件及它们所对应的数据库组件。这些组件及其相互关系如图5所示。
3.6 物理视图描述
物理视图描述如何把软件映射到硬件上,它通常考虑系统性能、规模和可扩展性等,主要通过UML中的配置图加以实现。配置图定义系统中软硬件的逻辑或物理的拓扑结构,它可以显示计算节点的拓扑结构和通信路径、节点上运行的软件组件、组件包含的逻辑单元等。
钢材库管理系统是一个采用C/S体系结构风格的系统,其体系结构中的物理视图如图6所示。客户端和服务器端是节点,两个节点之间通过TCP/IP协议进行连接。在客户端,开户单、入库单和出库单填写界面作为相应的构件。
4 结论
针对基于UML的“4+1”视图体系结构模型描述的特点,分别阐述各视图的定义及其基于UML的描述方法,最后将该模型应用到钢材库管理系统的体系结构描述中,证明了将该模型用于面向对象的软件开发方法中描述软件体系结构的可行性及易用性。
参考文献
[1]J.Wiley. The Art of Software Architecture:Design[J]. Methods and Techniques.2003.
[2]M.Bernardo, P.Ciancarini, L.Donatiello. On the formalization of architectural types with Process algebras.In D.S.Rosenblum, editor,Proc.of the 8th ACM Int.Symp.on the Foundations of software Engineering (FSE-8):14~148.ACM press, November 2000.
[3]马重明,张学旺,范时平.基于UML的软件体系结构开发方法[J].计算机工程与应用.2006(4).