教師備課教案本

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

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

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

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

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

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

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

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

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

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