C2-軟件體系結(jié)構(gòu)建模

軟件體系結(jié)構(gòu)

--第三章軟件體系結(jié)構(gòu)建模2內(nèi)容概要3.1軟件體系結(jié)構(gòu)建模概述

3.2“4+1”視圖模型3.3“4+1”視圖模型案例分析3.4“4+1”視圖模型補充知識3.5軟件體系結(jié)構(gòu)核心模型3.6軟件體系結(jié)構(gòu)生命周期模型研究軟件體系結(jié)構(gòu)的首要問題是如何表示軟件體系結(jié)構(gòu)，即如何對軟件體系結(jié)構(gòu)建模。根據(jù)建模的側(cè)重點不同，可以將軟件體系結(jié)構(gòu)的模型分為5種：第3章軟件體系結(jié)構(gòu)建模3.1軟件體系結(jié)構(gòu)建模概述

◎結(jié)構(gòu)模型◎框架模型◎動態(tài)模型◎過程模型◎功能模型32023/2/1

軟件體系結(jié)構(gòu)建模的種類

第3章軟件體系結(jié)構(gòu)建模3.1軟件體系結(jié)構(gòu)建模概述

◎結(jié)構(gòu)模型

這是一個最直觀、最普遍的建模方法。這種方法以體系結(jié)構(gòu)的構(gòu)件、連接件和其他概念來刻畫結(jié)構(gòu)，并力圖通過結(jié)構(gòu)來反映系統(tǒng)的重要語義內(nèi)容，包括系統(tǒng)的配置、約束、隱含的假設(shè)條件、風(fēng)格、性質(zhì)等。

研究結(jié)構(gòu)模型的核心是體系結(jié)構(gòu)描述語言。42023/2/1

軟件體系結(jié)構(gòu)建模的種類

第3章軟件體系結(jié)構(gòu)建模3.1軟件體系結(jié)構(gòu)建模概述

◎框架模型框架模型與結(jié)構(gòu)模型類似，但它不太側(cè)重描述結(jié)構(gòu)的細節(jié)而更側(cè)重于整體的結(jié)構(gòu)。

框架模型主要以一些特殊的問題為目標(biāo)建立只針對和適應(yīng)該問題的結(jié)構(gòu)。52023/2/1

軟件體系結(jié)構(gòu)建模的種類

第3章軟件體系結(jié)構(gòu)建模3.1軟件體系結(jié)構(gòu)建模概述

◎動態(tài)模型

動態(tài)模型是對結(jié)構(gòu)或框架模型的補充，研究系統(tǒng)的“大顆?！钡男袨樾再|(zhì)。例如，描述系統(tǒng)的重新配置或演化。動態(tài)可以指系統(tǒng)總體結(jié)構(gòu)的配置、建立或拆除通信通道或計算的過程。62023/2/1

軟件體系結(jié)構(gòu)建模的種類

第3章軟件體系結(jié)構(gòu)建模3.1軟件體系結(jié)構(gòu)建模概述

◎過程模型過程模型研究構(gòu)造系統(tǒng)的步驟和過程。結(jié)構(gòu)是遵循某些過程腳本的結(jié)果。72023/2/1

軟件體系結(jié)構(gòu)建模的種類

第3章軟件體系結(jié)構(gòu)建模3.1軟件體系結(jié)構(gòu)建模概述

◎功能模型功能模型認為體系結(jié)構(gòu)是由一組功能構(gòu)件按層次組成，下層向上層提供服務(wù)。

功能模型可以看作是一種特殊的框架模型。82023/2/1

“4+1”模型概述

第3章軟件體系結(jié)構(gòu)建模3.2“4+1”視圖模型以上五種模型各有所長，將五種模型有機的統(tǒng)一在一起，形成一個完整的模型來刻畫軟件體系結(jié)構(gòu)更加合適。9

WHY：1、每個視圖模型可看成對系統(tǒng)不同方面一個投影，一個構(gòu)架的不同視圖其實反映的是同一個系統(tǒng)。

2、各個不同的視圖是可以融合在一起的，而且也只有將不同的視圖融合在一起才能獲得關(guān)于一個系統(tǒng)構(gòu)架的全面信息。

“4+1”視圖模型概述

第3章軟件體系結(jié)構(gòu)建模3.2“4+1”視圖模型Rational公司的PhilippeKruchten在1995年提出了用于體系結(jié)構(gòu)描述的“4十l”視圖模型。該模型建立在體系結(jié)構(gòu)的Perry＆Wolf定義和BerryBoehm定義的基礎(chǔ)上。102023/2/1

