跳转到内容

架构描述语言

本页使用了标题或全文手工转换
维基百科,自由的百科全书
(重定向自架構描述語言

架构描述语言(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候选

架构解决方案

[编辑]
  • 学院派解决方案
    • 专注于架构化模型的分析评估
    • 单独模型
    • 严格的建模标记
    • 强大的分析技术
    • 深度优先广度
    • 特殊用途的解决方案
  • 工业解决方案
    • 专注于广泛的开发问题
    • 模型家族化
    • 实用性优先于严谨性
    • 架构作为开发的蓝图
    • 广度优先深度
    • 通用解决方案

结论

[编辑]
  • 有丰富的研究可借鉴
  • 已经学习了很多表现和分析架构的知识
  • 现在需要总结共同知识并付诸实践