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

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

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

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

4、：軟件工程是一種層次化的技術(shù) 質(zhì)量優(yōu)先是整個(gè)軟件工程的核心價(jià)值觀（以質(zhì)量為中心） （軟件）過程：由為建造、維護(hù)高質(zhì)量軟件所需要完成的一系列相互關(guān)聯(lián)的活動(dòng)組成的框架，即形成軟件產(chǎn)品的一系列步驟。過程是軟件工程管理和實(shí)施的基礎(chǔ)。 方法：軟件開發(fā)和維護(hù)過程中一些具體問題的最佳解決手段。方法是軟件工程的核心手段 工具：為實(shí)現(xiàn)軟件工程中各種過程和方法的自動(dòng)化和半自動(dòng)化而開發(fā)的程序系統(tǒng)。工具是軟件工程的效率倍增器。8.軟件工程必須重視人員的培訓(xùn)。9.軟件工程中的相關(guān)人員： 用戶User：軟件使用者。目的是使用軟件解決問題或提高工作效率。 客戶Customer：為軟件付錢的人。他們的目標(biāo)是增加利潤，或只是使

5、業(yè)務(wù)運(yùn)作更為有效。 軟件開發(fā)人員Developer：開發(fā)并維護(hù)軟件的人。 開發(fā)管理人員Manager：管理軟件開發(fā)過程的人員。其目標(biāo)是花最少的錢滿足客戶要求10.軟件神話：關(guān)于軟件及其開發(fā)過程的一些錯(cuò)誤說法。 神話一：因?yàn)檐浖怯蓮椥缘?，因此可以很容易的適應(yīng)需求變化。（修改軟件要付出成本） 神話二：如果我們無法按時(shí)完成計(jì)劃，可以通過增加電腦和程序員人數(shù)趕上速度。 神話三：軟件過程就是嚴(yán)格按照完成的軟件開發(fā)標(biāo)準(zhǔn)和規(guī)程來開發(fā)軟件。（錯(cuò)在把手段當(dāng)成了目的，應(yīng)該根據(jù)項(xiàng)目實(shí)際需要，靈活安排實(shí)際的軟件過程活動(dòng)） 神話四：當(dāng)程序編寫完成并交付給客戶后，任務(wù)就完成了，因此應(yīng)該盡快開始編寫代碼。 神話五：軟件工

6、程會(huì)導(dǎo)致我們產(chǎn)生大量無用的文檔，因此降低了效率。（創(chuàng)建文檔的目的是保證開發(fā)軟件的質(zhì)量）文檔最重要的作用是（1）促使開發(fā)者認(rèn)真思考和（2）促進(jìn)交流。CH1 軟件過程與方法本章重點(diǎn)：v 過程管理的任務(wù)v 過程的定義v 五個(gè)核心軟件活動(dòng)v 幾種軟件過程模型，其活動(dòng)間的順序關(guān)系是怎樣的（順序、迭代、演化還是并行？）v 原型及其作用v 敏捷開發(fā)的價(jià)值觀v 敏捷開發(fā)的基本推動(dòng)力1.過程管理：辨識出一連串的商業(yè)活動(dòng)，并針對這些活動(dòng)的作業(yè)流程進(jìn)行管理。2.過程管理的目標(biāo)： 確保企業(yè)中各種商業(yè)活動(dòng)的執(zhí)行成果能具有一定的水平和精確度。 確保能持續(xù)改善活動(dòng)的進(jìn)行方式，串連活動(dòng)的作業(yè)流程 讓企業(yè)能保持市場上的競爭力3

7、.過程管理的任務(wù)： 尋找、發(fā)現(xiàn)企業(yè)中有價(jià)值的業(yè)務(wù)過程（過程識別） 發(fā)現(xiàn)、去除非增值活動(dòng)，簡化過程；通過合理安排活動(dòng)順序提高過程效率（過程梳理和優(yōu)化） 對過程各個(gè)活動(dòng)進(jìn)行規(guī)范，形成標(biāo)準(zhǔn)（過程固化） 對過程執(zhí)行情況加以監(jiān)控（過程監(jiān)控） 尋找過程中的錯(cuò)誤、薄弱、低效環(huán)節(jié)并加予以糾正（過程改進(jìn)）4.過程：也稱業(yè)務(wù)過程，指為客戶創(chuàng)造價(jià)值的一系列相互關(guān)聯(lián)、有組織的活動(dòng)或任務(wù)的集合。v 管理學(xué)意義上的過程是有明確目的性的：為客戶（或企業(yè)）創(chuàng)造價(jià)值5.（業(yè)務(wù)）過程的特點(diǎn)： 可確定性：有明確的輸入、輸出和邊界； 順序：構(gòu)成過程的活動(dòng)，必須在時(shí)間和空間里具有確定的順序； 客戶：過程的結(jié)果必須有接收者客戶。 增值：

8、在過程中發(fā)生的轉(zhuǎn)換必須為接收者增加價(jià)值，無論接收者是在過程的上游還是下游。6.軟件過程：構(gòu)建、維護(hù)軟件產(chǎn)品時(shí)所執(zhí)行的一系列步驟（活動(dòng)、動(dòng)作和任務(wù)）的集合。v 活動(dòng)：組成軟件過程的最主要的宏觀步驟。 例如：需求分析、設(shè)計(jì)、編碼、發(fā)布等。v 動(dòng)作：對活動(dòng)進(jìn)一步細(xì)分的得到的步驟。 例如設(shè)計(jì)活動(dòng)，可以細(xì)分分為總體設(shè)計(jì)、模塊設(shè)計(jì)等多個(gè)動(dòng)作。v 任務(wù)：具體的工作步驟7.核心軟件活動(dòng)：所有合理的軟件過程都包含一些共同的必要的活動(dòng)（步驟），這些活動(dòng)我們稱為核心軟件活動(dòng)。8.軟件過程通常包括下列五個(gè)核心軟件活動(dòng)： 需求分析：通過與客戶的溝通協(xié)作，了解客戶的真實(shí)需要，決定軟件特性和功能，制定項(xiàng)目目標(biāo)。 建模（設(shè)計(jì)