邏輯視圖進程視圖開發(fā)視圖物理視圖最終用戶：功能需求場景編程人員：軟件管理系統(tǒng)集成人員：性能可擴充性、吞吐量等系統(tǒng)工程人員：系統(tǒng)拓撲、安裝、通信等11*

軟件架構(gòu)視圖Kruchten在其著作《Rational統(tǒng)一過程引論》中寫道：一個架構(gòu)視圖是對于從某一視角或某一點上看到的系統(tǒng)所做的簡化描述，描述中涵蓋了系統(tǒng)的某一特定方面，而省略了與此方面無關(guān)的實體。

軟件架構(gòu)的每個視圖分別關(guān)注不同的方面，針對不同的目標(biāo)和用途。第3章軟件體系結(jié)構(gòu)建模3.2“4+1”視圖模型12*

關(guān)于視圖氣候?qū)W家關(guān)心的社會學(xué)家關(guān)心的引入視圖的作用：世界地圖的繪制者很難將不同的信息都繪制到同一幅圖中；而看地圖的人也希望有一幅地圖是專門針對他的需要的。

同一事物的不同視圖之間是有聯(lián)系的。對比上面兩幅圖，除了南美洲之外基本都是降水量足的地方人口較密集?！?+1”視圖模型從5個不同的視角包括邏輯視圖、進程視圖、物理視圖、開發(fā)視圖和場景視圖來描述軟件體系結(jié)構(gòu)。每一個視圖只關(guān)心系統(tǒng)的一個側(cè)面，5個視圖結(jié)合在一起才能夠處理富于挑戰(zhàn)性的、大規(guī)模的軟件系統(tǒng)。“4+1”視圖模型的不同視圖之間也存在相互影響。

132023/2/1邏輯視圖進程視圖開發(fā)視圖物理視圖最終用戶：功能需求場景編程人員：軟件管理系統(tǒng)集成人員：性能可擴充性、吞吐量等系統(tǒng)工程人員：系統(tǒng)拓撲、安裝、通信等

142023/2/1u邏輯視圖

當(dāng)采用面向?qū)ο蟮脑O(shè)計方法時，邏輯視圖即是對象模型。u進程視圖

描述系統(tǒng)的并發(fā)和同步方面的設(shè)計。u物理視圖

描述軟件到硬件之間的映射關(guān)系，反映系統(tǒng)在分布方面的設(shè)計。邏輯視圖進程視圖開發(fā)視圖物理視圖最終用戶：功能需求場景編程人員：軟件管理系統(tǒng)集成人員：性能可擴充性、吞吐量等系統(tǒng)工程人員：系統(tǒng)拓撲、安裝、通信等

15u開發(fā)視圖

描述軟件在開發(fā)環(huán)境下的靜態(tài)組織。u場景視圖通過選擇出一些用例對體系結(jié)構(gòu)加以說明。這些用例稱作場景。

“4+1”的由來：四個視圖反映的是同一個系統(tǒng)，之所以用了第五個視圖，“+1”視圖，因為它是由一系列重要的案例組成。用這些重要的案例將前面的四個視圖聯(lián)系到一起，從而組成第五個視圖。邏輯視圖進程視圖開發(fā)視圖物理視圖最終用戶：功能需求場景編程人員：軟件管理系統(tǒng)集成人員：性能可擴充性、吞吐量等系統(tǒng)工程人員：系統(tǒng)拓撲、安裝、通信等

162023/2/1對體系結(jié)構(gòu)進行的描述是圍繞著以上4個視圖展開的。然后，通過選擇出的一些用例對體系結(jié)構(gòu)加以說明。這些用例被稱作場景(scenarios)，它們構(gòu)成了第5個視圖。實際上，體系結(jié)構(gòu)在某種程度上是由場景演化而來的。

邏輯視圖進程視圖開發(fā)視圖物理視圖最終用戶：功能需求場景編程人員：軟件管理系統(tǒng)集成人員：性能可擴充性、吞吐量等系統(tǒng)工程人員：系統(tǒng)拓撲、安裝、通信等

