軟件工程復(fù)習(xí)筆記

1、. CH0 概論 本章重點： ? 軟件工程的定義 ? 什么是軟件退化 ? 軟件與程序的區(qū)別 ? 軟件工程的組成 ? 客戶和用戶的定義 ? 常見的軟件神話，他們錯在何處？ ? 軟件工程的目標有哪些？ ? 軟件工程的目標中最重要的是哪個？ ? 軟件過程是一種層次化的技術(shù)，其層次結(jié)構(gòu)是什么樣的？ ? 軟件是想改就能改的嗎？ ? 軟件開發(fā)時是不是越早開始寫代碼越好 1.為什么需要軟件工程： 個人、企業(yè)和政府在日?；顒印⒐芾砗蛻?zhàn)略戰(zhàn)術(shù)決策時越來越依賴于軟件，因此必須確保軟件的質(zhì)量； 鑒于軟件開發(fā)成本巨大，因此必須確保開發(fā)出來的軟件能夠滿足目標用戶的真實 要求； 隨著軟件越來越復(fù)雜，其開發(fā)和實際也越來越復(fù)

2、雜，必須確保開發(fā)活動的有序、 有效； 隨著軟件用戶數(shù)量和壽命的增加，對其適應(yīng)性、可擴展性的要求也在增加。必須確保軟件具備良好的可維護性。 2.軟件工程定義 軟件工程是對合理工程原則的建立和使用，最經(jīng)典的定義：其目的是為了經(jīng)濟地 獲得可靠的、可以在實際機器上高效運行的軟件。 IEEE給出的定義：將系統(tǒng)化的、規(guī)范的、可量化的方法應(yīng)用于軟件的開發(fā)、運行 和維護。即將工程化方法應(yīng)用于軟件。 課程給出的定義：軟件工程是為了經(jīng)濟的開發(fā)出高質(zhì)量的軟件，并有效的維護它，將工程、管理手段與技術(shù)手段相結(jié)合應(yīng)用于軟件的方法的集合 目的：經(jīng)濟的開發(fā)出高質(zhì)量的軟件，并有效的維護它 方法：將工程、管理手段與技術(shù)手段相結(jié)合

3、 3.軟件工程要實現(xiàn)多個目標，這些目標之間的重要性不一樣價值觀問題 軟件工程的目標如下：又好又快 ? 保證軟件質(zhì)量 ? 提升開發(fā)效率、降低開發(fā)成本 ? 提高維護效率、降低維護成本 4.軟件的定義：計算機系統(tǒng)中與硬件相互依存的另一部分，是程序、數(shù)據(jù)及其相 關(guān)文檔的完整集合。軟件是邏輯的而非物理的系統(tǒng)元素。 . . 5.軟件的特點： ? 沒有物理實體 ? 設(shè)計開發(fā)成本高昂，生產(chǎn)復(fù)制則幾乎是零成本的 ? 軟件不會磨損、老化，但是也會退化 軟件退化：隨著軟件的維護升級，軟件結(jié)構(gòu)逐漸偏離原有設(shè)計并導(dǎo)致了軟件質(zhì)量的下降，稱為軟件退化。 ? 軟件發(fā)展的速度落后于硬件和實際需求 ? 軟件占計算機系統(tǒng)成本的比重

4、越來越大 ? 軟件開發(fā)尚未真正實現(xiàn)標準化 6.軟件與程序的區(qū)別： 軟件不僅僅只是計算機程序 7.軟件工程組成： 軟件工程是一種層次化的技術(shù) ? 質(zhì)量優(yōu)先是整個軟件工程的核心價值觀（以質(zhì)量為中心） ? （軟件）過程：由為建造、維護高質(zhì)量軟件所需要完成的一系列相互關(guān)聯(lián)的活動組成的框架，即形成軟件產(chǎn)品的一系列步驟。過程是軟件工程管理和實 施的基礎(chǔ)。 ? 方法：軟件開發(fā)和維護過程中一些具體問題的最佳解決手段。方法是軟件工 程的核心手段 ? 工具：為實現(xiàn)軟件工程中各種過程和方法的自動化和半自動化而開發(fā)的程序系統(tǒng)。工具是軟件工程的效率倍增器。 8.軟件工程必須重視人員的培訓(xùn)。 9.軟件工程中的相關(guān)人員：

5、? 用戶User：軟件使用者。目的是使用軟件解決問題或提高工作效率。 ? 客戶Customer：為軟件付錢的人。他們的目標是增加利潤，或只是使業(yè)務(wù)運作更為有效。 ? 軟件開發(fā)人員Developer：開發(fā)并維護軟件的人。 ? 開發(fā)管理人員Manager：管理軟件開發(fā)過程的人員。其目標是花最少的錢滿足客戶要求 10.軟件神話：關(guān)于軟件及其開發(fā)過程的一些錯誤說法。 ? 神話一：因為軟件是由彈性的，因此可以很容易的適應(yīng)需求變化。（修改軟件要付出成本） ? 神話二：如果我們無法按時完成計劃，可以通過增加電腦和程序員人數(shù)趕上速度。 ? 神話三：軟件過程就是嚴格按照完成的軟件開發(fā)標準和規(guī)程來開發(fā)軟件。（錯在

6、把手段當(dāng)成了目的，應(yīng)該根據(jù)項目實際需要，靈活安排實際的軟件過程活動） ? 神話四：當(dāng)程序編寫完成并交付給客戶后，任務(wù)就完成了，因此應(yīng)該盡快開始編寫代碼。 . . ? 神話五：軟件工程會導(dǎo)致我們產(chǎn)生大量無用的文檔，因此降低了效率。（創(chuàng)建文檔的目的是保證開發(fā)軟件的質(zhì)量）文檔最重要的作用是（1）促使開發(fā)者認真思考和（2）促進交流。 CH1 軟件過程與方法 本章重點： ? 過程管理的任務(wù) ? 過程的定義 ? 五個核心軟件活動 ? 幾種軟件過程模型，其活動間的順序關(guān)系是怎樣的（順序、迭代、演化還是并行？） ? 原型及其作用 ? 敏捷開發(fā)的價值觀 ? 敏捷開發(fā)的基本推動力 1.過程管理：辨識出一連串的商業(yè)

7、活動，并針對這些活動的作業(yè)流程進行管理。 2.過程管理的目標： ? 確保企業(yè)中各種商業(yè)活動的執(zhí)行成果能具有一定的水平和精確度。 ? 確保能持續(xù)改善活動的進行方式，串連活動的作業(yè)流程 ? 讓企業(yè)能保持市場上的競爭力 3.過程管理的任務(wù)： ? 尋找、發(fā)現(xiàn)企業(yè)中有價值的業(yè)務(wù)過程（過程識別） ? 發(fā)現(xiàn)、去除非增值活動，簡化過程；通過合理安排活動順序提高過程效率（過程梳理和優(yōu)化） ? 對過程各個活動進行規(guī)范，形成標準（過程固化） ? 對過程執(zhí)行情況加以監(jiān)控（過程監(jiān)控） ? 尋找過程中的錯誤、薄弱、低效環(huán)節(jié)并加予以糾正（過程改進） 4.過程：也稱業(yè)務(wù)過程，指為客戶創(chuàng)造價值的一系列相互關(guān)聯(lián)、有組織的活動或任