9、）：通過構(gòu)造軟件模型(通常是圖形形式的模型）的方法來研究、理解具體問題，（向客戶和其他開發(fā)人員）展現(xiàn)具體解決方案。 編碼與測試：實(shí)際編寫代碼、驗(yàn)證代碼的正確性 運(yùn)行與部署：將軟件交付用戶使用。通常用戶會(huì)對軟件進(jìn)行一段時(shí)間的試用，并給出反饋意見 維護(hù)：修復(fù)用戶使用過程中發(fā)現(xiàn)的軟件缺陷，或者根據(jù)用戶使用意見對軟件進(jìn)行改進(jìn)9.在實(shí)際軟件過程中往往還存在一些貫穿整個(gè)過程的普適性活動(dòng)，以幫助軟件團(tuán)隊(duì)管理和控制項(xiàng)目進(jìn)度、質(zhì)量、變化和風(fēng)險(xiǎn)。項(xiàng)目管理的角度說，這些“普適性活動(dòng)”實(shí)質(zhì)上是項(xiàng)目管理活動(dòng)。常見普適性活動(dòng)包括： 策劃：創(chuàng)建軟件項(xiàng)目的“地圖”，以指導(dǎo)團(tuán)隊(duì)的項(xiàng)目旅程。通常包括：需要執(zhí)行的具體任務(wù)、每個(gè)任務(wù)

10、需要的資源分配，每個(gè)任務(wù)的具體產(chǎn)品，以及工作計(jì)劃等 項(xiàng)目跟蹤和控制：定期評估項(xiàng)目進(jìn)度情況，采取必要措施確保項(xiàng)目按期完成 風(fēng)險(xiǎn)管理：對可能影響項(xiàng)目進(jìn)度和產(chǎn)品質(zhì)量的風(fēng)險(xiǎn)進(jìn)行評估，并采取必要措施來降低風(fēng)險(xiǎn) 測量：定義和采集關(guān)于過程、項(xiàng)目和產(chǎn)品的度量數(shù)據(jù)，以幫助管理和改進(jìn)其他活動(dòng)。例如：開發(fā)人員的生產(chǎn)率等 軟件質(zhì)量保證：確保軟件質(zhì)量的措施和活動(dòng) 軟件配置管理：管理軟件（代碼、配置信息及其文檔）的版本變化歷史 可復(fù)用管理：建立產(chǎn)品（代碼等）復(fù)用的機(jī)制和標(biāo)準(zhǔn)（如公用函數(shù)庫等） 人員培訓(xùn)：對相關(guān)人員進(jìn)行必要的培訓(xùn)，使其具備必要的知識和技能，掌握相關(guān)工具的使用方法10. 軟件過程模型是從一特定角度提出的軟件過

11、程的簡化描述。過程流（模型）是最主要的一類軟件過程模型。過程流描述了如何在執(zhí)行順序和執(zhí)行時(shí)間這一層面上，組織軟件過程中（除維護(hù)之外的）的活動(dòng)。11.幾種主要的過程流及典型過程模型： 線性過程流：瀑布模型 迭代過程流：原型開發(fā)模型 演化過程流：螺旋模型 并行過程流 混合過程流：增量模型12.瀑布模型：又稱軟件生存周期模型，瀑布模型嚴(yán)格按照軟件生存周期各個(gè)階段來進(jìn)行開發(fā)，上一階段的輸出即是下一階段的輸入，并強(qiáng)調(diào)每一階段的嚴(yán)格性。每一階段的任務(wù)完成后，都必須對其階段性產(chǎn)品（主要是文檔）進(jìn)行評審，通過后才能開始下一階段的工作。是一種以文檔作為驅(qū)動(dòng)的模型v 軟件生存周期：軟件從定義開始，經(jīng)過開發(fā)、使用和

12、維護(hù)，直到最終退役的全過程稱為軟件生存周期。瀑布模型將軟件生命周期分成軟件定義、軟件開發(fā)、運(yùn)行、維護(hù)及退役五個(gè)時(shí)期組成。v 優(yōu)點(diǎn)：可強(qiáng)迫開發(fā)人員采用的規(guī)范方法；嚴(yán)格規(guī)定了每一階段必須提交的文檔；要求每一階段交付之產(chǎn)品都必須經(jīng)過質(zhì)量保證小組的仔細(xì)審查；清晰區(qū)分了邏輯設(shè)計(jì)與物理設(shè)計(jì)，盡可能推遲程序的物理實(shí)現(xiàn)；提供了軟件開發(fā)的基本框架，有利于大型軟件開發(fā)過程中人員的組織、管理，有利于軟件開發(fā)方法和工具的研究與使用，因此，在軟件工程中占有重要的地位。 v 缺點(diǎn)：要求在項(xiàng)目開始的需求分析階段就能夠完整的得到客戶的所有需求，現(xiàn)實(shí)中很難實(shí)現(xiàn) 客戶要到項(xiàng)目接近尾聲的驗(yàn)收階段才能夠看到實(shí)際的程序執(zhí)行效果。如果這

13、時(shí)才發(fā)現(xiàn)程序和客戶實(shí)際要求有重大偏差，就可能會(huì)造成重大的損失13.原型開發(fā)模型：原型，就是軟件的一個(gè)模擬的可執(zhí)行界面。用戶可在原型上進(jìn)行操作，直觀的感受軟件的執(zhí)行效果。原型開發(fā)就是軟件開發(fā)人員根據(jù)用戶提出的軟件基本需求快速開發(fā)一個(gè)原型，向用戶展示軟件界面和功能。在征求用戶對原型的評價(jià)意見后，進(jìn)一步改進(jìn)、完善原型，如此迭代，直到軟件開發(fā)人員和用戶都確認(rèn)軟件系統(tǒng)的需求并達(dá)成一致的理解為止。優(yōu)點(diǎn)： 原型的開發(fā)和評審時(shí)系統(tǒng)分析員和用戶/客戶共同參與的迭代過程，有利于雙方充分理解和溝通。 比瀑布模型更符合人們認(rèn)識事物的過程和規(guī)律，項(xiàng)目成員能夠更清晰的理解用戶實(shí)際需求。 如果原型的開發(fā)語言和實(shí)際軟件相同，

14、那么它的若干高質(zhì)量的程序片段和開發(fā)工具也可被用于工作程序的開發(fā)?？焖僭偷拈_發(fā)途徑：原型僅僅是需求分析的一部分，因此必須盡可能快速的開發(fā)原型。建造原型應(yīng)盡量采用相應(yīng)的軟件工具和環(huán)境，并盡量采用軟件重用技術(shù)，在運(yùn)行效率方面可做出讓步，以便盡快提供。同時(shí)，原型應(yīng)充分展示軟件系統(tǒng)的可見部分，如人機(jī)界面、數(shù)據(jù)的輸入方式和輸出格式等。缺點(diǎn)：v 原型開發(fā)模型要求開發(fā)者和用戶在一段時(shí)間內(nèi)緊密配合、共同參與完成原型系統(tǒng)的開發(fā)，特別是需要用戶的及時(shí)反饋。如果用戶對此不夠重視，那么原型開發(fā)的意義也就大打折扣了。v 原型的快速構(gòu)造容易讓用戶誤以為實(shí)際軟件的開發(fā)也是可以很容易、很快就完成的，或者要求開發(fā)者直接將原型稍

15、加修改使之成為實(shí)際運(yùn)行的產(chǎn)品。v 而實(shí)際上，為了快速開發(fā)原型，開發(fā)者往往會(huì)犧牲軟件質(zhì)量和可維護(hù)性而采取了最快速的開發(fā)手段，因此實(shí)際的高質(zhì)量軟件產(chǎn)品需要拋棄原型從頭開發(fā)。v 如果不能夠充分的向客戶解釋這一點(diǎn)的話，就容易導(dǎo)致軟件開發(fā)人員和用戶之間產(chǎn)生矛盾。v 原型開發(fā)模型最大的缺點(diǎn)在于，它仍然沒有解決需求變化的問題。14.螺旋模型：一種演化式的軟件過程模型。結(jié)合了原型開發(fā)模型的迭代性和瀑布模型的系統(tǒng)性和可控性特點(diǎn)。螺旋模型的每一個(gè)迭代周期都包括計(jì)劃（需求定義）、風(fēng)險(xiǎn)分析、工程實(shí)現(xiàn)和評審4個(gè)階段。螺旋模型是一個(gè)風(fēng)險(xiǎn)驅(qū)動(dòng)的模型，每個(gè)迭代周期都不應(yīng)該太長（一般是2-8周左右）螺旋模型優(yōu)點(diǎn)： 支持用戶需求

16、的動(dòng)態(tài)變化 原型可看作形式的可執(zhí)行的需求規(guī)格說明，易于為雙方共同理解；開發(fā)者和用戶共同參與軟件開發(fā)，可盡早發(fā)現(xiàn)軟件中的錯(cuò)誤。 螺旋模型特別強(qiáng)調(diào)原型的可擴(kuò)充性和可修改性。既保持瀑布模型的系統(tǒng)性、階段性，又可利用原型評估降低開發(fā)風(fēng)險(xiǎn)。 螺旋模型為項(xiàng)目管理人員及時(shí)調(diào)整管理決策提供了方便，進(jìn)而可降低開發(fā)風(fēng)險(xiǎn) 螺旋模型缺點(diǎn)： 如果每次迭代的效率不高，致使迭代次數(shù)過多，將會(huì)增加成本并推遲提交時(shí)間 使用該模型需要有相當(dāng)豐富的風(fēng)險(xiǎn)評估經(jīng)驗(yàn)和專門知識，要求開發(fā)隊(duì)伍水平較高適用場合：支持需求不明確、特別是大型軟件系統(tǒng)的開發(fā)，并支持面向規(guī)格說明、面向過程、面向?qū)ο蟮榷喾N軟件開發(fā)方法15.增量過程模型：螺旋模型基礎(chǔ)上

