河北工業(yè)大學(xué)軟件工程課件

內(nèi)容軟件工程主要的研究內(nèi)容；軟件工程相關(guān)的幾個(gè)關(guān)鍵問題；職業(yè)與道德責(zé)任對軟件工程的重要意義。1軟件工程的研究內(nèi)容幾個(gè)與軟件工程相關(guān)的現(xiàn)象（1）：幾乎所有發(fā)達(dá)國家的經(jīng)濟(jì)發(fā)展在很大程度上都依賴軟件產(chǎn)業(yè)的發(fā)展。越來越多的系統(tǒng)由軟件來控制，軟件在生產(chǎn)生活中扮演著越來越重要的角色。在發(fā)達(dá)國家中軟件在GNP中占有相當(dāng)?shù)谋戎?。軟件工程要考慮專業(yè)軟件開發(fā)所需要的理論、方法和工具工程技術(shù)問題軟件工程的研究內(nèi)容幾個(gè)與軟件工程相關(guān)的現(xiàn)象（2）：在計(jì)算機(jī)系統(tǒng)中軟件成本通常占優(yōu)—一臺PC機(jī)中軟件成本早已超過硬件成本。在軟件生命周期中用于維護(hù)的軟件成本通常會大于開發(fā)成本對于生命周期很長的軟件系統(tǒng)，維護(hù)成本有時(shí)會達(dá)到開發(fā)成本的幾倍。軟件工程要考慮如何有效的在軟件開發(fā)中利用有限的成本資源工程管理的問題2軟件工程相關(guān)的關(guān)鍵問題什么是軟件?什么是軟件工程?什么是軟件過程?什么是軟件過程模型?什么是軟件生命周期?誰會參與軟件工程?什么是軟件工程方法?軟件工程相關(guān)的關(guān)鍵問題什么是CASE(Computer-AidedSoftwareEngineering)優(yōu)良軟件的屬性是什么?什么是軟件工程面臨的主要問題?2.1什么是軟件?軟件的發(fā)展早期階段（20世紀(jì)50年代初-60年代中期）

面向批處理、有限分布、自定義；第二階段（20世紀(jì)60年代中-70年代中期）

多用戶、實(shí)時(shí)、數(shù)據(jù)庫、軟件產(chǎn)品；第三階段（20世紀(jì)70年代中-80年代中后期）

分布式系統(tǒng)、嵌入“智能”、硬件成本降低；第四階段（20世紀(jì)80年代中-至今）

桌面系統(tǒng)、面向?qū)ο蠹夹g(shù)、專家系統(tǒng)、人工神經(jīng)網(wǎng)絡(luò)。

2.1什么是軟件?計(jì)算機(jī)程序和相關(guān)的文檔（如需求文檔、設(shè)計(jì)模型和用戶手冊等）。軟件包括：①能夠提供客戶所需功能與性能的計(jì)算機(jī)程序；②使程序能夠適當(dāng)?shù)牟僮餍畔⒌臄?shù)據(jù)結(jié)構(gòu)；③用以描述程序開發(fā)過程及使用的文檔。2.1什么是軟件?軟件產(chǎn)品可以為一個(gè)特定的用戶設(shè)計(jì)開發(fā)，也可以為某一類通用的市場設(shè)計(jì)開發(fā)。軟件產(chǎn)品可以分成：通用軟件（GenericSoftware）定制軟件（BespokeSoftware）一個(gè)新的軟件并不一定是全新開發(fā)，可以由現(xiàn)有軟件或可復(fù)用軟件成分配置形成。模糊軟件的特征軟件是邏輯的而不是物理的；軟件只有設(shè)計(jì)過程，不存在傳統(tǒng)意義的制造過程；軟件產(chǎn)品不存在“磨損”的問題；軟件開發(fā)必須依賴硬件與操作系統(tǒng)；大多數(shù)軟件是為定制全新開發(fā)的，而不是由現(xiàn)有組件裝配完成的。軟件危機(jī)軟件危機(jī)指的是軟件的發(fā)展過程中出現(xiàn)的一系列嚴(yán)重的問題，如開發(fā)效率低下、成本高、可維護(hù)性差。出現(xiàn)于20世紀(jì)60年代后期。例子：來自于IBMConsultancyGroup的數(shù)據(jù)：(Included24leadingcompanies)55%軟件項(xiàng)目成本超預(yù)算；68%的項(xiàng)目不能按進(jìn)度計(jì)劃完成；88%不得不進(jìn)行大量的返工。

是什么導(dǎo)致了軟件項(xiàng)目的失敗?Factors %1.不完全的需求描述 13.1%2.缺少用戶參與 12.4%3.資源的短缺 10.6%4.不現(xiàn)實(shí)的期望 9.9%5.行政支持的缺乏 9.3%6.不斷變化的需求 8.7%7.缺乏合理的規(guī)劃 8.1%8.過短的生命周期 7.5%9.缺乏科學(xué)的項(xiàng)目管理 6.2%10.技術(shù)缺陷 4.3%11.其它 9.9%Source:StandishGroup19952.2什么是軟件工程？軟件工程是涉及軟件生產(chǎn)各個(gè)方面的一門工程學(xué)科軟件工程涉及軟件生命周期的各個(gè)方面，從軟件需求的確定到軟件退役。軟件工程還涉及軟件開發(fā)中的人為因素，如團(tuán)隊(duì)組織；經(jīng)濟(jì)因素，如成本估算；法律因素，如版權(quán)保護(hù)。軟件工程：（1）將系統(tǒng)化的、規(guī)范的、可度量的方法應(yīng)用于軟件的開發(fā)、運(yùn)行和維護(hù)的過程，即將工程化應(yīng)用于軟件；（2）研究（1）中的方法.

——IEEE[IEE93]2.2