8、務(wù)的集合。 ? 管理學(xué)意義上的過程是有明確目的性的：為客戶（或企業(yè)）創(chuàng)造價值 5.（業(yè)務(wù)）過程的特點： ? 可確定性：有明確的輸入、輸出和邊界； ? 順序：構(gòu)成過程的活動，必須在時間和空間里具有確定的順序； ? 客戶：過程的結(jié)果必須有接收者客戶。 ? 增值：在過程中發(fā)生的轉(zhuǎn)換必須為接收者增加價值，無論接收者是在過程的上游還是下游。 6.軟件過程：構(gòu)建、維護軟件產(chǎn)品時所執(zhí)行的一系列步驟（活動、動作和任務(wù)） 的集合。 ? 活動：組成軟件過程的最主要的宏觀步驟。 . . ? 例如：需求分析、設(shè)計、編碼、發(fā)布等。 ? 動作：對活動進一步細分的得到的步驟。 ? 例如設(shè)計活動，可以細分分為總體設(shè)計、模塊設(shè)

9、計等多個動作。 ? 任務(wù)：具體的工作步驟 7.核心軟件活動：所有合理的軟件過程都包含一些共同的必要的活動（步驟），這些活動我們稱為核心軟件活動。 軟件過程通常包括下列五個核心軟件活動：8. ? 需求分析：通過與客戶的溝通協(xié)作，了解客戶的真實需要，決定軟 件特性和功能，制定項目目標。 ? 建模（設(shè)計）：通過構(gòu)造軟件模型(通常是圖形形式的模型）的方法來研究、理解具體問題，（向客戶和其他開發(fā)人員）展現(xiàn)具體解決方案。 ? 編碼與測試：實際編寫代碼、驗證代碼的正確性 ? 運行與部署：將軟件交付用戶使用。通常用戶會對軟件進行一段時間的試用，并給出反饋意見 ? 維護：修復(fù)用戶使用過程中發(fā)現(xiàn)的軟件缺陷，或者根

10、據(jù)用戶使用意見對軟件進行改進 9.在實際軟件過程中往往還存在一些貫穿整個過程的普適性活動，以幫助軟件團隊管理和控制項目進度、質(zhì)量、變化和風(fēng)險。項目管理的角度說，這些“普適性活動”實質(zhì)上是項目管理活動。常見普適性活動包括： ? 策劃：創(chuàng)建軟件項目的“地圖”，以指導(dǎo)團隊的項目旅程。通常包括：需要執(zhí)行的具體任務(wù)、每個任務(wù)需要的資源分配，每個任務(wù)的具體產(chǎn)品，以及工作計劃等 ? 項目跟蹤和控制：定期評估項目進度情況，采取必要措施確保項目按期完成 ? 風(fēng)險管理：對可能影響項目進度和產(chǎn)品質(zhì)量的風(fēng)險進行評估，并采取必要措施來降低風(fēng)險 ? 測量：定義和采集關(guān)于過程、項目和產(chǎn)品的度量數(shù)據(jù)，以幫助管理和改進其他活動

11、。例如：開發(fā)人員的生產(chǎn)率等 ? 軟件質(zhì)量保證：確保軟件質(zhì)量的措施和活動 ? 軟件配置管理：管理軟件（代碼、配置信息及其文檔）的版本變化歷史 ? 可復(fù)用管理：建立產(chǎn)品（代碼等）復(fù)用的機制和標準（如公用函數(shù)庫等） ? 人員培訓(xùn)：對相關(guān)人員進行必要的培訓(xùn)，使其具備必要的知識和技能，掌握相關(guān)工具的使用方法 10. 軟件過程模型是從一特定角度提出的軟件過程的簡化描述。 過程流（模型）是最主要的一類軟件過程模型。 過程流描述了如何在執(zhí)行順序和執(zhí)行時間這一層面上，組織軟件過程中（除維護之外的）的活動。 11.幾種主要的過程流及典型過程模型： ? 線性過程流：瀑布模型 ? 迭代過程流：原型開發(fā)模型 . . ?

12、 演化過程流：螺旋模型 ? 并行過程流 ? 混合過程流：增量模型 瀑布模型：又稱軟件生存周期模型，瀑布模型嚴格按照軟件生存周期各個階12.并強調(diào)每一階段的嚴格性。上一階段的輸出即是下一階段的輸入，段來進行開發(fā)，每一階段的任務(wù)完成后，都必須對其階段性產(chǎn)品（主要是文檔）進行評審，通過 后才能開始下一階段的工作。 的模型是一種以文檔作為驅(qū)動：軟件從定義開始，經(jīng)過開發(fā)、使用和維護，直到最終退役軟件生存周期? 軟瀑布模型將軟件生命周期分成軟件定義、軟件生存周期。的全過程稱為 件開發(fā)、運行、維護及退役五個時期組成。 可強迫開發(fā)人員采用的規(guī)范方法； 優(yōu)點：? 嚴格規(guī)定了每一階段必須提交的文檔； 要求每一階段

13、交付之產(chǎn)品都必須經(jīng)過質(zhì)量保證小組的仔細審查； 清晰區(qū)分了邏輯設(shè)計與物理設(shè)計，盡可能推遲程序的物理實現(xiàn)； 有利于大型軟件開發(fā)過程中人員的組提供了軟件開發(fā)的基本框架，織、管理，有利于軟件開發(fā)方法和工具的研究與使用，因此，在軟件工程 中占有重要的地位。 要求在項目開始的需求分析階段就能夠完整的得到客戶的所有需求，缺點：? 現(xiàn)實中很難實現(xiàn)客戶要到項目接近尾聲的驗收階段才能夠看到實際的程序執(zhí)行效 就可能會造成重大如果這時才發(fā)現(xiàn)程序和客戶實際要求有重大偏差，果。 的損失 13.原型開發(fā)模型： 直觀的感用戶可在原型上進行操作，就是軟件的一個原型，模擬的可執(zhí)行界面。 受軟件的執(zhí)行效果。 向原型開發(fā)就是軟件開發(fā)

14、人員根據(jù)用戶提出的軟件基本需求快速開發(fā)一個原型，完善進一步改進、在征求用戶對原型的評價意見后，用戶展示軟件界面和功能。 直到軟件開發(fā)人員和用戶都確認軟件系統(tǒng)的需求并達成一致的如此迭代，原型， 理解為止。 優(yōu)點： . . 有利/客戶共同參與的迭代過程，? 原型的開發(fā)和評審時系統(tǒng)分析員和用戶 于雙方充分理解和溝通。比瀑布模型更符合人們認識事物的過程和規(guī)律，項目成員能夠更清晰的 ? 理解用戶實際需求。如果原型的開發(fā)語言和實際軟件相同，那么它的若干高質(zhì)量的程序片段? 和開發(fā)工具也可被用于工作程序的開發(fā)。 快速的開發(fā)原型?？焖僭偷拈_發(fā)途徑：原型僅僅是需求分析的一部分，因此必須盡可能 在運行效率建造原型

15、應(yīng)盡量采用相應(yīng)的軟件工具和環(huán)境，并盡量采用軟件重用技術(shù)， 如人機界面、同時，原型應(yīng)充分展示軟件系統(tǒng)的可見部分，方面可做出讓步，以便盡快提供。 數(shù)據(jù)的輸入方式和輸出格式等。 缺點： 原型開發(fā)模型要求開發(fā)者和用戶在一段時間內(nèi)緊密配合、共同參與完成? 原型系統(tǒng)的開發(fā)，特別是需要用戶的及時反饋。如果用戶對此不夠重視， 那么原型開發(fā)的意義也就大打折扣了。很快讓用戶誤以為實際軟件的開發(fā)也是可以很容易、原型的快速構(gòu)造容易? 或者要求開發(fā)者直接將原型稍加修改使之成為實際運行的產(chǎn)品。就完成的，開發(fā)者往往會犧牲軟件質(zhì)量和可維護性而為了快速開發(fā)原型，? 而實際上，因此實際的高質(zhì)量軟件產(chǎn)品需要拋棄原型從頭采取了最快速

16、的開發(fā)手段， 開發(fā)。 ?如果不能夠充分的向客戶解釋這一點的話，就容易導(dǎo)致軟件開發(fā)人員和用 戶之間產(chǎn)生矛盾。 沒有解決需求變化的問題原型開發(fā)模型最大的缺點在于，它仍然。 ? 的軟件過程模型。結(jié)合了原型開發(fā)模型的迭代性和瀑螺旋模型：一種14.演化式 布模型的系統(tǒng)性和可控性特點。 、風(fēng)險分析、工程實現(xiàn)和評螺旋模型的每一個迭代周期都包括計劃（需求定義） 個階段。審4 周左2-8每個迭代周期都不應(yīng)該太長（一般是螺旋模型是一個風(fēng)險驅(qū)動的模型， 右） 螺旋模型優(yōu)點：? 支持用戶需求的動態(tài)變化 ? 原型可看作形式的可執(zhí)行的需求規(guī)格說明，易于為雙方共同理解；開發(fā)者和用戶共同參與軟件開發(fā)，可盡早發(fā)現(xiàn)軟件中的錯誤。

17、 ? 螺旋模型特別強調(diào)原型的可擴充性和可修改性。既保持瀑布模型的系統(tǒng)性、階段性，又可利用原型評估降低開發(fā)風(fēng)險。 ? 螺旋模型為項目管理人員及時調(diào)整管理決策提供了方便，進而可降低開發(fā)風(fēng) 險 . . 螺旋模型缺點： ? 如果每次迭代的效率不高，致使迭代次數(shù)過多，將會增加成本并推遲提交時間 ? 使用該模型需要有相當(dāng)豐富的風(fēng)險評估經(jīng)驗和專門知識，要求開發(fā)隊伍水平較高 適用場合：支持需求不明確、特別是大型軟件系統(tǒng)的開發(fā)，并支持面向規(guī)格說明、面向過程、面向?qū)ο蟮榷喾N軟件開發(fā)方法 增量過程模型：螺旋模型基礎(chǔ)上的改進。采用并行方式 15.解決阻塞帶來的浪費問題 16.敏捷開發(fā)提出的背景： 傳統(tǒng)過程開發(fā)模型都是

