1995年,Philippe Kruchten在《IEEE Software》上發表了題爲《The 4+1 View Model of Architecture》的論文,引發了業界的極大關注。ios
論文原文:http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf架構
翻譯:http://www.ibm.com/developerworks/cn/rational/r-4p1-view/併發
咱們已經看到在許多文章和書籍中,做者欲使用單張視圖來捕捉全部的系統架構要點。經過仔細地觀察這些圖例中的方框和箭頭,不難發現做者努力地在單一視圖中表達超過其表達限度的藍圖。方框是表明運行的程序嗎?或者是表明源代碼的程序塊嗎?或是物理計算機嗎?或僅僅是邏輯功能的分組嗎?箭頭是表示編譯時的依賴關係嗎?或者是控制流嗎?或是數據流嗎?一般它表明了許多事物。是否架構只須要單個的架構樣式?有時軟件架構的缺陷源於過早地劃分軟件或過度的強調軟件開發的單個方面:數據工程、運行效率、開發策略和團隊組織等。有時架構並不能解決全部"客戶"(或者說"風險承擔人",USC 的命名)所關注的問題。許多做者都說起了這個問題:Garlan & Shaw 1、CMU 的 Abowd & Allen、SEI 的 Clements。做爲補充,咱們建議使用多個併發的視圖來組織軟件架構的描述,每一個視圖僅用來描述一個特定的所關注的方面的集合。分佈式
軟件架構用來處理軟件高層次結構的設計和實施。它以精心選擇的形式將若干結構元素進行裝配,從而知足系統主要功能和性能需求,並知足其餘非功能性需求,如可靠性、可伸縮性、可移植性和可用性。Perry 和 Wolfe 使用一個精確的公式來表達,該公式由 Boehm 作了進一步修改:性能
軟件架構 = {元素,形式,關係/約束}spa
軟件架構涉及到抽象、分解和組合、風格和美學。咱們用由多個視圖或視角組成的模型來描述它。爲了最終處理大型的、富有挑戰性的架構,該模型包含五個主要的視圖(請對照圖 1):翻譯
架構的描述,即所作的各類決定,能夠圍繞着這四個視圖來組織,而後由一些用例 (use cases)或場景(scenarios)來講明,從而造成了第五個視圖。正如將看到的,實際上軟件架構部分從這些場景演進而來,將在下文中討論。設計
後來,Philippe Kruchten加入Rational,他的4+1視圖方法演變爲著名的、爲許多架構師所熟知的「RUP 4+1視圖方法」(以下圖所示)。對象