軟件工程-實踐者的研究方法-知識點VIP

1、軟件工程復(fù)習(xí)總結(jié) 第1章軟件工程介紹1軟件的定義軟件是包括程序、數(shù)據(jù)及其相關(guān)文檔的完整集合。其中，程序是按照事先設(shè)計的功能和性能要求執(zhí)行的指令序列；數(shù)據(jù)是使程序能正常操作信息的數(shù)據(jù)結(jié)構(gòu)；文檔是與程序開發(fā)、維護和使用有關(guān)的圖文材料。軟件的定義：1、指令的集合，通過執(zhí)行這些指令可以滿足預(yù)期的特征、功能和性能需求2、數(shù)據(jù)結(jié)構(gòu)，它使得程序可以充分利用信息3描述程序操作和使用的文檔2軟件的特征a)軟件是設(shè)計開發(fā)的，而不是傳統(tǒng)意義上的生產(chǎn)制造的b)軟件不會磨損c)雖然整個工業(yè)向著基于構(gòu)件的構(gòu)造模式發(fā)展，然而大多數(shù)軟件仍是根據(jù)實際的顧客需求定制的3軟件與硬件的區(qū)別a)軟件是一種邏輯實體，而不是具體的物理實體

2、b)軟件的生產(chǎn)與硬件不同，軟件開發(fā)過程中沒有明顯的制造過程c)軟件在運行、使用期間沒有磨損、老化問題d)軟件的開發(fā)、運行受到計算機系統(tǒng)的限制，不同程度地依賴于硬件和環(huán)境，導(dǎo)致了軟件升級和移植地問題e)軟件復(fù)雜性越來越高f)軟件開發(fā)成本相當(dāng)昂貴g)大多數(shù)軟件是新開發(fā)的，而不是通過已有的構(gòu)件組裝而來的h)軟件工程涉及諸多的社會因素4遺留軟件與軟件的演化系統(tǒng)演化的原因:a)系統(tǒng)需要修改其適應(yīng)性，從而滿足新的計算環(huán)境或者技術(shù)的需求b)軟件必須根據(jù)新的業(yè)務(wù)需求進行升級c)軟件必須擴展以具有與更多現(xiàn)代系統(tǒng)和數(shù)據(jù)庫的協(xié)作能力d)軟件架構(gòu)必須進行改建以適應(yīng)多樣化的網(wǎng)絡(luò)環(huán)境30年來軟件發(fā)展的規(guī)律：1、持續(xù)變化規(guī)

3、律，2、復(fù)雜性增長規(guī)律，3、自我調(diào)控規(guī)律，4、組織穩(wěn)定性守恒規(guī)律，5、保證通曉性規(guī)律，6、持續(xù)增長規(guī)律，質(zhì)量衰減規(guī)律，7、反饋系統(tǒng)規(guī)律。5 軟件神話：1、管理神話。軟件項目經(jīng)理依賴信條，減輕提高軟件進度和質(zhì)量的壓力。如開發(fā)寶典、增加人員、軟件外包。2、用戶神話。開發(fā)小組沒有和用戶進行有效溝通，導(dǎo)致沒有達到用戶期望。如沒有詳細了解就開始寫程序，認為軟件容易適應(yīng)變更。3、從業(yè)者神話：軟件開發(fā)者深信各種神話，舊的方式根深蒂固。6.軟件新的挑戰(zhàn)：遍在計算。無線網(wǎng)絡(luò)的快速發(fā)展也許將很快促成真正的分布式計算的實現(xiàn)網(wǎng)絡(luò)資源。萬維網(wǎng)已經(jīng)快速發(fā)展為一個計算引擎和內(nèi)容提供平臺。開源軟件。開源軟件就是將系統(tǒng)應(yīng)用程序

4、源代碼開放，新經(jīng)濟。 第2章 過程綜述1 軟件工程定義：(1) 將系統(tǒng)的、規(guī)范的、可量化的方法應(yīng)用于軟件的開發(fā)、運行和維護，即將工程化方法用于軟件開發(fā)(2) 在(1)中所述的方法的研究2軟件工程的層次：工具 方法 過程 質(zhì)量關(guān)注點（根基）軟件工程的基礎(chǔ)是過程（process）層。軟件過程是將各個技術(shù)層次結(jié)合在一起并實施合理地、及時地開發(fā)計算機軟件。過程定義一個框架，為有效交付軟件過程技術(shù)，這個框架必須建立。軟件過程構(gòu)成了軟件項目管理控制的基礎(chǔ)，并且建立了一個環(huán)境以便于技術(shù)方法的采用、工作產(chǎn)品的產(chǎn)生、里程碑的建立、質(zhì)量的保證、正常變更的正確管理。軟件工程方法（method）為建造軟件提供技術(shù)上的

5、解決方法（"如何做"）方法覆蓋面很廣，包括溝通、需求分析、設(shè)計建模、編程、測試和支持。軟件工程方法依賴于一組基本原則，這些原則涵蓋了軟件工程所有技術(shù)領(lǐng)域，包括建模和其他描述性技術(shù)等。軟件工具（tool）為過程和方法提供自動化或半自動化的支持。這些工具可以集成起來，使得一個工具產(chǎn)生的信息可被另外一個工具使用，這樣就建立了軟件開發(fā)的支撐系統(tǒng)，稱為計算機輔助軟件工程（computer-aided software engineering）3通用過程框架Generic process framework的框架活動：溝通 策劃 建模 構(gòu)建和部署communication（溝通）這個框

6、架活動包含了與客戶（和其他共利益者）之間的大量的交流和協(xié)作，還包括需求獲取以及其他相關(guān)活動。planning（策劃）指為后續(xù)的軟件工程工作制定計劃。它描述了需要執(zhí)行的技術(shù)任務(wù)，可能的風(fēng)險、資源需求、工作產(chǎn)品和工作進度計劃。modeling （建模）它包括創(chuàng)建模型和設(shè)計兩方面。創(chuàng)建模型有助于客戶和開發(fā)人員更好的理解軟件需求；設(shè)計可以實現(xiàn)需求。Construction（構(gòu)建）它包括編碼（手寫的或者自動生成的）和測試（測試是為了發(fā)現(xiàn)編碼中的錯誤）deployment（部署）軟件（全部或者完成的部分）交付到用戶，用戶對其進行評估并給出反饋意見。4 CMMI的概念和等級（重點）：Capability M

7、aturity Model Integration能力成熟度模型，SEI提出的一個全面的過程元模型，當(dāng)軟件組織開發(fā)達到不同的過程能力和成熟度水平時，該模型可用來預(yù)測其所開發(fā)的系統(tǒng)和軟件工程能力。第0級：不完全級（Incomplete）。過程域沒有實施，或者已經(jīng)實施但未達到CMMI 1級成熟度所規(guī)定的所有目標(biāo)。第1級：已執(zhí)行級（Performed）CMMI中定義的所有過程域的特定目標(biāo)都已經(jīng)實現(xiàn)。產(chǎn)生規(guī)定的工作產(chǎn)品所必需的工作任務(wù)都已經(jīng)執(zhí)行。第2級：已管理級（Managed）所有第1級規(guī)定的要求都已經(jīng)達到。另外，所有與過程域相關(guān)的工作都符合組織的規(guī)程；工作人員都有足夠的資源完成工作；共利益者都積極