18、從管理者的角度來看待軟件開發(fā)，存在重大缺陷： 忽視變化的存在；忽視了軟件開發(fā)是一個智力密集型的工作；忽視了人與人之間的直接交流；過分注重過程。 17.敏捷開發(fā)宣言：敏捷開發(fā)的價值觀 ? 個人與交流 勝于 開發(fā)過程和工具 可運行的軟件? 勝于 面面俱到的文檔 客戶協(xié)作 ? 勝于 合同談判 響應(yīng)變化 ? 勝于 按部就班遵循計劃 18.敏捷的基本推動力：普遍存在的變化 19.敏捷鼓勵： ? 使溝通更便利的團隊結(jié)構(gòu)和協(xié)作態(tài)度 ? 快速交付可運行產(chǎn)品而非中間文檔 ? 客戶以開發(fā)團隊中的一員的身份參與項目 ? 根據(jù)實際情況靈活調(diào)整項目計劃 20.敏捷開發(fā)非常強調(diào)人的因素在軟件項目開發(fā)中的重要性 敏捷開發(fā)強

19、調(diào)團隊及其成員應(yīng)該具備下列要素：基本能力、共同目標、精誠合作、 決策能力、相互尊重和信任、不斷學(xué)習(xí)、自我組織。 21.敏捷過程模型： ? 極限編程（eXtreme Programming,XP） ? Scrum ? 特征驅(qū)動開發(fā)（FDD） ? 精益軟件開發(fā)（LSD） ? 統(tǒng)一過程（AUP） 22.極限編程： . . 定義了五個有重要意義的要素：XP 溝通：強調(diào)口頭的、面對面的交流? 當(dāng)設(shè)計需要改進時，為了簡化設(shè)計，只對當(dāng)前的需要做設(shè)計。 簡明：? 重來實現(xiàn)使用 ：通過測試、增量交付和持續(xù)集成等手段，快速獲得反饋 ?反饋 ：鼓勵符合極限精神的實踐。例如，盡可能減少過度設(shè)計。? 鼓勵以及內(nèi)部成員與

20、其他利益相關(guān)敏捷團隊?wèi)?yīng)在內(nèi)部成員之間， 尊重：? 者之間，灌輸相互尊重的思想。減少推諉和扯皮，增加協(xié)作。 23. Scrum是一種迭代式增量軟件開發(fā)過程 15-30天周期沖刺：一個 在沖刺的過程中，沒有人能夠變更沖刺訂單，強調(diào)開發(fā)和運營的密切協(xié)作，運營軟件過程領(lǐng)域最新的流行趨勢是DevOps24.也強調(diào)最新部門在軟件的產(chǎn)品設(shè)計、開發(fā)和測試過程中都要深度介入。DevOps 工具，如持續(xù)集成等自動化工具的使用，以提高工作效率并實現(xiàn)快速反應(yīng)。 小結(jié)：25. 需要將軟件開發(fā)劃分為一系列規(guī)范化的步驟，使之便于實施和管理。? 軟件開發(fā)需要客戶的深入?yún)⑴c和合作? ?軟件開發(fā)的主體是人，必須重視人的需求和交流

