摘要

本文的目的是為軟件體系結構的建立奠定基礎蜂绎。我們首先通過吸引幾個已經(jīng)確立的體系結構規(guī)程來開發(fā)軟件體系結構的直覺净刮【呶拢基于這種直覺，我們提出了一個軟件架構模型癞揉，它由三個部分組成:元素纸肉、形式和原理溺欧。元素是處理、數(shù)據(jù)或連接元素柏肪。表單是根據(jù)元素(即元素上的約束)的屬性和元素之間的關系來定義的姐刁。就系統(tǒng)約束而言，ratio-nale提供了體系結構的底層基礎烦味，這些約束通常來自于系統(tǒng)需求聂使。我們在體系結構和體系結構樣式的上下文中討論了模型的組成，并給出了一個擴展示例來說明一些重要的體系結構和樣式注意事項谬俄。最后柏靶，我們提出了軟件架構方法的一些原則，總結了我們的貢獻溃论，并將我們的方法與其他當前工作聯(lián)系起來屎蜓。

1.介紹

軟件設計在20世紀70年代受到了研究人員的極大關注。本研究針對20世紀60年代[5]首次提出的開發(fā)大型軟件系統(tǒng)的獨特問題钥勋。研究的前提是設計是一項獨立于實現(xiàn)的活動炬转，需要特殊的注意事項、技術和工具[3,9,17]算灸。這種軟件設計研究的成果現(xiàn)在已經(jīng)開始作為計算機輔助軟件工程(CASE)工具[7]進入市場扼劈。

在20世紀80年代，軟件工程研究的焦點從軟件設計轉向將設計和設計過程集成到軟件過程及其管理的更廣泛的環(huán)境中菲驴。這種集成的結果之一是测僵，為軟件設計開發(fā)的許多符號和技術已經(jīng)被實現(xiàn)語言所吸收。例如谢翎，考慮一下支持\大型編程的概念。這種集成往往模糊(如果不是混淆的話)設計和實現(xiàn)之間的區(qū)別沐旨。

20世紀80年代森逮，我們描述和分析軟件系統(tǒng)的能力也有了很大的進步。我們在這里指的是諸如形式描述技術和類型的詭辯概念之類的東西磁携，它們使我們能夠更客觀地對軟件系統(tǒng)進行推理褒侧。例如，我們能夠更直觀地推斷\一致性“和\不一致性”谊迄，我們能夠討論\類型一致性“1而不僅僅是\類型等價”闷供。

我們相信，20世紀90年代將是軟件架構的十年统诺。我們使用術語\架構“歪脏，在對比\設計”，以喚起概念的codification粮呢，抽象婿失，標準钞艇，正式培訓(軟件架構師)，和風格豪硅。雖然已經(jīng)有一些工作在德寧特定軟件架構(例如,[19日22]),甚至一些工作在發(fā)展中一般支持開發(fā)架構的過程(尤其是薩拉[8]),是時候重新審視架構的作用在這一大背景下的軟件過程,軟件過程管理哩照、以及元帥(marshal)已經(jīng)開發(fā)出來的各種新技術。

作為一門主要學科懒浮，我們期望從軟件體系結構的出現(xiàn)中獲得的一些好處是:
1)體系結構作為滿足需求的框架;
2)架構作為設計的技術基礎飘弧，作為成本估算和過程管理的管理基礎;
3)架構作為復用的一種映射基礎;
4)架構作為依賴和一致性分析的基礎。

因此砚著，我們研究的主要對象是支持軟件架構規(guī)范的開發(fā)和使用次伶。本文旨在為今后軟件體系結構的研究奠定基礎。

在第2節(jié)中赖草，我們首先在諸如硬件学少、網(wǎng)絡和構建體系結構等已確立的規(guī)程的背景下，開發(fā)關于軟件體系結構的直覺秧骑，建立軟件體系結構的上下文版确，并為我們的方法提供動機。

在第3節(jié)中乎折，我們提出了軟件體系結構和軟件體系結構風格的模型和描述绒疗。接下來，

在第4節(jié)中骂澄，我們將討論一個容易理解的示例吓蘑，以引出軟件體系結構的一些重要方面，并描述軟件體系結構表示法的需求坟冲。

在第5節(jié)中磨镶，我們詳細介紹了我們的軟件架構方法的兩個主要原則。

在第六章中健提，我們總結了本文的主要觀點琳猫，并結合相關工作進行了總結。

2.直覺私痹、情境和動機（Intuition, Context, and Motivation）

在介紹我們的軟件架構模型之前脐嫂，我們先來看看它的哲學基礎:
1)通過與現(xiàn)有學科的類比來發(fā)展對軟件架構的直覺;
2)提出多層次產(chǎn)品范式下的軟件體系結構協(xié)議書;
3)為軟件架構作為一門獨立的學科提供一些動力。

2.1培養(yǎng)對軟件架構的直覺

有趣的是紊遵，我們沒有命名軟件架構账千。我們有一些直覺，認為有不同種類的軟件架構暗膜，但是我們沒有將它們形式化匀奏，或者制度化。我們的主張是桦山，當前的事件狀態(tài)之所以存在攒射，是因為軟件架構太多了醋旦，而不是因為太少了。在這一節(jié)中会放，我們將介紹幾個架構學科饲齐，以便開發(fā)我們對軟件架構的直覺。我們關注硬件和網(wǎng)絡架構咧最，因為它們在理論上被認為是軟件架構的思想來源;我們關注建筑是因為它是經(jīng)典的“建筑學科”捂人。

2.1.1計算機硬件架構

