第8章架構建模第8章架構建模第8章架構建模第8章架構建模2本章主要內(nèi)容：架構是什么邏輯架構物理架構架構模式模型驅動的架構第8章架構建模第8章架構建模2本章主要內(nèi)容：8.1導言第8章架構建模3在這一章里，將學習如何使用UML建立和可視化地描述幾種不同類型的架構模型。架構建模是UML當今最流行的應用領域之一。一個健壯的架構對一個成功的應用，特別是對長壽的應用系統(tǒng)和系統(tǒng)隨時間所經(jīng)歷的變更是至關重要的。架構建模為理解、交流和確認系統(tǒng)的架構設計提供了關鍵支持。8.1導言第8章架構建模3在這一章里，將學習如何使用U8.2什么是架構第8章架構建模4在同GradyBooch的一次談話中，他說：“每一個軟件都有一個架構(architecture)，不論這個架構是否有意的被開發(fā)”。教科書中對架構一詞的定義是：架構(architecture)：建筑作品或科學；特別指：設計和建造結構物尤其是可供人居住的結構物的作品和實踐。有意識建立的某種格式或結構物<花園的架構>。一個計算機或計算機系統(tǒng)的組織和集成方式。譯注：在很多文獻中architecture也被譯為“體系結構”或“構架”，現(xiàn)在更多的是使用“架構”一詞。8.2什么是架構第8章架構建模4在同GradyBoo第8章架構建模5一個架構描述了某物體的多個部分如何集成為一個整體。一架飛機有一個架構；人的身體都有一個架構，盡管這些架構的特征各不相同。如果準備建立起某種事物，描述它的架構是很有用途的。描述方式：或者通過文本形式描述，或者為這個事物的架構建立一個模型(參見下圖)。第8章架構建模5一個架構描述了某物體的多個部分如何集成為一第8章架構建模6我們所討論的架構，是指一個系統(tǒng)的結構。架構包括了業(yè)務規(guī)則、軟件，以及軟件如何與其他軟件通信。一個架構既可以包括一個組織內(nèi)的軟件也可以包括組織外的軟件。因為內(nèi)部系統(tǒng)可能需要與合伙人、顧客和賣方整合，所以系統(tǒng)的架構既要包括內(nèi)部系統(tǒng)也要包括外部系統(tǒng)。架構還可以包括運行軟件的硬件，甚至還可以包括系統(tǒng)的使用者以及關于系統(tǒng)如何使用的理解和描述。第8章架構建模6我們所討論的架構，是指一個系統(tǒng)的結構。8.3為什么對架構建模第8章架構建模7軟件和系統(tǒng)架構的建模有著非常重要的價值。它幫助理解系統(tǒng)是如何被開發(fā)和建造的。軟件由許多小的單元組成，這些單元通常被稱作構件(component)。構件之間存在接口，共同執(zhí)行業(yè)務邏輯，并且時常要在彼此之間交換數(shù)據(jù)。理解了架構的功能和跨越系統(tǒng)邊界的依賴關系，就可以幫助理解軟件開發(fā)過程和設計出更好的系統(tǒng)。通過對架構建模，可以為其他人提供一個良好的通信機制，為系統(tǒng)開發(fā)提供不同的時間基線，理解系統(tǒng)與其他系統(tǒng)或組織之間的依賴關系，合理地分配開發(fā)工作量，找出設計缺陷和不良的設計模式，等等。8.3為什么對架構建模第8章架構建模7軟件和系統(tǒng)架構的第8章架構建模8軟件系統(tǒng)架構的可視化建模同樣具有許多優(yōu)點。一個可視化的模型能夠讓開發(fā)者在系統(tǒng)的物理實現(xiàn)之前直接觀察所計劃要建立的系統(tǒng)結構?？梢暬哪Ｐ瓦€可以使開發(fā)者更好地理解系統(tǒng)開發(fā)計劃，并通過模型在不同人員之間交流系統(tǒng)的設計信息?？梢暬哪Ｐ吞峁┝艘环N觀察系統(tǒng)設計的方式，這樣的方式確保了系統(tǒng)的設計在系統(tǒng)的整體架構下的合理性。通常，系統(tǒng)設計人員只關注他負責的那部分系統(tǒng)的設計并且不了解系統(tǒng)的整體架構——他設計的構件必須與其他設計人員設計的構件組裝到一起從而形成完整的系統(tǒng)。UML可以在三個主要層次上建立軟件和系統(tǒng)的架構模型：企業(yè)級、系統(tǒng)級和軟件級。第8章架構建模8軟件系統(tǒng)架構的可視化建模同樣具有許多優(yōu)點。8.3.1企業(yè)架構第8章架構建模9企業(yè)架構(enterprisearchitecture)用于提供企業(yè)的高層視圖，包括業(yè)務過程、組織結構、系統(tǒng)(包括軟件和硬件)，和預期的對現(xiàn)存架構的演化。可以基于許多不同的架構框架建立企業(yè)架構，包括Zachman框架、美國聯(lián)邦政府企業(yè)架構框架(FEAF)、美國國防部企業(yè)框架(DoDAF)和其他組織和行業(yè)的特定框架。這些企業(yè)架構框架為企業(yè)建模者提供了一個標準的方法，用于建立企業(yè)架構，以確保跨越了組織邊界的業(yè)務和操作的一致性。8.3.1企業(yè)架構第8章架構建模9企業(yè)架構(enter第8章架構建模10現(xiàn)實世界——強制推行的企業(yè)架構美國聯(lián)邦政府在所有政府部門中強制推行它的企業(yè)架構，要求政府各部門使用這個架構來說明該部門是如何使用各種軟硬件，從業(yè)務的角度說明企業(yè)的運作。聯(lián)邦政府管理和預算辦公室(OMB)推行了一個標準的企業(yè)架構框架，稱為聯(lián)邦企業(yè)架構框架(FEAF)，并要求所有政府部門必須遵循。盡管這個框架規(guī)定了政府部門應該如何描述企業(yè)架構，包括有關的建模和丈檔標準，但是該框架仍然留給各部門對其進行進一步解釋的余地。因為FEAF只是一組參考模型，更準確地講，它是一組元模型(meta-model)，每個政府部門對它的解釋可以不同，但是必須遵循同一個企業(yè)架構的建造過程。立法部門的一個機構采用了聯(lián)邦政府管理和預算辦公室制定的FEAF標準，以改進部門間和部門內(nèi)各系統(tǒng)間的信息整合，減少重復勞動。為了確保各個部門確實采用了FEAF標準，如果某個部門不能證明它按照該標準建立企業(yè)架構，那么聯(lián)邦政府管理和預算辦公室將終止對該部門的財政預算。第8章架構建模10現(xiàn)實世界——強制推行的企業(yè)架構第8章架構建模11我們曾經(jīng)與美國政府某部門一同工作，用UML模型向美國國會展示該部門的企業(yè)架構，說明了該架構正在建造之中以及它的進展情況。使用這些UML模型，雙方可以就該部門內(nèi)的軟件應用和所要執(zhí)行的業(yè)務過程進行很好溝通。這樣，他們可以共同制訂出關于該部門未來幾年的現(xiàn)代化改造的切實可行的計劃。上面的事例證明，企業(yè)架構可以有效地記錄企業(yè)現(xiàn)在的狀態(tài)，幫助理解企業(yè)未來隨時間所經(jīng)歷的演化過程，提供了企業(yè)架構演化的計劃或藍圖。要確保企業(yè)架構的文檔是一個隨著時間不斷及時更新的文檔，這是非常重要的。企業(yè)架構的文檔不應該是一經(jīng)建立就從不改變的文檔。第8章架構建模11我們曾經(jīng)與美國政府某部門一同工作，用UM第8章架構建模12吸取教訓向其他人提供企業(yè)架構的視圖可以幫助保證組織間的互操作性。建立企業(yè)架構模型，可以幫助理解組織的內(nèi)部組成，包括軟件、硬件、業(yè)務過程和組織資源。企業(yè)架構必須是一個隨時間演化的文檔。它不能在建立之后就束之高擱，而是要隨著企業(yè)變化而及時更新。一個企業(yè)架構必須是模型和文檔的結合，這樣可以保證需要理解它的人能夠對其有全面的理解。第8章架構建模12吸取教訓8.3.2系統(tǒng)架構第8章架構建模13一般地說，一個系統(tǒng)是由多個運行于硬件上軟件程序或控制硬件執(zhí)行某種動作的軟件程序組成。例如，一架飛機就是一個大的硬件，其中運行著許多不同的軟件程序，用來控制飛機的動作。硬件和軟件的結合構成了完整的系統(tǒng)——飛機。DVD的制造者將許多不同的軟件單元和硬件單元組合在一起，使得各硬件單元能夠協(xié)同工作，共同組成了一個系統(tǒng)：DVD播放器。8.3.2系統(tǒng)架構第8章架構建模13一般地說，一個系統(tǒng)第8章架構建模14軟件架構通常只說明一個特定的軟件應用。系統(tǒng)架構說明了一個系統(tǒng)的所有部件。既包括軟件構件也包括硬件構件，并且可視化地顯示這些構件是如何協(xié)同工作的。系統(tǒng)架構是系統(tǒng)開發(fā)中要建立的最重要的架構模型之一。例如，一個心臟起搏器是由執(zhí)行不同動作的不同部件構成的，用于維持心臟的正常工作。每一個部件都由其中運行的軟件加以控制，系統(tǒng)的整體架構確保了這些部件之間的協(xié)同工作，執(zhí)行正確的動作。盡管每一個硬件構件都可以獨立工作，但同時它們也要依賴于心臟起搏器中的其他部件和控制硬件操作的軟件。對系統(tǒng)架構建模，可以保證硬件和軟件都能被理解，有助于保證系統(tǒng)設計的正確性，還有助于保證部件間的依賴關系得以被正確理解以及各部件間的有效協(xié)同工作。第8章架構建模14軟件架構通常只說明一個特定的軟件應用。8.3.3軟件架構第8章架構建模15一個軟件架構對軟件的預期實現(xiàn)提供了可視化表示。在設計軟件時，多個構件或者部件通常要通過接口聯(lián)系起來，共同組成完整的應用。通過對軟件架構建模，能夠可視化地說明這些不同的構件如何組成一個應用，數(shù)據(jù)和業(yè)務過程如何被這些構件共享。企業(yè)架構試圖直接反映業(yè)務需要，而軟件架構則是通過描述符合企業(yè)架構的軟件設計來間接地反映業(yè)務需要。軟件架構設計師可能使用業(yè)務模型來幫助他們決定如何設計軟件，但是業(yè)務模型設計通常不直接作為軟件架構的組成部分。8.3.3軟件架構第8章架構建模15一個軟件架構對軟件8.4邏輯架構第8章架構建模16一個架構可以具有的描述范圍(即：企業(yè)架構、系統(tǒng)架構和軟件架構)。架構也可以有不同的抽象層次，每個抽象層次包含了不同的架構細節(jié)。這里要介紹兩個抽象層次上的架構，即：邏輯架構和物理架構。邏輯架構是與系統(tǒng)的全部實現(xiàn)技術無關的架構。邏輯架構說明了架構的邏輯組成。邏輯架構并非為了展示軟件的實現(xiàn)，而是對軟件的一個抽象。對于軟件來說，邏輯架構一般用普通語言(非技術語言)描述。邏輯架構沒有經(jīng)過任何具體技術的優(yōu)化(獨立于實現(xiàn)軟件的技術)。負責設計軟件的邏輯架構的架構設計師一般由非軟件開發(fā)者擔任。8.4邏輯架構第8章架構建模16一個架構可以具有的描述第8章架構建模17這里對各種邏輯架構做一個對比說明。企業(yè)架構展示了企業(yè)的內(nèi)部運作和企業(yè)未來的發(fā)展方向。系統(tǒng)架構說明了如何開發(fā)系統(tǒng)以滿足業(yè)務需要。軟件邏輯架構描繪了系統(tǒng)中運行的軟件的結構。第8章架構建模17這里對各種邏輯架構做一個對比說明。8.4.1類圖第8章架構建模18使用UML，可以用類圖中的類設計邏輯架構。一個類的圖標是一個矩形方框，其中包含了三個水平的分割欄。第一欄是類名，它是類的邏輯描述，通常是一個名字。例如，類的名字可以是“Customer(顧客)”、“Employee(雇員)”和“Oder(訂單)”，如圖所示。8.4.1類圖第8章架構建模18使用UML，可以用類圖第8章架構建模19第二欄是類的屬性(attribute)，它用于描述類的不同特性。類的屬性進一步說明了這個類的細節(jié)。屬性本身還有更多的特性，用于描述屬性攜帶的數(shù)據(jù)類型。屬性類型在UML類的圖標中位于屬性名的右側，如圖所示。第8章架構建模19第二欄是類的屬性(attribute)，第8章架構建模20第三欄是類的操作(operation)。操作用于描述類的行為。操作定義了系統(tǒng)的執(zhí)行邏輯，既包括基本的邏輯也包括復雜的邏輯。第8章架構建模20第三欄是類的操作(operation)。第8章架構建模21在類圖中可以使用多種不同類型的關聯(lián)，它們展示了類之間或類與其他建模元素之間的關系。下圖簡單定義了各種不同類型的關聯(lián)。第8章架構建模21在類圖中可以使用多種不同類型的關聯(lián)，它們第8章架構建模22第8章架構建模22第8章架構建模23在圖中，角色名之前有一個加號“+”。在定義代碼時，加號說明了其后的角色是公有的。一個角色可以是公有的(public，用“+”號表示)、受保護的(protected，用“#”號表示)、私有的(private，用“-”號表示)，或者具體于實現(xiàn)的(implementation，不用專門的符號表示)。公有角色可以被所有需要該角色的模型元素訪問受保護的角色只能被屬于該角色的一部分的關聯(lián)或角色訪問私有角色只能通過其所屬的關聯(lián)的另一端的模型元素訪問具體于實現(xiàn)的角色能夠被實現(xiàn)該角色的包內(nèi)的所有元素訪問。第8章架構建模23在圖中，角色名之前有一個加號“+”。在定第8章架構建模24在邏輯架構模型的設計中，泛化可用于展示類的繼承層次關系。例如，一個“Employee”可以是“Fulltime(全職)”的，或“Part-time(兼職)”的。在定義一個Employee類時，可能想通過添加屬性來表明雇員的不同類型。但是對于非技術評閱者來說，用泛化關系來表示雇員的不同類型將使模型更加清晰，如下圖所示。圖中的繼承層次說明了全職雇員和兼職雇員都是雇員，它們都繼承了父類Employee的所有屬性和操作。第8章架構建模24在邏輯架構模型的設計中，泛化可用于展示類8.4.2系統(tǒng)和子系統(tǒng)第8章架構建模25構造型(stereotype)使用構造型，可以擴展UML以滿足你更具體的建模需要。構造型本身也是一個UML模型元素，它的作用是擴展已有的模型元素。用構造型擴展后的模型元素具有了擴展后的新特性。UML中，在一個模型元素中增加了構造型圖標“<<stereotype>>”后，該圖標就表示用注明的構造型擴展后的模型元素。8.4.2系統(tǒng)和子系統(tǒng)第8章架構建模25構造型(ste第8章架構建模26如下圖所示，系統(tǒng)(system)是一個用構造型“<<system>>”擴展的包。系統(tǒng)代表了屬于某一個特定項目的所有模型元素。在建立更詳細的模型時，還可以通過構造型“<<businesssystem>>”和“<<applicationsystem>>”對系統(tǒng)進一步分解。第8章架構建模26如下圖所示，系統(tǒng)(system)是一個用第8章架構建模27一個系統(tǒng)通?？梢员环纸鉃槎鄠€子系統(tǒng)(subsystem)。子系統(tǒng)，如同系統(tǒng)，是通過一個構造型“<<sybsystem>>”擴展的包。如下圖所示。一個子系統(tǒng)由整個系統(tǒng)中的一組模型元素構成。第8章架構建模27一個系統(tǒng)通?？梢员环纸鉃槎鄠€子系統(tǒng)(su第8章架構建模28因為系統(tǒng)和子系統(tǒng)是用構造型擴展了的包，因此它們具有包的一切性質，符合包的所有使用規(guī)則。這意味著系統(tǒng)和子系統(tǒng)內(nèi)的模型元素屬于代表系統(tǒng)或子系統(tǒng)的包而不屬于其他任何包。子系統(tǒng)為項目的劃分提供了手段。既然一個系統(tǒng)包含了多個子系統(tǒng)，那么子系統(tǒng)內(nèi)的所有元素也同樣屬于包含子系統(tǒng)的系統(tǒng)?？梢杂靡粋€圖來描繪系統(tǒng)的邏輯架構(見下圖)。第8章架構建模28因為系統(tǒng)和子系統(tǒng)是用構造型擴展了的包，因8.5物理架構第8章架構建模29架構可以分別在邏輯層和物理層描述。邏輯架構是一個較通用的架構，它較少地依賴技術細節(jié)。物理架構更詳細地描述軟件和系統(tǒng)的設計，包括架構中規(guī)定要采用的不同技術細節(jié)，還描述了軟件自身及軟件與其他軟件是如何集成的。8.5物理架構第8章架構建模29架構可以分別在邏輯層和8.5.1操作第8章架構建模30操作描述了與類的職責和類之間的交互有關的業(yè)務邏輯。例如，“getCustomer”是Customer類中的一個操作。這個操作描述了與如何查詢顧客信息有關的應用邏輯(見圖)。8.5.1操作第8章架構建模30操作描述了與類的職責和第8章架構建模31盡管類的所有成分最終都將被轉換為物理代碼并成為可運行的軟件應用，但是操作的具體細節(jié)是在系統(tǒng)和模型的物理實現(xiàn)時考慮的更具體的類成分。在邏輯架構模型中，操作用于說明軟件的預期行為，而在物理架構中操作定義了系統(tǒng)的物理實現(xiàn)中的算法、函數(shù)等技術細節(jié)。操作描述了系統(tǒng)的功能，以及系統(tǒng)在實現(xiàn)中要用到的技術。第8章架構建模31盡管類的所有成分最終都將被轉換為物理代碼8.5.2構件圖第8章架構建模32構件(component)由一個或多個類組成，它描述了一個應用的一部分，這些部分可以被組裝和重用?；跇嫾募軜?component-basedarchitecture，CBD)是一種系統(tǒng)設計方法，在這樣的系統(tǒng)設計方法中，一個系統(tǒng)由多個構件組裝而成。將系統(tǒng)分解為多個小的部分(構件)分別開發(fā)，這是提高開發(fā)效率的重要手段，開發(fā)出的小的部件可以被用來組裝成完整的系統(tǒng)。這種開發(fā)方法可以重用已經(jīng)開發(fā)好的軟件構件，而不是每次都要重新開發(fā)。8.5.2構件圖第8章架構建模32構件(compone第8章架構建模33基于構件的架構還可以讓不同的小組共同開發(fā)一個軟件，他們可以通過接口將各自開發(fā)的部分組裝起來。接口(interface)是一個命名了的操作集合，這些操作讓構件通過接口代碼一起協(xié)同工作。一個構件可以通過它的接口部署的特定技術和代碼向其他構件提供信息或者從其他構件獲取信息。圖中顯示了構件圖中的構件和接口的表示法。第8章架構建模33基于構件的架構還可以讓不同的小組共同開發(fā)第8章架構建模34接口用一個圓圈形狀的圖標表示，也可以用構造型“<<interface>>”擴展的類來表示。構件圖展示了系統(tǒng)中的構件和構件是如何被組裝的，下圖給出了一個構件圖的例子。第8章架構建模34接口用一個圓圈形狀的圖標表示，也可以用構第8章架構建模35可以使用構件圖對系統(tǒng)的不同部分單獨建立架構模型。還可以使用構件圖對應用的內(nèi)部細節(jié)建模。還可以用構件圖來說明不同的應用是如何協(xié)同工作的。舉一個例子，考慮兩個可執(zhí)行文件(．exe)，其中的一個可執(zhí)行文件調(diào)用了另一個，這兩個可執(zhí)行文件都可以被建模為構件。當編寫Java應用程序時，每個Java源代碼文件也可以用UML表示為一個構件。這個例子說明，架構的不同層次可以(事實上經(jīng)常是這么做的)被建模為構件。類代表了程序代碼的邏輯架構。構件代表了系統(tǒng)的物理架構，并標識出了需要被實際實現(xiàn)的物理單元。第8章架構建模35可以使用構件圖對系統(tǒng)的不同部分單獨建立架8.5.3部署圖第8章架構建模36部署圖描述系統(tǒng)的運行時架構。部署圖中可以包括節(jié)點，節(jié)點代表了一個硬件單元，其中通常內(nèi)置了存儲器和處理器。節(jié)點有兩種類型：處理器(Processor)和設備(Device)。有時，多個應用運行于一個設備中的不同處理器上，也可以通過部署圖描述。例如，一個硬件服務器通常都包含了多個處理器。服務器的部署圖可以展示出多個應用可以運行于同一個服務器中的不同處理器。下圖說明了部署圖中的節(jié)點表示法。8.5.3部署圖第8章架構建模36部署圖描述系統(tǒng)的運行8.5.4構造型第8章架構建模37在所有UML圖中都可以使用構造型，這樣可以更好地定義建模元素，讓每個人在看到模型后都能理解這個模型是對什么建模的，模型背后講述了什么故事。UML定義了一些標準構造型。一個構造型可以只是一個模型元素的標題，但是它也可是一個圖標，圖標可以更好地說明構造型的含義，并為UML模型中增加了易于理解的圖形視圖。部署圖中的幾種部署元素也可以圖標表示，例如各種類型的飛機和輪船(見下圖)。8.5.4構造型第8章架構建模37在所有UML圖中都可以使第8章架構建模38第8章架構建模38第8章架構建模39也可以在更傳統(tǒng)的意義上使用部署圖：用于理解組織中的硬件和應用以及它們?nèi)绾未嬖谟诮M織之中。下圖給出了這樣的一個部署圖的例子。第8章架構建模39也可以在更傳統(tǒng)的意義上使用部署圖：用于理第8章架構建模第8章架構建模第8章架構建模第8章架構建模41本章主要內(nèi)容：架構是什么邏輯架構物理架構架構模式模型驅動的架構第8章架構建模第8章架構建模2本章主要內(nèi)容：8.1導言第8章架構建模42在這一章里，將學習如何使用UML建立和可視化地描述幾種不同類型的架構模型。架構建模是UML當今最流行的應用領域之一。一個健壯的架構對一個成功的應用，特別是對長壽的應用系統(tǒng)和系統(tǒng)隨時間所經(jīng)歷的變更是至關重要的。架構建模為理解、交流和確認系統(tǒng)的架構設計提供了關鍵支持。8.1導言第8章架構建模3在這一章里，將學習如何使用U8.2什么是架構第8章架構建模43在同GradyBooch的一次談話中，他說：“每一個軟件都有一個架構(architecture)，不論這個架構是否有意的被開發(fā)”。教科書中對架構一詞的定義是：架構(architecture)：建筑作品或科學；特別指：設計和建造結構物尤其是可供人居住的結構物的作品和實踐。有意識建立的某種格式或結構物<花園的架構>。一個計算機或計算機系統(tǒng)的組織和集成方式。譯注：在很多文獻中architecture也被譯為“體系結構”或“構架”，現(xiàn)在更多的是使用“架構”一詞。8.2什么是架構第8章架構建模4在同GradyBoo第8章架構建模44一個架構描述了某物體的多個部分如何集成為一個整體。一架飛機有一個架構；人的身體都有一個架構，盡管這些架構的特征各不相同。如果準備建立起某種事物，描述它的架構是很有用途的。描述方式：或者通過文本形式描述，或者為這個事物的架構建立一個模型(參見下圖)。第8章架構建模5一個架構描述了某物體的多個部分如何集成為一第8章架構建模45我們所討論的架構，是指一個系統(tǒng)的結構。架構包括了業(yè)務規(guī)則、軟件，以及軟件如何與其他軟件通信。一個架構既可以包括一個組織內(nèi)的軟件也可以包括組織外的軟件。因為內(nèi)部系統(tǒng)可能需要與合伙人、顧客和賣方整合，所以系統(tǒng)的架構既要包括內(nèi)部系統(tǒng)也要包括外部系統(tǒng)。架構還可以包括運行軟件的硬件，甚至還可以包括系統(tǒng)的使用者以及關于系統(tǒng)如何使用的理解和描述。第8章架構建模6我們所討論的架構，是指一個系統(tǒng)的結構。8.3為什么對架構建模第8章架構建模46軟件和系統(tǒng)架構的建模有著非常重要的價值。它幫助理解系統(tǒng)是如何被開發(fā)和建造的。軟件由許多小的單元組成，這些單元通常被稱作構件(component)。構件之間存在接口，共同執(zhí)行業(yè)務邏輯，并且時常要在彼此之間交換數(shù)據(jù)。理解了架構的功能和跨越系統(tǒng)邊界的依賴關系，就可以幫助理解軟件開發(fā)過程和設計出更好的系統(tǒng)。通過對架構建模，可以為其他人提供一個良好的通信機制，為系統(tǒng)開發(fā)提供不同的時間基線，理解系統(tǒng)與其他系統(tǒng)或組織之間的依賴關系，合理地分配開發(fā)工作量，找出設計缺陷和不良的設計模式，等等。8.3為什么對架構建模第8章架構建模7軟件和系統(tǒng)架構的第8章架構建模47軟件系統(tǒng)架構的可視化建模同樣具有許多優(yōu)點。一個可視化的模型能夠讓開發(fā)者在系統(tǒng)的物理實現(xiàn)之前直接觀察所計劃要建立的系統(tǒng)結構?？梢暬哪Ｐ瓦€可以使開發(fā)者更好地理解系統(tǒng)開發(fā)計劃，并通過模型在不同人員之間交流系統(tǒng)的設計信息?？梢暬哪Ｐ吞峁┝艘环N觀察系統(tǒng)設計的方式，這樣的方式確保了系統(tǒng)的設計在系統(tǒng)的整體架構下的合理性。通常，系統(tǒng)設計人員只關注他負責的那部分系統(tǒng)的設計并且不了解系統(tǒng)的整體架構——他設計的構件必須與其他設計人員設計的構件組裝到一起從而形成完整的系統(tǒng)。UML可以在三個主要層次上建立軟件和系統(tǒng)的架構模型：企業(yè)級、系統(tǒng)級和軟件級。第8章架構建模8軟件系統(tǒng)架構的可視化建模同樣具有許多優(yōu)點。8.3.1企業(yè)架構第8章架構建模48企業(yè)架構(enterprisearchitecture)用于提供企業(yè)的高層視圖，包括業(yè)務過程、組織結構、系統(tǒng)(包括軟件和硬件)，和預期的對現(xiàn)存架構的演化?？梢曰谠S多不同的架構框架建立企業(yè)架構，包括Zachman框架、美國聯(lián)邦政府企業(yè)架構框架(FEAF)、美國國防部企業(yè)框架(DoDAF)和其他組織和行業(yè)的特定框架。這些企業(yè)架構框架為企業(yè)建模者提供了一個標準的方法，用于建立企業(yè)架構，以確?？缭搅私M織邊界的業(yè)務和操作的一致性。8.3.1企業(yè)架構第8章架構建模9企業(yè)架構(enter第8章架構建模49現(xiàn)實世界——強制推行的企業(yè)架構美國聯(lián)邦政府在所有政府部門中強制推行它的企業(yè)架構，要求政府各部門使用這個架構來說明該部門是如何使用各種軟硬件，從業(yè)務的角度說明企業(yè)的運作。聯(lián)邦政府管理和預算辦公室(OMB)推行了一個標準的企業(yè)架構框架，稱為聯(lián)邦企業(yè)架構框架(FEAF)，并要求所有政府部門必須遵循。盡管這個框架規(guī)定了政府部門應該如何描述企業(yè)架構，包括有關的建模和丈檔標準，但是該框架仍然留給各部門對其進行進一步解釋的余地。因為FEAF只是一組參考模型，更準確地講，它是一組元模型(meta-model)，每個政府部門對它的解釋可以不同，但是必須遵循同一個企業(yè)架構的建造過程。立法部門的一個機構采用了聯(lián)邦政府管理和預算辦公室制定的FEAF標準，以改進部門間和部門內(nèi)各系統(tǒng)間的信息整合，減少重復勞動。為了確保各個部門確實采用了FEAF標準，如果某個部門不能證明它按照該標準建立企業(yè)架構，那么聯(lián)邦政府管理和預算辦公室將終止對該部門的財政預算。第8章架構建模10現(xiàn)實世界——強制推行的企業(yè)架構第8章架構建模50我們曾經(jīng)與美國政府某部門一同工作，用UML模型向美國國會展示該部門的企業(yè)架構，說明了該架構正在建造之中以及它的進展情況。使用這些UML模型，雙方可以就該部門內(nèi)的軟件應用和所要執(zhí)行的業(yè)務過程進行很好溝通。這樣，他們可以共同制訂出關于該部門未來幾年的現(xiàn)代化改造的切實可行的計劃。上面的事例證明，企業(yè)架構可以有效地記錄企業(yè)現(xiàn)在的狀態(tài)，幫助理解企業(yè)未來隨時間所經(jīng)歷的演化過程，提供了企業(yè)架構演化的計劃或藍圖。要確保企業(yè)架構的文檔是一個隨著時間不斷及時更新的文檔，這是非常重要的。企業(yè)架構的文檔不應該是一經(jīng)建立就從不改變的文檔。第8章架構建模11我們曾經(jīng)與美國政府某部門一同工作，用UM第8章架構建模51吸取教訓向其他人提供企業(yè)架構的視圖可以幫助保證組織間的互操作性。建立企業(yè)架構模型，可以幫助理解組織的內(nèi)部組成，包括軟件、硬件、業(yè)務過程和組織資源。企業(yè)架構必須是一個隨時間演化的文檔。它不能在建立之后就束之高擱，而是要隨著企業(yè)變化而及時更新。一個企業(yè)架構必須是模型和文檔的結合，這樣可以保證需要理解它的人能夠對其有全面的理解。第8章架構建模12吸取教訓8.3.2系統(tǒng)架構第8章架構建模52一般地說，一個系統(tǒng)是由多個運行于硬件上軟件程序或控制硬件執(zhí)行某種動作的軟件程序組成。例如，一架飛機就是一個大的硬件，其中運行著許多不同的軟件程序，用來控制飛機的動作。硬件和軟件的結合構成了完整的系統(tǒng)——飛機。DVD的制造者將許多不同的軟件單元和硬件單元組合在一起，使得各硬件單元能夠協(xié)同工作，共同組成了一個系統(tǒng)：DVD播放器。8.3.2系統(tǒng)架構第8章架構建模13一般地說，一個系統(tǒng)第8章架構建模53軟件架構通常只說明一個特定的軟件應用。系統(tǒng)架構說明了一個系統(tǒng)的所有部件。既包括軟件構件也包括硬件構件，并且可視化地顯示這些構件是如何協(xié)同工作的。系統(tǒng)架構是系統(tǒng)開發(fā)中要建立的最重要的架構模型之一。例如，一個心臟起搏器是由執(zhí)行不同動作的不同部件構成的，用于維持心臟的正常工作。每一個部件都由其中運行的軟件加以控制，系統(tǒng)的整體架構確保了這些部件之間的協(xié)同工作，執(zhí)行正確的動作。盡管每一個硬件構件都可以獨立工作，但同時它們也要依賴于心臟起搏器中的其他部件和控制硬件操作的軟件。對系統(tǒng)架構建模，可以保證硬件和軟件都能被理解，有助于保證系統(tǒng)設計的正確性，還有助于保證部件間的依賴關系得以被正確理解以及各部件間的有效協(xié)同工作。第8章架構建模14軟件架構通常只說明一個特定的軟件應用。8.3.3軟件架構第8章架構建模54一個軟件架構對軟件的預期實現(xiàn)提供了可視化表示。在設計軟件時，多個構件或者部件通常要通過接口聯(lián)系起來，共同組成完整的應用。通過對軟件架構建模，能夠可視化地說明這些不同的構件如何組成一個應用，數(shù)據(jù)和業(yè)務過程如何被這些構件共享。企業(yè)架構試圖直接反映業(yè)務需要，而軟件架構則是通過描述符合企業(yè)架構的軟件設計來間接地反映業(yè)務需要。軟件架構設計師可能使用業(yè)務模型來幫助他們決定如何設計軟件，但是業(yè)務模型設計通常不直接作為軟件架構的組成部分。8.3.3軟件架構第8章架構建模15一個軟件架構對軟件8.4邏輯架構第8章架構建模55一個架構可以具有的描述范圍(即：企業(yè)架構、系統(tǒng)架構和軟件架構)。架構也可以有不同的抽象層次，每個抽象層次包含了不同的架構細節(jié)。這里要介紹兩個抽象層次上的架構，即：邏輯架構和物理架構。邏輯架構是與系統(tǒng)的全部實現(xiàn)技術無關的架構。邏輯架構說明了架構的邏輯組成。邏輯架構并非為了展示軟件的實現(xiàn)，而是對軟件的一個抽象。對于軟件來說，邏輯架構一般用普通語言(非技術語言)描述。邏輯架構沒有經(jīng)過任何具體技術的優(yōu)化(獨立于實現(xiàn)軟件的技術)。負責設計軟件的邏輯架構的架構設計師一般由非軟件開發(fā)者擔任。8.4邏輯架構第8章架構建模16一個架構可以具有的描述第8章架構建模56這里對各種邏輯架構做一個對比說明。企業(yè)架構展示了企業(yè)的內(nèi)部運作和企業(yè)未來的發(fā)展方向。系統(tǒng)架構說明了如何開發(fā)系統(tǒng)以滿足業(yè)務需要。軟件邏輯架構描繪了系統(tǒng)中運行的軟件的結構。第8章架構建模17這里對各種邏輯架構做一個對比說明。8.4.1類圖第8章架構建模57使用UML，可以用類圖中的類設計邏輯架構。一個類的圖標是一個矩形方框，其中包含了三個水平的分割欄。第一欄是類名，它是類的邏輯描述，通常是一個名字。例如，類的名字可以是“Customer(顧客)”、“Employee(雇員)”和“Oder(訂單)”，如圖所示。8.4.1類圖第8章架構建模18使用UML，可以用類圖第8章架構建模58第二欄是類的屬性(attribute)，它用于描述類的不同特性。類的屬性進一步說明了這個類的細節(jié)。屬性本身還有更多的特性，用于描述屬性攜帶的數(shù)據(jù)類型。屬性類型在UML類的圖標中位于屬性名的右側，如圖所示。第8章架構建模19第二欄是類的屬性(attribute)，第8章架構建模59第三欄是類的操作(operation)。操作用于描述類的行為。操作定義了系統(tǒng)的執(zhí)行邏輯，既包括基本的邏輯也包括復雜的邏輯。第8章架構建模20第三欄是類的操作(operation)。第8章架構建模60在類圖中可以使用多種不同類型的關聯(lián)，它們展示了類之間或類與其他建模元素之間的關系。下圖簡單定義了各種不同類型的關聯(lián)。第8章架構建模21在類圖中可以使用多種不同類型的關聯(lián)，它們第8章架構建模61第8章架構建模22第8章架構建模62在圖中，角色名之前有一個加號“+”。在定義代碼時，加號說明了其后的角色是公有的。一個角色可以是公有的(public，用“+”號表示)、受保護的(protected，用“#”號表示)、私有的(private，用“-”號表示)，或者具體于實現(xiàn)的(implementation，不用專門的符號表示)。公有角色可以被所有需要該角色的模型元素訪問受保護的角色只能被屬于該角色的一部分的關聯(lián)或角色訪問私有角色只能通過其所屬的關聯(lián)的另一端的模型元素訪問具體于實現(xiàn)的角色能夠被實現(xiàn)該角色的包內(nèi)的所有元素訪問。第8章架構建模23在圖中，角色名之前有一個加號“+”。在定第8章架構建模63在邏輯架構模型的設計中，泛化可用于展示類的繼承層次關系。例如，一個“Employee”可以是“Fulltime(全職)”的，或“Part-time(兼職)”的。在定義一個Employee類時，可能想通過添加屬性來表明雇員的不同類型。但是對于非技術評閱者來說，用泛化關系來表示雇員的不同類型將使模型更加清晰，如下圖所示。圖中的繼承層次說明了全職雇員和兼職雇員都是雇員，它們都繼承了父類Employee的所有屬性和操作。第8章架構建模24在邏輯架構模型的設計中，泛化可用于展示類8.4.2系統(tǒng)和子系統(tǒng)第8章架構建模64構造型(stereotype)使用構造型，可以擴展UML以滿足你更具體的建模需要。構造型本身也是一個UML模型元素，它的作用是擴展已有的模型元素。用構造型擴展后的模型元素具有了擴展后的新特性。UML中，在一個模型元素中增加了構造型圖標“<<stereotype>>”后，該圖標就表示用注明的構造型擴展后的模型元素。8.4.2系統(tǒng)和子系統(tǒng)第8章架構建模25構造型(ste第8章架構建模65如下圖所示，系統(tǒng)(system)是一個用構造型“<<system>>”擴展的包。系統(tǒng)代表了屬于某一個特定項目的所有模型元素。在建立更詳細的模型時，還可以通過構造型“<<businesssystem>>”和“<<applicationsystem>>”對系統(tǒng)進一步分解。第8章架構建模26如下圖所示，系統(tǒng)(system)是一個用第8章架構建模66一個系統(tǒng)通?？梢员环纸鉃槎鄠€子系統(tǒng)(subsystem)。子系統(tǒng)，如同系統(tǒng)，是通過一個構造型“<<sybsystem>>”擴展的包。如下圖所示。一個子系統(tǒng)由整個系統(tǒng)中的一組模型元素構成。第8章架構建模27一個系統(tǒng)通?？梢员环纸鉃槎鄠€子系統(tǒng)(su第8章架構建模67因為系統(tǒng)和子系統(tǒng)是用構造型擴展了的包，因此它們具有包的一切性質，符合包的所有使用規(guī)則。這意味著系統(tǒng)和子系統(tǒng)內(nèi)的模型元素屬于代表系統(tǒng)或子系統(tǒng)的包而不屬于其他任何包。子系統(tǒng)為項目的劃分提供了手段。既然一個系統(tǒng)包含了多個子系統(tǒng)，那么子系統(tǒng)內(nèi)的所有元素也同樣屬于包含子系統(tǒng)的系統(tǒng)?？梢杂靡粋€圖來描繪系統(tǒng)的邏輯架構(見下圖)。第8章架構建模28因為系統(tǒng)和子系統(tǒng)是用構造型擴展了的包，因8.5物理架構第8章架構建模68架構可以分別在邏輯層和物理層描述。邏輯架構是一個較通用的架構，它較少地依賴技術細節(jié)。物理架構更詳細地描述軟件和系統(tǒng)的設計，包括架構中規(guī)定要采用的不同技術細節(jié)，還描述了軟件自身及軟件與其他軟件是如何集成的。8.5物理架構第8章架構建模29架構可以分別在邏輯層和8.5.1操作第8章架構建模69操作描述了與類的職責和類之間的交互有關的業(yè)務邏輯。例如，“getCustomer”是Customer類中的一個操作。這個操作描述了與如何查詢顧客信息有關的應用邏輯(見圖)。8.5.1操作第8章架構建模30操作描述了與類的職責和第8章架構建模70盡管類的所有成分最終都將被轉換為物理代碼并成為可運行的軟件應用，但是操作的具體細節(jié)是在系統(tǒng)和模型的物理實現(xiàn)時考慮的更具體的類成分。在邏輯架構模型中，操作用于說明軟件的預期行為，而在物理架構中操作定義了系統(tǒng)的物