动态软件体系结构描述方法
- 格式:doc
- 大小:278.50 KB
- 文档页数:5
UML的定义和组成详细介绍⽬录1、UML1.1概述UML(Unified Modeling Language 统⼀建模语⾔) 是为软件系统的制品进⾏描述(specifying)、可视化(visualizing)、构造(constructing)、⽂档化(documenting)的⼀种语⾔。
UML规范⽤来描述建模的概念有: 类、对象、关联、职责、⾏为、接⼝、⽤例、包、顺序、协作,以及状态。
1.2 UML是⼀种建模语⾔建模⽅法 = 建模语⾔ + 建模过程。
建模语⾔定义了⽤于表⽰设计的符号(通常是图形符号);建模过程描述进⾏设计所需要遵循的步骤。
标准建模语⾔UML是⼀种建模语⾔,⽽不是⼀种⽅法,它统⼀了⾯向对象建模的基本概念、术语及其图形符号,为⼈们建⽴了便于交流的共同语⾔。
建模能⼒:建模⽅法 + 领域知识 + 实践1.3 UML语⾔包含三⽅⾯1. UML基本图素:它是构成UML模型图的基本元素。
例如类、对象、包、接⼝、组件等。
2. UML模型图:它由UML基本图素按照UML建模规则构成。
例如⽤例图、类图、对象图、…等。
3. UML建模规则:UML模型图必须按特定的规则有机地组合⽽成,从⽽构成⼀个有机的、完整的UML模型图(well-formed UMLdiagram)。
2、UML⽀持软件体系结构建模为了表达不同的软件开发相关⼈员在软件开发周期的不同时期看待软件产品的不同侧重⾯, 需要对模型进⾏分层。
UML根据软件产品的体系结构(architecture)对软件进⾏分层。
软件的体系结构分解为五个不同的侧⾯,称为4+1视图(view)。
分别是:⽤例视图(Use case view,Scenarios)—场景视⾓逻辑视图(Logical view) — 逻辑视⾓进程(过程)视图(Process view) — 过程视⾓实现(开发)视图(Implementation view) —开发视⾓部署(物理、配置)视图(Deployment view) —物理视⾓每个视图分别关注软件开发的某⼀侧⾯视图由⼀种或多种模型图(diagram)构成模型图描述了构成相应视图的基本模型元素(element)及它们之间的相互关系。
软件体系结构◇软件体系结构概论◇软件体系结构建模◇软件体系结构风格◇软件体系结构描述◇动态软件体系结构◇Web服务体系结构◇基于体系结构的软件开发◇软件体系结构的分析与测试◇软件体系结构评估◇软件产品线体系结构软件危机的表现◎软件成本日益增长◎开发进度难以控制◎软件质量差◎软件维护困难软件危机的原因◎用户需求不明确◎缺乏正确的理论指导◎软件规模越来越大◎软件复杂度越来越高◎构件的定义构件是指语义完整、语法正确和有可重用价值的单位软件,是软件重用过程中可以明确辨识的系统;结构上,它是语义描述、通讯接口和实现代码的复合体。
构件模型的三个主要流派OMG(Object Management Group,对象管理集团)的CORBA(Common Object Request Broker Architecture,通用对象请求代理结构)Sun的EJB(Enterprise Java Bean)Microsoft的DCOM(Distributed Component Object Model,分布式构件对象模型)。
构件获取1.从现有构件中获得符合要求的构件,直接使用或作适应性修改,得到可重用的构件;2. 通过遗留工程,将具有潜在重用价值的构件提取出来,得到可重用的构件;3. 从市场上购买现成的商业构件,即COTS(Commercial Off-The-Shell)构件;4. 开发新的符合要求的构件。
构件管理◎构件描述◎构件分类与组织◎人员及权限管理构件描述构件模型是对构件本质的抽象描述,主要是为构件的制作与构件的重用提供依据;构件分类与组织◇关键字分类法◇刻面分类法◇超文本组织方法人员及权限管理一般来讲,构件库系统可包括五类用户,即注册用户、公共用户、构件提交者、一般系统管理员和超级系统管理员。
构件重用◎检索与提取构件◎理解与评价构件◎修改构件◎构件组装构件重用理解与评价构件◇构件的功能与行为◇相关的领域知识◇可适应性约束条件与例外情形◇可以预见的修改部分及修改方法构件组装◇基于功能的组装技术◇基于数据的组装技术◇面向对象的组装技术软件体系结构的定义软件体系结构为软件系统提供了一个结构、行为和属性的高级抽象,由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。
软件体系结构软件体系结构是指软件系统中各个组件之间的关系和结构的抽象描述。
它是构建软件系统的基础,对软件系统的设计和开发起着重要的指导作用。
本文将从软件体系结构的定义、目标和应用领域等方面对其进行详细的介绍。
一、软件体系结构的定义软件体系结构是指软件系统中各个组件之间的关系和结构的抽象描述,它包括软件系统的静态结构和动态行为。
静态结构是指软件系统中组件的组织方式和相互之间的关系,动态行为是指软件系统中组件的交互方式和相互之间的通信方式。
二、软件体系结构的目标软件体系结构的目标是实现软件系统的可重用性、可维护性、可扩展性和可伸缩性。
可重用性是指软件系统中的组件能够被多次使用,可维护性是指软件系统中的组件能够被轻松地修改和维护,可扩展性是指软件系统能够根据需求进行功能的扩展,可伸缩性是指软件系统能够根据需求进行性能的扩展。
三、软件体系结构的应用领域软件体系结构广泛应用于各个领域的软件系统开发,特别是大型跨平台和分布式系统的开发。
在金融领域,软件体系结构被应用于交易系统和风险管理系统的开发;在电子商务领域,软件体系结构被应用于在线购物系统和支付系统的开发;在物流领域,软件体系结构被应用于供应链管理系统和运输管理系统的开发。
四、软件体系结构的基本原则软件体系结构的设计应遵循以下基本原则:1. 模块化:将软件系统分为独立的模块,每个模块只负责特定的功能,通过接口进行通信和交互。
2. 松耦合:各个模块之间的依赖应尽量降低,避免模块之间的紧密耦合,以提高系统的灵活性和可维护性。
3. 高内聚:模块内部的各个元素之间应紧密关联,功能相关的元素应放在同一个模块中,以提高系统的内聚性。
4. 分层:将软件系统分为多个层次,每个层次负责不同的功能,上层层次通过接口调用下层层次的功能。
5. 可伸缩性:系统的设计应考虑未来的扩展需求,能够根据需求进行功能和性能的扩展。
六、软件体系结构的设计方法软件体系结构的设计方法有很多种,常用的有面向对象的体系结构设计方法、服务导向的体系结构设计方法和领域驱动设计方法。
软件体系结构试题库(软件工程)一、判断题4、软件体系结构充当一个理解系统构件和它们之间关系的框架,特别是那些始终跨越时间和实现的属性。
答案:√6、体系的核心模型由5种元素组成:构建、连接体、配置、端口和角色()答案:√7、软件体系结构的核心由5种元素组成:构件、连接件、配置端口和角色。
其中,构件、连接件和配置是最基本的元素()答案:√8、开发视图主要支持系统的功能需求,即系统提供给最终用户的服务()答案:某9、构件、连接件以及配置是体系结构的核心模型最基本的元素()答案:√10、HMB风格不支持系统系统自顶向下的层次化分解,因为它的构件比较简单。
答案:某11、正交软件体系结构由组织层和线索的构件构成。
答案:√12、基于事件的隐式调用风格的思想是构件不直接调用一个过程,而是触发或广播一个或多个事件。
答案:√13、线索是子系统的特例,它由完成不同层次功能的构建组成,每一条线索完成整个系统中相对独立的一部分功能。
()答案:√15、相交关系R是一个等价关系。
答案:√16、在软件设计中占据着主导地位的软件体系结构描述方法是图形表达工具。
答案:√17、Rapide是一种可执行的ADL,其目的在于通过定义并模拟基于事件的行为对分布式同步系统建模。
答案:某18、体系结构设计是整个软件生命周期中关键的一环,一般在需求分析之后,软件设计之前进行。
答案:√19、基于软构件的系统描述语言是较好的一种以构件为单位的软件系统描述语言。
答案:√20、需求语言与ADL的区别在于后者描述的是问题空间,而前者则扎根于解空间中。
答案:某21、基于构件的动态系统结构模型分为三层,风别是应用层、中间层、和体系结构层。
答案:√22、ADL提供了一种形式化机制来描述软件体系结构,大多数ADL不进描述系统的静态结构,也支持对体系结构动态性的描述()答案:某23、基于构件的动态系统结构模型分为应用层,中间层和体系结构层。
答案:√24、2000年世界计算机大会提出,软件体系结构中最为重要的三个研究方向是:体系结构风格,静态体系结构和动态体系结构。
2011-5-28大作业参考资料:1.试就一种常用软件体系结构说明其概念、结构模型与应用领域,并结合该体系结构的应用,用一种ADL来描述该体系结构。
2.结合某一应用,编写一个XML文档,并将其与一个XML Scheme对应起来,最后用一种方法来解析该XML文件。
3.登录Oracle网站,学习Java FX 的使用方法,编写一个小型Java FX应用。
(选作)4.通过网络学习Flex,用Flex编写一个应用程序。
(选作)5.给出三种常用的Java 设计模式,并用Java语言给出其实现的实例。
电子稿文件名格式:学号+姓名+软件体系结构期末作业.DOC软件体系结构描述语言(ADL)要点浏览本章将对学术界常见的体系结构描述语言进行介绍.由于研究流派不同,各种ADL的设计和能力也不尽相同.本章选取五种比较典型的ADL作为代表,希望能让读者了解主流ADL的基本能力,主要功能和应用范围.为了让读者对各种ADL 有一个更为清晰的认识,本章最后还对这五种典型的ADL进行了比较全面的比较. 通过本章的学习,您将能:了解主流ADL的语法和语义掌握主流ADL的特点区分主流ADL的不同总体介绍任何一个软件系统都有结构,在系统开发过程中的分析设计阶段,通过考察系统的结构,可以对系统的开发和实现提供良好的基础.系统的结构往往体现为系统的各个部分之间的配置.对于描述软件系统配置的表示法的研究由来已久.早在1975年,DeRemer和Kron就设计了模块互连语言(Module Interconnection Language,MIL)用于描述结构化的基于模块的程序.在MIL中,模块可能需要导入/导出各种资源.所谓的"资源"就是命名元素,例如类型定义,常量,变量,函数等.MIL 的编译器通过进行模块间的类型检查来保证系统的完整性,常见的检查包括:某个模块要使用的资源是否已经被其它模块提供了,资源的类型是否匹配,一个模块的实现是否确实提供了其规约中声明的资源,一个模块是否有权访问它要使用的资源等.早期的MIL要求不同模块的开发人员在开发前先达成很多一致.例如:能够根据简单的名字匹配来发现模块之间的交互,所有的模块都是用同一种语言开发的,所有的模块在组装系统时都可用,模块的接口描述了与之进行交互的其它模块……进一步的研究逐步弱化了这些限制.例如Darwin允许模块在运行时动态的实例化并进行绑定;Polygen允许不同的模块用不同的编程语言进行开发.各种软件配置的表示法逐渐成熟,它们既能描述静态也能描述动态的结构化的分布式系统. MIL的关注点是模块及其之间的互连.随着系统复杂度的提高,人们发现模块之间的交互逐步变得复杂.研究人员对模块之间交互的重视导致了"连接子"(connector)这个概念的诞生,它主要用于描述软件系统的各个组成部分(component)即构件之间的交互关系.从而软件系统的结构可以自然的用构件,连接子及其之间的配置进行描述.将连接子作为与构件同等重要的一阶实体进行处理,是因为如果不将构件之间的交互显式的进行描述,将会带来一些问题,包括: 难以将构件之间的交互信息局部化,从而导致难以识别系统中的连接,并且难以复用连接机制构件之间的关系难以进行抽象,从而阻碍对整个系统结构的理解由于构件的实现和交互信息绑定在一起,对不同构件的使用往往会因为交互机制的不兼容而产生严重的集成问题.支持构件,连接子及其配置的描述语言就是如今所说的体系结构描述语言(Architecture Description Language,ADL).UniCon就是最早出现的一种体系结构描述语言.此外,典型的ADL还包括:Rapide:一种事件驱动的ADL,它以体系结构定义作为开发框架,支持基于构件的开发.该语言提供了建模,分析,仿真和代码生成的能力,但是没有将连接子显式地表示为一阶实体.Wright:其主要特点是将CSP 用于软件体系结构的描述,从而完成对体系结构描述的某些形式化推理(包括相容性检查和死锁检查等).但它仅仅是一个设计规约语言,只能用于描述,无法支持系统生成,同时CSP 的使用也是比较困难的事情. Acme:支持ADL之间的映射及工具集成的体系结构互交换语言.其目标是作为体系结构设计的一个共同的互交换格式,以便将现有的各种ADL在这个框架下统一起来;而它本身也可以看作是一种ADL.xArch:一种基于XML 的ADL.它使用XML 定义了描述体系结构的核心元素,可以用来简单的描述软件体系结构,也可以作为设计其它ADL的基础,或者用作体系结构描述描述语言的互交换机制.xADL2.0:以xArch 为基础的基于XML 的ADL.除了xArch 的核心元素,xADL2.0 还提供了对系统运行时刻和设计时刻的元素的建模支持,类似版本,选项和变量等更高级的配置管理观念,以及对产品家族的体系结构的建模支持.此外,xADL2.0还利用XML 的可扩展性简化了新的ADL的设计及其相应工具的开发过程.各种ADL的出现为描述软件系统的结构提供了一种形式化的描述方法,而不是容易引起歧异的线框图.这种精确的描述也使得设计人员能够在系统开发的早期阶段对系统结构进行高层的分析和验证,从而有助于提高软件开发质量,降低开发成本.以下我们将着重介绍五种ADL:UniCon,Darwin,C2 SADL,Acme和xADL.常见的体系结构描述语言UniCon (Universal Connector)UniCon简介UniCon是由CMU和SEI设计的一个体系结构描述语言.该语言关注软件体系结构的结构化特性,将系统(本身也是一个复合构件)描述为构件和连接子的配置,其中构件表示计算或者数据,而连接子表示构件之间的交互.每个构件的接口都对外提供一些演员(player).构件通过这些演员与外界发生交互.与构件类似,一个连接子的协议对外提供一些角色(role),连接子通过这些角色来调解构件之间的交互.图- 1是用UniCon的图形化编辑器生成的示意图.UniCon概念的示意图图- 1中有两个构件,构件A和构件B,它们都是Unix中的过滤器.这两个构件都有三个演员,用三角形表示.左边的演员表示输入流"standard in",右边的演员是输出流"standard our"和"standard error".两个构件之间是一个连接子,它是Unix下的管道.这个连接子有两个角色:悬垂在左边的表示管道的入口(source),右边的表示管道的出口(sink).在上图中,构件和连接子之间还没有交互.为了在构件之间建立连接,演员必须和某个角色关联起来.如图- 2所示.在UniCon建立连接通过演员与角色的关联,最终就可以建立整个系统各个部分之间的配置.最新版本的UniCon不仅支持类似于上例的管道-过滤器系统,还支持使用过程调用和共享数据的模块交互系统,基于RPC调用的分布式系统,根据各种实时要求共享处理器的进程以及基于SQL命令的数据库访问.UniCon的提出是为了达到如下目的:解决系统描述和组装的实际问题,为实际工具提供一个原型;为各种连接机制提供一个一致的访问方式帮助软件设计师区分不同的构件类型和连接子类型并验证构件和连接子配置的正确性支持图形化和文本化符号以及二者之间的互换兼容现存的用常见的编程语言编写的构件(这些构件并不需要特定于UniCon) 尽可能的将运行时开销降到最低以下将具体介绍UniCon中构件和连接子的定义.UniCon中的构件UniCon中的构件定义包括规约部分和实现部分.构件的规约称为构件的接口(interface).接口定义了构件所能进行的计算以及使用构件必须遵循的约束.构件的接口包含三类信息:构件类型:构件类型表示构件提供的功能的类型,它限制了该构件所能定义的演员的数量,类型和规约.特性:由属性和值组成的二元组,用于指定与构件整体相关的附加信息,例如断言,约束等.演员:从构件外部可见的语义单元,构件通过演员与其它构件发生交互.其语法如下:构件的实现有两种形式:原子(primitive)实现:原子实现是一个指向存在于UniCon语言外部的文档链接,该文档包含了相应的构件实现.它可能是某种编程语言的源代码(目前UniCon工具集仅仅支持C语言的源代码),也可以是目标码,或者是包含目标码的Unix档案库文件,或者是二进制可执行文件,shell脚本,数据文件,C语言的include文件等复合(composite)实现:某个UniCon构件的复合实现是对其它已定义的构件和连接子的配置的描述,该实现包含三类信息:片段(piece):用于构造某个配置的构件和连接子实例配置信息:描述构件和连接子的关联抽象信息:描述该构件的接口如何由其复合实现中的构件接口实现.构件实现的语法如下:UniCon中的连接子连接子的定义也包含规约和实现两个部分,其中规约部分通过协议(protocol)进行描述.连接子的协议定义了构件之间允许产生的交互,并确保这些交互能够顺利进行.连接子的协议包含三类信息:连接子类型:连接子类型表示连接子所能调解的构件之间的交互类型,它限制了连接子的角色的数量,类型和规约.特性:由属性和值组成的二元组,用于指定和连接子整体相关的附加信息,例如断言,约束等(例如和时间和顺序相关的规则)角色:从连接子外部可见的语义单元,通过角色连接子对构件的交互进行调解.角色通过与演员发生关联,从而形成系统的连接,它定义了参与连接的演员的需求与责任.连接子的实现是UniCon内置的,即UniCon只支持连接子的原子实现,它本身不提供用户自定义连接子实现的机制.连接子的定义的语法如下(从中也可以看出UniCon目前支持的连接子实现的类型):UniCon是最早的体系结构描述语言之一.从上述介绍可以看出,UniCon强调将系统划分为构件后,用适当的连接子将其组装起来构成一个完整的系统.构件和连接子之间是松耦合关系.UniCon备受诟病的一点是它只支持预定义的连接子,并且不支持复合连接子.为了解决这个问题,相关研究人员在UniCon的基础上对其进行了增强.增强后的UniCon称为UniCon-2.UniCon-2提供了一个比较灵活的类型系统,并且引入了责任(duty)这个概念用于描述演员,角色等与属性的关系.某个系统配置的责任还可以用于描述体系结构风格.由于UniCon-2允许用户引入新类型,为了便于对与新类型相关的约束进行检查,UniCon-2采用了一种开放的编译器结构以便于增加相应的检测方法.DarwinDarwin简介Darwin最初是一个分布式系统配置语言,引入软件体系结构研究后,Darwin成为一个体系结构描述语言.作为一个ADL,Darwin对软件系统的静态结构的描述和UniCon非常相似,不过Darwin中引入了一些特有的构造(construct)使之便于描述系统的动态特性.此外,Darwin使用π演算作为其形式化基础,因此使用Darwin描述的体系结构模型能够进行一些高层的模型检测,例如是否存在死锁等.Darwin的建模能力和特点使用Darwin描述的软件系统配置主要由构件及构件之间的绑定(binding)组成. Darwin中的构件是用服务(service)进行定义的,一个构件既能对外提供一些服务,也能请求外部的服务.所有的服务名的作用范围仅限于定义这些服务的构件,亦即构件的定义本身并不需要了解全局的服务名.因此Darwin中的构件是上下文独立的(context independent),这有助于构件的复用,并能简化维护阶段对构件的替换工作.构件的服务由服务类型进行区分,但是Darwin本身并不解释服务类型信息.服务类型信息要么由低层的形式化行为规约进行解释,要么用于表示底层分布式平台所支持的通信机制(例如在Regis系统中,类型信息就可以直接用于选择正确的通信代码).图- 3是一个过滤器构件的定义,其中服务的类型信息就是尖括号内的内容.Darwin中的构件Darwin中的绑定就是构件的provide服务和require服务之间的链接.只有provide服务类型和require服务类型相互匹配,相应的绑定才是合法的.由于Darwin本身只管理服务类型,并不对其进行解释,因此必须由提供服务类型的系统来判断服务是否匹配(不过在Darwin目前的工具集中,仅仅简单的通过名字是否相同来判断服务是否匹配).为了灵活的对构件进行绑定,Darwin中提供了一些特有的关键字,例如forall,when等.下述代码是图- 4例子的Darwin描述,其中流水线的长度是由其参数动态决定的,forall,when等也体现了Darwin这种ADL 对动态性的支持.Darwin对动态结构的支持主要来自于延迟实例化(lazy instantiation)和直接动态实例化(direct dynamic instantiation)这两种技术.延迟实例化是指只有当用户试图访问某个服务时,提供该服务的构件才被实例化.将延迟实例化与递归结合起来就能描述几乎不受限制的结构,其局限性是不能描述循环绑定的结构.直接动态实例化则允许系统结构随意的发生演化,这需要底层π演算的相关支持.具体细节以及与π演算相关的内容请参看相关文献.可变长度的流水线(Pipeline)用Darwin 描述的客户服务期系统使用构件和绑定就能定义Darwin中的复合构件以及一个系统.事实上,Darwin描述的系统就是一个层次式结构化的复合构件.下述代码就是图- 5所示的客户服务器系统的Darwin描述.注意:其中的System构件就是最终的系统.Darwin的设计面向的是分布式软件,因此它对系统动态性的支持可以说是天生的.从抽象的角度来看,Darwin中的构件及其之间的绑定其实独立于具体的构件交互机制,因此理论上Darwin也能用于描述传统的程序结构.虽然Darwin能很好的描述系统的动态特性,但是Darwin中并没有显式的连接子概念,因此使用Darwin进行复杂系统设计时关注的主要还是构件;当然这似乎并不会削弱其表达能力.C2 SADLC2 SADL是UCI设计的一种基于消息传递的体系结构描述语言,主要用于描述符合C2风格的软件系统的体系结构.C2风格C2风格是一种基于构件和消息的体系结构风格,主要是应用于带有图形用户接口(GUI)的应用系统,但也能用于其它类型的应用.这种风格要求构件之间通过消息交换进行通信.因此每个C2构件和C2连接子都有一个top接口和一个bottom接口,其中top接口定义了该构件所能接收的应答消息和向上发出的请求消息,而bottom接口定义了该构件能够进行应答的请求消息及其向下发出的应答.所有消息都以连接子为桥梁在构件之间进行传递.这种风格的体系结构将系统中的构件用连接子划分为不同层次,如图- 4所示.C2风格的体系结构:可视化堆栈(Stack)C2概念的图例C2风格的核心在于构件之间的"有限可见性",即处于系统中某个层次的构件只能"看到"上层的构件,而不清楚下层到底是什么构件在与之进行通信.具体表现在如下所述的构件之间的通信规则(即系统的组装规则):构件的top接口只可能与某一个连接子的bottom接口相连构件的bottom接口只可能与某一个连接子的top接口相连与连接子相连的构件或者连接子没有数量限制两个连接子相连时,只能是其中一个的bottom接口与另一个的top接口相连C2 SADLC2 SADL目前还只是一个原型语言,其相应的支撑工具还在开发中.该语言包含三个部分:接口定义符号(IDN, interface definition notation):是C2中的构件接口的规约.如下所示是一个堆栈(Stack)构件的C2 IDN.体系结构描述符号(ADN,architecture description notation):是C2体系结构的声明性规约.例如图- 4所示例子的相应描述如下:体系结构构造符号(ACN,architecture construction notation):主要用于表达体系结构的动态变化,例如如果要在运行时删除堆栈的一种可视化表示方式,可以用ACN进行如下描述:C2 SADL中的连接子本质上是一种消息总线,复合这种结构的应用系统往往具有比较良好的灵活性和可扩展性.不过由于C2 SADL还没有针对大型实际系统进行建模和使用,因此对使用该结构所可能导致的性能问题还不是很明确.AcmeAcme简介Acme是CMU的Acme项目的产物.该项目始于1995年,目的是为了研究一个公共的语言,使之能在不同的体系结构设计工具之间作为体系结构描述信息互换的桥梁.目前Acme及其开发工具包AcmeLib提供了一个通用的,可扩展的基础框架用于描述,表示,生成以及分析系统的软件体系结构.而作为桥梁作用的Acme,由于必须具备大多数ADL共有的概念,因此它本身也是一个ADL,并且是一个相对而言比较简单的通用的ADL.Acme的建模元素和特点Acme的主要特点表现为:采用七个基本的体系结构设计元素作为体系结构的本体(architectural ontology),如图- 6,图- 7所示.采用灵活的标注机制支持使用外部语言定义的非结构化信息使用类型机制对常见的可复用的软件体系结构俗语和风格进行抽象描述使用开放的语义框架对体系结构描述进行推理Acme的设计元素Acme的设计元素以下对Acme所采用的设计元素进行简要介绍.这七个设计元素是:构件(components):系统中的计算元素和数据存储.直观的说,就是线框图中的框.典型的构件有:客户端,服务器,数据库,黑板,过滤器等.连接子(connectors):构件之间的交互.直观的说,就是线框图中的线.典型的连接子有:过程调用,事件广播,客户和服务器之间的协议等.系统(systems):构件和连接子的配置.端口(ports):构件通过端口与外界发生交互.一个构件可以有多个不同类型的端口,每个端口都是一个接口的集合,例如一系列需要以特定顺序调用的过程.角色(roles):连接子通过角色与外界发生交互.角色定义了构件之间交互的参与者. 表示(representations):构件或者连接子内部结构的描述.通过"表示"这个概念,系统的体系结构就具有了层次结构.同时,"表示"这个概念可以用于描述体系结构实体的多个视图(但是Acme本身并不处理视图之间的对应关系),如图- 7所示. 表示的映射(rep-maps):将构件或者连接子的内部"表示"与外部接口进行映射. 简单的客户端-服务器系统以下是一个简单的客户端-服务器系统(图- 8)的Acme描述.Acme本质上是一些ADL的建模元素的"最大公约数",因此它能作为不同ADL 及其支撑工具之间用于信息交换的语言.这是Acme的最大作用,当然这也使得它只能成为一个建模能力一般的ADL,例如Acme中就没有相应的机制用于对构件或者系统行为进行描述或者规约.相关研究者正在考虑在Acme中引入类似于Wright中使用的CSP的形式化语言来解决这个问题.当然,作为一个通用的交换语言,Acme的能力及其可扩展性也不是无限的.例如Acme的扩展仅限于在七个基本设计元素的基础上进行,并且Acme中缺乏用于描述属性及其数据格式的元语言.无论如何,Acme是第一个ADL之间的互交换语言,它的出现使得不同的ADL支持工具之间有可能进行体系结构描述信息的交流.xADLxADL简介xADL是UCI设计的一个基于xml的ADL,最新版本是xADL2.0.其建模元素都是使用xml schema进行定义的.xADL除了提供ADL中常见的建模元素外,还对产品家族的描述提供了一些支持,例如体系结构版本等.这是xADL的一个独特之处.此外,xADL本身设计成一个模块化语言,因此具有良好的可扩展性.xADL建模元素和特点作为一个ADL,xADL也定义了常见ADL中的建模元素,包括构件,连接子,构件的接口,配置等,其中构件和连接子都具有内部结构.由于xADL的模块化特性,使得用xADL描述的体系结构看起来就像是一些相互独立的结构的集合.例如下述代码就是用xADL描述的一个客户-服务器结构(图- 11)(由于空间有限,下述简写代码没有遵循xml的格式!)用xADL 描述的客户-服务器系统除了上述常见的体系结构建模元素,xADL还提供了一些特有的建模元素用于支持产品家族的建模,这些元素包括:选项(Option):允许体系结构描述中的一些构件或者连接子在某些情况下是可选的,即不一定存在.变体(Variant):类似于编程语言中的联合(Union).将某些构件或者连接子指定为变体,意味着这些元素在某些情况下可以被实例化为不同类型的元素.版本(Version):用于描述构件,连接子和接口的版本树.这样就可以在同一个体系结构模型中使用同一类型元素的不同版本.结构差异(Structural Differing):用于描述两个xADL结构的差异.产品线体系结构差异(Product-Line Architecture Differing):用于描述产品线中两个体系结构的差异.上述建模元素在xADL中根据抽象层次分为两类,一类是运行时概念,包括构件实例,连接子实例,接口实例,链接实例等;还有一类是运行时概念,包括构件,连接子,接口,链接等(这些都是类型的概念)xADL的另一个特点在于其灵活的可扩展性.其可扩展性本质上来源于xml以及schema的可扩展性,例如可以通过schema的include机制来实现继承等.当然,从上述介绍中也可以看出,xADL也提供了体系结构建模的基本元素,并且用于定义xADL的xml schema是独立于其它ADL的,因此xADL也可以用于ADL 之间的转换.已有研究人员已经给出了从C2,Acme等ADL到xADL的映射规则. xADL相比UniCon等ADL来说属于第二代的ADL.其xml基础使其具有良好的可扩展性,并且由于xml格式文本的易交换性使得xADL能比较容易的集成不同的支持工具.但是由于xml格式的冗长,因此对xADL的使用需要有一定的工具支持.体系结构描述语言分类框架根据对ADL的研究,Medvidovic 和Taylor 于2000年提出了一个用于对ADL进行分类和比较的一般框架,如表1所示.该框架认为一个ADL必须明确的对构件,连接子和它们的配置进行建模;为了保证体系结构描述有明确的语义还必须对构件的接口进行建模.此外,为了保证可用性和有用性,它也必须为基于体系结构的开发和演化提供工具支持.除了上述必需的建模元素外,不同的方法由于关注点的不同,可能会关注不同的体系结构特性,比如系统组装的风格,某个应用领域的特征以及分布,并发,安全和吞吐量等属性.体系结构描述语言体系结构建模特性构件接口,类型,语义,约束,演化,非功能属性连接子接口,类型,语义,约束,演化,非功能属性体系结构配置易理解性,组装性,精化和追踪性,异构性,可量测性,演化,动态性,约束,非功能属性工具支持主动规约,多视图,分析,精化,实现生成,动态性ADL的分类与比较框架,黑体字表示必须建模的元素如上所述,构成体系结构描述的三要素是:构件,连接子和体系结构配置.因此,一个ADL应该提供至少这三种元素的显式描述.是否同时描述了这三种元素,也可以。
1、软件重用是指重复使用已有的软件产品用于开发新的软件系统,以达到提高软件系统的开发质量与效率,降低开发成本的目的。
答案:√2、可重用技术对构件库组织方法要求不仅要支持精确匹配,还要支持相似构件的查找。
答案:√3、软件体系结构充当一个理解系统构件和它们之间关系的框架,特别是那些始终跨越时间和实现的属性。
答案:√5、构件可以由其他复合构建和原子构件通过连接而成。
()答案:√6、体系的核心模型由5种元素组成:构建、连接体、配置、端口和角色()答案:√7、软件体系结构的核心由5种元素组成:构件、连接件、配置端口和角色。
其中,构件、连接件和配置是最基本的元素()答案:√8、开发视图主要支持系统的功能需求,即系统提供给最终用户的服务()答案:X9、构件、连接件以及配置是体系结构的核心模型最基本的元素()答案:√10、HMB风格不支持系统系统自顶向下的层次化分解,因为它的构件比较简单。
答案:×11、正交软件体系结构由组织层和线索的构件构成。
13、线索是子系统的特例,它由完成不同层次功能的构建组成,每一条线索完成整个系统中相对独立的一部分功能。
()答案:√14、层次系统中支持抽象程度递增的系统设计是设计师可以把一个复杂系统按照递增的步骤进行分解,同时支持功能增强,但是不支持重用。
答案:×16、在软件设计中占据着主导地位的软件体系结构描述方法是图形表达工具。
答案:√18、体系结构设计是整个软件生命周期中关键的一环,一般在需求分析之后,软件设计之前进行。
答案:√19、基于软构件的系统描述语言是较好的一种以构件为单位的软件系统描述语言。
答案:√21、基于构件的动态系统结构模型分为三层,风别是应用层、中间层、和体系结构层。
答案:√23、基于构件的动态系统结构模型分为应用层,中间层和体系结构层。
答案:√29、一般的说,一个模式有一下4个基本成分,1.模式名称,2.问题,3.解决方案,4.效果,这句话是对的()答案:√30、设计模式的概念最早是由美国的一位计算机专家提出的。
学号 1206
年级 2012级
动态软件体系结构描述D-ADL方法理解与研究
专业班级计算机(2)班
姓名
联系方式 15
任课教师周
2015年5月
中国南京
摘要
D-ADL是一种刻画软件的动态行为的描述方法,该方法是由我国学者李长云提出的。
在D—ADL中,组件、连接件和体系结构风格定义为抽象类型,系统行为被模型化为进程,构件和连接件的交互点则被模型化为通道,它将动态行为从计算行为中分离出来,其结果能够被预先推导。
关键词:动态软件体系结构;D-ADL
根据软件体系结构在运行时的演化方式,可以分为静态软件体系结构和动态软件体系结构。
软件体系结构的动态演化包括组件或连接件的创建或删除、组件的更新、调整负载平衡等几种情况。
D-ADL便是一种为动态体系结构建模提供支持的方法。
D-ADL遵循Wright等给出的SA描述框架,并且D-ADL将高阶多型π演算作为行为语义基础,凭借高阶π演算描述动态系统的特征,D-ADL允许构件、连接件和配置产生变更,并使得对SA的自动化分析成为可能。
D-ADL将类型与实例区分开来,构件类型是实现构件重用的手段。
构件具有三个基本组成部分:接口部分、行为部分和属性部分。
构件分有原子构件和复合构件两种。
原子构件是指不具备内部结构的构件。
为了进一步促进原子构件的重用,构件可以参数化,通过输入不同的参数,来提高构件的灵活性。
复合构件是由多个构件实例和连接件实例组装而成的,它在规约层次上表达了成员之间的组合。
与原子构件类似,复合构件也可进行参数化,从而提高构件的可重用性。
连接件是一种特殊的构件,同样地,连接件也分为原子连接件和复合连接件两类。
原子连接件语法规约类似于原子构件,仅仅是计算行为描述换成了路由行为。
通过结构化组合,多个连接件和构件也能形成复合连接件。
在D-ADL中,动态行为规约是通过choreographer来处理的.动态行为本质上是对体系结构的动态重配置,涉及到如下的体系结构变动:
(1)动态创建新的构件实例和连接件实例以及新的端口和通道;
(2)动态删除构件实例和连接件实例以及端口和通道;
(3)体系结构元素之间连接的改变。
在π演算中定义了两种行为等价关系:强等价关系和弱等价关系。
强等价关系既考虑系统的内部行为,又考虑系统的外部行为;而弱等价关系是一种不考虑系统的内部行为的行为等价理论,即如果系统A和B弱互模拟,则A和B表现出来的外部行为是等价的。
它定义了如下规则:
1.设构件A和B的行为分别被形式化为进程Pa和Pb,则要使得A和B能够相互联机替换,必要的条件是Pa和Pb具备弱等价关系。
D-ADL以高阶多型π演算作为行为语义基础,因此构件的行为规约能够从D-ADL描述出发转换为高阶π演算进程,进而利用规则1和高阶π演算弱等价判定理论及其工具推导出构件能否替。
2.设进程PA表示构件A的行为,进程PB表示构件B的行为,若构件A是对构件B的求精,则PA观察弱模拟PB。
分支弱模拟意指对不可观察的活动序列进行抽象,在跟踪每一
个可观察的活动的同时保持进程的所有分支轨迹.连接件旨在建立构件间的交互,而交互的核心体现为路由行为,连接件求精应该保持路由行为的一致。
3.设进程PC表示连接件C的行为,进程PD表示连接件D的行为,若连接件C是对连接件D的求精,则PC分支弱模拟PD。
D—ADL的特点:
(1)D—ADL将动态行为从计算行为中分离出来,显式地、集中地表示,便于体系结构动态逻辑的理解、编写和修改;
(2)D.ADL中的动态行为可形式化为高阶兀演算进程,因此能够预先推导动态行为的结果;
(3)借助于高阶7c演算理论和工具,D—ADL可用于动态体系结构模型的形式化验证、求精和演化。
π-ADL与D-ADL的比较:
D—ADL借鉴了π-ADL的一些思想,也是一种基于高阶π演算的形式化语言,支持动态体系结构建模和验证。
但与π-ADL相比有如下不同:
(1)D-ADL显性定义了体系结构的动态行为操作符“new”和“delete",π-ADL则借助π进程的输入输出动作间接实现动态行为.虽然D—ADL的动态行为操作符的语义解释也归于π进程的输入输出动作,但从语用学角度看,使用D-ADL更便于动态行为的描述和理解。
(2)D-ADL将动态行为与计算行为相分离,使得动态体系结构的行为视图更加清晰,同时由于动态行为具备高阶π演算语义,能够预先推导动态行为的结果,因此可采取措施使这种分离不影响计算行为的正确性。
(3)π-ADL直接支持体系结构的演化,D-ADL本身仅实现了对体系结构动态行为(规约不变)的描述,但对体系结构的演化也有间接的支持。
D-ADL的发展:
D-ADL是基于高阶多型π演算的动态体系结构语言,它将π演算的行为模拟和等价理论用于系统的联机演化和SA模型求精的规则,实现动态行为和计算行为解耦,并将动态行为形式化为高阶π演算进程,能预先推导动态行为的结果,但在支持非预设的动态演化方面,D-ADL只是通过不同的求精方式来支持,不能明确地推导出软件的自适应行为。
D-ADL进一步的工作是结合其他形式化规约方法,完善D-ADL语言。
基于高阶π演算理论,D-ADL适合描述动态系统的结构和行为。
然而,体系结构尚有许多方面需要进行描述,如系统的属性和约束。
如何运用多种形式化机制,从不同视点描述体系结构,并组成一个有机整体,是D—ADL面临的巨大挑战。
此外,虽然已经存在许多高阶冗演算工具,但
并不能够完全满足D—ADL的需求。
因此,需要进一步研制相关支持工具,对复杂系统规约能够进行自动化分析、检测和仿真。