軟件需求分析與設(shè)計－緒論

1、軟件需求分析與設(shè)計緒論軟件分析與設(shè)計緒論主要內(nèi)容OOA/D的根本概念迭代開發(fā)案例引進(jìn)9/22/20222軟件分析與設(shè)計根本概念分析是對問題和需求的調(diào)查研究，不強(qiáng)調(diào)解決問題在面向?qū)ο蠓治鲞^程中強(qiáng)調(diào)的是在問題領(lǐng)域發(fā)現(xiàn)和描述對象設(shè)計滿足需求的概念上的解決方案，不強(qiáng)調(diào)實現(xiàn)面向?qū)ο蟮姆治鰪?qiáng)調(diào)的是定義軟件對象以及他們?nèi)绾螀f(xié)作以實現(xiàn)需求9/22/20223面向?qū)ο蠓治龅膸讉€問題9/22/20224面向?qū)ο蟮姆治瞿Ｐ秃瓦^程9/22/20225面向?qū)ο笤O(shè)計的幾個問題9/22/20226OO模型9/22/20227OOD過程逐個設(shè)計OOD模型的五個局部問題域局部的設(shè)計人機(jī)交互局部的設(shè)計控制流管理局部的設(shè)計數(shù)據(jù)管理

2、局部的設(shè)計構(gòu)件部署設(shè)計不強(qiáng)調(diào)次序每個局部均采用與OOA一致的概念、表示法及活動，但具有自己獨特的策略9/22/20228問題管理局部的設(shè)計繼續(xù)運用OOA 的方法，細(xì)化使用OOA的結(jié)果，并加以修改擴(kuò)充為服用設(shè)計與編程的類而增加結(jié)果增加一般類以建立共同協(xié)議按編程語言調(diào)整集成提高性能為數(shù)據(jù)存儲管理增補(bǔ)屬性與效勞為編程方便增加底層成分決定關(guān)系的實現(xiàn)方式對例外的處理編程語言限制了可用的屬性類型構(gòu)造或優(yōu)化算法調(diào)整效勞決定對象間的可訪問性考慮采用設(shè)計模式9/22/20229人機(jī)交互局部的設(shè)計從use case 分析人機(jī)交互命令的組織設(shè)計模式：觀察者、視圖幫助者等開發(fā)工具的支持9/22/202210控制流程管

3、理局部的設(shè)計用主動對象表示每個控制流進(jìn)程、線程所有的主動類構(gòu)成控制流管理局部識別每個控制流審查與篩選定義各控制流控制流間的同步對進(jìn)程和線程建模9/22/202211順序系統(tǒng)的消息9/22/202212并發(fā)系統(tǒng)中的消息9/22/202213數(shù)據(jù)管理局部的設(shè)計利用關(guān)系數(shù)據(jù)系統(tǒng)進(jìn)行數(shù)據(jù)存儲設(shè)計永久類的存放設(shè)計設(shè)計數(shù)據(jù)管理局部的類并修改問題域系統(tǒng)保存和恢復(fù)對象的時機(jī)對關(guān)系的存儲利用面向?qū)ο髷?shù)據(jù)庫系統(tǒng)進(jìn)行數(shù)據(jù)存儲設(shè)計利用文件實現(xiàn)數(shù)據(jù)存儲9/22/202214軟件分析與設(shè)計根本過程定義用例用例不是面向?qū)ο笾破?，而是對情?jié)的記錄，是需求分析中的工具定義領(lǐng)域模型面向?qū)ο蠓治鲫P(guān)注從對象的角度創(chuàng)立領(lǐng)域描述，面向?qū)?/p>

4、象分析需要鑒別重要的概念、屬性和關(guān)聯(lián)面向?qū)ο蠓治龅慕Y(jié)果可以表示為領(lǐng)域模型分配對象職責(zé)并繪制交互圖面向?qū)ο笤O(shè)計關(guān)注軟件對象的定義他們的職責(zé)和協(xié)作順序圖定義設(shè)計類圖用設(shè)計類圖描述類的靜態(tài)視圖9/22/202215軟件分析與設(shè)計簡單實例定義用例骰子游戲：游戲者請求擲骰子。系統(tǒng)展示結(jié)果：如果骰子的總點數(shù)是7，那么游戲者贏，否那么游戲者輸領(lǐng)域模型PlayernameDieFace valueDie game1 Rolls 21Plays11 Includes29/22/202216軟件分析與設(shè)計順序圖9/22/202217軟件需求分析與設(shè)計_局部設(shè)計類圖9/22/202218軟件分析與設(shè)計迭代、進(jìn)化和敏

