软件体系结构
软件体系结构范文第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.
软件体系结构范文第2篇
软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组合连接起来。这一定义注重区分处理构件、数据构件和连接构件，这一方法在其他的定义和方法中基本上得到保持。
1997年，Bass，Ctements和Kazman在《使用软件体系结构》一书中给出如下的定义：一个程序或计算机系统的软件体系结构包括一个或一组软件构件、软件构件的外部的可见特性及其相互关系。其中，"软件外部的可见特性
（来源：文章屋网 ）
软件体系结构范文第3篇
【关键词】软件体系结构 构件模型 构件语言 SACM SAJ
【中图分类号】G642 【文献标识码】A 【文章编号】1674-4810（2013）14-0081-01
在软件开发中，如何提高软件质量是人们的普遍追求和共同愿望。而提高质量的关键问题就是构件技术和软件体系结构技术。但是，目前在这两项技术开发中面临着多方面的挑战，本文拟对这些问题提出相应的解决方案。
一 基于软件体系结构的构件模型SACM
第一，构件。SACM构件是能提供相对独立服务的计算单元，具有规范的接口和显示的上下文依赖，能够被第三方组合。就其组成来看，主要包括端口和服务两个部分，每个端口代表一个交互点，至多有一个请求服务接口和一个提供服务接口。对于构件来说，其服务实现部分由方法体构成，这就降低了构件之间的耦合度，能够提高构件的复用程度。
第二，构件之间的关系。在SACM中，存在着多种构件，这些构架之间相互联系，形成了多种多样的不同的关系，主要有部分-整体关系、泛化关系、连接关系、协作关系。
第三，连接子的引入及其作用。为了更容易地实现映射、对软件系统属性进行分析、验证和跟踪，提高构件的复用程度，提高软件系统结构的动态配置、加强低软件的维护，在SACM构件中有必要引入连接子。就其作用来看，连接子主要发挥通信、转换、辅助交换、协调控制的作用，对整个软件系统的运行有着积极的意义。
第四，基于连接子构件组合方法。在SACM构件当中，构件组合方法主要有两种：基于被动的和基于主动的连接子构件组合方法，不同的方式有各自的优势，需要根据具体情况选用。
二 面向构件语言SAJ
第一，SAJ语言设计的目的。该语言设计的目的主要包括以下几个方面：能够更好地支持面向构件软件开发、实现从体系结构设计模型到地层代码的映射。
第二，SAJ语言支持面向构件软件开发。在进行软件开发的过程中，为了能够更好地对面向构件的软件进行支持，面向构件语言应能够支持构件的封装、复用和组合，并支持构件的设计与开发。具体来说，是从以下五个方面来支持面向构件软件开发的：构件的封装性、构件组合、面向构件设计原则、设计模式、连接子复用。
第三，SAJ语言的实现。使用Polyglot框架来实现SAJ语言的编译器，并将编写的源代码翻译成Java代码，每个端口自动产生一个字段，保存所使用的连接子。由连接子协调构件之间的通信，通过消息截取和消息过滤，有利于解决构件之间不相容的问题。有利于实现日志、数据加密传输等服务，并能够实现各种体系结构风格，具有良好的运用空间。
三 SAJ语言的语法、语义和类型系统
第一，SAJ语言的简介。对于SAJ语言来说，它的核心是基于RelJ，它是在RelJ的基础上，添加了构件、端口、连接子、角色等软件体系结构。
第二，SAJ语言的类型系统。类型是程序设计中项的集合，它们具有共同的性质。对于类型系统，从本质上来说，它是一个类型推导规则的集合，在程序设计中具有重要的作用：检查类型错误、支持语言抽象、优化程序，并支持语言的安全性。
四 丰富构件接口信息
第一，显示相应的服务关系。显示描述请求服务和提供服务之间的关系，构件要想为外界服务，就需要从外界得到相应的请求服务。对于现有构件模型来说，请求服务和提供服务之间的关系是固定的。但是在可复用构件的软件开发中，请求服务和提供服务之间不存在严格的依赖关系，往往存在着一些问题与不足，影响正常的服务。因此，有必要显示请求服务与提供服务之间的关系。此外，从构件复用粒度的角度来说，显示它们之间的服务也是十分必要的。同时，显示它们之间的关系，有利于对构件质量进行精确度量、调整与改进，更能灵活适应不同的环境，提高服务质量，更好地满足软件开发的实际需要。
第二，描述服务的参数值。在进行软件开发时，服务的参数值往往会对构件行为产生一定的影响。并且构件开发人员对这个也非常清楚。所以，在接口中增加描述服务的参数值是现实的、必要的。在构件接口中，有提供服务和请求服务，对于它们的参数值描述略有不同。一般是在行为协议中描述参数值，并在构件组合中得到具体应用。
五 结束语
总之，构件模型和面向构件语言有利于解决当前构件技术和软件体系结构技术所面临的问题。文中所提出的构件模型SACM和构件语言SAJ，能够有力地促进构件技术的发展。在今后的实际工作中，仍然有对该相关问题进行进一步深入研究的必要。
参考文献
[1]岳洋.SMC/ADL：一种层级式构件系统的体系结构描述语言[J].计算机科学，2012（7）
软件体系结构范文第4篇
关键词：组件；连接器；软件体系结构；抽象代数；结构函数
中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2013）20-4743-03
软件体系结构为软件系统提供一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成[1]。软件体系结构的描述是进行软件体系结构研究的基础，一种形式化、规范化的体系结构描述语言对于软件体系结构的设计和理解都有重要作用。
软件体系结构描述语言（ADL）能形式化地描述基于组件和连接器的软件体系结构，并给出了软件体系结构的一般框架，但未对框架中的组件、连接器连接成为软件体系结构过程进行抽象描述。文献[2]借助抽象代数的思维方式，在给出组件、连接器和软件体系结构定义的同时，用数学方法描述了他们的属性和行为，并总结出了基于软件体系结构的抽象模型。
本文在文献[2]的基础上，进一步用数学方法探讨软件体系结构，核心是用组件的运算描述组件的连接，并在此基础上给出了软件体系结构抽象模型的函数理论研究，最后给出了软件体系结构抽象模型函数表示的一般应用。
1 组件
为了更好地理解组件这一抽象概念，该文将引入文献[2]对组件相关概念的定义和定理。
定义1[2] 组件是一个数据单元或一个计算单元， 它由组件接口和组件实现模块组成。 组件接口是组件与外部接触点的集合， 即[]， 而每一个接触点[Porti]是一个八元组[]。
在定义1 中组件接口给出了组件的形式化描述， 它定义了一类组件的模式[2]。 为了方便， 一般用元组元素（ ID ） 表示组件ID 中的一类元素的集合。 如[Publ（C）]表示组件C 中各接口点[Port]中[Publ]元素的集合[2]。
定义2 设[A]和[B]是论域[U]中两个组件，如果[A]的某一接口[i]和[B]的某一接口[j]满足：[ExteAi∈Publ（B）]且[ExteBj∈Publ（A）]，则[B]可以通过连接器接入到[A]中，组成一个新组件[C]，称作组件B嵌入到组件[A]。记为：[C=A+B]。
易知组件C满足以下性质：
1）[Dom（C）=Dom（A）?Dom（B）]
2） [Publ（C）=Publ（A）?Publ（B）]
3） [Extn（C）=Extn（A）?Extn（B）]
4）[Priv（C）=Priv（A）?Priv（B）]
5） [Beha（C）?Beha（A）∧Beha（B）]
6） [Msgs（C）=Msgs（A）?Msgs（B）]
7）[Cons（C）?Cons（A）∧Cons（B）]
8） [Non-Func（C）?Non-Func（A）∧][Non-Func（B）]
其中，组件[B]可以通过激发（[]）、使用（[?]）等运算来嵌入到组件[A]中。
定理1 设[C1]、[C2]、[C3]是论域[U]的3个组件，它们对运算[+]满足结合律，即：
[（C1+C2）+C3=C1+（C2+C3）]
该定理显然成立，其证明过程与文献[2]中的激发运算（[]）满足结合律的证明类似。
同理，可以定义嵌入组件的逆运算。
定义3 设[A]、[B]是论域[U]中两个组件，且[B?A]，如果[B]从[A]中撤离，[A]成为一个新的组件[C]，且[C]满足以下条件，则称[B]为[A]的脱组件。记为：[C=A-B]。
类似于嵌入组件运算，脱组件运算也有相关性质，以及满足结合律，此处不再赘述。
定义4 设[C]为论域[U]中的组件，且[?x∈U]都有[x?C]，则称[C]为元组件，记作[Ce]。
定义5 设[A]为论域[U]中的组件，[A]中含有元组件的个数称为[A]组件的基，记作：[A]。元组件的基为[1]，即[Ce=1]
定理2设[A]、[B]是论域[U]中两个组件，则[A?B=A+B-A?B]。该定理也称为组件的容斥原理。
证明：此定理跟集合运算中的包含排斥原理证明相同，显然成立，在此省略。
定义6：设[C]为论域[U]中的任一组件，若存在组件[C′][（C′∈U）]在某一方向上、某一形态上或者某一意义上对称，则称[C′]为[C]的对称组件，记作[C]。
如图2，在结构模型的结构中，组件1与组件2在[X]轴方向上对称，它们互为对称组件。
显然，对称组件具有如下性质：
1） 等价性。即对称组件在功能上或者结构上相似或者相同，两者可以等同替换。
2） 冗余性。对于一个结构而言，出现对称组件，意味着结构重复，可以利用等同转化方法将结构简化。
3） 自反性，即[C=C]。
定义7 设[A]、[B]、[C]均为论域[U]中的组件，满足[C={x|x∈（A?B）-（A?B）}]，那么组件[C]称为[A]和[B]的对称差。记作：[C=A?B]。
组件的对称差运算，实质上是取两个组件相异的元组件。在体系结构设计时，抽取相异的组件来进行分析，能起到简化结构等重要作用。
2 连接器
在软件体系结构中，连接器是组件间连接和交互的纽带，赋予了组件间交互规则等，使得组件间的连接和各种交互活动得以顺利且规范地进行。
定义8[2] 连接器是组件运算的实现。 它是一个六元组[]。 其中：
[ID]、[Beha]、[Msgs]、[Cons]、[Non-Func]跟组件的接口属性定义相仿。而[Role]为连接器与组件交互点的集合， 每个[Role=]组成。
3 软件体系结构
软件体系结构是一个系统的规划和抽象设计框架，它包括所建立系统中的各元素（组件和连接器）的描述、元素间的交互、指导装配的范例的约束[4]。
定义9[2] 设论域为U ，
1） 组件是一个软件体系结构；
2） 连接器是一个软件体系结构；
3） 组件经有限次连接（运算） 后是软件体系结构。
软件体系结构记为[A=]， 简称结构[2]。 其中：[C]表示组成结构组件的集合，[O]表示组件运算的集合[2]。
一般地，[O]包含嵌入组件和脱组件两种运算，其中嵌入组件运算又进一步分为激发[]、使用[?]等运算。
由定义8可得软件体系结构具有封闭性、层次性和可扩充性 [2]。
软件体系结构函数模型
由软件体系结构的递归定义及软件体系结构的封闭性性质可知，如果软件体系结构满足[1NF][2]，即任一组件都至少与另一组件依赖，则软件体系结构是组件的函数。
1） Tuple模型
软件体系结构可以抽象为组件、连接器，以及它们间的连接等交互活动。其中，组件跟组件通过连接器相连，组成一个三元组 [（component，connector，component）]，而软件体系结构就是由若干三元组的有机结合而成。所以，软件体系结构是三元组的函数。这就叫做软件体系结构函数的元组模型，简称Tuple模型。
[A=C1+C2+…+Cn] [=F（Ci，Conj，Ck）].[=Ci1Ci2?CinConj1Conj2?ConjnCk1Ck2?Ckn]
其中，[0≤i，k≤C]，[0≤j≤Con]，[n=min（i，j，k）]
矩阵的每一行称为一个元组，每个元组表示组件与组件的连接。组件与组件间连接（运算）行为的性质取决于连接器[Connector]中角色[Role]的活动[Action]。
2） 元组件模型
在设计软件体系结构中，有时我们只关心的是嵌入组件或者脱组件操作，而很少理会操作细节。此时，我们可以把软件体系结构看作是元组件（[C]）或者结构间运算而成的有机体。也就是说，软件体系结构（[A]）为元组件（[C]）的函数。表示为：
[A=F（x）] 其中，[x∈C]
组件间的连接可以是激发（[]）和使用（[?]）等混合运算，函数[F（x）]的值就是软件体系结构。结构函数的图形表示如下：
性质1 结构函数[A=F（x）]是增函数。
推论1 结构函数可以嵌套为更加复杂的结构函数。例如：[A=F（G（x））]，如果[x]为元组件，那么组件[G（x）]为结构[A]的最底层，组件[F（G（x））]为结构[A]的最高层。
4 结构函数的一般应用
定义10 如果软件体系结构[A=F（x）]中，[x∈C]具有对称性（即[?x∈C]，[?x′∈C]，使得[x=x′]），且[?x∈C]，都有[F（x）=F（x）]，则称[F（C）]为结构对称函数。相应的软件体系结构[A]称作对称结构。
根据对称组件的冗余性质可知，对称结构不是最简结构，在一定程度上结构冗余，不利于软件体系结构的设计和理解，从而我们必须将结构最简化。
下面给出对称结构最简化的一般方法：
1）对组件进行标记操作。原组件[C]（[C∈A]）标记为[Ci>0]；相应的对称组件[C?]标记为[Ci?
2） 脱组件操作。从最低层开始，对[A]中所有小于0的组件进行脱组件操作：[A′=A-Ci]。直到最高层为止。
其中，[Ci∈A，Ci
如图3，对一个软件体系结构进行脱组件之后，得到一个简化的软件体系结构。
借助软件体系结构函数，对于功能模型的结构可以用功能上的对称来进一步简化结构；对于动态模型、过程模型的结构，可以用语义、形态上的对称性来简化结构。从而取得更加简洁的结构，由于篇幅有限，该文不作详细介绍。
结构函数的最简化，实质上是软件体系结构更高层次上的抽象，它把结构中具有系统属性和动作看成一个黑盒，而软件体系结构就是有一个个的黑盒组成，大大方便软件结构设计和理解。
5 小结
本文引入了代数理论和函数思想来描述软件体系结构模型。继承了文献[2]中组件运算表示组件连接的观点，进一步完善了软件体系结构抽象模型的基本概念。同时，提出了软件体系结构函数模型这一概念，并进行简单应用，为进一步应用函数思想来研究软件体系结构相关问题奠定基础。
代数理论和函数思想具有强大的理论体系，必将是描述和研究多样的软件体系结构的有力工具。在软件体系结构设计中，如果能建立结构函数模型，并采用核函数等进行非线性变换，演算出最优的软件体系结构，这方面的研究十分必要，相关理论有待发展和完善。
参考文献：
[1] 张友生.软件体系结构[M].北京：清华大学出版社，2006.
软件体系结构范文第5篇
关键词:软件体系结构;多视图;模型;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.