17、的改進(jìn)。采用并行方式 解決阻塞帶來的浪費(fèi)問題16.敏捷開發(fā)提出的背景：傳統(tǒng)過程開發(fā)模型都是從管理者的角度來看待軟件開發(fā)，存在重大缺陷：忽視變化的存在；忽視了軟件開發(fā)是一個(gè)智力密集型的工作；忽視了人與人之間的直接交流；過分注重過程。17.敏捷開發(fā)宣言：敏捷開發(fā)的價(jià)值觀 個(gè)人與交流 勝于 開發(fā)過程和工具 可運(yùn)行的軟件 勝于 面面俱到的文檔 客戶協(xié)作 勝于 合同談判 響應(yīng)變化 勝于 按部就班遵循計(jì)劃18.敏捷的基本推動(dòng)力：普遍存在的變化19.敏捷鼓勵(lì)： 使溝通更便利的團(tuán)隊(duì)結(jié)構(gòu)和協(xié)作態(tài)度 快速交付可運(yùn)行產(chǎn)品而非中間文檔 客戶以開發(fā)團(tuán)隊(duì)中的一員的身份參與項(xiàng)目 根據(jù)實(shí)際情況靈活調(diào)整項(xiàng)目計(jì)劃20.敏捷開發(fā)非

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

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

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

21、)：為了解決客戶的特定問題，軟件所必須提供的能力和必須遵從的約束條件。3.需求分析：項(xiàng)目人員確定用戶需求所需要做的工作需求分析的目標(biāo)： 弄清楚客戶/用戶究竟想用軟件來干什么。 弄清楚用戶究竟想怎么用。 讓客戶明確他最終能得到什么樣的產(chǎn)品需求分析的成果：軟件需求說明書4.需求通常分為功能需求和非功能需求兩大類功能需求：描述系統(tǒng)應(yīng)該提供的功能或服務(wù)，通常涉及用戶或外部系統(tǒng)與該系統(tǒng)之間的交互。即軟件必須提供的能力。 業(yè)務(wù)需求、用戶需求、功能需求、系統(tǒng)需求非功能需求：從各個(gè)角度對系統(tǒng)的約束和限制，反映了應(yīng)用對軟件系統(tǒng)質(zhì)量和特性的額外要求，例如響應(yīng)時(shí)間、數(shù)據(jù)精度、可靠性、開發(fā)過程的標(biāo)準(zhǔn)等。即軟件的約束。

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

23、、業(yè)務(wù)規(guī)則等v 相關(guān)票據(jù)、記錄、報(bào)表等業(yè)務(wù)規(guī)則:描述業(yè)務(wù)處理可能遇到的情況及相應(yīng)的處理措施或約束。需求獲取方法：個(gè)別訪談、會(huì)議、調(diào)查、觀察 需求分析與協(xié)商：對需求獲取采集的信息進(jìn)行匯總、分析，形成詳細(xì)、規(guī)范的需求描述。需要獲取的成果最終必須以可見成果的形式描述出來需求描述工具：v 用例：一段用文字表述的故事，闡述用戶如何使用軟件來實(shí)現(xiàn)某個(gè)具體的業(yè)務(wù)目標(biāo)。相關(guān)工具：系統(tǒng)范圍圖/表業(yè)務(wù)流程圖（活動(dòng)圖）用戶目標(biāo)表：用表格形式匯總展現(xiàn)系統(tǒng)所涉及的全部用例及其優(yōu)先級(用例的目錄)用戶情況表數(shù)據(jù)流模型：用圖形方式表示數(shù)據(jù)的輸入、輸出和加工過程。 需求規(guī)約：形成正式需求分析文檔的過程軟件需求說明書（軟件需求