5、捷軟件開發(fā)過程描述構(gòu)造、部署以及維護(hù)軟件的方式統(tǒng)一軟件開發(fā)過程UP)已成為一種流行的構(gòu)造面向?qū)ο笙到y(tǒng)的迭代開發(fā)過程RUP (Rational Unified Process) 是對統(tǒng)一過程的詳細(xì)細(xì)化靈活并且開放，鼓勵引進(jìn)其他迭代方法極限編程Scrum敏捷開發(fā)方法UP實踐提供了如何實施OOA/D的示范結(jié)構(gòu)9/22/202219軟件分析與設(shè)計迭代、進(jìn)化和敏捷迭代開發(fā)Iterative development是統(tǒng)一開發(fā)過程的關(guān)鍵實踐開發(fā)被組織成一系列固定的短期小工程每次迭代都產(chǎn)生經(jīng)過測試、集成并可執(zhí)行的局部系統(tǒng)每次迭代都具有各自的需求分析、設(shè)計、實現(xiàn)和測試隨著時間和一次次迭代，系統(tǒng)增量式完善9/22

6、/202220迭代和進(jìn)化式9/22/202221在迭代工程中處理變更 早期迭代遠(yuǎn)離系統(tǒng)的“真實路徑”。通過反饋和調(diào)整，系統(tǒng)向最適宜的需求和設(shè)計收斂包括設(shè)計、實現(xiàn)、集成和測試的一次迭代 在后期迭代中，很少會在需求上產(chǎn)生顯著變化，但是存在這種可能性。這種后期的變化可能會給組織帶來業(yè)務(wù)競爭優(yōu)勢9/22/202222軟件分析與設(shè)計迭代、進(jìn)化和敏捷迭代開發(fā)的優(yōu)點減少工程失敗的可能性，提高生產(chǎn)率，降低缺陷率在早期緩解高風(fēng)險早期反響、用戶參與和調(diào)整，會產(chǎn)生更接近真實需求的精化系統(tǒng)可控復(fù)雜性，團(tuán)隊不會被“分析癱瘓或長期且復(fù)雜的步驟所淹沒一次迭代中的經(jīng)驗可以被系統(tǒng)地用于改進(jìn)開發(fā)過程本身，并如此反復(fù)進(jìn)行下去一次迭

7、代的持續(xù)時間和時間定量小步驟，快速反響和調(diào)整時間定量，必需按時間完成9/22/202223軟件分析與設(shè)計迭代、進(jìn)化和敏捷瀑布模型在編程之前試圖定義所有或大局部需求在編程之前試圖完成完整的設(shè)計試圖在開始前定義“可靠的時間表問題錯誤的假設(shè)，規(guī)格說明是可預(yù)知的和穩(wěn)定的，在開始就可以定義，具有低變更率變更對于軟件是永恒在復(fù)雜變更系統(tǒng)中，反響和調(diào)整是成功的關(guān)鍵不要讓瀑布思維侵蝕迭代或UP工程9/22/202224軟件分析與設(shè)計迭代的分析設(shè)計實例1)第一次迭代前第一個時間定量需求會議進(jìn)行高階需求分析，確定用例和特性名稱和關(guān)鍵的非功能屬性通過咨詢首席架構(gòu)師和業(yè)務(wù)人員，選擇10用例具有重要的架構(gòu)意義具有高業(yè)務(wù)

8、價值對選出的用例的功能和非功能性需求進(jìn)行詳細(xì)分析2)召開迭代方案會議，選定特定時間進(jìn)行設(shè)計、構(gòu)造和測試9/22/202225軟件分析與設(shè)計迭代的分析設(shè)計實例3)在34周完成第1次迭代分組進(jìn)行建模和設(shè)計工作編程、測試和集成進(jìn)行單元測試、驗收測試、負(fù)載測試和可用性測試在結(jié)束前的一周，檢查是否能夠完成初始的迭代目標(biāo)，如果不能，那么縮小迭代范圍凍結(jié)代碼，檢查，集成測試，建立迭代基線向外部顯示局部系統(tǒng)，展示可視進(jìn)展和要求反響9/22/202226軟件分析與設(shè)計迭代的分析設(shè)計實例4)在第1次迭代即將結(jié)束時，召開第2次需求工作會議，對上次會議所有的材料進(jìn)行復(fù)查和精化，細(xì)化1015的用例5)舉行下一個迭代的迭

9、代方案會議6)以相同的步驟進(jìn)行第2次迭代7)反復(fù)進(jìn)行4次迭代和5次需求工作會議，完成8090需求，實現(xiàn)系統(tǒng)的108工程推進(jìn)20，進(jìn)入細(xì)化階段9此后一般不進(jìn)行需求工作會議，需求已穩(wěn)定9/22/202227進(jìn)化式分析和設(shè)計早期迭代的主要形式需求20%軟件2%需求30%軟件5%50%8%90%10%90%20%迭代1 迭代2 迭代3 迭代4 迭代51234520需求討論會假設(shè)該工程最終有20個迭代在進(jìn)化式迭代開發(fā)中，通過一系列需求討論會，需求在一組早期迭代中進(jìn)化?；蛟S經(jīng)過四次迭代和討論會后，可以定義和精化90%的需求，然而，只構(gòu)建了10%的軟件。MTWThFMTWThFMTWThF為期三周的迭代一星

