山東大學(xué)軟件學(xué)院軟件需求分析與設(shè)計(jì)復(fù)習(xí)題答案

1、以下內(nèi)容是曲文博同學(xué)整理提供！在此深表感謝！、基本概念1. OOA/OOD : 面向?qū)ο蠓治龇椒?Object-Oriented Analysis ，OOA)，是確定需求或者業(yè)務(wù)的角度，按照面向?qū)ο蟮乃枷雭矸治鰳I(yè)務(wù)。是在一個(gè)系統(tǒng)的開發(fā)過程中進(jìn)行了系統(tǒng)業(yè)務(wù)調(diào)查以后，按照面向?qū)ο蟮乃枷雭矸治鰡栴}。OOA所強(qiáng)調(diào)的是在系統(tǒng)調(diào)查資料的基礎(chǔ)上，針對(duì)OO方法所需要的素材進(jìn)行的歸類分析和整理，而不是對(duì)管理業(yè)務(wù)現(xiàn)狀和方法的分析。面向?qū)ο笤O(shè)計(jì)(Object-Oriented Design，OOD )方法是OO方法中一個(gè)中間過渡環(huán)節(jié)。其主要作用是對(duì) OOA分析的結(jié)果作進(jìn)一步的規(guī)范化整理，以便能夠被OOP直接接受。是

2、一種解決軟件問題的設(shè)計(jì)范式( paradigm )，一種抽象的范式。2. 迭代開發(fā)：是統(tǒng)一開發(fā)過程的關(guān)鍵實(shí)踐開發(fā)被組織成一系列固定的短期小項(xiàng)目I每次迭代都產(chǎn)生經(jīng)過測試、集成并可執(zhí)行的局部系統(tǒng)每次迭代都具有各自的需求分析、設(shè)計(jì)、實(shí)現(xiàn)和測試隨著時(shí)間和一次次迭代，系統(tǒng)增量式完善I反饋和調(diào)整使規(guī)格說明和設(shè)計(jì)不斷進(jìn)化。如果問到特征，就寫下面的，沒問就不用寫。迭代式開發(fā)特征：1、在進(jìn)行大規(guī)模的投資之前就解決了關(guān)鍵的風(fēng)險(xiǎn)分析。2、使得早期的用戶反饋在初始迭代中就能出現(xiàn)。3、 對(duì)各個(gè)目標(biāo)里程碑提供了短期的焦點(diǎn)(階段性的中心)。4、對(duì)過程的測量是通過對(duì)實(shí)現(xiàn)的評(píng)定(而不僅僅是文檔)來進(jìn)行的?？梢詫?duì)局部的實(shí)現(xiàn)進(jìn)行部

3、署。3. UP:UP( Unified Process )是軟件工程的過程，是一種指導(dǎo)軟件開發(fā)活動(dòng)的方法。提供了 在開發(fā)組織中分派任務(wù)和責(zé)任的紀(jì)律化方法。它的目標(biāo)是在可預(yù)見的日程和預(yù)算前提 下，確保滿足最終用戶需求的高質(zhì)量產(chǎn)品。統(tǒng)一過程模型是一種“用例驅(qū)動(dòng)，以體系結(jié) 構(gòu)為核心，迭代及增量”的軟件過程框架，由UML方法和工具支持。如果問到RUP，就寫下面的，沒問就不用寫。RUP ( Rational Unified Process )，是對(duì)統(tǒng)一過程的詳細(xì)細(xì)化。4. FURPS+ :是指功能(function )、易用性(usability )、可靠度(reliability )、性能(perfo

4、rmanee )、可支持性(supportability)以及輔助性和次要因素，它是一種識(shí)別軟件質(zhì)量屬性的模型也可以說是需求的類型。以下是詳細(xì)的回答。- 功能性(Functional )特性、功能、安全性-可用性(Usability ):人性化因素、幫助、文檔- 可靠性(Reliability ):故障頻率、可恢復(fù)性、可預(yù)測性- 性能(Performanee ):響應(yīng)時(shí)間、吞吐量、準(zhǔn)確性、有效性、資源利用率- 可支持性(Supportablity ):適應(yīng)性、可維護(hù)性、國際化、可配置性-+:輔助性和次要因素- 實(shí)現(xiàn)(implementation):資源限制、語言和工具、硬件等- 接口( In

5、terface ):強(qiáng)加于外部系統(tǒng)接口之上的約束-操作(operation):對(duì)其操作設(shè)置的系統(tǒng)管理- 包裝(Packaging ):物理包裝盒-授權(quán)(Legal )許可證或其他方式5. 用例：就是一組相關(guān)的成功和失敗場景集合，用來描述參與者如何使用系統(tǒng)來實(shí)現(xiàn)目標(biāo)。6. 敏捷建模：敏捷建模(Agile Modeling , AM)是一種基于實(shí)踐的軟件過程，它的范圍包括描述如何 建模以及以一種高效而敏捷的方式編寫文檔。理想情況下，AM的實(shí)踐應(yīng)該用來促進(jìn)其它更完整的軟件過程。7. 領(lǐng)域模型：是對(duì)領(lǐng)域內(nèi)的概念類或現(xiàn)實(shí)世界中對(duì)象的可視化表示，也稱概念模型、領(lǐng)域?qū)ο竽Ｐ秃头治鰧?duì)象模型，是領(lǐng)域概念的可視化

