架構描述語言
此條目沒有列出任何參考或來源。 (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) (頁面存檔備份,存於網際網路檔案館)
- 第二候選
- 其他
架構解決方案
編輯- 學院派解決方案
- 專注於架構化模型的分析評估
- 單獨模型
- 嚴格的建模標記
- 強大的分析技術
- 深度優先廣度
- 特殊用途的解決方案
- 工業解決方案
- 專注於廣泛的開發問題
- 模型家族化
- 實用性優先於嚴謹性
- 架構作為開發的藍圖
- 廣度優先深度
- 通用解決方案
結論
編輯- 有豐富的研究可借鑑
- 已經學習了很多表現和分析架構的知識
- 現在需要總結共同知識並付諸實踐