軟件工程課后作業(yè)

1、第一章1.1答：軟件危機(jī)是指在計(jì)算機(jī)軟件開發(fā)、使用與維護(hù)過程中遇到的一系列嚴(yán)重問題和難題。它包括兩方面：如何開發(fā)軟件，已滿足對軟件日益增長的需求；如何維護(hù)數(shù)量不斷增長的已有軟件。軟件危機(jī)的典型表現(xiàn)：(1) 對軟件開發(fā)成本和進(jìn)度的估計(jì)常常很不準(zhǔn)確。常常出現(xiàn)實(shí)際成本比估算成本高出一個數(shù)量級、實(shí)際進(jìn)度比計(jì)劃進(jìn)度拖延幾個月甚至幾年的現(xiàn)象。而為了趕進(jìn)度和節(jié)約成本所采取的一些權(quán)宜之計(jì)又往往損害了軟件產(chǎn)品的質(zhì)量。這些都降低了開發(fā)商的信譽(yù)，引起用戶不滿。(2) 用戶對已完成的軟件不滿意的現(xiàn)象時有發(fā)生。(3) 軟件產(chǎn)品的質(zhì)量往往是靠不住的。(4) 軟件常常是不可維護(hù)的。(5) 軟件通常沒有適當(dāng)?shù)奈臋n資料。文檔資

2、料不全或不合格，必將給軟件開發(fā)和維護(hù)工作帶來許多難以想象的困難和難以解決的問題。(6) 軟件成本、軟件維護(hù)費(fèi)在計(jì)算機(jī)系統(tǒng)總成本中所占比例逐年上升。(7) 開發(fā)生產(chǎn)率提高的速度遠(yuǎn)跟不上計(jì)算機(jī)應(yīng)用普及的需求。軟件危機(jī)出現(xiàn)的原因：(1) 來自軟件自身的特點(diǎn)：是邏輯部件，缺乏可見性；規(guī)模龐大、復(fù)雜，修改、維護(hù)困難。(2) 軟件開發(fā)與維護(hù)的方法不當(dāng)：忽視需求分析；認(rèn)為軟件開發(fā)等于程序編寫；輕視軟件維護(hù)。(3) 供求矛盾將是一個永恒的主題：面對日益增長的軟件需求，人們顯得力不從心。1.2答：在軟件開發(fā)的不同階段進(jìn)行修改付出的代價(jià)是很不相同的，在早期引入變動，涉及的面較少，因而代價(jià)也比較低；在開發(fā)的中期，軟

3、件配置的許多成分已經(jīng)完成，引入一個變動要對所有已完成的配置成分都做相應(yīng)的修改，不僅工作量大，而且邏輯上也更復(fù)雜，因此付出的代價(jià)劇增；在軟件“已經(jīng)完成”是在引入變動，當(dāng)然付出的代價(jià)更高。一個故障是代碼錯誤造成的，有時這種錯誤是不可避免的，但要修改的成本是很小的，因?yàn)檫@不是整體構(gòu)架的錯誤。1.3答：1993年IEEE的定義：軟件工程是： 把系統(tǒng)的、規(guī)范的、可度量的途徑應(yīng)用于軟件開發(fā)、運(yùn)行和維護(hù)過程，也就是把工程應(yīng)用于軟件； 研究中提到的途徑。軟件工程的本質(zhì)特征：(1) 軟件工程關(guān)注于大型程序(軟件系統(tǒng))的構(gòu)造(2) 軟件工程的中心課題是分解問題，控制復(fù)雜性(3) 軟件是經(jīng)常變化的，開發(fā)過程中必須考