有幾種不同的硬件架構方法，它們的區(qū)別在于所強調的硬件方面矢沿。RISC機器是一種強調指令集是重要特征的硬件架構的組成部分滥搭。流水線機器和多處理器機器是硬件架構的例子，它們強調硬件架構塊的組合捣鲸。
在我們考慮軟件體系結構時瑟匆，第二個面向硬件體系結構的方法有兩個重要的有趣特性:

• there are a relatively small number of design ele-ments;
  設計元素相對較少;
• scale is achieved by replication of these design ele-ments.
  規(guī)模是通過復制這些設計元素來實現(xiàn)的。

這與軟件架構形成了對比栽惶，在軟件架構中愁溜，可能的設計元素非常多。此外外厂，規(guī)模不是通過復制設計元素來實現(xiàn)的冕象，而是通過添加更多不同的設計元素來實現(xiàn)的。然而汁蝶，也有一些相似之處:我們經(jīng)常以類似于上面提到的硬件架構的方式組織和調用軟件架構渐扮。例如，我們創(chuàng)建多進程軟件系統(tǒng)并使用流水線處理掖棉。

因此墓律，本討論的重要觀點是，這兩種體系結構之間存在根本和重要的差異幔亥。由于這些差異只锻，我們經(jīng)常以類似硬件的術語表示軟件架構，這多少有些諷刺紫谷。

2.1.2 網(wǎng)絡體系結構

網(wǎng)絡架構是通過將網(wǎng)絡的設計元素抽象為節(jié)點和連接，并通過命名這兩個元素之間的關系來實現(xiàn)的捐寥。因此笤昨，我們以星網(wǎng)、環(huán)網(wǎng)和曼哈頓街網(wǎng)絡作為命名網(wǎng)絡架構的例子握恳。

關于網(wǎng)絡架構的兩個有趣的架構點是:

• there are two components nodes and connections;
  有兩個組件 節(jié)點和連接;
• there are only a few topologies that are considered
  只有少數(shù)拓撲被考慮

當然瞒窒，我們可以在軟件架構中抽象到類似的層次，例如流程和集成流程通信乡洼。然而崇裁，與其考慮一些拓撲匕坯，還不如考慮非常多的可能拓撲，而且這些拓撲通常沒有名稱拔稳。此外葛峻，我們強調大小方面的差異，從拓撲的節(jié)點和連接巴比。相反术奖，我們考慮的問題是進程的位置(例如，分布式架構)或進程間通信的類型(例如轻绞，消息傳遞架構)采记。

因此，盡管我們可以從一個類似的抽象層次來看待架構元素政勃，但是我們并沒有從使用網(wǎng)絡作為軟件架構的類比中得到太多好處唧龄。

2.1.3 建筑結構

經(jīng)典的架構領域為軟件架構提供了一些更有趣的見解。雖然兩者的主題相當不同奸远，但是在構建體系結構時既棺，有許多有趣的體系結構點可以為軟件體系結構提供建議:

• multiple views;
  多個視圖;
• architectural styles;
  建筑風格;
• style and engineering;
  風格和工程;
• style and materials;
  風格和材料;

建筑建筑師通過許多不同的觀點與客戶一起工作，這些觀點強調了建筑的某些特定方面然走。例如援制，立面圖和平面圖分別給出了外部視圖和自上而下的視圖。立面視圖可以通過背景圖甚至比例模型來補充芍瑞，為客戶提供建筑在其背景下的外觀晨仑。對于建造者來說，建筑師提供了相同的樓層平面圖和額外的結構視圖拆檬，這些視圖提供了關于各種顯式設計考慮(如電線洪己、管道、供暖和空調)的大量細節(jié)竟贯。

類似地答捕，軟件架構師需要為不同的用途和用戶提供不同的軟件架構視圖。目前我們只有一個觀點:實現(xiàn)屑那。在真正意義上拱镐，實現(xiàn)就像一個構建器詳細視圖，也就是說持际，就像一個沒有外殼的建筑沃琅，其中所有的細節(jié)都是可見的。從系統(tǒng)的各個細節(jié)抽象出系統(tǒng)的設計和構造是非常困難的蜘欲。(以巴黎蓬皮杜中心為例益眉。)

從描述性和說明性的角度來看，體系結構風格的概念特別有用。建筑風格是設計元素和形式安排的一種具體的規(guī)定郭脂。從規(guī)定上說年碘，風格限制了設計元素的種類和它們的正式安排。也就是說展鸡，建筑風格既限制了設計元素屿衅，又限制了設計元素之間的形式關系。類似地娱颊，我們將發(fā)現(xiàn)這是軟件架構中最有用的概念傲诵。

最重要的是工程原則和建筑風格(當然還有建筑本身)之間的關系。例如箱硕，在劍橋大學國王學院的禮拜堂里拴竹，從羅馬式工程學院(romanesque engineering)傳來的光線和通風的垂直型風格讓人感覺不到。從羅馬式的厚重到垂直的輕盈剧罩，需要不同的工程原理栓拜。這不僅僅是美學問題。這種工程原理與軟件體系結構之間的關系也是非常重要的惠昔。

最后幕与，建筑風格與材料之間的關系至關重要。這些材料具有某些特性镇防，可用于提供特定的樣式啦鸣。人們可以將結構與材料的美學用途結合起來，例如都鐸式房屋的柱梁結構来氧。然而诫给，人們不會用木樁和木梁建造摩天大樓。設計元素的材料方面為建筑提供了美學和工程基礎啦扬。同樣中狂，這種關系在軟件架構中是至關重要的。