什么是軟件工程？2.2什么是軟件工程？軟件工程是一門旨在指導(dǎo)生產(chǎn)”無缺陷”軟件的學(xué)科，既指導(dǎo)如何生產(chǎn)能夠及時(shí)交付、成本不超預(yù)算并且滿足用戶需求的軟件產(chǎn)品。軟件工程人員應(yīng)該采用系統(tǒng)的、有組織的工作方法，并按照所要解決的問題、開發(fā)約束和可用資源來選擇適當(dāng)?shù)墓ぞ吲c技術(shù)。2.3什么是軟件過程？軟件過程是指開發(fā)或制作軟件產(chǎn)品的一系列活動及其成果.所有的軟件過程中都包括四個(gè)基本活動:描述（Specification）-系統(tǒng)應(yīng)該提供的功能及其開發(fā)約束；開發(fā)（Development）-軟件產(chǎn)品的生產(chǎn)過程；有效性驗(yàn)證（Validation）-檢驗(yàn)軟件產(chǎn)品是否滿足了客戶的需要；進(jìn)化（Evolution）-按照用戶的變更要求不斷的改進(jìn)軟件。2.4什么是軟件過程模型？軟件過程模型是從一個(gè)特定的角度對軟件過程的簡化描述。幾種軟件過程模型：工作流模型-sequenceofactivities;數(shù)據(jù)流模型-informationflow;角色/動作模型-whodoeswhat.通用的軟件過程模型： 瀑布模型;進(jìn)化式開發(fā)模型;基于組件的軟件工程（CBSE）。2.5什么是軟件生命周期？軟件生命周期是軟件過程的另一種形象描述，包括：(1)需求定義

Identifytheneedsoftheusersbyinterviewingthem.(2)分析與描述

Describewhatthesoftwaresystemshoulddotomeettherequirements.(3)設(shè)計(jì)

Describehowthesystemshould performtherequiredtasks.2.5什么是軟件生命周期？(4)實(shí)現(xiàn)

Programvariousmodulesofthesystem.(5)集成（測試）

Combinethemodulesandverifythatthewholesystemworkscorrectly.(6)維護(hù)

Maintaintheoperationofthesystem, removebugsastheyarediscovered.(7)退役

Migratetoanewsystem.相對成本軟件生命周期各階段的相對成本[Grady1994]Maintenanceissoexpensive—amajoraspectofsoftwaredevelopmentconsistsoftechniques,tools,andpracticesthatleadtoareductioninmaintenancecost2.6誰是軟件工程的參與者?2.7什么是軟件工程方法？軟件工程方法是軟件生命周期中使用的一整套技術(shù)方法的集合，包括系統(tǒng)模型描述、約束規(guī)則、設(shè)計(jì)建議和過程指南等組成元素。普遍采用的軟件過程方法：結(jié)構(gòu)化方法面向?qū)ο蠓椒?.8什么是CASE(Computer-AidedSoftwareEngineering)？CASE是一些用于支持軟件過程活動的自動化、半自動化的軟件系統(tǒng)CASE通常分為兩個(gè)層次：高層（高端）CASE，用于支持軟件過程早期的分析與設(shè)計(jì)，如報(bào)告生成器、符號編輯器；低層（低端）CASE，用于支持后期的實(shí)現(xiàn)與測試，如代碼生成器、調(diào)試器、測試用例生成器。2.9什么是優(yōu)良軟件的屬性？優(yōu)良的軟件應(yīng)能交付相應(yīng)的功能與性能，而且應(yīng)具有良好的可維護(hù)性、可依賴性、有效性和可用性：可維護(hù)性（Maintainability）可依賴性（Dependability）有效性（Efficiency）可接受性（Acceptability）2.10什么是軟件工程面臨的主要問題21世紀(jì)軟件工程面臨三大挑戰(zhàn)：異構(gòu)：如何使軟件在異構(gòu)的平臺與執(zhí)行環(huán)境下構(gòu)建與移植；交付：如何快速有效的交付軟件產(chǎn)品；信任：如何提高軟件的可信任程度。

——IanSommerville3職業(yè)與道德責(zé)任軟件工程所涉及的不僅僅是技術(shù)應(yīng)用，還包括許多職業(yè)與道德責(zé)任。軟件工程師必須堅(jiān)持正直誠實(shí)的行為準(zhǔn)則。道德行為不僅僅是通過遵守法律來約束。職業(yè)與道德責(zé)任保密工作能力知識產(chǎn)權(quán)計(jì)算機(jī)濫用要點(diǎn)軟件工程是一門工程學(xué)科，涉及軟件生產(chǎn)的各個(gè)方面.軟件產(chǎn)品包括所開發(fā)的程序和相關(guān)的文檔，軟件產(chǎn)品的基本屬性是可維護(hù)性、可依賴性、有效性和可用性。軟件過程包括開發(fā)軟件產(chǎn)品的一系列活動。基本的活動包括軟件描述、開發(fā)、有效性驗(yàn)證和進(jìn)化。軟件方法是軟件生產(chǎn)的組織方式，包括對軟件過程的建議、使用的標(biāo)記、進(jìn)行系統(tǒng)描述的規(guī)則和設(shè)計(jì)指南。要點(diǎn)CASE工具是一些能夠支持軟件過程活動的軟件系統(tǒng)，如編輯設(shè)計(jì)圖表、檢查程序的一致性和追蹤已運(yùn)行的程序測試。軟件工程師對軟件工程這一職業(yè)和社會負(fù)有責(zé)任，不應(yīng)該只關(guān)心技術(shù)問題。思考1、軟件工程是一門工程學(xué)科，它把工程理論與技術(shù)應(yīng)用于軟件開發(fā)，規(guī)范軟件的開發(fā)過程，提高軟件的開發(fā)質(zhì)量。請思考：傳統(tǒng)工程學(xué)科如機(jī)械工程、電子工程中的工程理論能否直接應(yīng)用于軟件工程？只依靠工程理論與技術(shù)能否解決軟件開發(fā)中的所有問題？2、了解了軟件工程的一些基本概念，你對軟件的理解有了哪些不同？思考第二講軟件過程