8、參與到要求的過程域；所有的工作任務(wù)和工作產(chǎn)品都被"監(jiān)督、控制和評審；并評估是否與過程描述相一致"。第3極：已定義級（Defined）所有第2級規(guī)定的要求都已經(jīng)達到。另外，根據(jù)組織剪裁準(zhǔn)則，對其標(biāo)準(zhǔn)過程進行了裁剪，裁剪過的過程對組織的過程資產(chǎn)增添了新的內(nèi)容，如工作產(chǎn)品、測量和其他過程改進信息等。第4級：已定量管理級（Quantitatively Managed）所有第3級規(guī)定的要求都已經(jīng)達到。另外，通過采用測量和定量的估計等手段，對過程域進行控制和不斷改進。"已經(jīng)建立起來對質(zhì)量和過程性能的定量指標(biāo)，并作為過程管理的標(biāo)準(zhǔn)"。第5級：優(yōu)化級（Optimized

9、）所有第4級規(guī)定的要求都已經(jīng)達到。另外，"采用定量（統(tǒng)計）的方法調(diào)整和優(yōu)化過程域，以滿足用戶不斷變更的需求，并持續(xù)地提高過程域的有效性。"5PSP/TSP模型特點PSP（個人軟件過程）過程模型定義了5個框架活動：策劃、高層設(shè)計、高層設(shè)計評審、開發(fā)、后驗。策劃：它將需求活動分離出來，并根據(jù)需求計算項目的規(guī)模和所需資源，并且預(yù)測缺陷數(shù)目。所有的度量都用工作表或模板記錄。最后，識別開發(fā)任務(wù)，并建立項目進度計劃。高層設(shè)計：建立每個構(gòu)件的外部規(guī)格說明，并完成構(gòu)件設(shè)計。如果有不確定的需求，則構(gòu)建原型系統(tǒng)。所有問題都被記錄和跟蹤。高層設(shè)計評審：使用形式化驗證方法來發(fā)現(xiàn)設(shè)計中的錯誤。對所有

10、的重要任務(wù)和工作結(jié)果都進行度量。開發(fā)：細化和評審構(gòu)件級設(shè)計。完成編碼，對代碼進行評審，并進行編譯和測試。對所有的重要任務(wù)和工作結(jié)果都進行度量。后驗：根據(jù)收集到的度量和測量結(jié)果，確定過程的有效性。度量和測量結(jié)果為提高過程的有效性提供指導(dǎo)。TSP的目標(biāo)（團隊軟件過程）·建立自我管理團隊來計劃和跟蹤其工作，確定目標(biāo)，建立團隊自己的過程和計劃。·只是管理人員如何指導(dǎo)和激勵其團隊，并保持團隊的最佳表現(xiàn)。·使CMM第5級的行為常規(guī)化，并依此約束員工，這樣可加速軟件過程改進。·為高成熟度的軟件組織提供改進指導(dǎo)。·協(xié)助大學(xué)傳授工業(yè)級團隊技能。 第3章 過程模型

11、1過程模型的作用：使軟件開發(fā)更加有序2傳統(tǒng)過程模型瀑布模型 又被稱為經(jīng)典生命周期，它提出了一個系統(tǒng)的、順序的軟件開發(fā)方法，從用戶需求規(guī)格說明開始，通過策劃、建模、構(gòu)建和部署過程，最終提供一個完整的軟件并提供持續(xù)的技術(shù)支持。要求：需求明確 更改較小的情形增量過程模型：增量模型：以迭代的方式運用瀑布模型。隨著時間推移，增量模型在每個階段運用線性序列，每個線性序列生產(chǎn)出一個軟件的可交付增量。和原型不同，增量模型每個增量都提交一個可交付的產(chǎn)品。瀑布模型的一個迭代版本，在每個階段運行瀑布模型生產(chǎn)出一個軟件可交付增量。運用增量模型時，第一個增量往往時核心產(chǎn)品。適用范圍：在開發(fā)過程中開發(fā)人員不足RAD模型

12、：快速應(yīng)用程序開發(fā)是一種側(cè)重于短暫的開發(fā)周期的增量軟甲過程模型。RAD是瀑布模型的高速變體，通過基于構(gòu)建的方法實現(xiàn)快速開發(fā)。溝通來理解軟件的特征，策劃確保多個團隊并行工作，建模包括三個階段業(yè)務(wù)建模、數(shù)據(jù)建模和過程建模。構(gòu)建運用已有的構(gòu)件技術(shù)并用代碼自動生成技術(shù)，部署為以后的迭代建立基礎(chǔ)。不足：1、大量的人員，2、開發(fā)者和客戶如果沒有為短實踐內(nèi)急速完成做好準(zhǔn)備，通常為失敗，3、需要合理的模塊化，否則構(gòu)建建立會有很多問題，4、不適合高性能，5、高風(fēng)險不宜采用RAD。演化過程模型：原型模型（重點）原型模型的基本思想是：軟件開發(fā)人員在與用戶進行需求分析時，以比較小的代價快速建立一個能夠反映用戶主要需求

13、的原型系統(tǒng)，然后由客戶或者用戶進行評價。開發(fā)人員根據(jù)反饋進一步對原型進行補充和完善，直到用戶對開發(fā)的原型系統(tǒng)滿意為止。使用原型系統(tǒng)時，客戶和開發(fā)者必須承認原型是為定義需求服務(wù)的。然后丟棄原型，實際的軟件系統(tǒng)是以質(zhì)量第一為目標(biāo)的。適用范圍：a) 客戶提出了軟件的一些基本功能，但是沒有詳細定義的輸入、處理和輸出需求。b) 開發(fā)人員對算法的效率、操作系統(tǒng)的兼容性和人機交互的形式等情況不確定。優(yōu)點：由用戶或客戶進行評價，能夠用來定義需求 缺點：第一個系統(tǒng)通常是不可用的，必須被扔掉螺旋模型一種風(fēng)險驅(qū)動型過程模型，它有兩個顯著的特點。一是采用循環(huán)的方式逐步加深系統(tǒng)定義和實現(xiàn)的深度，同時降低風(fēng)險（要求在項目

14、的所有階段始終考慮技術(shù)風(fēng)險）。二是確定一系列里程碑，確保共利益者都支持可行的和令人滿意的系統(tǒng)解決方案。適用范圍：大型系統(tǒng)開發(fā)協(xié)同開發(fā)模型。有時候叫協(xié)同工程，可以表示為一系列框架活動、軟件工程動作和任務(wù)以及相應(yīng)的狀態(tài)。協(xié)同過程模型定義了一系列事件，這些事件將出發(fā)軟件工程活動、動作或狀態(tài)轉(zhuǎn)換。協(xié)同過程模型可用于所有類型的軟件開發(fā)，能提供項目當(dāng)前的狀態(tài)圖。專用過程模型：基于構(gòu)建的開發(fā)：能夠做到軟件復(fù)用，帶來極大收益。形式化方法模型：的主要活動是生成計算機軟件的數(shù)學(xué)規(guī)格說明。使用形式化方法，歧義性問題、不完整問題、不一致問題都容易被發(fā)現(xiàn)和改正，不是依靠特定的評審，而是應(yīng)用分析的方法。面向方面的軟件開發(fā)

