第三講需求工程(requirementsengineering)資料課件

第三講需求工程

（RequirementsEngineering）WelcometoSoftwareEngineeringLecture3ZhangJiannanjiannanz@163.com第三講需求工程

（RequirementsEngin目標(biāo)了解需求工程的主要活動及它們之間的關(guān)系；掌握有關(guān)需求的基本知識；掌握需求導(dǎo)出和分析的一些技術(shù)；了解結(jié)構(gòu)化分析的基礎(chǔ)知識和基本方法；重點掌握基于UML建模的面向?qū)ο蠓治龇椒私庑枨笥行则炞C及如何進(jìn)行需求評審；了解需求管理的必要性以及它如何支持其它需求工程活動。目標(biāo)了解需求工程的主要活動及它們之間的關(guān)系；內(nèi)容可行性研究需求分析基礎(chǔ)需求導(dǎo)出與分析結(jié)構(gòu)化分析基礎(chǔ)UML與面向?qū)ο蠓治龇椒ㄐ枨笥行则炞C需求文檔需求管理內(nèi)容可行性研究恐怖的噩夢一個棘手的項目終于接近了尾聲，作為項目經(jīng)理的你坐在辦公室舒展著緊張了幾個月的身軀，頭腦中盤算著如何讓客戶痛快的付清合同款。這時，客戶走進(jìn)你的辦公室，坐下，直視著你的眼睛說道：“我知道你認(rèn)為你理解了我說的是什么，但你恐怕不知道，我所說的其實不是我想要的?！笨植赖呢瑝粢粋€棘手的項目終于接近了尾聲，作為項目經(jīng)理的你坐在需求工程過程需求工程過程并不具有唯一的模型，按照不同的應(yīng)用領(lǐng)域、不同的客戶與開發(fā)團(tuán)隊，需求工程的過程有很大的差異。然而，在所有的過程中都會涉及一些共同的活動，它們是：可行性研究(feasibilitystudy)；需求導(dǎo)出與分析(elicitationandanalysis)；需求描述(specification)；需求有效性驗證(validation)；需求管理(management)。需求工程過程需求工程過程并不具有唯一的模型，按照不同的應(yīng)用領(lǐng)需求工程過程需求工程過程需求工程需求工程1.可行性研究可行性研究要決定被提議的系統(tǒng)是否值得去做。可行性研究過程較短，焦點集中在以下幾個問題：系統(tǒng)的開發(fā)是否符合組織的總體目標(biāo)？系統(tǒng)是否可能在現(xiàn)有的技術(shù)和預(yù)算限制內(nèi)完成？系統(tǒng)能否與已存在的其它系統(tǒng)相兼容？1.可行性研究可行性研究要決定被提議的系統(tǒng)是否值得去做。進(jìn)行可行性研究進(jìn)行可行性研究包括信息評估、信息匯總和書寫報告三部分工作。信息的評估與匯總需要分析人員與Stakeholders相溝通，通過提出問題匯總信息，可能提出的問題包括：如果系統(tǒng)沒有實現(xiàn)，機(jī)構(gòu)將如何應(yīng)對？當(dāng)前處理過程存在哪些問題？新系統(tǒng)將如何處理？系統(tǒng)將對業(yè)務(wù)目標(biāo)有什么直接的貢獻(xiàn)？系統(tǒng)需要和哪些系統(tǒng)相集成？需要使用新技術(shù)嗎？使用那些技術(shù)？對待開發(fā)系統(tǒng)感興趣和直接或間接從系統(tǒng)中獲益的人進(jìn)行可行性研究進(jìn)行可行性研究包括信息評估、信息匯總和書寫報告2.需求分析基礎(chǔ)2.1什么是需求？定義不一致需求具有雙重功能：IanSommerville可以作為競標(biāo)、簽約的基礎(chǔ)一種開放的、易于交流的系統(tǒng)功能及約束的高層概要描述；簽約之后，為了完成合同約定，開發(fā)者給出的對系統(tǒng)的詳盡、準(zhǔn)確的描述。兩種描述都叫做需求文檔，分別對應(yīng)于用戶需求和系統(tǒng)需求。2.需求分析基礎(chǔ)2.1什么是需求？2.2需求的類型用戶需求從客戶的角度，采用自然語言配合以圖表對目標(biāo)系統(tǒng)應(yīng)提供的服務(wù)以及系統(tǒng)操作要受到的約束進(jìn)行的聲明。系統(tǒng)需求系統(tǒng)需求是一種結(jié)構(gòu)化文檔，要運(yùn)用一些專業(yè)的模型詳細(xì)的描述系統(tǒng)的功能及其約束。系統(tǒng)需求文檔有時也稱為功能描述，應(yīng)該是精確的，它可以成為雙方之間合同的重要內(nèi)容，同時作為開發(fā)工作的依據(jù)。2.2需求的類型用戶需求需求定義與描述用戶需求定義1.LIBSYS應(yīng)該能夠管理全國及其他地區(qū)的版權(quán)代理商所要求的全部數(shù)據(jù)。系統(tǒng)需求描述1.1向LIBSYS申請建立一個檔案的時候，系統(tǒng)應(yīng)該用一個表格來記錄申請者及他所提出的申請的詳細(xì)情況；1.2LIBSYS申請表格應(yīng)該從提交的日子開始在系統(tǒng)中保存5年；1.3LIBSYS申請表格必須能夠由用戶根據(jù)請求材料的名稱和申請人來進(jìn)行索引；1.4LIBSYS應(yīng)該能夠維護(hù)一個已經(jīng)被系統(tǒng)處理的所有申請的日志；1.5對于作者提供出借權(quán)的材料，系統(tǒng)應(yīng)該按月向已經(jīng)在系統(tǒng)注冊的版權(quán)代理商提供詳細(xì)的出借信息。需求定義與描述用戶需求定義1.LIBSYS應(yīng)該能夠管理全國2.3功能需求與非功能需求功能需求對系統(tǒng)應(yīng)提供的功能，系統(tǒng)在特定的輸入下做出的反應(yīng)及特定條件下的行為的描述。某些情況下還要包括系統(tǒng)不應(yīng)做什么。非功能需求對系統(tǒng)提供服務(wù)或功能時收到的約束進(jìn)行描述。如時間約束、開發(fā)過程約束和標(biāo)準(zhǔn)等。領(lǐng)域需求這種需求來自于系統(tǒng)的應(yīng)用領(lǐng)域，反映領(lǐng)域特征。可能是功能需求也可能是非功能需求。2.3功能需求與非功能需求功能需求2.3.1功能需求功能需求描述系統(tǒng)所應(yīng)提供的功能或服務(wù)。取決于待開發(fā)軟件的類型、未來的用戶以及開發(fā)的系統(tǒng)類型。功能性的用戶需求只需要對系統(tǒng)應(yīng)提供的服務(wù)進(jìn)行高層一般描述，對于系統(tǒng)需求，則應(yīng)該詳細(xì)的描述系統(tǒng)功能、輸入輸出及異常。2.3.1功能需求功能需求描述系統(tǒng)所應(yīng)提供的功能或服務(wù)。功能需求描述例：圖書館系統(tǒng)（LIBSYS）

該圖書館系統(tǒng)要提供一個界面，使顧客能夠訪問多個圖書館不同的文獻(xiàn)數(shù)據(jù)庫中的資料。允許用戶出于個人學(xué)習(xí)的目的對文獻(xiàn)資料進(jìn)行搜索、下載和打印。功能需求描述例：圖書館系統(tǒng)（LIBSYS）功能需求描述用戶可以從總的數(shù)據(jù)庫中進(jìn)行查詢，也可以從其中一個子集中查詢；系統(tǒng)應(yīng)提供一個適當(dāng)?shù)臑g覽器供用戶閱讀館藏資料；每次借閱應(yīng)該對應(yīng)一個唯一標(biāo)識符(ORDER_ID)。通過這個標(biāo)識，可以允許用戶把文獻(xiàn)拷貝到常備存儲區(qū)。功能需求描述用戶可以從總的數(shù)據(jù)庫中進(jìn)行查詢，也可以從其中一個不嚴(yán)密問題當(dāng)需求被不嚴(yán)密的表述時，會產(chǎn)生很多問題。一些不明確、不準(zhǔn)確的表述可能會使用戶與開發(fā)者有不同的理解。思考上例中的短語“適當(dāng)?shù)臑g覽器”，如何理解？用戶的理解