17“４+１”視圖模型的特征一：體系結(jié)構(gòu)的概念在每個視圖里面都可以獨立應(yīng)用，即可以在每個視圖里面定義體系結(jié)構(gòu)的各種組成元素，如構(gòu)件、連接件等。對于不同的視圖，還可以選擇不同的體系結(jié)構(gòu)風(fēng)格，因此在同一個系統(tǒng)結(jié)構(gòu)中可以使用多種風(fēng)格。在每一種視圖里，我們使用該視圖特定的符號。這避免了符號用法和意義的混亂。

邏輯視圖進程視圖開發(fā)視圖物理視圖最終用戶：功能需求場景編程人員：軟件管理系統(tǒng)集成人員：性能可擴充性、吞吐量等系統(tǒng)工程人員：系統(tǒng)拓撲、安裝、通信等

18“４+１”視圖模型的特征二：“4十1”模型實際上使得有不同需求的人員能夠得到他們對于軟件體系結(jié)構(gòu)想要了解的東西。系統(tǒng)工程師先從物理視圖，然后從進程視圖靠近體系結(jié)構(gòu)。最終使用者、客戶、數(shù)據(jù)專家從邏輯視圖看體系結(jié)構(gòu)；項目經(jīng)理、軟件配置人員從開發(fā)視圖看體系結(jié)構(gòu)。

邏輯視圖進程視圖開發(fā)視圖物理視圖最終用戶：功能需求場景編程人員：軟件管理系統(tǒng)集成人員：性能可擴充性、吞吐量等系統(tǒng)工程人員：系統(tǒng)拓撲、安裝、通信等

19“４+１”視圖模型的特征三：不是所有的軟件體系結(jié)構(gòu)都需要完整的“4十1”視圖。沒有用的視圖在體系結(jié)構(gòu)描述中可以被省略。例如對于非常小的系統(tǒng)，邏輯視圖和開發(fā)視圖有可能非常相似以至于沒有必要把它們分開描述。場景視圖在各種環(huán)境下都是有用的。

邏輯視圖進程視圖開發(fā)視圖物理視圖最終用戶：功能需求場景編程人員：軟件管理系統(tǒng)集成人員：性能可擴充性、吞吐量等系統(tǒng)工程人員：系統(tǒng)拓撲、安裝、通信等2023/2/13.2.1邏輯視圖：面向?qū)ο蟮姆纸?/p>

邏輯視圖主要支持系統(tǒng)的功能需求，即系統(tǒng)提供給最終用戶的服務(wù)。在邏輯視圖中，系統(tǒng)分解成一系列的功能抽象，這些抽象主要來自問題領(lǐng)域。這種分解不但可以用來進行功能分析，而且可用作標(biāo)識在整個系統(tǒng)的各個不同部分的通用機制和設(shè)計元素。在面向?qū)ο蠹夹g(shù)中，通過抽象、封裝和繼承，可以用對象模型來代表邏輯視圖，用類圖來描述邏輯視圖。

202023/2/13.2.1邏輯視圖的符號表示法可以從Booch標(biāo)記法中導(dǎo)出邏輯視圖的標(biāo)記法，只是從體系結(jié)構(gòu)級的范疇來考慮這些符號，用RationalRose進行體系結(jié)構(gòu)設(shè)計。

212023/2/1關(guān)聯(lián)：表示兩個類之間存在某種語義上的聯(lián)系，真正含義由附加在橫線上的短語說明。包含：實心圓一端表示整體，另一端表示部分。使用：空心圓一端連接在請求服務(wù)的類，另一端連接在提供服務(wù)的類。繼承：箭頭由子類指向基類。3.2.1邏輯視圖的風(fēng)格邏輯視圖可以采用面向?qū)ο蟮娘L(fēng)格。邏輯視圖設(shè)計的主要準(zhǔn)則是，要設(shè)法在整個系統(tǒng)中保持一個單一的、連貫的對象模型。

222023/2/1

232023/2/13.2.1邏輯視圖的例子

左圖顯示了一個專用自動交換分機(ACS)的例子。專用自動交換分機用于在通信終端之間建立連接。通信終端可能是電話機、中繼線(連接到中心室的線路)、專用線(專用自動交換分機和一般的交換分機之間的線路)、數(shù)據(jù)線、ISDN線等。不同的線路需要不同的線路接口卡的支持。終端對象負責(zé)維護終端的狀態(tài)，并代表所在的線路提供通信服務(wù)。線路控制器對象負責(zé)譯碼：從線路接口卡接受信號，以及向它發(fā)送信號，并完成信號和一系列的事件(如開始、結(jié)束、計數(shù)等)之間的轉(zhuǎn)換?？刂破鬟€必須受到嚴(yán)格的實時要求的約束。為了適應(yīng)不同的接口，這個類有許多的子類。會話對象代表在一個對話中涉及的終端的集合。會話對象使用轉(zhuǎn)換服務(wù)(邏輯地址和物理地址之間的映射、路由等)和連接服務(wù)建立兩個終端之間的語音連接。242023/2/1

