軟件工程教案范本

教師備課教案本

教師授課計劃*課程名稱軟件工程學(xué)分3課程類型1、普通教育必修課（）；2、學(xué)科基礎(chǔ)必修課（）；3、專業(yè)方向課（√）；4、學(xué)科基礎(chǔ)選修課（）；5、素質(zhì)教育選修課（）；6、專業(yè)選修課（）。學(xué)時分配總學(xué)時：48；課堂講授：32學(xué)時；實踐（驗）課16學(xué)時授課起止周1-16授課班級軟件工程班級人數(shù)56,69,50授課總次數(shù)*16教材名稱《軟件工程案例教程：軟件項目開發(fā)實踐第2版》作者韓萬江姜立新出版時間2011年10月13日章節(jié)基本內(nèi)容計劃學(xué)時1軟件工程總攬（軟件工程知識體系，軟件工程的三段論，方法、過程和工具的概述）62軟件開發(fā)模型及可行性研究2軟件需求（需求定義，需求層次，需求建模，需求規(guī)格說明，需求驗證和變更控制）43分析建模（領(lǐng)域建模，架構(gòu)設(shè)計）44軟件設(shè)計（設(shè)計模式的應(yīng)用,子系統(tǒng)設(shè)計）86軟件編碼（編碼方法，編碼過程）47軟件測試、發(fā)布與維護(hù)（測試方法，測試級別）4考核要求（根據(jù)課程實際情況，不做要求的項目可不寫）：1、平時成績的構(gòu)成比例和考核方式；20%考勤和讀書筆記2、期中成績的構(gòu)成比例和考核方式；3、期末成績的構(gòu)成比例和考核方式；50%綜合課程設(shè)計4、實驗成績的構(gòu)成比例和考核方式。30%上機(jī)實驗。填表日期：2015年3月1日章節(jié)名稱第一章總攬（4次課）教學(xué)目的講解軟件工程三個基本要素，通過比較各種軟件工程方法的優(yōu)缺點來給出面向?qū)ο筌浖こ谭椒ㄕ摗Ｍ瑫r講解各種軟件過程模型，以及uml建模語言的相關(guān)知識。教學(xué)重點與難點軟件工程的三個基本要素面向?qū)ο筌浖こ趟枷?，學(xué)會以對象的方式來思考問題UML表示法教學(xué)內(nèi)容與過程設(shè)計教學(xué)內(nèi)容與過程設(shè)計軟件工程的成果是為軟件設(shè)計和開發(fā)人員提供思想方法和工具，而軟件開發(fā)是一項需要良好組織、嚴(yán)密管理且各方面人員配合協(xié)作的復(fù)雜工作。軟件工程正是指導(dǎo)這項工程的一門科學(xué)。一、軟件工程知識體系（1）需求定義為解決真實世界問題而必須展示的特性。（2）設(shè)計既是“定義一個系統(tǒng)或組件的體系結(jié)構(gòu)、組件、接口和其它特征的過程”，又是“這個過程的結(jié)果”。（3）軟件構(gòu)造指通過編碼、驗證、單元測試、集成測試和排錯的組合，詳細(xì)創(chuàng)建一個可以工作的、有意義的軟件。（4）軟件測試由在有限測試用例集合上，根據(jù)期望的行為，對程序的行為進(jìn)行的動態(tài)驗證組成，測試用例是從實際上是無限的執(zhí)行域中適當(dāng)?shù)倪x擇出來的。（5）軟件一旦投入運行，就可能出現(xiàn)異常，運行環(huán)境可能發(fā)生改變，用戶會提出新的需求。生命周期的維護(hù)階段從軟件交付時開始，但維護(hù)活動出現(xiàn)得還要早。（6）軟件配置管理（SoftwareConfigurationManagement，SCM）是為了系統(tǒng)地控制配置的變更和維護(hù)配置在整個系統(tǒng)的生命周期中的完整性和可追蹤性，而標(biāo)識軟件在時間上不同點的配置的學(xué)科。（7）軟件工程管理知識域處理軟件工程的管理與度量，雖然度量是所有知識域的一個重要方面，但在這里涉及的是度量程序的主題。（8）軟件工程過程的知識域涉及軟件工程過程本身的定義、實現(xiàn)、評定、度量、管理、變更和改進(jìn)。（9）軟件工程工具和方法知識域包括軟件工程工具、軟件工程方法。（10）軟件質(zhì)量知識域處理跨越軟件生命周期過程的軟件質(zhì)量的考慮，由于軟件質(zhì)量在軟件工程中無處不在，其它知識域也涉及質(zhì)量問題，讀者可以注意到本知識域到其它知識域的指示器?？己朔绞剑航M隊，通過在整個項目的實施過程中不斷貫徹軟件工程的思想，達(dá)到培養(yǎng)團(tuán)隊開發(fā)的目的。討論：小組人數(shù)最好多于3人，這是基于以下事實：給延期的項目增加人手會使項目進(jìn)一步延期。因為向項目中增加人手，就必須花時間來進(jìn)行培訓(xùn)。因此最終結(jié)果變成了：新增人員貢獻(xiàn)非常慢，即使他們的效率確實很高時，那也只是耗盡了原有程序員的時間和精力。而且，項目中的程序員越多，程序員之間的相互交流就越復(fù)雜。該事實詮釋了一部軟件工程經(jīng)典著作的書名，《TheMythicalMan-Month》即人月神話。該書指出：雖然我們采用人月（peoplepermonth）為單位來安排人手，但是每個人對軟件的貢獻(xiàn)各不相同，所以這些人月也不盡相同。在項目后期加入的人員更是如此，這些人的貢獻(xiàn)幾乎可以忽略不計。二、軟件工程概述瓦茨·S·漢弗萊在IBM工作了27年，負(fù)責(zé)管理IBM全球產(chǎn)品研發(fā)。離任后，受美國國防部委托，加入卡內(nèi)基·梅隆大學(xué)軟件工程研究所（SEI），領(lǐng)導(dǎo)SEI過程研究計劃，并提出了能力成熟模型（CMM）思想。在CMM浪潮席卷軟件工業(yè)界之時，他又力推個人軟件過程（PersonalSoftwareProcess，PSP）和團(tuán)隊軟件過程（TeamSoftwareProcess，TSP），成為軟件開發(fā)人員和開發(fā)團(tuán)隊的自修寶典。強(qiáng)調(diào)：這里需要注意“復(fù)雜”兩個字，過于簡單的應(yīng)用沒有必要是結(jié)構(gòu)復(fù)雜化，高級的體系結(jié)構(gòu)、框架、設(shè)計模式都是為復(fù)雜系統(tǒng)準(zhǔn)備的。軟件的復(fù)雜性：軟件是一個龐大的邏輯系統(tǒng)，此外，軟件主要依靠人腦的“智力”構(gòu)造出來，多種人為因素使得軟件難以統(tǒng)一化，更增加了其復(fù)雜性。軟件的復(fù)雜性使得軟件產(chǎn)品難以理解，難以生產(chǎn)，難以維護(hù)，更難以對生產(chǎn)過程進(jìn)行管理。許多軟件項目在某些方面非常復(fù)雜。例如，軟件所涉足的應(yīng)用領(lǐng)域往往包含復(fù)雜的專業(yè)知識，而懂得應(yīng)用領(lǐng)域?qū)I(yè)知識的人很可能不是實際編寫軟件的人。所以，這些領(lǐng)域的專家必須和負(fù)責(zé)軟件開發(fā)的技術(shù)人員交流自己的需求。交流的過程是復(fù)雜的，軟件開發(fā)人員只有在理解了用戶面臨的問題和需求后，才能動手開發(fā)軟件。最后，許多進(jìn)行中的軟件項目規(guī)模非常大，不可能由一個人獨立完成，因而開發(fā)技術(shù)小組必須將開發(fā)任務(wù)分成易于管理的模塊，當(dāng)各個部分全部完成后，將它們組裝成可以協(xié)同工作的整體。將一個大項目分割成幾個小部分，每個小部分由不同的人來開發(fā)，并且保證這些部分可以在一起工作，這個工程成為軟件開發(fā)過程另一個復(fù)雜的來源。軟件發(fā)展過程強(qiáng)調(diào)軟件工程學(xué)科的發(fā)展沒有停止，而且這里面沒有教條，只有實踐。舉例：1、倫敦股票交易系統(tǒng)當(dāng)初預(yù)算4.5億英鎊，后來追加到7.5億英鎊，歷時五年，但最終還是失敗，導(dǎo)致倫敦股票市場聲譽下跌。2、2007年北京機(jī)場信息系統(tǒng)癱瘓。2007年10月10日13時28分，設(shè)在北京首都國際機(jī)場的中國民航信息網(wǎng)絡(luò)股份公司離港系統(tǒng)突然發(fā)生故障，短短50分鐘內(nèi)，北京、廣州、深圳、長沙機(jī)場至少84個離港航班發(fā)生延誤。該系統(tǒng)是由美國某家公司研發(fā)，此事件引發(fā)信息系統(tǒng)安全的擔(dān)憂。3、2008年北京奧運會售票系統(tǒng)于2007年10月30日上午11時癱瘓：北京奧運會的指定獨家票務(wù)供應(yīng)商——北京歌華特瑪捷票務(wù)公司成立于2006年9月，由美國特瑪捷公司、中體產(chǎn)業(yè)股份有限公司及北京歌華文化發(fā)展集團(tuán)三家出資構(gòu)建而成。售票系統(tǒng)癱瘓事件發(fā)生后，公眾普遍質(zhì)疑該公司是否具備承擔(dān)08年北京奧運會的票務(wù)銷售能力。三、軟件工程三個要素——方法、工具、過程。軟件工程是一門建立在以質(zhì)量焦點為基礎(chǔ)，分過程、方法和工具三個研究層次的綜合技術(shù)。軟件工程的基層是過程層，軟件過程層是將方法和技術(shù)結(jié)合在一起的凝聚層，使得軟件能夠合理地、及時地開發(fā)出來。軟件方法：在軟件開發(fā)過程中所采用的技術(shù)，例如結(jié)構(gòu)化的方法、面向?qū)ο蟮姆椒?。軟件過程：在軟件產(chǎn)品生產(chǎn)過程中，軟件人員所進(jìn)行的一系列的軟件工程活動。軟件工具：在軟件開發(fā)過程中為了實現(xiàn)某些方法而采用的手段，例如CASE工具，UML以及Rose等。討論：一個有爭議的觀點：在軟件開發(fā)中，最重要的因素不是程序員采用的工具、技術(shù)和語言，也不是過程，而是程序員自身的質(zhì)量。這一觀點來源于《peopleware》人件。其中說道“我們工作中最重要的問題與其說是技術(shù)問題，還不如說它本質(zhì)上是社會問題?！辈⑻岢隽恕叭藛T的作用遠(yuǎn)遠(yuǎn)大于其他任何因素”。這本書還有一些獨到的見解，比如“工作環(huán)境對工作效率和產(chǎn)品質(zhì)量也有影響”。例如，“最好團(tuán)隊的工作空間是最差團(tuán)隊的1.7倍（測量可用地板空間），而最好團(tuán)隊的表現(xiàn)是最差團(tuán)隊的2.6倍。軟件工程的基本原理用分階段的生命周期計劃嚴(yán)格管理2.堅持進(jìn)行階段評審3.實行嚴(yán)格的產(chǎn)品控制4.采用現(xiàn)代程序設(shè)計技術(shù)5.結(jié)果應(yīng)能清楚地審查6.開發(fā)小組的人員應(yīng)該少而精7.承認(rèn)不斷改進(jìn)軟件工程實踐的必要性四、軟件方法論軟件描述的就是現(xiàn)實業(yè)務(wù)在計算機(jī)中的映射，說起來簡單，做起來很難。因為現(xiàn)實業(yè)務(wù)越來越復(fù)雜，而用戶希望對軟件的操作是越直接越好。軟件分析設(shè)計方法的演變：1、沒有方法。即意大利面條：SpaghettiCode，意指包含復(fù)雜龐大控制結(jié)構(gòu)，雜亂無章的代碼，特別是大量使用goto語句的代碼等等。2、功能分解法功能分解＝功能＋子功能＋功能接口以系統(tǒng)需要提供的功能為中心來組織系統(tǒng)。適用于功能穩(wěn)定的應(yīng)用領(lǐng)域，如科學(xué)計算等。缺點：開頭容易，結(jié)束難。對眾多領(lǐng)域而言，功能易變。如企業(yè)管理和商業(yè)管理。對需求變化的適應(yīng)能力很差。局部錯誤和局部修改很容易產(chǎn)生全局性的影響。重視功能，忽略數(shù)據(jù)?！九e例】工資支付系統(tǒng)：更新工資信息；發(fā)放工資。更新工資信息：檢查員工信息；提交工作記錄；計算應(yīng)發(fā)工資。發(fā)放工資：檢查員工信息；計算應(yīng)發(fā)工資；打印工資單；登記領(lǐng)取。3、數(shù)據(jù)流法：又稱作結(jié)構(gòu)化分析?；静呗允歉檾?shù)據(jù)流，即研究問題域中數(shù)據(jù)如何流動以及在各個環(huán)節(jié)上進(jìn)行何種處理，從而發(fā)現(xiàn)數(shù)據(jù)流和加工。4、信息建模法：信息建模＝實體（對象）＋屬性＋關(guān)系＋父類型/子類型＋關(guān)聯(lián)對象由實體－關(guān)系法發(fā)展而來。與數(shù)據(jù)庫設(shè)計有很深的淵源。核心概念是實體和關(guān)系，實體描述問題域的事物，包含屬性。關(guān)系描述事物之間在數(shù)據(jù)方面的聯(lián)系，也可以帶有屬性。重視實體，而忽略功能。5、面向?qū)ο蠓椒ǎ好嫦驅(qū)ο蠓椒ǖ某霭l(fā)點和基本原則，是盡可能模擬人類習(xí)慣的思維方式，使開發(fā)軟件的方法與過程盡可能接近人類認(rèn)識世界解決問題的方法與過程，也就是使描述問題的問題空間(也稱為問題域)與實現(xiàn)解法的解空間(也稱為求解域)在結(jié)構(gòu)上盡可能一致。五、面向?qū)ο蟮幕靖拍睿?）對象在應(yīng)用領(lǐng)域中有意義的、與所要解決的問題有關(guān)系的任何事物都可以作為對象，它既可以是具體的物理實體的抽象，也可以是人為的概念，或者是任何有明確邊界和意義的東西。例如，一名職工、一家公司、一個窗口、一座圖書館、一本圖書、貸款和借款等，都可以作為一個對象。總之，對象是對問題域中某個實體的抽象，設(shè)立某個對象就反映了軟件系統(tǒng)保存有關(guān)它的信息，并具有與它進(jìn)行交互的能力。對象的定義對象是封裝了數(shù)據(jù)結(jié)構(gòu)及可以施加在這些數(shù)據(jù)結(jié)構(gòu)上的操作的封裝體，這個封裝體有可以唯一標(biāo)識它的名字，而且向外界提供一組服務(wù)。屬性表示對象的性質(zhì)，屬性值規(guī)定了對象所有可能的狀態(tài)。對象的操作是指該對象可以展現(xiàn)的外部服務(wù)。例如，大型客機(jī)可視為對象，它具有位置、速度、顏色、容量等屬性，對于該對象可施行起飛、降落、加速、維修等操作，這些操作將或多或少地改變飛機(jī)的屬性值(狀態(tài))。（2）類是具有相同數(shù)據(jù)結(jié)構(gòu)和相同操作的一組相似對象的抽象。即表示某些對象在屬性和操作方面的共同特征。例如：直升飛機(jī)、大型客機(jī)、轟炸機(jī)可歸為飛行器類。共同屬性有：位置、速度和顏色等共同操作有：起飛、降落、加速和維修等類是在對象之上的抽象，有了類以后，對象則是類的具體化，是類的實例。把一組對象的共同特性加以抽象并存貯在一個類中的能力，是面向?qū)ο蠹夹g(shù)最重要的一點！（3）消息對象之間進(jìn)行通訊的一種構(gòu)造叫做消息。當(dāng)一個消息發(fā)送給某個對象時，包含要求接收對象去執(zhí)行某些活動的信息。接收到消息的對象經(jīng)過解釋，然后予以響應(yīng)。這種通訊機(jī)制叫做消息傳遞。發(fā)送消息的對象不需要知道接收消息的對象如何對請求予以響應(yīng)。訪問一個方法的過程稱為向這個對象發(fā)送一個消息。例如：MyCircle.Show(Green)，MyCircle是接收消息的對象的名字，Show是消息名，Green是消息的變元。消息的理解A）如何要求對象完成一定的處理動作？對象間如何進(jìn)行聯(lián)系？所有這一切都只能通過消息傳遞來實現(xiàn)。B）傳遞消息的對象稱為發(fā)送者，接受消息的對象稱為接受者。C）消息中只包含傳遞者的要求，它告訴接受者需要哪些處理，但并不指示接受者應(yīng)該怎樣完成這些處理。D）消息完全由接受者解釋，接受者獨立決定采用什么方式完成所需的處理，發(fā)送者對接受者不起任何控制作用。（4）封裝封裝幫助你管理復(fù)雜度的方法是不讓你看到那些復(fù)雜度。在面向?qū)ο蟮某绦蛑?，把?shù)據(jù)和實現(xiàn)操作的代碼集中起來放在對象內(nèi)部。一個對象好像是一個不透明的黑盒子，表示對象狀態(tài)的數(shù)據(jù)和實現(xiàn)操作的代碼與局部數(shù)據(jù)都被封裝在黑盒子里面，從外面是看不見的，更不能從外面直接訪問和修改這些數(shù)據(jù)和代碼。使用對象的時候只需要知道他向外界提供的接口的形式，無須知道它的數(shù)據(jù)結(jié)構(gòu)細(xì)節(jié)和實現(xiàn)操作的算法。信息隱藏的一個例子：假設(shè)你有一個程序，其中的每個對象都是通過一個名為id的成員變量來保存一種唯一的ID。這種設(shè)計方法是用一個整數(shù)來表示ID，同時用一個名為g_maxId的全局變量來保存目前已分配的ID的最大值。每當(dāng)創(chuàng)建新的對象時，你只要在該對象的構(gòu)造函數(shù)中簡單地使用id=++g_maxId，就肯定能獲得一個唯一的ID值，這樣設(shè)計有沒有問題？問題：1、如果你想把某些范圍的ID留做它用該怎么辦？2、如果你想使用非連續(xù)的ID來提高安全性？3、如果你想重新使用已銷毀對象的ID？4、如果你的程序是多線程的，這種方法也不是線程安全的。創(chuàng)建新ID的方法就是一種你應(yīng)該隱藏起來的設(shè)計決策。如果你在程序中到處使用++g_maxId，你就暴露了創(chuàng)建新ID的方法。相反，如果你在程序中都使用id=NewId()，那么就把創(chuàng)建新ID的方法隱藏起來了。再假設(shè)你發(fā)現(xiàn)需要把ID的類型由整型改為字符串。此時你會想到應(yīng)該隱藏ID的類型。在C++里面，你可以簡單地使用typedef把ID定義為IdType，或者定義一個IdType的類。（5）繼承廣義地說，繼承是指能夠直接獲得已有的性質(zhì)和特征，而不必重復(fù)定義它們。在面向?qū)ο蠹夹g(shù)中，繼承是子類自動地共享基類中定義的數(shù)據(jù)和方法的機(jī)制。（6）多態(tài)“Thisabilitytomanipulatemorethanonetypewithapointerorareferencetoabaseclassisspokenofaspolymorphism”(《C++Primer》第838頁)。即用基類的指針/引用來操作多種類(基類和其派生類)的對象的能力稱之為多態(tài)。它是從語言實現(xiàn)的角度來考慮的。“polymorphismprovidesanotherdimensionofseparationofinterfacefromimplementation,todecouplewhatfromhow”(《ThinkinJava》3rdedtion)，即多態(tài)提供了另外一種分離接口和實現(xiàn)的尺度，即把“做什么”與“怎么做”分開。它是從設(shè)計的角度考慮的。“TheabilitytousethesameexpressiontodenotedifferentoperationsisreferedtoasPolymorphism”，(《Object-OrientedMethodsPrinciples&Practice》3rdEdition，第16頁)。簡單的說，多態(tài)就是“相同的表達(dá)式，不同的操作”，也可以說成“相同的命令，不同的操作”。這是從面向?qū)ο蟮恼Z義的角度來看的。三種說法分別從不同的角度來闡述了多態(tài)的實質(zhì)。其中第三種說法尤為確切：相同的表達(dá)式—函數(shù)調(diào)用，不同的操作——根據(jù)不同的對象就有不同的操作比如在公司中有各種職責(zé)不同的員工(程序員，業(yè)務(wù)員，文管等)，他們“上班”時，做不同的事情(也可以看作是一種業(yè)務(wù)邏輯)，我們把他們各自的工作都抽象為"上班"，關(guān)系如下：不恰當(dāng)?shù)谋扔鳎篛O的精髓是繼承、封裝和多態(tài)。繼承就是說：你的愛人會繼承做你女朋友時的相當(dāng)多的優(yōu)點，因為這些優(yōu)點對你都是public的，但同時她也會繼承以前的更多的缺點，因為其中很多缺點對你是protected，繼承后才讓你能訪問。封裝就是說：許多不想讓你知道的東西她會封裝起來，你只能通過她提供的有限的接口來訪問到被接口函數(shù)做了手腳的東西。多態(tài)就是說：在她心情不同時，你去訪問以她為參數(shù)的一個函數(shù)得到的結(jié)果是不同的。比如對她說“我愛你”。六、軟件過程過程模型的思想只有兩種：順序和迭代。順序：一年的時間，分成4個階段，每個階段完成一項任務(wù)。迭代：一年的時間，分成4個階段，每個階段作為一次迭代周期，每個迭代周期完成一系列任務(wù)。選擇順序方法的理由：1、需求相當(dāng)穩(wěn)定2、設(shè)計直截了當(dāng)，而且理解透徹。3、開發(fā)團(tuán)隊對于這一應(yīng)用領(lǐng)域非常熟悉。4、項目的風(fēng)險很小。5、后期改變需求，設(shè)計和編碼的代價很可能較昂貴。選擇迭代方法的理由：1、需求并沒有被理解透徹，或者出于其他理由你認(rèn)為它是不穩(wěn)定的。2、設(shè)計很復(fù)雜，或者有挑戰(zhàn)性。3、開發(fā)團(tuán)隊對于這一應(yīng)用領(lǐng)域不熟悉。4、項目包含許多風(fēng)險。5、后期改變需求，設(shè)計和編碼的代價很可能較低。1、瀑布模型瀑布模型的特點：階段間具有順序性和依賴性；盡可能推遲程序的物理實現(xiàn)；基于文檔驅(qū)動的模型。瀑布模型的缺點：傳統(tǒng)的瀑布模型過于理想化，實際的瀑布模型是帶“反饋環(huán)”的。需求具有變更性，無法在最初就準(zhǔn)確無誤的確定下來。最終開發(fā)出的軟件產(chǎn)品可能并不是用戶真正需要的。所以瀑布模型的采用，一定要保證需求必須是準(zhǔn)確定義和相對穩(wěn)定的。2、快速原型模型快速原型模型是不帶反饋環(huán)的，軟件產(chǎn)品的開發(fā)基本上是線性順序進(jìn)行的。因為原型系統(tǒng)已經(jīng)通過與用戶交互而得到驗證，據(jù)此產(chǎn)生的規(guī)格說明文檔正確地描述了用戶需求。快速原型模型的本質(zhì)就是“快速”，一旦需求確定了，原型將被拋棄。制作原型：制作原型是指開發(fā)出系統(tǒng)中關(guān)鍵功能的實際模型。例如開發(fā)出一部分用戶界面的原型可以判斷系統(tǒng)的可用性，開發(fā)出關(guān)鍵算法的原型可以確定功能的執(zhí)行時間，開發(fā)出典型數(shù)據(jù)集的原型能知道程序的內(nèi)存需求。3、增量模型把軟件產(chǎn)品作為一系列的增量構(gòu)件來設(shè)計、編碼、集成和測試。通常，第一個增量構(gòu)件往往實現(xiàn)軟件的基本需求，提供最核心的功能。交付產(chǎn)品時采用分批逐步向用戶提交產(chǎn)品，而不是一次性交付產(chǎn)品。使用增量模型的困難是，在把每個新的增量構(gòu)件集成到現(xiàn)有軟件體系結(jié)構(gòu)中時，必須不破壞原來已經(jīng)開發(fā)的產(chǎn)品。因此必須把軟件的體系結(jié)構(gòu)設(shè)計得具有開放性和擴(kuò)充性。增量模型具有可在軟件開發(fā)的早期階段使投資獲得明顯回報和較易維護(hù)的優(yōu)點。在進(jìn)行增量開發(fā)時，我們先做出軟件系統(tǒng)的一個盡可能簡單、但能運行的版本。它不必接受真實的輸入，也無需對數(shù)據(jù)進(jìn)行真正的處理，更不用產(chǎn)生真實的輸出——它僅僅需要構(gòu)成一個足夠強(qiáng)壯的骨架，支撐起未來將要開發(fā)的真實系統(tǒng)。在骨架形成之后，你要一點點地在其上附著肌肉和皮膚：把每個虛假的類替換為真正的類；不再假裝接受輸入，而是把接收真實輸入的代碼替換進(jìn)去；不再假裝產(chǎn)生輸出，而是把產(chǎn)生真實輸出的代碼替換進(jìn)去。你一次增加一小部分代碼，直到得到一個完全可以工作的系統(tǒng)。【舉例】采用增量模型開發(fā)的字處理軟件，在第1個增量中提供基本的文件管理、編輯和文檔生成功能；在第2個增量中提供復(fù)雜的編輯和文檔生成功能；在第3個增量中提供拼寫和語法檢查功能；在第4個增量中提供高級頁面排版功能。4、螺旋模型螺旋模型可以理解為帶有風(fēng)險分析過程的快速原型模型。構(gòu)建原型是一種能使某些類型的風(fēng)險降至最低的方法，但原型不能“包治百病”，對于某些類型的風(fēng)險（例如，聘請不到需要的專業(yè)人員，或關(guān)鍵的技術(shù)人員在項目完成前“跳槽”），原型方法是無能為力的。螺旋模型的基本思想是：使用原型及其他方法來盡量降低風(fēng)險。即每個階段之前都增加了風(fēng)險分析過程和快速原型模型。5、噴泉模型“噴泉”體現(xiàn)了面向?qū)ο筌浖_發(fā)過程迭代和無縫的特性。因為用面向?qū)ο蠓椒ㄩ_發(fā)軟件時，在分析、設(shè)計和編碼等項開發(fā)活動之間并不存在明顯的邊界。舉例：如何進(jìn)行迭代和進(jìn)化式分析和設(shè)計。假設(shè)在項目交付前，最終將有20次迭代。1）在第1次迭代之前，召開第一個時間定量的需求工作會議，例如確切的定義為兩天時間。業(yè)務(wù)和開發(fā)人員（包括首席架構(gòu)師）需要出席。 在第一天上午，進(jìn)行高階需求分析，例如僅僅確定用例和特性的名稱，以及關(guān)鍵的非功能性需求。這種分析不可能是完美的。 通過咨詢首席架構(gòu)師和業(yè)務(wù)人員，從高階列表中選擇10％列表項，假設(shè)為3個用例，這些項目需要具備以下三種性質(zhì)：1、具有重要的架構(gòu)意義，2、具有高業(yè)務(wù)價值。3、具有高風(fēng)險。 在剩下的一天半內(nèi)，對這3個用例的功能和非功能性需求進(jìn)行詳細(xì)的分析。完成這一過程后，對10％進(jìn)行了深入分析，90％進(jìn)行了高階分析。2）在第一次迭代之前，召開迭代計劃會議，選擇3個用例的子集，在特定時間內(nèi)進(jìn)行設(shè)計、構(gòu)造和測試。3）在三到四周內(nèi)完成第一次迭代（選擇時間定量，并嚴(yán)格遵守時間）。 在開始兩天內(nèi)，開發(fā)者和其他成員分組進(jìn)行建模和設(shè)計工作，畫出UML草圖。 然后，開發(fā)者摘掉其“建模帽子”并帶上“編程帽子”，開始編程、測試和集成工作并且剩余的時間均用于完成這項工作。 進(jìn)行大量的測試，包括單元測試、驗收測試、負(fù)載測試和可用性測試。 在結(jié)束前的一周，檢查是否能夠完成初始的迭代目標(biāo)；如果不能，則縮小迭代范圍，將次要目標(biāo)置回任務(wù)列表中。 在最后一周的星期二，凍結(jié)代碼，必須檢入、集成和測試所有代碼，以建立迭代的基線。4）在第一次迭代即將結(jié)束時，召開第二次需求工作會，對上一次會議的所有材料進(jìn)行復(fù)查和精化。然后選擇具有重要架構(gòu)意義和高業(yè)務(wù)價值的另外10％到15％的用例，用一到兩天對其進(jìn)行詳細(xì)分析。這項工作完成后，會詳細(xì)記錄大概25％的用例和非功能性需求。當(dāng)然，這也不是完美的。5）與周五上午，舉行下一次迭代的迭代計劃會議。6）以相同的步驟進(jìn)行第2次迭代。7）反復(fù)進(jìn)行四次迭代和五次需求工作會，這樣在第4次迭代結(jié)束時，可能已經(jīng)詳細(xì)記錄了約80％～90％的需求，但是只實現(xiàn)了系統(tǒng)的10％。8）我們大概推進(jìn)了整個項目過程的20％。在UP的術(shù)語里，這是細(xì)化階段的結(jié)束。9）此后，一般不需要再召開需求工作會；需求已經(jīng)穩(wěn)定了。接下來是一系列為期三周的迭代，在最后一個周五召開的迭代計劃會上選擇適宜的下一步工作?？偨Y(jié)：最重要的UP思想——迭代開發(fā)在這種方法中，開發(fā)被組織成一系列固定的短期小項目，稱為迭代；每次迭代都產(chǎn)生經(jīng)過測試的、經(jīng)過集成的和可執(zhí)行的系統(tǒng)。每次迭代都有自己的需求分析、設(shè)計、實現(xiàn)和測試活動。迭代的輸出不是實驗性或?qū)G棄的原型，迭代開發(fā)也不是原型開發(fā)。與之相反，其輸出是最終系統(tǒng)的產(chǎn)品的子集。迭代開發(fā)不是要通過在實現(xiàn)前試圖完整和正確地描述、凍結(jié)和“終止”一個已凍結(jié)的需求集和設(shè)計來應(yīng)對軟件開發(fā)中出現(xiàn)的不可避免的變更，而是要基于擁抱變更和適應(yīng)調(diào)整的態(tài)度將變更和調(diào)整作為迭代開發(fā)中不能避免且真正必要的驅(qū)動力。每次迭代選擇一小組需求，并快速設(shè)計、實現(xiàn)和測試，可以得到快速的反饋——來自用戶、開發(fā)人員和測試（例如負(fù)載測試和可用性測試）的反饋。迭代開發(fā)的優(yōu)點：在早期而不是晚期緩解高風(fēng)險（技術(shù)、需求、目標(biāo)、可用性等方面的風(fēng)險）。早期可見的發(fā)展。早期反饋、用戶參與和調(diào)整，會得到一個更接近項目相關(guān)人員真實需求的經(jīng)過精化的系統(tǒng)。可控復(fù)雜性；開發(fā)組不會被“分析癱瘓”或長期復(fù)雜過程所淹沒。在一次迭代中學(xué)到的知識可以被有系統(tǒng)地用于改進(jìn)開發(fā)過程本身，下一次迭代也是如此，依次類推，進(jìn)行下去。UP階段和流程初始階段：大體上的構(gòu)想，業(yè)務(wù)案例，范圍，模糊評估。細(xì)化階段：已精化的構(gòu)想，核心架構(gòu)的迭代實現(xiàn)，高風(fēng)險的解決，大多數(shù)需求和范圍的識別，更為現(xiàn)實的評估。構(gòu)造階段：迭代實現(xiàn)遺留下來的風(fēng)險較低和比較容易的元素，準(zhǔn)備部署。移交階段：beta測試，部署。細(xì)化階段的一些關(guān)鍵思想和最佳實踐包括：做短時間分區(qū)的、風(fēng)險驅(qū)動的迭代。盡早開始編程。適應(yīng)性地設(shè)計、實現(xiàn)并測試架構(gòu)的核心和風(fēng)險部分。盡早、經(jīng)常、實際地測試。基于來自測試、用戶、開發(fā)人員的反饋信息進(jìn)行調(diào)整。通過一系列的研討會，每個細(xì)化迭代一次，詳細(xì)編寫大部分用例和需求。細(xì)化階段中在架構(gòu)方面重要的是什么：1、早期的迭代建立和證明核心架構(gòu)。（1）采用“寬且淺”的設(shè)計和實現(xiàn)方案。即識別單獨的過程、層、軟件包和子系統(tǒng)以及它們高層的職責(zé)和接口，為了連接它們以及闡明接口而部分實現(xiàn)它們。（2）細(xì)化模塊間的本地和遠(yuǎn)程接口。（3）集成已有的組件。2、為了得到反饋信息，調(diào)整并證明核心架構(gòu)是健壯的，細(xì)化階段測試是重要的。七、軟件工具：UMLUML也稱為統(tǒng)一建模語言。它提供了一個可視化的建模語言，所謂可視化即通過一些很直觀，容易理解的圖形化來描述系統(tǒng)。因此用uml實現(xiàn)的文檔形式為：“圖形化＋文本描述＝相應(yīng)文檔”UML語言很全面，龐大，可以表示各種復(fù)雜的問題。這樣一個豐富的語言，我們只需要用其20%部分，描述80％的問題，因此學(xué)習(xí)中，我們只需要掌握常用的基本組成部分，關(guān)鍵是要對這些組成部分了解之后，能夠應(yīng)用他所提供的表示方法，進(jìn)行分析和設(shè)計。實際上在真正應(yīng)用里面，活用UML是非常關(guān)鍵的，雖然它是一個語言，但是應(yīng)用這個語言要根據(jù)分析設(shè)計里面需要描述設(shè)計模型的需要來應(yīng)用。而不是說死記一些條目，很死板的去應(yīng)用。只有活用，才能感受到UML語言的威力。一個比喻：uml中所提供的標(biāo)準(zhǔn)的圖符，相當(dāng)于音樂五線譜里的樂符，學(xué)會看樂符才能看得懂樂譜，才能進(jìn)一步創(chuàng)造音樂。同樣，懂得uml中的圖符，才能進(jìn)行系統(tǒng)分析和設(shè)計。應(yīng)用UML的三種方式（1）UML作為草圖——非正式的、不完整的圖（通常是在白板上手繪草圖），借助可視化語言的功能，用于探討問題或解決方案空間的復(fù)雜部分。（2）UML作為藍(lán)圖——相對詳細(xì)的設(shè)計圖，用于：1）逆向工程，即以UML圖的方式對現(xiàn)有代碼進(jìn)行可視化，使其易于理解。2）代碼生成（前向工程），一般情況下，代碼生成工具使用圖生成一些代碼，然后由開發(fā)者編寫并填充其他代碼。（3）UML作為編程語言——用UML完成軟件系統(tǒng)可執(zhí)行規(guī)格說明?？蓤?zhí)行代碼能夠被自動生成，但并不像通常一樣為開發(fā)者所見或修改，但是目前在理論、工具的健壯性和可用性方面仍然處于發(fā)展階段。說明：UML和銀彈思想，即相信軟件中存在某種特殊的工具或技術(shù)，可以在生產(chǎn)率、缺陷減少、可靠性和簡易性等方面帶來極大的變化。工具無法彌補設(shè)計上的疏漏。UML的應(yīng)用對象建模是用例驅(qū)動（即建立用例模型，從分析到設(shè)計都是以用例為核心來設(shè)計）：優(yōu)勢于功能列表（不是站在用戶的角度考慮問題）以體系結(jié)構(gòu)為中心（整個系統(tǒng)中強(qiáng)調(diào)體系結(jié)構(gòu)的設(shè)計）迭代開發(fā)過程（由于開發(fā)過程不是一下子能夠全部完成的，強(qiáng)調(diào)迭代化的開發(fā)，可以在用例的設(shè)計過程中不斷的設(shè)計和補充）4＋1視圖在用uml語言建立相應(yīng)系統(tǒng)模型時，具體對于軟件系統(tǒng)是用什么樣的視圖描述，通常uml建議采用4＋1＝5個視圖的描述。用例視圖：整個系統(tǒng)核心，它是從用戶角度對系統(tǒng)的參與和要求的交互過程。描述整個系統(tǒng)具有什么樣的功能。它也是后續(xù)設(shè)計、實現(xiàn)、實施、測試等等所有階段的核心和基礎(chǔ)，所有后續(xù)階段或其他視圖都以它為根本。邏輯視圖：描述該系統(tǒng)，即用例中的所有功能，其內(nèi)部結(jié)構(gòu)是什么，組成關(guān)系是什么。主要應(yīng)用于分析設(shè)計人員，建立相應(yīng)結(jié)構(gòu)。象靜態(tài)結(jié)構(gòu)方面：類，對象，及其關(guān)系；動態(tài)行為方面：并發(fā)，消息等相互聯(lián)系。建立了邏輯視圖之后，還要對系統(tǒng)進(jìn)程、并發(fā)等機(jī)制進(jìn)行描述。進(jìn)程視圖：處理并發(fā)和同步的線程和進(jìn)程。實現(xiàn)視圖：具體開發(fā)時，怎樣把大的復(fù)雜系統(tǒng)分解成若干小的不同系統(tǒng)，進(jìn)行搭建，或不同組件進(jìn)行組合。一般大系統(tǒng)可能有不同組件，到底有哪些組件，哪些文件，這些組件，這些文件怎樣連接，構(gòu)成所要實現(xiàn)的系統(tǒng)。分布視圖：系統(tǒng)開發(fā)完成后，系統(tǒng)可能是在分布式環(huán)境、網(wǎng)絡(luò)環(huán)境下運行，系統(tǒng)不同部分在網(wǎng)絡(luò)環(huán)境下怎樣分布、布置，在部署視圖中提供?？偨Y(jié)：由這樣5個視圖從不同方面完整的表示了系統(tǒng)的所有功能和需要提供各個方面的要求。UML的組成：UML的詞匯表包括3種構(gòu)造模塊：元素、關(guān)系、圖。（1）元素：模型中重要的抽象。結(jié)構(gòu)元素：UML模型中的名詞。是模型中主要的靜態(tài)部分，代表了概念的或物理的元素。1、用例與協(xié)作：前面講過的用例是表示系統(tǒng)要實現(xiàn)的一個具體功能，要完成這個功能，實際需要一組對象類，及其對象類之間的互相關(guān)聯(lián)來實現(xiàn)的，因此協(xié)作是對具體用例的實現(xiàn)進(jìn)行建模，表示方法為虛橢圓。區(qū)別：用例只是描述對外呈獻(xiàn)的行為，不關(guān)心這些具體功能是怎樣實現(xiàn)的，而協(xié)作描述要實現(xiàn)這個用例的功能，具體需要哪些類，類與類之間的關(guān)系怎樣。因此用例和協(xié)作之間是實現(xiàn)的關(guān)系。2、主動類：在類里面有一種類和一般類有一定區(qū)別，這種類具有主動的行為，一般來講它可以主動的啟動一些控制的活動，對實現(xiàn)來說它通常擁有一個進(jìn)程或線程。它的表示方式是在外邊框加粗。例如：事件管理器，它對事件隊列有掛起，刷新功能，該類有一個進(jìn)程對應(yīng)，有主動控制的行為，稱為主動類。3、構(gòu)件：在大的系統(tǒng)開發(fā)過程中，往往把復(fù)雜的系統(tǒng)分成不同的構(gòu)件，所以系統(tǒng)里面真正可以替代的構(gòu)件在UML里面也有相應(yīng)的描述，構(gòu)件往往和接口一起使用的，因為任何構(gòu)件的對外服務(wù)都是通過接口來描述的。行為元素：UML模型中的動態(tài)部分，它是模型中的動詞，代表了跨越時間和空間的行為。UML中有兩種主要的行為元素：交互作用（Interaction）和狀態(tài)機(jī)（StateMachine）。交互作用：由在特定上下文中為完成特定目的而在對象間交換的消息集組成的行為。交互作用包括許多其他元素：消息、動作序列（由消息激活的行為）、連接（對象間的連接）。2、狀態(tài)機(jī)：對象真正在創(chuàng)建到消亡的過程中，即實際生命周期里，是通過響應(yīng)一定的事件，經(jīng)歷了不同的狀態(tài)，所以狀態(tài)機(jī)來描述對象所經(jīng)歷的狀態(tài)的序列，及觸發(fā)狀態(tài)變化的事件。例如：命令處理的狀態(tài)轉(zhuǎn)換。開始系統(tǒng)一啟動，進(jìn)入初始狀態(tài)，在初始狀態(tài)進(jìn)行初始化，準(zhǔn)備工作；初始化完成后，進(jìn)入空閑狀態(tài)，循環(huán)等待輸入的狀態(tài)。如果接收了鍵盤輸入，就使得系統(tǒng)從空閑狀態(tài)進(jìn)入命令處理狀態(tài)，可能一個命令是由多個字符組成，所以它在接收相應(yīng)按鍵之后把相應(yīng)字符存入命令隊列中，然后返回空閑狀態(tài)，當(dāng)下一次再有按鍵進(jìn)入時，又繼續(xù)進(jìn)行處理，如果完整的命令輸入完之后，可能要調(diào)用相應(yīng)的命令處理程序執(zhí)行，如果命令是一個結(jié)束的命令，則整個狀態(tài)機(jī)就結(jié)束了。所以狀態(tài)機(jī)有一個開始狀態(tài)，多個結(jié)束狀態(tài)，中間還有不同的中間狀態(tài)，每個狀態(tài)轉(zhuǎn)換都有相應(yīng)的事件觸發(fā)。分組元素：是UML模型中用來組織元素的元素。在基本的事物組成中，經(jīng)常把大量事物通過分包的方式進(jìn)行組合。包：把一類基本元素分類，按照分包的原則可以各種各樣。（2）關(guān)系：事物之間的連接。真正要構(gòu)成一個系統(tǒng)，事物之間是有一些關(guān)系的。例如：課表和課程之間，課程可以加到課表里，或從課表里刪除。課程變化時，課表相應(yīng)發(fā)生變化。課程和課表之間是依賴關(guān)系。關(guān)聯(lián)關(guān)系：屬性可見性。通常需要保持長期，穩(wěn)定存在的關(guān)系。依賴關(guān)系：非屬性可見性（局部、本地、全局可見性），通常只需要保持短期的，局部的關(guān)系。實現(xiàn)關(guān)系：把具體形式化的描述與具體實現(xiàn)分離的方法。好處：把對外的形式化描述和具體實現(xiàn)分離，分離后如果內(nèi)部實現(xiàn)改變，只要對外形式化描述不變，跟外部交互連接的部分不受到影響。（3）圖：把事物通過關(guān)系連接起來形成圖。真正描述模型是用一個個圖來描述的。UML的9種圖：用例圖：定義了系統(tǒng)的功能需求，它完全是從系統(tǒng)的外部觀看系統(tǒng)功能，并不描述系統(tǒng)內(nèi)部對功能的具體實現(xiàn)。類圖：描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，表示系統(tǒng)中的類以及類與類之間的關(guān)系。對象圖：描述了一組對象以及它們之間的關(guān)系，表示類的對象實例。組件圖：描述組件以及它們之間的關(guān)系，表示系統(tǒng)的靜態(tài)實現(xiàn)視圖。具體系統(tǒng)可能劃分成不同組件和模塊，有哪些模塊，組件之間的關(guān)系怎樣由組件圖描述。例子：在課程注冊管理系統(tǒng)中，有兩個子系統(tǒng)：收費系統(tǒng)，注冊系統(tǒng)。注冊系統(tǒng)分為：課程組件，人員管理組件。注冊系統(tǒng)在課程注冊完后，通過接口調(diào)用收費系統(tǒng)，將學(xué)生相應(yīng)注冊信息傳遞給收費系統(tǒng)，形成對學(xué)生的收費單，通知學(xué)生交費。課程系統(tǒng)又通過接口管理相應(yīng)課程信息，即課程模塊。對于學(xué)生教師人員進(jìn)行管理。通過這兩個模塊，實現(xiàn)存取相應(yīng)人員和課程信息，最后實現(xiàn)相應(yīng)功能。部署圖：反映系統(tǒng)中軟件和硬件的物理架構(gòu)，表示系統(tǒng)運行時的處理節(jié)點，以及節(jié)點中組件的配置。時序圖和協(xié)作圖：都表示一組對象之間的動態(tài)協(xié)作關(guān)系。其中時序圖反映對象之間發(fā)送消息的時間順序，協(xié)作圖反映收發(fā)消息的對象的結(jié)構(gòu)組織。時序圖和協(xié)作圖是同構(gòu)的，即兩者之間可以相互轉(zhuǎn)換。狀態(tài)圖：強(qiáng)調(diào)同一個類里對象狀態(tài)變化過程，和相應(yīng)事件觸發(fā)過程。所謂狀態(tài)，是對對象屬性值的一種抽象。各對象之間相互觸發(fā)（即作用）就形成了一系列的狀態(tài)變化。我們把一個觸發(fā)行為稱作一個事件。對象對事件的響應(yīng)，取決于接受該觸發(fā)的對象當(dāng)時所處的狀態(tài)，響應(yīng)包括改變自己的狀態(tài)或者又形成一個新的觸發(fā)行為。狀態(tài)有持續(xù)性，它占用一段時間間隔。狀態(tài)與事件密不可分，一個事件分開兩個狀態(tài)，一個狀態(tài)隔開兩個事件。事件表示時刻，狀態(tài)代表時間間隔?；顒訄D：反映系統(tǒng)中從一個活動到另一個活動的流程，強(qiáng)調(diào)對象間的控制流程。八、敏捷宣言AgileSoftware敏捷過程作為對慣例性過程的挑戰(zhàn)，由17位方法學(xué)家于2001年2月提出。在該方法論中，他們提出了4項價值以鼓勵更好的開發(fā)軟件：1、個人和交互高于過程和工具。開發(fā)過程中，最重要的因素是必須考慮到開發(fā)者是如何在一起工作的，因為如果他們不能擺正態(tài)度的話，最好的工具和過程也將會失去作用。2、可工作軟件高于詳盡的文檔。3、與客戶合作高于合同談判。只有客戶才能告訴開發(fā)者他們想要什么。與客戶建立合同是重要的，但合同不能代替相互之間的溝通。4、對變化及時做出響應(yīng)高于遵循計劃。變化是軟件開發(fā)的現(xiàn)實。

