系統(tǒng)架構(gòu)=業(yè)務(wù)架構(gòu)+軟件架構(gòu)

1、系統(tǒng)架構(gòu)=業(yè)務(wù)架構(gòu)+軟件架構(gòu)2022年3月2日星期三第2頁第8章 系統(tǒng)架構(gòu)設(shè)計v8.1 業(yè)務(wù)架構(gòu)v8.2 業(yè)務(wù)架構(gòu)分析v8.3 軟件架構(gòu)v8.4 軟件架構(gòu)設(shè)計v8.5 軟件架構(gòu)與框架v8.6 軟件架構(gòu)的“41”視圖模型v8.7 組件圖v8.8 部署圖2022年3月2日星期三第3頁8.1 業(yè)務(wù)架構(gòu) v1. 問題引入問題引入系統(tǒng)架構(gòu)一般涉及到兩個方面的內(nèi)容，其一是業(yè)務(wù)架構(gòu)，其二是軟件架構(gòu)。人們常常會聽到軟件架構(gòu)這個詞，對軟件架構(gòu)的概念也有一些了解，但是，也許還有人對業(yè)務(wù)架構(gòu)這個詞比較陌生，那么，究竟什么是業(yè)務(wù)架構(gòu)呢？ 2022年3月2日星期三第4頁8.1 業(yè)務(wù)架構(gòu)v2. 解答問題解答問題業(yè)務(wù)架構(gòu)描

2、述了業(yè)務(wù)領(lǐng)域主要的業(yè)務(wù)模塊及其組織結(jié)構(gòu)。業(yè)務(wù)架構(gòu)在先啟階段建立，在精化階段得以改進（關(guān)于先啟階段、精化階段等內(nèi)容請讀者參見第3章的RUP統(tǒng)一過程的相關(guān)內(nèi)容）。業(yè)務(wù)架構(gòu)的目的是為業(yè)務(wù)領(lǐng)域建立一個維護和擴展的結(jié)構(gòu)，描述業(yè)務(wù)的構(gòu)成。業(yè)務(wù)架構(gòu)對我們理解客戶業(yè)務(wù)，尤其是對軟件開發(fā)行業(yè)確定解決方案起著非常重要的作用。 2022年3月2日星期三第5頁8.1 業(yè)務(wù)架構(gòu)v3. 分析問題分析問題 軟件開發(fā)一直在追求構(gòu)件化，就像建房子一樣來構(gòu)建系統(tǒng)，用一塊一塊砌成不同形狀的磚頭來搭建自己想要的房子。在很多人看來，構(gòu)件化開發(fā)是技術(shù)問題。即隨著技術(shù)的發(fā)展，各種先進的架構(gòu)和技術(shù)框架能夠越來越多地解決復(fù)雜的現(xiàn)實問題，總有一

3、天，我們能夠利用一個極其靈活和強大的技術(shù)架構(gòu)，將現(xiàn)實中的業(yè)務(wù)像搭房子一樣構(gòu)建出整個系統(tǒng)。但是，技術(shù)架構(gòu)僅僅提供了您搭建房子的手段和方法，從可行性上給予您支持，您是否想過您砌成大大小小不同形狀的磚頭是什么呢？它們從何而來呢？ 8.1 業(yè)務(wù)架構(gòu)可見，喜歡和迷信技術(shù)的我們又忘了一個基本原則：技術(shù)服務(wù)于業(yè)務(wù)。盡管我們知道怎么樣搭建房子，而手中卻沒有可用的磚頭，怎么能建好房子呢？正所謂巧婦難為無米之炊啊。軟件、技術(shù)通通是服務(wù)于業(yè)務(wù)的，技術(shù)只是保證做好系統(tǒng)的手段，一個好的軟件其根本還在于業(yè)務(wù)的理解上。 8.1 業(yè)務(wù)架構(gòu)SAP是業(yè)界著名的ERP軟件產(chǎn)品，它之所以能夠做到通用，即使在不同行業(yè)間實施也只需很小的

4、開發(fā)工作量，絕大部分需求都是通過配置來完成的。不是因為SAP采用了多么先進的技術(shù)架構(gòu)，而是因為SAP把業(yè)務(wù)做到了極致，它已經(jīng)砌好了那些可以搭建不同業(yè)務(wù)平臺的各式各樣的磚塊。再復(fù)雜和迥異的需求，都可以用這些磚塊搭建出來。這些磚塊，就是業(yè)務(wù)架構(gòu)。 8.1 業(yè)務(wù)架構(gòu)在項目開發(fā)過程中，當我們獲得了一份需求時，如果不建立業(yè)務(wù)架構(gòu)，那么這份需求對我們來說就是一盤沙子，每次我們都要從頭把沙子做成磚塊，一點點辛苦地開發(fā)程序。而建立業(yè)務(wù)架構(gòu)的工作，就是要把沙子變成各式各樣的磚塊、部件，從部件做起而不是從沙子做起，像拼圖一樣，拼出我們的世界來。 8.1 業(yè)務(wù)架構(gòu)但這項工作是非常困難的，需要非常精深的行業(yè)知識。并且

5、不是一朝一夕就可行的，必須通過幾個甚至幾十個項目的累積，才有可能總結(jié)出可用的拼圖。在開發(fā)項目時，僅將業(yè)務(wù)架構(gòu)作為項目中的一項工作，它可能不會對你當前的項目帶來什么好處，但是隨著每一個項目的積累，不斷地修正和豐富業(yè)務(wù)架構(gòu)，手中可用的磚塊就會越來越多，越來越豐富?？傆幸惶欤憧梢杂闷磮D來完成項目中大部分的業(yè)務(wù)需求，也就是行業(yè)解決方案的形成。 8.2 業(yè)務(wù)架構(gòu)分析v分析工作往往被模糊化，經(jīng)常的情況是需求弄清楚以后直接進入設(shè)計階段，例如詳細的表結(jié)構(gòu)、類方法、屬性、頁面原型等，然后就進入編碼階段了。那么分析與設(shè)計之間究竟存在什么樣的差別呢？從工作任務(wù)上來說，分析做的是需求的計算機概念化；設(shè)計做的是計算機