21、溝通 ? 軟件開發(fā)過程必須具備高度的靈活性，以適應(yīng)變化。對管理者也提出總之，軟件開發(fā)過程在不斷引入新的技術(shù)和工具的同時， ? 了越來越高的要求 CH2 需求分析概述 本章重點： 軟件需求的概念? 需求分析的目標? 功能需求與非功能需求? ? 企業(yè)管理各個層級對信息系統(tǒng)的需求主要是什么？企業(yè)管理信息系統(tǒng)可分為哪兩大模塊，各自對應(yīng)哪個管理層級的需求 ? 需求分析的五個階段（都做什么）； ? 需求跟蹤與需求狀態(tài)跟蹤各自都做什么？ . . 1.導(dǎo)致項目不能按計劃完成的最重要的三個原因是： ? 缺少用戶反饋（12.8%） ? 需求不完整（12.3%） ? 需求變化（11.8%） 軟件需求是決定軟件開發(fā)成

22、敗的關(guān)鍵因素 2.(軟件)需求(Requirement)：為了解決客戶的特定問題，軟件所必須提供的能力和必須遵從的約束條件。 3.需求分析：項目人員確定用戶需求所需要做的工作 需求分析的目標： ? 弄清楚客戶/用戶究竟想用軟件來干什么。 ? 弄清楚用戶究竟想怎么用。 ? 讓客戶明確他最終能得到什么樣的產(chǎn)品 需求分析的成果：軟件需求說明書 4.需求通常分為功能需求和非功能需求兩大類 功能需求：描述系統(tǒng)應(yīng)該提供的功能或服務(wù)，通常涉及用戶或外部系統(tǒng)與該系統(tǒng)之間的交互。即軟件必須提供的能力。 ? 業(yè)務(wù)需求、用戶需求、功能需求、系統(tǒng)需求 非功能需求：從各個角度對系統(tǒng)的約束和限制，反映了應(yīng)用對軟件系統(tǒng)質(zhì)量

23、和特性的額外要求，例如響應(yīng)時間、數(shù)據(jù)精度、可靠性、開發(fā)過程的標準等。即軟件的約束。非功能需求難以被測試和雁陣；容易被忽視。 業(yè)務(wù)規(guī)則、質(zhì)量屬性、外部接口、約束條件 5.除非必要，否則需求中不應(yīng)該包含技術(shù)細節(jié) 6.軟件需求的固有困難： ? 用戶不一定清楚的知道他到底想要什么； ? 軟件開發(fā)人員不了解項目的業(yè)務(wù)背景知識； ? 日常交流所用的語言文字本身具有很大的模糊性； ? 用戶企業(yè)不同部門之間需求彼此矛盾； ? 用戶的需求經(jīng)常會發(fā)生變化 7.需求工程就是：形式化、工程化的需求分析 8.軟件需求工程的五個階段 ? 需求獲?。很浖_發(fā)人員通過與用戶之間的有效溝通,了解用戶對軟件真實需要的過程。 本質(zhì)

24、：開發(fā)人員與用戶間的溝通 目的：了解用戶對軟件的真實需要 需求獲取的內(nèi)容： ? 客戶的戰(zhàn)略 ? 相關(guān)的業(yè)務(wù)過程 ? 相關(guān)規(guī)章制度、業(yè)務(wù)規(guī)則等 ? 相關(guān)票據(jù)、記錄、報表等 業(yè)務(wù)規(guī)則:描述業(yè)務(wù)處理可能遇到的情況及相應(yīng)的處理措施或約束。 需求獲取方法：個別訪談、會議、調(diào)查、觀察 . . ? 需求分析與協(xié)商：對需求獲取采集的信息進行匯總、分析，形成詳細、規(guī)范的需求描述。 需要獲取的成果最終必須以可見成果的形式描述出來 需求描述工具： ? 用例：一段用文字表述的故事，闡述用戶如何使用軟件來實現(xiàn)某個具體的業(yè)務(wù)目標。 相關(guān)工具：系統(tǒng)范圍圖/表 業(yè)務(wù)流程圖（活動圖） 用戶目標表：用表格形式匯總展現(xiàn)系統(tǒng)所涉及的

25、全部用例及其優(yōu)先級(用例的目錄) 用戶情況表 數(shù)據(jù)流模型：用圖形方式表示數(shù)據(jù)的輸入、輸出和加工過程。 ? 需求規(guī)約：形成正式需求分析文檔的過程 軟件需求說明書（軟件需求規(guī)約，SRS）是分析任務(wù)的最終產(chǎn)物，是用戶和開發(fā)者雙方對于軟件產(chǎn)品要求的正式約定。 需求說明書模板： ? 第一章 目標與范圍 ? 1a 項目的整體范圍與目標是什么？ ? 1b 利益相關(guān)者（Who cares?） ? 1c 項目范圍內(nèi)包括什么？什么不在項目范圍內(nèi)？ ? 第二章 詞匯表 ? 第三章 用例 ? 3a 項目的主要參與者與他們的目標 ? 3b 概要級別用例（以主要參與者的視角來分別描述各個主要的業(yè)務(wù)流程） ? 3c 用戶目

26、標級別用例（具體描述主要參與者如何使用系統(tǒng)來實現(xiàn)他們的目標） ? 3d 用戶目標表 ? 第四章技術(shù)要求 ? 第五章其他要求 ? 第六章人工備份、法律、政治與組織問題 ? 需求驗證 ? 需求管理：是一組用于幫助項目組在項目進展中的任何時候去標識、控制和跟蹤需求的活動 . . 目的：? 保障需求說明書與產(chǎn)品的一致性? 控制需求變更對項目開發(fā)的影響? 使需求活動與計劃保持一致? 內(nèi)容：變更控制? 版本控制 需求跟蹤 需求狀態(tài)跟蹤 需求變更：在軟件需求基線已經(jīng)確定之后又要添加新的需求或進 ? 行較大的需求變動。需求變更管理：由專人統(tǒng)一負責(zé)接收、評估、審批和實施需求變 更請求 需求變更管理的目的：確保需

27、求變更的利大于弊需求跟蹤：在軟件開發(fā)的全過程中，記錄和維護每項需求與軟件 ?其他系統(tǒng)元素（如設(shè)計模塊、程序代碼、測試用例等等）之間的 關(guān)系設(shè)計編程測試”之間的作用：建立與維護“需求其他需求- 一致性 方式：正向跟蹤、逆向跟蹤、雙向跟蹤 目的： 確保所有的工作成果最終符合用戶需求。? 當(dāng)需求發(fā)生變更時能夠快速定位所有被影響的系統(tǒng)元素? 是表示需求和其他系統(tǒng)元素之間的聯(lián)系鏈的RTM）需求跟蹤矩陣（ 一種常用工具 （即其在當(dāng)在項目整個生命周期中對項目所處狀態(tài)需求狀態(tài)跟蹤： 前時刻的情況）進行追蹤. . 目的：確保用戶提出的每一項需求都得到了妥善的處理 工具：單獨的需求狀態(tài)跟蹤表；也可合并到需求跟蹤矩