章節(jié)名稱需求工程（4次課）教學(xué)目的需求的定義和需求的層次。什么是用例，如何編寫用例。如何構(gòu)建需求模型，如何編寫需求規(guī)格說明書。教學(xué)重點與難點1、需求捕獲的方法。2、用例。3、需求模型的構(gòu)建。4、需求規(guī)格說明書的編寫。教學(xué)內(nèi)容與過程設(shè)計教學(xué)內(nèi)容與過程設(shè)計啟動軟件項目是由于軟件需求的存在，資料表明，軟件項目中40％～60％的問題都是在需求分析階段埋下的隱患。軟件開發(fā)中返工開銷占開發(fā)總費用的40％，而其中70％～80％的返工是由需求方面的錯誤所導(dǎo)致。因此一個項目成功的關(guān)鍵因素之一就是對需求分析的把握程度。而項目的整體風(fēng)險往往表現(xiàn)在需求分析不明確，業(yè)務(wù)流程不合理，所以，需求分析是軟件開發(fā)的重要一環(huán)。軟件的需求具有模糊性、不確定性、變化性和主觀性的特點，相比硬件的需求，是有形的、客觀的、可描述的、可檢測的。一、需求的定義需求，是指對用戶需要解決的問題的整體描述。需求是軟件實現(xiàn)之源，沒有了需求，軟件也就無從談起。在IEEE軟件工程標(biāo)準(zhǔn)詞匯表中定義需求為：（1）用戶解決問題或達(dá)到目標(biāo)所需要的條件或能力（2）系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其他正式規(guī)定文檔所需具有的條件或能力（3）一種反映上面（1）或（2）所描述條件或能力的文檔說明二、需求的層次軟件需求是指用戶對軟件的功能和性能的要求。軟件人員要準(zhǔn)確理解用戶的要求，進(jìn)行細(xì)致的調(diào)查分析，將用戶非形式化的需求陳述轉(zhuǎn)化為完整的需求定義，再由需求定義轉(zhuǎn)化到相應(yīng)形式的需求規(guī)格說明。有時也可以將軟件需求按照層次來說明（如上圖）。業(yè)務(wù)需求：反映了組織機(jī)構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們在項目視圖與范圍文檔中說明。用戶需求：用戶使用產(chǎn)品必須要完成的任務(wù)，它們通常使用用例文檔（usecase）進(jìn)行說明。功能需求：開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。非功能需求：描述系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。包括：產(chǎn)品必須遵循的標(biāo)準(zhǔn)、規(guī)范和合約；外部界面的具體細(xì)節(jié)；性能要求；設(shè)計或?qū)崿F(xiàn)的約束條件；質(zhì)量屬性。通常也可以總結(jié)為FURPS+：Functional（功能性）：特性、功能、安全性。Usability（可用性）：人性化因素、幫助、文檔。Reliability（可靠性）：故障頻率、可恢復(fù)性、可預(yù)測性。Performance（性能）：響應(yīng)時間、吞吐量、準(zhǔn)確性、有效性、資源利用率。Supportability（可支持性）：適應(yīng)性、可維護(hù)性、國際化、可配置性。＋：表示一些輔助性的和次要的因素，比如：實現(xiàn)（Implementation）：資源限制、語言和工具、硬件等。接口（Interface）：強(qiáng)加于外部系統(tǒng)接口之上的約束。操作（Operation）：對其操作設(shè)置的系統(tǒng)管理。包裝（Packaging）：例如物理的包裝盒。授權(quán)（Legal）：許可證或其他方式。軟件需求規(guī)格：軟件需求規(guī)格充分描述了軟件系統(tǒng)應(yīng)具有的外部行為，它描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。它包括產(chǎn)品必須遵從的標(biāo)準(zhǔn)、規(guī)范和合約；外部界面的具體細(xì)節(jié)；非功能性需求（例如性能要求等）；設(shè)計或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。軟件需求規(guī)格說明在開發(fā)、測試、質(zhì)量保證、項目管理以及相關(guān)項目功能中都起到重要的作用。為了強(qiáng)調(diào)非功能需求，舉例說明：2月27日，中央電視臺“第一時間”報道了北京市二中院開庭審理程稚瀚涉嫌盜取北京移動通信公司充值卡密碼一案，程稚瀚曾是UT斯達(dá)康深圳分公司工程師，被指控利用網(wǎng)絡(luò)技術(shù)手段侵入北京移動通信公司充值中心數(shù)據(jù)庫，修改充值卡原始數(shù)據(jù)并竊取了充值卡密碼，并通過淘寶網(wǎng)和QQ向他人出售，致使北京移動通信公司損失近380萬元。該欄目主持人認(rèn)為：1.2億元網(wǎng)絡(luò)安全投入，居然不堪一擊，中國移動也該好好總結(jié)一下了。事實上，程稚瀚在作案過程中使用的大多都是些沒有技術(shù)含量的攻擊手段，但是偏偏沒有技術(shù)含量的攻擊事件，在電信、銀行、證券、保險業(yè)卻屢屢得逞另一個案例：兩大學(xué)生利用網(wǎng)通ADSL用戶升級時系統(tǒng)的漏洞，在一個月內(nèi)盜取了價值70余萬元的網(wǎng)易一卡通虛擬游戲點卡。不能不令我們深思。三分技術(shù)，七分管理”的網(wǎng)絡(luò)安全體系建立原則幾乎被每個電信和銀行業(yè)的企業(yè)所強(qiáng)調(diào)，并成為指導(dǎo)其安全管理體系建設(shè)的基本原則。三、需求工程20世紀(jì)80年代中期，形成了軟件工程的子領(lǐng)域——需求工程。需求工程是指應(yīng)用已證實有效的技術(shù)、方法進(jìn)行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標(biāo)系統(tǒng)的所有外部特征的一門學(xué)科。四、需求問題的代價在早期階段，軟件是無形的，除了一些文檔性的規(guī)格說明以外沒有什么具體有形的東西，而且比較容易修改。但隨著時間的推移，軟件產(chǎn)品越來越詳細(xì)（在設(shè)計階段），越來越具體（在編碼階段），越來越固定（當(dāng)代碼逐漸接近最終的方案時）。在早期可以輕易改變的東西，越到后期就越難得多。很多人不理解這些前期準(zhǔn)備的重要性，其實我們可以把軟件過程比作食物鏈。其中程序員是軟件食物鏈的最后一環(huán)。架構(gòu)師吃掉需求，設(shè)計師吃掉架構(gòu)，而程序員則消化設(shè)計。在健康的生態(tài)環(huán)境中，海鷗吃新鮮的鮭魚。這對海鷗是營養(yǎng)豐富的大餐，因為鮭魚吃的是新鮮的青魚，而青魚吃的是新鮮的水蝽。這是一條健康的食物鏈。在軟件開發(fā)中如果食物鏈的每一級都是健康的食物，那么最終由程序員編寫出的代碼也是健康的。而在受污染的環(huán)境中，水蝽在核廢料中游泳，青魚被聚氯聯(lián)二苯污染，而吃青魚的鮭魚又在泄漏的原油中游蕩。海鷗，就成為最不幸的了，因此它吃下去的不僅僅是不健康的鮭魚體內(nèi)的原油，還有青魚體內(nèi)的聚氯聯(lián)二苯和水蝽體內(nèi)的核廢料。在軟件開發(fā)中，如果需求污染了，它就會污染架構(gòu)，而架構(gòu)就會污染編碼。這樣會導(dǎo)致程序員脾氣暴躁、營養(yǎng)失調(diào)；開發(fā)出的軟件具有放射性污染，而且周身都是缺陷。五、需求面臨的困難“石頭”問題：說客戶常常會交給她一些項目，她稱之為“給我一塊石頭”?？墒钱?dāng)你把石頭交給客戶時，他會看一會“石頭”，然后說：“是的，但是……，實際上我想要的是一塊小一點的藍(lán)色石頭?！倍?dāng)你交出一塊小一點的藍(lán)色石頭時，又會引發(fā)“一塊圓的小一點的藍(lán)色石頭”的要求。最終的結(jié)果可能是，客戶一直都在想要一塊小一點的藍(lán)色大理石—或者他也許根本不能確定他到底要什么，而不是一塊小小的藍(lán)色大理石—甚至是貓眼大小的藍(lán)色大理石就已經(jīng)足夠了。而他會在你交出第一塊（大的）石頭和第三塊（藍(lán)色的?。┦又g不斷改變對需求的想法。開發(fā)人員在與客戶會談時總會提這樣的問題：“你想要它做什么？”當(dāng)開發(fā)人員按照客戶預(yù)先的需求經(jīng)過艱苦努力終于交出一塊石頭卻得不到客戶的肯定時，總是感到非常沮喪；而客戶也同樣沮喪，因為即使他可能也發(fā)現(xiàn)很難說清自己真正的要求，他還是覺得自己已經(jīng)講得很明白，只是開發(fā)人員沒理解罷了！解決需求問題的手段和方法：A、分離穩(wěn)定和不穩(wěn)定B、先定架構(gòu)再進(jìn)行子系統(tǒng)的開發(fā)六、什么是用例用例：一種被廣泛使用的用于發(fā)現(xiàn)和記錄需求的機(jī)制。用例就是如何使用系統(tǒng)來達(dá)到目標(biāo)的一組情節(jié)。用例不應(yīng)該被設(shè)計得過于復(fù)雜，寫到夠用的詳細(xì)程度即可。一個用例就是描述參與者使用系統(tǒng)來達(dá)成目標(biāo)的時候一組相關(guān)的成功場景和失敗場景的集合。用例是文本文檔而不是圖表，用例建模的主要工作是寫文本而不是畫圖。用例的層次性使得用例對需求變更的適應(yīng)性很強(qiáng)。再次強(qiáng)調(diào)：用例是文本形式的情節(jié)描述，用以說明某參與者使用系統(tǒng)以實現(xiàn)某些目標(biāo)。初學(xué)者的常見錯誤就是注重于次要的UML用例圖，而非重要的用例文本。七、需求調(diào)研需求獲取的主要任務(wù)是和用戶方的領(lǐng)導(dǎo)層、業(yè)務(wù)層人員的訪談式溝通，目的是從宏觀上把握用戶的具體需求方向和趨勢，了解現(xiàn)有的組織架構(gòu)、業(yè)務(wù)流程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運行系統(tǒng)等具體情況和客觀的信息，以建立起良好的溝通渠道和方式。需求調(diào)研的方式(1)訪談和會議：需要注意，每一次交流一定要有記錄，對于交流的結(jié)果還可以進(jìn)行分類，便于后續(xù)的分析活動。例如，可以將需求細(xì)分為功能需求、非功能需求、環(huán)境限制、設(shè)計約束等類型。(2)市場調(diào)查(3)訪問用戶和用戶領(lǐng)域的專家(4)考察現(xiàn)場，跟蹤現(xiàn)場業(yè)務(wù)流程(5)開發(fā)人員和用戶共同組成聯(lián)合小組“老太太哲學(xué)”來源于李瑞環(huán)在天津當(dāng)市長時候的一個故事，說是，人大代表、政協(xié)委員和各界群眾座談，有一次，一個老太太問：她家的煤氣灶為什么總是點不著火？主管領(lǐng)導(dǎo)通過講道理、擺數(shù)字的方式，給老太太解釋，此時李瑞環(huán)說，你不用講太多道理，老太太只要求煤氣能一點就著。