因此扑毡，我們在構建體系結構時發(fā)現(xiàn)了一些關于軟件體系結構的基本觀點:需要多個視圖來強調和理解體系結構的不同方面;風格是一種令人信服的重要的法典（codification）形式胃榕，既可用于描述，也可用于規(guī)定;而工程原理和材料性能在發(fā)展和支撐一種顆粒建筑和建筑風格中具有根本的重要性瞄摊。

2.2架構的上下文(the context of architecture)

在討論我們進行軟件架構說明的動機之前勋又，我們假定在整個軟件產(chǎn)品的上下文中對架構進行了描述。請注意换帜，我們并不是在暗示創(chuàng)建此產(chǎn)品的特定流程的任何內容赐写，當然，我們的視圖中可能包含有關該流程的暗示膜赃。我們的目的主要是為體系結構提供一個環(huán)境，在這個環(huán)境中可以被認為是一個相當標準的軟件產(chǎn)品揉忘。

我們將軟件產(chǎn)品的不同部分劃分為對該部分重要的事物的種類跳座，在該層次上重要的實體的種類端铛，它們的屬性和關系，以及在該層次上相關的決策和評估標準的種類:

• 要求是有關確定資訊疲眷、處理禾蚕，以及該等資訊和處理的特點，是系統(tǒng)使用者所需要的;
• 體系結構涉及檔案結構元素的選擇狂丝、它們之間的相互作用换淆，以及對這些元素的約束和它們之間的相互作用，這些元素是提供滿足需求并作為設計基礎的框架所必需的;
• 設計是指設計元素及其算法和程序的模塊化和詳細接口，以及支持體系結構和滿足需求所需的數(shù)據(jù)類型;
• 實現(xiàn)涉及滿足設計、體系結構和需求的算法和數(shù)據(jù)類型的表示厨姚。

某一特定產(chǎn)品的不同部分絕不是如此簡單的表征注益。模型、抽象沟启、轉換和表示的可能選擇是連續(xù)的。我們將這個連續(xù)體簡化為四個獨立的部分，主要是為了直觀地了解體系結構如何與軟件系統(tǒng)的需求和設計相關聯(lián)躁愿。

需要注意的是，有一些開發(fā)范式我們的描述并不適用于|沪蓬，例如在AI研究中經(jīng)常發(fā)現(xiàn)的探索性編程范式彤钟。然而，我們的描述代表了在產(chǎn)品軟件創(chuàng)建中使用的各種開發(fā)和演進范式跷叉，并且描述了一個重要的逸雹、迄今為止被低估的軟件產(chǎn)品[15]的一部分。

2.3架構規(guī)范的動機(motivation for Architectural Specifications)

有許多因素導致了軟件的高成本性芬。兩個重要的因素是軟件架構是演進和定制的峡眶。（evolution and customization）

系統(tǒng)不斷發(fā)展并適應新的用途，就像建筑物隨著時間的推移而變化并適應新的用途一樣植锉。演化的一個經(jīng)常伴隨的特性是系統(tǒng)|的脆性增加辫樱，即對變化的阻力增加，或者至少對優(yōu)雅地變化[5]的阻力增加俊庇。這部分是由于兩個建筑問題:建筑侵蝕和建筑漂移狮暑。建筑的侵蝕是由于對建筑結構的破壞。這些違規(guī)行為往往會導致系統(tǒng)問題的增加辉饱，并導致系統(tǒng)|的脆性增加搬男，例如，拆除承重墻往往會導致災難性的結果彭沼。建筑的漂移是由于對建筑的不敏感造成的缔逛。這種不敏感更容易導致不適應，而不是災難，并導致形式缺乏連貫性和清晰度褐奴，從而更容易違反現(xiàn)在變得更加模糊的架構按脚。

定制是軟件架構中的一個重要因素，這并不是因為它會導致問題敦冬，而是因為它所預言的架構成熟度的缺乏辅搬。在構建軟件系統(tǒng)時，我們仍然處于為每個新體系結構重新創(chuàng)建每個設計元素的階段脖旱。我們還沒有達到一個標準的階段堪遂，我們有一套標準的建筑風格，伴隨著它們的設計元素和正式的安排萌庆。每個系統(tǒng)在本質上都是一個新的建筑溶褪，一種新的建筑風格。無處不在的定制的出現(xiàn)表明踊兜，對編碼的需求是普遍存在的 -----也就是說竿滨，需要為各種體系結構樣式提供體系結構模板。對于具有特定風格的系統(tǒng)的標準部分捏境，架構師可以從一組已知的和可理解的元素中進行選擇于游，并以適合所需體系結構的方式使用它們。對體系結構元素使用標準模板之后垫言，架構師就可以將精力集中在那些定制非常重要的元素上贰剥。

考慮到我們對架構的描述和激勵問題，有許多事情我們想要能夠用架構規(guī)范來做：

• 規(guī)定所需級別|的架構約束筷频，即指示所需的限制性或許可性蚌成，確定所需級別的概括性或特殊性，指出什么是必需品凛捏，什么是奢侈品担忧，并指出相關性和絕對性的程度。我們希望一種支持最小約束原則的方法“能夠只表達體系結構中在系統(tǒng)描述的體系結構級別上需要的那些約束”坯癣。這與當前的實踐是一個重要的背離瓶盛，當前的實踐不是指定約束，而是提供包含這些期望約束的特定解決方案示罗。
• 美學與工程分離------也就是說惩猫，要從“什么是\演講”中準確地說出什么是\承重。這種分離使我們能夠避免導致體系結構侵蝕的各種更改蚜点。
• 以適當?shù)姆绞奖磉_體系結構的不同方面轧房，也就是說，在適當?shù)囊晥D中描述體系結構的不同部分绍绘。
• 執(zhí)行依賴和一致性分析-------即確定體系結構奶镶、需求和設計之間的相互依賴關系;確定體系結構各個部分之間的相互依賴關系;確定建筑風格之間迟赃、風格與建筑之間、建筑元素之間的一致性或缺乏一致性厂镇。