6、概念實例化。從抽象層次上來說，分析高于實現(xiàn)語言、實現(xiàn)方式；而設(shè)計則基于特定的語言和實現(xiàn)方式。因此分析的抽象層次高于設(shè)計的抽象層次。從角色上來說，分析由系統(tǒng)分析師承擔的，而設(shè)計則由設(shè)計師來承擔。從產(chǎn)出物上來說，分析的典型成果是分析模型和組件模型，設(shè)計的成果是設(shè)計類、程序包等。 8.2 業(yè)務(wù)架構(gòu)分析v系統(tǒng)分析是在不考慮具體實現(xiàn)語言和實現(xiàn)方式的情況下，將需求在軟件架構(gòu)和框架下進行的計算機模擬。系統(tǒng)分析的目的是確定系統(tǒng)應(yīng)當做成什么樣的設(shè)想，而系統(tǒng)設(shè)計的目的是將這些設(shè)想轉(zhuǎn)化為可實施的步驟。如果類比于房屋裝修，分析相當于繪制設(shè)計圖，而設(shè)計則相當于繪制施工圖。分析決定哪個地方用哪個物品來裝飾，設(shè)計決定如何裝

7、飾，用什么工具來裝飾。 8.2 業(yè)務(wù)架構(gòu)分析v事實上，經(jīng)過分析之后，已經(jīng)決定了系統(tǒng)要做成什么樣子，已經(jīng)完成了從需求到系統(tǒng)的轉(zhuǎn)換過程。至于接下來是用JAVA還是C#，是用J2EE還是.NET，是用兩層結(jié)構(gòu)還是用三層結(jié)構(gòu)，是用工廠模式還是用適配器模式就已經(jīng)不是問題的重點了。不論采取什么樣的實現(xiàn)方式，得到的結(jié)果無非是程序運行效率的高低、擴展性、可維護性的差別，無論如何都不會影響系統(tǒng)實現(xiàn)需求這一最基本的要求。 8.2 業(yè)務(wù)架構(gòu)分析v8.2.1 客戶服務(wù)系統(tǒng)業(yè)務(wù)架構(gòu)分析v8.2.2 客戶服務(wù)系統(tǒng)子模塊劃分2022年3月2日星期三第14頁8.2.1 客戶服務(wù)系統(tǒng)業(yè)務(wù)架構(gòu)分析 v1. 問題引入問題引入上面我

8、們已經(jīng)了解了分析與設(shè)計的區(qū)別，接下來將討論客戶服務(wù)系統(tǒng)的業(yè)務(wù)架構(gòu)分析與實現(xiàn)。 2022年3月2日星期三第15頁8.2.1 客戶服務(wù)系統(tǒng)業(yè)務(wù)架構(gòu)分析v2. 解答問題解答問題客戶服務(wù)系統(tǒng)的業(yè)務(wù)架構(gòu)如圖8-1所示。8.2.1 客戶服務(wù)系統(tǒng)業(yè)務(wù)架構(gòu)分析電話咨詢客戶客服人員維護人員部門領(lǐng)導(dǎo)管理員投訴處理維護處理回訪處理信息查詢系統(tǒng)管理圖8-1 客戶服務(wù)系統(tǒng)業(yè)務(wù)架構(gòu) 2022年3月2日星期三第17頁8.2.1 客戶服務(wù)系統(tǒng)業(yè)務(wù)架構(gòu)分析v3. 分析問題分析問題對客戶服務(wù)系統(tǒng)業(yè)務(wù)架構(gòu)的分析立足于對需求足夠理解的基礎(chǔ)之上，我們知道軟件開發(fā)中最重要的就是抽象，也就是采用OO（面向?qū)ο螅┑乃枷耄@個思想應(yīng)貫穿于軟件

9、開發(fā)過程的始終。需求作為分析過程的輸入，需求分析后，產(chǎn)生用例模型和領(lǐng)域模型。用例模型和領(lǐng)域模型是業(yè)務(wù)架構(gòu)的基礎(chǔ)。如果只有用例模型和領(lǐng)域模型而沒有業(yè)務(wù)架構(gòu)，我們將“只見樹木不見森林”。因為不論是用例模型還是領(lǐng)域模型，它們都只是業(yè)務(wù)領(lǐng)域的一部分。如果說用例模型代表了一個軟件項目對需求的定義和理解，那么架構(gòu)就代表了一個軟件項目對系統(tǒng)的定義和理解。架構(gòu)將系統(tǒng)規(guī)劃為一些獨立的邏輯組件，各負其責，這些組件通過標準的通信接口傳遞信息。一個架構(gòu)就是一個系統(tǒng)的骨架。 8.2.1 客戶服務(wù)系統(tǒng)業(yè)務(wù)架構(gòu)分析v通過整理客戶服務(wù)系統(tǒng)的需求，我們摘錄出系統(tǒng)的核心業(yè)務(wù)如下：v(1) 公司客戶通過 完成對軟件產(chǎn)品或項目提出使