6、，類似于領(lǐng)域?qū)嶓w的靜態(tài)信息模型。在UP中，是對(duì)現(xiàn)實(shí)世界概念類的表示，而非軟件對(duì)象的表示，該術(shù)語并不是指用來描述軟件類、軟件構(gòu)架類領(lǐng)域?qū)踊蛴新氊?zé)軟件對(duì)象的一組圖。UP領(lǐng)域模型是UP業(yè)務(wù)對(duì)象模型的特化，專注于特定領(lǐng)域，領(lǐng)域模型主要是在特定群體中用于理解和溝通的工具。有效的領(lǐng)域模 型捕獲了當(dāng)前需求語境下的本質(zhì)抽象和理解領(lǐng)域所需要的信息，并且可以幫助人們理解領(lǐng)域的概念、術(shù)語和關(guān)系。8. 設(shè)計(jì)模式：模式是對(duì)問題和解決方案的已命名描述，它可以用于新的語境，為在變化環(huán)境中如何運(yùn) 用和權(quán)衡其解決方案給出建議，好的模式是成對(duì)的問題/解決方案，并且具有廣為人知的名稱。9. GRASP通用職責(zé)分配軟件模式(Gene

7、ral Respo nsibility Assig nment Software Patterns.)是一種基于職責(zé)的設(shè)計(jì)，GRASP原則或模式包括：-、創(chuàng)建者(Creator )、控制器(Cotroller )、 純虛構(gòu)(Pure Fabricati on )、信息專家(In formation Expert)、高內(nèi)聚(High Cohesion )、間接性(In direction )、低耦合(Low Coupli ng)、多態(tài)性(Polymorphism )、防止變異(Protected Variations)。10. SAD文檔描述有關(guān)架構(gòu)的總體想法，包含架構(gòu)分析的關(guān)鍵決策，可以幫助開

8、發(fā)人員理解系統(tǒng)的基 本概念。二、 寶自迭代曲豆4 ，世界是由對(duì)象構(gòu)成的i(1 )您如何看待面向?qū)ο蟮姆治?、設(shè)計(jì)和實(shí)現(xiàn)。氏OO ( Object-briented-面向?qū)ο?方法基于的“世界觀象有其自己的屬性和內(nèi)部運(yùn)動(dòng)規(guī)律，對(duì)象之間的相互作用，構(gòu)成了大千世界的各式 的不同系統(tǒng)。I：;面向?qū)ο蠓椒ǖ慕鉀Q問題的思路是從現(xiàn)實(shí)世界中的客觀對(duì)象 正6+卡的自然思維方式來構(gòu)造軟件系統(tǒng)。對(duì)象(object)+ 分類(classfication+ -繼承Mnheritance)+ 通過消息(message)入手，盡量運(yùn)用人類的自然思維方式來構(gòu)造軟件系牛.11 I fej 片-(如人和事物)面向?qū)Φ耐ㄐ拧終集戚