28、陣中 管理層級與信息系統(tǒng)9. 數(shù)據(jù)流關(guān)注：績效指標體系和 關(guān)注：用戶使用場景和業(yè)務(wù)流程 還要關(guān)注：崗位與權(quán)限、數(shù)據(jù)量 不能說的秘密：需求分析必須重視利益干系人10. CH3 需求分析場景分析與用例 本章重點： ? 用例的組成部份及其寫法 ? 各用例相關(guān)工具的作用 ? 用例圖的畫法 活動圖的畫法? 基于用例的場景分析? 1. 需求分析的兩個最主要的視角： 業(yè)務(wù)（流程）視角? 績效（信息）視角? 來描述企業(yè)業(yè)務(wù)核心的一套方法和工具為2.目前的主流是使用以用例 用戶的使用場景來獲取需求的技術(shù)。Use Case用例（）：一種通過描述 客觀（第三者視角）描述使用場景 的行為描述；對業(yè)務(wù)場景中有明確目標的

29、參與者之間 契約。利益相關(guān)方關(guān)于（待開發(fā)）系統(tǒng)行為的用例是 3.用例的組成 ? 用例名稱 賓語結(jié)構(gòu)詞組或簡短的主謂賓結(jié)構(gòu)短語 ?動詞、動詞+ ?能夠清晰的用例的功能或要實現(xiàn)的反映目標. . 參與者及其目標? 的人事物。行為或職責(zé)參與者（Actor）是在用例中具有參與者可能是人，也可能是某個組織（部門、企業(yè)），還可能是某個軟硬 ）一般不會作為參與者。件系統(tǒng)。待分析的系統(tǒng)（SuD實現(xiàn)其目SuD：SuD的主要服務(wù)目標或使用對象。使用? 主要參與者 標。 提供服務(wù)的參與者：為SuD協(xié)助參與者? 利益相關(guān)者及其關(guān)注點? 利益相關(guān)者。間接受用例影響的組織或個人，我們稱之為 確保利益相關(guān)者的利益得到了切實的

30、保護SuD必須 范圍與目標級別? 范圍界定了用例中要分析的系統(tǒng) 目標級別：描述用例中主要參與者的目標層級 研如采購流程、概要：描述企業(yè)業(yè)務(wù)流程或用戶流程的總體步驟，? 發(fā)流程等（可能跨度很長；可能涉及多個非系統(tǒng)參與者）主要參與者使用業(yè)務(wù)流程中的某一步，在這一步驟中，? 用戶目標： 待開發(fā)系統(tǒng)來實現(xiàn)一個具體的目標。如（超市）用戶結(jié)賬等。（超對用戶目標級別用例中的單個步驟的進一步描述，如? 子功能：市）用戶刷卡付款等。 判斷： ? （圖書館管理系統(tǒng)）讀者登錄 ? （圖書館管理系統(tǒng)）讀者借書 ? （超市管理系統(tǒng)）用信用卡支付 ? （超市管理系統(tǒng)）處理退貨 ? （超市管理系統(tǒng)）尋找供貨商 ? （ATM