10、用中的BUG或疑難問題以及投訴建議等內(nèi)容。v(2) 客戶服務(wù)人員代理公司客戶將咨詢內(nèi)容錄入到客戶服務(wù)系統(tǒng)中，以供備案查詢。v(3) 部門領(lǐng)導(dǎo)負責處理相關(guān)客戶的投訴建議及故障申報，并視具體情況安排維護人員上門維護及安排客戶服務(wù)人員進行回訪。v(4) 維護人員通過查詢?nèi)蝿?wù)安排，接受相關(guān)派工任務(wù)，并填寫維護報告。v(5) 客戶服務(wù)人員通過查詢?nèi)蝿?wù)安排，接受相關(guān)回訪任務(wù)，并填寫相關(guān)回訪報告。v(6) 系統(tǒng)管理員對系統(tǒng)基礎(chǔ)資料進行維護管理。v(7) 部門領(lǐng)導(dǎo)可以查詢客戶服務(wù)人員及維護人員的工作完成情況。v由此分析出客戶服務(wù)系統(tǒng)的核心業(yè)務(wù)架構(gòu)，用業(yè)務(wù)活動圖表示如圖8-2所示。 8.2.1 客戶服務(wù)系統(tǒng)業(yè)務(wù)

11、架構(gòu)分析圖8-2 客戶服務(wù)核心業(yè)務(wù)活動圖 8.2.1 客戶服務(wù)系統(tǒng)業(yè)務(wù)架構(gòu)分析v業(yè)務(wù)架構(gòu)與核心模型的關(guān)系可用圖8-3來表示。用例模型、領(lǐng)域模型所描述的業(yè)務(wù)過程，通過抽象可得到業(yè)務(wù)架構(gòu)。反過來，業(yè)務(wù)架構(gòu)對用例模型和領(lǐng)域模型則有著重要的指導(dǎo)作用。尤其在業(yè)務(wù)架構(gòu)改進的時候，某些用例可能需要重組，領(lǐng)域模型也可能重構(gòu)。 8.2.1 客戶服務(wù)系統(tǒng)業(yè)務(wù)架構(gòu)分析圖8-3 業(yè)務(wù)架構(gòu)與核心模型的關(guān)系 8.2.1 客戶服務(wù)系統(tǒng)業(yè)務(wù)架構(gòu)分析v從圖8-3可以看出，實際上建立業(yè)務(wù)架構(gòu)的活動是一個反復(fù)迭代的過程，且非常類似于面向過程的結(jié)構(gòu)化設(shè)計，不同的是，在結(jié)構(gòu)化設(shè)計方法中，得到的結(jié)果是子系統(tǒng)、模塊；而在面向?qū)ο蟮脑O(shè)計方法

12、中，得到的結(jié)果則是業(yè)務(wù)組件。 2022年3月2日星期三第23頁8.2.2 客戶服務(wù)系統(tǒng)子模塊劃分客戶服務(wù)系統(tǒng)子模塊劃分v1. 問題引入問題引入了解客戶服務(wù)系統(tǒng)的業(yè)務(wù)架構(gòu)圖之后，接下來我們應(yīng)該做的就是對客戶服務(wù)系統(tǒng)劃分模塊。 2022年3月2日星期三第24頁8.2.2 客戶服務(wù)系統(tǒng)子模塊劃分客戶服務(wù)系統(tǒng)子模塊劃分v2. 解答問題解答問題客戶服務(wù)系統(tǒng)的子模塊如圖8-4所示。8.2.2 客戶服務(wù)系統(tǒng)子模塊劃分客戶服務(wù)系統(tǒng)子模塊劃分客服系統(tǒng)系統(tǒng)管理模塊客服業(yè)務(wù)處理模塊信息查詢統(tǒng)計模塊圖8-4 客戶服務(wù)系統(tǒng)子模塊 8.2.2 客戶服務(wù)系統(tǒng)子模塊劃分客戶服務(wù)系統(tǒng)子模塊劃分v進一步劃分模塊，系統(tǒng)管理模塊、客

13、戶服務(wù)業(yè)務(wù)處理模塊、信息查詢統(tǒng)計模塊分別劃分為如圖8-5、圖8-6、圖8-7所示的子模塊。 8.2.2 客戶服務(wù)系統(tǒng)子模塊劃分客戶服務(wù)系統(tǒng)子模塊劃分系統(tǒng)管理模塊客戶資料管理系統(tǒng)用戶管理產(chǎn)品及項目管理經(jīng)驗庫管理系統(tǒng)維護管理圖8-5 系統(tǒng)管理模塊 8.2.2 客戶服務(wù)系統(tǒng)子模塊劃分客戶服務(wù)系統(tǒng)子模塊劃分客服業(yè)務(wù)處理模塊客戶咨詢管理咨詢投訴報障派工管理維護安排回訪安排圖8-6 客戶服務(wù)業(yè)務(wù)處理模塊 8.2.2 客戶服務(wù)系統(tǒng)子模塊劃分客戶服務(wù)系統(tǒng)子模塊劃分信息查詢統(tǒng)計模塊基礎(chǔ)資料查詢統(tǒng)計客戶咨詢查詢統(tǒng)計派工單完成情況查詢統(tǒng)計報表查詢圖8-7 信息查詢統(tǒng)計模塊 2022年3月2日星期三第30頁8.2.2

14、 客戶服務(wù)系統(tǒng)子模塊劃分客戶服務(wù)系統(tǒng)子模塊劃分v3. 分析問題分析問題(1) 客戶服務(wù)系統(tǒng)子模塊在得到業(yè)務(wù)架構(gòu)的基礎(chǔ)上，我們對客戶服務(wù)系統(tǒng)的業(yè)務(wù)進行細分為以下三個子模塊：v 系統(tǒng)管理模塊。包括客戶基礎(chǔ)資料錄入修改，客戶服務(wù)系統(tǒng)用戶信息的添加、刪除和修改，軟件產(chǎn)品的基礎(chǔ)資料維護，已上線項目的基礎(chǔ)資料維護，F(xiàn)AQ經(jīng)驗庫的數(shù)據(jù)維護以及客戶服務(wù)系統(tǒng)本身的維護管理等。v 客戶服務(wù)業(yè)務(wù)處理模塊。包括客戶咨詢服務(wù)處理、故障申報處理、投訴處理，部門領(lǐng)導(dǎo)派工處理，客戶服務(wù)人員回訪處理，維護人員上門處理等。v 信息查詢統(tǒng)計模塊。包括基礎(chǔ)資料查詢統(tǒng)計，客戶咨詢的查詢與統(tǒng)計，派工單完成情況，回訪報告，維護報告查詢統(tǒng)計

