軟件設(shè)計(jì)模式實(shí)驗(yàn)報(bào)告

1、應(yīng)用 4+1 視圖法及 UML設(shè)計(jì)軟件體系架構(gòu)及設(shè)計(jì)模式實(shí)踐一實(shí)驗(yàn)?zāi)康耐ㄟ^對(duì)實(shí)際案例進(jìn)行軟件設(shè)計(jì)來掌握軟件體系架構(gòu)模式的選擇應(yīng)用以及典型 4+1 視圖軟件架構(gòu)設(shè)計(jì)方法的應(yīng)用，并能熟練掌握如何利用Rational Rose軟件進(jìn)行軟件架構(gòu)設(shè)計(jì)。二實(shí)驗(yàn)內(nèi)容(1) 根據(jù)“信用卡申請(qǐng)件處理外包業(yè)務(wù)處理平臺(tái)設(shè)計(jì)” 需求選定軟件體系結(jié)構(gòu)模式(2) 利用 UML軟件進(jìn)行 4+1 視圖架構(gòu)設(shè)計(jì)，包括邏輯視圖、開發(fā)視圖、進(jìn)程視圖、物理視圖和場(chǎng)景視圖。 A 邏輯視圖描述系統(tǒng)的功能需求，系統(tǒng)分解成一系列的功能抽象，采用時(shí)序圖、協(xié)作圖、類圖等來表示；B 開發(fā)視圖描述軟件在開發(fā)環(huán)境下的靜態(tài)組織。開發(fā)視圖關(guān)注程序包，應(yīng)用

2、的統(tǒng)一框架，引用的類庫、 SDK和中間件，以及工程和包的劃分規(guī)則等，規(guī)范、約束開發(fā)環(huán)境的結(jié)構(gòu)；C 進(jìn)程試圖側(cè)重系統(tǒng)的運(yùn)行特性，關(guān)注非功能性的需求（性能，可用性）。服務(wù)于系統(tǒng)集成人員，方便后續(xù)性能測(cè)試。強(qiáng)調(diào)并發(fā)性、分布性、集成性、魯棒性（容錯(cuò)） 、可擴(kuò)充性、吞吐量等。定義邏輯視圖中的各個(gè)類的具體操作是在哪一個(gè)進(jìn)程和線程中被執(zhí)行， 可以組件圖為基礎(chǔ)表示；D 物理試圖主要描述硬件配置。服務(wù)于系統(tǒng)工程人員，解決系統(tǒng)的拓?fù)浣Y(jié)構(gòu)、系統(tǒng)安裝、通信等問題。主要考慮如何把軟件映射到硬件上，也要考慮系統(tǒng)性能、規(guī)模、可靠性等。可以與進(jìn)程視圖一起映射；E 場(chǎng)景用于刻畫構(gòu)件之間的相互關(guān)系，將四個(gè)視圖有機(jī)地聯(lián)系起來。.可

3、以描述一個(gè)特定的視圖內(nèi)的構(gòu)件關(guān)系，也可以描述不同視圖間的構(gòu)件關(guān)系。通常用Use Case 圖來描述。(3) 設(shè)計(jì)模式的實(shí)踐， 從創(chuàng)建者模式、 結(jié)構(gòu)型模式和行為模式三大類模式進(jìn)行對(duì)象設(shè)計(jì)， 每種類型的模式至少應(yīng)用一種， 并用應(yīng)用了設(shè)計(jì)模式后的類設(shè)計(jì)修訂邏輯視圖中的類圖。三 SOA 架構(gòu)模式及流程分析（湛濱瑜）3.1 SOA 架構(gòu)介紹SOA是英文 Service-Oriented Architecture，即面向服務(wù)架構(gòu)的縮寫。面向服務(wù)的體系結(jié)構(gòu)（ service-oriented architecture，SOA）是一個(gè)組件模型，它將應(yīng)用程序的不同功能單元 （稱為服務(wù)） 通過這些服務(wù)之間定義良好

4、的接口和契約聯(lián)系起來。 接口是采用中立的方式進(jìn)行定義的， 它應(yīng)該獨(dú)立于實(shí)現(xiàn)服務(wù)的硬件平臺(tái)、 操作系統(tǒng)和編程語言。 這使得構(gòu)建在各種這樣的系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進(jìn)行交互。這種具有中立的接口定義（沒有強(qiáng)制綁定到特定的實(shí)現(xiàn)上）的特征稱為服務(wù)之間的松耦合。松耦合系統(tǒng)的好處有兩點(diǎn)，一點(diǎn)是它的靈活性，另一點(diǎn)是，當(dāng)組成整個(gè)應(yīng)用程序的每個(gè)服務(wù)的內(nèi)部結(jié)構(gòu)和實(shí)現(xiàn)逐漸地發(fā)生改變時(shí)，它能夠繼續(xù)存在。而另一方面，緊耦合意味著應(yīng)用程序的不同組件之間的接口與其功能和結(jié)構(gòu)是緊密相連的， 因而當(dāng)需要對(duì)部分或整個(gè)應(yīng)用程序進(jìn)行某種形式的更改時(shí)，它們就顯得非常脆弱。對(duì)松耦合的系統(tǒng)的需要來源于業(yè)務(wù)應(yīng)用程序需要根據(jù)業(yè)務(wù)的