許多媒體用“老百姓哲學(xué)”來對這個故事進(jìn)行解讀，說是政府要替老百姓辦實事。我這里從軟件工程的角度解讀一下。

老太太提問題的目的，顯然不是為了學(xué)習(xí)煤氣灶點火的機(jī)理，實際上傳遞了一個信息，天津的煤氣有問題，點不著。政府官員，假定不是推卸責(zé)任的話，顯然沒有理解老太太的真實意圖。官員的回答，也沒有用老太太能理解的方式進(jìn)行，他應(yīng)該直接告訴老太太怎么做，即便要推卸責(zé)任，用哪些情況做不到來代替說理也要好些。

軟件工程中，需求獲取是項目的重要步驟，用戶的問題域是項目執(zhí)行者要解決的目標(biāo)域，不過，這兩個域卻存在不同的表達(dá)方式，用戶總是從使用的角度來理解問題和提出問題，項目人員總是從設(shè)計的角度來理解問題和解決問題。

客戶的問題并不能直接變成項目執(zhí)行的目標(biāo)，因為客戶的問題使用業(yè)務(wù)術(shù)語來描述，項目卻需要軟件術(shù)語來執(zhí)行。舉例子說，數(shù)學(xué)工作者的問題是用數(shù)學(xué)公式來描述的，他并不知道軟件怎樣設(shè)計才能完成他的任務(wù)，如果軟件設(shè)計者只熟悉軟件領(lǐng)域，數(shù)學(xué)公式他也無法看懂，就談不上完成任務(wù)。

