系統(tǒng)分析師之軟件工程云計(jì)算體系結(jié)構(gòu)組成資源層資源層是指基礎(chǔ)架構(gòu)層間的云計(jì)算服務(wù)這些服務(wù)可以提供虛擬化的資源從而隱藏物理資源的復(fù)雜性。如服務(wù)器存儲(chǔ)平臺(tái)層為用戶提供對(duì)資源層服務(wù)的封裝使用戶可以構(gòu)建自己的應(yīng)用。應(yīng)用層提供軟件服務(wù)如財(cái)務(wù)管理客戶關(guān)系管理商業(yè)智能用戶訪問層方便用戶使用云計(jì)算服務(wù)所需的各種支撐服務(wù)針對(duì)每個(gè)層次的云計(jì)算服務(wù)都需要提供相應(yīng)的訪問接口。管理層提供對(duì)所有層次云計(jì)算服務(wù)的管理功能。云計(jì)算的使用場景云計(jì)算是一種基于并高度依賴Internet用戶與實(shí)際服務(wù)提供的計(jì)算資源相分離集合了大量計(jì)算設(shè)備和資源并向用戶屏蔽底層差異的分布式處理架構(gòu)。一般地當(dāng)有以下需求時(shí)可以考慮使用云計(jì)算服務(wù)短時(shí)間內(nèi)的中、大規(guī)模計(jì)算需求代建系統(tǒng)前期投入低并且總體擁有成本較優(yōu)在充分相信云計(jì)算服務(wù)提供商的情況下的數(shù)據(jù)安全性需求在沒有足夠的服務(wù)器管理和 運(yùn)維人員在終端設(shè)備配置較差的情況下完成較復(fù)雜的應(yīng)用。WS-BPEL業(yè)務(wù)流程編排Web Services Business Process Execution Language可以理解成把多個(gè)Web Service串起來組成一個(gè)完整業(yè)務(wù)流程。IDEFIntegration DEFinition method,集成定義方法建模方法IDEF是一系列建模、分析和仿真方法的統(tǒng)稱每套方法都是通過建模來獲得某種特定類型的信息。軟件開發(fā)模型傳統(tǒng)軟件開發(fā)模型大體上可分為三種類型1以軟件需求完全確定為前提的瀑布模型2在軟件開發(fā)初始階段只能提供基本需求時(shí)采用的迭代式或漸進(jìn)式開發(fā)模型例如噴泉模型、螺旋模型、統(tǒng)一開發(fā)過程和敏捷方法等3以形式化開發(fā)方法為基礎(chǔ)的變換模型。The Firset Model:瀑布模型瀑布模型是一種嚴(yán)格定義方法它將軟件開發(fā)的過程分為軟件計(jì)劃、需求分析、軟件設(shè)計(jì)、程序編碼、軟件測試和運(yùn)行維護(hù)6個(gè)階段形如瀑布流水最終得到軟件產(chǎn)品。瀑布模型是一個(gè)線性順序模型支持線性開發(fā)。它假設(shè)當(dāng)線性序列完成之后就能交付一個(gè)完善的系統(tǒng)并沒有考慮軟件的演化特征。其優(yōu)點(diǎn)是強(qiáng)調(diào)開發(fā)的階段性、早期計(jì)劃和需求調(diào)查以及產(chǎn)品測試以這樣嚴(yán)格的方式構(gòu)造軟件開發(fā)人員很清楚每一步應(yīng)該怎么做有利于項(xiàng)目管理。缺點(diǎn)對(duì)于風(fēng)險(xiǎn)的控制能力較弱The Second Model:演化模型演化模型主要針對(duì)事先不能完整定義需求的軟件開發(fā)是在快速開發(fā)一個(gè)原型的基礎(chǔ)上根據(jù)用戶在調(diào)用原型的過程中提出的反饋意見和建議對(duì)原型進(jìn)行改進(jìn)獲得原型的新版本重復(fù)這一過程直到演化成最終的軟件產(chǎn)品。優(yōu)點(diǎn)任何功能一經(jīng)開發(fā)就能進(jìn)入測試以便驗(yàn)證是否符合產(chǎn)品需求可以幫助引導(dǎo)出高質(zhì)量的產(chǎn)品要求。缺點(diǎn)如果不加控制地讓用戶接觸開發(fā)中尚未穩(wěn)定地功能可能會(huì)對(duì)開發(fā)人員和用戶都會(huì)產(chǎn)生負(fù)面的影響。The Third Model:螺旋模型螺旋模型是瀑布模型與演化模型相結(jié)合并加入兩者所忽略的風(fēng)險(xiǎn)分析所建立的一種軟件開發(fā)模型。螺旋模型是一種演化軟件過程模型它將原型實(shí)現(xiàn)的迭代特征與線性順序模型中的控制和系統(tǒng)化的方面結(jié)合起來使軟件的增量版本的快速開發(fā)成為可能。在螺旋模型中軟件開發(fā)使一系列的增量發(fā)布。優(yōu)點(diǎn)強(qiáng)調(diào)風(fēng)險(xiǎn)分析適用于龐大、復(fù)雜并具有高風(fēng)險(xiǎn)的系統(tǒng)缺點(diǎn)過多的迭代次數(shù)會(huì)增加開發(fā)成本延遲提交時(shí)間。The Fourth Model噴泉模型噴泉模型是一種以用戶需求為動(dòng)力以對(duì)象為驅(qū)動(dòng)的模型主要用于描述面向?qū)ο蟮能浖_發(fā)過程。各活動(dòng)之間沒有明顯的邊界The Fifth ModelV模型V模型是在快速應(yīng)用開發(fā)的基礎(chǔ)上演變而來的應(yīng)用在軟件測試方面V模型強(qiáng)調(diào)軟件開發(fā)的協(xié)作和速度將軟件實(shí)現(xiàn)和驗(yàn)證有機(jī)地結(jié)合起來在保證較高地軟件質(zhì)量的情況下縮短開發(fā)周期。V模型適合企業(yè)級(jí)的軟件開發(fā)它更清楚地揭示了軟件開發(fā)過程的特性及其本質(zhì)?？焖賾?yīng)用開發(fā)快速應(yīng)用開發(fā)Rapid Application DevelopmentRAD是一種比傳統(tǒng)生命周期法快得多的開發(fā)方法它強(qiáng)調(diào)極短的開發(fā)周期。RAD模型是瀑布模型的一個(gè)高速變種通過使用基于構(gòu)件的開發(fā)方法獲得快速開發(fā)。RAD的基本思想讓用戶更主動(dòng)地參與到系統(tǒng)分析、設(shè)計(jì)和構(gòu)造活動(dòng)中來。將項(xiàng)目開發(fā)組織成一系列重點(diǎn)突出的研討會(huì)研討會(huì)要讓項(xiàng)目投資方、用戶、系統(tǒng)分析師、設(shè)計(jì)人員和開發(fā)人員一起參與。通過一種迭代的構(gòu)造方法加速需求分析和設(shè)計(jì)階段。讓用戶看到一個(gè)可工作的系統(tǒng)。敏捷方法數(shù)據(jù)庫設(shè)計(jì)的四個(gè)階段需求分析概念結(jié)構(gòu)設(shè)計(jì)邏輯結(jié)構(gòu)設(shè)計(jì)物理設(shè)計(jì)系統(tǒng)設(shè)計(jì)的主要內(nèi)容包括概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)。概要設(shè)計(jì)又稱為系統(tǒng)總體結(jié)構(gòu)設(shè)計(jì)它是系統(tǒng)開發(fā)過程中很關(guān)鍵的一步其主要任務(wù)是將系統(tǒng)的功能需求分配給軟件模塊確定每個(gè)模塊的功能和調(diào)用關(guān)系形成軟件的模塊結(jié)構(gòu)圖即系統(tǒng)結(jié)構(gòu)圖。在概要設(shè)計(jì)中將系統(tǒng)開發(fā)的總?cè)蝿?wù)分解成許多個(gè)基本的、具體的任務(wù)為每個(gè)具體的任務(wù)選擇適當(dāng)?shù)募夹g(shù)手段和處理方法的過程稱為詳細(xì)設(shè)計(jì)。根據(jù)任務(wù)的不同詳細(xì)設(shè)計(jì)又可分很多種例如網(wǎng)絡(luò)設(shè)計(jì)、代碼設(shè)計(jì)、輸入/輸出設(shè)計(jì)、處理流程設(shè)計(jì)、數(shù)據(jù)存儲(chǔ)設(shè)計(jì)、用戶界面設(shè)計(jì)、安全性和可靠性設(shè)計(jì)等。軟件的逆向工程工作流參考模型工作流管理系統(tǒng)的基本功能軟件能力成熟度模型UML中事物之間的關(guān)系關(guān)系英文核心含義典型關(guān)鍵詞UML表示依賴Dependency臨時(shí)使用使用虛線箭頭關(guān)聯(lián)Association長期存在聯(lián)系擁有/知道實(shí)線聚合Aggregation弱“整體—部分”包含空心菱形組合Composition強(qiáng)“整體—部分”共存亡實(shí)心菱形泛化Generalization繼承is-a是一種實(shí)線空心三角實(shí)現(xiàn)Realization實(shí)現(xiàn)接口implements虛線空心三角UML的14種圖① 依賴 DependencyA - - - - - B虛線普通箭頭② 關(guān)聯(lián) AssociationA ───────── B實(shí)線③ 聚合 Aggregation整體 ◇────── 部分空心菱形④ 組合 Composition整體 ◆────── 部分實(shí)心菱形⑤ 泛化 Generalization子類 ───────? 父類實(shí)線空心三角⑥ 實(shí)現(xiàn) Realization實(shí)現(xiàn)類 - - -? 接口虛線空心三角兩個(gè)類是什么關(guān)系│├── A是一種B嗎│ ↓ 是│ 泛化│├── A實(shí)現(xiàn)某接口嗎│ ↓ 是│ 實(shí)現(xiàn)│├── A是B的一部分嗎│ ↓│ 整體沒了部分還能存在│ ││ ┌───┴───┐│ ↓ ↓│ 能 不能│ ↓ ↓│ 聚合 組合│├── 兩者存在穩(wěn)定業(yè)務(wù)聯(lián)系│ ↓│ 關(guān)聯(lián)│└── 只是臨時(shí)調(diào)用/使用↓依賴UML的5個(gè)系統(tǒng)視圖需求獲取在軟件工程中需求獲取是非常重要的環(huán)節(jié)它需要開展一系列活動(dòng)來獲取正確的需求。通常軟件需求獲取的過程包括評(píng)審和完全理解系統(tǒng)需求和安全需求。軟件工程師必須對(duì)系統(tǒng)需求非常熟悉。對(duì)初始安全評(píng)估的理解也是掌握安全驅(qū)動(dòng)力所必需的。與客戶、系統(tǒng)工程師、領(lǐng)域?qū)＜疫M(jìn)行會(huì)談回答系統(tǒng)需求中的問題并補(bǔ)充遺漏的系統(tǒng)需求。在撰寫軟件需求前確定系統(tǒng)需求和安全需求的成熟度和完整度。與系統(tǒng)工程師一起改進(jìn)系統(tǒng)需求。在軟件組把系統(tǒng)需求細(xì)化為軟件需求之前系統(tǒng)需求必須應(yīng)該相對(duì)成熟和穩(wěn)定。復(fù)用過去相關(guān)項(xiàng)目的需求并考查這些項(xiàng)目的問題報(bào)告。定義初步的術(shù)語表以保持需求陳述的術(shù)語的一致性避免項(xiàng)目成員對(duì)術(shù)語的使用及其含義產(chǎn)生誤解減少二義性。所有其他文檔的文字說明中都應(yīng)該始終如一地使用術(shù)語表中的術(shù)語。而軟件設(shè)計(jì)過程活動(dòng)的要求包括在設(shè)計(jì)過程期間開發(fā)的低級(jí)需求和軟件體系結(jié)構(gòu)要符合軟件設(shè)計(jì)標(biāo)準(zhǔn)并且是可追蹤、可驗(yàn)證和一致的。要定義和分析派生的需求并保證不損害高級(jí)需求。軟件設(shè)計(jì)過程的活動(dòng)可能引入失效模式到軟件中或相反地影響其他的軟件。在軟件設(shè)計(jì)中采用劃分或其他結(jié)構(gòu)方法可改變某些軟件部件的軟件等級(jí)的分配。在這些情況下將定義附加資料作為派生需求并把這些資料提供給系統(tǒng)安全性評(píng)估過程。當(dāng)規(guī)定與安全相關(guān)的需求時(shí)要監(jiān)控控制流和數(shù)據(jù)流如看門狗定時(shí)器、合理的檢查和交叉通道比較。對(duì)失效狀態(tài)的響應(yīng)要與安全性有關(guān)的要求一致。在軟件設(shè)計(jì)過程中檢測到的不合適的或不正確的輸入將提供給 系統(tǒng)的生存周期過程、軟件需求過程或軟件測試過程作為澄清或糾正的反饋。用例VS類用例描述“系統(tǒng)要為用戶做什么”類描述“系統(tǒng)內(nèi)部由什么組成”。23種設(shè)計(jì)模式遺留系統(tǒng)的再利用問題軟件開發(fā)方法、軟件開發(fā)模型和軟件設(shè)計(jì)方法軟件工程 / 信息系統(tǒng)開發(fā)│├── ① 系統(tǒng)開發(fā)方法│ ├── 結(jié)構(gòu)化方法│ ├── 原型化方法│ ├── 面向?qū)ο蠓椒ī?└── 面向服務(wù)方法 SOA│├── ② 軟件開發(fā)模型│ ├── 瀑布模型│ ├── V模型│ ├── 原型模型│ ├── 增量模型│ ├── 螺旋模型│ └── 敏捷開發(fā)│├── ③ 軟件開發(fā)方法/敏捷方法│ ├── XP│ ├── Scrum│ ├── Crystal│ └── FDD等│└── ④ 軟件設(shè)計(jì)方法├── 結(jié)構(gòu)化設(shè)計(jì)├── 面向?qū)ο笤O(shè)計(jì)├── UML├── 設(shè)計(jì)原則└── 設(shè)計(jì)模式軟件工程軟件生命周期軟件定義時(shí)期├─問題定義├─可行性研究└─需求分析軟件開發(fā)時(shí)期├─概要設(shè)計(jì)├─詳細(xì)設(shè)計(jì)├─編碼└─測試軟件運(yùn)行維護(hù)時(shí)期└─運(yùn)行、維護(hù)、升級(jí)、退役CMM成熟度等級(jí)軟件重用和再工程