5、需要變得更加靈活，以適應(yīng)不斷變化的環(huán)境，比如經(jīng)常改變的政策、業(yè)務(wù)級(jí)別、業(yè)務(wù)重點(diǎn)、合作伙伴關(guān)系、行業(yè)地位以及其他與業(yè)務(wù)有關(guān)的因素，這些因素甚至?xí)绊憳I(yè)務(wù)的性質(zhì)。我們稱能夠靈活地適應(yīng)環(huán)境變化的業(yè)務(wù)為按需（On demand）業(yè)務(wù)，在按需業(yè)務(wù)中，一旦需要，就可以對(duì)完成或執(zhí)行任務(wù)的方式進(jìn)行必要的更改。SOA三大基本特征.1、獨(dú)立的功能實(shí)體在 Internet 這樣松散的使用環(huán)境中，任何訪問請(qǐng)求都有可能出錯(cuò)，因此任何企圖通過 Internet 進(jìn)行控制的結(jié)構(gòu)都會(huì)面臨嚴(yán)重的穩(wěn)定性問題。 SOA非常強(qiáng)調(diào)架構(gòu)中提供服務(wù)的功能實(shí)體的完全獨(dú)立自主的能力。傳統(tǒng)的組件技術(shù)，如.NET Remoting ，EJB，CO

6、M或者 CORBA，都需要有一個(gè)宿主 (Host 或者 Server) 來存放和管理這些功能實(shí)體； 當(dāng)這些宿主運(yùn)行結(jié)束時(shí)這些組件的壽命也隨之結(jié)束。 這樣當(dāng)宿主本身或者其它功能部分出現(xiàn)問 題的時(shí)候，在該宿主上運(yùn)行的其它應(yīng)用服務(wù)就會(huì)受到影響。SOA架構(gòu)中非常強(qiáng)調(diào)實(shí)體自我管理和恢復(fù)能力。常見的用來進(jìn)行自我恢復(fù)的技術(shù)，比如事務(wù)處理 (Transaction) ，消息隊(duì)列 (Message Queue) ，冗余部署 (R edundant Deployment) 和集群系統(tǒng) (Cluster) 在 SOA中都起到至關(guān)重要的作用。2、大數(shù)據(jù)量低頻率訪問對(duì)于 .NET Remoting ，EJB或者 XML

7、-RPC這些傳統(tǒng)的分布式計(jì)算模型而言，他們的服務(wù)提供都是通過函數(shù)調(diào)用的方式進(jìn)行的，一個(gè)功能的完成 往往需要通過客戶端和服務(wù)器來回很多次函數(shù)調(diào)用才能完成。在 Intranet 的環(huán)境下，這些調(diào)用給系統(tǒng)的響應(yīng)速度和穩(wěn)定性帶來的影響都可以忽略不計(jì)，但是在 Internet環(huán)境下這些因素往往是決定整個(gè)系統(tǒng)是否能正常工作的一個(gè)關(guān)鍵決定因素。 因此SOA系統(tǒng)推薦采用大數(shù)據(jù)量的方式一次 性進(jìn)行信息交換。3、基于文本的消息傳遞由于 Internet 中大量異構(gòu)系統(tǒng)的存在決定了 SOA系統(tǒng)必須采用基于文本而非二進(jìn)制的消息傳遞方式。 在 COM、CORBA這些傳統(tǒng)的組件模型中， 從服務(wù)器端傳往客戶端的是一個(gè)二進(jìn)制

8、編碼的對(duì)象， 在客戶端通過調(diào)用這個(gè)對(duì)象的方法來完成某些功能；但是在 Internet 環(huán)境下，不同語言， 不同平臺(tái)對(duì)數(shù)據(jù)、甚至是一些基本數(shù)據(jù)類型定義不同， 給不同的服務(wù)之間傳遞對(duì)象帶來的很大困難。 由于基于文本的消息本身是不包含任何處 理邏輯和數(shù)據(jù)類型的，因此服務(wù)間只傳遞文本，對(duì)數(shù)據(jù)的處理依賴于接收端的方式可以幫忙繞過兼容性這個(gè)的大泥坑。.3.2 信用卡申請(qǐng)件外包處理流程分析信用卡申請(qǐng)件外包處理的主要流程為：第一階段：信用卡申請(qǐng)人準(zhǔn)備個(gè)人檔案資料并接件提交， 將所有接受的檔案文件通過拆件、然后再分類整理后， 給申請(qǐng)人的檔案資料帖上條形碼標(biāo)識(shí)。 在影像處理過程中，通過電子掃描設(shè)備將檔案條形碼掃人