15、（AOSD）：為定義、說明、設(shè)計和構(gòu)建方面提供過程和方法，是對橫切關(guān)注點局部表示的一種機制，超越了子程序和繼承的方法。統(tǒng)一過程：UP以用例為驅(qū)動、以系統(tǒng)架構(gòu)為中心的迭代與增量過程。RUP包括起始、細化、構(gòu)建、轉(zhuǎn)換和生產(chǎn)5個部分。五個UP階段并不是順序地進行，而是階段性地并發(fā)進行。UP模型（概念重點）：一種用UML進行面向?qū)ο筌浖こ痰目蚣?。敏捷的概?了解模型的特點與使用范圍 第6章 系統(tǒng)工程（不作要求）1系統(tǒng)工程的概念2基于計算機系統(tǒng)的要素3系統(tǒng)工程的層次 全局/領(lǐng)域/要素/詳細視圖4業(yè)務(wù)過程工程 需要分析和設(shè)計的三種不同架構(gòu)：數(shù)據(jù)、應(yīng)用、和技術(shù)基礎(chǔ)設(shè)施5產(chǎn)品工程需求工程、構(gòu)建工程、軟件工程

16、需求導(dǎo)出為何困難：范圍問題 理解問題 易變問題產(chǎn)品工程的目的是將用戶期望的已定義的一組能力轉(zhuǎn)化成真實產(chǎn)品。為了達到這個目的，產(chǎn)品工程類似系統(tǒng)工程必須給出架構(gòu)和基礎(chǔ)設(shè)施。這個構(gòu)架包括四個不同的系統(tǒng)構(gòu)件：軟件 硬件 數(shù)據(jù)（數(shù)據(jù)庫）以及人員軟件構(gòu)造包括了編碼和測試循環(huán)，循環(huán)過程包括為每個構(gòu)件生成源碼并對其進行測試和糾錯。軟件部署發(fā)生在向客戶展示每個軟件增量的時候。交付的關(guān)鍵原則是滿足客戶期望并且能為客戶提供合適的軟件信息支持。6系統(tǒng)建模方法：HP方法（輸入處理輸出 界面和維護自檢）7SCD圖8UML系統(tǒng)建模（部署圖、活動圖和用例圖） 第7章 需求工程（概念）1需求工程的任務(wù)：啟始、導(dǎo)出、求精、協(xié)商、

17、規(guī)格說明、確認和需求管理Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management2質(zhì)量功能部署（QFD）三類要求：正常需求、期望需求、令人興奮的需求。3用戶場景的概念用來識別對將要構(gòu)建的系統(tǒng)的使用線索的描述用例。場景通常稱為用例。本質(zhì)上，用例定義了最終用戶如何在以特定的環(huán)境下與系統(tǒng)交互。4UML用例建模（用例圖、活動圖、狀態(tài)圖和類圖）系統(tǒng)規(guī)格說明的三個目標(biāo)：功能 性能 約束用例模版 p1275. 需求工程概念：需求工程幫助軟件工程師更好的理解他們將要解決的問題。其

18、中所包含的一系列任務(wù)有助于理解軟件將如何影響業(yè)務(wù)、客戶想要什么以及最終用戶將如何與軟件交互。通過需求分析可以得到的產(chǎn)品有：用戶場景、功能和特征列表、分析模型或功能說明。需求工程（RE）是一個軟件工程動作，開始于溝通并持續(xù)到建模。需求工程在設(shè)計和構(gòu)造之間建立聯(lián)系的橋梁6. 啟動需求工程的過程a. 確認共利益者b. 識別多種觀點c. 協(xié)同合作d. 首次提問7. 導(dǎo)出需求a. 協(xié)同需求收集b. 質(zhì)量功能部署c. 用戶場景d. 導(dǎo)出工作產(chǎn)品 第8章 構(gòu)建分析模型 建模的目的 對象技術(shù) 建模原則 分析包1分析建模的三個目標(biāo)a.描述客戶需要什么，b.為軟件設(shè)計奠定基礎(chǔ)，c.定義在軟件完成后可以被確認的一組

19、需求。分析模型在系統(tǒng)描述和設(shè)計模型之間建立橋梁。2分析建模的方法（結(jié)構(gòu)化分析和面向?qū)ο螅?、一種考慮數(shù)據(jù)和處理的分析建模方法被稱為結(jié)構(gòu)分析。2、第二種方法是面向?qū)ο蟮姆治觯@種方法關(guān)注于定義類和影響客戶需求的類之間的協(xié)作方式。3分析模型的元素：基于場景、面向信息流、基于類、基于行為4ERD（實體關(guān)系基數(shù)和形態(tài)）數(shù)據(jù)字典 面向?qū)ο蠓治瞿Ｐ?基于場景建模（用例模版、活動圖/泳道圖）6狀態(tài)圖7基于類的建模：實體、類、類圖（CRC圖），行為模型（時序圖）8基于用例圖的分析類的抽象方法9分析模型的概念及其組成分析包：分析建模的一個重要部分就是分類，也就是將分析模型的各種元素（如用例、分析類）分組打包稱作

20、分析包，并為每個包取一個有代表性的名稱。10.創(chuàng)建分析模型遵循的原則：a. 模型應(yīng)關(guān)注在問題域或業(yè)務(wù)域內(nèi)可見的需求，抽象的級別應(yīng)該相對高一些b. 分析模型的每個元素都應(yīng)能增加對軟件需求的整體理解，并提供對信息域。功能和系統(tǒng)行為的深入理解c. 基于基礎(chǔ)結(jié)構(gòu)和其他非功能的模型應(yīng)推延到設(shè)計階段再考慮d. 最小化整個系統(tǒng)內(nèi)的關(guān)聯(lián)e. 確認分析模型為所有共利益者都帶來價值f. 盡可能保持模型簡潔第八章 構(gòu)建分析模型1、分析模型。分析模型使用文字和圖表的綜合形式以相對容易理解的方式描繪需求的數(shù)據(jù)、功能和行為，更重要的是，可以更直接的評審它們的正確性、完整性和一致性。2、基于場景的建模從用戶的角度表現(xiàn)系統(tǒng)，