開發(fā)者的理解不嚴(yán)密問題當(dāng)需求被不嚴(yán)密的表述時，會產(chǎn)生很多問題。需求的全面性和一致性原則上，功能性需求描述應(yīng)該具備全面性和一致性。全面性包括了所有用戶要求的服務(wù)。一致性在系統(tǒng)服務(wù)的描述中沒有沖突和矛盾Inpractice,itisimpossibletoproduceacompleteandconsistentrequirementsdocument.需求的全面性和一致性原則上，功能性需求描述應(yīng)該具備全面性和一2.3.2非功能性需求非功能需求不直接和功能相關(guān)，但定義了實現(xiàn)系統(tǒng)功能受到的約束與系統(tǒng)特性。如可靠性、響應(yīng)時間、存儲空間、I/O設(shè)備能力等。非功能需求還常與系統(tǒng)的開發(fā)過程有關(guān)，表現(xiàn)為過程需求。如設(shè)計必須實用的特定CASE工具集、設(shè)計語言和開發(fā)方法。Whichoneismorecritical?2.3.2非功能性需求非功能需求不直接和功能相關(guān)，但定義了俺當(dāng)上白領(lǐng)兒了？也該買輛車了！先生，我們的汽車配置齊全，自動巡航、四氣囊、真皮座椅、電動天窗、自動空調(diào)一應(yīng)俱全，才八萬多，性價比相當(dāng)高！嗯，功能不錯，價格也便宜，安全性怎麼樣？……,呵呵，說實話，是有點小毛病，偶爾剎車會失靈，不過問題不大，多踩幾下就行了！俺當(dāng)上白領(lǐng)兒了？也該買輛車了！先生，我們的汽車配置齊全，自動非功能需求分類產(chǎn)品需求Requirementswhichspecifythatthedeliveredproductmustbehaveinaparticularwaye.g.executionspeed,reliability,etc.機(jī)構(gòu)需求Rcessstandardsused,implementationrequirements,etc.外部需求Reroperabilityrequirements,legislativerequirements,etc.非功能需求分類產(chǎn)品需求非功能需求的類型非功能需求的類型非功能需求案例（仍以LIBSYS為例）產(chǎn)品需求

LIBSYS的用戶界面應(yīng)該能夠正確處理錯誤操作，并給出提示和幫助信息。組織需求系統(tǒng)的開發(fā)過程和可交付文檔應(yīng)遵照XYZCo-SP-STAN-95中的相關(guān)定義。外部需求

系統(tǒng)不應(yīng)對系統(tǒng)操作人員公開客戶除名字與索引代碼之外的任何個人信息。非功能需求案例（仍以LIBSYS為例）目標(biāo)與驗證非功能需求的常見問題是檢驗困難，可以通過設(shè)定目標(biāo)來定義可檢驗的非功能需求。目標(biāo)明確說明用戶的意圖，如可用性；可檢驗的非功能需求用可測試的度量標(biāo)準(zhǔn)來描述需求。可能的情況下，應(yīng)量化非功能需求，從而使其檢驗更客觀。目標(biāo)與驗證非功能需求的常見問題是檢驗困難，可以通過設(shè)定目標(biāo)來案例：系統(tǒng)目標(biāo)Thesystemshouldbeeasytouseeventoexperiencelesscontrollersandshouldbeorganisedinsuchawaythatusererrorsareminimised.可檢驗的非功能需求Experiencelesscontrollersshallbeabletouseallthesystemfunctionsafteratotaloftwohourstraining.Afterthistraining,theaveragenumberoferrorsmadebyexperiencelessusersshallnotexceedtwoperday.案例：系統(tǒng)目標(biāo)非功能需求的度量非功能需求的度量需求沖突一些復(fù)雜的系統(tǒng)中，功能需求與非功能需求常會出現(xiàn)沖突。例：SpacecraftsystemTominimiseweight,thenumberofseparatechipsinthesystemshouldbeminimised.Tominimisepowerconsumption,lowerpowerchipsshouldbeused.However,usinglowpowerchipsmaymeanthatmorechipshavetobeused.Whichisthemostcriticalrequirement?需求沖突一些復(fù)雜的系統(tǒng)中，功能需求與非功能需求常會出現(xiàn)沖突。2.3.3領(lǐng)域需求領(lǐng)域需求來自于應(yīng)用領(lǐng)域，描述的是反映領(lǐng)域特點的系統(tǒng)特性與特征。領(lǐng)域需求可能是新的功能需求，也可能是對現(xiàn)有需求的約束或定義一個特別的計算。領(lǐng)域需求非常重要，如果領(lǐng)域需求不能滿足，可能會使整個系統(tǒng)無法運(yùn)轉(zhuǎn)。2.3.3領(lǐng)域需求領(lǐng)域需求來自于應(yīng)用領(lǐng)域，描述的是反映領(lǐng)域圖書館系統(tǒng)的領(lǐng)域需求ThereshallbeastandarduserinterfacetoalldatabaseswhichshallbebasedontheZ39.50standard.Becauseofcopyrightrestrictions,somedocumentsmustbedeletedimmediatelyonarrival.Dependingontheuser’srequirements,thesedocumentswilleitherbeprintedlocallyonthesystemserverformanuallyforwardingtotheuserorroutedtoanetworkprinter.圖書館系統(tǒng)的領(lǐng)域需求Thereshallbeasta領(lǐng)域需求表述的問題不易理解Requirementsareexpressedinthelanguageoftheapplicationdomain;Thisisoftennotunderstoodbysoftwareengineersdevelopingthesystem.表述模糊Domainspecialistsunderstandtheareasowellthattheydonotthinkofmakingthedomainrequirementsexplicit.領(lǐng)域需求表述的問題不易理解2.4用戶需求用戶需求是從用戶角度來描述的系統(tǒng)功能需求與非功能需求，這樣的描述可以使不具備專業(yè)技術(shù)知識的用戶能夠看明白。用戶需求使用任何人都看得懂的自然語言、圖表和直觀的圖形來描述。2.4用戶需求用戶需求是從用戶角度來描述的系統(tǒng)功能需求與非自然語言的缺陷描述不夠清楚

存在二義性，不易準(zhǔn)確理解；需求混亂功能需求、非功能需求無法清晰區(qū)分；需求混合多個不同的需求可能被混合在一起表述；自然語言的缺陷描述不夠清楚書寫用戶需求的準(zhǔn)則設(shè)計一個標(biāo)準(zhǔn)格式，以幫助減少遺漏，避免不必要的細(xì)節(jié)描述；使用一致的語言，尤其強(qiáng)調(diào)區(qū)別強(qiáng)制性需求與希望性需求。如使用“必須

”定義強(qiáng)制性需求，使用“應(yīng)該

”定義希望性需求；使用文本加亮來突出關(guān)鍵性需求；盡量避免使用計算機(jī)專用術(shù)語。書寫用戶需求的準(zhǔn)則設(shè)計一個標(biāo)準(zhǔn)格式，以幫助減少遺漏，避免不2.5系統(tǒng)需求相對于用戶需求，系統(tǒng)需求是對系統(tǒng)功能、服務(wù)及約束的更詳盡的描述。系統(tǒng)需求是系統(tǒng)實現(xiàn)的基本依據(jù)，會被寫入合同中。因此系統(tǒng)需求是一個完全的、一致的系統(tǒng)描述，是設(shè)計的起點。系統(tǒng)需求可以用系統(tǒng)模型來定義與說明。2.5系統(tǒng)需求相對于用戶需求，系統(tǒng)需求是對系統(tǒng)功能、服務(wù)及使用自然語言描述系統(tǒng)需求的問題不明確Thereadersandwritersoftherequirementmustinterpretthesamewordsinthesameway.NLisnaturallyambiguoussothisisverydifficult.描述隨意性太大Thesamethingmaybesaidinanumberofdifferentwaysinthespecification.不能進(jìn)行模塊化描述NLstructuresareinadequatetostructuresystemrequirements.使用自然語言描述系統(tǒng)需求的問題不明確代替NL的描述方法代替NL的描述方法結(jié)構(gòu)化的自然語言這種方式保持了自然語言的表達(dá)能力和易懂等特點，同時用預(yù)先定義的模版限制了書寫需求使得自由度：所有的需求都用一致的標(biāo)準(zhǔn)方法來書寫；對使用的詞匯進(jìn)行了限制，并用模板來約束。結(jié)構(gòu)化的自然語言這種方式保持了自然語言的表達(dá)能力和易懂等特點基于標(biāo)準(zhǔn)格式的描述方法對功能或?qū)嶓w的定義；對輸入及輸入來源的描述；對輸出及輸出去向的描述；其它被引用實體的索引；前條件與后條件；對操作的副作用（如果有）的描繪。基于標(biāo)準(zhǔn)格式的描述方法對功能或?qū)嶓w的定義；例：添加節(jié)點的格式化描繪例：添加節(jié)點的格式化描繪應(yīng)用表格進(jìn)行描述這種方法常用做自然語言描述的補(bǔ)充。適用于對于多種不同條件有多種可選動作（結(jié)果）的情況。應(yīng)用表格進(jìn)行描述這種方法常用做自然語言描述的補(bǔ)充。例：表格描述例：表格描述圖形模型圖形模型在需要描述系統(tǒng)的狀態(tài)變化或動作序列時最為有用。有關(guān)圖形模型的應(yīng)用是這門課程的實踐重點！圖形模型圖形模型在需要描述系統(tǒng)的狀態(tài)變化或動作序列時最為有用例：ATM取款序列圖例：ATM取款序列圖3.需求導(dǎo)出與分析這個階段在可行性研究之后進(jìn)行。系統(tǒng)分析人員要和客戶及最終用戶一同調(diào)查應(yīng)用領(lǐng)域，找出系統(tǒng)應(yīng)提供的服務(wù)及其約束，即找出系統(tǒng)的功能需求與非功能需求。這個階段通常與需求描述交叉進(jìn)行。這個階段的活動會涉及到機(jī)構(gòu)中方方面面的人，如終端用戶、工程人員、業(yè)務(wù)經(jīng)理領(lǐng)域?qū)＜?，甚至工會代表，他們都是對系統(tǒng)需求產(chǎn)生直接或間接影響的人，被稱作