4、慮軟件將來可能的變化(4) 開發(fā)軟件的效率非常重要，因此，軟件工程的一個重要課題就是，尋求開發(fā)與維護(hù)軟件的更好更有效的方法和工具(5) 和諧地合作是開發(fā)軟件的關(guān)鍵(6) 軟件必須有效地支持它的用戶在軟件工程領(lǐng)域中是由具有一種文化背景的人替具有另一種文化背景的人(完成一些工作)消除軟件危機(jī)的途徑：(1) 對計(jì)算機(jī)軟件有一個正確的認(rèn)識(軟件程序）(2) 必須充分認(rèn)識到軟件開發(fā)不是某種個體勞動的神秘技巧，而應(yīng)該是一種組織良好、管理嚴(yán)密、各類人員協(xié)同配合、共同完成的工程項(xiàng)目(3) 推廣使用在實(shí)踐中總結(jié)出來的開發(fā)軟件的成功技術(shù)和方法(4) 開發(fā)和使用更好的軟件工具1.4答：1.傳統(tǒng)方法學(xué)：也稱為生命周期

5、方法學(xué)或結(jié)構(gòu)化范型。優(yōu)點(diǎn)：把軟件生命周期劃分成基干個階段，每個階段的任務(wù)相對獨(dú)立，而且比較簡單，便于不同人員分工協(xié)作，從而降低了整個軟件開發(fā)過程的困難程度。缺點(diǎn)：當(dāng)軟件規(guī)模龐大時，或者對軟件的需求是模糊的或會承受時間而變化的時候，開發(fā)出的軟件往往不成功；而且維護(hù)起來仍然很困難。2.面向?qū)ο蠓椒▽W(xué)：優(yōu)點(diǎn)：降低了軟件產(chǎn)品的復(fù)雜性；提高了軟件的可理解性；簡化了軟件的開發(fā)和維護(hù)工作；促進(jìn)了軟件重用。1.5答：(1) 存儲容量需求M=4080e0.28（1985-1960）=4474263（字）存儲器價(jià)格P=0.048*0.72（1985-1974）*4474263=5789美元(2) 需要工作量447

6、4263/200=22371（人/月）指令成本22371*4000=89484000美元(3) 需求估計(jì)M=4080e0.28（1995-1960）=73577679字存儲器價(jià)格0.003*32*0.72（1995-1974）*73577679=7127美元工作量73577679/600=122629(人/月）成本122629*6000=735776790美元1.6答：軟件過程是為了開發(fā)出高質(zhì)量的軟件產(chǎn)品所需完成的一系列任務(wù)的框架，它規(guī)定了完成各項(xiàng)任務(wù)的工作步驟。軟件工程方法學(xué)：通常把在軟件生命周期全過程中使用的一整套技術(shù)方法的集合稱為方法學(xué)，也稱范型。軟件過程是軟件工程方法學(xué)的3個重要組成部

7、分之一。1.7答：軟件生命周期模型是跨越整個生存期的系統(tǒng)開發(fā)、運(yùn)作和維護(hù)所實(shí)施的全部過程、活動和任務(wù)的結(jié)構(gòu)框架。瀑布模型:優(yōu)點(diǎn)：它提供了一個模板，這個模板使得分析、設(shè)計(jì)、編碼、測試和支持的方法可以在該模板下有一個共同的指導(dǎo)。雖然有不少缺陷但比在軟件開發(fā)中隨意的狀態(tài)要好得多。缺點(diǎn)：(1) 實(shí)際的項(xiàng)目大部分情況難以按照該模型給出的順序進(jìn)行，而且這種模型的迭代是間接的，這很容易由微小的變化而造成大的混亂。(2) 經(jīng)常情況下客戶難以表達(dá)真正的需求，而這種模型卻要求如此，這種模型是不歡迎具有二義性問題存在的。(3) 客戶要等到開發(fā)周期的晚期才能看到程序運(yùn)行的測試版本，而在這時發(fā)現(xiàn)大的錯誤時，可能引起客戶

8、的驚慌，而后果也可能是災(zāi)難性的。快速原型模型:優(yōu)點(diǎn)：使用戶能夠感受到實(shí)際的系統(tǒng)，使開發(fā)者能夠快速地構(gòu)造出系統(tǒng)的框架。缺點(diǎn)：產(chǎn)品的先天性不足，因?yàn)殚_發(fā)者常常需要做實(shí)現(xiàn)上的折中，可能采用不合適的操作系統(tǒng)或程序設(shè)計(jì)語言，以使原型能夠盡快工作。 增量模型:優(yōu)點(diǎn)：(1) 人員分配靈活，剛開始不用投入大量人力資源，當(dāng)核心產(chǎn)品很受歡迎時，可增加人力實(shí)現(xiàn)下一個增量。(2) 當(dāng)配備的人員不能在設(shè)定的期限內(nèi)完成產(chǎn)品時，它提供了一種先推出核心產(chǎn)品的途徑，這樣就可以先發(fā)布部分功能給客戶，對客戶起到鎮(zhèn)靜劑的作用。缺點(diǎn)：(1) 至始至終開發(fā)者和客戶糾纏在一起，直到完全版本出來。(2) 適合于軟件需求不明確、設(shè)計(jì)方案有一定