21、面向流的建模在說明數(shù)據(jù)對象如何通過處理函數(shù)進行轉(zhuǎn)換方面提供了指示，基于類的建模定義了對象、屬性和關(guān)系，行為建模描述了系統(tǒng)狀態(tài)、類和事件在這些類上的影響。3、分析模型必須實現(xiàn)的三個主要目標(biāo)：a.描述客戶需要什么，b.為軟件設(shè)計奠定基礎(chǔ)，c.定義在軟件完成后可以被確認的一組需求。分析模型在系統(tǒng)描述和設(shè)計模型之間建立橋梁。4、分析建模的方法。1、一種考慮數(shù)據(jù)和處理的分析建模方法被稱為結(jié)構(gòu)分析。2、第二種方法是面向?qū)ο蟮姆治?，這種方法關(guān)注于定義類和影響客戶需求的類之間的協(xié)作方式。5、基于場景的建模使用UML分析建模，從開發(fā)用例、活動圖和泳道圖形式的場景開始。6、創(chuàng)建數(shù)據(jù)流模型，數(shù)據(jù)流圖有助于軟件工程師

22、開發(fā)信息域的模型，并同時開發(fā)功能域的模型。7、CRC建模。CRC提供了一個簡單的方法，可以識別和組織與系統(tǒng)或產(chǎn)品需求相關(guān)的類。CRC模型實際上師表示類的標(biāo)準(zhǔn)索引卡片的集合。這些卡片被分為三部分，頂部寫類名，下面左側(cè)列出類的職責(zé)，右側(cè)部分列出類的協(xié)作關(guān)系。8、生成行為模型。CRC索引卡和其他面向?qū)ο竽Ｐ捅憩F(xiàn)了分析模型中的靜態(tài)元素，行為模型表示系統(tǒng)或產(chǎn)品的動態(tài)行為，有狀態(tài)圖、順序圖。9、分析模型由4種建模元素構(gòu)成：基于場景的模型、流模型、基于類的模型和行為模型。10、基于場景的模型從用戶的角度描述軟件需求。用例是主要的建模元素，還可以適用活動圖說明場景，泳道圖顯示了處理流如何分配給不同的用戶。流模

23、型關(guān)注當(dāng)數(shù)據(jù)對象通過處理函數(shù)轉(zhuǎn)換時的流動?；陬惖慕Ｊ褂没趫鼍昂兔嫦蛄鞯慕Ｔ刂刑崛〉男畔⒋_定分析類。前面三種分析模型元素提供了軟件的靜態(tài)視圖，行為模型描述了動態(tài)行為。行為模型使用基于場景、面向流和基于類的元素作為輸入，從整體上表現(xiàn)分析系統(tǒng)和類的狀態(tài)。要做到這一點，要識別狀態(tài)，定義導(dǎo)致類做出狀態(tài)轉(zhuǎn)移的事件，以及確認當(dāng)轉(zhuǎn)移完成時所發(fā)生的動作。狀態(tài)圖和順序圖是用于行為建模的UML表達方式。11.實體/關(guān)系圖（ERD）圖形化的表示對象/關(guān)系對。ERD識別了一組基本元素：數(shù)據(jù)對象、屬性、關(guān)系以及各種類型的指示符，使用ERD的主要目的是表示數(shù)據(jù)對象及其關(guān)系 第9章 設(shè)計工程1McGlaughlin

24、指導(dǎo)評價良好設(shè)計的3個特征2設(shè)計的概念抽象：抽象是人類處理復(fù)雜問題的基本方法之一。當(dāng)我們在不同抽象級間移動時，我們力圖創(chuàng)建過程抽象和數(shù)據(jù)抽象。過程抽象是指具有明確和有限功能的指令序列。數(shù)據(jù)抽象是描述對象的冠名數(shù)據(jù)集合體系結(jié)構(gòu)（概念）軟件體系結(jié)構(gòu)意指"軟件的整體結(jié)構(gòu)和這種結(jié)構(gòu)為系統(tǒng)提供概念上完整性的方式"。從最簡單的形式來看，體系結(jié)構(gòu)是程序構(gòu)建（模塊）的結(jié)構(gòu)或組織、這些構(gòu)件交互的形式以及這些構(gòu)件所用數(shù)據(jù)的結(jié)構(gòu)。模式：設(shè)計模式描述了在某個特定場景與可能影響模式應(yīng)用和使用方式的“影響力”中解決某個特定的設(shè)計問題的設(shè)計結(jié)構(gòu)。模塊化：軟件體系結(jié)構(gòu)和設(shè)計模式表現(xiàn)為模塊化；軟件被劃分為獨

25、立命名的、可尋址的構(gòu)件，有時被稱為模塊，把這些構(gòu)件集到一起可以滿足問題的需求信息隱藏（重點）每個模塊對其它所有模塊都隱藏自己的設(shè)計決策。就是說，模塊應(yīng)該詳細說明且精心設(shè)計以求在某個模塊中包含的信息（算法和數(shù)據(jù)）不被不需要這些信息的其他模塊訪問。隱蔽定義并加強了模塊內(nèi)的過程細節(jié)和模塊所使用的任何局部數(shù)據(jù)結(jié)構(gòu)的訪問和約束。功能獨立：功能獨立的概念是模塊化、抽象概念和信息隱蔽的直接結(jié)果求精：逐步求精是一種自頂向下的設(shè)計策略，求精實際上是一個細化的過程。重構(gòu)：重構(gòu)是一種重新組織的技術(shù)，可以簡化構(gòu)件的設(shè)計（或代碼）而無需改變其功能或行為。設(shè)計類：組織良好的設(shè)計類的4個特征完整性和充分性 原始性 高內(nèi)聚和

26、低耦合性4模式和框架5完整設(shè)計的4個模型和作用：數(shù)據(jù)、體系結(jié)構(gòu)、接口和構(gòu)件級設(shè)計數(shù)據(jù)設(shè)計：創(chuàng)建在高抽象級上（以客戶/用戶的數(shù)據(jù)觀點）表示的數(shù)據(jù)模型或信息模型體系結(jié)構(gòu)設(shè)計：揭示了規(guī)格分析模型的軟件和硬件元素之間的關(guān)系和協(xié)作，體系結(jié)構(gòu)設(shè)計定義了軟件的主要結(jié)構(gòu)元素之間的聯(lián)系，為我們提供了軟件的整體視圖接口設(shè)計：軟件接口設(shè)計元素告訴我們信息如何流入和流出系統(tǒng)以及被定義為體系結(jié)構(gòu)一部分的構(gòu)件之間是如何通信的，描述了一組可以用來描述一個特定類的外部可見的行為的操作以及提供對這些操作的訪問包括三個重要元素：用戶界面（UI）；和其他系統(tǒng)、設(shè)備、網(wǎng)絡(luò)或其他的信息生產(chǎn)者或使用者的外部接口；各種設(shè)計構(gòu)件之間的內(nèi)部接