24、規(guī)約，SRS）是分析任務(wù)的最終產(chǎn)物，是用戶和開發(fā)者雙方對于軟件產(chǎn)品要求的正式約定。需求說明書模板： 第一章 目標(biāo)與范圍 1a 項(xiàng)目的整體范圍與目標(biāo)是什么？ 1b 利益相關(guān)者（Who cares?） 1c 項(xiàng)目范圍內(nèi)包括什么？什么不在項(xiàng)目范圍內(nèi)？ 第二章 詞匯表 第三章 用例 3a 項(xiàng)目的主要參與者與他們的目標(biāo) 3b 概要級別用例（以主要參與者的視角來分別描述各個(gè)主要的業(yè)務(wù)流程） 3c 用戶目標(biāo)級別用例（具體描述主要參與者如何使用系統(tǒng)來實(shí)現(xiàn)他們的目標(biāo)） 3d 用戶目標(biāo)表 第四章技術(shù)要求 第五章其他要求 第六章人工備份、法律、政治與組織問題 需求驗(yàn)證 需求管理：是一組用于幫助項(xiàng)目組在項(xiàng)目進(jìn)展中的任

25、何時(shí)候去標(biāo)識、控制和跟蹤需求的活動(dòng) 目的：v 保障需求說明書與產(chǎn)品的一致性v 控制需求變更對項(xiàng)目開發(fā)的影響v 使需求活動(dòng)與計(jì)劃保持一致 內(nèi)容：變更控制 版本控制 需求跟蹤 需求狀態(tài)跟蹤 需求變更：在軟件需求基線已經(jīng)確定之后又要添加新的需求或進(jìn)行較大的需求變動(dòng)。需求變更管理：由專人統(tǒng)一負(fù)責(zé)接收、評估、審批和實(shí)施需求變更請求需求變更管理的目的：確保需求變更的利大于弊 需求跟蹤：在軟件開發(fā)的全過程中，記錄和維護(hù)每項(xiàng)需求與軟件其他系統(tǒng)元素（如設(shè)計(jì)模塊、程序代碼、測試用例等等）之間的關(guān)系作用：建立與維護(hù)“需求其他需求-設(shè)計(jì)編程測試”之間的一致性方式：正向跟蹤、逆向跟蹤、雙向跟蹤目的：v 確保所有的工作成

26、果最終符合用戶需求。v 當(dāng)需求發(fā)生變更時(shí)能夠快速定位所有被影響的系統(tǒng)元素需求跟蹤矩陣（RTM）是表示需求和其他系統(tǒng)元素之間的聯(lián)系鏈的一種常用工具需求狀態(tài)跟蹤：在項(xiàng)目整個(gè)生命周期中對項(xiàng)目所處狀態(tài)（即其在當(dāng)前時(shí)刻的情況）進(jìn)行追蹤目的：確保用戶提出的每一項(xiàng)需求都得到了妥善的處理工具：單獨(dú)的需求狀態(tài)跟蹤表；也可合并到需求跟蹤矩陣中 9.管理層級與信息系統(tǒng)關(guān)注：用戶使用場景和業(yè)務(wù)流程關(guān)注：績效指標(biāo)體系和數(shù)據(jù)流 還要關(guān)注：崗位與權(quán)限、數(shù)據(jù)量10.不能說的秘密：需求分析必須重視利益干系人CH3 需求分析場景分析與用例本章重點(diǎn)：v 用例的組成部份及其寫法v 各用例相關(guān)工具的作用v 用例圖的畫法v 活動(dòng)圖的畫法

27、v 基于用例的場景分析1.需求分析的兩個(gè)最主要的視角： 業(yè)務(wù)（流程）視角 績效（信息）視角2.目前的主流是使用以用例為核心的一套方法和工具來描述企業(yè)業(yè)務(wù)用例（Use Case）：一種通過描述用戶的使用場景來獲取需求的技術(shù)?？陀^（第三者視角）描述使用場景對業(yè)務(wù)場景中有明確目標(biāo)的參與者之間的行為描述；用例是利益相關(guān)方關(guān)于（待開發(fā)）系統(tǒng)行為的契約。3.用例的組成v 用例名稱 動(dòng)詞、動(dòng)詞+賓語結(jié)構(gòu)詞組或簡短的主謂賓結(jié)構(gòu)短語 能夠清晰的反映用例的功能或要實(shí)現(xiàn)的目標(biāo)v 參與者及其目標(biāo)參與者（Actor）是在用例中具有行為或職責(zé)的人事物。參與者可能是人，也可能是某個(gè)組織（部門、企業(yè)），還可能是某個(gè)軟硬件系統(tǒng)

28、。待分析的系統(tǒng)（SuD）一般不會(huì)作為參與者。 主要參與者：SuD的主要服務(wù)目標(biāo)或使用對象。使用SuD實(shí)現(xiàn)其目標(biāo)。 協(xié)助參與者：為SuD提供服務(wù)的參與者v 利益相關(guān)者及其關(guān)注點(diǎn)間接受用例影響的組織或個(gè)人，我們稱之為利益相關(guān)者。SuD必須確保利益相關(guān)者的利益得到了切實(shí)的保護(hù)v 范圍與目標(biāo)級別范圍界定了用例中要分析的系統(tǒng) 目標(biāo)級別：描述用例中主要參與者的目標(biāo)層級 概要：描述企業(yè)業(yè)務(wù)流程或用戶流程的總體步驟，如采購流程、研發(fā)流程等（可能跨度很長；可能涉及多個(gè)非系統(tǒng)參與者） 用戶目標(biāo)：業(yè)務(wù)流程中的某一步，在這一步驟中，主要參與者使用待開發(fā)系統(tǒng)來實(shí)現(xiàn)一個(gè)具體的目標(biāo)。如（超市）用戶結(jié)賬等。 子功能：對用戶目