9、(2 )說明迭代和進(jìn)化式開發(fā)過程式中的一些弱被組織為一系列的短是一種與傳統(tǒng)的瀑布式開發(fā)木皈的軟件開發(fā)過程，它彌補(bǔ)了傳統(tǒng)開發(fā)方式中的一些弱 點(diǎn)，具有更高的成功率和生產(chǎn)率。在迭代式開發(fā)方法中，整個(gè)開發(fā)工作被組織為一系列的短 ，”一亠 一3周)的小項(xiàng)目，被稱為一系列的迭代。每一次迭代都包括了定義、 實(shí)現(xiàn)與測試。采用這種方法，開發(fā)工作可以在需求被完整地確定之前啟動(dòng)， 再通過客丿戶的反饋來細(xì)化4小的、固定長度(如需求分析、設(shè)計(jì)、 , 并在一次迭代中完成系統(tǒng)的一部分功育能或業(yè)務(wù)邏輯的開發(fā)工作。 求，并開始新一輪的迭代。”在一個(gè)廿問區(qū)問內(nèi) |次迭(3) 統(tǒng)一過程UP的階段有哪些，每一階段的工作和目標(biāo)是什么。

10、統(tǒng)一過程UP有四個(gè)階段：初始階段、細(xì)化階段、構(gòu)造階段、移交階段。初始：大體上的構(gòu)想，業(yè)務(wù)案例，范圍和模糊評(píng)估，主要目的是建立項(xiàng)目的范圍和 版本，確定項(xiàng)目目標(biāo)的可行性和穩(wěn)定性 ，制品包括需求和用例。細(xì)化：已精化的構(gòu)想，核心架構(gòu)的迭代實(shí)現(xiàn)，高風(fēng)險(xiǎn)的解決，確定大多數(shù)需求的范 圍以及進(jìn)行更為實(shí)際的評(píng)估， 該階段的目的是對(duì)問題域進(jìn)行分析，精細(xì)化需求和開始架構(gòu)設(shè)計(jì)，確定實(shí)現(xiàn)的可行性和穩(wěn)定性，制品包括系統(tǒng)架構(gòu)，問題領(lǐng)域、精化后的需求及設(shè)計(jì) 等相關(guān)文檔。構(gòu)造： 對(duì)遺留下來的風(fēng)險(xiǎn)較低和比較簡單的元素進(jìn)行迭代和實(shí)現(xiàn)，準(zhǔn)備部署。制 品包括精化的設(shè)計(jì)等相關(guān)文檔。移交：進(jìn)行Beta測試和部署。(4) 說明統(tǒng)一過程 UP

11、中業(yè)務(wù)建模科目需要完成的工作，涉及的所有制品的名稱和作用。 業(yè)務(wù)建模(business Modeling )，其用途是理解和溝通將要部署系統(tǒng)的組織結(jié)構(gòu)和 動(dòng)態(tài)特征”，通過敏捷建模和需求討論會(huì)的實(shí)踐，完成領(lǐng)域模型。領(lǐng)域模型是對(duì)所關(guān)注的現(xiàn)實(shí)世界領(lǐng)域中事物的可視化，是領(lǐng)域概念的可視化， 類似于領(lǐng)域?qū)嶓w的靜態(tài)信息模型。領(lǐng)域模型的作用主要是在特定群體中用于理解和溝通的工具； 捕獲當(dāng)前需求語境下的本質(zhì)抽象和理解領(lǐng)域所需要的信息，并且可以幫助人們理解領(lǐng)域的概念、術(shù)語和關(guān)系；將那些與當(dāng)前需求無關(guān)的概念類排除在問題域之外。(5) 說明統(tǒng)一過程 UP中需求科目需要完成的工作，涉及的所有制品的名稱和作用。需求科目需