9、風(fēng)險(xiǎn)的軟件項(xiàng)目。該模型具有一定的市場。螺旋模型:優(yōu)點(diǎn)：對于大型系統(tǒng)及軟件的開發(fā)，這種模型是一個很好的方法。開發(fā)者和客戶能夠較好地對待和理解每一個演化級別上的風(fēng)險(xiǎn)。缺點(diǎn)：(1) 需要相當(dāng)?shù)娘L(fēng)險(xiǎn)分析評估的專門技術(shù)，且成功依賴于這種技術(shù)。(2) 很明顯一個大的沒有被發(fā)現(xiàn)的風(fēng)險(xiǎn)問題，將會導(dǎo)致問題的發(fā)生，可能導(dǎo)致演化的方法失去控制。(3) 這種模型相對比較新，應(yīng)用不廣泛，其功效需要進(jìn)一步的驗(yàn)證。該模型適合于大型軟件的開發(fā)1.8答：因?yàn)槭褂妹嫦驅(qū)ο蠓椒▽W(xué)開發(fā)軟件時，各個階段都使用統(tǒng)一的概念和表示符號，因此，整個開發(fā)過程都是吻合一致的，或者說是無縫連接的，這自然就很容易實(shí)現(xiàn)各個開發(fā)步驟的反復(fù)多次迭代，達(dá)到認(rèn)

10、識的逐步深化，而噴泉模型則很好的體現(xiàn)了面向?qū)ο筌浖_發(fā)過程迭代和無縫的特性。1.9答：優(yōu)點(diǎn):提高了團(tuán)隊(duì)生產(chǎn)力，在迭代的開發(fā)過程、需求管理、基于組建的體系結(jié)構(gòu)、可視化軟件建模、驗(yàn)證軟件質(zhì)量及控制軟件變更等方面、針對所有關(guān)鍵的開發(fā)活動為每個開發(fā)成員提供了必要的準(zhǔn)則、模版和工具指導(dǎo)，并確保全體成員共享相同的知識基礎(chǔ)。它建立了簡潔和清晰的過程結(jié)構(gòu)，為開發(fā)過程提供較大的通用性。缺點(diǎn)：RUP只是一個開發(fā)過程，并沒有涵蓋軟件過程的全部內(nèi)容，例如它缺少關(guān)于軟件運(yùn)行和支持等方面的內(nèi)容，此外，他沒有支持多項(xiàng)目的開發(fā)結(jié)構(gòu)，這在一定程度上降低了在開發(fā)組織內(nèi)大范圍實(shí)現(xiàn)重用的可能性。1.10答：大型的需求不斷變化的復(fù)雜軟

11、件系統(tǒng)項(xiàng)目1.11答：適用于商業(yè)競爭環(huán)境下對小型項(xiàng)目提出的有限資源和有限開發(fā)時間的約束1.12適用于商業(yè)環(huán)境下具有有限資源和有限開發(fā)時間約束的項(xiàng)目的軟件過程模式.第二章2.2答：如果是存款，儲戶填寫存款單，然后交給業(yè)務(wù)員鍵入系統(tǒng)，同時系統(tǒng)還要記錄存款人姓名、住址（或電話號碼）、身份證號碼、存款類型、存款日期、利率等信息，完成后由系統(tǒng)打印存款單給儲戶。如果是取款，儲戶填寫取款單，然后交給業(yè)務(wù)員，業(yè)務(wù)員把取款金額輸入系統(tǒng)并要求儲戶輸入密碼以確認(rèn)身份，核對密碼正確無誤后系統(tǒng)計(jì)算利息并印出利息清單給儲戶。為了滿足儲戶的需求，該系統(tǒng)需要迅速的對用戶的要求做出反饋，要對用戶輸入的信息作出最快的處理，所以就

12、需要很大的主存容量，以及強(qiáng)大的數(shù)據(jù)庫支持。由于是所面向的用戶是廣泛的儲蓄用戶群，所以需要系統(tǒng)強(qiáng)大的安全性能支持?？尚行匝芯糠椒l件、假定和限制建議開發(fā)軟件運(yùn)行的最短壽命：5年進(jìn)行系統(tǒng)方案選擇比較的期限：2個月經(jīng)費(fèi)來源和使用限制：定制銀行硬件、軟件、運(yùn)行環(huán)境和開發(fā)環(huán)境的條件和限制：銀行中心擁有大型機(jī)以及用來支持的數(shù)據(jù)庫，各個銀行網(wǎng)點(diǎn)都有安好的PC機(jī)，安裝有Windows2000及以上的操作系統(tǒng)。建議開發(fā)軟件投入使用的最遲時間：開發(fā)完成后試運(yùn)行1個月。可行性研究方法通過與銀行熟練業(yè)務(wù)員進(jìn)行深入討論，制定詳細(xì)用戶調(diào)查問卷，真正了解用戶以及銀行業(yè)務(wù)員的實(shí)際需求，根據(jù)業(yè)務(wù)員提供的信息以及問題定義再綜合調(diào)