stakeholders。3.需求導(dǎo)出與分析這個階段在可行性研究之后進(jìn)行。需求分析可能遇到的問題Stakeholdersdon’tknowwhattheyreallywant.Stakeholdersexpressrequirementsintheirownterms.Differentstakeholdersmayhaveconflictingrequirements.Organisationalandpoliticalfactorsmayinfluencethesystemrequirements.Therequirementschangeduringtheanalysisprocess.Newstakeholdersmayemergeandthebusinessenvironmentchange.需求分析可能遇到的問題Stakeholdersdon’t需求螺旋需求螺旋過程活動需求發(fā)現(xiàn)Interactingwithstakeholderstodiscovertheirrequirements.Domainrequirementsarealsodiscoveredatthisstage.需求的分類與組織Groupsrelatedrequirementsandorganisesthemintocoherentclusters.優(yōu)先排序和沖突解決Prioritisingrequirementsandresolvingrequirementsconflicts.需求文檔Requirementsaredocumentedandinputintothenextroundofthespiral.過程活動需求發(fā)現(xiàn)需求的發(fā)現(xiàn)與識別這是整個過程中最為關(guān)鍵的活動，負(fù)責(zé)收集目標(biāo)系統(tǒng)級現(xiàn)存系統(tǒng)的相關(guān)信息并從這些信息中提煉出用戶需求和系統(tǒng)需求。信息的來源包括已有的文件，系統(tǒng)的信息持有者（stakeholders）以及相近系統(tǒng)的規(guī)約描述。需求的發(fā)現(xiàn)與識別這是整個過程中最為關(guān)鍵的活動，負(fù)責(zé)收集目標(biāo)系A(chǔ)TMstakeholdersBankcustomersRepresentativesofotherbanksBankmanagersCounterstaffDatabaseadministratorsSecuritymanagersMarketingdepartmentHardwareandsoftwaremaintenanceengineersBankingregulatorsATMstakeholdersBankcustomers3.1多視點（viewpoint）需求定義視點用來表述不同角度的需求來源（信息持有者、其它相關(guān)系統(tǒng)及領(lǐng)域）。每一個視點代表系統(tǒng)需求的一個子集。從多視點對系統(tǒng)進(jìn)行分析是十分重要的，因為沒有那一種單一的途徑能夠詮釋整個系統(tǒng)需求。3.1多視點（viewpoint）需求定義視點用來表述不同視點的類型交互者視點Peopleorothersystemsthatinteractdirectlywiththesystem.InanATM,thecustomer’sandtheaccountdatabaseareinteractorVPs.間接視點Stakeholderswhodonotusethesystemthemselvesbutwhoinfluencetherequirements.InanATM,managementandsecuritystaffareindirectviewpoints.領(lǐng)域視點Domaincharacteristicsandconstraintsthatinfluencetherequirements.InanATM,anexamplewouldbestandardsforinter-bankcommunications.視點的類型交互者視點視點的識別以下的幾個方面可以幫助識別視點：Providersandreceiversofsystemservices;Systemsthatinteractdirectlywiththesystembeingspecified;Regulationsandstandards;Sourcesofbusinessandnon-functionalrequirements.Engineerswhohavetodevelopandmaintainthesystem;Marketingandotherbusinessviewpoints.視點的識別以下的幾個方面可以幫助識別視點：LIBSYS的視點LIBSYS的視點3.2訪談對stakeholders進(jìn)行正式的和非正式的訪談對于需求工程是非常重要的工作。有兩種類型的訪談：封閉式訪談，預(yù)先定義所要提問的問題，又叫做限定式訪談；開放式訪談，不預(yù)先設(shè)定訪談內(nèi)容，給定一個范圍，與stakeholders自由交流以更好的把握他們的要求。3.2訪談對stakeholders進(jìn)行正式的和非正式訪談實踐通常是采用兩種方式相混合，以封閉式訪談開始，以開放式結(jié)束。訪談對于全面了解系統(tǒng)需求是一種很好的方法，在訪談中可以了解stakeholders的要求，他們是如何與系統(tǒng)交互的，對當(dāng)前系統(tǒng)面臨的問題等。訪談方式對于獲取領(lǐng)域需求并不是很奏效Requirementsengineerscannotunderstandspecificdomainterminology;Somedomainknowledgeissofamiliarthatpeoplefindithardtoarticulateorthinkthatitisn’twortharticulating.訪談實踐通常是采用兩種方式相混合，以封閉式訪談開始，以開放式對訪談?wù)叩囊笥心芰Φ脑L談?wù)邞?yīng)該是思維開闊的，愿意聆聽他人的想法，并且不會對問題有先入為主的看法。他們善于用問題和建議去啟發(fā)訪問者的思維，或使用原型與被訪問者討論，而不是僅用‘whatdoyouwant’進(jìn)行簡單的提問。對訪談?wù)叩囊笥心芰Φ脑L談?wù)邞?yīng)該是思維開闊的，愿意聆聽他人的3.3場景場景描述法是采用把系統(tǒng)交互放到一個真實的生活片段中，這樣比采用抽象的形式描述要容易理解，容易導(dǎo)出目標(biāo)系統(tǒng)的使用細(xì)節(jié)。場景的描述方式很多，一般包括：場景開始時系統(tǒng)初始狀態(tài)的描述；一個標(biāo)準(zhǔn)事件流的描述；對可能出現(xiàn)的錯誤及解決方法的描述；其它并行事件流的描述；場景結(jié)束狀態(tài)的描述。常用的方法，自然語言和用例。3.3場景場景描述法是采用把系統(tǒng)交互放到一個真實的生活片段例：酒店預(yù)定場景描述開始：MedocaSansumi,是theSantaCruzB&B的酒店前臺，一邊看著theHotelAppMain的銀幕一邊等著電話。電話從Ms.JaneGoogol打來，一個來自紐約的客戶。Ms.Googol拿起電話說“你好，我是JaneGoogol，我想要為新年的前夜預(yù)定一間房間”。Medoca在HotelApp的主銀幕上選擇了“創(chuàng)建預(yù)定”。屏幕上顯示出一個空預(yù)定。例：酒店預(yù)定場景描述開始：中間過程：

Medoca問到“你什么時候到達(dá)這里？”。Jane回答到“12月31日到，我想要住到1月5日。”Medoca輸入了開始日期，并且問到“你想要預(yù)定什么類型的房子呢？”，“我將和我的丈夫一起到那，所以需要一個單獨的并且有足夠空間的，那個Blue房子有空的嗎？”Jane問到。Medoca選擇“single”在預(yù)定的表格中，完成了查找。系統(tǒng)給予了三種空房間的回應(yīng)：Victoria,Blue和Queen?！笆堑模锌盏摹盡edoca回答。Medoca選擇了Bule房間，系統(tǒng)把它填入預(yù)定的表格中，然后做出“held”的預(yù)約記號。例：酒店預(yù)定場景描述中間過程：例：酒店預(yù)定場景描述更多的中間過程：

Medoca向系統(tǒng)中輸入Jane的全名。Ms.Googol是一個現(xiàn)有的客戶，所以系統(tǒng)通過客戶表單的數(shù)據(jù)在預(yù)約的表格中給出回應(yīng)?！澳阆胍裉炀桶堰@個預(yù)定確定下來嗎？”Medoca問道?！笆堑摹盝ane說，“用我的VISA卡，卡號是：1111-2222-3333-4444?！盝ane在Medoca把卡號輸入進(jìn)去以后暫停了?！敖刂寥掌谑?007年7月?！盡edoca輸入這些信息，并且在系統(tǒng)上選擇了“VerifyPayment（確認(rèn)付款）”。五分鐘后，系統(tǒng)給出了銀行存款驗證的回應(yīng)。系統(tǒng)把預(yù)定的狀態(tài)改成了“confirmed.”例：酒店預(yù)定場景描述更多的中間過程：例：酒店預(yù)定場景描述例：酒店預(yù)定場景描述結(jié)束：

