卡內(nèi)基梅隆大學(xué)軟件研究所關(guān)于軟件架構(gòu)的定義[5]

問題
　　多個(gè)問題解決顧問（知識(shí)顧問）必須通過協(xié)作來解決他們無法單獨(dú)解決的問題。各顧問的工作結(jié)果必須可以供所有其他顧問訪問，使他們可以評估自己是否可以參與解決方案的查找并發(fā)布其工作結(jié)果。 
　　影響
　　知識(shí)顧問參與解決問題的順序不是確定的，這可能取決于問題解決策略不同顧問的輸入（結(jié)果或部分解決方案）可能有不同的表示方式各顧問并不直接知道對方的存在，但可以評估對方發(fā)布的工作
　　解決辦法
　　多名知識(shí)顧問都可訪問一個(gè)稱為“黑板”的共享數(shù)據(jù)庫。黑板提供監(jiān)測和更新其內(nèi)容的接口�？刂颇�塊/對象激活遵循某種策略的顧問。激活后，顧問查看黑板，以確定它是否能參與解決問題。如果顧問決定它可以參與，控制對象就可以允許顧問將其部分（或最終）解決方案放置于黑板上。
　　示例：

　　
　　
　　以上顯示了使用 UML 建模的結(jié)構(gòu)或靜態(tài)視圖。 它將成為參數(shù)化協(xié)作的一部分，然后會(huì)綁定到實(shí)參上對模式進(jìn)行實(shí)例化。 mda.com  

　　構(gòu)架風(fēng)格 
　　軟件構(gòu)架（或僅是構(gòu)架視圖）可以具有名為構(gòu)架風(fēng)格的屬性，該屬性減少了可選的形式，并使構(gòu)架具有一定程度的一致性。樣式可以通過一組模式或通過選擇特定構(gòu)件或連接器作為基本構(gòu)件來定義。對給定系統(tǒng)，某些樣式可作為構(gòu)架描述的一部分記錄在構(gòu)架風(fēng)格指南（Rational Unified Process 中設(shè)計(jì)指南文檔的一部分）中。樣式在構(gòu)架的可理解性與完整性方面起著主要的作用。

　　構(gòu)架設(shè)計(jì)圖 
　　構(gòu)架視圖的圖形描述稱為構(gòu)架設(shè)計(jì)圖。對于以上描述的各種視圖，設(shè)計(jì)圖由以下統(tǒng)一建模語言圖組成 [UML99]： 

　　邏輯視類圖、狀態(tài)機(jī)和對象圖。 
　　進(jìn)程視類圖與對象圖（包括任務(wù) - 進(jìn)程與線程）。 
　　實(shí)施視構(gòu)件圖。 
　　部署視配置圖。 
　　用例視用例圖描述用例、主角和普通設(shè)計(jì)類；順序圖描述設(shè)計(jì)對象及其協(xié)作關(guān)系。 
　　構(gòu)架設(shè)計(jì)流程 
　　在 Rational Unified Process 中，構(gòu)架主要是分析設(shè)計(jì)工作流程的結(jié)果。當(dāng)項(xiàng)目再次進(jìn)行此工作流程時(shí)，構(gòu)架將在一次又一次迭代中不斷演化、改進(jìn)、精煉。由于每次迭代都包括集成和測試，所以在交付產(chǎn)品時(shí)，構(gòu)架就相當(dāng)強(qiáng)壯了。構(gòu)架是精化階段各次迭代的重點(diǎn)，構(gòu)架的基線通常會(huì)在此階段結(jié)束時(shí)確定。

　　架構(gòu)師
　　軟體設(shè)計(jì)師中有一些技術(shù)水平較高、經(jīng)驗(yàn)較為豐富的人，他們需要承擔(dān)軟件系統(tǒng)的架構(gòu)設(shè)計(jì)，也就是需要設(shè)計(jì)系統(tǒng)的元件如何劃分、元件之間如何發(fā)生相互作用，以及系統(tǒng)中邏輯的、物理的、系統(tǒng)的重要決定的作出。

　　這樣的人就是所謂的架構(gòu)師（Architect）。在很多公司中，架構(gòu)師不是一個(gè)專門的和正式的職務(wù)。通常在一個(gè)開發(fā)小組中，最有經(jīng)驗(yàn)的程序員會(huì)負(fù)責(zé)一些架構(gòu)方面的工作。在一個(gè)部門中，最有經(jīng)驗(yàn)的項(xiàng)目經(jīng)理會(huì)負(fù)責(zé)一些架構(gòu)方面的工作。

　　但是，越來越多的公司體認(rèn)到架構(gòu)工作的重要性，并且在不同的組織層次上設(shè)置專門的架構(gòu)師位置，由他們負(fù)責(zé)不同層次上的邏輯架構(gòu)、物理架構(gòu)、系統(tǒng)架構(gòu)的設(shè)計(jì)、配置、維護(hù)等工作。