27、口。構(gòu)件級設(shè)計：描述每一個軟件組件的內(nèi)部細節(jié)。為所有本地數(shù)據(jù)對象定義數(shù)據(jù)結(jié)構(gòu)，為所有在構(gòu)件內(nèi)發(fā)生的處理定義算法細節(jié)，并定義允許訪問所有構(gòu)件操作（行為）的接口。6.從分析模型到設(shè)計模型的轉(zhuǎn)化 第10章 體系結(jié)構(gòu)設(shè)計1體系結(jié)構(gòu)設(shè)計定義和重要性定義：一個程序和計算系統(tǒng)軟件體系結(jié)構(gòu)是指系統(tǒng)的一個或者多個結(jié)構(gòu)。結(jié)構(gòu)中包括軟件的構(gòu)件，構(gòu)件的外部可見屬性以及它們之間的相互關(guān)系。體系結(jié)構(gòu)并非可運行軟件，確切的說，它是一種表達，是軟件工程師能夠（1）分析設(shè)計在滿足需求方面的有效性，（2）在設(shè)計變更相對容易的階段，考慮體系結(jié)構(gòu)可能的選擇方案，（3）降低與軟件構(gòu)造相關(guān)聯(lián)的風(fēng)險。重要性：軟件體系機構(gòu)的表示有助于對計算

28、機系統(tǒng)開發(fā)感興趣的各方（共利益者）開展交流；體系結(jié)構(gòu)突出早期設(shè)計決策，影響隨后的軟件工程工作，同時對系統(tǒng)的最后成功有重要作用；體系結(jié)構(gòu)"創(chuàng)建了一個相對小的，易于理解的模型，該模型描述了系統(tǒng)如何構(gòu)成以及其構(gòu)件如何一起工作"2數(shù)據(jù)設(shè)計目標(biāo) 數(shù)據(jù)字典數(shù)據(jù)字典是用來定義數(shù)據(jù)流圖中的各個成分的具體含義的。它以一種準(zhǔn)確的、無二義性的說明方式為系統(tǒng)的分析、設(shè)計及維護提供了有關(guān)元素的一致的定義和詳細的描述。數(shù)據(jù)設(shè)計是把分析模型定義的數(shù)據(jù)對象轉(zhuǎn)化成軟件構(gòu)件級的數(shù)據(jù)結(jié)構(gòu)，并且再必要時轉(zhuǎn)化為應(yīng)用程序級的數(shù)據(jù)庫體系結(jié)構(gòu)。3體系結(jié)構(gòu)風(fēng)格的組成要素一組構(gòu)件、一組連接器、約束和語意模型一種體系風(fēng)格就是一

29、種加在整個系統(tǒng)設(shè)計上面的變換。它的目的就是為系統(tǒng)的所有的構(gòu)建建立一個結(jié)構(gòu)。對已有體系結(jié)構(gòu)進行再工程時，強制采用一種體系結(jié)構(gòu)風(fēng)格會導(dǎo)致軟件結(jié)構(gòu)的根本性改變，包括對構(gòu)建功能的再分配。每種風(fēng)格描述一種系統(tǒng)類別，包括（1）一組構(gòu)建完成系統(tǒng)需要的某種功能，（2）一組連接器，使構(gòu)建間實現(xiàn)通信、合作和協(xié)調(diào)，（3）約束，定義構(gòu)件成為一個系統(tǒng)，（4）語義模型，使設(shè)計者通過分析系統(tǒng)的構(gòu)成成分的性質(zhì)來理解系統(tǒng)的整體性質(zhì)。4體系結(jié)構(gòu)風(fēng)格分類以數(shù)據(jù)為中心的體系結(jié)構(gòu) 數(shù)據(jù)流體系結(jié)構(gòu) 調(diào)用返回體系結(jié)構(gòu) 面向?qū)ο篌w系結(jié)構(gòu) 層次體系結(jié)構(gòu)5模式 （并發(fā)性、持久性、分布性）體系結(jié)構(gòu)模式（architecture pattern）軟

30、件的體系結(jié)構(gòu)模式定義了處理系統(tǒng)某些行為特征的方法。體系結(jié)構(gòu)模式域：并發(fā)性、持久性、分布性。6體系結(jié)構(gòu)設(shè)計（體系結(jié)構(gòu)環(huán)境ACD）在體系結(jié)構(gòu)設(shè)計層，軟件架構(gòu)師用體系結(jié)構(gòu)環(huán)境圖（architectural context diagram）對軟件與外部實體交互方式進行建模。7 體系結(jié)構(gòu)的復(fù)雜性（共享依賴 流依賴 約束依賴） a. 共享依賴表示在使用相同資源的消費者間或為相同消費者生產(chǎn)的生產(chǎn)者之間的依賴關(guān)系b. 流依賴表示資源的生產(chǎn)者和消費者之間的依賴關(guān)系c. 約束依賴表示在一組活動間相關(guān)控制流上的約束 第11章 構(gòu)件級設(shè)計建模1構(gòu)件的定義（面向?qū)ο蠛蛡鹘y(tǒng)的觀點）構(gòu)件是：系統(tǒng)中某一定型化的、可配置的和可

31、替換的部件，該部件封裝了實現(xiàn)并暴露一系列接口。從面向?qū)ο笥^點：一個構(gòu)件就是一個協(xié)作類的集合。傳統(tǒng)觀點：一個構(gòu)件就是程序的一個功能要素，程序由處理邏輯及實現(xiàn)處理邏輯所需的內(nèi)部數(shù)據(jù)結(jié)構(gòu)以及能夠保證構(gòu)件被調(diào)用和實現(xiàn)數(shù)據(jù)傳遞的接口構(gòu)成。承擔(dān)以下角色：a. 控制構(gòu)件b. 問題域構(gòu)件c. 基礎(chǔ)設(shè)施構(gòu)件2基于類的構(gòu)件的基本設(shè)計原則開關(guān)原則 替換原則 依賴倒置原則 接口分離原則 發(fā)布復(fù)用等價性原則 共同封裝原則共同復(fù)用原則開關(guān)原則The Open-Closed Principle (OCP)：模塊應(yīng)該對外延具有開放性，對修改具有封閉性Liskov替換原則The Liskov Substitution Prin

32、ciple (LSP)：子類可以替換它們的基類依賴倒置原則Dependency Inversion Principle (DIP)：依賴于抽象，而非具體的實現(xiàn)接口分離原則The Interface Segregation Principle (ISP)：多個用戶專用接口比一個通用接口要好發(fā)布復(fù)用等價性原則The Release Reuse Equivalency Principle (REP)：復(fù)用的粒度就是發(fā)布的粒度共同封裝原則The Common Closure Principle (CCP)：一同變更的類應(yīng)該合在一起共同復(fù)用原則The Common Reuse Principle (CR

33、P)：不能一起復(fù)用的類不能被分到一組3 構(gòu)件的內(nèi)聚性（Cohesion）（概念）：在為面向?qū)ο笙到y(tǒng)進行構(gòu)件級設(shè)計中，內(nèi)聚性意味著構(gòu)建或者類只封裝那些相互關(guān)聯(lián)密切，以及與構(gòu)件或類自身有密切關(guān)系的屬性和操作按內(nèi)聚性的級別排序有：功能、分層、通信、順序、過程、暫時、實用內(nèi)聚。4 構(gòu)件間的耦合（Coupling）耦合是彼此聯(lián)系程度的定性度量。構(gòu)建級設(shè)計中，一個重要的目標(biāo)就是保持低耦合。耦合的分類：內(nèi)容耦合 共用耦合 控制耦合 印記耦合 數(shù)據(jù)耦合 例程調(diào)用耦合 類型使用耦合 包含或?qū)腭詈?外部耦合5面向?qū)ο蟮臉?gòu)件級設(shè)計步驟步驟一：標(biāo)識出所有與問題域相對應(yīng)的設(shè)計類。步驟二：確定所有與基礎(chǔ)設(shè)施域相對應(yīng)的設(shè)