Medoca告訴Jane預(yù)約號（系統(tǒng)產(chǎn)生的），并且問道“我還能為您做什么？”，Jane回答沒什么了，Medoca向Jane道謝并且再見。Medoca關(guān)閉了預(yù)約表格的窗口，系統(tǒng)返回到MainHotelApp的主屏幕上。例：酒店預(yù)定場景描述結(jié)束：用例（UseCase）用例是一種基于UML的場景描述技術(shù)，用來識別在一個系統(tǒng)交互中的參與者并描述這個交互過程。用例的集合應(yīng)該可以描述系統(tǒng)中的所有的交互。UML中的序列圖可以用來配合用例圖描述系統(tǒng)的交互細(xì)節(jié)。用例（UseCase）用例是一種基于UML的場景描述技術(shù)，例1：文獻(xiàn)打印用例圖例1：文獻(xiàn)打印用例圖例2：LIBSYS用例模型例2：LIBSYS用例模型例3：文獻(xiàn)打印序列圖例3：文獻(xiàn)打印序列圖3.4導(dǎo)出工作產(chǎn)品對于大多數(shù)系統(tǒng)而言，工作產(chǎn)品包括：Astatementofneedandfeasibility.Aboundedstatementofscopeforthesystemorproduct.Alistofcustomers,users,andotherstakeholderswhoparticipatedinrequirementselicitationAdescriptionofthesystem’stechnicalenvironment.Alistofrequirements(preferablyorganizedbyfunction)andthedomainconstraintsthatapplytoeach.Asetofusagescenariosthatprovideinsightintotheuseofthesystemorproductunderdifferentoperatingconditions.Anyprototypes

developedtobetterdefinerequirements.3.4導(dǎo)出工作產(chǎn)品對于大多數(shù)系統(tǒng)而言，工作產(chǎn)品包括：4結(jié)構(gòu)化分析（SA）建模結(jié)構(gòu)化分析方法是一種面向數(shù)據(jù)流的系統(tǒng)建模技術(shù)；SA幫助分析者理解系統(tǒng)的功能，并采用模型與用戶進(jìn)行交流；不同的模型從不同的角度對系統(tǒng)進(jìn)行描述。4結(jié)構(gòu)化分析（SA）建模結(jié)構(gòu)化分析方法是一種面向數(shù)據(jù)流的系結(jié)構(gòu)化分析建模結(jié)構(gòu)化分析方法建立的分析模型結(jié)構(gòu)如下圖：實體—關(guān)系圖

數(shù)據(jù)詞典狀態(tài)—遷移圖數(shù)據(jù)流圖數(shù)據(jù)對象描述控制規(guī)格說明加工規(guī)格說明結(jié)構(gòu)化分析建模結(jié)構(gòu)化分析方法建立的分析模型結(jié)構(gòu)如下圖：實體—結(jié)構(gòu)化分析模型的核心是數(shù)據(jù)詞典，它描述了所有的在目標(biāo)系統(tǒng)中使用的和生成的數(shù)據(jù)對象。圍繞著這個核心的有三種圖：實體—關(guān)系圖(ERD)描述數(shù)據(jù)對象及數(shù)據(jù)對象之間的關(guān)系；數(shù)據(jù)流圖(DFD)描述數(shù)據(jù)在系統(tǒng)中如何被傳送或變換，以及描述如何對數(shù)據(jù)流進(jìn)行變換的功能（子功能）；狀態(tài)—遷移圖(STD)描述系統(tǒng)對外部事件如何響應(yīng)，如何動作。因此，ERD用于數(shù)據(jù)建模，DFD用于功能建模，STD用于行為建模。

結(jié)構(gòu)化分析建模結(jié)構(gòu)化分析模型的核心是數(shù)據(jù)詞典，它描述了所有的在目標(biāo)系統(tǒng)中使4.1數(shù)據(jù)建模與實體—關(guān)系圖(ERD)數(shù)據(jù)模型包括三種互相關(guān)聯(lián)的信息：數(shù)據(jù)對象描述對象的屬性描述對象間相互連接的關(guān)系（具體繪制方法同數(shù)據(jù)庫原理ER模型畫法）4.1數(shù)據(jù)建模與實體—關(guān)系圖(ERD)數(shù)據(jù)模型包括三種互相關(guān)4.2功能建模和數(shù)據(jù)流圖

功能建模的思想就是用抽象模型的概念，按照軟件內(nèi)部數(shù)據(jù)傳遞、變換的關(guān)系，自頂向下逐層分解，直到找到滿足功能要求的所有可實現(xiàn)的軟件為止。數(shù)據(jù)流圖可以表示任何一個系統(tǒng)（人工的、自動的、或混合的）中的數(shù)據(jù)流程；每個表示加工的圓圈可能需要進(jìn)一步分解以求得對問題的全面理解；著重強(qiáng)調(diào)的是數(shù)據(jù)流程而不是控制流程。4.2功能建模和數(shù)據(jù)流圖功能建模的思想就是用抽象模型的概4.2.1數(shù)據(jù)流圖的畫法數(shù)據(jù)流圖中的常用圖元有以下四種：表示外部實體，代表數(shù)據(jù)源和數(shù)據(jù)池（終點）。表示加工，代表接收輸入，經(jīng)過變換，繼而產(chǎn)生輸出的處理過程。表示數(shù)據(jù)流，代表數(shù)據(jù)的流向和路徑。表示數(shù)據(jù)存儲，代表系統(tǒng)加工的數(shù)據(jù)所存儲的地方。4.2.1數(shù)據(jù)流圖的畫法數(shù)據(jù)流圖中的常用圖元有以下四種：

例：教材采購與銷售管理系統(tǒng)數(shù)據(jù)流圖

F1教材存量表

1

銷售

2采購

書庫保管員

學(xué)

生領(lǐng)書單購書通知進(jìn)書通知

購書單

缺書單

F2缺書登記表

缺書匯總表例：教材采購與銷售管理系統(tǒng)數(shù)據(jù)流圖F1教材存量表1多個數(shù)據(jù)流與加工之間關(guān)系的符號

多個數(shù)據(jù)流與加工之間關(guān)系的符號4.2.2分層數(shù)據(jù)流圖復(fù)雜的實際問題，在數(shù)據(jù)流圖上常常出現(xiàn)十幾個甚至幾十個加工。畫數(shù)據(jù)流圖的基本步驟概括地說，就是自外向內(nèi)，自頂向下，逐層細(xì)化，完善求精。按照系統(tǒng)的層次結(jié)構(gòu)進(jìn)行逐步分解，并以分層的數(shù)據(jù)流圖反映復(fù)雜的結(jié)構(gòu)關(guān)系，能清楚地表達(dá)和容易理解整個系統(tǒng)。4.2.2分層數(shù)據(jù)流圖復(fù)雜的實際問題，在數(shù)據(jù)流圖上常常出現(xiàn)4.2.2分層數(shù)據(jù)流圖4.2.2分層數(shù)據(jù)流圖畫分層數(shù)據(jù)流圖的注意事項數(shù)據(jù)流圖要具有可讀性、一致性、正確性。①數(shù)據(jù)流圖上所有圖形符號只限于前述四種基本圖形元素。②頂層數(shù)據(jù)流圖上的數(shù)據(jù)流必須封閉在外部實體之間。③數(shù)據(jù)應(yīng)通過加工流動，避免從一個數(shù)據(jù)存儲直接流向另一個數(shù)據(jù)存儲。④每個加工至少有一個輸入數(shù)據(jù)流和一個輸出數(shù)據(jù)流，且輸入與輸出數(shù)據(jù)流要平衡。有輸入，無使用及輸出為“黑洞”，無輸入和產(chǎn)生而有輸出為“奇跡”。⑤在數(shù)據(jù)流圖中，需按層給加工框編號。編號表明該加工處在哪一層，以及上下層的父圖與子圖的對應(yīng)關(guān)系。⑥規(guī)定任何一個數(shù)據(jù)流子圖必須與它上一層的一個加工對應(yīng)，兩者的輸入數(shù)據(jù)流和輸出數(shù)據(jù)流必須一致。此即父圖與子圖的平衡。畫分層數(shù)據(jù)流圖的注意事項數(shù)據(jù)流圖要具有可讀性、一致性、正確性畫分層數(shù)據(jù)流圖的注意事項⑦圖上每個元素都必須有名字。數(shù)據(jù)流和數(shù)據(jù)文件的名字應(yīng)當(dāng)是“名詞”或“名詞性短語”，表明流動的數(shù)據(jù)是什么。加工的名字應(yīng)當(dāng)是“動詞＋賓語”，表明做什么事情。⑧可以在數(shù)據(jù)流圖中加入物質(zhì)流，幫助用戶理解數(shù)據(jù)流圖。⑨數(shù)據(jù)流圖中不可夾帶控制流。⑩初畫時可以忽略瑣碎的細(xì)節(jié)，以集中精力于主要數(shù)據(jù)流。畫分層數(shù)據(jù)流圖的注意事項⑦圖上每個元素都必須有名字。數(shù)據(jù)流例：教材采購與銷售管理系統(tǒng)零層數(shù)據(jù)流圖L0教材購銷系統(tǒng)領(lǐng)書單

進(jìn)書通知

學(xué)生書庫保管員

購書單缺書單

例：教材采購與銷售管理系統(tǒng)零層數(shù)據(jù)流圖L0教材領(lǐng)書單教材采購與銷售管理系統(tǒng)一層數(shù)據(jù)流圖L1F1教材存量表

1

銷售

2采購

書庫保管員

學(xué)

生領(lǐng)書單購書通知進(jìn)書通知

購書單

缺書單

F2缺書登記表