15、以及相關(guān)報表的查詢等。 2022年3月2日星期三第31頁8.2.2 客戶服務(wù)系統(tǒng)子模塊劃分客戶服務(wù)系統(tǒng)子模塊劃分v(2) 各子模塊的功能 系統(tǒng)管理模塊v客戶資料管理客戶資料是客戶服務(wù)系統(tǒng)的根源，只有健全的客戶資料體系才能夠保證客戶服務(wù)有序地開展。主要包括錄入客戶資料、修改客戶資料、刪除客戶資料和查詢客戶資料等功能。v系統(tǒng)用戶管理包括本系統(tǒng)的所有使用者的信息資料管理及查詢。v產(chǎn)品管理包括公司所有發(fā)布的軟件產(chǎn)品信息的管理及查詢。v項目管理包括公司所承擔的各種軟件研發(fā)項目信息的管理及查詢。v經(jīng)驗庫管理包括經(jīng)驗信息的管理及查詢。 8.2.2 客戶服務(wù)系統(tǒng)子模塊劃分客戶服務(wù)系統(tǒng)子模塊劃分 客戶服務(wù)業(yè)務(wù)處

16、理模塊。v客戶咨詢管理包括客戶咨詢信息的管理及查詢?？蛻糇稍兎?wù)活動如圖8-8所示。 圖8-8 客戶咨詢服務(wù)活動圖 8.2.2 客戶服務(wù)系統(tǒng)子模塊劃分客戶服務(wù)系統(tǒng)子模塊劃分v派工管理當有客戶投訴及報障時，部門領(lǐng)導(dǎo)會立即對投訴及報障的客戶作出快速反應(yīng)，及時安排派工任務(wù)。對投訴的客戶安排客戶服務(wù)人員及時回訪處理；對報障的客戶安排維護人員進行上門維護處理。派工活動圖如圖8-9所示。 圖8-9 部門領(lǐng)導(dǎo)派工活動圖 8.2.2 客戶服務(wù)系統(tǒng)子模塊劃分客戶服務(wù)系統(tǒng)子模塊劃分 信息查詢統(tǒng)計模塊v包括查詢統(tǒng)計基礎(chǔ)資料、客戶咨詢信息、派工單完成情況等信息，并可打印報表。 2022年3月2日星期三第37頁8.3

17、軟件架構(gòu)v1. 問題引入問題引入經(jīng)過業(yè)務(wù)架構(gòu)的分析與建模，我們得到了許多業(yè)務(wù)構(gòu)件，要將這些業(yè)務(wù)構(gòu)件搭建起來需要了解軟件架構(gòu)的知識。那么什么是軟件架構(gòu)呢？ 2022年3月2日星期三第38頁8.3 軟件架構(gòu)v2. 解答問題解答問題軟件架構(gòu)是一種思想，一個系統(tǒng)藍圖，是對軟件結(jié)構(gòu)組成的規(guī)劃和職責設(shè)定。一個軟件里有處理數(shù)據(jù)存儲的、處理業(yè)務(wù)邏輯的、處理頁面交互的、處理安全的等許多可邏輯劃分出來的部分。傳統(tǒng)的軟件并不區(qū)分這些，將它們?nèi)炕旌显谝欢纬绦蚶?。軟件架?gòu)的意義就是要將這些可邏輯劃分的部分獨立出來，用約定的接口和協(xié)議將它們有機地結(jié)合在一起，形成職責清晰、結(jié)構(gòu)明朗的軟件結(jié)構(gòu)。 2022年3月2日星期三第

18、39頁8.3 軟件架構(gòu)v3. 分析問題分析問題一個典型的軟件架構(gòu)包括兩個視角：廣度視角和深度視角。這兩個視角構(gòu)成對軟件架構(gòu)的“立體”描述。廣度視角即是我們常說的軟件層次結(jié)構(gòu)，它關(guān)注軟件的分層，規(guī)定每一層的職責以及層與層之間的通訊標準。一般使用包元素來描述。圖8-10展示了一個典型的多層架構(gòu)的層次模型。8.3 軟件架構(gòu)圖8-10 軟件層次的廣度視角架構(gòu)圖 8.3 軟件架構(gòu)另一方面，軟件架構(gòu)還需要描述深度視角。所謂深度視角，是指廣度視角中每一層的詳細說明，它關(guān)注每一層以及每個部分的具體實現(xiàn)架構(gòu)。例如可以針對業(yè)務(wù)實體層進行架構(gòu)描述，也可以針對XMLBean進行架構(gòu)描述。圖8-11展示了業(yè)務(wù)實體層的深

19、度視角視圖。 8.3 軟件架構(gòu)圖8-11 軟件層次深度視角架構(gòu)圖 8.3 軟件架構(gòu)廣度視角和深度視角將軟件架構(gòu)立體化了。層次構(gòu)成了廣度視角維度，而每一個層次的包、類的結(jié)構(gòu)構(gòu)成了深度視角維度。2022年3月2日星期三第44頁8.4 軟件架構(gòu)設(shè)計v1. 問題引入問題引入軟件架構(gòu)設(shè)計就是要將我們在業(yè)務(wù)架構(gòu)中設(shè)計出來的業(yè)務(wù)構(gòu)件有機地結(jié)合在一起協(xié)調(diào)工作。那么客戶服務(wù)系統(tǒng)的軟件架構(gòu)是怎樣的呢？ 2022年3月2日星期三第45頁8.4 軟件架構(gòu)設(shè)計v2. 解答問題解答問題客戶服務(wù)系統(tǒng)軟件架構(gòu)圖如圖8-12所示。2022年3月2日星期三第46頁DBWebServicesDaoDB ControlJDBCWeb