需求問題實際上還要復(fù)雜，客戶受限于知識水平和經(jīng)驗，常常無法準(zhǔn)確地表達(dá)要求，作為問題提出者，他們的描述是零散的、模糊的、錯誤的甚至是自相矛盾的，而這樣的目標(biāo)無法完成，因此，需求獲取者從有干擾的信息中挖掘、過濾、還原用戶的真實需求，是重要的任務(wù)。

要準(zhǔn)確獲取需求，需要貼近客戶，用他們能夠理解的方式溝通，說他們能夠聽得懂的話，而不是雞對鴨講，各說各話。對于技術(shù)人員之間，則要用技術(shù)人員的語言，便于意思的精確表達(dá)，減少交流誤差。表現(xiàn)在軟件工程中，就是對不同的人建立不同的模型。不同的模型分別以不同的側(cè)面來展現(xiàn)問題本身。

如果你是技術(shù)人員，你不能很好的和客戶溝通，或者你的老板總是不理解你每天的辛苦，老太太哲學(xué)應(yīng)該能給你一些提示。調(diào)研中存在的問題小型項目：投入幾萬到三四十萬的項目，忽略合同或協(xié)議的簽署，而僅僅只有一個表面的意向。最終導(dǎo)致在開發(fā)過程中，用戶不斷提出各種各樣的問題和要求，以至于需求工作無法正常進(jìn)行。大型項目：幾百萬或者幾千萬的項目。軟件開發(fā)商急切的想得到這個項目，于是就逼迫開發(fā)人員盡快投入開發(fā)，必須不惜一切代價去拿下它。這樣也就直接造成在還沒有簽訂合同和正式協(xié)議之前，開發(fā)人員就不得不進(jìn)入用戶的工作區(qū)進(jìn)行需求調(diào)研。此時，如果商務(wù)最終沒有能談下來，就使得開發(fā)人員的工作付之東流。用戶日漸成熟：用戶會要求軟件廠商先拿出相應(yīng)的產(chǎn)品或者軟件，然后才會考慮和軟件廠商簽訂進(jìn)一步合同。用戶甚至希望，先試用軟件（其實是使用軟件），然后簽合同。合同一旦簽完，軟件就可全部交付！而國內(nèi)軟件企業(yè)很難做到（產(chǎn)品化的軟件太少，造成經(jīng)常發(fā)生用戶現(xiàn)場定制開發(fā)工作的情況存在。）用戶過于繁忙：用戶有很多借口說忙。當(dāng)然，在需求調(diào)研人員以諸如請客吃飯為借口搞好關(guān)系的時候，他們大多數(shù)還是愿意來的。因此需求調(diào)研人員就需要考慮如何協(xié)調(diào)這其中的關(guān)系，來保證需求調(diào)研的順利完成。這時需要掌握好一個原則是：不能逼迫用戶（如催促等行為），不要以與項目相關(guān)的任何理由來逼迫用戶配合需求調(diào)研工作。不同的軟件不同的結(jié)果：對于可以讓客戶直接見到利益的軟件系統(tǒng)，用戶愿意購買，也比較愿意付款，而且也比較愿意配合您的工作。但是這樣的項目大部分都隸屬于增值業(yè)務(wù)范圍之內(nèi)。還有相當(dāng)數(shù)量的軟件是不可能讓客戶直接體會到收益的；此時應(yīng)該注意將隱藏在軟件產(chǎn)品后面的收益盡量呈獻(xiàn)出來，讓客戶充分體會到。高層的關(guān)注：高層領(lǐng)導(dǎo)非常關(guān)注的大型項目，一般比較容易推進(jìn)。例如電信行業(yè)的計費、網(wǎng)管系統(tǒng)，稅務(wù)的稅收、繳費系統(tǒng)、電力的生產(chǎn)、調(diào)度、計費、電檢系統(tǒng)等。但是，也要注意，不要因為引起了高層的關(guān)注就對下面的人不再關(guān)注，更不能因此而引起具體辦事人員的反感，否則將使項目的進(jìn)展面臨異乎尋常的壓力。和用戶交流的技巧交流中的心態(tài)定位：首先，開發(fā)人員一定要讓用戶意識到：開發(fā)人員是為他們工作的！開發(fā)人員的工作不會造成他們被裁掉，只是用來簡化他們的工作，減輕他們的工作負(fù)擔(dān)，讓他們可以更舒服、更輕松地工作——即使，最終的結(jié)果可能完全相反，也要如此做。我們要為用戶考慮：應(yīng)該站在用戶的立場上進(jìn)行考慮。采用適當(dāng)?shù)慕涣髡Z言：盡量采用用戶行業(yè)內(nèi)的語言或者用戶可以理解的語言和方式。使用流程圖最常用的方式是：用戶邊描述，需求人員邊繪圖，然后給用戶看圖，讓用戶根據(jù)圖來指出問題，然后，再修改，再看，如此反復(fù)，直到用戶滿意為止。表格：流程圖可以描述工作流程，而表格可以描述工作的結(jié)果，或者階段性成果。圖形：如設(shè)備部署圖、網(wǎng)絡(luò)結(jié)構(gòu)圖、資源分布圖等。文字：使用文字是必須的，但是文字越少越好！描述性文字一定要精練、短小，切忌長篇大論。八、需求建模問題的提出：在系統(tǒng)尚未存在時，怎樣描述用戶需要一個什么樣的系統(tǒng)？如何規(guī)范的定義用戶需求？考慮問題的思路：把系統(tǒng)看作一個黑箱，看它對外部的客觀世界發(fā)揮什么作用，描述它外部可見的行為。注意：需求是技術(shù)無關(guān)的。在需求階段討論技術(shù)是沒有任何意義的。那只會讓你的注意力分散。需求分析的基本策略是采用腦力風(fēng)暴、專家評審、焦點會議組等方式進(jìn)行具體的流程細(xì)化、數(shù)據(jù)項的確認(rèn)，必要時可以提供原型系統(tǒng)和明確的業(yè)務(wù)流程報告、數(shù)據(jù)項表，并能清晰地向用戶描述系統(tǒng)的業(yè)務(wù)流設(shè)計目標(biāo)。用戶方可以通過審查業(yè)務(wù)流程報告、數(shù)據(jù)項表以及操作開發(fā)方提供的原型系統(tǒng)，來提出反饋意見，并對可接受的報告、文檔簽字確認(rèn)。需求建模的步驟：1、識別執(zhí)行者2、識別用例3、詳述業(yè)務(wù)用例4、對用例進(jìn)行排序和分包第一步：識別執(zhí)行者執(zhí)行者：在系統(tǒng)之外，透過系統(tǒng)邊界與系統(tǒng)進(jìn)行有意義交互的任何人或外部系統(tǒng)。三類參與者：1、主要參與者：具有用戶目標(biāo)，并通過使用該系統(tǒng)的服務(wù)完成。為何確定主要參與者？發(fā)現(xiàn)驅(qū)動用例的用戶目標(biāo)。2、協(xié)助參與者：為系統(tǒng)提供服務(wù)（例如，信息服務(wù)）。自動付費授權(quán)服務(wù)即是一例。協(xié)助參與者通常是計算機(jī)系統(tǒng)，但也可以是組織和人。為何確定協(xié)助參與者？為了明確外部接口和協(xié)議。3、幕后參與者：在用例行為中具有影響或利益，但不是主要或協(xié)助參與者。例如，政府稅收機(jī)構(gòu)。為何確定幕后參與者？這是為了確保確定并滿足所有必要的重要事物。如果不明確地對幕后參與者進(jìn)行命名，則有時很容易忽略其影響或利益。執(zhí)行者要點：系統(tǒng)外—必須和它交互系統(tǒng)邊界--責(zé)任邊界，非物理邊界系統(tǒng)邊界--直接與系統(tǒng)交互有意義交互--屬于目標(biāo)系統(tǒng)的責(zé)任任何事物--人、外系統(tǒng)、外部因素、時間與外部系統(tǒng)交互的幾種情況：1、一直與系統(tǒng)進(jìn)行交互的其他系統(tǒng)或設(shè)備。2、發(fā)起交互的其他系統(tǒng)或設(shè)備。3、從交互中取值的其他系統(tǒng)或設(shè)備。注意：用例圖的執(zhí)行者描述了可以由某些實體扮演的一種角色，不表示一個特定個體。一個執(zhí)行者和一個用例之間存在通信關(guān)系并不意味著扮演這個角色的實體必須執(zhí)行某個任務(wù)，它僅表示可能執(zhí)行這個任務(wù)，這取決于具體情況。第二步：識別用例用例實例是在系統(tǒng)中執(zhí)行的一系列動作，這些動作將生成特定執(zhí)行者可見的價值結(jié)果。一個用例定義一組用例實例。用例的三種常用形式：1、摘要——簡潔的一段式概要，通常用于主成功場景。何時使用？在早期需求分析過程中，為快速了解主題和范圍。可能只需要幾分鐘進(jìn)行編寫。2、非正式——非正式的段落格式。用幾個段落覆蓋不同場景。何時使用？同上。3、詳述——詳細(xì)編寫所有步驟及各種變化，同時具有補充部分，如前置條件和成功保證。何時使用？確定并以摘要形式編寫了大量用例后，在第一次需求討論會中，詳細(xì)地編寫其中少量（10％）的具有重要架構(gòu)意義和高價值的用例。識別用例的要點：價值結(jié)果à有意義的目標(biāo)執(zhí)行者可見à業(yè)務(wù)語言執(zhí)行者可見à用戶觀點一組用例實例à用例的粒度用例的粒度討論：警惕CRUD泛濫！Create,Read,update,delete用有色眼鏡看，所有業(yè)務(wù)最終都會成為CRUD多問：為什么要CRUD？光CRUD能為actor提供價值嗎？如果CRUD不涉及復(fù)雜的交互，一個用例“管理××”即可不管是C、R、U、D，都是為了完成“管理”的目標(biāo)甚至很多種基本數(shù)據(jù)的管理都可以用一個用例表示討論：登陸怎么處理方案二：“登陸”用例僅描述登陸的信息，會員執(zhí)行其他功能時都要先登陸，其缺點為，對會員要進(jìn)行多次驗證。方案三：注意在“購物”和“修改會員資料”用例的前置條件中寫明登陸成功條件。用例的關(guān)系：擴(kuò)展關(guān)系：尋找用例中的特殊場景：用例中的特殊場景點，（例如，購物，包括支付卡，現(xiàn)金，優(yōu)惠卷等），（例如，定價，包括打折的業(yè)務(wù)規(guī)則）。包含關(guān)系:某些步驟在多個用例重復(fù)出現(xiàn)，且單獨形成價值，即用例之間的公共功能。已經(jīng)有現(xiàn)成的公共用例存在，只需拿來使用即可。用例的步驟較多時，可以用Include簡化（慎用）。泛化關(guān)系：用例之間的泛化：一個任務(wù)與該任務(wù)的一個特殊版本之間的關(guān)系。例子：在買票系統(tǒng)中，個人購買和團(tuán)體購買都是買票的特例。采用關(guān)系不同，文檔結(jié)構(gòu)不同（如果改成extend，則表示識別用戶用例中的另外一條路徑）討論：泛化與擴(kuò)展的區(qū)別如果打算描述一個根據(jù)“運行時”條件有可能在某一時刻增加的附加行為，則可以使用擴(kuò)展。如果希望標(biāo)記整個任務(wù)的一個特定版本，就應(yīng)該用泛化。第三步：編寫用例文檔用例文檔模板：前置條件和后置條件：開始用例之前必須滿足的條件。注意：必須是系統(tǒng)能檢測的。用例成功結(jié)束后系統(tǒng)應(yīng)該具備的狀態(tài)。例如，前提條件可能是另一個用例已經(jīng)執(zhí)行，或者用戶具有運行當(dāng)前用例的權(quán)限。用例圖并不顯示用例執(zhí)行的順序，但前提條件可以將這一方面的信息建檔。前置條件傳達(dá)的是編寫者認(rèn)為應(yīng)該引起讀者警惕的那些值得注意的假設(shè)。涉眾利益：回答了用例應(yīng)該包含什么？即用例應(yīng)該包含滿足了所有項目相關(guān)人員興趣的內(nèi)容。另外，在編寫用例其余部分之前就確定涉眾及其關(guān)注點，能夠讓我們更加清楚地了解詳細(xì)的系統(tǒng)職責(zé)?；韭窂剑汉诵牡暮诵模嚎蛻糇钕肟吹?、最關(guān)心的路徑各種補充約束的描述方法：非功能性需求：正確性：correctness，指系統(tǒng)規(guī)范、設(shè)計和實現(xiàn)方面的錯誤的稀少程度?？捎眯裕褐赣脩魧W(xué)習(xí)和使用一個系統(tǒng)的容易程度。集群是一種廉價且實用的高可用性解決方案。所謂集群指的是一系列節(jié)點的集合，這些節(jié)點具有相同的目的，并且互相連接。集群的優(yōu)點在于可以賦予服務(wù)容錯和負(fù)載均衡的能力。集群通過多個節(jié)點間的相互補充，可以在其中某個節(jié)點失效時持續(xù)的提供服務(wù)，從而提高服務(wù)的可用性；通過集群中各節(jié)點對負(fù)載的動態(tài)分擔(dān)，可以將負(fù)載比較均勻的分布到多個節(jié)點中，從而提高整體性能?？煽啃裕篟eliability，指在指定的必需條件下，一個系統(tǒng)完成所需功能的能力——應(yīng)該有很長的平均無故障時間。數(shù)據(jù)庫服務(wù)器＋備份服務(wù)器各種設(shè)計約束：界面樣式：系統(tǒng)顯示訂單明細(xì)，應(yīng)采用附件××所示的屏幕格式報表：系統(tǒng)打印工資單，工資單的格式如附件××所示平臺：一般針對整個系統(tǒng)：由于公司目前大約有200臺PC在使用，還需要使用若干年，所以系統(tǒng)應(yīng)能在這些PC上運行（Pentium166，128MRAM）由于×公司的IT人員有Oracle專長，而且目前已有的其他應(yīng)用系統(tǒng)也使用Oracle數(shù)據(jù)庫，所以系統(tǒng)應(yīng)使用Oracle數(shù)據(jù)庫。接口：通過RS-232接口讀取?？偨Y(jié)：用例編寫準(zhǔn)則1、以無用戶界面約束的本質(zhì)風(fēng)格編寫用例。2、編寫簡潔的用例。3、編寫黑盒用例。（黑盒用例不對系統(tǒng)內(nèi)部工作、構(gòu)件或設(shè)計進(jìn)行描述。反之，它以通過職責(zé)來描述系統(tǒng)）4、采用參與者和參與者目標(biāo)的視點。第四步：對用例進(jìn)行排序和分包排序原則：以下情況的用例優(yōu)先級別最高a)對類圖有重要影響b)包含豐富的業(yè)務(wù)過程信息和線索c)有開發(fā)風(fēng)險、時間緊迫或功能復(fù)雜d)涉及到重要核心技術(shù)或新技術(shù)e)能直接產(chǎn)生經(jīng)濟(jì)效益或降低成本f)代表本系統(tǒng)的核心流程分包原則：按執(zhí)行者分包按主題分包按開發(fā)團(tuán)隊分包按發(fā)布情況分包補充、活動圖利用文本描述事件流是很有用的，但如果事件流的邏輯復(fù)雜且有許多其他事件流，則文本形式可能較難閱讀和理解。這時可以使用活動圖來描述事件流，它是事件流的另一種建模方式。在用例模型中，活動圖用來捕捉用例的活動，它著重描述操作以及用例實例或?qū)ο笾械幕顒??；顒訄D是一種描述工作流的方式，它用來描述采取何種動作、做什么（對象狀態(tài)改變）、何時發(fā)生（動作序列）以及在何處發(fā)生（泳道）?；顒訄D用于描述系統(tǒng)的工作流程和并發(fā)行為，活動圖可以看作狀態(tài)圖的特殊形式，活動圖中一個活動結(jié)束后將立即進(jìn)入下一個活動?？偨Y(jié)：用例實踐方法最理想：客戶寫用例－－理想即不現(xiàn)實最糟糕：客戶不參與，開發(fā)人員杜撰折衷：客戶提供素材，開發(fā)人員寫用例九、需求管理由于需求是正在構(gòu)建的系統(tǒng)必須符合的事務(wù)，而且符合某些需求決定了項目的成功或失敗，因此找出需求是什么，將它們記下來，進(jìn)行組織，并在發(fā)生變化時對它們進(jìn)行追蹤，這些活動都是有意義的。需求管理就是：一種獲取、組織并記錄系統(tǒng)需求的系統(tǒng)化方案，以及一個使客戶與項目團(tuán)隊對不斷變更的系統(tǒng)需求達(dá)成并保持一致的過程。需求管理的主要活動：需求確認(rèn)：開發(fā)方和客戶共同對需求文檔進(jìn)行評審，雙方對需求達(dá)成共識后做出書面承諾，使需求文檔具有商業(yè)合同效果。在設(shè)計開始之前驗證需求的正確性及其質(zhì)量，就能大大減少項目后期的返工現(xiàn)象。需求驗證務(wù)必確保需求符合完整性、正確性、靈活性、必要性、無二義性、一致性、可跟蹤性及可驗證性等。需求跟蹤：將系統(tǒng)設(shè)計、編程、測試等階段的工作成果與需求文檔進(jìn)行比較，建立與維護(hù)“需求文檔－設(shè)計文檔－代碼－測試用例”之間的一致性，確保產(chǎn)品依據(jù)需求文檔進(jìn)行開發(fā)。需求變更控制：依據(jù)“變更申請——審批——更改——重新確認(rèn)”的流程處理需求的變更，確保需求的變更不會失去控制而導(dǎo)致項目發(fā)生混亂。這是一句老話了：唯一不變的只有變化。你應(yīng)該將所有系統(tǒng)將可能發(fā)生的變化以及潛在需求記錄下來,以便將來能夠?qū)崿F(xiàn)通過在建模期間考慮這些假設(shè)的情況，你就有可能開發(fā)出足夠強(qiáng)壯且容易維護(hù)的軟件。設(shè)計強(qiáng)壯的軟件是你最基本的目標(biāo)。案例分析：某公司的需求變更控制流程