缺書匯總表教材采購與銷售管理系統(tǒng)一層數(shù)據(jù)流圖L1F1教材存量表1教材采購與銷售管理系統(tǒng)二層數(shù)據(jù)流圖L2.11.1查庫存1.2售書1.3申請采購

學(xué)生

購書單領(lǐng)書單缺書列表F1教材存量表F2缺書登記表到貨書單進(jìn)書通知缺書匯總表教材采購與銷售管理系統(tǒng)二層數(shù)據(jù)流圖L2.11.1查庫存1.教材采購與銷售管理系統(tǒng)二層數(shù)據(jù)流圖L2.22.3進(jìn)貨進(jìn)書通知F1教材庫存量表2.1詢價2.2訂貨訂貨價格F2缺書登記表缺書單

書庫管理員進(jìn)書通知進(jìn)貨單缺書匯總表教材采購與銷售管理系統(tǒng)二層數(shù)據(jù)流圖L2.22.3進(jìn)貨進(jìn)書通4.2.3數(shù)據(jù)詞典數(shù)據(jù)詞典用于精確、嚴(yán)格地定義每一個與系統(tǒng)相關(guān)的數(shù)據(jù)元素（包括數(shù)據(jù)流、數(shù)據(jù)存儲和數(shù)據(jù)項），并以字典式順序?qū)⑺鼈兘M織起來，使得用戶和分析員有共同的理解。在數(shù)據(jù)詞典的每一個詞條中應(yīng)包含以下信息：①名稱：數(shù)據(jù)對象或控制項、數(shù)據(jù)存儲或外部實體的名字。②別名或編號。③分類：數(shù)據(jù)對象？加工？數(shù)據(jù)流？數(shù)據(jù)文件？外部實體？控制項（事件∕狀態(tài)）？④描述：描述內(nèi)容或數(shù)據(jù)結(jié)構(gòu)等。⑤何處使用：使用該詞條（數(shù)據(jù)或控制項）的加工。⑥注釋：數(shù)據(jù)量，峰值，限制，組織方式等4.2.3數(shù)據(jù)詞典數(shù)據(jù)詞典用于精確、嚴(yán)格地定義

數(shù)據(jù)詞典中的符號

數(shù)據(jù)詞典中的符號例如：類型：數(shù)據(jù)流條目名字：購書列表別名：購書單列表描述：對學(xué)生提供的購書單通過查庫存將有庫存的購書信息匯總形成的列表定義：購書列表={需書單位+書名+（刊號）+數(shù)量+（時限）+[學(xué)生用書|教師用書|圖書館用書]}例如：類型：數(shù)據(jù)流條目類型：數(shù)據(jù)項條目名字：需書單位別名：購書單位描述：提供購書單的單位名稱定義：20個漢字例如：類型：數(shù)據(jù)項條目例如：類型：數(shù)據(jù)存儲條目編號：F1名字：教材庫存量表別名：描述：記錄每種庫存教材的庫存數(shù)量定義：教材庫存量表={書名+（刊號）+（版本）+數(shù)量}數(shù)據(jù)組織方式：按書名拼音順序排列例如：類型：數(shù)據(jù)存儲條目例如：4.2.4加工規(guī)格說明

加工規(guī)格說明用來說明DFD中的數(shù)據(jù)加工的加工細(xì)節(jié)，數(shù)據(jù)加工的輸入，實現(xiàn)加工的算法以及產(chǎn)生的輸出。另外，加工規(guī)格說明指明了加工（功能）的約束和限制，與加工相關(guān)的性能要求，以及影響加工的實現(xiàn)方式的設(shè)計約束。目前用于寫加工規(guī)格說明的工具有結(jié)構(gòu)化語言、判定表和判定樹。4.2.4加工規(guī)格說明加工規(guī)格說明用來說明DFD中的數(shù)據(jù)結(jié)構(gòu)化語言：類型：加工說明條目編號：2.1名字：詢價別名：加工邏輯：首先根據(jù)購書通知逐個進(jìn)行多方詢價然后比較各種報價比較其他情況（有無現(xiàn)貨，付款方式，是否送貨等）綜合評定供應(yīng)商，確定訂貨價格輸入數(shù)據(jù)：購書通知輸出數(shù)據(jù)：訂貨價格觸發(fā)條件：每當(dāng)書庫管理員發(fā)出購書通知執(zhí)行發(fā)生頻度：一般每周一次，最多每天一次結(jié)構(gòu)化語言：類型：加工說明條目判定樹和判定表

判定樹和判定表適于描述多個邏輯條件的組合描述。判定樹根據(jù)判定條件的關(guān)系構(gòu)造，內(nèi)部節(jié)點為判定條件，葉子節(jié)點為判定結(jié)果。判定表的基本結(jié)構(gòu)為：判定樹和判定表判定樹和判定表適于描述多個邏輯條件的組合描述判定樹和判定表

判定樹和判定表判定樹和判定表

判定樹和判定表5UML與面向?qū)ο蠓治龇椒ㄝ^早的軟件開發(fā)，用結(jié)構(gòu)程序設(shè)計方法。這種方法中程序的定律是：程序=（算法）+（數(shù)據(jù)結(jié)構(gòu)）即過程（函數(shù)）是一個獨立的整體，數(shù)據(jù)結(jié)構(gòu)（包含數(shù)據(jù)類型與數(shù)據(jù)）也是一個獨立的整體。兩者分開設(shè)計，以算法（函數(shù)或過程）為主。voidmain(){inta=1,b=2,c;c=max(a,b);}5.1結(jié)構(gòu)化與面向?qū)ο?UML與面向?qū)ο蠓治龇椒ㄝ^早的軟件開發(fā)，用結(jié)構(gòu)程序設(shè)計方結(jié)構(gòu)化程序設(shè)計是一種面向過程的自頂向下的程序設(shè)計方法。BuildACarBuildChassisBuildEngineBuildDriveSystemAssemble…………結(jié)構(gòu)化與面向?qū)ο蠼Y(jié)構(gòu)化程序設(shè)計是一種面向過程的自頂向下的程序設(shè)計方法。Bui結(jié)構(gòu)化設(shè)計中模塊和模塊之間的關(guān)系，被緊緊局限于信息流，試圖通過信息流及其轉(zhuǎn)換來認(rèn)識系統(tǒng)，這限制了對模塊之間眾多關(guān)系的表達(dá)和體現(xiàn)，如繼承、依賴。main()buildD()buildE()buildC()assemble()…………結(jié)構(gòu)化與面向?qū)ο髆ain()buildD()buildE()buildC()流水線式的過程處理與人們?nèi)粘Ｌ幚韱栴}的方式不一致。隨著時間流逝，軟件工程師越來越注重系統(tǒng)整體關(guān)系的表示和數(shù)據(jù)模型技術(shù)（把數(shù)據(jù)結(jié)構(gòu)與過程看作一個獨立功能模塊）。程序定律被重新認(rèn)識：

程序=（過程+數(shù)據(jù)結(jié)構(gòu)）這樣的思想符合現(xiàn)實世界中的事物特征，我們區(qū)分事務(wù)主要依靠就是事物各式各樣的特征，包括事物不同的屬性和特定的行為。集成化的軟件開發(fā)方法--面向?qū)ο蠓椒óa(chǎn)生。結(jié)構(gòu)化與面向?qū)ο罅魉€式的過程處理與人們?nèi)粘Ｌ幚韱栴}的方式不一致。隨著時間流在面向?qū)ο笾校^程與數(shù)據(jù)結(jié)構(gòu)被捆綁成一個對象，這樣就不用為如何實現(xiàn)通盤的程序功能而費(fèi)盡心機(jī)了。這時侯，程序定義變?yōu)椋?/p>

對象=（過程+數(shù)據(jù)結(jié)構(gòu)）程序=（對象+對象+...）也就是說，程序就是許多對象在計算機(jī)中相繼表現(xiàn)自己。而對象又是一個個程序?qū)嶓w。結(jié)構(gòu)化與面向?qū)ο笤诿嫦驅(qū)ο笾校^程與數(shù)據(jù)結(jié)構(gòu)被捆綁成一個對象，這樣就不用為如

思考：請描述你到飯店就餐的情景！

結(jié)構(gòu)化與面向?qū)ο笏伎迹赫埫枋瞿愕斤埖昃筒偷那榫?！結(jié)構(gòu)化與面向?qū)ο?.2.1UML是什么統(tǒng)一建模語言UnifiedModelingLanguageUML是一個通用的可視化建模語言UnifiedModelingLanguage（統(tǒng)一建模語言）是對象管理組織（OMG）制定的一個通用的、可視化的建模語言標(biāo)準(zhǔn)，可以用來可視化（visualize）、描述（specify）、構(gòu)造（construct）和文檔化（document）軟件密集型系統(tǒng)的各種工件（artifacts，又譯制品）

5.2UML基礎(chǔ)5.2.1UML是什么統(tǒng)一建模語言UnifiedModUML的歷史BoochmethodOMTUnifiedMethod0.8OOSEOthermethodsUML0.9UML1.01989-1994期間，OO方法從不足10種增加到50多種UML1.1OOPSLA′95Web-June′96UMLpartnerspublicfeedback