（SoftwareProcesses）WelcometoSoftwareEngineeringLecture2目標(biāo)了解軟件過程與軟件過程模型的概念；掌握四種一般的過程模型及它們的適用情況；掌握軟件需求工程、軟件開發(fā)、軟件測試及軟件進(jìn)化所涉及的主要活動；了解軟件復(fù)用的思想和基于構(gòu)件的軟件開發(fā)的一般過程了解Rational統(tǒng)一過程模型的基本特點(diǎn)。內(nèi)容1.軟件過程模型2.過程活動3.基于構(gòu)件的軟件工程4.Rational統(tǒng)一過程軟件工程——一種層次化技術(shù)SoftwareEngineeringSoftwareEngineering“quality”focusprocessmethodstools過程、方法和工具軟件過程與軟件過程模型

軟件過程指包括了軟件生產(chǎn)設(shè)計(jì)的一系列活動，基本活動包括：Specification;Development(DesignandImplementation);Validation;Evolution.一個(gè)軟件過程模型是軟件過程的一種抽象表示，它通常是對軟件過程某一特定方面的抽象描述。1軟件過程模型介紹幾種常見的一般過程模型：瀑布模型（Thewaterfallmodel）進(jìn)化式開發(fā)（Evolutionarydevelopment）增量式開發(fā)螺旋式開發(fā)1.1瀑布模型（順序模型）1.1瀑布模型（順序模型）A.k.a.:ClassicLifeCycle1.1瀑布模型（順序模型）瀑布模型各階段需求定義與分析系統(tǒng)和軟件設(shè)計(jì)實(shí)現(xiàn)和單元測試集成與系統(tǒng)測試運(yùn)行和維護(hù)反饋表示在軟件開發(fā)過程中要針對一些具體情況做一些適應(yīng)性調(diào)整。瀑布模型的缺點(diǎn)和適用情況這種模型生硬的把一個(gè)軟件過程劃分成幾個(gè)界限清晰的階段，而且這些階段前后有嚴(yán)格的順序，這導(dǎo)致它很難對用戶的需求變更做出及時(shí)的調(diào)整；因此，瀑布模型只適合需求非常清楚和需求變更被嚴(yán)格限制的情況下。

實(shí)際的軟件開發(fā)過程中，幾乎沒有多少業(yè)務(wù)系統(tǒng)具有穩(wěn)定的需求。瀑布模型反映了工程設(shè)計(jì)的基本思想。

1.2進(jìn)化式開發(fā)模型基本思想：通過開發(fā)系統(tǒng)原型和用戶反復(fù)交互，以明確需求，使系統(tǒng)在不斷調(diào)整與修改中得以進(jìn)化成熟。又叫做原型式開發(fā)方法。兩種基本類型：探索式開發(fā);拋棄式原型法.1.2進(jìn)化式開發(fā)模型框架描述描述開發(fā)有效性驗(yàn)證初始版本最終版本中間版本中間版本中間版本并行活動問題缺乏過程可見性;系統(tǒng)結(jié)構(gòu)通常會很差;需要一些特別的技術(shù)（如原型快速開發(fā)技術(shù)），通常與主流技術(shù)不兼容.適用情況適合中小規(guī)模的交互系統(tǒng);可用于大型系統(tǒng)的局部開發(fā)（如系統(tǒng)界面），可以和瀑布模型混合使用；生命周期較短的系統(tǒng)。1.2進(jìn)化式開發(fā)模型1.3基于過程反復(fù)的過程模型對于大型項(xiàng)目而言，系統(tǒng)需求的變更是無法避免的，因此開發(fā)過程的反復(fù)是軟件開發(fā)的必要手段；過程反復(fù)可以和任何一種一般過程模型結(jié)合使用。兩種支持過程反復(fù)的過程模型：增量式開發(fā)；螺旋式開發(fā)。增量式開發(fā)這種開發(fā)方式不把系統(tǒng)作為一個(gè)整體交付，而是把系統(tǒng)分解成為若干個(gè)增量，每個(gè)增量交付系統(tǒng)部分功能；用戶需求按優(yōu)先級進(jìn)行排序，優(yōu)先級最高的需求有最早交付的增量來完成；一旦增量進(jìn)入開發(fā)階段，其需求的變更便被“凍結(jié)”，而同時(shí)后續(xù)的增量的需求分析可以同步進(jìn)行。增量式開發(fā)增量式開發(fā)的特點(diǎn)分析分析分析分析設(shè)計(jì)設(shè)計(jì)設(shè)計(jì)設(shè)計(jì)編碼編碼編碼編碼測試測試測試測試增量1增量2

增量3增量4

軟件功能項(xiàng)目時(shí)間增量1發(fā)布增量3發(fā)布增量2發(fā)布增量4發(fā)布增量式開發(fā)的特點(diǎn)分析分析設(shè)計(jì)設(shè)計(jì)編碼測試編碼測試測試增量1增量2

分析設(shè)計(jì)編碼增量3分析設(shè)計(jì)編碼測試增量4