9、， 經(jīng)過對(duì)檔案文件的質(zhì)量檢測(cè)和影像的切分后將數(shù)據(jù)信息傳輸給外包中心做數(shù)據(jù)處理。第二階段：外包中心接受到影像處理階段傳遞的數(shù)據(jù)信息后， 通過任務(wù)分配環(huán)節(jié)將傳遞過來的數(shù)據(jù)信息錄入， 兩次錄入完成后， 進(jìn)入一個(gè)重要的復(fù)核環(huán)節(jié)。 如果復(fù)核匹配失敗，則進(jìn)入第三人復(fù)核階段， 如果第三人復(fù)核成功， 在確保數(shù)據(jù)錄入的準(zhǔn)確無誤后進(jìn)入影像匹配階段。 如果第三人復(fù)核失敗， 則將問題交由專門的人員來處理解決。通過影像匹配環(huán)節(jié)將數(shù)據(jù)歸檔處理。 供工作人員查詢使用。 同時(shí)將數(shù)據(jù)回傳遞給銀行信用卡數(shù)據(jù)中心。第三階段：銀行信用卡數(shù)據(jù)中心，接受到數(shù)據(jù)，并保存。四 4+1視圖（張獻(xiàn)忠）和設(shè)計(jì)模式（李金栓）4.1 4+1視圖介紹軟

10、件架構(gòu)用來處理軟件高層次結(jié)構(gòu)的設(shè)計(jì)和實(shí)施。它以精心選擇的形式將若干結(jié)構(gòu)元素進(jìn)行裝配，從而滿足系統(tǒng)主要功能和性能需求，并滿足其他非功能性需求，如可靠性、可伸縮性、可移植性和可用性。 Perry 和 Wolfe 使用一個(gè)精確的公式來表達(dá)， 該公式由 Boehm 做了進(jìn)一步修改：軟件架構(gòu) 元素，形式，關(guān)系/ 約束 軟件架構(gòu)涉及到抽象、 分解和組合、 風(fēng)格和美學(xué)。 我們用由多個(gè)視圖或視角組成的模型來描述它。為了最終處理大型的、富有挑戰(zhàn)性的架構(gòu)，該模型包含五個(gè)主要的視圖.邏輯視圖（ Logical View），設(shè)計(jì)的對(duì)象模型（使用面向?qū)ο蟮脑O(shè)計(jì)方法時(shí)）。過程視圖（ Process View ），捕捉設(shè)計(jì)

11、的并發(fā)和同步特征。物理視圖（ Physical View），描述了軟件到硬件的映射，反映了分布式特性。開發(fā)視圖（ Development View ），描述了在開發(fā)環(huán)境中軟件的靜態(tài)組織結(jié)構(gòu)。架構(gòu)的描述， 即所做的各種決定， 可以圍繞著這四個(gè)視圖來組織，然后由一些用例（ usecases ）或場(chǎng)景 (scenarios)來說明， 從而形成了第五個(gè)視圖。正如將看到的，實(shí)際上軟件架構(gòu)部分從這些場(chǎng)景演進(jìn)而來，我們?cè)诿總€(gè)視圖上均獨(dú)立地應(yīng)用Perry& Wolf的公式，即定義一個(gè)所使用的元素集合（組件、容器、連接符），捕獲工作形式和模式，并且捕獲關(guān)系及約束， 將架構(gòu)與某些需求連接起來。每種視圖使用

12、自身所特有的表示法藍(lán)圖（ blueprint）來描述，并且架構(gòu)師可以對(duì)每種視圖選用特定的架構(gòu)風(fēng)格（architecturalstyle ），從而允許系統(tǒng)中多種風(fēng)格并存。我們將輪流的觀察這五種視圖，展現(xiàn)各個(gè)視圖的目標(biāo)：即視圖的所關(guān)注的問題，相應(yīng)的架構(gòu)藍(lán)圖的標(biāo)記方式，描述和管理藍(lán)圖的工具。并以非常簡單的形式從PABX 的設(shè)計(jì)中， 從我們?cè)?Alcatel商業(yè)系統(tǒng)（ Alcatel Business System）上所做的工作中，以及從航空運(yùn)輸控制系統(tǒng)（ AirTrafficControlsystem ）中引出一些例子旨在描述一下視圖的特定及其標(biāo)記的方式，而不是定義這些系統(tǒng)的架構(gòu)。"4+1"視圖模型具有相當(dāng)?shù)?quot; 普遍性 &quo