2004FinalsubmissiontoOMG,Nov‘97FirstsubmissiontoOMG,Jan′97OMGAcceptance,Nov1997

Fall1998UML1.3UML2.0UML的歷史BoochmethodOMTUnifiedMUML的創(chuàng)始人UML是由世界著名的面向?qū)ο蠹夹g(shù)專家G.Booch、J.Rumbaugh和I.Jacobson發(fā)起，在Booch方法、OMT方法和OOSE方法的基礎(chǔ)上，廣泛征求意見，集眾家之長，幾經(jīng)修改而完成的。ThreeamigosBoochRumbaughJacobsonUML的創(chuàng)始人UML是由世界著名的面向?qū)ο蠹夹g(shù)專家G.BoUML的特點統(tǒng)一了面向?qū)ο蠓椒ǖ谋硎颈硎灸芰?qiáng)大，可用于各種軟件系統(tǒng)建模，以及其它系統(tǒng)建模，如商業(yè)系統(tǒng)與開發(fā)過程無關(guān)允許擴(kuò)展本身不設(shè)計特點語言的語法及規(guī)則，但可對應(yīng)到各種OOP語言框架UML的特點統(tǒng)一了面向?qū)ο蠓椒ǖ谋硎綰ML和OOA、OODUML既不是方法論，也不是一種開發(fā)過程，而是面向?qū)ο笙到y(tǒng)分析與設(shè)計的建模語言，是一種語言工具。如同英語充當(dāng)國際交流的工具一樣OOA&OOD是方法論，該方法論的實踐過程中需要使用UML的圖符，使用時還必須遵循一定的原則及步驟。UML和OOA、OODUML既不是方法論，也不是一種開發(fā)過程5.2.2UML結(jié)構(gòu)UMLStructure構(gòu)造塊buildingblocks公共機(jī)制commonmechanisms構(gòu)架architecture基本UML建模元素、關(guān)系和圖達(dá)到特定目標(biāo)的公共UML方法系統(tǒng)架構(gòu)的UML視圖5.2.2UML結(jié)構(gòu)UMLStructure構(gòu)造塊公共機(jī)UML模型元素模型元素是構(gòu)成圖片的最基本單位，一種模型元素通常有它主要出現(xiàn)的圖類型，但同時可以用在不同的圖中，但不論出現(xiàn)在哪里，一般表示相同的含義。通用機(jī)制一般用來表示注釋、語義、約束等含義，不隸屬于任何一種圖，是所有圖中通用的一些特殊模型元素。

UML模型元素模型元素是構(gòu)成圖片的最基本單位，一種模型元素