章節(jié)名稱面向?qū)ο蠓治鼋虒W(xué)目的掌握分析階段的主要活動掌握領(lǐng)域建模、系統(tǒng)順序圖、操作契約等的編寫方法教學(xué)重點與難點靜態(tài)模型的建模方法動態(tài)模型的建模方法教學(xué)內(nèi)容與過程設(shè)計教學(xué)內(nèi)容與過程設(shè)計一、概述OOA：概念層。幫助軟件工程人員和用戶組織目標(biāo)系統(tǒng)的知識。不考慮與實現(xiàn)有關(guān)的因素。是一種以從問題域詞匯中發(fā)現(xiàn)的類和對象的概念來考察需求的分析方法。OOD：OOD把注意的焦點從問題空間轉(zhuǎn)移到了解空間。針對系統(tǒng)的具體實現(xiàn)，對OOA階段建立的模型進(jìn)行調(diào)整與增補，并對人機(jī)界面、數(shù)據(jù)存儲和控制接口建模。OOP：實現(xiàn)層，把OOD模型變?yōu)槌绦?。即用面向?qū)ο笳Z言(如C++，Java等)實現(xiàn)設(shè)計。分析和設(shè)計可以概括為：做正確的事（分析）和正確地做事（設(shè)計）。面向?qū)ο蠓治龊驮O(shè)計：在OOA過程中，強(qiáng)調(diào)的是在問題領(lǐng)域內(nèi)發(fā)現(xiàn)和描述對象或概念。在OOD過程中，強(qiáng)調(diào)的是定義軟件對象和這些軟件對象如何協(xié)作來滿足需求。UP過程的描述：初始和細(xì)化初始階段是邁向細(xì)化階段的一小步。在該階段決定基本的可行性、風(fēng)險和范圍，對項目是否值得深入調(diào)查進(jìn)行決策。初始階段可能的活動和制品包括：（1）簡短的需求討論會。（2）大多數(shù)參與者、目標(biāo)和用例名稱。（3）大多數(shù)以摘要形式編寫的用例。以詳述形式編寫10％～20％的用例，以加深對范圍和復(fù)雜性的理解。（4）確定大多數(shù)具有影響和風(fēng)險的質(zhì)量需求。（5）編寫設(shè)想和補充性規(guī)格說明的第一個版本。（6）風(fēng)險列表。（7）技術(shù)上的概念驗證原型和其他調(diào)查，用以揭示特殊需求的技術(shù)可行性。（8）面向用戶界面的原型，用于確定對功能需求的設(shè)想。（9）對購買/構(gòu)建/復(fù)用構(gòu)件的建議，在細(xì)化階段進(jìn)行精化。（10）對候選的高層架構(gòu)和構(gòu)件給出建議。（11）第一次迭代的計劃。（12）候選的工具列表。細(xì)化：構(gòu)建核心架構(gòu)，解決高風(fēng)險元素，定義大部分需求，預(yù)計總體進(jìn)度和資源。在細(xì)化階段可能出現(xiàn)的一些關(guān)鍵思想和最佳實踐包括：（1）實行短時間定量、風(fēng)險驅(qū)動的迭代。（2）及早開始編程。（3）對架構(gòu)的核心和風(fēng)險部分進(jìn)行適應(yīng)性的設(shè)計、實現(xiàn)和測試。（4）盡早、頻繁、實際地測試。（5）基于來自測試、用戶、開發(fā)者的反饋進(jìn)行調(diào)整。（6）通過一系列討論會，詳細(xì)編寫大部分用例和其他需求，每個細(xì)化迭代舉行一次。面向?qū)ο蠓治龊驮O(shè)計的實質(zhì)是一種系統(tǒng)建模的技術(shù)，它不是從功能或算法上考慮整個系統(tǒng)，而是從系統(tǒng)的組成上進(jìn)行分解，利用類及對象作為軟件的基本構(gòu)造單元，以更接近人類思維的方式建立模型，從而使設(shè)計出的系統(tǒng)盡可能直接的描述現(xiàn)實世界，構(gòu)造出模塊化、可重用、易維護(hù)的軟件。動態(tài)模型：有助于設(shè)計邏輯、代碼行為或方法體。例如UML交互圖。動態(tài)模型傾向于創(chuàng)建更為有益、困難和重要的圖形。靜態(tài)模型：有助于設(shè)計包、類名、屬性和方法特征標(biāo)記（但不是方法體）的定義，例如UML類圖。敏捷建模采取了并行創(chuàng)建這兩種模型的方式。二、對象模型領(lǐng)域模型是概念類或者感興趣領(lǐng)域的現(xiàn)實對象的可視化表示。UML表示法中，用一組不定義操作的一組類圖來說明。領(lǐng)域模型是現(xiàn)實世界概念類的一種表示，不是軟件組件的一種表示。它不是描述軟件類的圖集，也不是有著職責(zé)的軟件對象。2.1創(chuàng)建領(lǐng)域模型的步驟：用概念類分類列表和名詞短語識別的方法找出當(dāng)前需求中的候選概念類。在領(lǐng)域模型中描述這些概念類。在概念類之間添加必要的關(guān)聯(lián)來記錄那些需要保存記憶的關(guān)系。添加用來實現(xiàn)需求的必要屬性。注意：概念類和屬性命名時使用問題域中的詞匯。一個領(lǐng)域模型可以將那些與當(dāng)前需求無關(guān)的概念類排除在問題域之外。領(lǐng)域模型應(yīng)當(dāng)排除不包含在當(dāng)前考慮下的問題域中的事物。2.2識別類及其屬性對象是對問題域中有意義的事物的抽象，它們既可能是物理實體，也可能是抽象概念。具體地說，大多數(shù)客觀事物可分為下述5類：(1)可感知的物理實體，例如，飛機(jī)、汽車、書、房屋等等。(2)人或組織的角色，例如，醫(yī)生、教師、雇主、雇員、計算機(jī)系、財務(wù)處等等。(3)應(yīng)該記憶的事件，例如，飛行、演出、訪問、交通事故等等。(4)兩個或多個對象的相互作用，通常具有交易或接觸的性質(zhì)，例如，購買、納稅、結(jié)婚等等。(5)需要說明的概念，例如，政策、保險政策、版權(quán)法等等。在分析所面臨的問題時，可以參照上列5類常見事物，找出在當(dāng)前問題域中的候選類與對象。另一種更簡單的分析方法，是所謂的非正式分析。這種分析方法以用自然語言書寫的需求陳述為依據(jù)，把陳述中的名詞作為類與對象的候選者，用形容詞作為確定屬性的線索，把動詞作為服務(wù)(操作)的候選者。當(dāng)然，用這種簡單方法確定的候選者是非常不準(zhǔn)確的，其中往往包含大量不正確的或不必要的事物，還必須經(jīng)過更進(jìn)一步的嚴(yán)格篩選。通常，非正式分析是更詳細(xì)、更精確的正式的面向?qū)ο蠓治龅囊粋€很好的開端。2.3審查類（1）冗余相同的類使用多于一個的名字。注意：近似的對象不一定完全相同，應(yīng)該確定是否值得建立不同的類。（2）系統(tǒng)邊界之外現(xiàn)實世界中存在許多對象，不能把它們都納入到系統(tǒng)中去，僅需要把與本問題密切相關(guān)的類與對象放進(jìn)目標(biāo)系統(tǒng)中。有些類在其他問題中可能很重要，但與當(dāng)前要解決的問題無關(guān)，同樣也應(yīng)該把它們刪掉。（3）操作指被系統(tǒng)或者在系統(tǒng)內(nèi)部完成的事件的名詞。應(yīng)該慎重考慮它們在本問題中的含義，以便正確地決定把它們作為類還是作為類中定義的操作。通過判斷一個事件或者操作的實例是否包含狀態(tài)、行為或者特征，如果沒有，則不應(yīng)該是類。（4）屬性一個名詞明顯表示一些不具有感興趣行為的簡單事情，它是另一個類的屬性。當(dāng)然，如果某個性質(zhì)具有很強(qiáng)的獨立性，則應(yīng)把它作為類而不是作為屬性。判斷是概念類或?qū)傩缘脑瓌t:如果我們不將概念類X看成是現(xiàn)實世界中的數(shù)字或者文本，X就可能是概念類而非屬性。（5）實現(xiàn)在分析階段不應(yīng)該過早地考慮怎樣實現(xiàn)目標(biāo)系統(tǒng)。因此，應(yīng)該去掉僅和實現(xiàn)有關(guān)的候選的類與對象。在設(shè)計和實現(xiàn)階段，這些類與對象可能是重要的，但在分析階段過早地考慮它們反而會分散我們的注意力。（6）描述概念類在下列情況下，添加概念類的規(guī)格說明或描述：當(dāng)需要商品或者服務(wù)的信息描述，獨立于那些商品或者服務(wù)當(dāng)前已存在的任何示例。由于與被刪除的事物之間存在不正確的關(guān)聯(lián)信息，刪除它們所描述的事物實例會導(dǎo)致仍需維護(hù)信息的丟失。能夠減少冗余或者重復(fù)的信息。2.4屬性審查屬性對問題域的基本結(jié)構(gòu)影響很小。隨著時間的推移，問題域中的類始終保持穩(wěn)定，屬性卻可能改變了，相應(yīng)地，類中方法的復(fù)雜程度也將改變。（1）是否在系統(tǒng)責(zé)任之內(nèi)屬性不是越詳細(xì)越好，關(guān)鍵看是否是當(dāng)前系統(tǒng)感興趣的屬性。（2）屬性是否描述類對象的特征（3）屬性是否存在冗余：常見冗余如：出生年月－－年齡（4）是否有1對多的復(fù)雜屬性1:1－－可以在原類內(nèi)展開1:N－－獨立出去形成關(guān)聯(lián)如果一個會員只有一個聯(lián)系地址，可以在原類內(nèi)展開，如果包含多個聯(lián)系地址，則將聯(lián)系地址獨立出去形成關(guān)聯(lián)。（5）屬性是否對類的所有對象都有意義2.5識別類之間的泛化泛化：子類通過繼承擁有超類的特征關(guān)聯(lián)：對象通過組裝擁有其他對象的特征類A具有類B的全部屬性和操作，而且具有自己特有的某些屬性和操作。A稱為B的子類，B稱為A的超類。泛化舉例兩種方式建立泛化關(guān)系：自底向上：抽象出現(xiàn)有類的共同性質(zhì)泛化出父類，這個過程實質(zhì)上模擬了人類歸納思維過程。自頂向下：把現(xiàn)有類細(xì)化成更具體的子類，這模擬了人類的演繹思維過程。2.6審查泛化關(guān)系（1）問題域是否需要這樣的分類？（例：書——善本書）（2）系統(tǒng)責(zé)任是否需要這樣的分類?（例：職員——本市職員）（3）是否符合分類學(xué)的常識?（用“isa”去套）（4）是否構(gòu)成了繼承關(guān)系?（確實繼承了一些屬性或服務(wù)，如航標(biāo)船與一般的船）2.7識別類之間的關(guān)聯(lián)類A與類B關(guān)聯(lián)，如果類A在物理上或邏輯上是B的一部分；類A的對象向類B的對象發(fā)送一個消息；類A的對象建立類B的對象；類A的對象包含一個屬性，屬性的取值是類B的對象或者類B的對象集合；對象之間的靜態(tài)聯(lián)系是指，最終可通過對象屬性來表示的一個對象對另一個對象的依賴關(guān)系。對象之間的動態(tài)聯(lián)系是指，對象之間在行為（服務(wù)）上的依賴關(guān)系。在一個領(lǐng)域模型中需要考慮下面的關(guān)聯(lián)：（1）那些需要將概念之間的關(guān)系信息保持一段時間的關(guān)聯(lián)（“需要知道”型關(guān)聯(lián)）。（2）從通用關(guān)聯(lián)列表中派生出的關(guān)聯(lián)。通用關(guān)聯(lián)列表A在物理上是B的一部分A在邏輯上是B的一部分A在物理上包含在B中/依賴于BA在邏輯上包含在B中A是對B的描述A是交易或報表B中的一項A為B所知/為B所記錄/錄入B中/為B所捕獲A是B的一個組織子單元A使用或管理BA與B通信A與一個交易B有關(guān)A是一個與另一個交易B有關(guān)的事務(wù)A與B相鄰A為B所擁有A是一個與B有關(guān)的事件關(guān)聯(lián)的指導(dǎo)原則：（1）將注意力集中在那些需要將概念之間的關(guān)系信息保持一段時間的關(guān)聯(lián)。（2）識別概念類比識別關(guān)聯(lián)更重要（3）太多的關(guān)聯(lián)不僅不能有效地表示領(lǐng)域模型，反而會使領(lǐng)域模型變得混亂。有時，（4）發(fā)現(xiàn)某些關(guān)聯(lián)很費時，但帶來的好處并不大。（5）避免顯示冗余或?qū)С龅年P(guān)聯(lián)。聚合vs.組合識別聚合（組合）結(jié)構(gòu)的意義：在動態(tài)建模時幫助進(jìn)行職責(zé)分配。舉例：發(fā)給訂單的修改訂單項消息，在內(nèi)部是通過調(diào)用訂單項的修改消息完成的。比較：關(guān)聯(lián)的幾種表現(xiàn)形式2.8識別聚合（組合）思路（1）物理上的整體事物和它的組成部分（2）組織機(jī)構(gòu)和它的下級組織（3）團(tuán)隊（組織）和成員（4）空間上的包容（5）抽象事物的整體和部分2.9識別連接（1）將注意力集中在那些需要將概念之間的關(guān)系信息保持一段時間的關(guān)聯(lián)。（2）識別實體類比識別關(guān)聯(lián)更重要。（3）太多的關(guān)聯(lián)不僅不能有效地表示對象模型，反而會使對象模型變得混亂。（4）避免顯示冗余或?qū)С龅年P(guān)聯(lián)。課堂作業(yè)：根據(jù)前面的類圖，識別類之間的關(guān)聯(lián)（聚合、組合、連接），要說明多重性，如果關(guān)聯(lián)的形式是“連接”，還要注明關(guān)聯(lián)名。三、動態(tài)模型幾乎解決任何一個問題，都需要從客觀世界實體間的相互關(guān)系中抽象出有價值的對象模型；當(dāng)問題涉及交互作用和時序（如用戶界面或過程控制等），動態(tài)模型