3.軟件架構模型

在第2節(jié)中捺氢，我們使用構建體系結構的領域來提供一些關于軟件體系結構可能是什么的洞見。建筑結構的概念剪撬，我們呼吁的是標準的定義:藝術或科學的建筑:特別是設計和建設的哈比斯結構“[11]。也許與我們的需要更相關的是一個次要的概念:\統(tǒng)一或連貫的形式或結構“[11]”悠反。這就是建筑的感覺------提供一個統(tǒng)一或連貫的形式或結構|残黑，這注入了我們的軟件檔案結構模型。

我們首先介紹了我們的軟件架構模型斋否，介紹了軟件架構風格的概念梨水，并討論了處理、數(shù)據(jù)和連接器視圖之間的相互依賴關系茵臭。

3.1模型

通過與建筑體系結構的類比疫诽，我們提出了軟件體系結構的如下模型:

軟件架構=元素、形式旦委、基本原理 (Elements, Form, Rationale)

也就是說奇徒，軟件體系結構是一組具有特定形式的體系結構(或者，如果您愿意缨硝，也可以稱為設計)元素摩钙。

我們區(qū)分了三種不同類型的架構元素:

• 處理元素
• 數(shù)據(jù)元素
• 連接元素

處理元素是那些支持對數(shù)據(jù)元素進行轉換的組件;
數(shù)據(jù)元素是那些包含使用和轉換的信息的元素;
連接的元素(有時可能是處理元素，也可能是數(shù)據(jù)元素查辩，或者兩者兼而有之)是將體系結構的不同部分粘合在一起的粘合劑胖笛。
例如，過程調用宜岛、共享數(shù)據(jù)和消息是連接用于將“體系結構元素”粘合在一起的元素的不同示例长踊。

以水球為例，它隱喻了不同類別的元素:游泳者是處理元素萍倡，球是數(shù)據(jù)元素身弊，水是主要的連接元素(粘合劑)。進一步考慮水球遣铝、馬球和足球的相似之處佑刷。它們都有一個類似的\架構“但是在\膠水中有差別”------也就是說，它們具有相似的元素酿炸、形狀和形式瘫絮，但迪爾主要是在它們所處的環(huán)境中，以及在元素連接在一起的方式中發(fā)揮作用填硕。下面我們將看到麦萤，這些連接的元素在區(qū)分一個建筑與另一個建筑的過程中發(fā)揮著基礎性的作用鹿鳖，并可能對一個特殊建筑或建筑風格的特征產(chǎn)生重要影響。

建筑形式由加權屬性和關系組成壮莹。權重表示兩種情況之一:要么是屬性的重要性翅帜，要么是關系的重要性，要么是在備選方案中進行選擇的必要性命满，其中一些方案可能比其他方案更受青睞涝滴。使用加權來表示重要性，使架構師能夠區(qū)分“承重”和“裝飾”的形式方面;使用權重來指示可選方案使架構師能夠約束選擇胶台，同時為必須滿足和實現(xiàn)體系結構的設計人員提供一定程度的自由度歼疮。

屬性用于約束存檔結構元素|的選擇，也就是說诈唬，屬性用于將對元素的約束去除到架構師希望的程度韩脏。除非另有說明，否則屬性不受所需的最小約束-----也就是說铸磅，對于屬性所定義的約束赡矢，默認情況是:“架構師沒有約束的東西可以采用設計者或實現(xiàn)者希望的任何形式”。

關系用于約束架構元素的“位置”也就是說阅仔，它們限制了不同元素如何交互吹散，以及它們如何在體系結構中相互組織。與屬性一樣霎槐，關系不受所需的最小約束送浊，除非另有說明。

架構的一個基礎的丘跌、但完整的部分是在定義架構時所做的各種選擇的基本原理袭景。基本原理捕獲了選擇體系結構風格闭树、元素和表單的動機耸棒。在建筑建筑學中，基本原理解釋了激勵建筑師的潛在哲學美學报辱。在軟件體系結構中与殃，基本原理是解釋系統(tǒng)約束的滿足程度。這些約束由基本功能方面到各種非功能方面的考慮決定碍现，如經(jīng)濟[4]幅疼、性能[2]和可靠性[13]。

3.2 架構風格

如果說建筑是一種形式化的組織昼接，那么建筑風格就是從各種具體的建筑中抽象出元素和形式化的方面爽篷。與特定的體系結構相比，體系結構風格的約束更少慢睡，也更不完整逐工。例如铡溪，我們可以討論分布式樣式或多進程樣式。在這些情況下泪喊，我們只關注特定體系結構的某些方面:處理元素和硬件處理器之間的關系棕硫，以及元素上的約束。

考慮到這種對架構和架構風格的定義袒啼，在架構風格停止的地方和架構開始的地方之間并沒有嚴格的分界線哈扮。我們有一個連續(xù)體，其中一個人的建筑可能是另一個人的建筑風格蚓再。它是架構還是樣式在某種意義上取決于使用灶泵。例如，我們在2.3節(jié)中建議將架構樣式用作架構上的約束对途。假設我們希望架構規(guī)格僅受架構師所希望的級別的約束，那么很容易發(fā)生的情況是髓棋，一個人的架構可能比另一個人的架構風格受到的約束要少实檀。