軟件功能項(xiàng)目時(shí)間增量1發(fā)布增量3發(fā)布增量2發(fā)布增量4發(fā)布增量式開發(fā)的特點(diǎn)由于每個(gè)增量可以交付部分系統(tǒng)功能，因此軟件可以較早的交付用戶使用（部分功能）；早期交付的增量可以作為后期增量的原型幫助后期需求的確定；項(xiàng)目總體的失敗率較低；優(yōu)先級最高的系統(tǒng)功能得到最多的測試。螺旋式開發(fā)這種模型用螺旋線表示軟件過程，而不是采用一系列活動及活動間的反饋；螺旋中的每個(gè)回路表示軟件過程中的一個(gè)階段；這種模型充分考慮了軟件開發(fā)所面臨的風(fēng)險(xiǎn)，并貫穿軟件過程始終。螺旋模型螺旋模型螺旋線劃分成四部分目標(biāo)設(shè)置風(fēng)險(xiǎn)評估和規(guī)避開發(fā)與有效性驗(yàn)證規(guī)劃2.過程活動軟件描述（SoftwareSpecification）軟件設(shè)計(jì)和實(shí)現(xiàn)（SoftwareDesignandImplementation）軟件有效性驗(yàn)證（SoftwareValidation）軟件進(jìn)化（SoftwareEvolution）2.1軟件描述軟件描述（需求工程）要確定軟件系統(tǒng)要實(shí)現(xiàn)的功能及系統(tǒng)開發(fā)與運(yùn)行過程中要遵循的一些約束。需求工程過程包括：可行性研究；需求導(dǎo)出與分析；需求描述；需求有效性驗(yàn)證。需求工程過程2.2軟件設(shè)計(jì)與實(shí)現(xiàn)這個(gè)階段要把需求工程得到的系統(tǒng)描述轉(zhuǎn)換成可執(zhí)行的系統(tǒng)。軟件設(shè)計(jì)設(shè)計(jì)符合軟件描述的系統(tǒng)架構(gòu)和細(xì)節(jié)構(gòu)成，形成完整的系統(tǒng)解決方案。實(shí)現(xiàn)把“設(shè)計(jì)藍(lán)圖”翻譯成可執(zhí)行程序。設(shè)計(jì)與實(shí)現(xiàn)的活動常常是緊密聯(lián)系在一起的，很多時(shí)候是交替進(jìn)行的。設(shè)計(jì)過程活動體系結(jié)構(gòu)設(shè)計(jì)抽象描述接口設(shè)計(jì)組件設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)算法設(shè)計(jì)軟件設(shè)計(jì)過程程序設(shè)計(jì)與調(diào)試程序設(shè)計(jì)與調(diào)試是把設(shè)計(jì)翻譯成程序并且在程序中排除錯誤的過程；程序設(shè)計(jì)因人而異，通常沒有統(tǒng)一的設(shè)計(jì)模式；程序員通常要負(fù)責(zé)對自己編寫的程序進(jìn)行檢驗(yàn)（單元測試），從程序中定位錯誤并改正（調(diào)試）。調(diào)試過程2.3軟件有效性驗(yàn)證檢驗(yàn)（Verification）和有效性驗(yàn)證（validation）是要檢驗(yàn)系統(tǒng)是否符合它的規(guī)約描述的符合程度以及系統(tǒng)是否符合客戶的預(yù)期目標(biāo)。包括檢查、評審和系統(tǒng)測試的過程。系統(tǒng)測試主要是采用測試用例來執(zhí)行程序，測試用例是按照系統(tǒng)規(guī)約描述設(shè)計(jì)的系統(tǒng)可能處理的實(shí)際數(shù)據(jù)及預(yù)期結(jié)果。測試過程測試過程中的階段組件（或單元）測試Individualcomponentsaretestedindependently;Componentsmaybefunctionsorobjectsorcoherentgroupingsoftheseentities.集成測試Testingofthesystemasawhole.Testingofemergentpropertiesisparticularlyimportant.驗(yàn)收測試Testingwithcustomerdatatocheckthatthesystemmeetsthecustomer’sneeds.測試階段2.4軟件進(jìn)化軟件的特點(diǎn)使得軟件具有靈活性和易變性；由于需求會隨著業(yè)務(wù)環(huán)境發(fā)生變化，用于支持業(yè)務(wù)活動的軟件系統(tǒng)必須進(jìn)行進(jìn)化與變更。軟件過程通常會把軟件開發(fā)與軟件維護(hù)劃分為兩個(gè)階段，但完全從頭開發(fā)的系統(tǒng)已經(jīng)越來越少，所以把系統(tǒng)的開發(fā)與維護(hù)開成一個(gè)連續(xù)的過程更有意義即軟件進(jìn)化。系統(tǒng)進(jìn)化Exercise3基于構(gòu)件的軟件工程基于組件的軟件工程是一種面向軟件復(fù)用的軟件開發(fā)方式，這種方式中，軟件產(chǎn)品是由現(xiàn)有軟件組件或COTS(Commercial-off-the-shelf)系統(tǒng)組裝而成.過程階段組件分析;需求修訂;應(yīng)用復(fù)用的系統(tǒng)設(shè)計(jì);開發(fā)與集成。Thisapproachisbecomingincreasinglyusedascomponentstandardshaveemerged.3.1