34、計類。步驟三：細化所有不能作為復(fù)用構(gòu)件的設(shè)計類。31：在類或構(gòu)件的協(xié)作時說明信息的細節(jié)32：為每一個構(gòu)件說明適當(dāng)?shù)慕涌凇?3：細化屬性并且定義相應(yīng)的數(shù)據(jù)類型和數(shù)據(jù)結(jié)構(gòu)。34：詳細描述每個操作中的處理流。步驟四：說明持久數(shù)據(jù)源（數(shù)據(jù)庫和文件）并確定管理數(shù)據(jù)源所需的類。步驟五：開發(fā)并且細化類或構(gòu)件的行為表示。步驟六：細化部署圖以提供額外的實現(xiàn)細節(jié)。步驟七：考慮每一個構(gòu)件設(shè)計表示，并且時刻考慮其它選擇。6傳統(tǒng)構(gòu)件級設(shè)計的圖形表示流程圖 決策表 PDL程序設(shè)計語言 第12章 實現(xiàn)用戶界面設(shè)計1黃金原則a. 置用戶于控制之下b. 減少用戶的記憶負擔(dān)c. 保持界面一致2用戶界面分析和設(shè)計過程包括4個不同的

35、框架活動：a. 用戶、任務(wù)和環(huán)境分析及建模b. 界面設(shè)計c. 界面構(gòu)造（實現(xiàn)）d. 界面確認。3. 界面分析步驟：1) 用戶分析2) 任務(wù)分析和建模a. 用例（Use-cases）：描述參與者和系統(tǒng)的交互行為方式b. 任務(wù)細化（Task elaboration）：進行功能分解，定義和劃分任務(wù)c. 對象細化（Object elaboration）：定義每個類和與其相關(guān)的操作d. 工作流分析（Workflow analysis）：理解包含多個成員（角色）時，一個工作過程是如何完成的。用UML泳道圖能夠有效的表示工作流3) 顯示內(nèi)容分析4) 工作環(huán)境分析4. 界面設(shè)計步驟：a. 使用界面分析中獲得的

36、信息，定義界面對象和行為（操作)b. 定義那些導(dǎo)致用戶界面狀態(tài)發(fā)生變化的事件（用戶動作）。對這個行為建模c. 描述每一個界面的狀態(tài)，就像最終用戶實際看到的那樣d. 簡要說明用戶如何從界面提供的界面信息來解釋系統(tǒng)狀態(tài) 第13章 測試策略 軟件測試（概念）軟件測試是為了發(fā)現(xiàn)設(shè)計過程中的疏忽所造成的錯誤的一系列活動。軟件測試是一種能夠系統(tǒng)地加以計劃和說明的活動，可以進行測試用例設(shè)計，定義測試策略，根據(jù)預(yù)期的結(jié)果評估測試結(jié)果。調(diào)試出現(xiàn)在成功的測試之后，也就是說，當(dāng)測試用例發(fā)現(xiàn)錯誤時，調(diào)試是致使錯誤消除的行為。1測試的不可窮盡性2驗證和確認的概念和區(qū)別驗證（verification）是指確保軟件正確地實

37、現(xiàn)某一特定功能的一系列活動。確認（validation）則指的是確保開發(fā)的軟件可追溯到用戶需求的另外一系列活動。驗證測試是對產(chǎn)品實現(xiàn)的功能的正確性進行測試，驗證實現(xiàn)的功能是否正確。而確認測試是對產(chǎn)品是否實現(xiàn)了需求所定義的功能的測試，確認是否實現(xiàn)了功能。獨立測試組(Independent Test Group)的作用是為了避免開發(fā)人員進行測試所引發(fā)的固有問題。獨立測試可以消除可能存在的認識差異。從分析與設(shè)計開始到計劃和指定測試規(guī)程，ITG參與到整個項目過程。3測試的過程和策略單元測試 集成測試 確認測試和系統(tǒng)測試概念以過程的觀點考慮整個測試過程，軟件工程環(huán)境中的測試實際上就是按照順序?qū)崿F(xiàn)四個步驟

38、。單元測試充分利用測試技術(shù)，檢查構(gòu)件中每個控制結(jié)構(gòu)的特定路徑以確保完全覆蓋，并最大可能地發(fā)現(xiàn)錯誤。集成測試組裝或集成各個構(gòu)件以形成完整地額軟件包，處理并驗證與程序構(gòu)造相關(guān)的問題。確認測試執(zhí)行一系列的高階測試，評估確認準(zhǔn)則，為軟件的功能、行為和性能需求提供最后的保證。系統(tǒng)測試驗證所有的成份能夠何時地結(jié)合在一起，且能滿足整個系統(tǒng)地功能/性能需求。4單元測試的策略測試模塊的接口能保證被測程序單元的信息能夠正常的流入和流出；檢查局部數(shù)據(jù)結(jié)構(gòu)以確保臨時存儲的數(shù)據(jù)在算法的整個執(zhí)行過程中能維護其完整性；走遍控制結(jié)構(gòu)中的所有獨立路徑（基本路徑）以確保模塊中的所有語句至少被執(zhí)行一次；測試邊界條件以確保模塊在到達

39、邊界置的極限或受限處理的情況下仍能正確地執(zhí)行。最后對所有的錯誤處理路徑進行測試。單元測試通常被認為是編碼階段的附屬工作。單元測試的設(shè)計可以在編碼之前或在源代碼生成之后完成。5集成測試的策略集成測試是構(gòu)造軟件體系結(jié)構(gòu)的系統(tǒng)化技術(shù)，同時也是進行一些旨在發(fā)現(xiàn)與接口相關(guān)的錯誤的測試。其目標(biāo)是利用已通過單元測試的構(gòu)件建立設(shè)計中描述的程序結(jié)構(gòu)。增量集成以小增量的方式逐步進行構(gòu)造和測試，這樣錯誤易于奮力和糾正，更易于對接口進行徹底測試，而且可以運用系統(tǒng)化的測試方法。自頂向下集成：從主控模塊開始，沿著控制層次結(jié)構(gòu)逐步向下，利用深度優(yōu)先或廣度優(yōu)先的方式將從屬于（和間接從屬于）主控模塊的模塊集成到結(jié)構(gòu)中去。（概念