架構風格的重要之處在于，它封裝了關于架構元素的重要決策按声，并強調了對元素及其關系的重要約束膳犹。風格的有用之處在于，我們可以使用它來約束體系結構和協(xié)調協(xié)作的架構師签则。此外须床，風格體現(xiàn)了那些有助于侵蝕和漂移的決策。強調風格作為對體系結構的約束提供了對體系結構某些方面的可見性渐裂，以便這些方面的違反和對它們的不敏感將更加明顯豺旬。

3.3 處理/數(shù)據(jù)/連接器相互依存(process/data/connector interdependence)

如上所述，來自建筑體系結構的一個重要觀點是多視圖柒凉。軟件架構中的三個重要視圖是處理視圖族阅、數(shù)據(jù)視圖和連接視圖。我們注意到膝捞，如果提供了體系結構的流程視圖坦刀，則結果的重點是處理元素的數(shù)據(jù)流，以及處理元素之間相對于數(shù)據(jù)元素的連接的某些方面蔬咬。相反鲤遥，如果提供了體系結構的數(shù)據(jù)視圖，則結果的重點放在處理流上林艘，但不像在流程視圖中那樣側重于連接元素盖奈。雖然目前的共識似乎強調面向對象(即面向數(shù)據(jù))的方法，但我們認為所有這三個視圖在體系結構級別上都是必要和有用的北启。

我們非正式地認為卜朗，有一個進程和數(shù)據(jù)相互依存:

• 有一些屬性可以區(qū)分數(shù)據(jù)的一種狀態(tài)和另一種狀態(tài);
• 這些特性是由某些處理元素產(chǎn)生的某些轉換的結果拔第。

因此，這兩種觀點是相互交織的——至少在數(shù)據(jù)和處理的一些重要特征上场钉，它們相互依賴蚊俺。(有關流程和數(shù)據(jù)相互依賴的更一般討論，請參見[10]逛万。)

處理和數(shù)據(jù)在連接上的相互依賴關系更加明顯:連接元素是在處理器之間移動數(shù)據(jù)的機制泳猬。由于數(shù)據(jù)上的這種活動，連接的元素必然具有數(shù)據(jù)元素所需的某些屬性宇植，其方式與處理元素具有數(shù)據(jù)元素所需的某些屬性完全相同得封。

在架構層，我們需要所有三個視圖指郁，以及在它們之間自由輕松移動的能力忙上。下一節(jié)中的示例將說明這種相互依賴關系，以及如何提供三個不同但重疊的視圖闲坎。

4.例子

獲得廣泛接受的為數(shù)不多的軟件體系結構樣式之一是多相編譯器疫粥。實際上，這是所有軟件工程師都應該接受過培訓的惟一風格腰懂。我們依靠這種熟悉程度來說明我們對軟件架構及其描述所獲得的一些見解梗逮。

在這一節(jié)中，我們來看兩種多相風格的編譯器架構:

• a compiler that is organized sequentially;
  按順序組織的編譯器;
• a compiler that is organized as a set of parallel pro-cesses connected by means of a shared internal rep-resentation.
  一種編譯器绣溜，由一組并行進程組成慷彤，這些進程通過共享的內部表示連接在一起。

由于篇幅限制和表示目的怖喻，我們的示例有些簡單和理想化底哗，忽略了許多細節(jié)。此外锚沸，我們使用現(xiàn)有的表示法艘虎，因為它們便于說明;關于特殊建筑符號的建議超出了本文的范圍。在每種情況下咒吐，我們都將重點放在從該特定示例派生出來的最有趣的架構考慮事項上野建。(當然，還存在其他多階段編譯器體系結構的例子恬叹，我們不主張對該體系結構的全面覆蓋候生。)在研究這些示例之前，我們簡要回顧一下它們的常見架構風格绽昼。

4.1多階段架構風格（the mulit-phase architectural style）

我們的編譯器簡化模型分為五個階段:詞法分析唯鸭、語法分析、語義分析硅确、優(yōu)化和代碼生成目溉。

詞法分析作用于源文本中的字符明肮，以產(chǎn)生用于語法分析的令牌。

句法分析產(chǎn)生的短語要么是修飾性短語缭付，要么是使用性短語柿估。

語義分析將使用短語與刪除短語關聯(lián)起來——程序元素(如標識符)的每次使用都與該元素的刪除相關聯(lián)，從而產(chǎn)生相關的短語陷猫。

優(yōu)化會對相關短語產(chǎn)生注釋秫舌，這些短語是在生成目標代碼時使用的提示。

優(yōu)化階段被認為是這種風格的首選方面绣檬，但不是必需的足陨。因此，多階段風格識別以下架構元素:

processing elements:
lexer, parser, semantor, optimizer, and code generator;
處理元素:
詞法分析程序娇未、解析器墨缘、語義器、優(yōu)化器和代碼生成器;

data elements:
characters, tokens, phrases,
correlated phrases, annotated
phrases, and object code.
數(shù)據(jù)元素:
人物,令牌,短語,
相關的短語,注釋
短語和目標代碼零抬。

注意飒房，我們還沒有形成連接元素。簡單地說媚值，這種樣式并沒有規(guī)定要使用哪些連接元素。當然护糖，連接元素的選擇對最終的架構有深遠的影響褥芒，如下所示。