對于規(guī)模更大的系統(tǒng)來說，體系結(jié)構(gòu)級中包含數(shù)十甚至數(shù)百個類。左圖是空中交通管制系統(tǒng)的頂級類圖，該圖包含了8個類種屬（即類的分組）。3.2.1邏輯視圖的例子

3.2.2進程視圖：過程分解

進程視圖（processview,也稱過程視圖）側(cè)重于系統(tǒng)的運行特性，主要考慮的是一些非功能性的需求，諸如性能、可用性等。它所要面對的問題有并發(fā)，分布，系統(tǒng)的完整性，容錯能力等。它還要考慮怎樣把進程體系結(jié)構(gòu)與邏輯視圖體系結(jié)構(gòu)的要點相適應(yīng)——對某個對象的某個操作實際上是在哪個控制線程上發(fā)生的。

252023/2/13.2.2進程視圖：過程分解

可以把進程體系結(jié)構(gòu)分為幾個抽象層次來描述，每個層次關(guān)注不同的方面。在最高層次上，進程體系結(jié)構(gòu)可以看做是構(gòu)成一個執(zhí)行單元的一組任務(wù)通過進程視圖可以估計出消息流和過程負荷，也可以從過程測量一個目標(biāo)系統(tǒng)最終執(zhí)行情況。

262023/2/13.2.2進程視圖的符號表示法

通過擴展Booch對Ada任務(wù)的表示法，來表示進程視圖。3.2.2進程視圖的風(fēng)格

有多種風(fēng)格適合進程視圖。例如管道和過濾器、客戶／服務(wù)器及其變體(多客戶／單服務(wù)器，多客戶／多服務(wù)器)等。

3.2.2進程視圖的例子（ACS系統(tǒng)局部進程視圖）

282023/2/1（1）在圖中，所有終端均由同一個終端進程進行處理，由其輸入隊列中的消息驅(qū)動。

（3）控制器對象在組成控制器進程的3個任務(wù)之一中執(zhí)行。

292023/2/1（3）慢循環(huán)周期(200ms)任務(wù)掃描所有掛起的終端，把任何一個活動的終端置入快循環(huán)周期(10ms)任務(wù)的掃描列表。

（4）快循環(huán)周期任務(wù)檢測任何顯著的狀態(tài)改變，并把改變的狀態(tài)傳遞給主控制器任務(wù)。

302023/2/1（5）主控制器任務(wù)解釋改變，通過消息與相應(yīng)的終端進行通信。

（6）通過共享內(nèi)存來實現(xiàn)在控制器進程中傳遞的消息。

312023/2/13.2.3開發(fā)視圖：子系統(tǒng)分解

(1)開發(fā)視圖也稱為模塊視圖，側(cè)重的是在軟件開發(fā)環(huán)境中軟件模塊的實際組織和管理。軟件被打包成可以由單個或少量程序員開發(fā)的各種小的部分：程序庫或子系統(tǒng)。子系統(tǒng)被組織成層次化的體系結(jié)構(gòu)，每一層為上一層提供一個嚴(yán)密的、明確定義的接口。

322023/2/13.2.3開發(fā)視圖：子系統(tǒng)分解

（3）描述開發(fā)視圖的原則是：分割、編組、可視。（3）開發(fā)視圖要考慮軟件內(nèi)部的需求，如軟件開發(fā)的容易性、軟件的重用和軟件的通用性，要充分考慮由于具體開發(fā)工具的不同而帶來的局限性。

332023/2/13.2.3開發(fā)視圖的符號表示法開發(fā)視圖的符號表示法采用Booch表示法的變體，并且只考慮對于體系結(jié)構(gòu)有重要意義的元素，如圖所示。在RationnalRose中，可以繪制模塊層和子系統(tǒng)層的開發(fā)視圖，還可以在反向工程中從已經(jīng)開發(fā)的源代碼(Ada或C十十)得出系統(tǒng)的開發(fā)視圖。