10、期二星期三星期啟動會議，向團(tuán)隊明確迭代目標(biāo)，1小時團(tuán)隊進(jìn)行敏捷建模和設(shè)計，在白板上繪制UML草圖，5小時開始編碼和測試在此期間進(jìn)行大部分OOA/D并應(yīng)用UML如果有太多工作，分解迭代目標(biāo)為形成迭代基線，最后檢入代碼并凍結(jié)代碼演示和為期兩天的需求討論會下一次迭代方案會議，2小時在討論會上進(jìn)行用例建模9/22/202228軟件分析與設(shè)計迭代、進(jìn)化和敏捷風(fēng)險驅(qū)動與客戶驅(qū)動更明確包含以架構(gòu)為中心的迭代開發(fā)敏捷方法應(yīng)用時間定量的迭代使用自適應(yīng)方案，提倡增量交付敏捷宣言個體和迭代、超越過程和工具；工作的軟件、超越完整的文檔；客戶協(xié)作、超越合同談判；相應(yīng)變更，查閱履行方案9/22/202229軟件分析與設(shè)計

11、敏捷原那么優(yōu)先級最高的是，通過早期和持續(xù)交付有價值的軟件來滿足客戶歡迎變更需求，即使在開發(fā)的后期提出，敏捷過程為客戶的競爭優(yōu)勢而控制變更以2周到2月為周期，頻繁的交付可運行的軟件，首推較短的時間定量在整個項目的過程中，每一天開發(fā)人員都要和業(yè)務(wù)人員合作由個體推動項目的建設(shè)，為個體提供所需的環(huán)境、支持和信任在開發(fā)團(tuán)隊中或開發(fā)團(tuán)隊間傳遞信息的最為有效和高效的方法是面對面交流衡量進(jìn)展的重要尺度是可運行的軟件敏捷過程提倡可持續(xù)的開發(fā)發(fā)起人、開發(fā)者和用戶應(yīng)該步調(diào)一致不斷地關(guān)注技術(shù)上優(yōu)越的設(shè)計會提高敏捷性簡潔是最重要的，簡潔就是盡量減少工作量的藝術(shù)最佳的架構(gòu)、需求和設(shè)計來自組織的團(tuán)隊團(tuán)隊要定期反省如何使工作

12、更有效，然后相應(yīng)地調(diào)整行為9/22/202230軟件分析與設(shè)計迭代、進(jìn)化和敏捷敏捷建模采用敏捷方法并不意味著不進(jìn)行任何建模建模的目的主要是為了理解和勾通，而不是構(gòu)建文檔不要對所有或大多數(shù)軟件設(shè)計建模或應(yīng)用UML，可以將簡單的設(shè)計問題推延到編程階段盡可能使用最簡單的工具不要單獨建模，而是結(jié)對同時建模并行的創(chuàng)立模型在白板上畫草圖，“足夠好就可以所有的模型可能是不精確的開發(fā)者應(yīng)為自己進(jìn)行OO設(shè)計建模9/22/202231敏捷建模草圖例如9/22/202232軟件分析與設(shè)計迭代、進(jìn)化和敏捷敏捷UP推薦使用UP活動和制品簡集實現(xiàn)前的需求可以不完整以敏捷建模實踐應(yīng)用UML不應(yīng)有詳細(xì)的方案主里程碑方案和下一

13、迭代方案9/22/202233軟件分析與設(shè)計迭代、進(jìn)化和敏捷UP的其他實踐在早期迭代過程中解決高風(fēng)險和高價值的問題不斷地讓用戶參與評估、反響和需求在早期迭代中建立內(nèi)聚的核心架構(gòu)不斷地驗證質(zhì)量；提早、經(jīng)常和實際地測試在適當(dāng)?shù)胤绞褂糜美M(jìn)行一些可視化建模認(rèn)真管理需求實行變更請求和配置管理9/22/202234 初始細(xì)化構(gòu)造 移 交里程碑發(fā)布增量最終產(chǎn)品發(fā)布 迭代的結(jié)束點，此時有重要決策或評估產(chǎn)生 最終產(chǎn)品的穩(wěn)定可執(zhí)行子集。每個迭代的結(jié)束點都是小型的發(fā)布 兩次迭代發(fā)布子集之間的差異增量 此時，為產(chǎn)品的使用發(fā)布系統(tǒng)UP中面向進(jìn)度表的術(shù)語迭代階段開發(fā)周期9/22/202235科目9/22/202236科目與階段UP科目樣例初始 細(xì)化 構(gòu)造 移交業(yè)務(wù)建模需求設(shè)計實現(xiàn) 科目的相對工作量在不同階段有所變化 本例只是建議，并非嚴(yán)格規(guī)定9/22/202237簡單開發(fā)案例s:開始，r:精化科目實踐制品迭代初始I1細(xì)化E1.E