建筑風格的形式是通過加權屬性和檔案結構元素之間的關系來表達的嫡良。例如锰扶，優(yōu)化器和沒有標記的短語必須一起找到，但是它們都是首選元素寝受，沒有必要坷牛。另一個例子是，組成程序文本的字符很澄、lexer生成的令牌和解析器生成的短語之間存在線性關系京闰。具體來說，令牌由一系列字符組成甩苛，短語由一系列to-kens組成蹂楣。然而，短語與相關短語之間存在非線性關系讯蒲。這些關系如圖1所示痊土。作為一個nal示例，每個處理元素都有一組屬性墨林，這些屬性消除了對這些元素的約束赁酝。例如犯祠，lexer將表示程序文本的字符作為輸入，并生成一系列令牌作為輸出酌呆。此外衡载，令牌和字符之間存在必須由lexer保存的順序對應關系。一個好的架構描述將捕獲這些以及其他此類屬性和關系肪笋。

讓我們通過形式化地描述字符和令牌之間的關系以及描述lexer的順序保存屬性來說明這一點月劈。我們從一個用序列和不相交子序列表示的數(shù)據(jù)視圖開始描述。

image.png

image.png

image.png

從處理的角度來看藤乙，lexer現(xiàn)在被限制接受字符C序列猜揪，生成令牌T序列，并保持字符與令牌之間的順序對應關系:

image.png

最后坛梁，值得注意的是連接器視圖顯示了應該放在體系結構樣式上的其他約束而姐。這些約束可以通過lexer和解析器之間的連接來說明。特別是划咐，連接元素必須確保為解析器保留lexer生成的令牌拴念，以便順序保持完整，并且沒有丟失褐缠、重復或虛假的添加政鼠。

4.2 連續(xù)的體系結構 Sequential Architecture

如果有一個“經(jīng)典的”多階段編譯器體系結構，那么它就是一個順序的體系結構队魏，在這個體系結構中公般，每個階段在下一個階段開始之前完成其功能，在這個體系結構中胡桨，數(shù)據(jù)元素直接從一個處理元素傳遞到另一個處理元素官帘。因此，我們添加了以下架構元素來描述整體風格:

image.png

此外昧谊，我們還使用了令牌來將標識符令牌的結構包含到一個名稱表(NT)中刽虹，并對短語進行了優(yōu)化，以便將其組織到一個抽象語法樹(AST)中呢诬。短語之間的相關性會導致抽象語法圖(ASG)和帶注釋的抽象語法圖(AASG)中的優(yōu)化涌哲。圖2給出了順序體系結構的處理視圖，顯示了通過系統(tǒng)的數(shù)據(jù)流尚镰。注意膛虫，從semantor到代碼生成器有兩條路徑，只有一條路徑通過優(yōu)化器钓猬。這反映了在此體系結構中不需要單獨的優(yōu)化階段這一事實稍刀。也就是說，滿足此體系結構的設計不需要提供優(yōu)化器。

為了說明處理和數(shù)據(jù)視圖之間的相互依賴關系账月，讓我們將正在創(chuàng)建和轉換的數(shù)據(jù)作為一個整體來考慮综膀。我們發(fā)現(xiàn)，數(shù)據(jù)視圖最好由我們稱為面向應用程序的屬性的概念來捕獲局齿。面向應用程序的屬性描述數(shù)據(jù)結構的狀態(tài)剧劝，這些狀態(tài)對于操作該結構的處理元素非常重要。它們可以用于控制處理順序抓歼，幫助消除數(shù)據(jù)結構上處理元素的影響讥此，甚至幫助消除處理元素實現(xiàn)這些影響所需的操作。
對于本例谣妻，(簡化)面向應用程序的屬性如下:

image.png

image.png

再次注意萄喳，最后一個屬性是首選的。雖然在本例中蹋半，面向應用程序的屬性可能看起來很明顯他巨，而且?guī)缀醪恢匾窃谙乱粋€示例中减江，它們對于體系結構的描述以及確保設計和實現(xiàn)與該體系結構的一致性至關重要染突。

需要考慮的一個有趣問題是，為什么我們選擇使用基于屬性的方案來描述體系結構元素辈灼，而不是使用基于類型的方案份企。原因是這種模式,因為它們目前存在,本質上是只能夠描述元素和應用方面的一個應用到另一個之間的關系(例如,子類型化和in-heritance[12]),在那個特定的元素與其他元素的關系(例如,奧羅斯[18]),和可以執(zhí)行的操作的元素。它們不適合描述元素的特征巡莹，比如上面提到的面向應用程序的屬性司志。例如，僅僅知道有一個與抽象語法圖相關聯(lián)的操作來將一個短語連接到另一個短語榕莺，并不能理解抽象語法圖必須在代碼生成器能夠訪問該圖之前將所有短語關聯(lián)起來。

另一方面棵介，基于屬性的方案可以很容易地捕獲所有這些特征;元素的一個屬性可以是與其關聯(lián)的操作集钉鸯。在這方面考慮增強類型模型似乎是合理的，我們認為這是未來工作中一個潛在的有趣領域邮辽。但是唠雕，我們注意到，如第2節(jié)所述吨述，基于類型的方案已經(jīng)在設計級別適當?shù)厥褂醚艺觥４送猓覀冏⒁獾酱г疲嫦驊贸绦虻膶傩蕴峁┝艘粋€很好的工具捕儒，用于驅動元素類型的一組操作的設計，或證明其適用性。

回到處理和數(shù)據(jù)視圖之間的相互依賴關系刘莹，我們可以看到數(shù)據(jù)視圖集中于描述每個數(shù)據(jù)結構時重要的特定面向應用程序的屬性阎毅，而處理視圖集中于每個處理元素的功能屬性。這些觀點實際上是互補的点弯。事實上扇调，如果我們描述數(shù)據(jù)視圖(如圖3所示)，并將其與圖2所示的processing視圖進行比較抢肛，那么對應關系就變得相當明顯狼钮。