UML模型元素依賴實現(xiàn)UML模型元素UML圖形圖diagrams類圖classdiagrams對象圖objectdiagrams構(gòu)件圖componentdiagrams部署圖deploymentdiagrams用例圖usecasediagrams順序圖sequence`diagrams協(xié)作圖collaborationdiagrams狀態(tài)圖statechartdiagrams活動圖activitydiagrams靜態(tài)模型

(系統(tǒng)結(jié)構(gòu))動態(tài)模型

(系統(tǒng)行為)UML圖形圖類圖對象圖構(gòu)件圖部署圖用例圖順序圖協(xié)作圖狀態(tài)圖活UML圖形對整個系統(tǒng)而言：功能由用例圖描述。靜態(tài)結(jié)構(gòu)由類圖和對象圖描述。動態(tài)行為由狀態(tài)圖、順序圖、協(xié)作圖和活動圖描述。物理架構(gòu)則是由構(gòu)件圖和部署圖描述。UML圖形對整個系統(tǒng)而言：用例圖UseCaseDiagram用例圖定義了系統(tǒng)的功能需求，它完全是從系統(tǒng)的外部觀看系統(tǒng)功能，并不描述系統(tǒng)內(nèi)部對功能的具體實現(xiàn)。是從外部執(zhí)行者的角度來描述系統(tǒng)提供的功能。購買貨品歸還貨品出租貨品報廢貨品店員用例圖UseCaseDiagram用例圖定義了系統(tǒng)的功類圖ClassDiagram類圖描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，表示系統(tǒng)中的類以及類與類之間的關(guān)系。類圖ClassDiagram類圖描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，表示對象圖ObjectDiagram對象圖描述了一組對象以及它們之間的關(guān)系，表示類的對象實例。對象圖是對類圖一種實例化。是系統(tǒng)某個時期可能存在的具體對象實例。aLoan2：借書記錄借書日期=2006-04-16應(yīng)還日期=2006-06-16還書日期=2006-06-10aItem3：圖書序號=003狀態(tài)=租出aReader：讀者編號=042440101姓名=張三……aLoan1：借書記錄借書日期=2006-04-16應(yīng)還日期=2006-06-16還書日期=2006-05-8aItem2：圖書序號=001狀態(tài)=在庫aItem1：圖書流水號=001狀態(tài)=租出aTitle：圖書品種索書號=TP21108館藏數(shù)量=3可借數(shù)量=2…對象圖ObjectDiagram對象圖描述了一組對象以及狀態(tài)圖StateChartDiagram狀態(tài)圖表示一個狀態(tài)機(jī)，強(qiáng)調(diào)對象行為的事件順序。是對類的補(bǔ)充，展示此類對象可能的狀態(tài)和發(fā)生某些事件時其狀態(tài)的轉(zhuǎn)移情況。在館內(nèi)狀態(tài)=在館借出歸還淘汰圖書購買圖書正常狀態(tài)=借出超過期限借出超期通知讀者狀態(tài)圖StateChartDiagram狀態(tài)圖表示一個狀順序圖SequenceDiagram&

協(xié)作圖CollaborationDiagram順序圖和協(xié)作圖均表示一組對象之間的動態(tài)協(xié)作關(guān)系，其中順序圖反映對象之間發(fā)送消息的時間順序，協(xié)作圖反映收發(fā)消息的對象的結(jié)構(gòu)組織。順序圖和協(xié)作圖是同構(gòu)的，即兩者之間可以相互轉(zhuǎn)換。順序圖SequenceDiagram&

協(xié)作圖Col構(gòu)件圖ComponentDiagram構(gòu)件圖描述程序代碼的組織結(jié)構(gòu)。構(gòu)件以及它們之間的依賴關(guān)系，表示系統(tǒng)的靜態(tài)實現(xiàn)視圖。CourseCourseOfferingStudentProfessorCourse.dllPeople.dllCourseUserRegister.exeBilling.exeBillingSystem構(gòu)件圖ComponentDiagram構(gòu)件圖描述程序代碼UML2.0中的構(gòu)件圖UML2.0中的構(gòu)件圖部署圖DeploymentDiagram部署圖反映了系統(tǒng)中軟件和硬件的物理架構(gòu)，表示系統(tǒng)運(yùn)行時的處理節(jié)點以及節(jié)點中構(gòu)件的配置。瘦客戶端Web服務(wù)器(HP6000)應(yīng)用服務(wù)器(HP6000)數(shù)據(jù)庫服務(wù)器(IBM7100)HTTPTCP/IPTCP/IP管理員客戶端TCP/IP部署圖DeploymentDiagram部署圖反映了系統(tǒng)架構(gòu)與視圖軟件架構(gòu)（softwarearchiecture）也稱之為軟件體系結(jié)構(gòu)，它是一組有關(guān)如下要素的重要決策：軟件系統(tǒng)的組織，構(gòu)成系統(tǒng)的結(jié)構(gòu)化元素，接口和它們相互協(xié)作的行為的選擇，結(jié)構(gòu)化元素和行為元素組合成粒度更大的子系統(tǒng)的方式的選擇，以及指導(dǎo)這一組織（元素及其接口、協(xié)作和組合方式）的架構(gòu)風(fēng)格的選擇。IEEE：：架構(gòu)是在組件及其彼此間和與環(huán)境間的關(guān)系引導(dǎo)設(shè)計發(fā)展原則中體現(xiàn)的系統(tǒng)的基本結(jié)構(gòu)。架構(gòu)與視圖軟件架構(gòu)（softwarearchiecture4+1視圖ProcessViewDeploymentViewLogicalViewUse-CaseViewImplementationViewEnd-userFunctionalityProgrammers

Softwaremanagement

PerformanceScalabilityThroughput

SystemintegratorsSystemtopology

Delivery,installationcommunicationSystemengineeringAnalysts/DesignersStructure

4+1視圖ProcessViewDeploymentVi4+1視圖UseCaseViewEnd-user:Functionality這些視圖由用例視圖所統(tǒng)一，它描述項目干系人（stakeholder）的需求；所有其他視圖都是從用例視圖派生而來，該視圖把系統(tǒng)的基本需求捕獲為用例并提供構(gòu)造其他視圖的基礎(chǔ)LogicalViewAnalysts/Designers:Structure系統(tǒng)功能和關(guān)鍵抽象；描述問題域的關(guān)鍵抽象，作為類和對象的集合。重點是展示對象和類是如何組成系統(tǒng)、實現(xiàn)所需系統(tǒng)行為的。4+1視圖UseCaseView4+1視圖ProcessViewSystemintegrators:Performance,Scalability,Throughput系統(tǒng)性能、可伸縮性和吞吐量；建模在我們系統(tǒng)中的可執(zhí)行線程和進(jìn)程作為活動類。其實，它是邏輯視圖面向進(jìn)程的變體，包含所有相同的制品。ImplementationViewProgrammers:SoftwareManagement系統(tǒng)組裝和配置管理；對組成基于系統(tǒng)的物理代碼的文件和構(gòu)件進(jìn)行建模。它同樣展示出構(gòu)件之間的依賴，展示一組構(gòu)件的配置管理以定義系統(tǒng)的版本。DeploymentViewSystemengineering:SystemTopology,Delivery,Installation,Communication系統(tǒng)的拓?fù)浣Y(jié)構(gòu)、分布、移交和安裝；建模把構(gòu)件物理地部署到一組物理的、可計算節(jié)點上，如計算機(jī)和外設(shè)上。4+1視圖ProcessView5.3面向?qū)ο蟮姆治觯∣OA）面向?qū)ο蟮姆治?、設(shè)計和編程是彼此相聯(lián)系又相區(qū)分的。面向?qū)ο蟮姆治鍪窍鄬τ诮Y(jié)構(gòu)化分析方法而言，關(guān)注的是應(yīng)用領(lǐng)域的對象建模。面向?qū)ο蟮姆治鲆餐瑯影ㄐ枨蟮膶?dǎo)出、分析和確認(rèn)等幾個基本活動，但所用的分析方法與模型和傳統(tǒng)的結(jié)構(gòu)化方法不同。5.3面向?qū)ο蟮姆治觯∣OA）面向?qū)ο蟮姆治觥⒃O(shè)計和編程是5.3.1需求導(dǎo)出5.3.1需求導(dǎo)出需求導(dǎo)出工作流程訪談業(yè)務(wù)所屬人獲取高層的功能性需求

訪談項目干系人獲得所有的功能性和非功能性需求

通過SRS文檔確定項目約束和風(fēng)險

通過SRS文檔中的功能性需求創(chuàng)建項目詞典

通過SRS文檔創(chuàng)建初始用例圖

業(yè)務(wù)所屬者腦海中的模型項目干系人腦海中的模型愿景文檔SRS需求導(dǎo)出工作流程訪談業(yè)務(wù)所屬人獲取高層的功能性需求訪談項目訪談業(yè)務(wù)所屬人獲取高層的功能性需求

訪談項目干系人獲得所有的功能性和非功能性需求

通過SRS文檔確定項目約束和風(fēng)險

通過SRS文檔中的功能性需求創(chuàng)建項目詞典

通過SRS文檔創(chuàng)建初始用例圖

業(yè)務(wù)所屬者腦海中的模型項目干系人腦海中的模型愿景文檔SRS確定項目愿景訪談業(yè)務(wù)所屬人獲取高層的功能性需求訪談項目干系人獲得所有的確定項目愿景如果要決定項目的愿景，則必須與項目的業(yè)務(wù)所屬者訪談后決定高級別的功能需求。業(yè)務(wù)所屬者指擁有項目的任何人。功能性需求是系統(tǒng)必須為某個角色所執(zhí)行的操作。確定項目愿景如果要決定項目的愿景，則必須與項愿景訪談焦點愿景訪談需要注意以下方面：用于項目的商業(yè)案例。用于項目的功能需求。風(fēng)險。約束。項目干系人。愿景訪談焦點愿景訪談需要注意以下方面：捕獲需求訪談業(yè)務(wù)所屬人獲取高層的功能性需求

訪談項目干系人獲得所有的功能性和非功能性需求

通過SRS文檔確定項目約束和風(fēng)險

通過SRS文檔中的功能性需求創(chuàng)建項目詞典

通過SRS文檔創(chuàng)建初始用例圖

業(yè)務(wù)所屬者腦海中的模型項目干系人腦海中的模型愿景文檔SRS捕獲需求訪談業(yè)務(wù)所屬人獲取高層的功能性需求制定需求收集的計劃需要：確定所有必須的需求的來源確定所有要訪談的項目干系人制定需求收集的計劃需要：確定捕獲需求的來源可以從多種來源獲取系統(tǒng)需求，以下是主要的幾種：訪談項目干系人觀察用戶的工作

分析和記錄政策和過程分析現(xiàn)有的系統(tǒng)分析和記錄輸入輸出確定捕獲需求的來源可以從多種來源獲取系統(tǒng)需求，以下是主要的幾創(chuàng)建SRS文檔SRS文檔記錄軟件系統(tǒng)的一系列需求SRS文檔包括六部分：項目簡介約束與假定風(fēng)險功能性需求非功能性需求項目術(shù)語SRS文檔應(yīng)該詳細(xì)，避免不清晰與缺乏焦點創(chuàng)建SRS文檔SRS文檔記錄軟件系統(tǒng)的一系列需求功能性需求功能性需求部分包括以下幾部分：主要特性參與者用例應(yīng)用用例詳細(xì)需求功能性需求功能性需求部分包括以下幾部分：用例部分用例部分提供了一個包括所有用例的優(yōu)先級，唯一編號，以及描述的表格。例如：用例部分用例部分提供了一個包括所有用例的優(yōu)先級，唯一編應(yīng)用部分應(yīng)用部分提供了一個包括所有組成系統(tǒng)的獨立應(yīng)用表格。例如：應(yīng)用部分應(yīng)用部分提供了一個包括所有組成系統(tǒng)的獨立應(yīng)用表詳細(xì)需求部分詳細(xì)需求部分是構(gòu)成每一個用例的完整的詳盡的功能性需求列表。每個功能性需求有一個基于用例編碼的標(biāo)識符。這個用例編碼是優(yōu)先級編號加上用例編號每一個功能性需求有一個描述例如：詳細(xì)需求部分詳細(xì)需求部分是構(gòu)成每一個用例的完整的詳盡的功能性寫一個詳細(xì)的需求一個功能性的需求描述的一個重要要素是用單詞“將會”，例如，“旅店預(yù)定系統(tǒng)將會允許一個預(yù)定代理新建，檢索更新，但是不能刪除一個用戶?！睘榱烁釉敿?xì)?？梢栽谙旅娣秶鷥?nèi)考慮：描繪一個用例的數(shù)據(jù)集或者需要；描繪系統(tǒng)中對象之間，活動之間的關(guān)聯(lián)性；描繪能完成一個活動的所有策略。寫一個詳細(xì)的需求一個功能性的需求描述的一個重要要素是用單詞“可追溯性的重要性詳盡的功能性需求定義了系統(tǒng)必須執(zhí)行的行為，貫穿其它的工作流（分析，設(shè)計，實現(xiàn)，測試）對于驗證系統(tǒng)是否滿足需求是非常重要的。用UML注釋中的功能性需求編號標(biāo)記滿足需求的組件用源代碼注釋中的功能需求編號表示滿足需求的代碼塊用測試計劃中的功能需求編號表示是哪個測試驗證了需求被滿足可追溯性的重要性詳盡的功能性需求定義了系統(tǒng)必須執(zhí)行的行為，貫寫非功能性需求部分非功能性需求部分是按照系統(tǒng)質(zhì)量分類的一個完整列表。每一個非功能性需求在一個用例的基礎(chǔ)上給定一個標(biāo)識每一個非功能性需求包含一個描述，例如：寫非功能性需求部分非功能性需求部分是按照系寫項目術(shù)語表SRS中的術(shù)語表應(yīng)該包括：特定領(lǐng)域內(nèi)的術(shù)語同義詞技術(shù)術(shù)語軟件開發(fā)術(shù)語寫項目術(shù)語表SRS中的術(shù)語表應(yīng)該包括：創(chuàng)建初始用例圖訪談業(yè)務(wù)所屬人獲取高層的功能性需求

訪談項目干系人獲得所有的功能性和非功能性需求

通過SRS文檔確定項目約束和風(fēng)險

通過SRS文檔中的功能性需求創(chuàng)建項目詞典

通過SRS文檔創(chuàng)建初始用例圖

業(yè)務(wù)所屬者腦海中的模型項目干系人腦海中的模型愿景文檔SRS創(chuàng)建初始用例圖訪談業(yè)務(wù)所屬人獲取高層的功能性用例圖的必要性SRS是由一系列詳細(xì)的需求組成的，是基于文本形式的?？蛻舴礁上等诵枰到y(tǒng)的一份整體視圖。系統(tǒng)的用例組成了所有開發(fā)的基礎(chǔ)。用例圖的必要性SRS是由一系列詳細(xì)的需求組成的，是基于文本形確定用例圖的元素用例圖是“表示了系統(tǒng)內(nèi)的參與者與用例之間關(guān)系的一個圖”（UMLv1.4specpageB-21）確定用例圖的元素用例圖是“表示了系統(tǒng)內(nèi)的參與者與用例之間關(guān)系參與者（Actors）參與者就是代表與系統(tǒng)進(jìn)行交互的角色這個圖標(biāo)代表了系統(tǒng)的human類型的參與者這個圖標(biāo)能代表參與者是一個外部系統(tǒng)這個圖標(biāo)代表激活用例的時間觸發(fā)器參與者（Actors）這個圖標(biāo)代表了系統(tǒng)的human類型的參用例（UseCases）一個用例封裝了為達(dá)到某個成果的系統(tǒng)的主要行為用例是用橢圓形表達(dá)的，它內(nèi)部的文字就是用例的標(biāo)題用例編碼能夠被用在標(biāo)題的前面，用來建立與SRS的對應(yīng)關(guān)系一個用例描述了為實現(xiàn)某個有價值的成果，在參與者與系統(tǒng)之間進(jìn)行的交互。用例（UseCases）一個用例封裝了為達(dá)到某個成果的系統(tǒng)系統(tǒng)邊界“用例可選擇附在一個長方形里表示系統(tǒng)內(nèi)部的邊界(UMLv1.4spec.page354)”系統(tǒng)的邊界是隨意的這個等價的用例圖表示了一個透明的系統(tǒng)邊界系統(tǒng)邊界“用例可選擇附在一個長方形里表示系統(tǒng)內(nèi)部的邊界(UM用例關(guān)聯(lián)用例關(guān)聯(lián)描述了“在用例中一個用戶的參與。”一個參與者必須關(guān)聯(lián)一個或者多個用例一個用例必須關(guān)聯(lián)一個或者多個參與者它們之間的關(guān)聯(lián)是用一條沒有箭頭的實線來表示的用例關(guān)聯(lián)用例關(guān)聯(lián)描述了“在用例中一個用戶的參與。”創(chuàng)建一個用例圖創(chuàng)建和命名系統(tǒng)的邊界長方形。確定所有從SRS中得到的系統(tǒng)的參與者。為每個參與者：用例為系統(tǒng)描述了所有高級的行為和有哪些參與者參與了這些行為中。創(chuàng)建一個用例圖，主要有以下幾個步驟：

在圖中增加一個參與者的圖標(biāo)在每個參與者參與的圖中增加用例畫出參與者的用例關(guān)聯(lián)創(chuàng)建一個用例圖創(chuàng)建和命名系統(tǒng)的邊界長方形。用例為系統(tǒng)描述了所例：HotelReservationSystem1）創(chuàng)建系統(tǒng)邊界例：HotelReservationSystem1）創(chuàng)建2）增加用戶這個參與者和用例2）增加用戶這個參與者和用例3）增加預(yù)約代理這個參與者3）增加預(yù)約代理這個參與者4）增加了接待員這個參與者4）增加了接待員這個參與者保存用例圖用例圖提供了SRS功能性需求部分的可視化表示法。保持SRS中的用例圖能夠促進(jìn)保持兩個成果物的同步。用例圖的主要目的是為用戶提供系統(tǒng)行為的簡單視圖。用例圖能夠放置在SRS中。保存用例圖用例圖提供了SRS功能性需求部分的可視化表示法。用用例場景盡可能詳細(xì)的從來不包含有條件的陳述以相同的方法開始但擁有不同的結(jié)果不指明過多用戶界面方面的細(xì)節(jié)顯示成功的也顯示不成功的結(jié)果（在不同的場景中）一個用例場景是一個用例的混合實例一個用例場景應(yīng)該：用例場景驅(qū)動著幾個其他的OOAD工作流程用例場景盡可能詳細(xì)的一個用例場景是一個用例的混合實例用例場景選擇用例場景用例包括與參與者的復(fù)雜的交互作用。用例有幾個潛在的失敗點，例如系統(tǒng)或者數(shù)據(jù)庫的外部的交互作用。為所有用例創(chuàng)建多個場景，將花費(fèi)很多的時間。因此，可以通過下面的標(biāo)準(zhǔn)，選擇合適的場景：下面是場景的兩種類型：主要的場景用來記錄成功的結(jié)果次要的場景用來記錄失敗的事件選擇用例場景用例包括與參與者的復(fù)雜的交互作用。為所有用例創(chuàng)建書寫一個用例場景一個用例場景是一個故事：描述了一個參與者怎么使用系統(tǒng)和系統(tǒng)對參與者的動作給于了怎么樣回應(yīng)。擁有一個開始，一個過程和一個結(jié)果。書寫一個用例場景一個用例場景是一個故事：用例場景舉例開始：MedocaSansumi,是theSantaCruzB&B的酒店前臺，一邊看著theHotelAppMain的銀幕一邊等著電話。電話從Ms.JaneGoogol打來，一個來自紐約的客戶。Ms.Googol拿起電話說“你好，我是JaneGoogol，我想要為新年的前夜預(yù)定一間房間”。Medoca在HotelApp的主銀幕上選擇了“創(chuàng)建預(yù)定”。屏幕上顯示出一個空預(yù)定。用例場景舉例開始：中間過程：Medoca問到“你什么時候到達(dá)這里？”。Jane回答到“12月31日到，我想要住到1月5日?！盡edoca輸入了開始日期，并且問到“你想要預(yù)定什么類型的房子呢？”，“我將和我的丈夫一起到那，所以需要一個單獨的并且有足夠空間的，那個Blue房子有空的嗎？”Jane問到。Medoca選擇“single”在預(yù)定的表格中，完成了查找。系統(tǒng)給予了三種空房間的回應(yīng)：Victoria,Blue和Queen?！笆堑模锌盏摹盡edoca回答。Medoca選擇了Bule房間，系統(tǒng)把它填入預(yù)定的表格中，然后做出“held”的預(yù)約記號。用例場景舉例中間過程：用例場景舉例更多的中間過程：Medoca向系統(tǒng)中輸入Jane的全名。Ms.Googol是一個現(xiàn)有的客戶，所以系統(tǒng)通過客戶表單的數(shù)據(jù)在預(yù)約的表格中給出回應(yīng)。“你想要今天就把這個預(yù)定確定下來嗎？”Medoca問道?！笆堑摹盝ane說，“用我的VISA卡，卡號是：1111-2222-3333-4444?！盝ane在Medoca把卡號輸入進(jìn)去以后暫停了。“截至日期是2007年7月?！盡edoca輸入這些信息，并且在系統(tǒng)上選擇了“VerifyPayment（確認(rèn)付款）”。五分鐘后，系統(tǒng)給出了銀行存款驗證的回應(yīng)。系統(tǒng)把預(yù)定的狀態(tài)改成了“confirmed.”用例場景舉例更多的中間過程：用例場景舉例結(jié)束：Medoca告訴Jane預(yù)約號（系統(tǒng)產(chǎn)生的），并且問道“我還能為您做什么？”，Jane回答沒什么了，Medoca向Jane道謝并且再見。Medoca關(guān)閉了預(yù)約表格的窗口，系統(tǒng)返回到MainHotelApp的主屏幕上。用例場景舉例結(jié)束：用例場景舉例保存用例場景用例場景比較長，通常是保存在從SRS中分離出來的文檔中SRS應(yīng)該建立對這些用例場景的文檔的引用保存用例場景用例場景比較長，通常是保存在從SRS中分離出來的5.3.2需求分析（精化）5.3.2需求分析（精化）需求分析工作流程分析用例場景發(fā)現(xiàn)更多細(xì)節(jié)在分析的基礎(chǔ)上精化用例圖用活動圖驗證用例用CRC分析法確定關(guān)鍵抽象表述域模型中關(guān)鍵抽象之間的關(guān)系使用從用例場景中得到的對象圖來驗證域模型SRSUseCaseformCRC需求分析工作流程分析用例場景發(fā)現(xiàn)更多細(xì)節(jié)在分析的基礎(chǔ)上精化用精化用例分析用例場景發(fā)現(xiàn)更多細(xì)節(jié)在分析的基礎(chǔ)上精化用例圖用活動圖驗證用例用CRC分析法確定關(guān)鍵抽象表述域模型中關(guān)鍵抽象之間的關(guān)系使用從用例場景中得到的對象圖來驗證域模型SRSUseCaseformCRC精化用例分析用例場景發(fā)現(xiàn)更多細(xì)節(jié)在分析的基礎(chǔ)分析用例創(chuàng)建一個用例表格。識別繼承模式。識別用例依賴。分析用例創(chuàng)建一個用例表格。用例表格用例表格用于記錄單用例詳細(xì)分析和用例場景用例表格用例表格用于記錄單用例詳細(xì)分析和用例場景用例表格用例表格創(chuàng)建用例表按照下面的步驟確定用例表中應(yīng)填寫的信息：1、依照SRS文檔來填寫數(shù)據(jù)。2、依據(jù)用例場景決定前置條件；3、依據(jù)用例場景決定觸發(fā)條件；4、依據(jù)用例主要用例場景決定主事件流；5、依據(jù)用例次要用例場景決定可選事件流6、決定后置條件創(chuàng)建用例表按照下面的步驟確定用例表中應(yīng)填寫的信息：第一步—根據(jù)需求規(guī)約文檔填寫相關(guān)信息根據(jù)需求規(guī)約文檔填寫下列元素：第一步—根據(jù)需求規(guī)約文檔填寫相關(guān)信息根據(jù)需求規(guī)約文檔填寫下列第二