軟件復(fù)用與軟構(gòu)件的基本思想軟件復(fù)用的定義軟構(gòu)件的概念軟件復(fù)用的意義1）軟件復(fù)用的定義正式提出：1968年，D.Mcllroy在國際上首次討論軟件工程的國際會議上建議建立生產(chǎn)軟組件的工廠，用產(chǎn)品目錄上的軟組件構(gòu)成復(fù)雜系統(tǒng)，以作為解決軟件危機(jī)的一種的一種可能技術(shù)途徑。軟件復(fù)用是指在兩次或多次不同的軟件開發(fā)過程中重復(fù)使用相同或相似軟件元素（通常稱為可復(fù)用構(gòu)件、組件或軟部件）的過程。軟件復(fù)用通常指復(fù)用“為了復(fù)用目的而設(shè)計(jì)的軟件”的過程。2）軟構(gòu)件的基本概念軟構(gòu)件的類比軟件IC!?軟件標(biāo)準(zhǔn)零部件!?2）構(gòu)件的基本概念構(gòu)件是為組裝服務(wù)的！軟件構(gòu)件是指可以獨(dú)立生產(chǎn)、獲取和部署的、可以被組裝到一個(gè)功能性系統(tǒng)中去的可執(zhí)行單元。軟構(gòu)件是標(biāo)準(zhǔn)的、可以互換的、經(jīng)過裝配可隨時(shí)使用的軟件模塊。3）軟件復(fù)用的意義軟件復(fù)用的出發(fā)點(diǎn)是使軟件系統(tǒng)的開發(fā)不再“一切從零開始”，能夠充分利用已有的知識和經(jīng)驗(yàn)。軟件復(fù)用是在軟件開發(fā)中避免重復(fù)勞動的解決方案。通過軟件復(fù)用，能夠充分利用已有的開發(fā)成果，消除軟件開發(fā)個(gè)階段的重復(fù)勞動，可以提高開發(fā)效率，見地開發(fā)成本。軟件復(fù)用還可以避免全新開發(fā)可能引入的錯誤，從而提高軟件的開發(fā)質(zhì)量。4）軟件復(fù)用技術(shù)的發(fā)展歷史1968年的NATO軟件工程會議上，Mcllroy在提交會議的論文《大量生產(chǎn)的軟件構(gòu)件》中，提出了“軟件組裝生產(chǎn)線”的思想。70年代中：軟件工廠研究實(shí)驗(yàn)80年代后期:構(gòu)件庫系統(tǒng)與構(gòu)件分類技術(shù)的研究取得進(jìn)展的方面：可復(fù)用構(gòu)件的創(chuàng)建與分發(fā)、復(fù)用支持環(huán)境、公司級復(fù)用計(jì)劃。問題：復(fù)用范圍太狹窄，沒有達(dá)到預(yù)期的在軟件生產(chǎn)力和質(zhì)量上的重大提高。提出對軟件復(fù)用的廣義理解。90年代：系統(tǒng)化復(fù)用對軟件體系結(jié)構(gòu)的認(rèn)識對過程的改進(jìn)復(fù)用業(yè)務(wù)組織90年代，基于構(gòu)件的軟件開發(fā)方法的研究和應(yīng)用開始興起?！皹?gòu)件化開發(fā)方法的興起是源于面向?qū)ο箝_發(fā)方法在軟件復(fù)用方面的受到的挫折?！?/p>

IanSommerville3.2基于構(gòu)件的軟件開發(fā)技術(shù)1）軟構(gòu)件技術(shù)的產(chǎn)生2）軟構(gòu)件的基本形式構(gòu)件是可被用來構(gòu)造其他軟件的軟件成分，基本形式可以是：被封裝的對象類類樹功能模塊軟件框架（framwork）軟件架構(gòu)（或體系結(jié)構(gòu)Architecture）文檔分析件設(shè)計(jì)模式等3）基于構(gòu)件的軟件工程（CBSE）由兩部分組成：制造軟件構(gòu)件的技術(shù)(屬于領(lǐng)域工程)。使用軟件構(gòu)件的技術(shù),也稱“基于構(gòu)件的軟件開發(fā)”。(ComponentBasedSoftwareDevelopment,CBSD）基于構(gòu)件的軟件工程需求描述組件分析需求修訂基于復(fù)用的系統(tǒng)設(shè)計(jì)開發(fā)與集成系統(tǒng)驗(yàn)證VSCBSE過程模型構(gòu)件生產(chǎn)線系統(tǒng)生產(chǎn)線

構(gòu)件開發(fā)分析設(shè)計(jì)編程測試

領(lǐng)域分析系統(tǒng)測試構(gòu)架細(xì)化

構(gòu)件提交領(lǐng)域知識領(lǐng)域?qū)＜医?jīng)驗(yàn)現(xiàn)有系統(tǒng)資料領(lǐng)域構(gòu)件需求構(gòu)件/構(gòu)架庫領(lǐng)域構(gòu)架領(lǐng)域構(gòu)件系統(tǒng)開發(fā)系統(tǒng)專用構(gòu)件應(yīng)用系統(tǒng)領(lǐng)域構(gòu)架領(lǐng)域構(gòu)件問題域用戶需求

專用構(gòu)件開發(fā)分析設(shè)計(jì)編程測試系統(tǒng)組裝

分析設(shè)計(jì)編程4.Rational統(tǒng)一過程（RUP）RUP是Rational在提出UML后開發(fā)的統(tǒng)一過程模型，是基于UML及相關(guān)過程的一種現(xiàn)代過程模型。RUP一般從三個(gè)視角來描述過程：動態(tài)視角；靜態(tài)視角；實(shí)踐視角。RUP階段模型RUP階段模型RUP各階段初始Establishthebusinesscaseforthesystem.細(xì)化Developanunderstandingoftheproblemdomainandthesystemarchitecture.構(gòu)造Systemdesign,programmingandtesting.轉(zhuǎn)換Deploythesysteminitsoperatingenvironment.RUP的好的實(shí)踐反復(fù)地開發(fā)軟件管理需求使用基于組件的體系結(jié)構(gòu)可視化模型軟件驗(yàn)證軟件質(zhì)量控制軟件變更要點(diǎn)軟件過程指軟件系統(tǒng)生產(chǎn)與進(jìn)化的一系列活動；軟件過程模型是軟件過程的抽象表示；軟件過程基本的過程活動包括軟件描述、軟件開發(fā)、軟件有效性驗(yàn)證和軟件進(jìn)化；四種一般過程模型：瀑布模型、進(jìn)化式軟件開發(fā)、增量式開發(fā)和螺旋模型；需求過程是開發(fā)軟件描述的過程；設(shè)計(jì)與實(shí)現(xiàn)把軟件描述轉(zhuǎn)換成一個(gè)可執(zhí)行程序；要點(diǎn)有效性驗(yàn)證要檢查系統(tǒng)是否符合規(guī)格描述和用戶需求；進(jìn)化考慮如何在軟件投付使用后修改完善軟件的問題；軟件復(fù)用是指在兩次或多次不同的軟件開發(fā)過程中重復(fù)使用相同或相似軟件元素（通常稱為可復(fù)用構(gòu)件、組件或軟部件）的過程?；跇?gòu)件的開發(fā)方式是采用大量可復(fù)用構(gòu)件組裝系統(tǒng)的開發(fā)方法。RUP是一個(gè)現(xiàn)代的一般過程模型；Exercise查找資料，了解敏捷開發(fā)與極限編程的基本思想及其與傳統(tǒng)軟件開發(fā)過程的區(qū)別，下節(jié)課討論！