13、查問卷中用戶提出的意見進(jìn)行改進(jìn)。最終確定項(xiàng)目需要解決的問題，并確定問題能不能被解決。決定可行性的主要因素1）項(xiàng)目開發(fā)成本2）所需設(shè)備置辦成本3）技術(shù)是否能滿足需求4）操作人員的熟練程度5）資源有效性對現(xiàn)有系統(tǒng)的分析1處理流程和數(shù)據(jù)流程系統(tǒng)流程圖存款流程圖：取款流程圖：數(shù)據(jù)流圖：2工作負(fù)荷當(dāng)前大多數(shù)銀行所使用的銀行儲蓄系統(tǒng)在辦理業(yè)務(wù)時手續(xù)繁瑣，人工業(yè)務(wù)操作過多，辦理一個客戶的業(yè)務(wù)就需耗費(fèi)較長的時間，其他客戶只有等待。這樣太浪費(fèi)時間，需要大量的業(yè)務(wù)員處理客戶業(yè)務(wù)。特別是在節(jié)假日人流高峰期，導(dǎo)致工作效率非常低，且出錯率高，以致客戶等待辦理手續(xù)過長感到不耐煩，降低了銀行效率。這也給銀行工作人員增加了非

14、常大的負(fù)擔(dān)和額外的工作負(fù)荷；同時業(yè)務(wù)員增多，銀行費(fèi)用支出多，給銀行公司的發(fā)展帶來嚴(yán)重的制約和壓力。3費(fèi)用支出運(yùn)行現(xiàn)有系統(tǒng)所需要的費(fèi)用支出包括：銀行業(yè)務(wù)員及其他工作人員的工資，系統(tǒng)維護(hù)所需資金，4人員需要大量的業(yè)務(wù)員、客服人員，系統(tǒng)維護(hù)人員以及其他工作人員。5設(shè)備現(xiàn)有系統(tǒng)所需要的設(shè)備有：打印機(jī)、PC機(jī)、電腦。6局限性工作效率底下，不能符合大量群眾的及時需求，給群眾的生活帶來不便。這是現(xiàn)有系統(tǒng)辦理業(yè)務(wù)的流程中出現(xiàn)的一個嚴(yán)重問題。為了解決這一問題，讓人們再辦理銀行業(yè)務(wù)更加方便快捷，我們急需開發(fā)一個更為高效的銀行計(jì)算機(jī)儲蓄系統(tǒng)，讓儲蓄業(yè)務(wù)不用再排隊(duì)。（1）當(dāng)前銀行使用的銀行儲蓄系統(tǒng)在辦理業(yè)務(wù)時僅僅靠手

15、工操作，人工業(yè)務(wù)占據(jù)了全部，所以要求銀行業(yè)務(wù)員辦理業(yè)務(wù)時細(xì)心耐心，對數(shù)字敏感，算術(shù)水平高。它嚴(yán)重影響了工作效率，且出錯率高，儲戶辦理事務(wù)時需要等待時間過長，需要大量的銀行業(yè)務(wù)員才能滿足日益增長的存取款要求。（2）用紙張記錄保存用戶存款記錄查找繁瑣，耗時久，不方便，且容易丟失。且人工記錄不能保證萬無一失，容易出現(xiàn)數(shù)據(jù)錄入錯誤。隨著用戶數(shù)的增多，這個缺陷會越發(fā)凸顯。（3）存款記錄保密性差，任何一個業(yè)務(wù)員都可以隨意更改查閱用戶數(shù)據(jù)，用戶的資料容易泄漏，帶來安全隱患。（4）業(yè)務(wù)員服務(wù)的時間有限，不能24小時辦理業(yè)務(wù)，沒有應(yīng)急處理，不能更好的解決群眾的需求。（5）所有客戶的業(yè)務(wù)都由業(yè)務(wù)員手工辦理，浪費(fèi)人