12、要完成需求討論會(huì)、設(shè)想包裝練習(xí)、計(jì)點(diǎn)投票表決工作，產(chǎn)出用例模型、設(shè)想、補(bǔ)充性規(guī)格說明與詞匯表等制品。用例模型，用來描述功能需求。補(bǔ)充性規(guī)格說明，捕獲用例或詞匯表難以描述的其他需求、信息和約束，如報(bào)表，文檔、包裝可支持性、許可授權(quán)。設(shè)想，概述了對(duì)項(xiàng)目的“設(shè)想”。即執(zhí)行摘要。為項(xiàng)目主要思想提供簡潔描述。詞匯表，捕獲術(shù)語和定義，也可起到數(shù)據(jù)字典的作用。(6 )說明統(tǒng)一過程 UP 中設(shè)計(jì)科目需要完成的工作，涉及的所有制品的名稱和作用。 敏捷建?？颇啃枰ㄟ^完成敏捷建模、測試驅(qū)動(dòng)開發(fā)來產(chǎn)出設(shè)計(jì)模型、軟件架構(gòu)文檔、 數(shù)據(jù)模型。設(shè)計(jì)模型，描述邏輯設(shè)計(jì)的一組圖，包括軟件類圖、對(duì)象交互圖、包圖等。軟件架構(gòu)文檔，

13、 學(xué)習(xí)輔助工具， 概括關(guān)鍵架構(gòu)問題及其在設(shè)計(jì)中的解決方案。 該文檔是 對(duì)重要設(shè)計(jì)思想及其在系統(tǒng)中動(dòng)機(jī)的概要。數(shù)據(jù)模型，包括數(shù)據(jù)庫方案，以及在對(duì)象和非對(duì)象表示之間的映射的策略。(7 )系統(tǒng)的用例模型包括哪些內(nèi)容，如何確定系統(tǒng)的用例？用例之間的關(guān)系有哪幾種？請(qǐng) 說明用例編寫的規(guī)則。用例模型包括：用例圖 (Use Case Diagram) 、用例規(guī)約 (Use Case Specification) 兩部分內(nèi)容，主 要由參與者 (Actor) 、用例 (Use Case) 、通訊關(guān)聯(lián) (Communication Association) 等模型元素構(gòu)成。用例確定：選擇系統(tǒng)邊界， 確定主要參與者，

14、 確定每個(gè)參與者的目標(biāo)， 定義滿足用戶目標(biāo)的用 例，根據(jù)其目標(biāo)對(duì)用例進(jìn)行命名。用例之間的關(guān)系：包含 (include) 、擴(kuò)展 (extend) 和泛化 (generalization) 。編寫規(guī)則如下：1. 以無用戶界面約束的本質(zhì)風(fēng)格編寫用例，以本質(zhì)風(fēng)格編寫用例；剔除用戶界面 并且關(guān)注參與者的意圖2. 編寫簡潔的用例3. 編寫黑盒用例，不對(duì)系統(tǒng)內(nèi)部工作、構(gòu)件或設(shè)計(jì)進(jìn)行描述，通過職責(zé)來描述系 統(tǒng)，描述做什么，不描述如何做。4. 采用參與者與參與者目標(biāo)的視點(diǎn)，關(guān)注系統(tǒng)的用戶或參與者來編寫需求，詢問 其目標(biāo)和典型情況并關(guān)注理解參與者所考慮的有價(jià)值結(jié)果5. 尋找主要參與者和目標(biāo)6. 用例名稱應(yīng)使用動(dòng)