第三講需求工程

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

LIBSYS）

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

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

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

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

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

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

”定義希望性需求；使用文本加亮來突出關(guān)鍵性需求；盡量避免使用計(jì)算機(jī)專用術(shù)語。2.5系統(tǒng)需求相對于用戶需求，系統(tǒng)需求是對系統(tǒng)功能、服務(wù)及約束的更詳盡的描述。系統(tǒng)需求是系統(tǒng)實(shí)現(xiàn)的基本依據(jù)，會被寫入合同中。因此系統(tǒng)需求是一個(gè)完全的、一致的系統(tǒng)描述，是設(shè)計(jì)的起點(diǎn)。系統(tǒng)需求可以用系統(tǒng)模型來定義與說明。使用自然語言描述系統(tǒng)需求的問題不明確Thereadersandwritersoftherequirementmustinterpretthesamewordsinthesameway.NLisnaturallyambiguoussothisisverydifficult.描述隨意性太大Thesamethingmaybesaidinanumberofdifferentwaysinthespecification.不能進(jìn)行模塊化描述NLstructuresareinadequatetostructuresystemrequirements.代替NL的描述方法結(jié)構(gòu)化的自然語言這種方式保持了自然語言的表達(dá)能力和易懂等特點(diǎn)，同時(shí)用預(yù)先定義的模版限制了書寫需求使得自由度：所有的需求都用一致的標(biāo)準(zhǔn)方法來書寫；對使用的詞匯進(jìn)行了限制，并用模板來約束?；跇?biāo)準(zhǔn)格式的描述方法對功能或?qū)嶓w的定義；對輸入及輸入來源的描述；對輸出及輸出去向的描述；其它被引用實(shí)體的索引；前條件與后條件；對操作的副作用（如果有）的描繪。例：添加節(jié)點(diǎn)的格式化描繪應(yīng)用表格進(jìn)行描述這種方法常用做自然語言描述的補(bǔ)充。適用于對于多種不同條件有多種可選動作（結(jié)果）的情況。例：表格描述圖形模型圖形模型在需要描述系統(tǒng)的狀態(tài)變化或動作序列時(shí)最為有用。有關(guān)圖形模型的應(yīng)用是這門課程的實(shí)踐重點(diǎn)！例：ATM取款序列圖3.需求導(dǎo)出與分析這個(gè)階段在可行性研究之后進(jìn)行。系統(tǒng)分析人員要和客戶及最終用戶一同調(diào)查應(yīng)用領(lǐng)域，找出系統(tǒng)應(yīng)提供的服務(wù)及其約束，即找出系統(tǒng)的功能需求與非功能需求。這個(gè)階段通常與需求描述交叉進(jìn)行。這個(gè)階段的活動會涉及到機(jī)構(gòu)中方方面面的人，如終端用戶、工程人員、業(yè)務(wù)經(jīng)理領(lǐng)域?qū)＜遥踔凉恚麄兌际菍ο到y(tǒng)需求產(chǎn)生直接或間接影響的人，被稱作stakeholders。需求分析可能遇到的問題Stakeholdersdon’tknowwhattheyreallywant.Stakeholdersexpressrequirementsintheirownterms.Differentstakeholdersmayhaveconflictingrequirements.Organisationalandpoliticalfactorsmayinfluencethesystemrequirements.Therequirementschangeduringtheanalysisprocess.Newstakeholdersmayemergeandthebusinessenvironmentchange.需求螺旋過程活動需求發(fā)現(xiàn)Interactingwithstakeholderstodiscovertheirrequirements.Domainrequirementsarealsodiscoveredatthisstage.需求的分類與組織Groupsrelatedrequirementsandorganisesthemintocoherentclusters.優(yōu)先排序和沖突解決Prioritisingrequirementsandresolvingrequirementsconflicts.需求文檔Requirementsaredocumentedandinputintothenextroundofthespiral.需求的發(fā)現(xiàn)與識別這是整個(gè)過程中最為關(guān)鍵的活動，負(fù)責(zé)收集目標(biāo)系統(tǒng)級現(xiàn)存系統(tǒng)的相關(guān)信息并從這些信息中提煉出用戶需求和系統(tǒng)需求。信息的來源包括已有的文件，系統(tǒng)的信息持有者（stakeholders）以及相近系統(tǒng)的規(guī)約描述。ATMstakeholdersBankcustomersRepresentativesofotherbanksBankmanagersCounterstaffDatabaseadministratorsSecuritymanagersMarketingdepartmentHardwareandsoftwaremaintenanceengineersBankingregulators3.1多視點(diǎn)（viewpoint）需求定義視點(diǎn)用來表述不同角度的需求來源（信息持有者、其它相關(guān)系統(tǒng)及領(lǐng)域）。每一個(gè)視點(diǎn)代表系統(tǒng)需求的一個(gè)子集。從多視點(diǎn)對系統(tǒng)進(jìn)行分析是十分重要的，因?yàn)闆]有那一種單一的途徑能夠詮釋整個(gè)系統(tǒng)需求。視點(diǎn)的類型交互者視點(diǎn)Peopleorothersystemsthatinteractdirectlywiththesystem.InanATM,thecustomer’sandtheaccountdatabaseareinteractorVPs.間接視點(diǎn)Stakeholderswhodonotusethesystemthemselvesbutwhoinfluencetherequirements.InanATM,managementandsecuritystaffareindirectviewpoints.領(lǐng)域視點(diǎn)Domaincharacteristicsandconstraintsthatinfluencetherequirements.InanATM,anexamplewouldbestandardsforinter-bankcommunications.視點(diǎn)的識別以下的幾個(gè)方面可以幫助識別視點(diǎn)：Providersandreceiversofsystemservices;Systemsthatinteractdirectlywiththesystembeingspecified;Regulationsandstandards;Sourcesofbusinessandnon-functionalrequirements.Engineerswhohavetodevelopandmaintainthesystem;Marketingandotherbusinessviewpoints.LIBSYS的視點(diǎn)3.2訪談對stakeholders進(jìn)行正式的和非正式的訪談對于需求工程是非常重要的工作。有兩種類型的訪談：封閉式訪談，預(yù)先定義所要提問的問題，又叫做限定式訪談；開放式訪談，不預(yù)先設(shè)定訪談內(nèi)容，給定一個(gè)范圍，與stakeholders自由交流以更好的把握他們的要求。訪談實(shí)踐通常是采用兩種方式相混合，以封閉式訪談開始，以開放式結(jié)束。訪談對于全面了解系統(tǒng)需求是一種很好的方法，在訪談中可以了解stakeholders的要求，他們是如何與系統(tǒng)交互的，對當(dāng)前系統(tǒng)面臨的問題等。訪談方式對于獲取領(lǐng)域需求并不是很奏效Requirementsengineerscannotunderstandspecificdomainterminology;Somedomainknowledgeissofamiliarthatpeoplefindithardtoarticulateorthinkthatitisn’twortharticulating.對訪談?wù)叩囊笥心芰Φ脑L談?wù)邞?yīng)該是思維開闊的，愿意聆聽他人的想法，并且不會對問題有先入為主的看法。他們善于用問題和建議去啟發(fā)訪問者的思維，或使用原型與被訪問者討論，而不是僅用‘whatdoyouwant’進(jìn)行簡單的提問。