20、層用Struts框架，負責展現(xiàn)業(yè)務(wù)數(shù)據(jù)和人機交互，包括FormBean(ActionForm)和Action負責處自Web的Request，負責業(yè)務(wù)邏輯處理。接收來自Web的Request，將業(yè)務(wù)邏輯處理轉(zhuǎn)化成針對Value Object的增、刪、改、查，然后將處理完成的VO由Web展示給用戶Value ObjectValue Object是由Hibernate PO復(fù)合而成的一個POJO對象。針對特定的業(yè)務(wù)需求而設(shè)計。一個VO由多個PO組成，并可通過VO的getter和setter方法訪問實際PO值。VO是dao，services和web層之間的標準傳輸格式負責業(yè)務(wù)數(shù)據(jù)邏輯處理。將Value

21、 Object分解成Hibernate PO交由DB Control處理，或?qū)O組合成Value Object交由Services處理。HibernateHibernate是符合Hibernate框架規(guī)范的POJO，一個PO對應(yīng)一張數(shù)據(jù)表。PO在DB Control層生成，在Dao層組合成VO圖8-12 客戶服務(wù)系統(tǒng)軟件架構(gòu)圖 2022年3月2日星期三第47頁8.4 軟件架構(gòu)設(shè)計v3. 分析問題分析問題根據(jù)需求，客戶服務(wù)系統(tǒng)要求是B/S架構(gòu)的，即瀏覽器/服務(wù)器架構(gòu)。該架構(gòu)有許多優(yōu)點：客戶端無需安裝任何軟件，只要有瀏覽器就可以使用系統(tǒng)，方便客戶服務(wù)人員能即時處理客戶問題。當業(yè)務(wù)架構(gòu)確定后，至于

22、是選用.NET來實現(xiàn)還是選用J2EE來實現(xiàn)并不重要，主要依據(jù)開發(fā)團隊的技術(shù)素質(zhì)而定，以期達到最小項目風險和減少開發(fā)成本的目的。本節(jié)選用J2EE來描述客戶服務(wù)系統(tǒng)的軟件架構(gòu)分層模型，采用了MVC架構(gòu)體系，結(jié)合當前使用最成熟的Struts + Spring + Hibernate框架，如圖8-13所示。8.4 軟件架構(gòu)設(shè)計 表示層 Struts-MVC Action， ActionForm， JSP， Struts-config， XML 等 業(yè)務(wù)層 Spring Transactions Hibernate Session Management Business Service Classes

23、永久層 Hibernate DataSource /connection pool Query Language 等 提交服務(wù) Dao 類 領(lǐng)域模型業(yè)務(wù)對象 圖8-13 Struts+Spring+Hibernate框架圖 8.4 軟件架構(gòu)設(shè)計Struts + Spring + Hiberante框架的WEB應(yīng)用常常被擴展成4個各負其責的層次：表示層（Presentation）、業(yè)務(wù)層（Business）、持久層（Persistence）、領(lǐng)域模型層（Domain Model）。前三層分別對應(yīng)于Struts、Spring、Hibernate，而領(lǐng)域模型層則是由那些現(xiàn)實世界中的業(yè)務(wù)對象組成，如客

24、戶、咨詢、回訪、投訴等等，它們是在上面三個層之間傳遞的對象。每層職責明確，彼此獨立，通過專門編寫的接口傳遞消息。 8.4 軟件架構(gòu)設(shè)計客戶服務(wù)系統(tǒng)分為四個層次，其中WEB層采用Struts框架，Service和Dao采用Spring框架封裝客戶服務(wù)業(yè)務(wù)邏輯處理，DB Control層采用Hibernate框架。VO（Value Object，值對象）和PO（Persistant Object，持久對象）之間的關(guān)系及傳遞如圖8-14所示。 8.4 軟件架構(gòu)設(shè)計ServiceControlPOVORelationShip圖8-14 PO與VO之間實現(xiàn)關(guān)系 8.4 軟件架構(gòu)設(shè)計PO可以看成是與數(shù)據(jù)庫

25、中的表相映射的Java對象。一張數(shù)據(jù)庫表對應(yīng)一個Java對象。由Hibernate自動反轉(zhuǎn)生成，簡化Java與數(shù)據(jù)庫之間的操作。VO是由Hibernate PO復(fù)合而成的一個業(yè)務(wù)對象，用于業(yè)務(wù)層之間的數(shù)據(jù)傳遞。RelationShip維護組成VO與多個PO之間的對應(yīng)關(guān)系。Hibernate可維護PO之間的一對多，一對一，多對多等關(guān)系，但這些關(guān)系是指數(shù)據(jù)庫之間的關(guān)系。Relationship管理的是非數(shù)據(jù)庫的、業(yè)務(wù)邏輯要求的關(guān)系。ServiceControl是Service層訪問Dao層的接口。負責將PO組合成VO或?qū)O分解成PO。Service層通過ServiceControl來存取VO，同

26、時將分解出的PO傳遞給DBControl。 8.4 軟件架構(gòu)設(shè)計圖8-15以客戶服務(wù)系統(tǒng)查詢客戶來電咨詢記錄，同時顯示客戶資料信息為例，說明客戶服務(wù)系統(tǒng)架構(gòu)層次的動態(tài)實現(xiàn)。ServicesServiceControlDBControlRelationShipPOVO1: 查詢客戶咨詢記錄2: 查詢客戶咨詢記錄表3: 返回結(jié)果4: 組成VO5: get方法6: set方法7: 返回來電記錄VO8: 根據(jù)來電記錄，查找客戶信息9: 查詢客戶資料10: 根據(jù)客戶ID外鍵11: 返回客戶資料ID12: 查詢客戶資料13: 組成VO14: set方法15: 返回客戶咨詢記錄及客戶信息圖8-15 客戶服務(wù)