40、）自底向上集成：從原子模塊（程序結(jié)構(gòu)的最底層構(gòu)件）開始進行構(gòu)造和測試。在處理時所需要的從屬于給定層次的模塊都是存在的，沒有必要使用樁模塊。6回歸測試在集成測試策略的環(huán)境下，回歸測試是重新執(zhí)行已進行測試的某個子集，以確保變更沒有傳播不期望的副作用。7 系統(tǒng)測試系統(tǒng)測試實際上是對整個基于計算機的系統(tǒng)進行一系列不同考驗的測試恢復(fù)測試 ：通過各種方式強制的讓系統(tǒng)發(fā)生故障并驗證其能適當(dāng)恢復(fù)的一種系統(tǒng)測試安全測試：驗證建立在系統(tǒng)內(nèi)的保護機制是否能夠?qū)嶋H保護系統(tǒng)不受非法入侵 壓力測試：以一種要求反常數(shù)量、頻率或容量的方式執(zhí)行系統(tǒng)性能測試：用來測試軟件在集成環(huán)境中的運行性能，通常與壓力測試一起進行，且常需要軟

41、件與硬件相配合。8調(diào)試策略三種調(diào)試方法：蠻力法 回溯法 原因排除法9. 確認測試確認測試始于集成測試的結(jié)束，那時已測試完成單個構(gòu)件，軟件已組裝成完整的軟件包，且接口錯誤已被發(fā)現(xiàn)和改正。確認測試是通過一系列表明已經(jīng)符合軟件需求的測試而獲得的。 第14章 測試手段1軟件可測試性的定義及其特性軟件可測試性就是（計算機程序）能夠被測試的容易程度。可操作性 可觀察性 可控制性 可分解性 簡單性 穩(wěn)定性 易理解性2白盒測試&黑盒測試白盒測試（玻璃盒測試），利用作為構(gòu)件層設(shè)計的一部分而描述的控制結(jié)構(gòu)來生成測試用例。作用：（1）保證一個模塊中的所有獨立路徑至少被執(zhí)行一次（2）對所有邏輯值均需測試真和假

42、（3）在上下邊界及可操作的范圍內(nèi)執(zhí)行所有的循環(huán)（4）檢驗內(nèi)部數(shù)據(jù)結(jié)構(gòu)以確保其有效性黑盒測試（行為測試），側(cè)重于軟件的功能需求，使軟件工程師能設(shè)計出將測試程序所有功能需求的輸入條件集?？梢园l(fā)現(xiàn)的錯誤類型：（1）功能不正確或遺漏（2）接口錯誤（3）數(shù)據(jù)結(jié)構(gòu)或外部數(shù)據(jù)庫訪問錯誤（4）行為或性能錯誤（5）初始化和終止錯誤3獨立路徑和環(huán)復(fù)雜度獨立路徑是貫穿程序的、至少引入一組新的處理語句或一個新的條件的路徑。環(huán)復(fù)雜度：一種軟件度量，它為程序的邏輯復(fù)雜度提供一個量化的測度。當(dāng)用在基本路徑測試方法的環(huán)境下，環(huán)復(fù)雜性的值是用基本集合定義程序的獨立路徑數(shù)，它提供了保證所有語句被執(zhí)行一次所需測試數(shù)量的上限。a.

43、域 b.V(G)=E-N+2 c.V(G)=P+1V(G)：環(huán)復(fù)雜性，E為流圖的節(jié)點數(shù)，P為包含在流圖中的判定節(jié)點數(shù)4等價劃分法和邊值分析法bva（黑盒測試）5控制結(jié)構(gòu)的測試（傳統(tǒng)）：條件測試，數(shù)據(jù)流測試，循環(huán)測試6基于場景的測試（00）不正確的規(guī)格說明 子系統(tǒng)間的交互7. 基本路徑測試：是一種白盒測試，使測試用例設(shè)計者產(chǎn)生一種過程設(shè)計的邏輯復(fù)雜性測度，這種測度為執(zhí)行路徑的基本集的定義提供指導(dǎo)。 第16章Web工程采用"可靠科學(xué)的原則、工程化的原則和管理原則，以及規(guī)范、系統(tǒng)的手段，以期獲得高質(zhì)量的基于Web的系統(tǒng)和應(yīng)用的成功開發(fā)、部署和維護"。Web屬性：網(wǎng)絡(luò)密集型 并發(fā)性

44、 無法預(yù)計的負載量 性能 可得性 數(shù)據(jù)驅(qū)動 內(nèi)容敏感性 持續(xù)演化 即時性 保密性 美學(xué)性Web應(yīng)用類型：信息型 下載型 可定制型 交互型 用戶輸入型 面向事務(wù)型 面向服務(wù)型 門戶型 數(shù)據(jù)庫訪問型 數(shù)據(jù)倉庫型 1Web應(yīng)用工程層次過程：（1）包含變化（2）鼓勵創(chuàng)新性、開發(fā)團隊的獨立性以及同WebApp的共利益者密切溝通（3）采用小的開發(fā)團隊構(gòu)造系統(tǒng)（4）強調(diào)使用短開發(fā)周期演化或增量開發(fā)方法：（1）溝通方法（2）需求分析方法（3）設(shè)計方法（4）測試方法工具及技術(shù)：。2Web工程過程框架如果說即時性和持續(xù)演化是webe的重要特點，選擇快速發(fā)布webe的敏捷過程模型；如果webe要開發(fā)一段很長的時間，

45、選擇增量過程模型客戶溝通策劃建模構(gòu)造部署 第18章 Web應(yīng)用分析1Web應(yīng)用分析模型內(nèi)容、交互、功能和配置內(nèi)容分析確定內(nèi)容類和協(xié)作；交互分析描述了用戶交互的基本元素、導(dǎo)航及最終發(fā)生的系統(tǒng)行為；功能分析定義了為用戶提供的webapp功能及最終的處理順序；配置分析確定了webapp所處的操作系統(tǒng)交互模型用例 順序圖 狀態(tài)圖 用戶界面原型功能模型活動圖配置模型部署圖 第19章 Web應(yīng)用設(shè)計1Web應(yīng)用質(zhì)量可用性 功能性 可靠性 效率 可維護性 可得性 可伸縮性 面市時間2設(shè)計目標(biāo)：簡單性 一致性 相符性 健壯性 導(dǎo)航性 視覺吸引 兼容性3Web界面設(shè)計模型美學(xué)設(shè)計、內(nèi)容設(shè)計、架構(gòu)設(shè)計、導(dǎo)航設(shè)計、

46、構(gòu)件級設(shè)計、超媒體設(shè)計補充材料（了解）：1數(shù)據(jù)流圖DFD采取了系統(tǒng)的輸入-處理-輸出觀點, 也就是說, 流入軟件的數(shù)據(jù)對象, 經(jīng)由處理元素轉(zhuǎn)換, 最后以結(jié)果數(shù)據(jù)對象的形式流出軟件. 數(shù)據(jù)對象由帶標(biāo)記的箭頭表示, 轉(zhuǎn)換由圓圈(也稱作泡泡)表示, DFD使用分層的方式表示, 即第一個數(shù)據(jù)流模型(有時也稱作第0層DFD或環(huán)境圖) 從整體上表現(xiàn)系統(tǒng), 隨后的數(shù)據(jù)流圖改進環(huán)境圖.每個流圖都有文字描述, 細化, 到最后的設(shè)計, 橢圓代表處理的功能.導(dǎo)出數(shù)據(jù)流圖時有一些簡單的指導(dǎo)原則:1. 第0層的數(shù)據(jù)流圖應(yīng)將軟件/系統(tǒng)描述為一個泡泡; 2. 主要的輸入和輸出應(yīng)被仔細地標(biāo)記; 3. 通過把在下一層表示的候選