342023/2/13.2.3開發(fā)視圖的風(fēng)格

對于開發(fā)視圖，最好采用分層風(fēng)格，定義4—6層的子系統(tǒng)。每一層都有明確責(zé)任。設(shè)計規(guī)則是，某一層的子系統(tǒng)只能依賴于本層或其下層的子系統(tǒng)。這樣可以使每個層次的接口既完備又精練，避免了各個模塊之間很復(fù)雜的依賴關(guān)系，并使得系統(tǒng)可以采用逐層的策略完成釋放。設(shè)計時要充分考慮，對于各個層次，層次越低，通用性越強，這樣，可以保證應(yīng)用程序的需求發(fā)生改變時，所做的改動最小。

352023/2/13.2.3開發(fā)視圖的例子

下圖用5個層次表示了航空交通管制系統(tǒng)產(chǎn)品線的開發(fā)組織。此開發(fā)視圖3－4中描述的邏輯視圖相對應(yīng)的。

362023/2/13.2.3開發(fā)視圖的例子（1）第1層和第２層組成了一個領(lǐng)域無關(guān)的分布式基礎(chǔ)結(jié)構(gòu)，貫穿于整個產(chǎn)品線中。這兩層獨立于應(yīng)用域，并將上層系統(tǒng)遮蔽起來，防止其受到與硬件平臺、操作系統(tǒng)或數(shù)據(jù)庫等變化的影響。

372023/2/13.2.3開發(fā)視圖的例子（3）第3層增加了空中交通管制系統(tǒng)的框架，以形成一個用于特定應(yīng)用領(lǐng)域的軟件體系結(jié)構(gòu)。

（3）第4層使用該框架構(gòu)造了一個功能平臺。

382023/2/13.2.3開發(fā)視圖的例子（4）第5層則依賴于具體客戶和產(chǎn)品，包含了大部分用戶界面和與外部系統(tǒng)的接口。

392023/2/13.2.4物理視圖：從軟件到硬件的映射

物理視圖主要考慮如何把軟件映射到硬件上，它通常要考慮到系統(tǒng)的非功能性的需求。如：可用性、可靠性(容錯性)、性能(信息吞吐量)、規(guī)模和可擴展性。解決系統(tǒng)拓撲結(jié)構(gòu)、系統(tǒng)安裝、通訊等問題。

402023/2/13.2.4物理視圖：從軟件到硬件的映射

當(dāng)軟件運行于不同的處理節(jié)點上時，各視圖中的構(gòu)件（如網(wǎng)絡(luò)、過程、任務(wù)和對象）都直接或間接地對應(yīng)于系統(tǒng)的不同節(jié)點（需要被映射至不同的節(jié)點）；我們希望使用不同的物理配置：一些用于開發(fā)和測試，另外一些則用于不同地點和不同客戶的部署。因此，從軟件到節(jié)點的映射要有較高的靈活性，當(dāng)環(huán)境改變時，對系統(tǒng)其他視圖的影響最小。

大型系統(tǒng)的物理視圖可能會變得十分混亂，因此可以與進程視圖的映射一起，以多種形式出現(xiàn)，也可單獨出現(xiàn)。

412023/2/13.2.4物理視圖的符號表示法

TRW公司的UNAS（通用網(wǎng)絡(luò)結(jié)構(gòu)服務(wù)技術(shù)）允許使用者采用數(shù)據(jù)驅(qū)動的方式將進程體系結(jié)構(gòu)映射到物理體系結(jié)構(gòu)，并允許在不修改源代碼的情況下對這種映射做出多種改動。

422023/2/1432023/2/1

ACS系統(tǒng)的物理視圖3.2.4物理視圖的符號表示法

上圖顯示了大型專用自動交換機（ACS）的一種可能的硬件配置。其中，C、F、K是3個不同容量的計算機類型，支持3個不同的可執(zhí)行文件。下面是進程視圖的兩個不同的物理映射，分別對應(yīng)一個小型的ACS和大型的ACS。具有進程分配的小型ACS系統(tǒng)的物理視圖具有進程分配的大型ACS系統(tǒng)的物理視圖3.2.5場景視圖：匯總