27、系統(tǒng)查詢客戶來電咨詢的動態(tài)實現(xiàn) 8.4 軟件架構(gòu)設(shè)計簡要說明：客戶服務(wù)人員首先發(fā)出“查詢客戶咨詢記錄”命令，系統(tǒng)查找到客戶咨詢記錄相關(guān)信息，并返回給ServiceControl，同時根據(jù)記錄在該表中的客戶資料ID的外鍵信息，到客戶資料信息表中查找相關(guān)客戶資料的詳細信息，最后將客戶資料信息和客戶來電記錄信息組合成VO返回到Service層，展示給客戶服務(wù)人員。 8.4 軟件架構(gòu)設(shè)計v下面分別對Struts、Spring和Hibernate作簡要介紹。8.4 軟件架構(gòu)設(shè)計v(1) StrutsStruts由一組相互協(xié)作的類、Servlet以及豐富的標記庫（jsp tag lib）和獨立于該框架工作

28、的實用程序類（Validator）組成。Struts有其自己的控制器（Controller），同時整合了其它的一些技術(shù)去實現(xiàn)模型層（Model）和視圖層（View）。在模型層，Struts可以很容易地與數(shù)據(jù)訪問技術(shù)相結(jié)合，包括EJB、JDBC和Object Relation Bridge。在視圖層，Struts能夠與JSP、Velocity Templates和XSL等等這些表示層組件想結(jié)合。Struts Framework是MVC 模式的體現(xiàn)，下面我們就分別從模型、視圖和控制來看看Struts的體系結(jié)構(gòu)（Architecture）。Struts Framework的體系結(jié)構(gòu)響應(yīng)客戶請求的時候

29、，各個部分的工作原理如圖8-16所示。8.4 軟件架構(gòu)設(shè)計圖8-16 Struts工作原理圖 8.4 軟件架構(gòu)設(shè)計v(2) SpringSpring 是一個開源框架，是為了解決企業(yè)級應(yīng)用程序開發(fā)的復(fù)雜性問題而創(chuàng)建的。框架的主要優(yōu)勢之一就是其分層架構(gòu)，分層架構(gòu)允許您選擇使用哪一個組件，同時為 J2EE 應(yīng)用程序開發(fā)提供集成的框架。Spring 框架是一個分層架構(gòu)，由 7 個定義良好的模塊組成。Spring 模塊構(gòu)建在核心容器之上，核心容器定義了創(chuàng)建、配置和管理 Bean 的方式，如圖8-17所示。8.4 軟件架構(gòu)設(shè)計圖8-17 Spring框架分層架構(gòu)圖 8.4 軟件架構(gòu)設(shè)計v(3) Hiber

30、nateHibernate是一個免費的開源Java包，它使得與關(guān)系數(shù)據(jù)庫打交道變得十分輕松，它是一個面向Java環(huán)境的對象/關(guān)系數(shù)據(jù)庫映射工具。對象/關(guān)系數(shù)據(jù)庫映射（object/relational mappin，ORM）這個術(shù)語表示一種技術(shù)，用來把對象模型表示的對象映射到基于SQL的關(guān)系模型數(shù)據(jù)結(jié)構(gòu)中去。Hibernate不僅管理Java類到數(shù)據(jù)庫表的映射（包括Java數(shù)據(jù)類型到SQL數(shù)據(jù)類型的映射），還提供數(shù)據(jù)查詢和獲取數(shù)據(jù)的方法，可以大幅度減少開發(fā)時人工使用SQL和JDBC處理數(shù)據(jù)的時間。 8.4 軟件架構(gòu)設(shè)計事實上，在一個基于數(shù)據(jù)庫的Web系統(tǒng)中，建立數(shù)據(jù)庫連接的操作將是系統(tǒng)中代價最

31、大的操作之一。很多時候，可能系統(tǒng)的速度瓶頸就在于此。Hibernate的目標是對于開發(fā)者通常的數(shù)據(jù)持久化相關(guān)的編程任務(wù)，解放其中的95，對于那些在基于Java的中間層應(yīng)用中，它們實現(xiàn)面向?qū)ο蟮臉I(yè)務(wù)模型和商業(yè)邏輯的應(yīng)用，Hibernate是最有用的。不管怎樣，Hibernate一定可以幫助我們消除或者包裝那些針對特定廠商的SQL代碼，并且?guī)臀覀儼呀Y(jié)果集從表格式的表示形式轉(zhuǎn)換到一系列的對象中去。 2022年3月2日星期三第63頁8.5 軟件架構(gòu)與框架v1. 問題引入問題引入現(xiàn)實中，很多人把架構(gòu)和框架搞混，有的人認為架構(gòu)和框架就是同一個東西，那么究竟兩者是否相同，如果不同，又有什么區(qū)別呢？ 2022

32、年3月2日星期三第64頁8.5 軟件架構(gòu)與框架v2. 解答問題解答問題架構(gòu)的英文原文是Architecture，而框架則是Framework。顯然是兩個完全不同的詞。從技術(shù)上講，IT有一個職業(yè)是架構(gòu)師，代表了軟件技術(shù)人員最高的職業(yè)，卻從沒有聽說過有軟件框架師的，所以肯定地說，軟件架構(gòu)和軟件框架是兩回事。架構(gòu)是一種思想，一個系統(tǒng)藍圖，是對系統(tǒng)高層次的定義和描述?？蚣苁轻槍δ硞€問題領(lǐng)域的通用解決方案，它通常集成了最佳實踐和可復(fù)用的基礎(chǔ)結(jié)構(gòu)，對開發(fā)工作起到減少工作量、指導(dǎo)和規(guī)范作用。2022年3月2日星期三第65頁8.5 軟件架構(gòu)與框架v3. 分析問題分析問題如果用建設(shè)一幢大樓來作比喻，架構(gòu)就是大樓