29、標(biāo)級別用例中的單個(gè)步驟的進(jìn)一步描述，如（超市）用戶刷卡付款等。判斷： （圖書館管理系統(tǒng)）讀者登錄 （圖書館管理系統(tǒng)）讀者借書 （超市管理系統(tǒng)）用信用卡支付 （超市管理系統(tǒng)）處理退貨 （超市管理系統(tǒng)）尋找供貨商 （ATM系統(tǒng)）使用ATM取現(xiàn)金 (ATM系統(tǒng)）使用ATM修改密碼 (ATM系統(tǒng)）使用ATM辦理業(yè)務(wù)v 前置條件：在用例中的場景開始之前，必須保證為真的條件用例中不要出現(xiàn)對前置條件進(jìn)行檢查的步驟可以不寫觸發(fā)條件：導(dǎo)致用例中的場景開始的事件?；颈ＷC：在用例執(zhí)行后，系統(tǒng)對各利益相關(guān)者的利益的最小保證 無論用例最終執(zhí)行是否成功，系統(tǒng)都必須確保基本保證中的承諾。成功保證：承諾如果用例成功執(zhí)行完畢

30、，利益相關(guān)者的哪些利益將會(huì)得到滿足（不重復(fù)基本保證中的內(nèi)容）v 主成功場景和步驟v 擴(kuò)展描述了用例中的其他所有場景或者場景分支片段 為什么擴(kuò)展是需求中最容易出問題的部分？n 擴(kuò)展中主要是各種異?；蝈e(cuò)誤情況的處理。n 這往往是業(yè)務(wù)人員并不熟悉的。n 不熟悉就會(huì)導(dǎo)致遺漏。n 一個(gè)只能處理正常情況的系統(tǒng)顯然不是一個(gè)完善的系統(tǒng)。即使擴(kuò)展中的異常情況系統(tǒng)最終不處理或無法處理，預(yù)先把它寫出來，甲乙雙方充分討論，能夠避免以后的扯皮 觸發(fā)條件：對應(yīng)于主成功場景中的某個(gè)步驟的特殊情況。在該步驟中，如果滿足該觸發(fā)條件，則改為執(zhí)行擴(kuò)展場景。（注意序號的對應(yīng)，數(shù)字代表步驟，字母代表觸發(fā)條件） 目標(biāo)：消除異常或特殊情況

31、，以繼續(xù)執(zhí)行主成功場景 場景結(jié)束：通常是重新并入主成功場景（缺省情況），或者是中止處理（即處理失?。﹙ 其他鏈接、特殊需求（與用例直接相關(guān)的非功能性需求、質(zhì)量屬性或約束）、技術(shù)和數(shù)據(jù)變元表（用戶對于系統(tǒng)實(shí)現(xiàn)的特殊技術(shù)要求）因?yàn)橛美斜苊庠O(shè)計(jì)和實(shí)現(xiàn)細(xì)節(jié)、發(fā)生頻率、優(yōu)先級、未決問題4用例相關(guān)工具項(xiàng)目愿景：用一兩句話對項(xiàng)目目標(biāo)做出的概括性描述。幫助項(xiàng)目團(tuán)隊(duì)成員建立起共同的項(xiàng)目目標(biāo)設(shè)計(jì)范圍圖：以直觀圖形的方式描述系統(tǒng)范圍。通常使用UML用例圖。In/Out表：一個(gè)簡單的工作主題列表，用于幫助討論和確定系統(tǒng)范圍。用戶目標(biāo)列表：匯總列出系統(tǒng)的主要使用者、目標(biāo)及其優(yōu)先級用戶情況表：匯總列出系統(tǒng)所有使用者的背

32、景、技能水平等情況。用例應(yīng)該讓用戶來寫。5.用例圖：用于描繪用例、系統(tǒng)、參與者及其之間的關(guān)系（語境圖）主要參與者系統(tǒng)（多個(gè)用例）協(xié)助參與者作用： 展示系統(tǒng)邊界 展現(xiàn)關(guān)系參與者泛化：參與者A泛化參與者B，表明參與者B參與的所有用例也被參與者A參與6.活動(dòng)圖（本質(zhì)是流程圖）基本組成元素：活動(dòng)：流程中的一個(gè)步驟。動(dòng)作：基礎(chǔ)的、邏輯上內(nèi)部不能再細(xì)分的活動(dòng)，是UML活動(dòng)圖中的最小分支與合并分叉與匯合：顯示并行線程 都會(huì)發(fā)生、但發(fā)生次序任意（一個(gè)時(shí)間段內(nèi)，同時(shí)進(jìn)行的活動(dòng)）甬道 每個(gè)活動(dòng)只能明確屬于一個(gè)甬道 用垂直實(shí)線分隔甬道本身沒有順序7.活動(dòng)圖與用例 活動(dòng)圖不能替代用例，因?yàn)橛美羞€有利益相關(guān)者及其關(guān)注

33、點(diǎn)等大量信息。 活動(dòng)圖能代替用例中的場景描述嗎？對于用戶目標(biāo)級別的用例而言：不能。因?yàn)槟繕?biāo)級別用例存在大量擴(kuò)展分支；過多分支會(huì)導(dǎo)致活動(dòng)圖難以理解適合輔助表達(dá)概要級別的用例8.基于用例的場景分析：自頂向下的過程 找出企業(yè)中需要信息化的業(yè)務(wù)過程。（有哪些業(yè)務(wù)&核心業(yè)務(wù)是啥） 將業(yè)務(wù)過程（Business Process）劃分為規(guī)范的步驟，并加以描述（概要級別用例）（用用例和活動(dòng)圖） 針對過程中的每個(gè)步驟編寫對應(yīng)的使用場景（用戶目標(biāo)級別用例）CH4 需求分析數(shù)據(jù)流分析本章重點(diǎn)：v 如何繪制DFDv 什么是KPI1.數(shù)據(jù)流圖（DFD）：描繪軟件系統(tǒng)邏輯模型的圖形工具2. DFD分層：按照系統(tǒng)的層次結(jié)構(gòu)

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

35、x為取值a的基本數(shù)據(jù)元素，即a無需進(jìn)一步定義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的缺陷完全聚焦于信息處理本身，對實(shí)際業(yè)務(wù)的描述不全面7.關(guān)鍵績效指標(biāo)KPI通過對組織業(yè)務(wù)流程的關(guān)鍵參數(shù)進(jìn)行設(shè)置、取樣、計(jì)算、分析，從而得到的用于衡量流程績效的一套目標(biāo)式量化管理指標(biāo)理論依據(jù)：20/80原則（帕累托原則）KPI業(yè)績考評體系是一整套覆蓋各項(xiàng)職能和各個(gè)層級的關(guān)鍵業(yè)績指標(biāo)管理系統(tǒng)，是從分析和計(jì)劃、匯報(bào)和指導(dǎo)、考核等三個(gè)方面實(shí)現(xiàn)管理規(guī)

36、范化，提高業(yè)務(wù)水平KPI是企業(yè)管理信息系統(tǒng)的數(shù)字儀表盤中儀表的來源。KPI體系制定： 第一步：開發(fā)業(yè)務(wù)“價(jià)值樹”； 第二步：確定影響大的“關(guān)鍵業(yè)績指標(biāo)”； 第三步：將“關(guān)鍵業(yè)績指標(biāo)”分配給有關(guān)經(jīng)理； 第四步：確定 “關(guān)鍵業(yè)績指標(biāo)”的目標(biāo)。v 需求分析階段，必須落實(shí)KPI與報(bào)表中每一項(xiàng)指標(biāo)的： 計(jì)算方法 數(shù)據(jù)來源OOP建模本章重點(diǎn)v 對象與類的關(guān)系v 什么是封裝;封裝的意義v 什么是繼承;什么是多態(tài)v 什么是覆蓋, 什么是動(dòng)態(tài)綁定v 什么是接口1.為什么要面向?qū)ο髲谋举|(zhì)上說：軟件開發(fā)過程是一個(gè)開發(fā)人員對開發(fā)項(xiàng)目不斷深入學(xué)習(xí)、理解和認(rèn)識，并將其用代碼的形式固化的過程認(rèn)識復(fù)雜事物的兩種主要方法：抽象

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