15、詞開頭(8 )什么是領(lǐng)域模型？為什么要?jiǎng)?chuàng)建領(lǐng)域模型？如何創(chuàng)建領(lǐng)域模型？舉例說明其中每一步 的做法?！邦I(lǐng)域模型” 含義：1. 在 UP 及本課中， “領(lǐng)域模型”是現(xiàn)實(shí)世界中對(duì)象的概念透視圖，而非軟件透 視圖。2. “軟件對(duì)象的領(lǐng)域?qū)印?：在表示層或 UI 層之下的軟件對(duì)象層是由領(lǐng)域?qū)ο? domain object )組成的領(lǐng)域?qū)ο笫潜硎締栴}空間事物 的軟件對(duì)象與“業(yè)務(wù)邏輯”或“領(lǐng)域邏輯”方法相關(guān)。領(lǐng)域模型的作用：主要是在特定群體中用于理解和溝通的工具； 捕獲當(dāng)前需求語境下的本質(zhì)抽象和理 解領(lǐng)域所需要的信息， 并且可以幫助人們理解領(lǐng)域的概念、 術(shù)語和關(guān)系； 將那些與 當(dāng)前需求無關(guān)的概念類排除在問

16、題域之外。如何創(chuàng)建領(lǐng)域模型-尋找概念類? 重用和修改現(xiàn)有的模型? 使用分類列表? 確定名詞短語-將其繪制為UML類圖中的類-添加關(guān)聯(lián)和屬性(9) 什么是系統(tǒng)順序圖？說明為什么使用系統(tǒng)順序圖。 系統(tǒng)順序圖和用例之間 的關(guān)系是 什么？系統(tǒng)順序圖 SSD 展示了直接與系統(tǒng)交互的外部參與者、系統(tǒng)(作為黑盒)以及由參 與者發(fā)起的系統(tǒng)事件，時(shí)間順序是自上而下的，并且事件的順序應(yīng)該遵循其在場景 中的順序。表示了對(duì)于用例的一個(gè)特定場景，外部參與者產(chǎn)生的事件，其順序和系 統(tǒng)之內(nèi)的事件，它是用例模型的一部分將用例場景中的交互可視化。是為闡述與所討論系統(tǒng)相關(guān)的輸入和輸出事件而快速、簡單地創(chuàng)建的制品。 確定系統(tǒng)操作消

17、 息，它是合作對(duì)象交互圖中的開始消息。（10）什么是邏輯架構(gòu)和層，請(qǐng)說明使用層的好處。給出一個(gè)比較常見的軟件分層邏輯結(jié) 構(gòu)。邏輯架構(gòu)是軟件類的宏觀組織結(jié)構(gòu)，他將軟件類組織為包（命名空間）、子系統(tǒng)和層,沒有決定如何在不同的操作系統(tǒng)或網(wǎng)絡(luò)層中物理的計(jì)算機(jī)上對(duì)這些元素進(jìn)行部署。層是對(duì)類、包或子系統(tǒng)的甚為粗粒度的分組，具有對(duì)系統(tǒng)主要方面加以內(nèi)聚的職責(zé)嚴(yán)格的分層，高層可以調(diào)用相鄰較底層的服務(wù)。寬松的分層架構(gòu)，較高層可以調(diào)用其下任何層的服務(wù)。00系統(tǒng)中通常包括的層有：1. 用戶界面2. 應(yīng)用邏輯和領(lǐng)域?qū)ο?表示領(lǐng)域概念的軟件對(duì)象,（例如軟件類Sale ）,這些對(duì)象實(shí)現(xiàn)了應(yīng)用需求，例如計(jì)算銷售總額；3. 技

18、術(shù)服務(wù)-提供支持技術(shù)服務(wù)的常用對(duì)象和子系統(tǒng)，例如數(shù)據(jù)庫接口或錯(cuò)誤日志。這些服務(wù)通常是獨(dú)立于應(yīng)用的，也可在多個(gè)系統(tǒng)中復(fù)用。（11 ）架構(gòu)中的領(lǐng)域?qū)雍皖I(lǐng)域模型之間的關(guān)系是什么？領(lǐng)域模型描述了軟件架構(gòu)的領(lǐng)域?qū)榆浖I(lǐng)域?qū)ο蟮拿Q和屬性。“領(lǐng)域模型”：現(xiàn)實(shí)世界中對(duì)象的概念透視圖?！邦I(lǐng)域?qū)印保涸诒硎緦踊騏I層之下的軟件對(duì)象層。有時(shí)間的話畫下圖：（12 ）系統(tǒng)順序圖、系統(tǒng)操作和三層架構(gòu)中的層之間的聯(lián)系是什么?領(lǐng)域?qū)雍皖I(lǐng)域模型的關(guān)系領(lǐng)域模型中是 概念，但在設(shè)計(jì)模型中的 Pavinent是軟件類。它們不是一回事.但前者 啟發(fā)了后者的名稱和定義,涉眾對(duì)wISll念的看法Payment：?amcwurrtSale這