3.3場景場景描述法是采用把系統(tǒng)交互放到一個(gè)真實(shí)的生活片段中，這樣比采用抽象的形式描述要容易理解，容易導(dǎo)出目標(biāo)系統(tǒng)的使用細(xì)節(jié)。場景的描述方式很多，一般包括：場景開始時(shí)系統(tǒng)初始狀態(tài)的描述；一個(gè)標(biāo)準(zhǔn)事件流的描述；對可能出現(xiàn)的錯誤及解決方法的描述；其它并行事件流的描述；場景結(jié)束狀態(tài)的描述。常用的方法，自然語言和用例。例：酒店預(yù)定場景描述開始：

MedocaSansumi,是theSantaCruzB&B的酒店前臺，一邊看著theHotelAppMain的銀幕一邊等著電話。電話從Ms.JaneGoogol打來，一個(gè)來自紐約的客戶。Ms.Googol拿起電話說“你好，我是JaneGoogol，我想要為新年的前夜預(yù)定一間房間”。Medoca在HotelApp的主銀幕上選擇了“創(chuàng)建預(yù)定”。屏幕上顯示出一個(gè)空預(yù)定。中間過程：

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

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

Medoca告訴Jane預(yù)約號（系統(tǒng)產(chǎn)生的），并且問道“我還能為您做什么？”，Jane回答沒什么了，Medoca向Jane道謝并且再見。Medoca關(guān)閉了預(yù)約表格的窗口，系統(tǒng)返回到MainHotelApp的主屏幕上。用例（UseCase）用例是一種基于UML的場景描述技術(shù)，用來識別在一個(gè)系統(tǒng)交互中的參與者并描述這個(gè)交互過程。用例的集合應(yīng)該可以描述系統(tǒng)中的所有的交互。UML中的序列圖可以用來配合用例圖描述系統(tǒng)的交互細(xì)節(jié)。例1：文獻(xiàn)打印用例圖例2：

LIBSYS用例模型例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.4結(jié)構(gòu)化分析（SA）建模結(jié)構(gòu)化分析方法是一種面向數(shù)據(jù)流的系統(tǒng)建模技術(shù)；SA幫助分析者理解系統(tǒng)的功能，并采用模型與用戶進(jìn)行交流；不同的模型從不同的角度對系統(tǒng)進(jìn)行描述。結(jié)構(gòu)化分析建模結(jié)構(gòu)化分析方法建立的分析模型結(jié)構(gòu)如下圖：實(shí)體—關(guān)系圖

數(shù)據(jù)詞典狀態(tài)—遷移圖數(shù)據(jù)流圖數(shù)據(jù)對象描述控制規(guī)格說明加工規(guī)格說明結(jié)構(gòu)化分析模型的核心是數(shù)據(jù)詞典，它描述了所有的在目標(biāo)系統(tǒng)中使用的和生成的數(shù)據(jù)對象。圍繞著這個(gè)核心的有三種圖：實(shí)體—關(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)化分析建模4.1數(shù)據(jù)建模與實(shí)體—關(guān)系圖(ERD)數(shù)據(jù)模型包括三種互相關(guān)聯(lián)的信息：數(shù)據(jù)對象描述對象的屬性描述對象間相互連接的關(guān)系（具體繪制方法同數(shù)據(jù)庫原理ER模型畫法）4.2功能建模和數(shù)據(jù)流圖

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

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

F1教材存量表

1

銷售

2采購

書庫保管員

學(xué)

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

購書單

缺書單

F2缺書登記表

缺書匯總表多個(gè)數(shù)據(jù)流與加工之間關(guān)系的符號

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

進(jìn)書通知

學(xué)生書庫保管員

購書單缺書單

教材采購與銷售管理系統(tǒng)一層數(shù)據(jù)流圖L1F1教材存量表

1

銷售

2采購

書庫保管員

學(xué)

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

購書單

缺書單

F2缺書登記表

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

學(xué)生

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

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

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

符號

含義

解釋

＝＋[...,...][...|...]{...}m{...}n(...)“...”..