16、力資源。有的簡單的業(yè)務(wù)經(jīng)改進(jìn)可由機(jī)器完成，完全不用人工參與，這樣節(jié)約了人力成本，也提高效率。（6）對現(xiàn)有系統(tǒng)的改進(jìn)維護(hù)只能依靠增多業(yè)務(wù)員數(shù)量，增多銀行分行數(shù)目，提高業(yè)務(wù)員業(yè)務(wù)素質(zhì)來實(shí)現(xiàn)。增多業(yè)務(wù)員數(shù)量會導(dǎo)致銀行人員支出大大增多，同時需要多選址建設(shè)分行，或者擴(kuò)大分行規(guī)模，費(fèi)用代價(jià)巨大。業(yè)務(wù)員的業(yè)務(wù)素質(zhì)需要培養(yǎng)，不能短期無限看見成效，及培養(yǎng)新人員需要一定的時間，這又浪費(fèi)資金和人力資源。對現(xiàn)用系統(tǒng)的改進(jìn)型維護(hù)已經(jīng)不能解決儲戶越來越多、儲戶時間越來越長的問題。第三章3.3解:數(shù)據(jù)流圖 用ER圖描繪系統(tǒng)中的數(shù)據(jù)對象。3.4 用ER圖描繪系統(tǒng)中的數(shù)據(jù)對象。數(shù)據(jù)流圖3.5（1）實(shí)體-聯(lián)系圖（2）數(shù)據(jù)流圖（3

17、）HIPO圖第五章5.3蓄系統(tǒng)不能是兩個分開的子系統(tǒng)，是相同的前臺單個處理機(jī)票預(yù)訂系統(tǒng)可以是兩個子系統(tǒng)，預(yù)定和取票是不同的處理方式（后臺批量和前臺單個）5.4解：（1）數(shù)據(jù)流圖：分解后：（2）需求說明： 1.功能需求：可以輸入調(diào)資的標(biāo)準(zhǔn)，輸入教師檔案，經(jīng)調(diào)資給出新的教師檔案，需要存儲檔案 2性能需求：軟件的響應(yīng)時間應(yīng)小于0.5s，更新處理要快 3靈活需求：當(dāng)需求發(fā)生某些變化時，該軟件應(yīng)該能夠適應(yīng)這些變化 4故障處理要求：出現(xiàn)錯誤時，應(yīng)給予警告或提示 （3）（a）比較耗時，因?yàn)樗獧z索所有的檔案，（b）從速度上看比較快，但是（b）需要排序算法，比較復(fù)雜，（a）對于設(shè)計(jì)來講比較簡單 .（4）畫出的

18、數(shù)據(jù)流圖比較適合（A）的算法 第六章6.3解：流程圖： 盒圖： 6.7解(1)(2)6.8解：流程圖：環(huán)形復(fù)雜度：V(G)結(jié)點(diǎn)E弧數(shù)n1=17-11+1=7=判斷結(jié)點(diǎn) 1=6 17封閉的區(qū)域數(shù)邏輯有問題，當(dāng)Z0時，容易形成死循環(huán)；條件Y5包含條件Y=2。第七章7.2語句覆蓋的含義是，選擇足夠多的測試數(shù)據(jù)，使被測試程序中的每個語句至少執(zhí)行一次。第九章9.1答: OO=objects+classes+inheritance+communication with messages 也就是說，面向?qū)ο缶褪羌仁褂脤ο笥质褂妙惡屠^承等機(jī)制，而且對象之間僅能通過傳遞消息實(shí)現(xiàn)彼此通信。面向?qū)ο蠓椒▽W(xué)的優(yōu)點(diǎn)：1

19、、與人類習(xí)慣的思維方法一致；2、穩(wěn)定性好；3、可重用性好；4、較易開發(fā)大型軟件產(chǎn)品；5、可維護(hù)性好。9.2答:把客觀世界中的實(shí)體抽象為問題域中的對象。它與傳統(tǒng)數(shù)據(jù)相同的是，它們都是現(xiàn)實(shí)實(shí)體特在在計(jì)算機(jī)中的抽象表示:不同的是，對象是進(jìn)行處理的主體，而傳統(tǒng)數(shù)據(jù)是被動的接受外部指令對它進(jìn)行處理；對象對實(shí)體特征進(jìn)行了封裝，而傳統(tǒng)數(shù)據(jù)沒有封裝；對象比傳統(tǒng)數(shù)據(jù)更為接近自然實(shí)體。9.3類是對具有相同屬性和行為的一個或多個對象的描述。9.4廣義地說，繼承是指能夠直接獲得已有的性質(zhì)和特征，而不必重復(fù)定義它們。在面向?qū)ο蟮能浖夹g(shù)中，繼承是子類自動地共享基類中定義的數(shù)據(jù)和方法的機(jī)制。9.5答:所謂模型，就是為了理