19、減少了表示差異這是對(duì).象技術(shù)的主要思想 之一datetimeW-其名稱SalePaymentPays-fordate: Date startlime: Time二 amounit: MoneyJ”gctBaUnce (): Moneygenoial ()： Moneyup設(shè)計(jì)模型中架拘的領(lǐng)域?qū)用嫦驅(qū)ο箝_發(fā)者在創(chuàng)建軟件類時(shí)9a)b)c)d)e)系統(tǒng)順序圖（SSD）中確定系統(tǒng)操作，它描述了系統(tǒng)操作。系統(tǒng)順序圖（SSD）展示了系統(tǒng)事件，系統(tǒng)操作用于處理輸入的系統(tǒng)事件。捕獲這些系統(tǒng)操作請(qǐng)求的對(duì)象通常是系統(tǒng)UI層的對(duì)象UI層對(duì)象將從UI層向領(lǐng)域?qū)愚D(zhuǎn)發(fā)（或委派）請(qǐng)求以進(jìn)行處理從UI層發(fā)送到領(lǐng)域?qū)拥南⑹?/p>

20、系統(tǒng)順序圖（SSD）中所描述的消息，例如en terltem.（13 ）說明模型一視圖分離原則。為什么將模型與視圖進(jìn)行分離? 原則：-不要將非UI對(duì)象直接與UI對(duì)象連接或耦合UI對(duì)象與某個(gè)應(yīng)用相關(guān)，而（理想情況下）非UI對(duì)象可以在新應(yīng)用中重用或附加到新界面。-不要在UI對(duì)象方法中加入應(yīng)用邏輯UI對(duì)象應(yīng)該只初始化 UI元素、接收UI事件、將應(yīng)用邏輯的請(qǐng)求委派到非UI對(duì)象-MVC中模型對(duì)象不應(yīng)直接與視圖對(duì)象連接-觀察者模式領(lǐng)域?qū)ο笾荒芡ㄟ^ propertylistener的接口向視圖的 UI對(duì)象發(fā)送消息動(dòng)機(jī)：-支持內(nèi)聚的模型定義，這些定義只關(guān)注領(lǐng)域過程，而不是用戶界面-允許對(duì)模型和用戶界面層分別進(jìn)

21、行開發(fā)-使界面的需求變更對(duì)領(lǐng)域?qū)拥挠绊懽钚』?允許新視圖能夠方便地連接到現(xiàn)有的領(lǐng)域?qū)又?，而不?huì)對(duì)領(lǐng)域?qū)赢a(chǎn)生影響-允許對(duì)同一模型對(duì)象同時(shí)使用多個(gè)視圖-允許模型層的運(yùn)行不依賴于用戶界面-允許模型層能夠簡單地移植到另一用戶界面（14 ）在對(duì)象設(shè)計(jì)中如何理解軟件對(duì)象的職責(zé)，職責(zé)驅(qū)動(dòng)設(shè)計(jì)的基本思想是什么。軟件對(duì)象的職責(zé)：由于軟件領(lǐng)域中對(duì)象根據(jù)不同場景可以扮演不同角色，對(duì)象的方法可以看成這些角色不同職責(zé)的表現(xiàn)。職責(zé)驅(qū)動(dòng)方式：?把軟件對(duì)象想象成為具有某種職責(zé)的人，它要與其他人協(xié)作以完成職責(zé)?職責(zé)定義為“類元”的契約和責(zé)任?職責(zé)主要分為兩種類型：|-行為職責(zé)?自身執(zhí)行一些行為，如創(chuàng)建對(duì)象或計(jì)算? 初始化其他