被定義為與或或重復(fù)重復(fù)可選基本數(shù)據(jù)元素連結(jié)符例如，x=a＋b，表示x由a和b組成。例如，x=[a,b]，x=[a|b]，表示x由a或由b組成。例如，x={a}，表示x由0個(gè)或多個(gè)a組成。例如，x=3{a}8，表示x中a出現(xiàn)3到8次。例如，x=(a)，表示a可在x中出現(xiàn),也可不出現(xiàn)。例如，x=“a”，表示x為取值為a的數(shù)據(jù)元素。例如，x=1..9，表示x可取1到9之中的任一值。例如：類型：數(shù)據(jù)流條目名字：購書列表別名：購書單列表描述：對學(xué)生提供的購書單通過查庫存將有庫存的購書信息匯總形成的列表定義：購書列表={需書單位+書名+（刊號）+數(shù)量+（時(shí)限）+[學(xué)生用書|教師用書|圖書館用書]}類型：數(shù)據(jù)項(xiàng)條目名字：需書單位別名：購書單位描述：提供購書單的單位名稱定義：20個(gè)漢字例如：類型：數(shù)據(jù)存儲條目編號：F1名字：教材庫存量表別名：描述：記錄每種庫存教材的庫存數(shù)量定義：教材庫存量表={書名+（刊號）+（版本）+數(shù)量}數(shù)據(jù)組織方式：按書名拼音順序排列例如：4.2.4加工規(guī)格說明

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

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

判定樹和判定表

5UML與面向?qū)ο蠓治龇椒ㄝ^早的軟件開發(fā)，用結(jié)構(gòu)程序設(shè)計(jì)方法。這種方法中程序的定律是：程序=（算法）+（數(shù)據(jù)結(jié)構(gòu)）即過程（函數(shù)）是一個(gè)獨(dú)立的整體，數(shù)據(jù)結(jié)構(gòu)（包含數(shù)據(jù)類型與數(shù)據(jù)）也是一個(gè)獨(dú)立的整體。兩者分開設(shè)計(jì)，以算法（函數(shù)或過程）為主。

voidmain(){inta=1,b=2,c;c=max(a,b);}5.1結(jié)構(gòu)化與面向?qū)ο蠼Y(jié)構(gòu)化程序設(shè)計(jì)是一種面向過程的自頂向下的程序設(shè)計(jì)方法。BuildACarBuildChassisBuildEngineBuildDriveSystemAssemble…………結(jié)構(gòu)化與面向?qū)ο蠼Y(jié)構(gòu)化設(shè)計(jì)中模塊和模塊之間的關(guān)系，被緊緊局限于信息流，試圖通過信息流及其轉(zhuǎn)換來認(rèn)識系統(tǒng)，這限制了對模塊之間眾多關(guān)系的表達(dá)和體現(xiàn)，如繼承、依賴。main()buildD()buildE()buildC()assemble()…………結(jié)構(gòu)化與面向?qū)ο罅魉€式的過程處理與人們?nèi)粘Ｌ幚韱栴}的方式不一致。隨著時(shí)間流逝，軟件工程師越來越注重系統(tǒng)整體關(guān)系的表示和數(shù)據(jù)模型技術(shù)（把數(shù)據(jù)結(jié)構(gòu)與過程看作一個(gè)獨(dú)立功能模塊）。程序定律被重新認(rèn)識：

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

對象=（過程+數(shù)據(jù)結(jié)構(gòu)）程序=（對象+對象+...）也就是說，程序就是許多對象在計(jì)算機(jī)中相繼表現(xiàn)自己。而對象又是一個(gè)個(gè)程序?qū)嶓w。結(jié)構(gòu)化與面向?qū)ο?/p>

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

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

5.2UML基礎(chǔ)UML的歷史BoochmethodOMTUnifiedMethod0.8OOSEOthermethodsUML0.9UML1.01989-1994期間，OO方法從不足10種增加到50多種UML1.1OOPSLA′95Web-June′96UMLpartnerspublicfeedback

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

Fall1998UML1.3UML2.0UML的創(chuàng)始人UML是由世界著名的面向?qū)ο蠹夹g(shù)專家G.Booch、J.Rumbaugh和I.Jacobson發(fā)起，在Booch方法、OMT方法和OOSE方法的基礎(chǔ)上，廣泛征求意見，集眾家之長，幾經(jīng)修改而完成的。ThreeamigosBoochRumbaughJacobsonUML的特點(diǎn)統(tǒng)一了面向?qū)ο蠓椒ǖ谋硎颈硎灸芰?qiáng)大，可用于各種軟件系統(tǒng)建模，以及其它系統(tǒng)建模，如商業(yè)系統(tǒng)與開發(fā)過程無關(guān)允許擴(kuò)展本身不設(shè)計(jì)特點(diǎn)語言的語法及規(guī)則，但可對應(yīng)到各種OOP語言框架UML和OOA、OODUML既不是方法論，也不是一種開發(fā)過程，而是面向?qū)ο笙到y(tǒng)分析與設(shè)計(jì)的建模語言，是一種語言工具。如同英語充當(dāng)國際交流的工具一樣OOA&OOD是方法論，該方法論的實(shí)踐過程中需要使用UML的圖符，使用時(shí)還必須遵循一定的原則及步驟。5.2.2

UML結(jié)構(gòu)UMLStructure構(gòu)造塊buildingblocks公共機(jī)制commonmechanisms構(gòu)架architecture基本UML建模元素、關(guān)系和圖達(dá)到特定目標(biāo)的公共UML方法系統(tǒng)架構(gòu)的UML視圖UML模型元素模型元素是構(gòu)成圖片的最基本單位，一種模型元素通常有它主要出現(xiàn)的圖類型，但同時(shí)可以用在不同的圖中，但不論出現(xiàn)在哪里，一般表示相同的含義。通用機(jī)制一般用來表示注釋、語義、約束等含義，不隸屬于任何一種圖，是所有圖中通用的一些特殊模型元素。

UML模型元素依賴實(shí)現(xiàn)UML圖形圖diagrams類圖classdiagrams對象圖objectdiagrams構(gòu)件圖componentdiagrams部署圖deploymentdiagrams用例圖usecasediagrams順序圖sequence`diagrams協(xié)