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