22、對(duì)象中的動(dòng)作? 控制和協(xié)調(diào)其他對(duì)象中的活動(dòng)-認(rèn)知職責(zé)? 對(duì)私有封裝數(shù)據(jù)的認(rèn)識(shí)? 對(duì)相關(guān)對(duì)象的認(rèn)知? 對(duì)其能夠?qū)С龌蛴?jì)算的事物的認(rèn)知?在對(duì)象設(shè)計(jì)中，職責(zé)是被分配給對(duì)象類的-例如“一個(gè)負(fù)責(zé)產(chǎn)生一個(gè)SalesLineltem 類”（一個(gè)行為型職責(zé)）;又如，“一個(gè)Sale類知道sale對(duì)象的total ”（一個(gè)認(rèn)知型職責(zé)）?準(zhǔn)則：對(duì)于軟件領(lǐng)域?qū)ο髞碚f，由于描述了領(lǐng)域?qū)ο蟮膶傩院完P(guān)聯(lián)。因此其 通常能夠從領(lǐng)域模型中產(chǎn)生與認(rèn)知型相關(guān)的職責(zé)。-例：如果領(lǐng)域模型中的 Sale類具有time屬性，由此可知道軟件的 Sale類應(yīng)該知道其產(chǎn)生的時(shí)間。（15 ）談?wù)勀鷮?duì)架構(gòu)的理解，SAD文檔的結(jié)構(gòu)。? 架構(gòu)的理解架構(gòu)是

23、一組重要決策，涉及軟件系統(tǒng)的組織，對(duì)結(jié)構(gòu)元素及其組成系統(tǒng)所用接口 的選擇，從這些結(jié)構(gòu)和行為元素到規(guī)模更大的子系統(tǒng)的組成，以及指導(dǎo)該組織結(jié) 構(gòu)的架構(gòu)風(fēng)格。共同主題涉及動(dòng)機(jī)、約束、模式、職責(zé)和系統(tǒng)連接。? 軟件架構(gòu)文檔 SAD文檔的結(jié)構(gòu)：架構(gòu)表示（概括介紹文檔中如何描述架構(gòu)，例如：使用技術(shù)備忘錄和架構(gòu)視圖，對(duì)于技術(shù)備忘錄或視圖不熟悉的人有用，注意并非所有視圖都是必要的架構(gòu)因素（參考補(bǔ)充性規(guī)格說明）架構(gòu)決策（概括決策的一組技術(shù)備忘錄）邏輯視圖（主要元素的UML包圖和類圖，對(duì)主要構(gòu)件的大尺度結(jié)構(gòu)和功能的解說）部署視圖（UML部署圖顯示了節(jié)點(diǎn)以及進(jìn)程和構(gòu)件的分配。有關(guān)網(wǎng)絡(luò)的注解）進(jìn)程視圖（解釋系統(tǒng)進(jìn)程和

24、線程的UML類圖和交互圖，基于交互的線程和進(jìn)程對(duì)此進(jìn)行組織，有關(guān)進(jìn)程間的通訊如何工作的解釋）用例視圖（簡要概括了構(gòu)架上最重要的用例，某些構(gòu)架上重要的用例實(shí)現(xiàn)或場景的 UML交互圖，以及在圖中解釋如何描述主要構(gòu)架元素的注釋） 其他視圖（16 ）請(qǐng)談?wù)劶軜?gòu)設(shè)計(jì)中一般要考慮的架構(gòu)因素以及架構(gòu)設(shè)計(jì)文檔主要內(nèi)容。架構(gòu)因素：組織因素、過程因素與參與開發(fā)人員因素、技術(shù)因素。（來自互聯(lián)網(wǎng)的答案，沒找到ppt中提到的參見33.6節(jié)補(bǔ)充規(guī)格說明書中重要架構(gòu)需求的因素表）架構(gòu)設(shè)計(jì)文檔主要內(nèi)容：描述有關(guān)架構(gòu)的總體想法、架構(gòu)分析的關(guān)鍵決策與系統(tǒng)的基本概念。基于N+1視圖模型創(chuàng)建?N+1（ 4 + 1 ）視圖模型-邏輯-