31、系統(tǒng)）使用ATM取現(xiàn)金 ? (ATM系統(tǒng)）使用ATM修改密碼 ? (ATM系統(tǒng)）使用ATM辦理業(yè)務(wù) ? 前置條件：在用例中的場景開始之前，必須保證為真的條件 用例中不要出現(xiàn)對前置條件進行檢查的步驟 可以不寫 觸發(fā)條件：導(dǎo)致用例中的場景開始的事件。 基本保證：在用例執(zhí)行后，系統(tǒng)對各利益相關(guān)者的利益的最小保證 ? 無論用例最終執(zhí)行是否成功，系統(tǒng)都必須確?；颈ＷC中的承諾。 成功保證：承諾如果用例成功執(zhí)行完畢，利益相關(guān)者的哪些利益將會得到滿足（不重復(fù)基本保證中的內(nèi)容） ? 主成功場景和步驟 ? 擴展描述了用例中的其他所有場景或者場景分支片段 ? 為什么擴展是需求中最容易出問題的部分？ ? 擴展中主要

32、是各種異?；蝈e誤情況的處理。 ? 這往往是業(yè)務(wù)人員并不熟悉的。 ? 不熟悉就會導(dǎo)致遺漏。 ? 一個只能處理正常情況的系統(tǒng)顯然不是一個完善的系統(tǒng)。 . . 即使擴展中的異常情況系統(tǒng)最終不處理或無法處理，預(yù)先把它寫出來，甲乙雙方充分討論，能夠避免以后的扯皮 ? 觸發(fā)條件：對應(yīng)于主成功場景中的某個步驟的特殊情況。在該步驟中，如果滿足該觸發(fā)條件，則改為執(zhí)行擴展場景。（注意序號的對應(yīng)，數(shù)字代表步驟，字母代表觸發(fā)條件） ? 目標：消除異?；蛱厥馇闆r，以繼續(xù)執(zhí)行主成功場景 ? 場景結(jié)束：通常是重新并入主成功場景（缺省情況），或者是中止處理（即處理失?。?? 其他 鏈接、特殊需求（與用例直接相關(guān)的非功能性需求

33、、質(zhì)量屬性或約束）、技術(shù)和數(shù)據(jù)變元表（用戶對于系統(tǒng)實現(xiàn)的特殊技術(shù)要求）因為用例中避免設(shè)計和實現(xiàn)細節(jié)、發(fā)生頻率、優(yōu)先級、未決問題 用例相關(guān)工具4 項目愿景：用一兩句話對項目目標做出的概括性描述。幫助項目團隊成員建立起共同的項目目標 設(shè)計范圍圖：以直觀圖形的方式描述系統(tǒng)范圍。通常使用UML用例圖。 In/Out表：一個簡單的工作主題列表，用于幫助討論和確定系統(tǒng)范圍。 用戶目標列表：匯總列出系統(tǒng)的主要使用者、目標及其優(yōu)先級 用戶情況表：匯總列出系統(tǒng)所有使用者的背景、技能水平等情況。 用例應(yīng)該讓用戶來寫。 5.用例圖：用于描繪用例、系統(tǒng)、參與者及其之間的關(guān)系（語境圖） 主要參與者系統(tǒng)（多個用例）協(xié)助參

34、與者 作用： ? 展示系統(tǒng)邊界 ? 展現(xiàn)關(guān)系 A泛化參與者B，表明參與者B參與的所有用例也被參與者參與者泛化：參與者A參與 6.活動圖（本質(zhì)是流程圖） . . 基本組成元素：活動：流程中的一個步驟。動作：基礎(chǔ)的、邏輯上內(nèi)部不能再細分的活動，是 活動圖中的最小UML 分支與合并都會發(fā)生、但發(fā)生次序任意（一個時間段內(nèi)，同 分叉與匯合：顯示并行線程 時進行的活動） 甬道本身沒有順序用垂直實線分隔每個活動只能明確屬于一個甬道 甬道 7.活動圖與用例 活動圖不能替代用例，因為用例中還有利益相關(guān)者及其關(guān)注點等大量信息。? 活動圖能代替用例中的場景描述嗎？?因為目標級別用例存在大量擴展分支；不能。對于用戶目

35、標級別的用例而言： 過多分支會導(dǎo)致活動圖難以理解 的用例適合輔助表達概要級別 基于用例的場景分析：自頂向下的過程8. &核心業(yè)務(wù)是啥）找出企業(yè)中需要信息化的業(yè)務(wù)過程。（有哪些業(yè)務(wù)? ）劃分為規(guī)范的步驟，并加以描述（概要級Business Process? 將業(yè)務(wù)過程（ 別用例）（用用例和活動圖） 針對過程中的每個步驟編寫對應(yīng)的使用場景（用戶目標級別用例）? CH4 需求分析數(shù)據(jù)流分析 本章重點：DFD 如何繪制? KPI 什么是? . . 1.數(shù)據(jù)流圖（DFD）：描繪軟件系統(tǒng)邏輯模型的圖形工具 2. DFD分層：按照系統(tǒng)的層次結(jié)構(gòu)進行逐步分解 子圖是對父圖中某一加工步驟的詳細展開； 每一層所包

36、含的加工通常不超過7個； 各層數(shù)據(jù)流保持平衡：父圖中某加工的輸入輸出數(shù)據(jù)流應(yīng)該同其子圖的輸入輸出相同(相對應(yīng)）。 3.系統(tǒng)環(huán)境圖（頂層數(shù)據(jù)流圖）0層DFD 僅包括一個數(shù)據(jù)處理過程，也就是要開發(fā)的目標系統(tǒng) 作用是確定系統(tǒng)邊界 4.數(shù)據(jù)字典 若X,a,b都是數(shù)據(jù)項 ? X= a + b x由a和b構(gòu)成 ? X= a , b x由a或b構(gòu)成 ? X= a | b x由a或b構(gòu)成 ? X= (a) a可在x中出現(xiàn)，也可能不出現(xiàn) ? X= a x由0次或多次重復(fù)的a構(gòu)成 ? X= man x由m至n個a組成，即至少有m個a,至多有n個a ? X= a.b x可以取a至b的任一值 ? X= “a” x為取

37、值a的基本數(shù)據(jù)元素，即a無需進一步定義 5.DFD繪制步驟 ? 識別數(shù)據(jù)源、數(shù)據(jù)流和存儲 ? 建立系統(tǒng)環(huán)境圖，確定系統(tǒng)邊界 ? 自頂向下，逐步求精，建立逐層建立系統(tǒng)的DFD ? 定義數(shù)據(jù)流、數(shù)據(jù)存儲的內(nèi)容和結(jié)構(gòu)（數(shù)據(jù)字典） ? 給出加工的具體信息，如，如業(yè)務(wù)規(guī)則等 6.DFD的缺陷 完全聚焦于信息處理本身，對實際業(yè)務(wù)的描述不全面 7.關(guān)鍵績效指標KPI 通過對組織業(yè)務(wù)流程的關(guān)鍵參數(shù)進行設(shè)置、取樣、計算、分析，從而得到的用于衡量流程績效的一套目標式量化管理指標 理論依據(jù)：20/80原則（帕累托原則） KPI業(yè)績考評體系是一整套覆蓋各項職能和各個層級的關(guān)鍵業(yè)績指標管理系統(tǒng)，是從分析和計劃、匯報和指

38、導(dǎo)、考核等三個方面實現(xiàn)管理規(guī)范化，提高業(yè)務(wù)水平 KPI是企業(yè)管理信息系統(tǒng)的數(shù)字儀表盤中儀表的來源。 KPI體系制定： 第一步：開發(fā)業(yè)務(wù)“價值樹”； 第二步：確定影響大的“關(guān)鍵業(yè)績指標”； 第三步：將“關(guān)鍵業(yè)績指標”分配給有關(guān)經(jīng)理； 第四步：確定 “關(guān)鍵業(yè)績指標”的目標。 ? 需求分析階段，必須落實KPI與報表中每一項指標的： ? 計算方法 ? 數(shù)據(jù)來源 OOP建模 . . 本章重點 ? 對象與類的關(guān)系 ? 什么是封裝;封裝的意義 ? 什么是繼承;什么是多態(tài) ? 什么是覆蓋, 什么是動態(tài)綁定 ? 什么是接口 1.為什么要面向?qū)ο?從本質(zhì)上說：軟件開發(fā)過程是一個開發(fā)人員對開發(fā)項目不斷深入學(xué)習(xí)、理解

39、和認識，并將其用代碼的形式固化的過程 認識復(fù)雜事物的兩種主要方法：抽象（舍棄次要特征）和分治 2.面向?qū)ο?? 以對象而非數(shù)據(jù)作為問題表示和描述的基本單位 ? 用日常認識世界的思維來指導(dǎo)軟件開發(fā) ? 變解決問題為認識問題、用程序來反映的問題的認識 ? 是抽象和分治方法的綜合應(yīng)用 ? 本質(zhì)上是以人為本，是軟件工程的返樸歸真！ 3.對象：一組數(shù)據(jù)和操作的集合；現(xiàn)實概念、問題在程序中的反應(yīng)；是對人類抽象思維基本單位“概念實體”的直接模擬 概念實體具有：靜態(tài)屬性和動態(tài)特征 即把非生物對象當(dāng)成能聽懂我們命令的生物，將它能夠?qū)崿F(xiàn)的被動行為當(dāng)作它的動態(tài)特征。 數(shù)據(jù)：屬性；操作：方法 面向?qū)ο螅∣bject

40、Oriented）：使用對象作為基本單位來認識問題、設(shè)計開發(fā)程序 4.類：創(chuàng)建對象的模板。對象：類的實例 ? 類與對象之間的關(guān)系是抽象與具體的關(guān)系： ? 對象是對所研究的某一個具體事物的邏輯簡化。 ? 而類是對同一類事物的抽象和歸納，相當(dāng)于概念。 ? 狗是一個類，我養(yǎng)的那只小狗就是一個對象。 ? 類創(chuàng)建對象的模板，類定義決定了該類型對象所具備的屬性和行為。 ? 只有先定義類，才能去定義該類對象。 ? 變量中保存的是對象，變量的類型是類。 實例對象產(chǎn)品 概念類模具 5.面向?qū)ο蟮娜齻€主要特性：封裝、多態(tài)、繼承 6.封裝： ? 把數(shù)據(jù)和及其對應(yīng)的操作（方法）用對象和類的形式組織起來，使之形成一個有

41、機的整體 ? 將數(shù)據(jù)處理的細節(jié)隱藏在對象內(nèi)部，外部無法干擾 封裝的目的： ? 隱藏對象的使用者不必關(guān)心的細節(jié) ? 避免使用者無意中破壞對象的屬性或方法的正常工作 . . Java中實現(xiàn)封裝： ? 構(gòu)造函數(shù) 作用：保證新產(chǎn)生的對象實例的屬性一定是合理的（可用的） ? 訪問限定符 作用：保證外界無法隨意修改對象的特定屬性或執(zhí)行對象的特定方法 7.繼承 類和類之間的從屬關(guān)系 is - a Dog繼承Animal，意味著Dog自動具有了Animal所有的屬性和方法 繼承是OOP中實現(xiàn)代碼復(fù)用的重要途徑 8.多態(tài)：可以把子類的對象實例當(dāng)成父類的對象實例 (由于繼承)一個對象變量可以引用多種實際類型；由此