33、的結(jié)構(gòu)、外觀和功能性設(shè)計，它需要考慮的問題可以延伸到抗震性能、防火性能、防洪性能等；而框架是建設(shè)大樓過程中的一些成熟工藝的應(yīng)用，例如樓體成型、一次澆灌等。再舉一個例子，可以說架構(gòu)是戰(zhàn)略性的，它描述戰(zhàn)略目標、指揮系統(tǒng)、信息傳遞、職責、部署等；框架是戰(zhàn)術(shù)性的，它描述組織、建設(shè)、作戰(zhàn)方案、命令下達、戰(zhàn)術(shù)執(zhí)行等。我們可以說MVC是一種設(shè)計思想，它將應(yīng)用程序劃分為實體、控制和視圖三個邏輯部件，因此它是一個軟件架構(gòu)。而Struts，JSF，WEBWork等開源項目則分別以自己的方式實現(xiàn)了這一架構(gòu)，提供了一個半成品，幫助開發(fā)人員迅速地開發(fā)一個符合MVC架構(gòu)的應(yīng)用程序，因此可以說我們采用了Struts或JSF

34、或WEBWork軟件框架，開發(fā)出了符合MVC架構(gòu)的應(yīng)用程序。 8.6 軟件架構(gòu)的“41”視圖模型v1. 問題引入問題引入 軟件架構(gòu)用來處理軟件高層次結(jié)構(gòu)的設(shè)計和實施。它不是一維的，而是由多個同時存在的視圖構(gòu)成。它將若干結(jié)構(gòu)元素進行裝配，從而滿足系統(tǒng)主要功能和性能需求，并滿足其它非功能性需求，如可靠性、可伸縮性、可移植性和可用性等。那么，描述軟件架構(gòu)的這個“41”視圖究竟有哪些？它們有怎樣的交互作用？ 8.6 軟件架構(gòu)的“41”視圖模型v2. 解答問題解答問題軟件架構(gòu)“41”視圖模型及視圖間的交互關(guān)系如圖8-18所示。4個視圖為邏輯視圖、進程視圖、組件視圖和部署視圖，而用例視圖則為“1”的視圖。

35、 8.6 軟件架構(gòu)的“41”視圖模型 邏輯視圖 進程視圖 部署視圖 組件視圖 用例視圖 功能需求 性能 可伸縮性 生產(chǎn)能力 配置管理 分發(fā) 交付 安裝 圖8-18 軟件架構(gòu)“41”視圖模型 8.6 軟件架構(gòu)的“41”視圖模型v3. 分析問題分析問題在RUP中，軟件架構(gòu)的“41”視圖模型包括下列五個視圖：v(1) 用例視圖：包含用例和場景，這些用例和場景含有重要架構(gòu)行為、類或技術(shù)風險。它是用例模型的子集，用于描述用例、參與者和普通設(shè)計類的用例圖，描述設(shè)計對象及其協(xié)作的順序圖。v(2) 邏輯視圖：包含最重要的設(shè)計類、包和子系統(tǒng)中類的組織，以及各層中這些包和子系統(tǒng)的組織。它還包含某些用例實現(xiàn)，它是設(shè)

36、計模型的子集。邏輯視圖包含類圖、狀態(tài)圖和對象圖。 8.6 軟件架構(gòu)的“41”視圖模型v(3) 組件視圖：包含實施模型的概述，以及按模塊劃分為包和層的模型組織。還描述了從“邏輯視圖”將包和類分配到“組件視圖”中的包和組件。它是組件模型的子集，包含組件圖。v(4) 進程視圖：包含所涉及任務(wù)（進程和線程）的描述、任務(wù)的交互和配置以及從設(shè)計對象和類到任務(wù)的分配。僅當系統(tǒng)具有相當并行程度時，才需要使用該視圖。它是設(shè)計模型的子集，包含類圖和對象圖。 8.6 軟件架構(gòu)的“41”視圖模型v(5) 部署視圖：包含對最典型平臺配置的多個實際節(jié)點的描述，以及從“進程視圖”將任務(wù)分配到實際節(jié)點。僅當系統(tǒng)為分發(fā)式系統(tǒng)時

37、，才需要使用該視圖，它是部署模型的子集，包含部署圖。但對于一些簡單的系統(tǒng)，您可以省略其中包含的某些視圖。例如，如果只有一個處理器，則可以省略部署圖；如果只有一個進程或程序，則可以省略進程視圖。 8.7 組件圖v1. 問題引入問題引入在軟件建模過程中，使用用例圖可以推斷系統(tǒng)希望的行為；使用類圖可以描述系統(tǒng)中的詞匯；使用順序圖、組件圖、狀態(tài)圖和活動圖可以說明這些詞匯中的事物如何相互作用以完成某些行為。在完成系統(tǒng)的邏輯設(shè)計之后，下一步要定義設(shè)計的物理實現(xiàn)，在面向?qū)ο笙到y(tǒng)的物理方面進行建模時要用到兩種圖：組件圖和部署圖。其中，使用組件圖能夠可視化物理組件以及它們之間的關(guān)系，并描述其構(gòu)造細節(jié)。那么什么是

38、組件圖？客戶服務(wù)系統(tǒng)的組件圖是怎樣的？ 8.7 組件圖v2. 解答問題解答問題組件圖（Component Diagram）描述了軟件的各種組件和它們之間的依賴關(guān)系。組件圖中通常包含3種元素：組件（Component）、接口（Interface）和依賴關(guān)系（Dependency）。每個組件實現(xiàn)一些接口，并使用另一些接口。如果組件間的依賴關(guān)系與接口有關(guān)，那么可以被具有同樣接口的其他組件所替代。(1) 客戶服務(wù)系統(tǒng)中的頁面級組件圖，如圖8-19所示。 DataServiceCustomerServiceSystemConsultationMaintainCustomerInfoMaintainSys