38、v 類與對象之間的關(guān)系是抽象與具體的關(guān)系： 對象是對所研究的某一個(gè)具體事物的邏輯簡化。 而類是對同一類事物的抽象和歸納，相當(dāng)于概念。 狗是一個(gè)類，我養(yǎng)的那只小狗就是一個(gè)對象。v 類創(chuàng)建對象的模板，類定義決定了該類型對象所具備的屬性和行為。 只有先定義類，才能去定義該類對象。v 變量中保存的是對象，變量的類型是類。實(shí)例對象產(chǎn)品概念類模具5.面向?qū)ο蟮娜齻€(gè)主要特性：封裝、多態(tài)、繼承6.封裝：v 把數(shù)據(jù)和及其對應(yīng)的操作（方法）用對象和類的形式組織起來，使之形成一個(gè)有機(jī)的整體v 將數(shù)據(jù)處理的細(xì)節(jié)隱藏在對象內(nèi)部，外部無法干擾封裝的目的：v 隱藏對象的使用者不必關(guān)心的細(xì)節(jié)v 避免使用者無意中破壞對象的屬性

39、或方法的正常工作Java中實(shí)現(xiàn)封裝：v 構(gòu)造函數(shù) 作用：保證新產(chǎn)生的對象實(shí)例的屬性一定是合理的（可用的）v 訪問限定符作用：保證外界無法隨意修改對象的特定屬性或執(zhí)行對象的特定方法7.繼承類和類之間的從屬關(guān)系 is - aDog繼承Animal，意味著Dog自動(dòng)具有了Animal所有的屬性和方法繼承是OOP中實(shí)現(xiàn)代碼復(fù)用的重要途徑8.多態(tài)：可以把子類的對象實(shí)例當(dāng)成父類的對象實(shí)例(由于繼承)一個(gè)對象變量可以引用多種實(shí)際類型；由此，同一段代碼，可以用于多種不同的對象。這種現(xiàn)象就是所謂的多態(tài)9.覆蓋：override子類可以重新實(shí)現(xiàn)父類定義的方法（覆蓋的作用是讓子類可以選擇性的去繼承父類已經(jīng)實(shí)現(xiàn)的功能

40、）重載：overload （同一個(gè)類中的）多個(gè)方法可以使用同一個(gè)名字（解決做同一件事，可能需要不同參數(shù)的情況） 重載和多態(tài)、OOP沒有關(guān)系！10.動(dòng)態(tài)綁定：一段方法代碼的具體行為是在程序運(yùn)行時(shí)，才由傳遞給它的實(shí)參到底是什么類型決定的public class Test public static void main(String args) Animal ani=new Dog(旺財(cái)); ani.run(); ani.cry(); 11.抽象類：在父類中的某些方法（抽象方法）只是起到一個(gè)定義契約的作用，沒有具體實(shí)現(xiàn)。 Abstract關(guān)鍵字 Shape s=new Circle();public

41、 abstract class Shape public abstract double getArea(); public abstract void draw();抽象類中也可以包含具體的方法。接口與抽象類的區(qū)別： 接口的所有方法都是抽象的public方法，而抽象類既可以有抽象方法，也可以有非抽象方法、即可以有public方法，也可以有private、protected方法 抽象類依然是類，因此受到Java語言中一個(gè)類只能有一個(gè)父類的限制；而一個(gè)類可以同時(shí)實(shí)現(xiàn)零到多個(gè)接口接口就相當(dāng)于一個(gè)純粹的契約實(shí)現(xiàn)一個(gè)接口，就是實(shí)現(xiàn)接口中聲明的所有方法通常我們用繼承關(guān)系表示類在概念上的包含與從屬關(guān)系（i

42、s-a關(guān)系）用接口實(shí)現(xiàn)關(guān)系，表示類具有的某種特性（has-a關(guān)系）CH5 需求分析領(lǐng)域建模本章重點(diǎn)：v 領(lǐng)域建模方法v 系統(tǒng)順序圖的繪制方法1.領(lǐng)域模型（domain model）：用圖形可視化的方式表示的領(lǐng)域內(nèi)的實(shí)體概念及其相互關(guān)系領(lǐng)域模型展現(xiàn)了：領(lǐng)域中的對象類或概念、概念之間的關(guān)系、概念的重要屬性2.概念類一定對應(yīng)于現(xiàn)實(shí)中的某個(gè)具體的概念或者事物出現(xiàn)在領(lǐng)域模型中的類都是概念類3.領(lǐng)域模型本質(zhì)上是關(guān)于特定領(lǐng)域的一個(gè)可視化的詞匯列表,但不能完全取代詞匯表4.領(lǐng)域模型中的類沒有職責(zé)（方法）；領(lǐng)域模型不包括軟件制品，如數(shù)據(jù)庫、網(wǎng)頁領(lǐng)域模型不是數(shù)據(jù)模型： 不需要考慮概念類的相關(guān)信息是否需要持久保存

43、不需要考慮概念類到底都有哪些屬性5.領(lǐng)域建?；静襟E： 尋找概念類：重用已有模型；使用分類列表；語言分析（與分類列表一起使用）概念類中有一類是對事物的描述，即描述類，避免：數(shù)據(jù)冗余；信息丟失概念類分析準(zhǔn)則： 準(zhǔn)則1:不要把概念類誤認(rèn)為屬性如果我們認(rèn)為某事物X不是現(xiàn)實(shí)世界中的數(shù)字或文字，那么X可能是概念類而不是屬性 準(zhǔn)則2：報(bào)表對象模型中是否要包括“票據(jù)” 準(zhǔn)則3：像地圖繪制者一樣思考使用領(lǐng)域術(shù)語 將其繪制到模型中使用簡化的UML類圖 添加關(guān)聯(lián)和屬性6.關(guān)聯(lián)分析：關(guān)聯(lián)（assosiation）：類的實(shí)例，即對象之間的關(guān)系，表示有意義和值得關(guān)注的連接。關(guān)聯(lián)不一定是永久性的關(guān)注那些現(xiàn)實(shí)業(yè)務(wù)需要關(guān)注和