42、，同一段代碼，可以用于多種不同的對象。這種現(xiàn)象就是所謂的多態(tài) 9.覆蓋：override 子類可以重新實現(xiàn)父類定義的方法（覆蓋的作用是讓子類可以選擇性的去繼承父類已經(jīng)實現(xiàn)的功能） 重載：overload （同一個類中的）多個方法可以使用同一個名字（解決做同一件事，可能需要不同參數(shù)的情況） ? 重載和多態(tài)、OOP沒有關(guān)系！ 10.動態(tài)綁定：一段方法代碼的具體行為是在程序運行時，才由傳遞給它的實參到底是什么類型決定的 public class Test public static void main(String args) 湁浩污慍楮渽睥?杯尨旺財); ani.run(); ani.cry();

43、 11.抽象類：在父類中的某些方法（抽象方法）只是起到一個定義契約的作用，沒有具體實現(xiàn)。 Abstract關(guān)鍵字 Shape s=new Circle(); public abstract class Shape public abstract double getArea(); public abstract void draw(); 抽象類中也可以包含具體的方法。 接口與抽象類的區(qū)別： ? 接口的所有方法都是抽象的public方法，而抽象類既可以有抽象方法，也可以有非抽象方法、即可以有public方法，也可以有private、protected方法 ? 抽象類依然是類，因此受到Java語言

44、中一個類只能有一個父類的限制；而一個類可以同時實現(xiàn)零到多個接口 接口就相當(dāng)于一個純粹的契約 實現(xiàn)一個接口，就是實現(xiàn)接口中聲明的所有方法 . . 通常我們用繼承關(guān)系表示類在概念上的包含與從屬關(guān)系（is-a關(guān)系） 用接口實現(xiàn)關(guān)系，表示類具有的某種特性（has-a關(guān)系） CH5 需求分析領(lǐng)域建模 本章重點： ? 領(lǐng)域建模方法 ? 系統(tǒng)順序圖的繪制方法 1.領(lǐng)域模型（domain model）：用圖形可視化的方式表示的領(lǐng)域內(nèi)的實體概念及其相互關(guān)系 領(lǐng)域模型展現(xiàn)了：領(lǐng)域中的對象類或概念、概念之間的關(guān)系、概念的重要屬性 2.概念類一定對應(yīng)于現(xiàn)實中的某個具體的概念或者事物 出現(xiàn)在領(lǐng)域模型中的類都是概念類 3

45、.領(lǐng)域模型本質(zhì)上是關(guān)于特定領(lǐng)域的一個可視化的詞匯列表,但不能完全取代詞匯表 4.領(lǐng)域模型中的類沒有職責(zé)（方法）；領(lǐng)域模型不包括軟件制品，如數(shù)據(jù)庫、網(wǎng)頁 領(lǐng)域模型不是數(shù)據(jù)模型： ? 不需要考慮概念類的相關(guān)信息是否需要持久保存 ? 不需要考慮概念類到底都有哪些屬性 5.領(lǐng)域建?；静襟E： ? 尋找概念類：重用已有模型；使用分類列表；語言分析（與分類列表一起使用） 概念類中有一類是對事物的描述，即描述類，避免：數(shù)據(jù)冗余；信息丟失 概念類分析準則： ? 準則1:不要把概念類誤認為屬性 如果我們認為某事物X不是現(xiàn)實世界中的數(shù)字或文字，那么X可能是概念類而不是屬性 ? 準則2：報表對象模型中是否要包括“票

46、據(jù)” ? 準則3：像地圖繪制者一樣思考使用領(lǐng)域術(shù)語 ? 將其繪制到模型中 使用簡化的UML類圖 ? 添加關(guān)聯(lián)和屬性 6.關(guān)聯(lián)分析： 關(guān)聯(lián)（assosiation）：類的實例，即對象之間的關(guān)系，表示有意義和值得關(guān)注的連接。關(guān)聯(lián)不一定是永久性的 關(guān)注那些現(xiàn)實業(yè)務(wù)需要關(guān)注和記錄的關(guān)聯(lián) 注意點：避免加入大量關(guān)聯(lián)；模型中的關(guān)聯(lián)不一定會在軟件中實現(xiàn) ? 關(guān)聯(lián)的表示： 關(guān)聯(lián)表示為類之間的連線，并冠以首字母大寫的關(guān)聯(lián)名稱。末端包含多重性表達式；本質(zhì)是雙向的 . . 關(guān)聯(lián)命名準則：格式為“類名動詞短語類名”；動詞短語應(yīng)是可讀的、有意義的 多重性：定義了類A有多少個實例可以和類B的一個實例關(guān)聯(lián) 多重性的數(shù)值表示在