25、進(jìn)程-部署-數(shù)據(jù)（“+ 1 ”）用例視圖包括以下結(jié)構(gòu)：架構(gòu)表示（概括介紹文檔中如何描述架構(gòu)，例如：使用技術(shù)備忘錄和架構(gòu)視圖，對(duì)于技術(shù)備忘錄或視圖不熟悉的人有用，注意并非所有視圖都是必要的架構(gòu)因素（參考補(bǔ)充性規(guī)格說明）架構(gòu)決策（概括決策的一組技術(shù)備忘錄）邏輯視圖（主要元素的UML包圖和類圖，對(duì)主要構(gòu)件的大尺度結(jié)構(gòu)和功能的解說）部署視圖（UML部署圖顯示了節(jié)點(diǎn)以及進(jìn)程和構(gòu)件的分配。有關(guān)網(wǎng)絡(luò)的注解）進(jìn)程視圖（解釋系統(tǒng)進(jìn)程和線程的 UML類圖和交互圖，基于交互的線程和進(jìn)程對(duì)此進(jìn) 行組織，有關(guān)進(jìn)程間的通訊如何工作的解釋）用例視圖（簡要概括了構(gòu)架上最重要的用例，某些構(gòu)架上重要的用例實(shí)現(xiàn)或場景的UML交互圖

26、，以及在圖中解釋如何描述主要構(gòu)架元素的注釋）其他視圖（17 ） 看懂給定的類圖和順序圖，解釋其中表達(dá)的含義。三、請(qǐng)給出下列設(shè)計(jì)模式的含義，包括名稱、問題和解決方案，并舉例說明在什么情況下可以使用該模式（1 ）信息專家名稱信息專家(Information Expert)問題給對(duì)象分配職責(zé)基本原則是什么解決方案把職責(zé)分配給具有完成該職責(zé)所需信息的那個(gè)類舉例NextGen POS 應(yīng)用系統(tǒng)中，某個(gè)類需要知道一次銷售的總額。（2）適配器名稱適配器（Adapter ）問題如何解決不相容的接口冋題，或者如何為具有不冋接口的類似構(gòu)件提供穩(wěn)定的接口解決方案通過中介適配器對(duì)象，將構(gòu)件的原有接口轉(zhuǎn)換為其他接口增加

27、一層間接性對(duì)象， 通過這些對(duì)象將不同的外部接口調(diào)整為在應(yīng)用程序 內(nèi)使用的一致接口舉例NextGen POS 應(yīng)用系統(tǒng)中的 SOAP over HTTP 遠(yuǎn)程訪冋SAPSystem 時(shí) 用到適配器模式。（3）外觀名稱外觀（Facade）問題對(duì)一組完全不冋的實(shí)現(xiàn)或接口需要公共、統(tǒng)一的接口?？赡軙?huì)與子系統(tǒng)內(nèi)部的大量事物產(chǎn)生耦合，或者子系統(tǒng)的實(shí)現(xiàn)可能會(huì)改變。怎么辦解決方案對(duì)子系統(tǒng)定義唯一的接觸點(diǎn)-使用外觀對(duì)象封裝子系統(tǒng)。該外觀對(duì)象提供了唯一和統(tǒng)一的接口，并負(fù)責(zé)與子系統(tǒng)構(gòu)件進(jìn)行協(xié)作相關(guān)模式外觀通常通過單實(shí)例類模式進(jìn)行訪問舉例我們把一個(gè)文件，放在了第二抽屜里，而第二個(gè)抽屜的鑰匙放在了第一個(gè) 抽屜里，我們要想取出這個(gè)文件，第一步肯定要拿到第一個(gè)抽屜的鑰匙， 然后打開它再拿出第二個(gè)抽屜的鑰匙，最后打開第二個(gè)抽屜取出文件。（兩個(gè)抽屜還好說，但如果是n個(gè)呢？）所以對(duì)于客戶來說，這些取鑰匙的過 程不需要知道，他們只需要