47、處理過程, 數(shù)據(jù)對象和數(shù)據(jù)存儲分離, 開始求精過程; 4. 應(yīng)使用有意義的名稱標(biāo)記所有的箭頭和泡泡;5. 當(dāng)從一個層轉(zhuǎn)到另一個層時要保持信息流連續(xù)性;6. 一次精化一個泡泡. 數(shù)據(jù)流圖過于復(fù)雜.2UML語言概述（概念）視圖是基于某一個抽象層對系統(tǒng)的一個抽象表示，反映系統(tǒng)的一個特定方面。所有視圖一起共同描述一個完整的系統(tǒng)。在面向?qū)ο蠓治龅倪^程中，（1）基于場景模型 用例圖 活動圖 泳道圖（2）基于類模型 類圖（3）基于行為模型 狀態(tài)圖 時序圖UML中主要有5中視圖：a)用例視圖（use case view）：用例視圖表達從用戶的角度看到的系統(tǒng)應(yīng)有的外部功能。用例圖是其它視圖的核心和基礎(chǔ)，它的內(nèi)容

48、將驅(qū)動其它視圖的構(gòu)建和發(fā)展。通常用例視圖用用例圖靜態(tài)地描述系統(tǒng)功能，有時也用時序圖、協(xié)作圖或活動圖動態(tài)地描述系統(tǒng)功能。b)邏輯視圖（logic view）：邏輯視圖用來描述如何實現(xiàn)用例視圖中提出的系統(tǒng)功能，也就是描述系統(tǒng)內(nèi)部的功能設(shè)計，并形成了對問題域解決方案的術(shù)語詞匯。它關(guān)注的是系統(tǒng)的內(nèi)部，既描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，也描述系統(tǒng)的內(nèi)部動態(tài)行為。靜態(tài)結(jié)構(gòu)描述類、對象以及它們之間的關(guān)系。動態(tài)行為描述對象之間的動態(tài)協(xié)作關(guān)系。系統(tǒng)的靜態(tài)結(jié)構(gòu)通常在類圖和對象圖中描述，而動態(tài)行為則在狀態(tài)圖、時序圖、協(xié)作圖和活動圖中描述。c)并發(fā)視圖（concurrent view）：并發(fā)視圖用于描述系統(tǒng)的動態(tài)行為及其并發(fā)性。

49、并發(fā)視圖的作用是將系統(tǒng)劃分為進程和處理器方式，并處理系統(tǒng)向進程和處理器的任務(wù)分配。并發(fā)視圖描述的是系統(tǒng)的非功能屬性方面，主要考慮的是資源的有效使用、代碼的并發(fā)執(zhí)行和異步事件的處理。并發(fā)視圖用狀態(tài)圖、時序圖、協(xié)作圖、活動圖、組件圖和部署圖來描述。d)組件視圖（component view）：組件視圖用來顯示系統(tǒng)代碼組件的組織結(jié)構(gòu)方式，展示系統(tǒng)實現(xiàn)的結(jié)構(gòu)和行為特征，包括實現(xiàn)模塊和它們之間的依賴關(guān)系。組件視圖由組件圖組成，組件圖通過一定的結(jié)構(gòu)和依賴關(guān)系表示系統(tǒng)中的各種組件。組件就是代碼模塊，不同類型的代碼模塊構(gòu)成不同的組件。e)部署視圖（deployment view）：部署視圖顯示系統(tǒng)的實現(xiàn)環(huán)境和

50、組件被部署到物理結(jié)構(gòu)中的映射。部署視圖用部署圖來表示。9中不同類型的圖：A靜態(tài)圖包括用例圖、類圖、對象圖、組件圖和部署圖。用例圖從系統(tǒng)的外部描述系統(tǒng)所提供的功能。類圖描述系統(tǒng)的靜態(tài)結(jié)構(gòu)。對象圖描述系統(tǒng)在某個時刻的靜態(tài)結(jié)構(gòu)。組件圖描述實現(xiàn)系統(tǒng)的元素的組織。部署圖描述系統(tǒng)環(huán)境元素的配置。B動態(tài)圖包括狀態(tài)圖、時序圖、協(xié)作圖和活動圖。狀態(tài)圖描述系統(tǒng)元素的狀態(tài)和響應(yīng)。時序圖按時間順序描述系統(tǒng)元素間的組織。協(xié)作圖按照時間和空間的順序描述系統(tǒng)元素間的交互和相互關(guān)系?；顒訄D描述系統(tǒng)元素的活動。3面向?qū)ο蟮娜筇攸c：封裝（用來實現(xiàn)信息隱藏）把對象的屬性和服務(wù)結(jié)合成一個獨立的系統(tǒng)單位，并盡可能隱藏對象的內(nèi)部細節(jié)。

51、繼承多態(tài)（隱藏在一個接口下的多個實現(xiàn)）在父類中定義的屬性或服務(wù)被子類繼承后，可以具有不同的數(shù)據(jù)類型或表現(xiàn)出不同的行為。耦合和內(nèi)聚：耦合（coupling）是類之間彼此聯(lián)系程度的一種定性度量。內(nèi)聚（cohesion）意味著構(gòu)件或者類只封裝那些相互關(guān)聯(lián)密切，以及與構(gòu)件自身有密切關(guān)系的屬性和操作。Chapter 19 - Test Questions1. What are the major attributes should be used to assess the quality of a WebApp? Answer (Section 19.1.1):Usability, functiona

52、lity, reliability, efficiency, maintainability 2. What are the 6 activities in the Web engineering design pyramid?Answer (Section 19.2):Interface design, aesthetic design, content design, navigation design, architecture design, and component design3. What are the primary design objectives of a WebAp

53、p interface?Answer (Section 19.3.2):· Establish a consistent window into the content and functionality provided by the interface· Guide the user through a series of interactions with the WebApp· Organize the navigation option and content available to the userFinal Exam Question1. List

54、 four content architectures find in WebApps?Answer (Section 19.6.1):· Linear structures· Grid structures· Hierarchical structures· Networked or pure web structures Chapter 18 - Test QuestionsDescribe the major tasks to be completed during WebApp requirements analysis? Answer (Sec

55、tion 18.1):Formulation I(dentify goal and objectives for WebApp,define categories of users, and create user hierarchy)Requirements Gathering (communication between WebE team and stakeholders intensifies, content and functional requirements are listed, and interaction scenarios (use-cases) are developed)Analysis modeling (content modeling, interaction modeling, functional modeling, configuration modeling) Describe the differences between WebApp structural elements and dynamic elements?Answer (Section 18.2):Structural elements identify classes and content object required to create a WebApp