47、特定時間點上有效關(guān)聯(lián)的實例數(shù)量 多重性的數(shù)值還與建模者的關(guān)注角度有關(guān) 多重關(guān)聯(lián) 7.屬性分析： 屬性：表示對象某一方面性質(zhì)的邏輯數(shù)據(jù)值 屬性分析的目的：在領(lǐng)域模型中進一步確定概念類的屬性，可以更好的展現(xiàn)當(dāng)前所開發(fā)場景的信息需求。 導(dǎo)出屬性：有些屬性可以從其他屬性，或關(guān)聯(lián)類的信息中推導(dǎo)出來（冗余，一般不應(yīng)該在領(lǐng)域模型中出現(xiàn)。） 一般來說屬性的類型不應(yīng)該是復(fù)雜的領(lǐng)域概念（即其他概念類） 8.系統(tǒng)順序圖：使用簡化的UML順序圖來描述外部參與者與SuD之間的輸入和輸出事件。 使用系統(tǒng)順序圖(System Sequence Diagram, SSD）來闡述系統(tǒng)的動態(tài)特性 時間順序、自上而下描述外部參與者

48、和系統(tǒng)之間的交互 CH6 架構(gòu)設(shè)計 本章重點： ? 什么是系統(tǒng)架構(gòu) ? 什么是性能，如何衡量？什么是可用性？ ? 在架構(gòu)中，什么是封裝？什么是耦合？什么是解耦？什么是分層 ? 典型的軟件架構(gòu)：C/S架構(gòu)，B/S架構(gòu)，三層C/S架構(gòu)各自的優(yōu)缺點。選擇合適的軟件架構(gòu) ? 邏輯三層結(jié)構(gòu) ? 什么是。如何對用戶口令加密。RBAC。什么是（安全）審計。 ? 架構(gòu)的設(shè)計與驗證 1.系統(tǒng)架構(gòu)（System Architecture）： ? 廣義上講，是指開發(fā)一個軟硬件系統(tǒng)所作出的最高層次的、以后難以更改的，商業(yè)的和技術(shù)的決定。 ? 狹義上說，就是指軟硬件系統(tǒng)的組成結(jié)構(gòu) 用軟件架構(gòu)特指軟件系統(tǒng)的架構(gòu) 包括：各

49、軟件元素、軟件元素的外在特性、軟件元素之間的關(guān)系 2.軟件架構(gòu)的根本作用：保證軟件系統(tǒng)能夠滿足用戶的需求 ? 軟件架構(gòu)的關(guān)注點更多的放在軟件的非功能性需求上 過程需求（軟件交付方法、實現(xiàn)方法、交付時間） 外部需求（互操作性、法律、道德約束、操作者水平等） ? 產(chǎn)品需求（質(zhì)量需求） 可用性、可靠性、安全性、可維護性等等 3.重要的非功能性需求 性能（Performance?）：即系統(tǒng)完成特定功能的效率 . . 性能的主要衡量指標： ? 吞吐率（throughput）：系統(tǒng)單位時間內(nèi)完成的工作量。又可分為平均吞吐率和峰值吞吐率。 ? 響應(yīng)時間（Responsetime）：從用戶發(fā)出處理請求到收到處

50、理結(jié)果所花的時間。又可分為平均響應(yīng)時間和最大響應(yīng)時間 ? 截止期限（Deadline）：系統(tǒng)的任務(wù)必須在某個特定時間段內(nèi)完成 架構(gòu)對性能的影響是雙方面的：對系統(tǒng)進行分塊和分裝，會引入額外的通訊和運行開銷；合理的布局和設(shè)計又可提高性能 可復(fù)用性：軟件或其模塊可以重復(fù)使用的程度。 ?可復(fù)用性越高，企業(yè)軟件開發(fā)效率越高 典型：數(shù)據(jù)庫 安全性：系統(tǒng)內(nèi)的信息被盜取或破壞，或者系統(tǒng)由于惡意攻擊導(dǎo)致不能工作?的可能性 可用性：系統(tǒng)的一部分出現(xiàn)故障，導(dǎo)致整個系統(tǒng)不能正常工作的可能性，以? 及使系統(tǒng)完全恢復(fù)正常所需要的時間長短。 可維護性：所有的軟件都需要修改和升級，好的架構(gòu)，能夠保證修改只影響?系統(tǒng)中很小的一

51、部分程序，從而使系統(tǒng)具備較好的可維護性 各非功能性需求之間相互影響，架構(gòu)設(shè)計必須是一個權(quán)衡的過程 價值觀 重要性排序 4.目前軟件架構(gòu)設(shè)計所采用的基本指導(dǎo)思想是分治。其表現(xiàn)形式主要有兩種： ? 封裝：把功能抽取成獨立的模塊 外界只能通過它的對外接口來訪問它的功能 外界不需要關(guān)心它內(nèi)部的具體結(jié)構(gòu)和實現(xiàn)方法。 ? 解耦：解除耦合 耦合：軟件設(shè)計中的耦合就是指軟件元素之間的依賴關(guān)系。 軟件中的耦合關(guān)系越多，就越難以修改和維護。 解耦包含兩層含義： ? 減少模塊之間的過度耦合 ? 對于必須存在的耦合（聯(lián)系），盡量使之標準化 5.封裝和解耦思想在架構(gòu)中主要體現(xiàn)為“分層” ? 分層：通過在軟件整體結(jié)構(gòu)中，

52、將基本功能集中到一個模塊中的做法，即稱為分層 較高層次的層可以調(diào)用較低層次的層，而反之則不然。即層與層之間的依賴是單向的 ? 解耦的另一種常用方法：參數(shù)化配置 通過分層和配置，對軟件外部耦合關(guān)系實現(xiàn)解耦 ? 繼承和多態(tài) 減少內(nèi)部耦合 基于接口的開發(fā) . . 封裝和解耦往往是在一起進行的： ? 封裝的模塊是按照解耦原則劃分出來的 ? 不封裝的解耦是無意義的 6.直接式架構(gòu)：沒有架構(gòu) 優(yōu)點：結(jié)構(gòu)簡單、容易實現(xiàn) 缺點：沒有明確的結(jié)構(gòu)、其軟件質(zhì)量特性沒有保證 適合：功能簡單的軟件 層架構(gòu)：把系統(tǒng)分為若干層，上層調(diào)用下層分層架構(gòu)：n7. 網(wǎng)絡(luò)典型：TCP/IP 基于物理分布的分層架構(gòu)8.Visual F

53、oxpro 、結(jié)構(gòu) Visual Basic? 2層結(jié)構(gòu)或C/S 特點? 系統(tǒng)分成兩層? 它是運行在用戶計算機上的一個），一層是客戶端? （Client 可執(zhí)行程序。通常是運行在后臺服務(wù)器上的）， 一層是服務(wù)器層（Server? 數(shù)據(jù)庫及其存儲過程。都在客戶端程序系統(tǒng)主要的功能，比如與用戶進行交互等，? 中完成。 后臺數(shù)據(jù)庫集中存儲重要的系統(tǒng)數(shù)據(jù)。? C/S解決了單機軟件之間數(shù)據(jù)共享和協(xié)作的問題? 二層架構(gòu)的缺點? 客戶端必須保存數(shù)據(jù)庫的訪問密碼，非常不利于安全。? 當(dāng)客戶端數(shù)量很多時，部署和升級不便? 結(jié)構(gòu)層或B/S3? 特點? 系統(tǒng)分成三層? ），運行在客戶計算機上，負責(zé)解Browser

54、一層是瀏覽器（? 釋和顯示網(wǎng)頁內(nèi)容。），運行在后臺Application Server? 一層是應(yīng)用服務(wù)器層（ 服務(wù)器上，負責(zé)處理用戶請求和生成網(wǎng)頁內(nèi)容。），運行在后臺單獨的一層是數(shù)據(jù)庫層（Database Server? 服務(wù)器上，負責(zé)數(shù)據(jù)存儲 ? 系統(tǒng)的核心業(yè)務(wù)處理都統(tǒng)一在應(yīng)用服務(wù)器層完成 ? 優(yōu)點 利于升級和部署。? 數(shù)據(jù)庫不直接暴漏在外，安全性更高。 ? 容易擴展和優(yōu)化? ? 缺點 對應(yīng)用服務(wù)器的性能有較高要求。? ，如打印、刷卡輸入等? 瀏覽器的功能有限RIA 解決辦法： 層 ?3C/S結(jié)構(gòu). . 即將原B/S三層架構(gòu)的中的瀏覽器改為專門開發(fā)的客戶端 功能受限的缺陷B/S彌補 幾種分層架構(gòu)的比較9. 10.目前絕大多數(shù)基于互聯(lián)網(wǎng)的軟件都采用了三層架構(gòu)。 二層架構(gòu)主要用在少數(shù)基于專用內(nèi)部網(wǎng)的企業(yè)或組織中： 超市、郵局、銀行、專用工業(yè)控制設(shè)備等? 三層邏輯架構(gòu)11. 將應(yīng)用服務(wù)器分為三層 ：解耦用戶人機交互方式的變化用戶界面層（表示層視圖層）? 處理用戶請求，繪制網(wǎng)站頁面? ：解耦業(yè)務(wù)處理規(guī)