44、記錄的關(guān)聯(lián)注意點(diǎn)：避免加入大量關(guān)聯(lián)；模型中的關(guān)聯(lián)不一定會(huì)在軟件中實(shí)現(xiàn) 關(guān)聯(lián)的表示：關(guān)聯(lián)表示為類之間的連線，并冠以首字母大寫的關(guān)聯(lián)名稱。末端包含多重性表達(dá)式；本質(zhì)是雙向的關(guān)聯(lián)命名準(zhǔn)則：格式為“類名動(dòng)詞短語類名”；動(dòng)詞短語應(yīng)是可讀的、有意義的多重性：定義了類A有多少個(gè)實(shí)例可以和類B的一個(gè)實(shí)例關(guān)聯(lián)多重性的數(shù)值表示在特定時(shí)間點(diǎn)上有效關(guān)聯(lián)的實(shí)例數(shù)量多重性的數(shù)值還與建模者的關(guān)注角度有關(guān)多重關(guān)聯(lián)7.屬性分析：屬性：表示對象某一方面性質(zhì)的邏輯數(shù)據(jù)值屬性分析的目的：在領(lǐng)域模型中進(jìn)一步確定概念類的屬性，可以更好的展現(xiàn)當(dāng)前所開發(fā)場景的信息需求。導(dǎo)出屬性：有些屬性可以從其他屬性，或關(guān)聯(lián)類的信息中推導(dǎo)出來（冗余，一般不

45、應(yīng)該在領(lǐng)域模型中出現(xiàn)。）一般來說屬性的類型不應(yīng)該是復(fù)雜的領(lǐng)域概念（即其他概念類）8.系統(tǒng)順序圖：使用簡化的UML順序圖來描述外部參與者與SuD之間的輸入和輸出事件。使用系統(tǒng)順序圖(System Sequence Diagram, SSD）來闡述系統(tǒng)的動(dòng)態(tài)特性時(shí)間順序、自上而下描述外部參與者和系統(tǒng)之間的交互CH6 架構(gòu)設(shè)計(jì)本章重點(diǎn)：v 什么是系統(tǒng)架構(gòu)v 什么是性能，如何衡量？什么是可用性？v 在架構(gòu)中，什么是封裝？什么是耦合？什么是解耦？什么是分層v 典型的軟件架構(gòu)：C/S架構(gòu)，B/S架構(gòu)，三層C/S架構(gòu)各自的優(yōu)缺點(diǎn)。選擇合適的軟件架構(gòu)v 邏輯三層結(jié)構(gòu)v 什么是。如何對用戶口令加密。RBAC。什

46、么是（安全）審計(jì)。v 架構(gòu)的設(shè)計(jì)與驗(yàn)證1.系統(tǒng)架構(gòu)（System Architecture）： 廣義上講，是指開發(fā)一個(gè)軟硬件系統(tǒng)所作出的最高層次的、以后難以更改的，商業(yè)的和技術(shù)的決定。 狹義上說，就是指軟硬件系統(tǒng)的組成結(jié)構(gòu) 用軟件架構(gòu)特指軟件系統(tǒng)的架構(gòu) 包括：各軟件元素、軟件元素的外在特性、軟件元素之間的關(guān)系2.軟件架構(gòu)的根本作用：保證軟件系統(tǒng)能夠滿足用戶的需求 軟件架構(gòu)的關(guān)注點(diǎn)更多的放在軟件的非功能性需求上過程需求（軟件交付方法、實(shí)現(xiàn)方法、交付時(shí)間）外部需求（互操作性、法律、道德約束、操作者水平等） 產(chǎn)品需求（質(zhì)量需求） 可用性、可靠性、安全性、可維護(hù)性等等3.重要的非功能性需求v 性能（P

47、erformance）：即系統(tǒng)完成特定功能的效率性能的主要衡量指標(biāo)： 吞吐率（throughput）：系統(tǒng)單位時(shí)間內(nèi)完成的工作量。又可分為平均吞吐率和峰值吞吐率。 響應(yīng)時(shí)間（Responsetime）：從用戶發(fā)出處理請求到收到處理結(jié)果所花的時(shí)間。又可分為平均響應(yīng)時(shí)間和最大響應(yīng)時(shí)間 截止期限（Deadline）：系統(tǒng)的任務(wù)必須在某個(gè)特定時(shí)間段內(nèi)完成架構(gòu)對性能的影響是雙方面的：對系統(tǒng)進(jìn)行分塊和分裝，會(huì)引入額外的通訊和運(yùn)行開銷；合理的布局和設(shè)計(jì)又可提高性能v 可復(fù)用性：軟件或其模塊可以重復(fù)使用的程度?？蓮?fù)用性越高，企業(yè)軟件開發(fā)效率越高典型：數(shù)據(jù)庫v 安全性：系統(tǒng)內(nèi)的信息被盜取或破壞，或者系統(tǒng)由于惡意

48、攻擊導(dǎo)致不能工作的可能性v 可用性：系統(tǒng)的一部分出現(xiàn)故障，導(dǎo)致整個(gè)系統(tǒng)不能正常工作的可能性，以及使系統(tǒng)完全恢復(fù)正常所需要的時(shí)間長短。v 可維護(hù)性：所有的軟件都需要修改和升級，好的架構(gòu)，能夠保證修改只影響系統(tǒng)中很小的一部分程序，從而使系統(tǒng)具備較好的可維護(hù)性各非功能性需求之間相互影響，架構(gòu)設(shè)計(jì)必須是一個(gè)權(quán)衡的過程價(jià)值觀 重要性排序4.目前軟件架構(gòu)設(shè)計(jì)所采用的基本指導(dǎo)思想是分治。其表現(xiàn)形式主要有兩種： 封裝：把功能抽取成獨(dú)立的模塊外界只能通過它的對外接口來訪問它的功能外界不需要關(guān)心它內(nèi)部的具體結(jié)構(gòu)和實(shí)現(xiàn)方法。 解耦：解除耦合耦合：軟件設(shè)計(jì)中的耦合就是指軟件元素之間的依賴關(guān)系。軟件中的耦合關(guān)系越多，就

49、越難以修改和維護(hù)。解耦包含兩層含義：u 減少模塊之間的過度耦合u 對于必須存在的耦合（聯(lián)系），盡量使之標(biāo)準(zhǔn)化5.封裝和解耦思想在架構(gòu)中主要體現(xiàn)為“分層” 分層：通過在軟件整體結(jié)構(gòu)中，將基本功能集中到一個(gè)模塊中的做法，即稱為分層較高層次的層可以調(diào)用較低層次的層，而反之則不然。即層與層之間的依賴是單向的 解耦的另一種常用方法：參數(shù)化配置通過分層和配置，對軟件外部耦合關(guān)系實(shí)現(xiàn)解耦 繼承和多態(tài) 減少內(nèi)部耦合基于接口的開發(fā)封裝和解耦往往是在一起進(jìn)行的： 封裝的模塊是按照解耦原則劃分出來的 不封裝的解耦是無意義的6.直接式架構(gòu)：沒有架構(gòu)優(yōu)點(diǎn)：結(jié)構(gòu)簡單、容易實(shí)現(xiàn)缺點(diǎn)：沒有明確的結(jié)構(gòu)、其軟件質(zhì)量特性沒有保證適