通過使用一些重要場景，4個視圖中的元素可以協(xié)調(diào)地共同工作。盡管這些場景是一個小集合，但是它們很重要。場景(scenario)是更通用的概念——用例(usecase)的實例。從某種意義上講，場景是最重要的需求的抽象。相對于其他的4個視圖，這個視圖承擔(dān)著兩個目的：●在體系結(jié)構(gòu)的設(shè)計中，將以此視圖為驅(qū)動來發(fā)現(xiàn)體系結(jié)構(gòu)的構(gòu)件和它們之間的作用。●在體系結(jié)構(gòu)設(shè)計結(jié)束后，此視圖承擔(dān)驗證和描述的角色。它不僅用于書面記錄，并且是體系結(jié)構(gòu)原型測試的起始點。

452023/2/13.2.5場景視圖的符號表示法

場景可以用文本表示，也可以用符號表示。場景視圖的符號表示法中，構(gòu)件的表示與邏輯視圖非常相似，但是連接件的表示使用進程視圖中的方法。注意，對象的實例用細實線表示。在工具的使用方面，和邏輯視圖類似，可以使用RationalRose繪制和管理對象場景圖。

462023/2/1

472023/2/13.2.5場景視圖的例子①小王的電話的控制器檢測到并證實了從掛起到取下的狀態(tài)轉(zhuǎn)變，并且發(fā)送了消息來喚醒相關(guān)的終端對象。②終端分配一定的資源，并告訴控制器發(fā)出撥號音。③控制器收到數(shù)字并將它們發(fā)送給終端。④終端使用編號計劃來分析號碼。⑤當(dāng)一個有效序列的輸入完成，終端打開一個對話。圖場景的雛形—本地呼叫選擇階段482023/2/1

小結(jié)

邏輯視圖和開發(fā)視圖描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，而進程視圖和物理視圖描述系統(tǒng)的動態(tài)結(jié)構(gòu)。對于不同的軟件系統(tǒng)來說，側(cè)重的角度也有所不同。例如，對于管理信息系統(tǒng)來說，比較側(cè)重于從邏輯視圖和開發(fā)視圖來描述系統(tǒng)，而對于實時控制系統(tǒng)來說，則比較注重于從進程視圖和物理視圖來描述系統(tǒng)。

案例分析：NAS—網(wǎng)絡(luò)終端通訊服務(wù)系統(tǒng)

第3章軟件體系結(jié)構(gòu)建模3.3“4+1”視圖模型案例分析

492023/2/1

需求描述：NAS可運行于網(wǎng)絡(luò)中任一臺終端上，可為終端用戶之間提供短信通信服務(wù)；NAS在傳輸信息之前要求先進行加密處理，然后再以密文的形式發(fā)送；NAS接收到傳輸?shù)拿芪暮?，要求再以明文方式顯示給終端用戶；

邏輯視圖——線框圖表示法第3章軟件體系結(jié)構(gòu)建模3.3“4+1”視圖模型案例分析

502023/2/1

邏輯視圖——ＵＭＬ表示法第3章軟件體系結(jié)構(gòu)建模3.3“4+1”視圖模型案例分析

512023/2/1

邏輯視圖——UML表示的NAS系統(tǒng)邏輯圖第3章軟件體系結(jié)構(gòu)建模3.3“4+1”視圖模型案例分析

522023/2/1

邏輯視圖——UML表示的NASNetService構(gòu)件的邏輯視圖第3章軟件體系結(jié)構(gòu)建模3.3“4+1”視圖模型案例分析

532023/2/1

開發(fā)視圖——UML表示法第3章軟件體系結(jié)構(gòu)建模3.3“4+1”視圖模型案例分析

542023/2/1

開發(fā)視圖——UML表示法第3章軟件體系結(jié)構(gòu)建模3.3“4+1”視圖模型案例分析

552023/2/1

進程視圖——UML表示法第3章軟件體系結(jié)構(gòu)建模3.3“4+1”視圖模型案例分析

562023/2/1

物理視圖——UML表示法第3章軟件體系結(jié)構(gòu)建模3.3“4+1”視圖模型案例分析

572023/2/1

3.6.3視圖間的交流不同視圖之間并不是互相獨立或互相正交的。視圖中的元素遵循一定的規(guī)則和經(jīng)驗法則與其他視圖中的元素形成聯(lián)系。從邏輯視圖（最終用戶）到進程視圖（系統(tǒng)集成人員）邏輯視圖中認為每個對象都是主動的、并發(fā)的。定義進程體系結(jié)構(gòu)時，將每個對象實現(xiàn)為獨立的控制線程是不實際的（將導(dǎo)致巨大的開銷）另一方面，多控制線程也是需要的