從這個例子中得出的重要架構考慮可以總結如下:

• 表單描述必須包含元素之間的關系和約束，包括相對權重和首選項;
• 目前基于類型的元素表征方案是不充分的;
• 處理和數(shù)據(jù)視圖之間存在一種自然的相互依賴關系捡絮，可以提供對體系結構的補充描述熬芜。

image.png

4.3 并行處理，共享數(shù)據(jù)結構架構 Parallel Process, shared data structure architecture

假設性能是最重要的锦援，比如希望盡可能優(yōu)化編譯器的速度猛蔽。一種可能的解決方案是采用一種體系結構，該體系結構將處理元素視為由共享內部表示驅動的獨立進程——也就是說灵寺，連接的元素是共享表示曼库，每個處理元素執(zhí)行即時評估。圖4描述了該體系結構的pld和部分流程視圖略板，顯示了內部表示與lexer毁枯、解析器和語義器之間的關系。(在本例的其余部分中叮称，我們只考慮這三個處理元素种玛。)

該體系結構中共享內部表示的面向應用程序的屬性要比前一個示例中給出的屬性復雜得多，也有趣得多瓤檐。特別是赂韵，一些處理元素正在檢查內部表示的狀態(tài)，并且是同時進行的挠蛉。這意味著面向應用程序的屬性必須提供處理元素之間的協(xié)調和同步祭示。我們首先給出內部表示可能顯示的基本屬性:

請注意，這些屬性暗示使用了令牌和短語谴古，但是相關短語是累積的(請考慮“has-phrase”與“have-correlate -phrase”)质涛。

由于處理元素的并行行為，必須顯式地描述各種基本屬性之間的相互關系掰担。存在許多適合進行此類描述的表示法汇陆，包括并行路徑表達式[6]、約束表達式[1]和petri網(wǎng)[16]带饱。在這個例子中毡代，我們使用并行路徑表達式，其中逗號表示序列，加號表示一個或多個重復月趟，星號表示零或多個重復灯蝴，子表達式用括號括起來。同步點發(fā)生在面向應用程序的屬性名稱在不同的并行路徑表達式中相同的地方孝宗。首先穷躁，給出了每個數(shù)據(jù)元素——令牌、短語和相關短語——的路徑表達式:

image.png

因此因妇，令牌被用來生成短語问潭，短語之間相互關聯(lián)，直到它們都被處理完婚被。

到目前為止狡忙，我們給出的基本上是一個連接器視圖(在本例中，也就是一個數(shù)據(jù)視圖)址芯。將注意力集中在processing視圖上灾茁，我們可以描述每個處理元素如何轉換內部表示，以及這些處理元素如何同步:

image.png

一個有趣的問題是這個體系結構如何與前一個體系結構相關聯(lián)谷炸。事實上北专，將類似架構關聯(lián)起來的能力是軟件過程的一個重要方面;一個例子是“競爭性”架構的評估。當然旬陡，具有共同風格的架構捕獲了關系的某些部分拓颓。但是，如果使用面向應用程序的屬性描孟，還可以說得更多驶睦。特別是，我們可以在不同的體系結構的屬性之間畫出相關性匿醒。下表顯示了其中的一些相關性场航。

image.png

在這種情況下，相關性表示處理的共同點廉羔，例如溉痢，可以更好地理解處理元素的可重用性。

這個例子的要點可以總結為:

• 處理元素與前一架構基本相同蜜另，但具有不同的“控制點”屬性;
• 該體系結構的形式比前一種更復雜——有更多面向應用的屬性适室，這些屬性需要更豐富的表示法來表示它們及其相互關系;
• 我們仍然從處理/數(shù)據(jù)/連接器視圖的相互依賴中獲益嫡意，盡管更加復雜;
• 面向應用程序的屬性在關聯(lián)類似的體系結構時很有用举瑰。

5.從軟件架構中獲得的一些好處

我們之前已經(jīng)提到了在需求和設計的上下文中軟件架構的使用。軟件體系結構提供了滿足系統(tǒng)需求的框架蔬螟，為系統(tǒng)的設計和實現(xiàn)提供了技術和管理依據(jù)此迅。我們還希望詳細討論兩個好處:軟件體系結構規(guī)范將使我們能夠執(zhí)行的分析類型和我們從軟件體系結構方法中獲得的重用類型。

5.1軟件架構與分析

除了提供清晰和精確的文檔外休讳，規(guī)范的主要目的是提供文檔的自動分析葱蝗，并暴露各種各樣的問題，否則這些問題將無法檢測到轰异。我們希望執(zhí)行的分析主要有兩類:一致性和依賴性分析坎怪。一致性發(fā)生在幾個方面:體系結構和體系結構風格中的一致性罢坝、體系結構與需求的一致性以及設計與體系結構的一致性。就像Inscape[14]規(guī)范地自動管理接口規(guī)范和實現(xiàn)之間的相互依賴一樣搅窿，我們也希望能夠管理需求嘁酿、體系結構和設計之間的相互依賴。

因此男应，我們希望至少提供和支持以下類型的分析:

• 架構風格約束的一致性;
• 架構風格滿意度研究
• 架構約束的一致性;
• 設計對架構的滿意度;
• 架構與設計闹司、架構與需求之間依賴關系的建立;
• 確定體系結構或體系結構風格變化對設計和需求的影響，反之亦然沐飘。

5.2架構及使用和重用的問題

提高設計人員和程序員生產(chǎn)力的一個重要方面是能夠建立在其他人的努力之上——也就是說游桩，使用和重用組件，不管它們是作為另一個系統(tǒng)的一部分還是作為標準組件目錄的一部分耐朴。