39、temServiceLoginExperienceBaseMaintainUserInfoMaintainMissionMaintain圖8-19 客戶服務(wù)系統(tǒng)中的頁面級組件圖 8.7 組件圖(2) 客戶服務(wù)系統(tǒng)的代碼級組件圖（部分組件），如圖8-20所示。8.7 組件圖CustomerCustomerTelCustomerTypeCustomerVisitOperatorProductTelStatusTelTypeVisitStatusVisitType8.7 組件圖IBasedaoIBasedaoBaseDaoMenuDAOMenuPurviewDAOOperatorRoleDAOPur

40、viewDAORoleDAORoleMenuDAOOperatorDAO圖8-20 客戶服務(wù)系統(tǒng)中的代碼級組件圖 8.7 組件圖v3. 分析問題分析問題所謂業(yè)務(wù)架構(gòu)，實際上就是在對需求細致分析和深刻理解的基礎(chǔ)上，抽象出若干相對獨立的業(yè)務(wù)模塊，形成自洽的業(yè)務(wù)組件。這些組件對內(nèi)可以完成一個或一組特定的業(yè)務(wù)功能，對外則有著完善的接口，可以與其他組件共同組成更為復(fù)雜的業(yè)務(wù)功能，直至構(gòu)成整個系統(tǒng)。 8.7 組件圖組件（Component）是定義了良好接口的物理實現(xiàn)單元，是系統(tǒng)中可替換的物理部件。一般情況下，組件表示將類、接口等邏輯元素打包而形成的物理模塊。它可以是軟件代碼（源代碼、二進制代碼或可執(zhí)行代碼

41、）或其等價物（如腳本或命令文件）。在UML中，組件用一個左側(cè)帶有兩個突出小矩形的矩形框來表示，如圖8-20中的標有“Customer”的組件，其中Customer是組件名。組件之間的虛線箭頭表示組件間的依賴關(guān)系。將組件通過一條實線相連的圓圈被稱為接口，如圖8-20中的“IBasedao”即為接口。 8.7 組件圖建模過程中，我們通過組件這一元素對分析設(shè)計過程中的類、接口等進行邏輯分類，一個組件表達軟件的一組功能。組件在很多方面與類相同：兩者都有名稱；都可以實現(xiàn)一組接口；都可以參與依賴關(guān)系；都可以被嵌套；都可以有實例；都可以參與交互。但是類和組件之間也存在著差別：類描述了軟件設(shè)計的邏輯組織和意圖

42、，而組件則描述軟件設(shè)計的物理實現(xiàn)，即每個組件體現(xiàn)了系統(tǒng)設(shè)計中特定類的實現(xiàn)。 8.7 組件圖組件圖的一般建模步驟如下：v(1) 確定組件。首先要分解系統(tǒng)，考慮有關(guān)系統(tǒng)的組成管理、軟件的重用和物理節(jié)點的配置等因素，把關(guān)系密切的可執(zhí)行程序和對象庫分別歸入組件，找出相應(yīng)的對象類、接口等模型元素。v(2) 對組件加上必要的構(gòu)造型。可以使用UML的標準構(gòu)造型executable、library、table、file、document，或自定義新的構(gòu)造型，說明組件的性質(zhì)。v(3) 確定組件之間的關(guān)系。最常見的組件之間的關(guān)系是接口依賴。一個組件使用某個接口，另一個組件實現(xiàn)該接口。v(4) 必要時把組件組織成包

43、。組件和對象類等模型元素一樣可以組織成包，如圖8-21所示的客戶服務(wù)系統(tǒng)組件包。v (5) 繪制組件圖。 圖8-21 客戶服務(wù)系統(tǒng)的組件結(jié)構(gòu) 8.8 部署圖v1. 問題引入問題引入上節(jié)提到對系統(tǒng)的物理方面進行建模時要用到兩種圖：組件圖和部署圖，并且已經(jīng)對組件圖做了介紹，本節(jié)將介紹部署圖的概念及客戶服務(wù)系統(tǒng)的部署圖。 8.8 部署圖v2. 解答問題解答問題部署圖（Deployment Diagram）描述了運行軟件的系統(tǒng)中硬件和軟件的物理結(jié)構(gòu)，即系統(tǒng)執(zhí)行處理過程中系統(tǒng)資源的部署情況以及軟件到這些資源的映射。部署圖中通常包含兩種元素：節(jié)點（Node）和關(guān)聯(lián)（Association）?？蛻舴?wù)系統(tǒng)的部署圖，如圖8-22所示。 數(shù)據(jù)庫服務(wù)器應(yīng)用服務(wù)器系統(tǒng)為三層架構(gòu)，應(yīng)用服務(wù)器負責整個系統(tǒng)的總體協(xié)調(diào)工作，數(shù)據(jù)庫服務(wù)器負責數(shù)據(jù)管理。管理員登錄維護人員登錄部門領(lǐng)導(dǎo)登錄客服人員登錄圖8-22 客戶服務(wù)系統(tǒng)部署圖 8.8 部署圖v3. 分析問題分析問題部署圖考慮應(yīng)用程序的物理部署，如網(wǎng)絡(luò)布局和組件在網(wǎng)絡(luò)上的位置的問題。部署圖包含處理器、設(shè)備、進程和處理器與設(shè)備之間的連接。這一切都顯示在部署圖上。每個系統(tǒng)只有一個部署圖，因此每個Rose模型也只有一個部署圖。 8.8 部署圖節(jié)點（Node）是在運行時代表計算資源的物理元