582023/2/1在確定并發(fā)程度及過程數(shù)目時，必須以潛在的物理目標(biāo)體系結(jié)構(gòu)集合為前提，可以參照以下兩種策略。自內(nèi)向外：從邏輯視圖開始的策略自外向內(nèi)：從物理體系結(jié)構(gòu)開始的策略結(jié)果：類及其對象到進程體系結(jié)構(gòu)的任務(wù)和過程集合的映射為達到可接受的設(shè)計結(jié)果，需要進行迭代

592023/2/13.從邏輯視圖（最終用戶）到開發(fā)視圖（編程人員）一個類通常被實現(xiàn)為一個模塊較大的類被分解為多個包一組相互聯(lián)系緊密的類的集合，或稱為類種屬，構(gòu)成子系統(tǒng)定義子系統(tǒng)時，必須考慮附加約束項目越大，邏輯視圖和開發(fā)視圖之間的距離越遠3.從進程視圖（系統(tǒng)集成人員）到物理視圖（系統(tǒng)工程人員）為了測試和部署，過程和過程組以各種配置映射到可用的物理硬件上。

602023/2/1模型的迭代過程和軟件過程1.迭代過程：場景驅(qū)動的方法采用“4+1”模型進行軟件體系結(jié)構(gòu)設(shè)計的一種推薦方法是：在完成原型、測試、度量、分析等步驟后，重新進入下一輪這樣的步驟，構(gòu)成迭代的過程系統(tǒng)最關(guān)鍵的功能以場景的形式得到。關(guān)鍵是指，功能上最重要，或是用頻度上最高，又或存在必須克服的技術(shù)風(fēng)險。初始的體系結(jié)構(gòu)演化為最終的真實系統(tǒng)。在3～3次迭代后，體系結(jié)構(gòu)本身有希望穩(wěn)定下來。接下來就可以進行軟件設(shè)計領(lǐng)域的工作了。

612023/2/13.軟件文檔體系結(jié)構(gòu)設(shè)計階段所形成的文檔主要有：軟件體系結(jié)構(gòu)文檔：基本按照4+1視圖組織軟件設(shè)計指導(dǎo)：描述為了維護系統(tǒng)的體系結(jié)構(gòu)的一致性所必須遵守的重要設(shè)計決定。

622023/2/163

綜合軟件體系結(jié)構(gòu)的概念，體系結(jié)構(gòu)的核心模型由5中元素組成：

構(gòu)件連接件配置端口角色其中，構(gòu)件、連接件和配置是最基本的元素。3.3體系結(jié)構(gòu)的核心模型軟件體系結(jié)構(gòu)配置連接件構(gòu)件端口角色1:N1:N1:N原子構(gòu)件復(fù)合構(gòu)件：表示軟件之間的交互表示構(gòu)件和連接件的拓撲結(jié)構(gòu)和約束：表示構(gòu)件和外部環(huán)境的交互點：：定義了該連接件表示的交互的參與者3.3體系結(jié)構(gòu)的核心模型3.3體系結(jié)構(gòu)的核心模型652023/2/1

軟件體系結(jié)構(gòu)的核心模型由五種元素組成：構(gòu)件、連接件、配置、端口和角色。其中構(gòu)件、連接件、配置是最基本的元素。構(gòu)件是具有某種功能的可重用的軟件模板單元，表示了系統(tǒng)中主要的計算元素和數(shù)據(jù)存儲。復(fù)合構(gòu)件由其他復(fù)合構(gòu)件和原子構(gòu)件通過連接而成。原子構(gòu)件是不可再分的構(gòu)件。構(gòu)件只能通過其接口與外部環(huán)境交互，構(gòu)件的接口由一組端口組成，每個端口表示了構(gòu)件和外部環(huán)境的交互點。通過不同的端口類型，一個構(gòu)件可以提供多重接口。連接件表示了構(gòu)件間的交互。連接件也有接口，其接口由一組角色組成，連接件的每一個角色定義了該連接件表示的交互的參與者，二元連接件有兩個角色。配置表示了構(gòu)件和連接件的拓撲邏輯和約束。需求分析建立體系結(jié)構(gòu)測試實現(xiàn)設(shè)計662023/2/1

3.4體系結(jié)構(gòu)的生命周期模型軟件開發(fā)過程3.4體系結(jié)構(gòu)的生命周期模型672