構件的可重用性問題一直受到人們的關注借卧。找到組件對于減少系統(tǒng)中工作和代碼的重復可能很重要，但它不是有效使用標準化組件的主要問題隔箍。例如谓娃，在數(shù)學庫中查找組件不是問題。主要問題是理解庫中包含的概念蜒滩。如果理解了這些組件滨达，通常就可以在庫中找到要使用的適當組件。如果它們不被理解俯艰，那么瀏覽只會在獲得適當概念的同時有所幫助捡遍。

體系結構中的主要焦點是重要屬性和關系的一致性——對體系結構、設計和系統(tǒng)實現(xiàn)所需的組件類型的約束竹握』辏考慮到這是使用和重用的基礎，架構師啦辐、設計人員或實現(xiàn)人員可能能夠選擇適當?shù)捏w系結構元素谓传、設計元素或實現(xiàn)的代碼，以滿足適當級別的特定約束芹关。

此外续挟，可以將以前實現(xiàn)的軟件的各個部分分開，從中選擇有用的部分侥衬。例如诗祸，來自另一個系統(tǒng)的組件的設計可能具有剛好滿足特定體系結構元素的體系結構約束跑芳，但是實現(xiàn)受到約束，以便與其他系統(tǒng)約束相結合直颅。解決方案是使用設計而不是實現(xiàn)博个。只有識別體系結構、設計和實現(xiàn)約束功偿，并使用它們來滿足體系結構盆佣、設計和實現(xiàn)的期望目標，這才可能實現(xiàn)械荷。

重用組件的重要經(jīng)驗是罪塔，當組件的規(guī)范在體系結構級別受到的約束最少時，重用的可能性最大养葵。實現(xiàn)級的組件重用通常太晚征堪，因為實現(xiàn)元素常常包含太多約束。此外关拒，在體系結構級別上考慮重用可能會導致開發(fā)走上一條不同的佃蚜、同樣有效的解決方案之路，但這條路會導致更大的重用着绊。

6結論

在過去的幾年里谐算，我們一直致力于改進與大型、復雜的軟件系統(tǒng)相關聯(lián)的軟件過程归露。我們已經(jīng)開始相信軟件架構可以在這個過程中扮演重要的角色洲脂，但是它既沒有得到充分利用，也沒有得到充分開發(fā)剧包。我們已經(jīng)開始通過建立對軟件體系結構和體系結構風格的直覺和上下文來解決這種情況恐锦。我們已經(jīng)制定了一個軟件體系結構模型，它強調數(shù)據(jù)疆液、處理和連接的體系結構元素一铅，突出它們的關系和屬性，并捕獲對它們的實現(xiàn)或滿足的約束堕油。此外潘飘，我們已經(jīng)開始描述架構描述技術及其支持基礎設施的必要特征。在這樣做的過程中掉缺，我們?yōu)槲磥淼难芯看_定了一個方向卜录，該方向應該確立軟件架構的首要地位。

其他人已經(jīng)開始關注軟件架構眶明。三個最相關的是Schwanke等人艰毒、zachman和Shaw。

Schwanke等人將架構定義為組件之間允許或允許的連接集赘来。我們同意架構的這個方面很重要现喳，但是我們認為架構不僅僅是組件和連接，正如我們在本文中演示的那樣犬辰。

Zachman[23]使用構建體系結構的隱喻來構建信息系統(tǒng)的體系結構嗦篱。他利用了不同體系結構文檔的概念，提供了構建信息系統(tǒng)中各種文檔應該是什么的視圖幌缝。架構師是用戶和系統(tǒng)構建者之間的中介灸促。各種文檔提供的各種視圖的不同部分產(chǎn)品- - - - - -用戶視圖中,承包商的觀點,等等。他的工作與我們的不同之處在于,他提出一個具體的建筑為一個特定的應用領域,而我們正試圖定義學科的哲學基礎,以確定的符號表達各種架構文檔的規(guī)范,并決定如何使用這些文檔在自動化方面涵卵。

Shaw[21]是最接近我們的浴栽。她采用編程語言設計器的觀點，從各種系統(tǒng)中抽象組件類轿偎、組合方法和模式典鸡。這在某種程度上與我們分別對處理和數(shù)據(jù)元素、連接元素和體系結構樣式的概念相對應坏晦。我們的工作與Shaw的工作的一個主要區(qū)別是萝玷，她采用了傳統(tǒng)的基于類型的方法來描述架構，而我們采用了更具表現(xiàn)力的基于屬性的方法昆婿。我們的方法似乎能夠更好地更直接地捕捉加權屬性和關系的概念球碉。Shaw將現(xiàn)有體系結構的各種屬性和關系抽象出來，并將它們包含在一組組件和組合類型中仓蛆，這種方法顯得相當有限睁冬。事實上，她正在尋求提供一組有用的架構元素看疙，可以將它們混合和匹配來創(chuàng)建架構豆拨。Shaw的方法顯然是一個重要而有用的方法，它在促進對基本和重要的建筑概念的理解方面起了很大的作用能庆。另一方面辽装，我們的方法強調了底層屬性和關系的重要性，它們是一種更通用的機制相味，可以用來描述元素和組合的特定類型拾积，從而提供了一個選擇范圍。

綜上所述丰涉，我們經(jīng)過以下推測:
也許軟件系統(tǒng)的開發(fā)和演進如此緩慢的原因是我們培訓了木匠和承包商（trainedcarpenters and contractors）拓巧，而沒有培訓架構師。