軟件工程復習筆記

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

29、標級別用例中的單個步驟的進一步描述，如（超市）用戶刷卡付款等。判斷： （圖書館管理系統(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è)務v 前置條件：在用例中的場景開始之前，必須保證為真的條件用例中不要出現(xiàn)對前置條件進行檢查的步驟可以不寫觸發(fā)條件：導致用例中的場景開始的事件?；颈ＷC：在用例執(zhí)行后，系統(tǒng)對各利益相關(guān)者的利益的最小保證 無論用例最終執(zhí)行是否成功，系統(tǒng)都必須確保基本保證中的承諾。成功保證：承諾如果用例成功執(zhí)行完畢

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

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

32、景、技能水平等情況。用例應該讓用戶來寫。5.用例圖：用于描繪用例、系統(tǒng)、參與者及其之間的關(guān)系（語境圖）主要參與者系統(tǒng)（多個用例）協(xié)助參與者作用： 展示系統(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)注

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

34、進行逐步分解子圖是對父圖中某一加工步驟的詳細展開；每一層所包含的加工通常不超過7個；各層數(shù)據(jù)流保持平衡：父圖中某加工的輸入輸出數(shù)據(jù)流應該同其子圖的輸入輸出相同(相對應）。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 + 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次或多次重復的a構(gòu)成 X= man x由m至n個a組成，即至少有m個a,至多有n個a X= a.bx可以取a至b的任一值 X= “a”

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

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

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

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

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

40、）重載：overload （同一個類中的）多個方法可以使用同一個名字（解決做同一件事，可能需要不同參數(shù)的情況） 重載和多態(tài)、OOP沒有關(guān)系！10.動態(tài)綁定：一段方法代碼的具體行為是在程序運行時，才由傳遞給它的實參到底是什么類型決定的public class Test public static void main(String args) Animal ani=new Dog(旺財); ani.run(); ani.cry(); 11.抽象類：在父類中的某些方法（抽象方法）只是起到一個定義契約的作用，沒有具體實現(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語言中一個類只能有一個父類的限制；而一個類可以同時實現(xiàn)零到多個接口接口就相當于一個純粹的契約實現(xiàn)一個接口，就是實現(xiàn)接口中聲明的所有方法通常我們用繼承關(guān)系表示類在概念上的包含與從屬關(guān)系（i

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

43、不需要考慮概念類到底都有哪些屬性5.領(lǐng)域建?；静襟E： 尋找概念類：重用已有模型；使用分類列表；語言分析（與分類列表一起使用）概念類中有一類是對事物的描述，即描述類，避免：數(shù)據(jù)冗余；信息丟失概念類分析準則： 準則1:不要把概念類誤認為屬性如果我們認為某事物X不是現(xiàn)實世界中的數(shù)字或文字，那么X可能是概念類而不是屬性 準則2：報表對象模型中是否要包括“票據(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è)務需要關(guān)注和

44、記錄的關(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)命名準則：格式為“類名動詞短語類名”；動詞短語應是可讀的、有意義的多重性：定義了類A有多少個實例可以和類B的一個實例關(guān)聯(lián)多重性的數(shù)值表示在特定時間點上有效關(guān)聯(lián)的實例數(shù)量多重性的數(shù)值還與建模者的關(guān)注角度有關(guān)多重關(guān)聯(lián)7.屬性分析：屬性：表示對象某一方面性質(zhì)的邏輯數(shù)據(jù)值屬性分析的目的：在領(lǐng)域模型中進一步確定概念類的屬性，可以更好的展現(xiàn)當前所開發(fā)場景的信息需求。導出屬性：有些屬性可以從其他屬性，或關(guān)聯(lián)類的信息中推導出來（冗余，一般不

45、應該在領(lǐng)域模型中出現(xiàn)。）一般來說屬性的類型不應該是復雜的領(lǐng)域概念（即其他概念類）8.系統(tǒng)順序圖：使用簡化的UML順序圖來描述外部參與者與SuD之間的輸入和輸出事件。使用系統(tǒng)順序圖(System Sequence Diagram, SSD）來闡述系統(tǒng)的動態(tài)特性時間順序、自上而下描述外部參與者和系統(tǒng)之間的交互CH6 架構(gòu)設計本章重點：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)缺點。選擇合適的軟件架構(gòu)v 邏輯三層結(jié)構(gòu)v 什么是。如何對用戶口令加密。RBAC。什

46、么是（安全）審計。v 架構(gòu)的設計與驗證1.系統(tǒng)架構(gòu)（System Architecture）： 廣義上講，是指開發(fā)一個軟硬件系統(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)注點更多的放在軟件的非功能性需求上過程需求（軟件交付方法、實現(xiàn)方法、交付時間）外部需求（互操作性、法律、道德約束、操作者水平等） 產(chǎn)品需求（質(zhì)量需求） 可用性、可靠性、安全性、可維護性等等3.重要的非功能性需求v 性能（P

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

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

49、越難以修改和維護。解耦包含兩層含義：u 減少模塊之間的過度耦合u 對于必須存在的耦合（聯(lián)系），盡量使之標準化5.封裝和解耦思想在架構(gòu)中主要體現(xiàn)為“分層” 分層：通過在軟件整體結(jié)構(gòu)中，將基本功能集中到一個模塊中的做法，即稱為分層較高層次的層可以調(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ì)量特性沒有保證適

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

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

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

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