軟件工程導(dǎo)論作業(yè)
軟件工程導(dǎo)論作業(yè)
Chapter1
1.1 什么是軟件危機(jī)?它有哪些典型表現(xiàn)?為什么會(huì)出現(xiàn)軟件危機(jī)?
答: 軟件危機(jī)是指在計(jì)算機(jī)軟件開發(fā)和維護(hù)過程中所遇到的一系列的嚴(yán)重問題。
它的典型表現(xiàn):1.軟件開發(fā)成本高,成本難以控制。2.研究周期長(zhǎng),軟件開發(fā)進(jìn)度難以控制,周期拖得很長(zhǎng)。3.正確性難以保證,軟件質(zhì)量差,可靠性難以保證。4.軟件維護(hù)困難,維護(hù)人員和維護(hù)費(fèi)用不斷增長(zhǎng)。5.軟件發(fā)展跟不上硬件的發(fā)展和用戶的要求。
它出現(xiàn)的原因一方面是由于軟件生產(chǎn)本身存在著復(fù)雜性,另一方面是與軟件開發(fā)所使用的方法和技術(shù)有關(guān)。軟件不同于硬件,它是計(jì)算機(jī)系統(tǒng)中的邏輯部件而不是物理部件。管理和控制軟件開發(fā)工程相當(dāng)困難,軟件是規(guī)模龐大,而且程序復(fù)雜性將隨著程序規(guī)模的增加而呈指數(shù)上升。目前相當(dāng)多的軟件專業(yè)技術(shù)人員對(duì)軟件開發(fā)和維護(hù)還有不省糊涂觀念,在實(shí)踐過程中或多或少地采用了錯(cuò)誤的方法和技術(shù),這是使軟件問題發(fā)展成為軟件危機(jī)的主要原因。
1.2 什么是軟件工程?它有哪些本質(zhì)特性?怎樣用軟件工程消除軟件危機(jī)?
答:軟件工程是將系統(tǒng)化的,規(guī)范化的,可度量的方法應(yīng)用于軟件開發(fā),運(yùn)行和維護(hù)的過程,即將工程化應(yīng)用于軟件中。
它的本質(zhì)特性:1.軟件工程關(guān)注于大型程序的構(gòu)造 2.軟件工程的中心課題是控制復(fù)雜性 3.軟件經(jīng)常化 4.開發(fā)軟件的效率非常重要 5.和諧地合作是開發(fā)軟件的關(guān)鍵 6.軟件必須有效地支持它的用戶 7.在軟件工程領(lǐng)域中是由一種文化背景的人替具有另一種文化背景的人創(chuàng)造產(chǎn)品。
基本原理: 1.用分階段的生命周期計(jì)劃嚴(yán)格管理 2.堅(jiān)持進(jìn)行階段評(píng)審 3.實(shí)行嚴(yán)格的產(chǎn)品控制 4.采用現(xiàn)代程序設(shè)計(jì)的技術(shù) 5.結(jié)果應(yīng)能清楚地審查 6.開發(fā)小組的人員應(yīng)該少而精 7.承認(rèn)不斷改進(jìn)軟件工程實(shí)踐的必要性。
1.3 什么是軟件?它有什么特點(diǎn)?
答:軟件是計(jì)算機(jī)系統(tǒng)中與硬件相互依存的另一部分,它是包括程序,數(shù)據(jù)結(jié)構(gòu)及其相關(guān)文檔的完整集合。
它的特點(diǎn)是:1.抽象而非具體 2.開發(fā)而非制造 3.退化而非磨損 4.定制而非基于構(gòu)件 5.不可見 6.復(fù)雜 7.易改變 8.易復(fù)制
1.4 什么是軟件過程?它與軟件工程方法學(xué)有何關(guān)系?
答:軟件過程是為了開發(fā)出高質(zhì)量的軟件產(chǎn)品所需完成的一系列任務(wù)的框架,它規(guī)定了完成各項(xiàng)任務(wù)的工作步驟。
軟件過程定義了運(yùn)用技術(shù)方法的順序,應(yīng)該交付的文檔資料,為保證軟件質(zhì)量和協(xié)調(diào)軟件變化必須采用的管理措施,以及標(biāo)志完成了相應(yīng)開發(fā)活動(dòng)的里程碑。軟件過程是軟件工程方法學(xué)的3個(gè)重要組成部分之一。軟件工程的基礎(chǔ)是軟件過程。
1.5 什么是軟件生命周期模型?試比較瀑布模型、原型模型、增量模型和螺旋模型的優(yōu)缺點(diǎn),說明每種模型的適用范圍。
答:軟件生命周期模型是軟件開發(fā)全部過程,活動(dòng)和任務(wù)的結(jié)構(gòu)框架,它能直觀表達(dá)軟件開發(fā)全過程,明確規(guī)定要完成的主要活動(dòng),任務(wù)和開發(fā)策略。也叫軟件開發(fā)模型。
瀑布模型 優(yōu)點(diǎn):有利于大型軟件開發(fā)過程中人員的組織,管理,有利于軟件開發(fā)方法和工具的研究,從而提高了大型軟件項(xiàng)目開發(fā)的質(zhì)量和效率。
缺點(diǎn):1,開發(fā)過程一般不能逆轉(zhuǎn),否則代價(jià)太大 2.實(shí)際的項(xiàng)目開發(fā)很難嚴(yán)格按
照該模型進(jìn)行 3.客戶往往很難清楚地給出所有的需求,而該模型卻要求如此 4.軟件的實(shí)際情況必須到項(xiàng)目開發(fā)的后期客戶才能看到,這要求客戶有足夠的耐心。
適用范圍:1.用戶的需求非常清楚全面,且在開發(fā)過程中沒有或變化很少 2.開發(fā)人員對(duì)軟件的應(yīng)用領(lǐng)域很熟悉 3.用戶的使用環(huán)境非常穩(wěn)定 4.開發(fā)工作隊(duì)用戶參與的要求很低。
原型模型 優(yōu)點(diǎn):1.可以得到比較良好的需求定義,容易適應(yīng)需求的變化 2.有利于開發(fā)與培訓(xùn)的同步 3.開發(fā)費(fèi)用低,開發(fā)周期短且隊(duì)用戶更友好。
缺點(diǎn):1.客戶與開發(fā)者對(duì)原型的理解不同 2.準(zhǔn)確的原型設(shè)計(jì)比較困難 3.不利于開發(fā)人員的創(chuàng)新
適用范圍:1.對(duì)所開發(fā)的領(lǐng)域比較熟悉而且有快速的原型開發(fā)工具 2.項(xiàng)目投標(biāo)時(shí),可以以原型模型作為軟件的開發(fā)模型 3.進(jìn)行產(chǎn)品移植或升級(jí)時(shí),或?qū)σ延挟a(chǎn)品原型進(jìn)行客戶化工作時(shí),原型模型非常合適。
增量模型 優(yōu)點(diǎn):1.采用增量模型的優(yōu)點(diǎn)是人員分配靈活,剛開始不用投入大量的人力資源
2.如果核心產(chǎn)品很受歡迎,則可增加人力實(shí)現(xiàn)下一個(gè)增量 3.可先發(fā)部分功能給客戶,對(duì)客戶起到鎮(zhèn)靜劑的作用。
缺點(diǎn):1.并行開發(fā)構(gòu)件有可能遇到不能集成的風(fēng)險(xiǎn),軟件必須具備開放式的體系結(jié)構(gòu) 2.增量模型的靈活性可以使其適應(yīng)這種變化的能力大于優(yōu)于瀑布模型和原型模型,但也很容易退化為邊做邊改模型,從而使軟件過程的控制失去整體性。
適用范圍:1.進(jìn)行已有產(chǎn)品升級(jí)或新版本開發(fā),增量模型是非常適合的 2.對(duì)完成期限嚴(yán)格要求的產(chǎn)品,可以使用增量模型 3.對(duì)所開發(fā)的領(lǐng)域比較熟悉而且已有原型系統(tǒng),增量模型也非常適合。
螺旋模型 優(yōu)點(diǎn):1.實(shí)際上的靈活性,可以再項(xiàng)目的各個(gè)階級(jí)進(jìn)行變更 2.以小的分段來構(gòu)建大型系統(tǒng),是成本計(jì)算變得簡(jiǎn)單容易 3.客戶始終參與每個(gè)階段的開發(fā),保證了項(xiàng)目不偏離正確方向以及項(xiàng)目的可控性 4.隨著項(xiàng)目推進(jìn),客戶始終掌握項(xiàng)目的最新消息,從而是他或她能夠和管理層有效地交互。
缺點(diǎn):1.采用螺旋模型需要具有相當(dāng)豐富的風(fēng)險(xiǎn)評(píng)估經(jīng)驗(yàn)和專門知識(shí),在風(fēng)險(xiǎn)較大的項(xiàng)目開發(fā)中,如果未能夠及時(shí)標(biāo)識(shí)風(fēng)險(xiǎn),勢(shì)必造成重大損失 2.過多的迭代次數(shù)會(huì)增加開發(fā)成本,延遲提交時(shí)間。
適用范圍:只適合于大規(guī)模的軟件項(xiàng)目。
1.6 怎么理解軟件工程的概念及其意義?
答:軟件工程是一門將理論和知識(shí)應(yīng)用于實(shí)踐的工程,它借鑒了傳統(tǒng)工程的原則和方法,以求高效地開發(fā)高質(zhì)量軟件。它是一種層次化技術(shù)。
意義:從歷史上講,軟件工程的作用,是為了克服上個(gè)世紀(jì)60年代出現(xiàn)的軟件危機(jī),這種危機(jī)表現(xiàn)為軟件開發(fā)的成本大、進(jìn)度慢、維護(hù)難和質(zhì)量得不到保障。從當(dāng)前來講,軟件工程的作用,就是告訴人們?cè)鯓尤ラ_發(fā)軟件和管理軟件。具體地講,它表現(xiàn)在與軟件開發(fā)和管理有關(guān)的人員和過程上。
1.7 軟件過程的通用過程框架包含哪兩類活動(dòng)?
答:一類是框架活動(dòng),還有一類是保護(hù)性活動(dòng)。
1.8 描述基于構(gòu)件開發(fā)的思想以及目前的發(fā)展情況。
答:基于構(gòu)件開發(fā)強(qiáng)調(diào)將被設(shè)計(jì)的系統(tǒng)分解成功能的或邏輯的構(gòu)件,構(gòu)件用定義好的接口進(jìn)行通信。
它是現(xiàn)在軟件復(fù)理論實(shí)用化的研究熱點(diǎn),在構(gòu)件對(duì)象模型的支持下,通過復(fù)用已有的構(gòu)件,軟件開發(fā)者可以“即插即用”地快速構(gòu)造應(yīng)用軟件,這樣即可以節(jié)省時(shí)間和經(jīng)費(fèi),提高工作效率,也可以產(chǎn)生更加規(guī)范,更加可靠的應(yīng)用軟件。
1.9 請(qǐng)簡(jiǎn)要說明 RUP 的9 個(gè)規(guī)程(disciplines)及之間關(guān)系?
答:RUP的9個(gè)規(guī)程為:業(yè)務(wù)建模,需求,分析與設(shè)計(jì),實(shí)現(xiàn),測(cè)試,部署,配置與變更管理,項(xiàng)目管理以及環(huán)境。
對(duì)于一個(gè)大型項(xiàng)目,RUP九個(gè)規(guī)程的活動(dòng)不可或缺,但對(duì)于有些項(xiàng)目可能不需要經(jīng)過所有九個(gè)規(guī)程,在項(xiàng)目開發(fā)時(shí)需要對(duì)這些規(guī)程涉及的活動(dòng)做具體的裁剪,以適應(yīng)具體項(xiàng)目的開發(fā)需要。
1.10 說明面向切面編程的特點(diǎn),有什么優(yōu)勢(shì)?
答:該范型以一種稱為切面的語言構(gòu)造為基礎(chǔ),切面是一種新的模塊化機(jī)制,用來描述分散在對(duì)象、類或函數(shù)中分離出來可以大大增強(qiáng)程序的模塊性。
優(yōu)勢(shì):他把特定領(lǐng)域問題的代碼從業(yè)務(wù)邏輯中獨(dú)立出來,業(yè)務(wù)邏輯的代碼中不再含有針對(duì)特定領(lǐng)域問題代碼的調(diào)用,業(yè)務(wù)邏輯同特定領(lǐng)域問題的關(guān)系通過切面來進(jìn)行封裝,維護(hù)。 優(yōu)勢(shì):面向切面編程的特點(diǎn)是針對(duì)業(yè)務(wù)處理過程中的切面提取,所面對(duì)的是處理過程中的某個(gè)步驟或階段,以獲得邏輯過程中各部分之間低耦合性的隔離效果,降低了耦合性。
1.11 模型驅(qū)動(dòng)工程中 MDA 的基本思想是什么?
答:MDA的基本思想是系統(tǒng)的功能性是用合適的規(guī)約語言以平臺(tái)無關(guān)的模型的方式定義,然后為實(shí)際的實(shí)現(xiàn)翻譯到一個(gè)或多個(gè)平臺(tái)相關(guān)的模型上。
Chapter2
2.1 描述面向?qū)ο蟮幕靖拍詈退枷搿?/p>
答:面向?qū)ο笫且环N以對(duì)象為基礎(chǔ),以事件或消息來驅(qū)動(dòng)對(duì)象執(zhí)行處理和程序設(shè)計(jì)技術(shù)。 面向?qū)ο蟮幕舅枷胧钦J(rèn)為客觀實(shí)體和實(shí)體之間的聯(lián)系構(gòu)成了現(xiàn)實(shí)世界的所有問題,而每
一個(gè)實(shí)體都可以抽象為對(duì)象。
2.2 面向?qū)ο蠓治鲈O(shè)計(jì)的基本思路和過程是怎樣的?
答:分析過程主要包括理解、表達(dá)和驗(yàn)證。設(shè)計(jì)是把分析階段得到的需求轉(zhuǎn)變成符合成本和質(zhì)量要求的、抽象的系統(tǒng)實(shí)現(xiàn)方案的過程。
過程:識(shí)別系統(tǒng)的用例和角色,進(jìn)行系統(tǒng)分析并抽象出類,設(shè)計(jì)系統(tǒng)并設(shè)計(jì)系統(tǒng)中的類及其行為。
2.3 面向?qū)ο蟪绦蛟O(shè)計(jì)中的概念主要包括哪些?分別闡述其主要思想。
答:對(duì)象:封裝了數(shù)據(jù)和操作這些數(shù)據(jù)的代碼的邏輯實(shí)體。
類:具有相同類型的對(duì)象的抽象。
封裝:保證軟件部分具有優(yōu)良的模塊性的基礎(chǔ)。
繼承:讓某個(gè)類型對(duì)象獲得另一個(gè)類型的對(duì)象特征。
多態(tài):使不同內(nèi)部結(jié)構(gòu)的對(duì)象可以共享相同的外部接口,減少代碼復(fù)雜度。
動(dòng)態(tài)綁定:多態(tài)實(shí)現(xiàn)的具體形式,將一個(gè)過程調(diào)用與相應(yīng)代碼鏈接起來的行為。 消息傳遞:使得對(duì)現(xiàn)實(shí)世界的描述更容易。
方法:定義一個(gè)類可以做的,但不一定去做的事。
2.4 描述 UML 的主要概念和歷史。
答:UML是統(tǒng)一建模語言,用來對(duì)軟件密集系統(tǒng)進(jìn)行可視化建模的一種語言。UML為面向?qū)ο箝_發(fā)系統(tǒng)的產(chǎn)品進(jìn)行說明、可視化、和編制文檔的一種標(biāo)準(zhǔn)語言。
歷史:Rumbaugh和Booch將Booch93和OMT-2統(tǒng)一起來,發(fā)布了UM0.8;后經(jīng)過Booch,Rumbaugh和Jacobson的共同努力,發(fā)布了UML0.9和UML0.91,并將UM重命名為UML。97年,Rational組織成立了UML合作者聯(lián)盟,以完善、加強(qiáng)和促進(jìn)UML的定義工作。2000年啟動(dòng)了UML2.0標(biāo)準(zhǔn)的制定工作。
2.5 RUP 是什么?應(yīng)用RUP 對(duì)軟件開發(fā)有什么意義?
答:RUP(Rational Unified Process)是統(tǒng)一軟件開發(fā)過程,是一個(gè)面向?qū)ο笄一诰W(wǎng)絡(luò)的程序開發(fā)方法論。
應(yīng)用RUP為軟件開發(fā)提供了一個(gè)模版,使得軟件開發(fā)過程規(guī)范化,統(tǒng)一化。
Chapter3
3.1 為什么要進(jìn)行業(yè)務(wù)建模?業(yè)務(wù)建模適用什么場(chǎng)合的軟件項(xiàng)目開發(fā)?
答:進(jìn)行業(yè)務(wù)建模的原因:業(yè)務(wù)人員、IT技術(shù)的業(yè)務(wù)知識(shí)、IT技術(shù)知識(shí)彼此之間存在著較大的差異,而規(guī)模較大的軟件開發(fā)項(xiàng)目是不太可能讓所有參加項(xiàng)目的IT技術(shù)人員都先熟悉
業(yè)務(wù)知識(shí)而再進(jìn)行開發(fā)的,所以需要通過“業(yè)務(wù)建!睂ⅰ皹I(yè)務(wù)需求”準(zhǔn)確地轉(zhuǎn)換為IT技術(shù)人員所熟悉的“軟件需求”。
適用場(chǎng)合:規(guī)模較大的軟件項(xiàng)目開發(fā)。
3.2 業(yè)務(wù)建?梢苑帜男┕ぷ髁鬟M(jìn)行?
答:評(píng)估業(yè)務(wù)狀態(tài)、描述當(dāng)前業(yè)務(wù)、定義業(yè)務(wù)、探索流程自動(dòng)化、開發(fā)領(lǐng)域模型。
3.3 什么是領(lǐng)域模型?與業(yè)務(wù)模型的關(guān)系是什么?
答:領(lǐng)域模型:領(lǐng)域模型是描述業(yè)務(wù)用例實(shí)現(xiàn)的對(duì)象模型。它是對(duì)業(yè)務(wù)角色和業(yè)務(wù)實(shí)體之間應(yīng)該如何聯(lián)系和協(xié)作以執(zhí)行業(yè)務(wù)的一種抽象。領(lǐng)域模型從業(yè)務(wù)角色內(nèi)部的觀點(diǎn)定義了業(yè)務(wù)用例。該模型為產(chǎn)生預(yù)期效果確定了業(yè)務(wù)人員以及他們處理和使用的對(duì)象(“業(yè)務(wù)類和對(duì)象”)之間應(yīng)該具有的靜態(tài)和動(dòng)態(tài)關(guān)系。它注重業(yè)務(wù)中承擔(dān)的角色及其當(dāng)前職責(zé)。這些模型類的對(duì)象組合在一起可以執(zhí)行所有的業(yè)務(wù)用例。
關(guān)系:開發(fā)領(lǐng)域模型是一個(gè)備選活動(dòng),領(lǐng)域模型是業(yè)務(wù)分析模型中獨(dú)立的一部分,注重于說明對(duì)于業(yè)務(wù)領(lǐng)域很重要的概念、產(chǎn)品、可交付成果和事件。這樣一個(gè)模型僅描述業(yè)務(wù)中的重要信息,并不包括人員承擔(dān)的職責(zé)。
3.4 什么是系統(tǒng)上下文?明確目標(biāo)系統(tǒng)的上下文有什么意義?
答:系統(tǒng)上下文:指的是目標(biāo)系統(tǒng)、與之交互的用戶和外部系統(tǒng)。
意義:業(yè)務(wù)建模作為軟件需求的前一階段,了解目標(biāo)系統(tǒng)的上下文是很有必要的,便于確定目標(biāo)組織和業(yè)務(wù)范圍。
3.5 什么是業(yè)務(wù)涉眾?業(yè)務(wù)涉眾可能來自哪些方面?
答:業(yè)務(wù)涉眾:所有跟目標(biāo)業(yè)務(wù)有利害關(guān)系的人。
方面:可能來自目標(biāo)組織內(nèi)部及目標(biāo)組織外部且跟目標(biāo)組織有關(guān)系的人和組織。
3.6 什么是業(yè)務(wù)愿景?怎么理解業(yè)務(wù)愿景的重要性?
答:業(yè)務(wù)愿景:定義業(yè)務(wù)建模工作所針對(duì)的一組目標(biāo)。
重要性:要了解組織的業(yè)務(wù)過程,對(duì)業(yè)務(wù)進(jìn)行建模,首先必須理解組織的共同愿景,業(yè)務(wù)建模時(shí)期的重要任務(wù)就是確定項(xiàng)目涉眾的共同愿景,而了解最有影響力的涉眾的愿望和目標(biāo)是非常重要的環(huán)節(jié)。所以業(yè)務(wù)愿景對(duì)整個(gè)業(yè)務(wù)建模過程來說是十分關(guān)鍵和重要的。
3.7 業(yè)務(wù)建模的作用是什么?哪些人和組織是潛在的業(yè)務(wù)執(zhí)行者?
答:作用:
(1)了解目標(biāo)組織(將要在其中部署系統(tǒng)的組織)的結(jié)構(gòu)和機(jī)制;
(2)了解目標(biāo)組織中當(dāng)前存在的問題并確定潛在改進(jìn)的可能性;
(3)確?蛻、最終用戶、開發(fā)人員和其他各方就目標(biāo)組織達(dá)成共識(shí);
(4)導(dǎo)出支持目標(biāo)組織所需的系統(tǒng)需求;
(5)了解要部署的軟件系統(tǒng)將如何融入組織。
潛在的業(yè)務(wù)執(zhí)行者:客戶、合作伙伴、供應(yīng)商、權(quán)威機(jī)構(gòu)(法律、法規(guī)等制訂機(jī)構(gòu))、子公司、所有者和投資者、業(yè)務(wù)以外的信息系統(tǒng)等。
3.8 結(jié)構(gòu)化業(yè)務(wù)用例的三種關(guān)系是什么?
答:三種關(guān)系:包含關(guān)系、擴(kuò)展關(guān)系、泛化關(guān)系。
3.9 業(yè)務(wù)用例的包含與擴(kuò)展關(guān)系、包含與泛化的區(qū)別是什么?
答:包含與泛化的區(qū)別:(1)對(duì)于用例泛化關(guān)系,子用例的執(zhí)行取決于父用例(重用部分)的結(jié)構(gòu)和行為,而在包含關(guān)系中,基本用例的執(zhí)行只取決于包含用例(重用部分)所執(zhí)行的功能的結(jié)果。(2)在泛化關(guān)系中,子用例的用途和結(jié)構(gòu)是相似的,而在包含關(guān)系中,重用同一個(gè)包含用例的基本用例可能有完全不同的用途,但需求執(zhí)行相同的功能。
包含與擴(kuò)展的區(qū)別:(1)包含關(guān)系:如果基本用例的某個(gè)部分代表一個(gè)功能,而業(yè)務(wù)用例只依賴于本功能的結(jié)果,而不是產(chǎn)生結(jié)果的方法,那么可以將這部分分離出來,形成一個(gè)附加用例。使用包含關(guān)系,將附加部分明確包含于基本用例中。包含關(guān)系將基本用例和包含用例連接起來。
(2)擴(kuò)展關(guān)系:如果基本用例的一部分是可選的,或?qū)τ诶斫庠撚美闹饕康膩碚f不是必需的,那么可以將這部分分離出來,形成一個(gè)附加用例,以簡(jiǎn)化基本用例的結(jié)構(gòu)。利用擴(kuò)展關(guān)系,將附加部分隱含地包含于基本用例中。擴(kuò)展關(guān)系將擴(kuò)展用例與基本用例連接起來。
3.10 業(yè)務(wù)分析模型的作用是什么?與業(yè)務(wù)用例模型的之間是什么關(guān)系?
答:作用:業(yè)務(wù)分析模型描述通過與業(yè)務(wù)系統(tǒng)、業(yè)務(wù)工作者和業(yè)務(wù)實(shí)體交互來實(shí)現(xiàn)業(yè)務(wù)用例。它充當(dāng)了為了執(zhí)行業(yè)務(wù)用例而所需業(yè)務(wù)系統(tǒng)、業(yè)務(wù)工作者和業(yè)務(wù)實(shí)體之間的相關(guān)和協(xié)作方式的.抽象。它還定義了在執(zhí)行業(yè)務(wù)用例時(shí)由業(yè)務(wù)執(zhí)行者調(diào)用的外部業(yè)務(wù)服務(wù)。
關(guān)系:業(yè)務(wù)用例模型是從與客戶和業(yè)務(wù)流程對(duì)應(yīng)的業(yè)務(wù)執(zhí)行者和業(yè)務(wù)用例的角度,對(duì)業(yè)務(wù)進(jìn)行描述。業(yè)務(wù)用例模型包括工作流程說明,此說明確定完成了那些工作。所以業(yè)務(wù)用例模型描述在業(yè)務(wù)執(zhí)行者和業(yè)務(wù)之間發(fā)生了什么,對(duì)于業(yè)務(wù)結(jié)構(gòu)或如何實(shí)現(xiàn)業(yè)務(wù)用例不作任何假設(shè)。而業(yè)務(wù)分析模型就是用于描述如何執(zhí)行業(yè)務(wù)用例,并具體定義業(yè)務(wù)提供的服務(wù),內(nèi)部業(yè)務(wù)工作者及其使用的信息,將它們的結(jié)構(gòu)化組織描述為獨(dú)立的單元,定義業(yè)務(wù)工作者如何通過交戶來實(shí)現(xiàn)業(yè)務(wù)用例中所描述的行為。
3.11
(c)
2. 以醫(yī)院為研究對(duì)象,請(qǐng)描述醫(yī)生、病歷的性質(zhì)分別是( )
(a) business actor、business worker
(b) business worker、business actor
(c) business actor、business entity
(d) business worker、business entity
3.12 綜合案例分析-餐廳點(diǎn)菜業(yè)務(wù)分析
某餐廳的點(diǎn)菜服務(wù)流程與規(guī)范如下:
1.遞上菜單
(1)客人入座后,服務(wù)員詢問客人需要什么茶水。準(zhǔn)備好茶水后,按“女士?jī)?yōu)先,先
賓后主”的原則從右邊為客人斟上茶水。
(2)將菜單打開第一頁,按照“女士?jī)?yōu)先”原則,用雙手從客人右側(cè)將菜單送至客人 手中,然后站在客人斜后方能觀察客人面部表情的地方,上身微躬。
2.推薦介紹酒店菜品
(1)在客人點(diǎn)菜前,服務(wù)員應(yīng)留有時(shí)間讓客人翻看菜單。
(2)在客人翻看菜單時(shí),應(yīng)及時(shí)向客人簡(jiǎn)單介紹菜單上的菜,回答客人的詢問。
(3)向客人介紹廚師長(zhǎng)今日特別推薦的菜品、其他的特色菜、暢銷菜和高檔菜等菜品, 并介紹其樣式、味道、溫度和特點(diǎn)。
3.接受點(diǎn)菜
(1)服務(wù)員先在點(diǎn)菜單上記下日期、本人姓名及臺(tái)號(hào)、就餐人數(shù)等。
(2)客人點(diǎn)菜時(shí),應(yīng)注視客人,聽清客人點(diǎn)的菜名,適時(shí)幫助客人選擇菜品和主動(dòng)推 介菜品,準(zhǔn)確地記錄菜名。
(3)對(duì)于特殊菜品,應(yīng)介紹其特殊之處,并問清客人所需火候、配料及調(diào)料等。
(4)若客人用餐時(shí)間較緊,點(diǎn)的菜需時(shí)間較長(zhǎng),則應(yīng)及時(shí)向客人征求意見;若有客人 點(diǎn)相同的菜式,如湯和羹或兩個(gè)酸甜味型的菜時(shí),應(yīng)有禮貌地問客人是否需要更換菜式。
(5)若客人有特殊要求,應(yīng)在點(diǎn)菜單上清楚注明,并告知傳菜服務(wù)員。
4.復(fù)述點(diǎn)菜內(nèi)容
(1)客人點(diǎn)菜完畢后,服務(wù)員應(yīng)清楚地重復(fù)一遍所點(diǎn)菜品內(nèi)容,并請(qǐng)客人確認(rèn)。
(2)復(fù)述完畢后,在點(diǎn)菜單的右上角寫明當(dāng)時(shí)的時(shí)間,以便查詢。
(3)收回菜單并向客人致謝,同時(shí)請(qǐng)客人稍等,說明大致的等候時(shí)間。
5.分送點(diǎn)菜單
(1)服務(wù)員將點(diǎn)菜單的第一聯(lián)送至收銀處。
(2)將點(diǎn)菜單的第二聯(lián)送至廚房。
(3)將第三聯(lián)給客戶,第四聯(lián)交給傳菜員、值臺(tái)服務(wù)員留底備查。
根據(jù)案例的描述,請(qǐng)你完成下列任務(wù):
1. 分析餐廳的點(diǎn)菜業(yè)務(wù),建立點(diǎn)菜業(yè)務(wù)模型。
這項(xiàng)業(yè)務(wù)的業(yè)務(wù)涉眾:外部涉眾:客人,
內(nèi)部涉眾:服務(wù)員,收銀處,廚房,值臺(tái)服務(wù)員
分析點(diǎn)菜業(yè)務(wù)模型:
業(yè)務(wù)執(zhí)行者為:客人
業(yè)務(wù)用例是:入座,推薦菜品,點(diǎn)菜,確認(rèn)內(nèi)容,分送菜單,上菜
2. 用活動(dòng)圖描述客人點(diǎn)菜的活動(dòng)。
3. 分析點(diǎn)菜業(yè)務(wù)模型,找出有哪些業(yè)務(wù)工作者和業(yè)務(wù)實(shí)體,并用交互圖來說明之間的通信和交互關(guān)系。
業(yè)務(wù)工作者為:服務(wù)員,收銀處,廚房,值臺(tái)服務(wù)員
業(yè)務(wù)實(shí)體為:菜單,點(diǎn)菜單
Chapter4
4.1 需求的類別有哪些?
答:需求可分為功能性需求和非功能性需求。
功能性需求規(guī)定了系統(tǒng)無需考慮物理約束而必須能夠執(zhí)行的動(dòng)作,描述支持用戶目標(biāo)、任務(wù)或活動(dòng)的系統(tǒng)行為(功能或服務(wù))。
非功能性需求是功能性需求之外的需求,包含質(zhì)量和約束,它們僅僅說明系統(tǒng)或系統(tǒng)環(huán)境的屬性。
4.2 怎么理解文中 Fred Brooks 關(guān)于需求的那段話?
構(gòu)建軟件系統(tǒng)最難的部分是確定要構(gòu)建什么(即系統(tǒng)需求)。相比其他工作,如果這個(gè)工作做錯(cuò),會(huì)嚴(yán)重影響將產(chǎn)生的系統(tǒng),也更難在以后矯正。
答:需求工作對(duì)于整個(gè)軟件系統(tǒng)來說是非常重要的,它是實(shí)現(xiàn)和測(cè)試的先啟階段,需求建模解釋如何理清涉眾的請(qǐng)求及如何把這些請(qǐng)求轉(zhuǎn)化為一組需求工作產(chǎn)品,確定要建系統(tǒng)的范圍,提供系統(tǒng)必須做的詳細(xì)要求。此階段是后續(xù)工作以及整個(gè)系統(tǒng)的基礎(chǔ)和關(guān)鍵,一旦這個(gè)階段出現(xiàn)問題,將會(huì)直接影響到后續(xù)工作的正常順利進(jìn)行,而如果想要在以后改,代價(jià)是非常大的,并且也難糾正。
4.3 系統(tǒng)用例模型可以描述什么方面的需求?補(bǔ)充規(guī)約主要補(bǔ)充哪方面的需求?
答:系統(tǒng)用例模型可以描述設(shè)計(jì)軟件系統(tǒng)方面的需求,參與者與軟件系統(tǒng)的交互,在系統(tǒng)用例說明中書寫足夠詳細(xì)的事件流。
補(bǔ)充歸約主要補(bǔ)充那些無法在用例中記錄的需求。包括:捕捉無用例歸約的功能性需求,捕捉系統(tǒng)資量,捕捉約束,捕捉符合性需求,捕捉文檔需求。
4.4 什么是系統(tǒng)執(zhí)行者?如何尋找潛在的系統(tǒng)執(zhí)行者?
答:系統(tǒng)執(zhí)行者:是指與目標(biāo)系統(tǒng)交換數(shù)據(jù)的任何對(duì)象,是在系統(tǒng)之外,透過系統(tǒng)邊界與系統(tǒng)進(jìn)行有意義交互的任何事物。執(zhí)行者可以是用戶、外部硬件或其它系統(tǒng)。
尋找潛在的系統(tǒng)執(zhí)行者:首先可以從業(yè)務(wù)模型中去查找,那些業(yè)務(wù)執(zhí)行者和業(yè)務(wù)工作者是潛在的系統(tǒng)執(zhí)行者。如果沒有做業(yè)務(wù)建模,那可以回答以下問題:哪些用戶組需要系統(tǒng)幫助來執(zhí)行它們的任務(wù)?執(zhí)行系統(tǒng)最明顯的主要功能需要哪些用戶組?要求哪些用戶組執(zhí)行次要功能,如系統(tǒng)維護(hù)和管理?哪些外部硬件或軟件系統(tǒng)會(huì)與新系統(tǒng)交互嗎?是否有事情在預(yù)定的時(shí)間自動(dòng)發(fā)生?
滿足一個(gè)或多個(gè)上面這些范疇的任何個(gè)人、小組或事物有可能就是執(zhí)行者。
4.5 如何理解系統(tǒng)執(zhí)行者與業(yè)務(wù)執(zhí)行者、業(yè)務(wù)工作者的關(guān)系?
答:業(yè)務(wù)執(zhí)行者是指某人或某物與業(yè)務(wù)進(jìn)行交互時(shí)所擔(dān)任的角色,它是指在業(yè)務(wù)之外和業(yè)務(wù)交互的人、組織或事物。
業(yè)務(wù)工作者代表在業(yè)務(wù)中進(jìn)行操作的人、軟件或硬件的抽象。它代表業(yè)務(wù)中的一個(gè)或一組角色。
系統(tǒng)執(zhí)行者:是指與目標(biāo)系統(tǒng)交換數(shù)據(jù)的任何對(duì)象,是在系統(tǒng)之外,透過系統(tǒng)邊界與系統(tǒng)進(jìn)行有意義交互的任何事物。執(zhí)行者可以是用戶、外部硬件或其它系統(tǒng)。
關(guān)系:系統(tǒng)執(zhí)行者是針對(duì)軟件系統(tǒng)來說明的,而業(yè)務(wù)執(zhí)行者和業(yè)務(wù)工作者是針對(duì)業(yè)務(wù)來說明的,系統(tǒng)執(zhí)行者和業(yè)務(wù)執(zhí)行者含義相似,只是所在的描述范疇不一樣。
4.6 請(qǐng)分析用例中的包含關(guān)系和擴(kuò)展關(guān)系的相似與區(qū)別?
答:相似:都是如果用例包含的一段行為片段可以用于其他用例,則將這段行為片段歸到“包含用例”或“擴(kuò)展用例”中,形成一個(gè)新的用例,原始用例就成為基本用例,對(duì)“包含用例”和“擴(kuò)展用例”分別有包含關(guān)系和擴(kuò)展關(guān)系。
區(qū)別:(1)擴(kuò)展用例是可選的,而包含用例不是可選的;(2)基本用例沒有擴(kuò)展用例是可以完成的,但沒有包含用例則不能完成;(3)擴(kuò)展用例的執(zhí)行是有條件的,而包含用例沒有;(4)擴(kuò)展用例會(huì)改變基本用例的行為,而包含用例不會(huì)。
4.7 簡(jiǎn)單說明把用例組織到包中有什么好處。
答:用例包是用例、執(zhí)行者、關(guān)系、圖和其他包的集合,可以通過將用例模型分成更小的部分來結(jié)構(gòu)化用例模型。這樣可以使得具有大量元素的用例模型中的用例結(jié)構(gòu)化,同一包中的用例彼此之間都有某種關(guān)系,更加清楚明了,便于以后模型的分析和使用。
4.8 用例詳細(xì)描述中有哪三種事件流,分別表示什么場(chǎng)景?
答:三種事件流:主事件流、分支事件流和異常事件流。
主事件流:在描述正常過程時(shí)列出執(zhí)行者和系統(tǒng)之間相互交互或?qū)υ挼膭?dòng)作序列。當(dāng)這種對(duì)話結(jié)束時(shí),執(zhí)行者也達(dá)到了預(yù)期的目的。
分支事件流:也可促進(jìn)成功地完成任務(wù),但它們代表了任務(wù)的細(xì)節(jié)或用于完成任務(wù)的途徑的變化部分。
異常事件流:不符合用例流正;蚧拘袨,引起任務(wù)不能順利完成。
4.9 什么是軟件需求規(guī)約(SRS)?
答:軟件需求規(guī)約是分析任務(wù)的最終產(chǎn)物,通過建立完整的信息描述、詳細(xì)的功能和行為描述、性能需求和設(shè)計(jì)約束的說明、合適的驗(yàn)收標(biāo)準(zhǔn),給出對(duì)目標(biāo)軟件的各種需求。
4.10 如何理解界面原型在需求建模中作用?
答:可以處理模糊需求,開發(fā)者和用戶可充分通信,降低開發(fā)風(fēng)險(xiǎn)。
靜態(tài)界面原型:供分析人員與用戶進(jìn)行進(jìn)一步交流和溝通,通過這種可視化方法,使雙方逐步就明確系統(tǒng)需求達(dá)成共識(shí)。
交互式界面原型:便于用戶可以操作,展示實(shí)際系統(tǒng)效果。
4.11 選擇題
1. 如圖4.11-1所示. A1 、A2 和A3 是什么? (單選題)( C)
(a) role
(b) Actress
(c) Actor
(d) User
2. 如圖4.11-1中,下面哪個(gè)語句是正確的? (多選題) ( BCD) (a) A3 可以使用UC4 與系統(tǒng)交互。
(b) Al 可以使用UCl 和UC4 與系統(tǒng)交互。 (c) A3, Al 與A2 不同。
(d) UC3 是沒有步驟的抽象用例。
3. 如圖4.11-1 所示,下面哪個(gè)語句是正確的? (多選題)(CD ) (a) UC5 是UC4 的補(bǔ)充部分。 (b) UC4 是UC5 的可選部分。 (c) UC1 是沒有用的。
(d) UC2 是UC4 的可選部分。 (e) UC4 是UC2 的補(bǔ)充部分。
4.12 綜合案例分析-餐廳智能移動(dòng)終端無線點(diǎn)菜系統(tǒng)需求
根據(jù)第 3 章的練習(xí)3.11 綜合案例分析的業(yè)務(wù)描述,來分析點(diǎn)餐系統(tǒng)的需求。
現(xiàn)在該餐廳為了提高管理效率,避免在點(diǎn)菜過程中出現(xiàn)掉單、飛單,錯(cuò)單、舞弊等現(xiàn)象,計(jì)劃采用智能移動(dòng)終端無線點(diǎn)菜系統(tǒng)。 無線點(diǎn)菜系統(tǒng)的要求: 1. 即時(shí)點(diǎn)菜
服務(wù)員隨時(shí)隨地地使用智能掌上電腦系統(tǒng),為顧客點(diǎn)菜、加菜,系統(tǒng)自動(dòng)將數(shù)據(jù)傳到后臺(tái)和分布在廚房與前臺(tái)的打印機(jī)上。打印機(jī)立刻打印所點(diǎn)的菜單。 2. 無需布線
系統(tǒng)前臺(tái)使用無線網(wǎng)絡(luò)與掌上電腦技術(shù),使前臺(tái)使用者可以在營業(yè)大廳內(nèi)隨意走動(dòng),自由的使用系統(tǒng)為顧客服務(wù),無需在大廳中布置任何網(wǎng)絡(luò)線路,從而避免影響餐廳的整體環(huán)境。 3 操作簡(jiǎn)單
系統(tǒng)采用 B/S 結(jié)構(gòu),前臺(tái)使用智能移動(dòng)終端如智能手機(jī)、平板電腦做客戶端,所有的操作都是筆觸式和手寫輸入,操作要方便,適宜于任何服務(wù)人員http://http://m.oriental01.com/news/55840068E518E83F.html使用。 4. 超長(zhǎng)傳送
傳送距離可達(dá) 100 米,室外傳送距離可送300 米。 根據(jù)案例的描述,請(qǐng)你完成下列任務(wù):
1. 建立無線點(diǎn)菜系統(tǒng)的用例模型(找出所有的系統(tǒng) Actor 和Use Case);
用例模型
系統(tǒng)Actor:服務(wù)員、客戶、經(jīng)理
Use case:點(diǎn)菜服務(wù)、自助點(diǎn)菜、統(tǒng)計(jì)
2. 對(duì)用例進(jìn)行詳細(xì)描述,包括前置條件、后置條件,以及各事件流,并用泳道圖畫出用例對(duì)應(yīng)的事件流。 前置條件:
服務(wù)員有掌上電腦系統(tǒng),廚房與前臺(tái)有打印機(jī),在傳輸距離之內(nèi) 后置條件:
打印機(jī)打印所點(diǎn)菜單 事件流: 主事件流: 1.顧客點(diǎn)菜;
2.服務(wù)員用掌上電腦及菜單; 3.廚房和前臺(tái)打印機(jī)打印菜單 分支事件流: 無
異常事件流:
步驟2后步驟3未接收,無法打印,返回步驟
2
3).打印菜單用例描述: 用例名稱:打印菜單
用例描述:打印點(diǎn)菜內(nèi)容 參與者 :打印機(jī) 前置條件:點(diǎn)菜完成
后置條件:打印機(jī)打印菜單給后臺(tái),廚房和前臺(tái) 主事件流:1.系統(tǒng)發(fā)送點(diǎn)菜單至打印機(jī)
2.打印機(jī)接收菜單 3.打印機(jī)打印菜單 分支事件流:無 異常事件流:無 泳道圖:
Chapter5
5.1 如何理解分析與設(shè)計(jì)的聯(lián)系?
答:“分析”是指“做什么”,強(qiáng)調(diào)對(duì)問題的調(diào)研而不是如何確定解決方案,重點(diǎn)集中在需求和應(yīng)用領(lǐng)域上;而“設(shè)計(jì)”指“怎么做”,強(qiáng)調(diào)的是問題的邏輯解決方案,即系統(tǒng)怎樣才能滿足需求,重點(diǎn)轉(zhuǎn)移了要產(chǎn)生軟件的結(jié)構(gòu)上。但由于分析與設(shè)計(jì)是把用戶需求轉(zhuǎn)化為實(shí)現(xiàn)的橋梁,分析和設(shè)計(jì)自始至終可以用相同的技術(shù)和類似的表示方法,它們之間的界限很難劃清,且沒有太多意義。
5.2 分析設(shè)計(jì)包括哪些工作流程?
答:分析和設(shè)計(jì)過程是一個(gè)不斷迭代優(yōu)化的過程。
包括:執(zhí)行體系結(jié)構(gòu)合成;定義候選體系結(jié)構(gòu);優(yōu)化體系結(jié)構(gòu);分析行為;設(shè)計(jì)構(gòu)件;設(shè)計(jì)數(shù)據(jù)庫;服務(wù)識(shí)別;服務(wù)規(guī)范。
5.3 分析建模的元素分哪幾類?具體是什么? 答:分析建模的元素分為四大類,分別是: (1)基于場(chǎng)景元素:
這類元素包括:用例文本、用例圖、活動(dòng)圖和泳道圖等; (2)面向流的元素:
這類元素包括數(shù)據(jù)流圖、控制流圖、處理敘述等; (3)基于類的元素:
這類元素包括類圖、分析包、CRC模型、通信圖等; (4)行為的元素:
這類元素包括狀態(tài)圖、順序圖等。
5.4 分析模型的靜態(tài)模型的用途是什么?靜態(tài)模型的元素有哪些?
答:用途:通過分析,可以將業(yè)務(wù)需求模型和系統(tǒng)需求模型轉(zhuǎn)化為系統(tǒng)可以處理的對(duì)象模型,并給出對(duì)象的基本屬性和對(duì)象間相互關(guān)系。
分析模型中靜態(tài)模型主要的元素是基于類的元素,包括: 分析包:模型中的包,表示層次結(jié)構(gòu)。 類:模型中的類,由包所擁有。 關(guān)系:模型中的關(guān)系,由包所擁有。
圖:模型中的類圖、協(xié)作(通信)圖,由包所擁有。
5.5 動(dòng)態(tài)模型的類被分為哪三類?分別在系統(tǒng)中承擔(dān)什么職責(zé)? 答:邊界類、控制類和實(shí)體類。
邊界類:是用來對(duì)系統(tǒng)環(huán)境及其內(nèi)部工作之間的交互建模的類。這樣的交互涉及轉(zhuǎn)換和轉(zhuǎn)移事件,并注釋系統(tǒng)表示中的更改(例如界面)。
控制類:是用于對(duì)特定于一個(gè)或一些用例的控制行為建模的類。 實(shí)體類:是用來對(duì)必須存儲(chǔ)的信息及關(guān)聯(lián)行為建模的類。
5.6 按照設(shè)計(jì)模型的不同層次和功能,設(shè)計(jì)元素可以分哪些方面?
答:(1)體系結(jié)構(gòu)元素;(2)構(gòu)件級(jí)元素;(3)接口/界面元素:用戶界面、構(gòu)件接口、系統(tǒng)接口;(4)數(shù)據(jù)元素:數(shù)據(jù)庫設(shè)計(jì)、數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì);(5)部署級(jí)元素。
5.7 軟件模式有哪三個(gè)層次?分別說明之。
答:一般地,軟件模式可劃分為三個(gè)層次:體系結(jié)構(gòu)模式,設(shè)計(jì)模式和代碼模式。
體系結(jié)構(gòu)模式:描述軟件系統(tǒng)里的基本的結(jié)構(gòu)組織或綱要。體系結(jié)構(gòu)模式提供一些事先定義好的子系統(tǒng),指定它們的責(zé)任,并給出把它們組織在一起的法則和指南。
設(shè)計(jì)模型:提供一種提煉子系統(tǒng)或軟件系統(tǒng)中的構(gòu)件或者兩者之間關(guān)系的綱要設(shè)計(jì)。設(shè)計(jì)模型描述普遍存在的在相互通訊的構(gòu)件中重復(fù)出現(xiàn)的結(jié)構(gòu),這種結(jié)構(gòu)解決在一定的背景中的具有一般性的設(shè)計(jì)問題。
代碼模型:也稱“成例”、實(shí)現(xiàn)模式。是較低層次的模式,并與編程語言密切相關(guān)。代碼模型描述怎樣利用一個(gè)特定的編程語言的特點(diǎn)來實(shí)現(xiàn)一個(gè)構(gòu)件的某些特定的方面或關(guān)系。
5.8 什么是軟件體系結(jié)構(gòu)?簡(jiǎn)述軟件體系結(jié)構(gòu)的設(shè)計(jì)重要性。
答:軟件體系結(jié)構(gòu):是具有一定形式的結(jié)構(gòu)化元素,即構(gòu)件的集合,包括處理構(gòu)件、數(shù)據(jù)構(gòu)件和連接構(gòu)件。處理構(gòu)件負(fù)責(zé)對(duì)數(shù)據(jù)進(jìn)行加工,數(shù)據(jù)構(gòu)件是被加工的信息,連接構(gòu)件把體系結(jié)構(gòu)的不同部分組組合連接起來。這一定義注重區(qū)分處理構(gòu)件、數(shù)據(jù)構(gòu)件和連接構(gòu)件,這一方法在其他的定義和方法中基本上得到保持。
重要性:軟件體系結(jié)構(gòu)設(shè)計(jì)是高階層的設(shè)計(jì),定義了包(子系統(tǒng)),包括包之間的依賴關(guān)系和主要的通信機(jī)制。自然清晰和簡(jiǎn)單的結(jié)構(gòu)是目標(biāo),避免幾乎沒有依賴或雙向依賴。
5.9 試說明軟件體系結(jié)構(gòu)的演變過程。
答:(1)單機(jī)系統(tǒng):是指只需裝在一臺(tái)電腦上,同時(shí)只能一個(gè)用戶使用的系統(tǒng),沒有服務(wù)器概念,很多早期的軟件都是單機(jī)系統(tǒng),與分布式系統(tǒng)區(qū)別。
(2)客戶機(jī)/服務(wù)器(兩層)結(jié)構(gòu):由服務(wù)器提供應(yīng)用(數(shù)據(jù))服務(wù),多臺(tái)客戶機(jī)進(jìn)行連接。
(3)瀏覽器/服務(wù)器(B/S)結(jié)構(gòu):在當(dāng)前Internet/Intranet領(lǐng)域,“瀏覽器/服務(wù)器”結(jié)構(gòu)是非常流行的客戶機(jī)/服務(wù)器結(jié)構(gòu)。這種結(jié)構(gòu)最大的優(yōu)點(diǎn)是:客戶機(jī)統(tǒng)一采用瀏覽器,這不僅讓用戶使用方便,而且使得客戶機(jī)不存在安裝維護(hù)問題。
(4)三層結(jié)構(gòu):三層結(jié)構(gòu)的客戶機(jī)/服務(wù)器模型是一種先進(jìn)的協(xié)同應(yīng)用程序開發(fā)模型,不是物理上,而是邏輯上將客戶機(jī)/服務(wù)器系統(tǒng)中各種各樣的部件劃分為三“層”服務(wù),它們共同組成一個(gè)應(yīng)用程序,這三層服務(wù)包括:數(shù)據(jù)訪問層、業(yè)務(wù)邏輯層和表示層。
5.10 如何理解體系結(jié)構(gòu)風(fēng)格和模式的本質(zhì)?
答:體系結(jié)構(gòu)風(fēng)格:定義了結(jié)構(gòu)組織模式的系統(tǒng)族,用來表達(dá)一組協(xié)作的約束,使得對(duì)公共約束的特征進(jìn)行溝通變得更加容易,被用作一種進(jìn)行抽象的方法,而不是代表一種個(gè)性化的設(shè)計(jì)。
體系結(jié)構(gòu)模式:是對(duì)某類問題域給出的一套軟件結(jié)構(gòu)的解決方案,描述了軟件系統(tǒng)基本的結(jié)構(gòu)化組織方案,是處理特定問題的高效、成熟的模板。
5.11 什么是軟件框架?與模式的區(qū)別是什么?
答:軟件框架:軟件開發(fā)過程中提取特定領(lǐng)域軟件的共性部分形成的體系結(jié)構(gòu),不同領(lǐng)域的軟件項(xiàng)目有著不同的框架模型。
區(qū)別:模式提供一種思想方法的指導(dǎo),應(yīng)用模式的指導(dǎo),可以幫助設(shè)計(jì)人員做出一個(gè)優(yōu)良的設(shè)計(jì)方案,達(dá)到事半功倍的效果。但模式不體現(xiàn)為程序,如MVC是一種體系結(jié)構(gòu)的模式,對(duì)于同一軟件體系結(jié)構(gòu),可以通過多種框架來實(shí)現(xiàn)。如Struts是實(shí)現(xiàn)MVC模式的著名框架,但不是唯一的。
5.12 RUP 的4+1 視圖分別是什么? 答:概括而言,RUP的4+1視圖是: (1)邏輯視圖:設(shè)計(jì)的對(duì)象模型。
(2)進(jìn)程視圖:捕捉設(shè)計(jì)的并發(fā)和同步特征。
(3)實(shí)現(xiàn)視圖:描述了在開發(fā)環(huán)境中軟件的靜態(tài)組織結(jié)構(gòu)。
(4)部署視圖:描述了軟件到硬件的映射,反映了分布式特征。
(5)用例視圖:該視圖是其他視圖的冗余(因此“+1”)。它包含用例和場(chǎng)景。
5.13 什么是設(shè)計(jì)模式?
答:設(shè)計(jì)模式:是一套被反復(fù)使用、多數(shù)人知曉的、經(jīng)過分類編目的、代碼設(shè)計(jì)經(jīng)驗(yàn)的總結(jié)。使用設(shè)計(jì)模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問,設(shè)計(jì)模式于己于他人于系統(tǒng)都是多贏的,設(shè)計(jì)模式使代碼編制真正工程化,設(shè)計(jì)模式是軟件工程的基石,如同大廈的一塊塊磚石一樣。
5.14 簡(jiǎn)要說明類的詳細(xì)設(shè)計(jì)分哪幾步來實(shí)現(xiàn)?
答:(1)使用設(shè)計(jì)模式和機(jī)制:使用適合設(shè)計(jì)的類或功能、符合項(xiàng)目設(shè)計(jì)指南的設(shè)計(jì)模式和機(jī)制。
(2)創(chuàng)建初始設(shè)計(jì)類:為指定為此任務(wù)輸入的分析類創(chuàng)建一個(gè)或多個(gè)初始設(shè)計(jì)類,并指定跟蹤依賴關(guān)系。包括設(shè)計(jì)邊界類、設(shè)計(jì)實(shí)體類和設(shè)計(jì)控制類。
(3)定義屬性:類的屬性為類實(shí)例提供信息存儲(chǔ),并經(jīng)常用于代表類實(shí)例的狀態(tài)。類本身保持的任何信息都是通過其屬性完成的。
(4)確定持久類:需要在永久介質(zhì)上存儲(chǔ)其狀態(tài)的類被稱為持久類。
(5)定義操作:類的操作是類的行為特征或動(dòng)態(tài)特征,表示類提供的服務(wù)。 (6)定義方法:方法制定操作的實(shí)現(xiàn)。
(7)定義狀態(tài):對(duì)于一些操作,操作的行為取決于接受者對(duì)象所處的狀態(tài)。
5.15 什么是實(shí)體類與持久類?說說兩者之間區(qū)別與聯(lián)系。
答:實(shí)體類:在分析期間,代表被操縱的信息單元。它們往往是被動(dòng)的、持久的,并且可能被確定并與持久性分析機(jī)制相關(guān)聯(lián)。
持久類:需要在永久介質(zhì)上存儲(chǔ)其狀態(tài)的類。
區(qū)別和聯(lián)系:持久類是針對(duì)于hibernate對(duì)數(shù)據(jù)庫的映射來說的,持久類=實(shí)體類+xml或注解配置;而實(shí)體類就是一個(gè)javabean類,有屬性,get、set方法,以及一些簡(jiǎn)單處理的方法。
5.16 開發(fā)物理數(shù)據(jù)庫設(shè)計(jì)的詳細(xì)步驟有哪些?
答:(1)定義域;(2)創(chuàng)建初始物理數(shù)據(jù)庫設(shè)計(jì)元素;(3)定義引用表;(4)創(chuàng)建主鍵和唯一性約束;(5)定義數(shù)據(jù)和參照完整性實(shí)現(xiàn)規(guī)則;(6)將數(shù)據(jù)庫設(shè)計(jì)反向規(guī)范化來為性能進(jìn)行優(yōu)化;(7)優(yōu)化數(shù)據(jù)訪問;(8)定義存儲(chǔ)器特征;(9)設(shè)計(jì)存儲(chǔ)過程來將類行為分發(fā)給數(shù)據(jù)庫。
5.17 進(jìn)行界面設(shè)計(jì)時(shí)分析用戶的特征有什么作用?
答:描述某些(人類)用戶的特征,這些用戶將與系統(tǒng)交互來執(zhí)行當(dāng)前迭代中考慮的需求。要重點(diǎn)描述主要用戶,因?yàn)榻换サ拇蟛糠稚婕斑@些用戶。該信息對(duì)于下面的后續(xù)步驟很重
要。
與系統(tǒng)分析人員協(xié)作,確定是否需要對(duì)用戶(主要的執(zhí)行者)描述做出更改,來反映特征描述。
5.18 選擇題
1. 如圖5.18-1 所示.A 、B 和C 是什么對(duì)象? (單選題)(D) (a) A 是實(shí)體.B 是控制.C 是邊界 (b) A 是邊界.B 是實(shí)體.C 是控制 (c) A 是實(shí)體,B 是邊界, C 是控制 (d) A 是控制,B 是實(shí)體.C 是邊界 (e) A 是邊界.B 是控制,C 是實(shí)體 (f) A 是控制,B 是邊界.C 是實(shí)體
2. 在UML圖中,哪個(gè)圖用于顯示在對(duì)象之間傳送的消息? (多選題)( CE) (a) 活動(dòng)圖 (b) 對(duì)象圖 (c) 通信圖 (d) 狀態(tài)機(jī)圖 (e) 順序圖 (f) 部署圖
3. 下面不是設(shè)計(jì)模型相關(guān)的?(單選題)( D) (a)architecture (b) data
(c) interfaces (d) project scope
5.19 綜合案例分析-餐廳PDA 無線點(diǎn)菜系統(tǒng)分析與設(shè)計(jì)
根據(jù)第 4 章餐廳PDA 無線點(diǎn)菜系統(tǒng)的需求,請(qǐng)分析設(shè)計(jì)相關(guān)系統(tǒng)。包括 1. 找出主要的概念實(shí)體,畫出實(shí)體類圖。
2. 畫出系統(tǒng)分析動(dòng)態(tài)模型中的順序圖(要體現(xiàn)邊界類、控制類和實(shí)體類之間通信內(nèi)容)。 3. 從上面的順序圖中解析出實(shí)體類的操作,畫出初步的設(shè)計(jì)類圖。 4. 選擇B/S結(jié)構(gòu),為系統(tǒng)設(shè)計(jì)相應(yīng)的界面。 5. 設(shè)計(jì)相應(yīng)的數(shù)據(jù)庫表結(jié)構(gòu)
答:1.主要的概念實(shí)體:客人,點(diǎn)菜單,點(diǎn)菜記錄,打印機(jī),服務(wù)員,菜品分類
實(shí)體類圖:
2.
3.實(shí)體類操作:1)客人: 輸入已點(diǎn)菜品()
2)點(diǎn)菜記錄:記錄已點(diǎn)菜品();確認(rèn)點(diǎn)菜記錄();發(fā)送點(diǎn)菜記錄() 3)打印機(jī):打印點(diǎn)菜記錄()
類圖:
4.界面:
5.數(shù)據(jù)庫表結(jié)構(gòu):
2013.01.05
【軟件工程導(dǎo)論作業(yè)】相關(guān)文章:
軟件工程導(dǎo)論課程教學(xué)改革的探討07-29
軟件工程導(dǎo)論課程中同伴教學(xué)法的應(yīng)用的論文10-10
軟件工程導(dǎo)論課程中同伴教學(xué)法的應(yīng)用論文06-19
《現(xiàn)代教師學(xué)導(dǎo)論》形成性考核冊(cè)作業(yè)3答案01-13
電氣導(dǎo)論論文09-05
旅游美育導(dǎo)論01-20
護(hù)理教育導(dǎo)論07-06