50、合：功能簡單的軟件7.分層架構(gòu)：n層架構(gòu)：把系統(tǒng)分為若干層，上層調(diào)用下層典型：TCP/IP網(wǎng)絡(luò)8.基于物理分布的分層架構(gòu)l 2層結(jié)構(gòu)或C/S結(jié)構(gòu) Visual Basic、Visual Foxprov 特點(diǎn) 系統(tǒng)分成兩層 一層是客戶端（Client），它是運(yùn)行在用戶計(jì)算機(jī)上的一個(gè)可執(zhí)行程序。 一層是服務(wù)器層（Server），通常是運(yùn)行在后臺服務(wù)器上的數(shù)據(jù)庫及其存儲過程。 系統(tǒng)主要的功能，比如與用戶進(jìn)行交互等，都在客戶端程序中完成。 后臺數(shù)據(jù)庫集中存儲重要的系統(tǒng)數(shù)據(jù)。v C/S解決了單機(jī)軟件之間數(shù)據(jù)共享和協(xié)作的問題v 二層架構(gòu)的缺點(diǎn) 客戶端必須保存數(shù)據(jù)庫的訪問密碼，非常不利于安全。 當(dāng)客戶端數(shù)量

51、很多時(shí)，部署和升級不便l 3層或B/S結(jié)構(gòu)v 特點(diǎn) 系統(tǒng)分成三層 一層是瀏覽器（Browser），運(yùn)行在客戶計(jì)算機(jī)上，負(fù)責(zé)解釋和顯示網(wǎng)頁內(nèi)容。 一層是應(yīng)用服務(wù)器層（Application Server），運(yùn)行在后臺服務(wù)器上，負(fù)責(zé)處理用戶請求和生成網(wǎng)頁內(nèi)容。 一層是數(shù)據(jù)庫層（Database Server），運(yùn)行在后臺單獨(dú)的服務(wù)器上，負(fù)責(zé)數(shù)據(jù)存儲 系統(tǒng)的核心業(yè)務(wù)處理都統(tǒng)一在應(yīng)用服務(wù)器層完成v 優(yōu)點(diǎn) 利于升級和部署。 數(shù)據(jù)庫不直接暴漏在外，安全性更高。 容易擴(kuò)展和優(yōu)化v 缺點(diǎn) 對應(yīng)用服務(wù)器的性能有較高要求。 瀏覽器的功能有限，如打印、刷卡輸入等解決辦法：RIAl 3層C/S結(jié)構(gòu)即將原B/S三層架構(gòu)

52、的中的瀏覽器改為專門開發(fā)的客戶端彌補(bǔ)B/S功能受限的缺陷9.幾種分層架構(gòu)的比較10. 目前絕大多數(shù)基于互聯(lián)網(wǎng)的軟件都采用了三層架構(gòu)。二層架構(gòu)主要用在少數(shù)基于專用內(nèi)部網(wǎng)的企業(yè)或組織中： 超市、郵局、銀行、專用工業(yè)控制設(shè)備等11.三層邏輯架構(gòu)將應(yīng)用服務(wù)器分為三層v 用戶界面層（表示層視圖層）：解耦用戶人機(jī)交互方式的變化 處理用戶請求，繪制網(wǎng)站頁面v 業(yè)務(wù)層（領(lǐng)域?qū)樱航怦顦I(yè)務(wù)處理規(guī)則的變化 根據(jù)業(yè)務(wù)規(guī)則處理業(yè)務(wù)請求v 數(shù)據(jù)存儲層（數(shù)據(jù)持久層）：解耦外部協(xié)作系統(tǒng)的變化 負(fù)責(zé)將對象與關(guān)系式數(shù)據(jù)庫表之間的轉(zhuǎn)換 與數(shù)據(jù)庫進(jìn)行通信協(xié)作12.系統(tǒng)安全的基本原則：AAA 身份驗(yàn)證（Authentication）

53、：通過某種方式，確定系統(tǒng)使用者的真實(shí)身份?？诹?、密碼Hash算法 授權(quán)管理（Authorization）：根據(jù)用戶的身份為其賦予相應(yīng)的操作權(quán)限訪問控制：簡單系統(tǒng)采用權(quán)限表的方式復(fù)雜系統(tǒng)采用RBAC（Role-Based Access Control，基于角色的訪問控制）用戶角色表&權(quán)限表放在哪一層尚無定論 審計(jì)（Accounting或Audit）：記錄和監(jiān)控用戶的所有操作。在事中或事后，定期或不定期的檢查記錄，發(fā)現(xiàn)是否有違規(guī)行為審計(jì)的前提是有各種操作的記錄，因此需要專門模塊對操作進(jìn)行記錄日志模塊 備份種類：冷備份/熱備份/增量備份；本地備份/遠(yuǎn)程備份/異地備份；人工備份/自動(dòng)備份13.架構(gòu)的設(shè)計(jì)與驗(yàn)證設(shè)計(jì)：根據(jù)需求劃分業(yè)務(wù)功能模塊（縱向劃分）依據(jù)非功能需求和解耦思想，對系統(tǒng)分層（橫向劃分）將功能模塊分配到對應(yīng)層（縱橫結(jié)合）補(bǔ)充訪問控制、日志等必要模塊，完善架構(gòu)決定每一層是否自行開發(fā)，開發(fā)應(yīng)采用的主要開發(fā)語言和技術(shù)等細(xì)節(jié)問題驗(yàn)證：試錯(cuò)法：對架構(gòu)設(shè)計(jì)行不通架構(gòu)設(shè)計(jì)的風(fēng)險(xiǎn)：架構(gòu)不能錯(cuò)；架構(gòu)只是一個(gè)設(shè)計(jì)，沒法測試兩種驗(yàn)證方法v 場景測試: 用一系列假設(shè)的故事來發(fā)現(xiàn)系統(tǒng)架構(gòu)設(shè)計(jì)的缺陷v 架構(gòu)原型: 按照設(shè)計(jì)的基本架構(gòu)開發(fā)一個(gè)實(shí)驗(yàn)性質(zhì)的系統(tǒng)實(shí)現(xiàn)，以實(shí)際檢驗(yàn)架構(gòu)或者系統(tǒng)的高風(fēng)險(xiǎn)或關(guān)鍵設(shè)計(jì) 架構(gòu)原型的主要作用：驗(yàn)證概念：設(shè)計(jì)架構(gòu)能否實(shí)際實(shí)現(xiàn)