架构描述语言
此條目没有列出任何参考或来源。 (2011年4月21日) |
架构描述语言(Architecture Description Language),簡稱ADL。目前,两个重要的团体在使用架构描述语言术语。它们是:
在软件工程团体,架构描述语言(ADL)是一种计算机语言,用来描述软件或系统架构。这意味着如果是技术性架构,该架构必须被清楚的传达给软件开发者。功能架构下,该软件架构必须被清楚的传达给利益相关者和企业工程师。一些软件工程团体开发了若干ADL,如ACME(CMU开发),AADL(SAE标准化),C2(UCI开发),Darwin(英国伦敦帝国学院开发)和Wright(CMU开发) 。
企业建模和工程团体也开发了企业级的架构描述语言。例子包括ArchiMate(现在是 The Open Group 發佈的标准),DEMO等。这些语言并不需要参照软件构件等。但他们大多数认为应用架构应该能清楚的传达给软件工程师。
下面所写的内容主要从软件工程团体的角度考虑。
简介
如有标准标记(ADL)表现架构,下列方面将会更好:
- 相互沟通
- 体现早期设计决策
- 系统抽象可转换
过去的架构主要是通过画方块和线表述。图中通常定义下列内容:
- 构件的自然特性
- 构件属性
- 语义连接
- 整个系统行为
ADL起源于正式表现架构的语言学方法,因此也表明了其缺点。复杂的ADL允许架构设计决策的早期分析和可行性测试。
特征
有许多种ADL,或由学术机构开发或由工业组织开发。有些语言不试图成为一个ADL,但事实证明它们适合表现和分析架构。ADL原则上的不同之处:
- 需求语言,因为ADL植根于解决方案,而需要说明问题。
- 编程语言,因为ADL不能绑定架构抽象到具体解决方案
- 建模语言,因为ADL往往侧重于表现构件而不是整体行为。然而,有重点表现构件的特定域建模语言(DSML)。
下面列表是ADL语言最基本的要求。必须:
- 适合架构表达给所有有关方面
- 支持架构创建,完善和验证任务
- 提供一个进一步实现的基础,因此它必须能够给ADL规范添加信息,使最终的系统规范衍生自ADL
- 提供表现通用类型架构的能力
- 支持分析能力或提供快速生成原型的实现
ADL的共同点:
- 图形语法,带有通常是文字形式并正式定义的语法和语义
- 分布式系统建模的特性
- 不支持捕捉设计信息,除非使用通用注释机制
- 能够表现细节层次,包括通过实例模板建立子结构
ADL的不同能力:
- 在架构层次,处理实时构造,如期限和任务优先次序,
- 支持不同风格架构的规范。很少处理面向对象类继承或动态架构
- 支持分析
- 处理相同架构的不同实例,涉及产品线架构
ADL积极因素
- ADL代表表现架构的正式方式
- ADL,人和机器可读
- 支持在可能比原先较高的水平描述一个系统
- ADL支持架构分析-完整性,一致性,歧义,和性能
- ADL支持自动生成软件系统
ADL消极因素
- 没有普遍一致的意见:ADL应表现什么,特别是架构的行为
- 目前使用的表现,分析困难且无商业工具支持
- 大多数ADL倾向于垂直优化特定的分析
架构的共同概念
ADL团体普遍认为,软件体系结构是一套组件以及它们之间的连接。但也有如下不同类型的架构:
对象连接架构
- 配置包括接口和面向对象系统的连接的
- 接口指定由模块必须提供的特性与接口一致
- 接口所代表的连接与调用图一起
- 通常编程语言强制一致性
o 分解- 接口关联到唯一的模块 o 接口一致性-句法规则的静态检查 o 通信完整性-模块之间可见性
接口连接架构
- 扩展接口和连接的角色
o 接口指定“需要”和“提供”特性 o 连接被定义在“需要”和“提供”特性之间
- 包括接口,连接和约束
o 约束架构中接口和连接的严格行为 o 架构中的约束映射为系统需求
大多数ADL实现了接口连接架构。
架构与设计
架构和设计区别是什么?架构铸造非功能性决策和划分功能需求,而设计是贯穿功能需求完成过程的原则。架构探索意味着,有必要更深一层验证选择,因此,架构必须做高层次的设计,以验证划分。
例子
下面的列表给出了目前为止最好的ADL候选
- 主要候选
- ACME / ADML (CMU/USC) (页面存档备份,存于互联网档案馆)
- Rapide (Stanford) (页面存档备份,存于互联网档案馆)
- Wright (CMU) (页面存档备份,存于互联网档案馆)
- Unicon (CMU)
- ByADL (Build Your ADL) (页面存档备份,存于互联网档案馆) - 拉奎拉大學
- LePUS3 和 Class-Z (页面存档备份,存于互联网档案馆) (艾塞克斯大学)
- ABACUS (UTS) (页面存档备份,存于互联网档案馆)
- 第二候选
- 其他
架构解决方案
- 学院派解决方案
- 专注于架构化模型的分析评估
- 单独模型
- 严格的建模标记
- 强大的分析技术
- 深度优先广度
- 特殊用途的解决方案
- 工业解决方案
- 专注于广泛的开发问题
- 模型家族化
- 实用性优先于严谨性
- 架构作为开发的蓝图
- 广度优先深度
- 通用解决方案
结论
- 有丰富的研究可借鉴
- 已经学习了很多表现和分析架构的知识
- 现在需要总结共同知识并付诸实践