20、解事物而對事物作出的一種抽象，是對事物的一種無歧義的書面描述。模型是一種思考工具，利用這種工具可以把知識規(guī)范地表示出來。其中，IT=105,MTTF1=0.4,T1=160,n1=100,MTTF2=2,T2=320,n2=300。 為了開發(fā)復(fù)雜的軟件系統(tǒng)，系統(tǒng)分析員應(yīng)該從不同角度抽象出目標(biāo)系統(tǒng)的特性，使用精確的表示方法構(gòu)造系統(tǒng)的模型，驗(yàn)證模型是否滿足用戶對目標(biāo)系統(tǒng)的需求，并在設(shè)計(jì)過程中逐漸把和實(shí)現(xiàn)有關(guān)的細(xì)節(jié)加進(jìn)模型中，直至最終用程序?qū)崿F(xiàn)模型。對于那些因過分復(fù)雜而不能直接理解的系統(tǒng)，特別需要建立模型，建模的目的主要是為了減少復(fù)雜性。9.6對象模型表示靜態(tài)的、結(jié)構(gòu)化的系統(tǒng)的“數(shù)據(jù)”性質(zhì)。它是對模

21、擬客觀世界實(shí)體的對象以及對象彼此間的關(guān)系的映射，描述了系統(tǒng)的靜態(tài)結(jié)構(gòu)。通常使用UML提供的類圖來建立對象模型。在UML中術(shù)語“類“的實(shí)際含義是，一個類及屬于該類的對象9.7動態(tài)模型表示瞬時的、行為化的系統(tǒng)的“控制”性質(zhì)，它規(guī)定了對象模型中的對象的合法變化序列。通常，用UML 提供的狀態(tài)圖來描繪對象的狀態(tài)、觸發(fā)狀態(tài)轉(zhuǎn)換的事件以及對象的行為(對事件的響應(yīng))。每個類的動態(tài)行為用一張狀態(tài)圖來描繪，各個類的狀態(tài)圖通過共享事件合并起來，從而構(gòu)成系統(tǒng)的動態(tài)模型。也就是說，動態(tài)模型是基于事件共享而互相關(guān)聯(lián)的一組狀態(tài)圖的集合。9.8功能模型表示變化的系統(tǒng)的“功能”性質(zhì)，它指明了系統(tǒng)應(yīng)該“做什么”，因此更直接地反

22、映了用戶對目標(biāo)系統(tǒng)的需求。功能模型由一組數(shù)據(jù)流圖組成。在面向?qū)ο蠓椒▽W(xué)中，數(shù)據(jù)流圖遠(yuǎn)不如在結(jié)構(gòu)分析，設(shè)計(jì)方法中那樣重要。簡單的處理(或用例)對應(yīng)于更基本的對象提供的服務(wù)。有時一個處理(或用例)對應(yīng)多個服務(wù)，也有一個服務(wù)對應(yīng)多個處理(或用例)的時候。(1)數(shù)據(jù)流圖中的數(shù)據(jù)存儲，以及數(shù)據(jù)的源點(diǎn)/終點(diǎn)，通常是對象模型中的對象。(2)數(shù)據(jù)流圖中的數(shù)據(jù)流，往往是對象模型中對象的屬性值，也可能是整個對象。(3)用例圖中的行為者，可能是對象模型中的對象。(4)功能模型中的處理(或用例)可能產(chǎn)生動態(tài)模型中的事件。(5)對象模型描述了數(shù)據(jù)流圖中的數(shù)據(jù)流、數(shù)據(jù)存儲以及數(shù)據(jù)源點(diǎn)/終點(diǎn)的結(jié)構(gòu)。9.99.10第十章10.11、對象模型：2、動態(tài)模型：3、功能模型10.4對象模型是三個模型中最關(guān)鍵的。它的作用是描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，包括構(gòu)成系統(tǒng)的類和對象、它們的屬性和操作以及它們之間的聯(lián)系。UML中類圖適用于建立對象模型，狀態(tài)圖適用于建立動態(tài)模型。每個類的動態(tài)行為用一張狀態(tài)圖來表示，各個類的狀態(tài)圖通過事件合并起來，構(gòu)成系統(tǒng)的動態(tài)模型。也就是說，動態(tài)模型是基于事件共享而相互關(guān)聯(lián)的一組狀態(tài)圖的集合。建立對象模型大體上按照下列順序進(jìn)行:尋找問題域內(nèi)的對象，識別出對