軟件工程課件

軟體工程軟體工程概述軟體工程中常見問題什麼是軟體？什麼是軟體工程？軟體工程和電腦科學有何區(qū)別？軟體工程和系統(tǒng)工程有何區(qū)別？什麼是軟體過程？什麼是軟體過程模型？軟體工程概述什麼是軟體？軟體：軟體是能夠完成預定義功能的可執(zhí)行的電腦程式和使程式正常執(zhí)行所需要的數(shù)據(jù)，加上描述程式的操作和文檔。簡明地表述，可以寫作：軟體=程式+文檔。軟體=程式+文檔可執(zhí)行部分不可執(zhí)行部分文檔1文檔2文檔3程式軟體工程概述程式：程式是為了解決某個特定問題而用程式設計語言描述的適合電腦處理的語句序列。Main(){inti,j;

//變數(shù)定義

charStr[10];i=i+j;//語句說明

……}ClassOrder{Stringnumber;//屬性

Stringcustomer;create()//方法

{……}……}C語言程式Java語言程式軟體工程概述範型：又稱為科學基質，代表科學共同體成員所共有的信念、價值、技術手段的總稱。簡單地說，範型是某一學科在一定時期內展開研究活動共有的基礎和準則。編程範型：是指導和制約編程活動的範型，通常在編程語言中體現(xiàn)。命令式編程範型面向對象的編程範型基於構件的編程範型面向服務的編程範型面向問題的編程範型其他範型軟體工程概述命令式編程範型：又稱過程式編程範型，指用程式狀態(tài)和改變程式狀態(tài)的語句描述計算的編程範型。命令式範型的典型語言包括：依賴於電腦機器語言和組合語言、獨立於電腦的高級語言(如Fortran、Pascal和C等)。記憶體(程式和數(shù)據(jù))

控制器

運算器

I/O地址數(shù)據(jù)CPUVonNeumann式電腦體系結構命令式編程範型是對VonNeumann式電腦的順序執(zhí)行機制的直接抽象。軟體工程概述面向對象的編程範型：是指用封裝了數(shù)據(jù)和對數(shù)據(jù)操作的對象以及對象之間的消息傳遞描述計算的編程範型。Java、C#是典型的面向對象編程範型語言。數(shù)據(jù)操作對象數(shù)據(jù)數(shù)據(jù)消息面向對象編程範型的示意圖對象對象面向對象編程範型的3個基本特徵：封裝、繼承和多態(tài)。軟體工程概述數(shù)據(jù)對象數(shù)據(jù)數(shù)據(jù)消息對象一個封裝了多個對象的構件構件的介面構件：模組化的、可部署、可替換的軟體系統(tǒng)組成部分，它封裝了內部的具體實現(xiàn)並對外提供一組介面?；稑嫾木幊坦犘停褐敢詷嫾膭?chuàng)建，構件的管理以及複用已有的構件組裝形成應用為基本活動的編程範型。目前有代表性的構件規(guī)範有COM/DCOM、EJB和CORBA。軟體工程概述服務1服務2服務3服務4異構系統(tǒng)的功能被封裝為服務以方便複用應用1(J2EE)應用2(.Net)應用3(Legacy)服務層應用層面向服務的編程範型：指以服務的創(chuàng)建、服務的管理以及複用已有的服務組裝形成應用為基本活動的編程範型。面向服務的編程技術WebService、BPEL、SCA等。服務：是自治、開放、自描述、與實現(xiàn)無關的網(wǎng)路構件。軟體工程概述面向問題的編程範型：該編程範型不需要程式員指明程式實現(xiàn)過程，只需給出問題和輸入數(shù)據(jù)，並指明輸出的形式，就可以得到所需結果。例如，資料庫查詢語言、報表語言、電路設計專用語言、人工智慧語言(Prolog)等。軟體工程概述文檔：軟體開發(fā)活動的記錄，主要供人們閱讀，既可用於專業(yè)人員和用戶之間的通信和交流，也可以用於軟體開發(fā)過程的管理和運行階段的維護。文檔的類型需求分析文檔軟體設計文檔軟體測試文檔……軟體工程概述軟體的類型系統(tǒng)軟體：電腦系統(tǒng)軟體是電腦管理自身資源(如CPU、記憶體、外存、外設等)，提高電腦使用效率並為電腦用戶提供各種服務的基礎軟體。例如，操作系統(tǒng)、資料庫管理系統(tǒng)等。即時軟體：監(jiān)測、分析和控制現(xiàn)實世界發(fā)生的事件，能以足夠快的速度對輸入資訊進行處理，並在規(guī)定的時間內作出反應的軟體。例如，各種設備運行監(jiān)控軟體等。軟體工程概述嵌入式軟體：嵌入式電腦系統(tǒng)將電腦嵌入在某一系統(tǒng)之中，使之成為該系統(tǒng)的重要組成部分，控制該系統(tǒng)的運行，進而實現(xiàn)某一特定的物理過程。用於嵌入電腦系統(tǒng)的軟體稱為嵌入式軟體。例如，航空航太系統(tǒng)、指揮系統(tǒng)、汽車控制系統(tǒng)等?？茖W和工程電腦軟體：它們以數(shù)值演算法為基礎，對數(shù)值量進行處理和計算，主要用於科學和工程計算。例如，數(shù)值天氣預報、導彈計算、石油勘探、計算輔助設計(CAD)等。軟體工程概述事務處理軟體：用於處理事務資訊，特別是商務資訊的電腦軟體。事務資訊處理是軟體最大的應用領域。例如，工資管理系統(tǒng)、人事管理系統(tǒng)、企業(yè)資源計畫系統(tǒng)(ERP)等。人工智慧軟體：支持電腦系統(tǒng)產(chǎn)生人類某些智能的軟體。它們求解複雜問題不是用傳統(tǒng)的計算或分析方法，而是採用諸如基於規(guī)則的演繹推理技術和演算法。應用領域有專家系統(tǒng)、模式識別、自然語言理解、人工神經(jīng)網(wǎng)路、程式驗證、自動程式設計、機器人學等。軟體工程概述CASE工具軟體：CASE工具軟體一般為支撐軟體生存週期中不同活動而研製，包括專案管理工具、需求分析工具、編程環(huán)境(編輯器、編譯器、鏈接器和測試器於一體)、軟體測試工具等。其他軟體：軟體工程概述軟體的特徵軟體開發(fā)更依賴於開發(fā)人員的業(yè)務素質、智力、人員的組織、合作和管理。軟體開發(fā)性質，如成本和進度等難以估計。軟體開發(fā)成功後，只需對原版進行複製。軟體不會老化。軟體在使用過程中維護比較複雜。軟體工程概述什麼是軟體工程？軟體工程：軟體工程是用工程、科學和數(shù)學的原則與方法研製、維護電腦軟體的有關技術及管理方法。首次提出：1968年，北大西洋公約組織在原西德召開電腦科學會議，由FritzBauer首次提出了“軟體工程”的概念。提出背景：解決軟體危機。軟體工程概述軟體危機：

軟體危機是指在電腦軟體的開發(fā)和維護過程中所遇到的一系列嚴重問題。兩個主要問題：如何開發(fā)軟體，怎樣滿足對軟體的日益增長的需求。如何維護數(shù)量不斷膨脹的已有軟體。軟體工程概述軟體危機的主要表現(xiàn)對軟體開發(fā)成本和進度的估計不準確用戶不滿意軟體品質不高、可靠性差軟體常常不可維護、錯誤難以改正缺乏適當?shù)奈臋n資料軟體成本占系統(tǒng)總成本的比例逐年上升軟體開發(fā)速度跟不上電腦發(fā)展速度軟體工程概述產(chǎn)生軟體危機的原因與軟體本身的特點有關：軟體不同於硬體，它是電腦系統(tǒng)的邏輯部件而不是物理部件。在寫出程式代碼並在電腦運行之前，軟體開發(fā)過程的進展情況較難衡量，軟體開發(fā)的品質也較難評價。因此，管理和控制軟體開發(fā)過程相當困難。軟體不易於維護軟體維護通常意味著改正或修改原來的設計，客觀上使軟體較難維護。軟體不同於一般程式，它的規(guī)模大，不易於維護。在軟體開發(fā)過程中，或多或少地採用了錯誤的方法和技術。對用戶需求沒有完整準確的認識，就匆忙著手編寫程式。軟體工程概述解決軟體危機的途徑技術措施使用更好的軟體開發(fā)方法和開發(fā)工具組織管理措施軟體開發(fā)不是某種個體勞動的神秘技巧，而應該是一種組織良好、管理嚴密、各類人員協(xié)同配合、共同完成的工程專案。軟體工程概述軟體工程的三要素過程方法工具軟體工程軟體工程三要素方法：軟體工程方法是完成軟體工程專案的技術手段，它支持專案計畫和估算、系統(tǒng)和軟體需求分析、軟體設計、編碼、測試和維護。軟體工程概述結構化程式設計

面向對象分佈式對象/系統(tǒng)基於構件的開發(fā)面向服務的計算19701980199020002010軟體開發(fā)方法的演化軟體工程概述工具：軟體工程使用的工具是人類在開發(fā)軟體的活動中智力和體力的擴展和延伸，它自動或半自動地支持軟體的開發(fā)和管理、支持各種軟體文檔的生成。過程：軟體工程中的過程貫穿於整個工程的各個環(huán)節(jié)，在這一過程中，管理人員應對軟體開發(fā)的品質、進度、成本等進行評估、管理和控制，包括計畫跟蹤與控制、成本估算、人員的組織、品質保證、配置管理等。軟體工程概述客戶發(fā)起系統(tǒng)開發(fā)人員客戶構建系統(tǒng)使用系統(tǒng)需要的資金合同契約需要軟體系統(tǒng)客戶(Customer)：是為將要開發(fā)的軟體系統(tǒng)支付費用的公司、組織或個人。開發(fā)人員(Developer)：是為客戶構建軟體系統(tǒng)的公司、組織或個人，其中包括任何協(xié)調並指導程式員和測試人員的管理人員。用戶(User):是將實際使用系統(tǒng)的人，包括坐在終端前的人、提交數(shù)據(jù)的人和閱讀輸出的人。軟體工程中涉及到人員軟體工程概述軟體工程的目標-可修改性(modifiability)：容許對系統(tǒng)進行修改而不增加原系統(tǒng)的複雜性。-有效性(efficiency)：指軟體系統(tǒng)的時間和空間效率。-可靠性(reliability)：能夠防止因概念、設計和結構等方面的不完善造成軟體系統(tǒng)失效，具有挽回因操作不當造成軟體系統(tǒng)失效的能力。軟體工程概述-可理解性(understandability)：系統(tǒng)具有清晰的結構，能直接反映問題的需求。-可維護性(maintainability)：軟體產(chǎn)品交付用戶使用後，能夠對它進行修改，以便改正潛在的錯誤和其他屬性，使軟體產(chǎn)品適應環(huán)境變化等方面工作的難易程度。-可重用性(reusability)：是指軟體可以在多種場合使用的程度。軟體工程概述-可適應性(adaptability)：軟體在不同系統(tǒng)約束條件下，使用戶需求得到滿足的難易程度。-可移植性(portability)：軟體從一個電腦系統(tǒng)或環(huán)境搬到另一個電腦系統(tǒng)或環(huán)境的難易程度。-可追蹤性(traceability)：根據(jù)軟體需求對軟體設計、程式進行正向追蹤，或者根據(jù)程式、軟體設計對軟體需求進行逆向追蹤的能力。-可互操作性(interoperability)：多個軟體元素相互通信並協(xié)同完成任務的能力。軟體工程概述軟體工程技術發(fā)展的一種途徑LINIXUNIXWindowsFortranJavaApplication遮罩電腦硬體的異構性發(fā)展了操作系統(tǒng).Net/COMJ2EE/EJBWebservice遮罩不同中間件之間的異構性發(fā)展了Web服務ArchitectureframeworkdesignpatternSupportsoftwaremiddlewareC/C++遮罩應用軟體和開發(fā)平臺之間的差異產(chǎn)生了體系結構/框架/設計模式遮罩操作系統(tǒng)之間和編程語言之間的異構性出現(xiàn)了支撐軟體和中間件軟體工程概述軟體工程和電腦科學的區(qū)別？電腦科學研究的是構成電腦和軟體系統(tǒng)基礎的有關理論和方法。軟體工程研究軟體製作中的一些實際問題。軟體工程應以電腦科學理論作為基礎。軟體工程是一門實踐性比較強的學科。對於實際、複雜的問題，電腦科學的經(jīng)典理論不可能總是適用的，這時需要軟體工程的方法來解決。軟體工程概述軟體工程和(電腦)系統(tǒng)工程有何區(qū)別？系統(tǒng)：系統(tǒng)是一組相互關聯(lián)、能在一起工作從而達到某個目標的相關元素的集合。電腦系統(tǒng)：通過處理資訊來完成某些預定義目標而組織在一起的元素的集合或排列。電腦系統(tǒng)構成要素：軟體(Software)、硬體(Hardware)、人(People)、資料庫(Database)、文檔(Document)、過程(Procedure)。軟體工程概述系統(tǒng)過程硬體軟體人資料庫文檔輸入輸出基於電腦的系統(tǒng)要素軟體工程概述電腦系統(tǒng)工程：是指與構造基於電腦系統(tǒng)有關的過程、方法和技術。硬體工程軟體工程人機交互工程資料庫工程軟體工程概述什麼是軟體過程(軟體生存週期)？軟體生存週期：軟體從定義開始，經(jīng)過開發(fā)、使用和維護直到最終退役的全過程稱為軟體生存週期。典型軟體生存週期一般分為：計畫時期：問題定義、可行性研究開發(fā)時期：需求分析、軟體設計、軟體編碼、軟體測試運行時期：軟體維護軟體工程概述需求分析

軟體設計編碼維護

測試問題定義可行性研究計畫時期開發(fā)時期維護時期軟體工程概述什麼是軟體過程模型(軟體開發(fā)模型)？軟體開發(fā)模型：一個軟體專案開發(fā)和維護的總體過程思路的框架。作用：指出了軟體開發(fā)過程各階段之間的關係和順序。為軟體開發(fā)過程提供原則和方法。為軟體工程管理提供里程碑和進度表。軟體工程概述主要的軟體開發(fā)模型傳統(tǒng)的軟體開發(fā)模型瀑布模型快速原型模型軟體演化模型階段開發(fā)模型螺旋模型面向對象開發(fā)模型統(tǒng)一過程形式化方法模型轉換模型模型驅動的開發(fā)模型基於構件的軟體開發(fā)模型構件集成模型基於複用的軟體開發(fā)模型軟體工程概述瀑布模型(WaterfallModel)是W.Royce於1970年提出。在瀑布模型中，各階段的工作順序展開。瀑布模型的特徵階段間的順序性和依賴性：前一階段工作完成以後，後一階段工作才能開始；前一階段的輸出文檔，是後一階段的輸入文檔。推遲實現(xiàn)觀點：需求分析軟體設計編碼品質保證觀點：每一階段都要完成規(guī)定文檔，沒有完成文檔，就認為沒有完成該階段的任務；每一階段都要對已有的文檔進行復審，以便儘早發(fā)現(xiàn)問題，消除隱患。軟體工程概述用戶要求需求分析需求規(guī)格說明總體設計軟體結構圖詳細設計模組說明編碼程式清單單元測試綜合測試確認測試系統(tǒng)測試瀑布模型的階段和文檔軟體工程概述瀑布模型存在問題軟體開發(fā)的初始階段指明軟體系統(tǒng)的全部需求是困難的，有時甚至是不現(xiàn)實的。需求確定以後，用戶和軟體專案負責人要等到相當長的時間(設計實現(xiàn)測試運行)才能得到一份軟體的最初版本。如果用戶對這個軟體提出比較大的修改意見，那麼軟體專案將會受到巨大的人力、財力和時間方面的損失。軟體工程概述快速原型模型(RapidPrototypeModel)原型：是一個部分開發(fā)的產(chǎn)品，它使客戶和開發(fā)人員能對計畫開發(fā)的系統(tǒng)來實現(xiàn)一小部分關鍵需求，以確保需求是一致的、可行和符合實際的?？焖僭湍Ｐ停菏紫冉⒁粋€能夠反映用戶主要需求的原型，讓用戶實際看一看未來系統(tǒng)的概貌，以便判斷哪些功能是符合需求的，哪些還需要改進。然後將原型反復改進，最終建立完全符合用戶要求的新系統(tǒng)。軟體工程概述需求分析原型評價最終系統(tǒng)設計

最終系統(tǒng)實現(xiàn)

原型開發(fā)規(guī)格說明可運行原型用戶回饋快速原型模型的生存週期模型軟體工程概述建立快速原型的方法：原型系統(tǒng)僅包含未來的主要功能以及系統(tǒng)的重要介面。原型系統(tǒng)充分展示軟體的可見部分，如數(shù)據(jù)的輸入方式、人機介面、數(shù)據(jù)的輸出格式。為了儘快向用戶提供原型，開發(fā)原型系統(tǒng)時應儘量使用能縮短開發(fā)週期的語言和工具。將原型系統(tǒng)作為基礎，通過補充與修改獲得最終的實際系統(tǒng)。軟體工程概述階段化開發(fā)模型迴圈週期：從編寫需求文檔到系統(tǒng)交付的時間稱為迴圈週期。減少迴圈週期的方法：階段化開發(fā)。階段化開發(fā)方法：使用階段化開發(fā)方法設計系統(tǒng)時，能夠使其一部分一部分地交付，從而在系統(tǒng)其餘部分正在開發(fā)的同時，用戶已經(jīng)獲得了一部分功能。因此，通常會存在兩個並行的系統(tǒng)：運行系統(tǒng)或產(chǎn)品系統(tǒng)和開發(fā)系統(tǒng)。軟體工程概述階段化開發(fā)模型構建發(fā)佈1構建發(fā)佈2構建發(fā)佈3發(fā)佈1發(fā)佈2發(fā)佈3開發(fā)系統(tǒng)(DevelopmentSystem)開發(fā)人員用戶時間準備用來替換現(xiàn)行產(chǎn)品系統(tǒng)的下一個版本產(chǎn)品系統(tǒng)(ProductionSystem)當前正在被客戶和用戶所使用的系統(tǒng)軟體工程概述增量開發(fā)和迭代開發(fā)增量開發(fā)(IncrementalDevelopment)迭代開發(fā)(IterativeDevelopment)在增量開發(fā)中，需求文檔中指定的系統(tǒng)按照功能劃分為子系統(tǒng)。定義發(fā)佈時首先定義一個小的功能子系統(tǒng)，然後在每一個新的發(fā)佈中增加新功能。迭代開發(fā)是在一開始就提交一個完整的系統(tǒng)，然後在每一個新的發(fā)佈中改變每個子系統(tǒng)的功能軟體工程概述採用階段化開發(fā)方法的原因即使還缺少某些功能，但在早期的發(fā)佈中就可以開始培訓。培訓過程可以使開發(fā)人員觀察某些功能的如何執(zhí)行的，並為後面的發(fā)佈提供改進的建議。這樣開發(fā)人員可以很好地對用戶的回饋做出反應?？梢约霸绲貫槟切┮郧皬奈刺峁┑墓δ荛_拓市場。當運行系統(tǒng)出現(xiàn)未預料到的問題時，經(jīng)常性的發(fā)佈可以使開發(fā)人員能全面、快速地修復這些問題。針對不同的發(fā)佈版本，開發(fā)團隊將重點放在不同的專業(yè)領域技術上。軟體工程概述螺旋模型(SpiralModel)在瀑布模型和快速原型模型的基礎上增加了風險分析。螺旋模型類似於迭代開發(fā)模型。它以需求和一個初始計畫(包括預算、約束、人員安排方案、設計和開發(fā)環(huán)境)為起點，在產(chǎn)生“操作概念”文檔(從高層描述系統(tǒng)如何工作)之前，插入一個風險評估和可選原型的步驟。操作概念是第一次迭代的產(chǎn)品，而需求則是第二次迭代的主要產(chǎn)品。在第四次迭代中，系統(tǒng)開發(fā)產(chǎn)生設計，而第四次迭代能夠進行測試。軟體工程概述螺旋模型(SpiralModel)

確定目標、可選方案及約束操作概念預算1預算2預算3預算4風險分析1需求、生命週期計畫約束1約束2約束3約束4風險分析2風險分析3風險分析4原型1原型2原型3原型4軟體需求經(jīng)確認的需求開發(fā)計畫軟體設計評估可選方案及風險可選方案2可選方案1可選方案3可選方案4制定計畫集成和測試計畫開發(fā)與測試經(jīng)確認的設計詳細設計編碼單元測試系統(tǒng)測試驗收測試實施計畫軟體工程概述面向對象的開發(fā)模型編程語言：Simula67(20世紀60年代)、Smalltalk(20世紀80年代)、C++和Java(20世紀90年代)建模語言：Booch、Rumbaugh和Jacoson共同提出的統(tǒng)一建模語言(UML)。面向對象的基本概念對象：對象是對現(xiàn)實世界中個體或事物的抽象表示，是它的屬性和相關操作的統(tǒng)一封裝體。屬性表示對象的性質，屬性值規(guī)定了對象所有可能的狀態(tài)。對象的操作是指該對象可以展示的外部服務。軟體工程概述面向對象的基本概念(續(xù))類：類用於表示某些對象的共同特徵(屬性和操作)，對象是類的實例。繼承關係：它是現(xiàn)實世界中遺傳關係的直接模擬，可以來表示類之間的內在聯(lián)繫以及對屬性和操作的共用。子類可以沿用父類的某些特徵，同時子類也可以具有自己獨立的屬性和操作。整體-部分關係：分為聚合和組合。聚合表示對象之間鬆散整體-部分關係，例如，計算和外設置之間的關係。組合表示對象之間強的整體-部分關係，例如，樹和樹葉之間的關係。消息：消息傳遞是對象與其外部世界相互關聯(lián)的唯一途徑。對象可以向其他對象發(fā)送消息以請求服務，也可以回應其他對象傳來的消息，完成自身固有的某些操作，從而服務於其他對象。軟體工程概述例：下麵是某企業(yè)的兩張客戶訂單，如何採用面向對象的概念來描述它們？軟體工程概述統(tǒng)一過程(UnifiedProcess，UP)UP的歷史Rational統(tǒng)一過程(RUP)是IBMUP的商業(yè)版本。RUP是UP的擴展。軟體工程概述需求分析設計實現(xiàn)測試迭代評估計畫專案相關其他活動UP中5個核心工作流其他工作流需求:捕獲系統(tǒng)應該做什麼分析:精化和結構化需求設計:在系統(tǒng)架構內實現(xiàn)需求實現(xiàn):構造軟體測試:驗證實現(xiàn)是否如期望那樣工作

軟體工程概述生命週期目標生命週期架構初始運作功能

產(chǎn)品發(fā)佈初始細化構造移交迭代1迭代2迭代3迭代4迭代5迭代6RADIT里程碑階段迭代5個核心工作流……建立可行性；創(chuàng)建業(yè)務用例；捕獲基本需求；識別關鍵風險。創(chuàng)建可執(zhí)行的架構基線；精化風險評估；定義品質屬性；捕獲80%的功能性需求用例；為構造階段創(chuàng)建詳細計畫完成所有的需求、分析和設計。修復缺陷；為用戶場所地準備新軟體；在用戶場所地裁減軟體；如果不可預見的問題出現(xiàn)，修改軟體；創(chuàng)作用戶手冊和其他文檔；提供用戶諮詢；產(chǎn)生專案後評審RADIT目標RADITRADITRARADIIT焦點UP的結構軟體工程概述第1次迭代第2次迭代第n-1次迭代初始細化構造移交需求第n次迭代分析設計實現(xiàn)測試隨著專案按UP的階段進展，每個核心工作流的工作量發(fā)生變化軟體工程概述轉換模型(TransformationModel)與需求比較後修正形式化規(guī)格說明形式化開發(fā)記錄變換n變換2變換1測試系統(tǒng)需求目標系統(tǒng)軟體工程概述模型驅動的軟體開發(fā)模型計算無關模型(CIM)平臺獨立模型(PIM)代碼

(Code)平臺相關模型(PSM)CIM是非常高級層次的抽象模型，它以一種獨立於電腦的方式捕獲了系統(tǒng)的關鍵需求以及問題域的辭彙。PIM是獨立於任何底層平臺的(例如，EJB,.Net)、表達軟體系統(tǒng)業(yè)務語義的模型。PSM包含了所有在PIM中表達的功能，並且還添加了針對實現(xiàn)平臺的設計思想。軟體系統(tǒng)(SoftwareSystem)

映射產(chǎn)生部署軟體工程概述構件集成模型(ComponentIntegrationModel)將新構件存入庫中標誌候選構件在構件庫中查找構件進行下一次迭代構造構件是否存在構件？是否計畫風險分析用戶通信產(chǎn)品開發(fā)與發(fā)佈用戶評估提取構件基於複用的軟體開發(fā)模型軟體工程概述分析領域需求的共性及變化性建立滿足領域需求的軟體架構(DSSA)在代碼級實現(xiàn)面向領域的構件可交付系統(tǒng)課程內容軟體工程概述軟體需求分析軟體設計軟體編碼軟體測試軟體維護軟體複用軟體工程管理軟體品質管理軟體需求分析需求分析的重要性材料1994年，StandishGroup調查了350多家公司的8000多個軟體專案，瞭解它們的進展情況。調查結果讓人吃驚，31%的軟體專案在完成之前就取消了。在大公司中，只有9%的專案按時在預算內交付，在小公司內，滿足這些標準的有16%。為了瞭解其中的原因，Standish請求被調查者解釋專案失敗的原因，首要的原因如下：不完整的需求(13.1%)。缺少用戶的參與(12.4%)。缺乏資源(10.6%)。軟體需求分析不切實際的期望(9.9%)。缺乏行政支持(9.3%)。改變需求和規(guī)格說明(8.7%)。缺乏計畫(8.1%)。不再需要該系統(tǒng)(7.5%)。軟體需求分析什麼是需求？需求(Requirement)就是對期望的行為的表達。需求處理的是對象或實體，它們可能處於的狀態(tài)，以及用於改變狀態(tài)或對象特性的功能。需求指定客戶想要什麼行為，而不是如何實現(xiàn)這些行為。需求描述了現(xiàn)實世界中的現(xiàn)象之間的交互，而不涉及系統(tǒng)的現(xiàn)象。軟體需求分析需求分析的任務建立分析模型(AnalysisModel)。編寫需求規(guī)格說明(SoftwareRequirementSpecification,SRS)。需求分析的步驟需求獲取需求提煉：分析建模需求描述：編寫SRS需求驗證軟體需求分析需求獲取的常用方法常規(guī)的需求獲取方法建立聯(lián)合分析小組客戶訪談問題分析與確認快速原型法在需求分析中的應用採用快速原型法的步驟：利用各種分析技術和方法，生成一個簡化的需求規(guī)格說明。對需求規(guī)格說明進行必要的檢查和修改後，確定原型的軟體結構、用戶介面和數(shù)據(jù)結構等；軟體需求分析在現(xiàn)有的工具和環(huán)境的幫助下快速生成可運行的軟體原型並進行測試、改進；將原型提交給用戶評估並徵求用戶的修改意見；重複上述過程，直到原型得到用戶認可。軟體需求分析應用案例瀑布模型實例：教材購銷系統(tǒng)(面向過程軟體)(1)根據(jù)學校的教學計畫，向選課的學生及時供應所需要的教材審查學生(個人或班級)購書的有效性，對有效的書單發(fā)售教材。對屬於計畫供應但暫時缺貨的教材進行缺書登記。(2)根據(jù)缺書登記補充採購所缺的教材，通知學生補購將缺書登記表匯總為待購教材計畫待購教材到貨後，及時通知學生補購軟體需求分析學生購書單審查有效性學生用書表售書登記表開發(fā)票教材存量表列印發(fā)票列印領書單並登記售書發(fā)票收費蓋章領書單發(fā)書缺書登記匯總並統(tǒng)計缺書缺書單書庫保管員進書產(chǎn)生補售書單教材購書系統(tǒng)流程圖售書購書軟體需求分析結構化分析模型結構化分析模型的組成結構DD是系統(tǒng)所涉及的各種數(shù)據(jù)對象的總和E-R圖描述數(shù)據(jù)對象之間的關係，它代表軟體的數(shù)據(jù)模型。DFD圖指明系統(tǒng)中的數(shù)據(jù)是如何流動和變換的，以及描述使用數(shù)據(jù)流進行變換的功能。在E-R圖中出現(xiàn)的每個數(shù)據(jù)對象的屬性均可用DOSPEC說明來描述在DFD圖中出現(xiàn)的每個功能的描述寫在PSPEC中。CFD圖是為適應即時系統(tǒng)的分析而提出的，描述了進程之間的控制流及系統(tǒng)的行為特徵。CSPEC圖用於指明系統(tǒng)在外部事件的作用下將會如何動作軟體需求分析數(shù)據(jù)流圖(DataFlowDiagram,DFD)數(shù)據(jù)流圖是用來刻畫數(shù)據(jù)流和加工的資訊系統(tǒng)建模技術，它用簡單的圖形符號分別表示數(shù)據(jù)流、加工、數(shù)據(jù)源以及外部實體。數(shù)據(jù)流圖也稱為泡泡圖(BubbleChart)、變換圖(TransformationGraph)或過程模型(ProcessModel)。加工/轉換/處理數(shù)據(jù)流實體(數(shù)據(jù)源點或數(shù)據(jù)終點)數(shù)據(jù)存儲(數(shù)據(jù)檔或資料庫)DFD圖的符號軟體需求分析數(shù)據(jù)流(DataFlow)：數(shù)據(jù)流是帶有箭頭的數(shù)據(jù)流向，表示數(shù)據(jù)元素的運動方向。數(shù)據(jù)流是一組成分固定的數(shù)據(jù)組成的。每一個數(shù)據(jù)流必須有一個合適的名字。為數(shù)據(jù)流命名時，可以從其組成成分或含義角度來考慮。數(shù)據(jù)流可以從加工流向加工，從加工流向數(shù)據(jù)存儲或從數(shù)據(jù)存儲流向加工，也可以數(shù)據(jù)源點流向加工或從加工流向數(shù)據(jù)終點。兩個加工之間可以有幾股數(shù)據(jù)流。檢查取款單合理性取款單合理取款單不合理取款單生產(chǎn)統(tǒng)計生產(chǎn)日報生產(chǎn)月報生產(chǎn)統(tǒng)計報表軟體需求分析加工(Process)：加工表示要執(zhí)行的一個功能，如檢查取款單合理性、生產(chǎn)、統(tǒng)計等，用圓圈表示。加工是對數(shù)據(jù)進行的操作，如果把數(shù)據(jù)流比喻為工廠的傳送帶，則加工就好像工廠裏的加工工序。每個加工都要有一個確定的名稱來命名，名稱的選取要能夠反映加工的主要功能。如果加工命名發(fā)生困難，則加工中可能還包含幾種類型不同的加工，需要進一步進行分解。每個加工一般有一個編號，編號說明該處理在層次分解中的位置。軟體需求分析加工通常以下列方式處理數(shù)據(jù)：只改變數(shù)據(jù)流的狀態(tài)，但不改變數(shù)據(jù)流的結構。例如，加工“檢查取款單的合理性”用來檢查每一個取款單是否合理。如果取款單合理，傳送一個“合理取款單”數(shù)據(jù)流，如果不合理，則傳送一個“不合理取款單”數(shù)據(jù)流，“合理取款單”和“不合理取款單”的組成成分完全一樣，都是取款單，只是狀態(tài)發(fā)生了變化。將一種數(shù)據(jù)流轉換為另一種數(shù)據(jù)流，即數(shù)據(jù)流的結構發(fā)生了變化。例如，輸入數(shù)據(jù)流“生產(chǎn)日報”或“生產(chǎn)月報”經(jīng)過加工“統(tǒng)計”後變成輸出數(shù)據(jù)流“生產(chǎn)統(tǒng)計報表”，顯然，傳入、傳出的數(shù)據(jù)流的組成發(fā)生了變化。軟體需求分析實體(Entity)：也稱為外部項，它既可以作為數(shù)據(jù)流的源，也可以作為數(shù)據(jù)流終點，用方框表示。實體有外部實體和內部實體之分。外部實體定義了系統(tǒng)的邊界，它們向系統(tǒng)提供輸入，接收由系統(tǒng)所產(chǎn)生的輸出，分別稱為源點和終點。軟體需求分析數(shù)據(jù)存儲(DataStore)：表示數(shù)據(jù)的存儲位置，用雙杠表示。數(shù)據(jù)存儲和加工之間的箭頭有指向數(shù)據(jù)存儲、背離數(shù)據(jù)存儲和雙向三種:(1)如果加工要讀數(shù)據(jù)，則數(shù)據(jù)是從數(shù)據(jù)存儲流出；(2)如果加工要寫或修改數(shù)據(jù)，則數(shù)據(jù)流是流向數(shù)據(jù)存儲；(3)如果加工既要讀數(shù)據(jù)，又要寫數(shù)據(jù)，則數(shù)據(jù)流是雙向的。檢查取款單合理性取款單合理取款單不合理取款單賬目審查發(fā)票購書單各班學生用書表教材存量表發(fā)票無效購書單軟體需求分析層次DFD對於一個大型的系統(tǒng)，如果用一張數(shù)據(jù)流圖畫出所有的數(shù)據(jù)流和加工，則圖紙將極其龐大複雜，因而難於理解。為了達到簡單性要求，通常採用層次或自頂向下分解的方法，將系統(tǒng)DFD中的每一個加工視為一個子系統(tǒng)，然後繼續(xù)向下分解，直到每一個加工容易理解為止，這就是結構化分析方法“自頂向下、逐步分解”的基本原則。分層DFD由：頂層、底層和中間層組成。頂層DFD說明系統(tǒng)邊界，即系統(tǒng)的輸入和輸出數(shù)據(jù)流，頂層DFD只有一張。底層DFD由一些不可再分解的加工組成，這些加工稱為基本加工。在頂層和底層之間的是中間層，中間層的DFD描述了某個加工的分解，而它的組成部分又要進一步分解。軟體需求分析教材購銷系統(tǒng)學生書庫保管員購書單領書單缺書單進書通知頂層DFD1銷售學生書庫保管員購書單領書單缺書單進書通知2採購F1教材存量表F2缺書登記進書通知第2層DFD(0)教材購銷系統(tǒng)的層次DFD軟體需求分析1.1審查購書單有效性學生購書單無效購書單領書單發(fā)票F1教材存量表F2缺書登記進書通知第3層DFD-銷售子系統(tǒng)(1)1.2開發(fā)票1.3列印發(fā)票1.4登記售書和列印領書單1.5登記缺書1.6產(chǎn)生補售書單采購有效購書單F3學生用書表F4售書登記表發(fā)票學生暫缺書單補售書單軟體需求分析銷售F1教材存量表F2缺書登記進書通知2.3修改教材庫存和待購量2.2按出版社統(tǒng)計缺書2.1按書號匯總缺書F1待購教材表F6教材一覽表書庫保管員缺書單進書通知第3層DFD-採購子系統(tǒng)(2)軟體需求分析DFD建模由外向裏繪製DFD畫出系統(tǒng)的輸入輸出數(shù)據(jù)流。畫出系統(tǒng)的內部。畫出加工的內部。由頂向下繪製DFD繪製分層DFD時應該注意以下幾個方面問題：編號、父圖與子圖的平衡、局部數(shù)據(jù)存儲、分解程度等。軟體需求分析編號：為了便於管理，需要按照以下規(guī)則為數(shù)據(jù)流圖和其中的加工編號：頂層DFD無圖號，頂層加工不編號；第二層DFD的圖號為0，第二層DFD中的加工編號為1,2,…,n；第三層每個DFD的編號就是父圖中加工的編號，第三層每個DFD中加工的編號由DFD圖號、小數(shù)點和局部號構成，以下各層以此類推。120ABABV圖編號1.11.21.3AVMN1處理編號軟體需求分析父圖與子圖的平衡：父圖中某個加工的輸入輸出數(shù)據(jù)流應該與相應子圖的輸入輸出數(shù)據(jù)流相同，層次DFD的這種特點稱為“平衡”。平衡是指子圖的所有輸入數(shù)據(jù)流必須是父圖中相應加工的輸入數(shù)據(jù)流，子圖的所有輸出數(shù)據(jù)流必須是父圖中相應加工的輸出數(shù)據(jù)流。1234ADCBEFG4.14.24.3ALPHADUEFVW軟體需求分析局部數(shù)據(jù)存儲數(shù)據(jù)存儲被畫出來的原則：數(shù)據(jù)存儲被用作DFD中某個加工之間的介面時，該數(shù)據(jù)存儲就必須劃出來。一旦數(shù)據(jù)存儲作為DFD中的一個獨立成分被畫出來時，它與其它成分之間的聯(lián)繫也應同時畫出來，即應畫出每個加工是讀還是寫該數(shù)據(jù)存儲。例如，在教材購銷系統(tǒng)中，第3層DFD-銷售子系統(tǒng)中的數(shù)據(jù)存儲“F3學生用書表”並沒有出現(xiàn)在父DFD中，這是因為它是該DFD圖的局部數(shù)據(jù)，而不是父DFD中加工之間的介面。而第2層DFD-銷售子系統(tǒng)中的數(shù)據(jù)存儲“F1教材存量表”則出現(xiàn)在父DFD中，這是因為它是父DFD中加工“銷售”和“採購”之間的介面。軟體需求分析分解程度：分解應該自然，概念上合理、清晰；只要不影響DFD的易理解性，可以適當?shù)囟喾纸?，這樣可以減少DFD的層數(shù)；一般來說，在上層分解的快一些，而在下層則分解得慢些，這是因為約接近下層功能越具體，分解速度快會增加用戶理解的困難；每一加工分解的子加工一般不超過7個。軟體需求分析數(shù)據(jù)字典(DataDictionary,DD)數(shù)據(jù)：出現(xiàn)在軟體中的數(shù)據(jù)可以分為3種情況：(1)只含有一個資料項目(或數(shù)據(jù)元素)；(2)由多個相關資料項目組成的數(shù)據(jù)流；(3)數(shù)據(jù)存儲(數(shù)據(jù)檔或資料庫)。數(shù)據(jù)字典：數(shù)據(jù)字典是對軟體系統(tǒng)中的每個數(shù)據(jù)規(guī)定一個條目，以保持數(shù)據(jù)在系統(tǒng)中的一致性。數(shù)據(jù)字典用簡潔、清晰、易理解的文字描述條目，說明數(shù)據(jù)流圖的加工功能、性能、要求及設計約束等。數(shù)據(jù)流圖與數(shù)據(jù)字典配套使用，完整地描述軟體需求。軟體需求分析數(shù)據(jù)流名：發(fā)票別名：購書發(fā)票組成：學號+姓名+{書號+單價+數(shù)量+總價}+書費合計備注：數(shù)據(jù)流例如，發(fā)票是一個數(shù)據(jù)流，其條目內容與書寫格式如下表所示。{}表示重複，重複的次數(shù)不限?！皩W號”、“姓名”、“書費合計”在數(shù)據(jù)流中僅出現(xiàn)一次，其餘資料項目則每買一本書就出現(xiàn)一次。資料項目名稱數(shù)據(jù)流“發(fā)票”字典條目軟體需求分析數(shù)據(jù)檔例如，各班學生用書表是一個數(shù)據(jù)檔，其條目內容與書寫格式如下表所示。文件名：各班學生用書表別名：組成：{系編號+專業(yè)和班編號+年級+{書號}}組織：按系、專業(yè)和班編號從小到大排列備注：數(shù)據(jù)檔“各班學生用書表”字典條目在該條目中，每個記錄記載一個班在一學年中需要的教材。軟體需求分析資料項目：無論是獨立的或者包含在數(shù)據(jù)流或檔中的資料項目，一般都應在字典中設置相應的條目。資料項目名：年級別名：取值及含義：F-freshman,一年級M-sophomore,二年級J-junior，三年級S-senior，四年級備注：資料項目“年級”的條目軟體需求分析資料項目名：數(shù)量別名：購書量取值：正整數(shù)備注：資料項目“年級”的條目資料項目名：書費合計別名：取值：00.00-99.99備注：資料項目“書費合計”的條目軟體需求分析在字典中使用=、+、|、{}、()等符號和注釋符“*……*”將數(shù)據(jù)流或數(shù)據(jù)檔寫成公式形狀的定義。符號含義=表示由…構成A+B表示A和B的順序連接A|B表示A和B的選擇連接{A}n

表示n個A的重複連接{}表示可以重複數(shù)據(jù)()表示可選數(shù)據(jù)軟體需求分析例：發(fā)票=(學號)+姓名+{發(fā)票行}+書費合計發(fā)票行=書號+單價+數(shù)量+總價各班學生用書表={系編號+專業(yè)和班編號+年級+{書號}}系編號={數(shù)字}2

*兩位數(shù)字，例如01,12*專業(yè)和班編號={數(shù)字}3

*三位數(shù)字，例如305*年級=F/M/J/S*在4個字母中任選一個*書號={字母}+{數(shù)字}*例如，Math11,Eng2等*軟體需求分析加工說明(ProcessSPECification,PSPEC)加工說明是對DFD中每個加工所作出的說明。加工說明是由輸入數(shù)據(jù)、加工邏輯和輸出數(shù)據(jù)等部分組成加工邏輯闡明把輸入數(shù)據(jù)轉換為輸出數(shù)據(jù)的策略，是加工說明的主體。加工說明的主要描述方法：結構化語言(StructuredLanguage)判定表(DecisionTable)判定樹(DecisionTree)軟體需求分析結構化語言自然語言加上結構化的形式，就形成了結構化語言。結構化語言是一種介於自然語言與程式設計語言之間的語言，既具有結構化程式清晰易讀的優(yōu)點，由具有自然語言的靈活性，不受程式設計語言的嚴格的語法約束。結構化程式可以使用順序、選擇、迴圈等控制結構。結構化語言借用這些結構來描述加工，其形式簡單，易於用戶理解。軟體需求分析審查並開發(fā)票的加工邏輯軟體需求分析判定表：判定表採用表格化的形式，適合於表達含有複雜判斷的加工邏輯。判定表和結構化語言可以配合使用。判定樹：判定樹是判定表的圖形表示，其適用場合與判定表相同。用戶可以根據(jù)習慣，在兩種中選用一種。例，某公司為推銷人員制定了獎勵辦法，把獎金與推銷金額及預定收款的數(shù)額掛鉤。凡每週推銷金額不超過10000元，按預收貨款是否超過50%，分別獎勵推銷額的6%或4%。反之若推銷金額超過10000元，則按預收貨款是否超過50%，分別寄獎勵推銷額的8%或5%。對於月薪低於1000元的推銷員，分別另發(fā)鼓勵獎300、200和500、300元。判定表：44頁的圖3.12判定樹：44頁的圖3.13軟體需求分析加工說明的作用是說明“做什麼”，而不是“怎麼做”，因此對加工邏輯的描述不宜過細，過細就變成設計，使開發(fā)人員過早地捲入如何實現(xiàn)的細節(jié)，但是，需求說明又是軟體設計的依據(jù)，如果過簡，又會使設計人員無據(jù)可依。軟體需求分析實體關係圖(Entity-RelationshipDiagram,ERD)基本概念：實體(Entity)：表示為矩形，代表具有共同性質和行為的現(xiàn)實世界對象構成的集合。屬性(Attribute)：是實體上的注釋，描述實體相關的數(shù)據(jù)或性質。屬性可以採用屬性表來描述。關係(Relationship)：用菱形表示，實體之間數(shù)量上的對應關係如下圖所示。0:11:10:m1:m軟體需求分析例如，下圖描述了電話機、生產(chǎn)廠商、經(jīng)銷商和用戶以及它們之間的關係。從下圖可以看出，一個生產(chǎn)廠商可以生產(chǎn)多個電話機，其產(chǎn)品可以由許多經(jīng)銷商經(jīng)銷，每個經(jīng)銷商可以將電話賣給許多用戶，每個用戶可以使用零至多部電話機。電話機生產(chǎn)廠商生產(chǎn)經(jīng)銷商用戶使用購買經(jīng)銷軟體需求分析電話機話筒話機按鍵連接線書教科書課外輔導書雜誌ERD表示整體-部分關係ERD表示一般-特殊關係實體-關係圖可以表示實體之間的整體-部分關係和一般-特殊關係軟體需求分析控制流圖(ControlFlowDiagram,CFD)與控制說明(ControlSPECification,CSPEC)即時系統(tǒng)：即時系統(tǒng)與現(xiàn)實世界的外部實體進行交互時具有鮮明的時間特性。其數(shù)據(jù)流應顯式地區(qū)分為時間上連續(xù)的數(shù)據(jù)流和離散的數(shù)據(jù)流(控制信號或事件)。數(shù)據(jù)流圖擴展：CFD是為了適應即時系統(tǒng)的分析而提出來的，通常與DFD配合使用，目的是使分析員在用DFD和PSPEC表示數(shù)據(jù)流和加工的同時，也能夠用CFD和CSPEC表示控制流和控制加工。軟體需求分析CFD與DFD的關係DFDPSPECCFDCSPEC行為模型過程模型輸入數(shù)據(jù)輸出數(shù)據(jù)輸入控制輸出控制數(shù)據(jù)條件加工啟動信號軟體需求分析處理/加工數(shù)據(jù)流實體(數(shù)據(jù)源點或數(shù)據(jù)終點)數(shù)據(jù)存儲(數(shù)據(jù)檔或資料庫)CFD的符號控制流被引用的控制說明CFD的符號：CFD在DFD的基礎上增加了兩個符號控制流和被引用的控制說明。軟體需求分析控制流：採用帶有箭頭的虛線來表示，虛線箭頭表示控制流從一個加工流向另一個加工的方向。虛線箭頭旁邊可以標注控制資訊或事件，控制資訊通常取布爾值或離散值。被引用的控制說明：採用短豎線表示。控制說明主要用於描述：當事件或控制資訊被感知時軟體如何行動；作為事件發(fā)生的結果，哪些加工將被啟動。軟體需求分析對於即時系統(tǒng)，在創(chuàng)建了DFD(過程模型)之後還必須創(chuàng)建CFD(行為模型)，以便描述相關的事件以及系統(tǒng)狀態(tài)在時間坐標系中的變遷。例如，首先畫出光電管採集DFD。光電管採集計數(shù)傳送工控機處理班數(shù)據(jù)處理即時數(shù)據(jù)顯示半小時數(shù)據(jù)班數(shù)據(jù)信號半分鐘數(shù)據(jù)光電管採集DFD軟體需求分析光電管採集計數(shù)傳送工控機處理班數(shù)據(jù)處理即時數(shù)據(jù)顯示半小時數(shù)據(jù)班數(shù)據(jù)信號半分鐘數(shù)據(jù)物品經(jīng)過某型號累加無動作半分鐘半小時翻屏人工驅動資訊在光電管採集DFD的基礎上加上事件和控制資訊，並加上控制說明的引用，即可得到光電管採集系統(tǒng)的CFD。光電管採集CFD時鐘軟體需求分析狀態(tài)轉換圖(StateTransformationDiagram,STD)狀態(tài)圖描述了軟體系統(tǒng)狀態(tài)的變遷，它是CSPEC中常用的一種重要描述工具。STD中的符號矩形：表示系統(tǒng)的狀態(tài)；箭頭：表示狀態(tài)的轉變方向；規(guī)則運算式：用來標明系統(tǒng)狀態(tài)發(fā)生轉變的事件和該事件的觸發(fā)行為。狀態(tài)1狀態(tài)2事件/觸發(fā)行為軟體需求分析20秒到/翻屏生成最新數(shù)據(jù)/翻屏半小時到/工控處理半分鐘到/傳送空閒/採集物品經(jīng)過/計數(shù)採集PLC計數(shù)傳送工控處理即時翻屏光電採集的STD軟體需求分析結構化分析方法：結構化分析就是使用DFD、CFD、DD、結構化語言、判定表、判定樹、PSPEC、CSPEC和STD等建模語言，來建立結構化規(guī)格說明的目標文檔。畫出分層數(shù)據(jù)流圖確定數(shù)據(jù)定義與加工策略從最低DFD的數(shù)據(jù)終點開始，沿著DFD一步步向數(shù)據(jù)源點回朔，來分析每一個資料項目的來龍去脈。需求分析復審父圖與子圖不平衡未區(qū)分局部檔和局部外部檔分解速度太快不遵守加工編號規(guī)則軟體需求分析面向對象分析模型描述了系統(tǒng)所涉及的全部類-對象。每一個類-對象都通過屬性、操作和協(xié)作者來進行描述。描述了對象之間的靜態(tài)關係，同時定義了系統(tǒng)中所有重要的消息路徑，它也可以具體化到對象的屬性、操作和協(xié)作者。描述了系統(tǒng)的動態(tài)行為，即對象在特定狀態(tài)下如何反應外界的事件。用例模型描述了軟體系統(tǒng)和外部參與者之間的交互。從用例模型出發(fā)，可以定義：類-對象模型、對象關係模型和對象行為模型軟體需求分析統(tǒng)一建模語言(UML)軟體需求分析為什麼稱為統(tǒng)一開發(fā)生命週期：UML提供用於從需求分析工程到實現(xiàn)，貫穿整個軟體開發(fā)生命週期的可視化建模語法。應用領域：UML已經(jīng)內應用於從關鍵即時嵌入式系統(tǒng)到管理決策支持系統(tǒng)中任何事物的建模。實現(xiàn)語言和平臺：UML獨立於語言和平臺。它不僅對純粹OO語言(例如Java,C#)據(jù)具有極好的支持，而且對於混合OO語言，如C++，甚至非OO語言也同樣有效。開發(fā)過程：儘管UP及其變體可能是OO系統(tǒng)的首選開發(fā)過程，UML能夠支持很多其他軟體工程過程。它本身內部概念：UML在其內部概念的一個小集合的應用上，勇於嘗試保持一致和統(tǒng)一。軟體需求分析UML的結構軟體需求分析UML的結構-架構圖：類圖複合結構圖對象圖包圖狀態(tài)圖圖：組件圖圖：類圖複合結構圖對象圖圖：部署圖邏輯視圖進程視圖實現(xiàn)視圖部署視圖圖：用例圖交互圖用例視圖關注：專案辭彙表功能關注：性能伸縮性吞吐量關注：系統(tǒng)裝配配置管理關注：系統(tǒng)拓撲分發(fā)移交安裝軟體需求分析用例圖軟體需求分析用例圖：是由主題(Subject)、用例(Usecase)、參與者(Actor)和關聯(lián)(執(zhí)行者與用例、用例與用例、執(zhí)行者與執(zhí)行者)組成。用例:是參與者想要系統(tǒng)做的事情。參與者(角色):說明當與系統(tǒng)直接交互時，一些外部實體採用的角色。主題(系統(tǒng)邊界)：定義由誰或什麼(即，參與者)使用系統(tǒng)，系統(tǒng)能夠為哪些參與者提供什麼特定利益(即，用例)。軟體需求分析用例規(guī)格說明：用例名稱：採用動詞或者動詞短語描述，通過用例的名稱，業(yè)務讀者能夠清晰地知曉用例建模的業(yè)務功能或過程。用例ID:它唯一地標識專案中特定的用例。簡要描述：捕獲用例的目的。參與者：第一參與者-實際觸發(fā)用例的那些參與者；第二參與者-在用例被觸發(fā)之後，與用例進行交互的參與者。前置條件和後置條件：前置條件說明在用例觸發(fā)之前什麼必須為真，後置條件說明在用例執(zhí)行之後什麼必須為真。主流：用例中陳述性的、具有時序的步驟序列。附流：主流的一串分支。通常表示異常、分支和中斷的路徑。軟體需求分析用例名稱用例ID簡要描述參與用例的參與者前置條件主流後置條件附流軟體需求分析參與者之間、用例之間的關係參與者泛化：一般參與者和特殊參與者之間的泛化關係。用例泛化：一般用例和特殊用例之間的泛化關係。包含關係：用例之間的關係，它允許一個用例包含另一個用例的行為。擴展關係：用例之間的關係，它允許一個用例使用另一個用例中的一個或多個片段來擴展它的行為。軟體需求分析參與者泛化：一般參與者和特殊參與者之間的泛化關係。使用參與者泛化可以簡化問題。一般參與者參與者泛化特殊者泛化軟體需求分析用例特性繼承添加覆寫關係YYN擴展點YYN前置條件YYY後置條件YYY主流中的步驟YYY附流YYY用例泛化：一般用例和特殊用例之間的泛化關係。在用例泛化中，子用例是父用例的特殊形式，子用例可以：從父用例那裏繼承特徵；添加新的特徵；覆寫(改變)已繼承的特徵。軟體需求分析繼承不改變3.(3.)繼承和重複編號6.2(6.1)繼承且覆寫1(o1)繼承、覆寫及重編號5.2(o5.1)添加6.3一般用例特殊用例用例泛化例：用例泛化軟體需求分析繼承不改變3.(3.)繼承和重複編號6.2(6.1)繼承且覆寫1(o1)繼承、覆寫及重編號5.2(o5.1)添加6.3軟體需求分析基礎用例內含用例包含關係包含關係：用例之間的關係，它允許一個用例包含另一個用例的行為。我們將包含用例稱為基用例，把被包含用例稱為內含用例，內含用例給它的基礎用例提供行為?；A用例執(zhí)行到包含點，那麼執(zhí)行傳遞給內含用例，當內含用例完成時，控制再次返回基礎用例。用例包含實例軟體需求分析軟體需求分析基礎用例包含用例軟體需求分析擴展用例基礎用例擴展關係擴展關係：用例之間的關係，它允許一個用例使用另一個用例中的一個或多個片段來擴展它的行為。基礎用例提供了一組擴展點，擴展點是鉤子，在此可以添加新的行為，擴展用例提供了一組插入片段，這些片段被插入到基礎用例鉤子位置。軟體需求分析擴展類基礎用例擴展用例擴展類名稱單一片段插入軟體需求分析單一片段插入基礎用例擴展用例軟體需求分析多重片段插入擴展類擴展類基礎用例擴展用例擴展類名稱軟體需求分析多重片段插入基礎用例擴展用例軟體需求分析條件擴展軟體需求分析對象圖軟體需求分析對象：是數(shù)據(jù)和函數(shù)的內聚單元。每個對象都是某個類的一個實例，該類定義了由該類所有對象所共有的特徵。對象特徵：標識：這是在時間和空間上對象唯一存在。它把該對象同所有其他對象區(qū)分開。狀態(tài)：特定時刻對象所有有意義的屬性值集合。行為：對象為其他對象提供的服務。在分析建模中為一組操作，調用操作可能引發(fā)狀態(tài)遷移。軟體需求分析123456Jim300.00Deposit()withdraw()getOwner()setOwner()屬性值操作對象中的數(shù)據(jù)被隱藏，僅能通過調用對象的函數(shù)才能操縱數(shù)據(jù)。封裝軟體需求分析Bank對象Account對象Bank對象發(fā)送資訊“withdraw150.00”給Account對象Account對象回應，調用它的取款操作。該操作減少帳戶餘額150.00withdraw(150.00)對象交互產(chǎn)生系統(tǒng)的行為交互涉及對象之間來回發(fā)送消息。當接收到消息時，則調用相應的方法，這可能引起狀態(tài)的改變。消息機制軟體需求分析JimsAccount:AccountaccoutNumber:String=“123456”owner:String=“Jim”balance:double=300.00對象名稱類名稱屬性名稱屬性類型屬性值名稱分欄屬性分欄UML對象符號軟體需求分析鏈接：當一個對象承載到另一個對象的對象引用時，產(chǎn)生鏈接。鏈接是兩個對象之間的語義聯(lián)繫，它允許消息從一個對象發(fā)送到另一個對象。不同的OO語言以不同的方法實現(xiàn)鏈接，Java把鏈接實現(xiàn)為對象引用，C++把鏈接實現(xiàn)為指針或引用，或者通過在對象中直接包含另一個對象來實現(xiàn)鏈接。bookClub:Club張三:Person李四:Person王二:Personchairpersonsecretarymember角色名稱雙向鏈接UML鏈接符號軟體需求分析類圖軟體需求分析類：共用相同屬性、操作、方法、關係或者行為的一組對象的描述符。類和對象關係：每個對象恰是一個類的實例。相同類的不同對象具有相同的屬性，但是可以具有這些屬性的不同值。不同屬性值引起相同類的不同對象的不同行為。使用構造型<<instantiate>>依賴，你能在類和它的對象之一之間表示實例化關係。對象的實例化是使用它的類作為範本創(chuàng)建新對象。大多數(shù)OO語言提供被稱作構造函數(shù)的特殊操作，當需要創(chuàng)建對象時，調用它，構造函數(shù)創(chuàng)建或初始化對象，構造函數(shù)是類範圍的。一些OO語言提供被稱作析構函數(shù)的特殊操作，當需要銷毀對象時，調用它，析構函數(shù)在對象後起清理作用。軟體需求分析<<entity>>Account-number:String-owner:String-balance:double=0.0+create(theNumber:String,theOwner:String)+deposit(amount:double)+withdraw(amount:double)+getNumber():String+getOwner():String+getBalance():double+setOwner(theOwner:String){author=Jim,Status=tested}名稱分欄屬性分欄操作分欄可見性修飾構造型類名稱標記值初始值類範圍操作(加下劃線)UML類符號軟體需求分析類的命名規(guī)則以大寫字母打頭，混合大小寫，其中每個單詞以大寫開頭。避免縮寫。儘量用完整單詞來描述。如果存在特定領域的縮略詞(例如，ERP-EnterpriseResourcePlanning)，被廣泛使用並且能夠被模型的所有讀者所理解，那麼你可以使用它。軟體需求分析屬性分欄命名規(guī)則：採用以小寫字母開頭，然後混合大小寫。屬性名通常是名詞或者名詞短語。語法規(guī)則visibilityname:type[multiplicity]=initialValue可見性名稱類型多重性初始值軟體需求分析可視性：可視性修飾作用於類內屬性和操作。它也可以作用於關係上的角色名稱。修飾可視性名稱語義+public能夠訪問該類的任何元素可以訪問該類帶有的公共可視性的任何特徵-private只有該類的操作才能訪問該類待有的私有可視性的特徵#protected只有該類及其子類的操作才能訪問該類帶有的保護可視性的特徵~package與該類處於相同包中的或者是在嵌套子包中的任何元素能夠訪問該類帶有的包可視性的任何特徵軟體需求分析類型：屬性的類型可以是其他的類型或者原始類型。原始類型語義UMLInteger整數(shù)UnlimitedNatural大於等於零的整數(shù)Boolean可以取值true或者falseString字元的序列，字串被雙引號括起來OCLReal浮點數(shù)軟體需求分析多重性：多重性允許你在一個屬性上通過使用多重性運算式建模兩種顯著不同的事物：集合：空值：初始值：當某個類實例化對象時，初始值允許你說明屬性此時採用的值。構造型和標記值：

<<stereotype>>attribute{tag1=value1,tag2=value2,…}address{addedBy=“Jim”,dataAdded=“20MAR2004”}軟體需求分析操作分欄操作：操作是綁定到特定類的函數(shù)。操作名稱通常是動詞或者動詞短語。操作具有特徵：名稱、參數(shù)列表和返回類型。操作名稱、所有參數(shù)的類型以及返回類型構成了操作簽名。類的每個操作必須具有唯一簽名，因為這是賦予操作標識的簽名。當消息發(fā)送到對象，消息簽名與定義在對象的類中的操作簽名相比較，如果找到匹配，在該對象上調用恰當?shù)牟僮鳌２僮鞯恼Z法規(guī)則：visibilityname(directionparameterName:parameterType=defaultValue,…):returnType操作簽名參數(shù)列表軟體需求分析參數(shù)方向語義inp1:Integer默認情況，該操作使用p1作為輸入?yún)?shù)該操作以某種方式使用p1的值p1不能被該操作所修改inoutp2:Integer該操作接受p2作為輸入?yún)?shù)/輸出參數(shù)該操作以某種方式使用p2的值，並且接受該操作的輸出p2可以被該操作所修改outp3:Integer該操作使用p3作為輸出參數(shù)該參數(shù)作為接收器接受該操作輸出的值P3可以被該操作所修改returnp4:Integer該操作使用p4作為返回值參數(shù)該操作返回p4作為返回值之一軟體需求分析關係：是建模元素之間的語義聯(lián)繫。關係類型實例化：類與對象之間的關係。關聯(lián)：關聯(lián)是類間的語義聯(lián)繫。依賴：依賴表示兩個或者多個元素之間的關係，對一個元素(提供者)的改變可能影響或提供資訊給其他元素(客戶)。繼承：發(fā)生在存泛化關係的類之間。軟體需求分析實例化JimAccount:AccountaccoutNumber:String=“123456”owner:String=“Jim”balance:double=300.00TomAccount:AccountaccoutNumber:String=“123457”owner:String=“Tom”balance:double=1000.00AccountaccoutNumber:Stringowner:Stringbalance:doubledeposit()withdraw()getOwner()setOwner()<<instantiate>><<instantiate>>軟體需求分析關聯(lián)：關聯(lián)是類間的語義聯(lián)繫。如果兩個對象之間存在鏈接，這些對象的類間必定存在關聯(lián)，這是因為鏈接是關聯(lián)的實例。CompanyPersonemploys1*關聯(lián)名稱導航性多重性CompanyPersonemployer1*角色名稱多重性employee導航性軟體需求分析關聯(lián)語法關聯(lián)名稱：可以首碼或尾碼一個小黑箭頭表明名稱應該閱讀的方向。應該是動詞或動詞短語。採用lowerCamelCase格式(第一個詞的首字母小寫,後面每個詞的首字母大寫)?？梢允褂藐P聯(lián)名稱或者角色名稱，但不要同時使用兩者。類有到其自身的關聯(lián)，稱為自反關聯(lián)，它表示該類的對象可以具有到該類的其他對象的鏈接。角色名稱：可以在關聯(lián)的一端或兩端上為類賦予角色名稱。應該是名詞或名詞語法描述角色的語義。採用lowerCamelCase格式。多重性多重性表明在任意時刻關係所能夠涉及的對象數(shù)目。對象可以任意去留，但多重性約束任意時刻對象的數(shù)目。多重性在內部說明以逗號隔開，例如，0..1，3..5。沒有默認的多重性，如果多重性沒有顯式地表示出來，那麼多重性沒有確定。軟體需求分析CompanyPersonemployee17BankAccountemployer11..*owneroperator0..*0..*多重性語義一個Company恰有7個employee;一個Person恰能被一個Company所雇用；一個BankAccount恰有一個owner;一個BankAccount具有一個或多個operator；一個Person可以有零個到多個BankAccount;一個Person可以操作零個到多個BankAccount。軟體需求分析DirectoryFileparent1subdirectory0..*0..10..*自反關聯(lián)每個Directory對象能夠具有到零個或多個扮演subdirectory角色的Directory對象的鏈接，並且具有到零個或一個扮演parent角色的Directory對象的鏈接。每個Directory對象關聯(lián)零個或多個File對象。C:DirectoryWindows:DirectoryMyDocuments:DirectoryCommand:Directoryautoexec:Fileconfig:FileToJohn:File自反關聯(lián)軟體需求分析導航性：在關係箭頭的端部顯示，如果關係沒有箭頭，那麼它是雙向的。導航性表明消息僅能夠在箭頭的方向上傳遞。OrderProduct**可導航的不可導航的對象Order能夠向對象Product發(fā)送消息，但消息不能反向發(fā)送。CompanyPerson1*可導航的可導航的對象Company能夠向對象Person發(fā)送消息，對象Person也能夠向Company發(fā)送消息。軟體需求分析關聯(lián)類：關聯(lián)類既是關聯(lián)又是類，它可以具有屬性、操作和關係。當兩個類間具有多對多關係時，有時存在一些屬性，它們不能簡單地放入任何一個類中。例如，如果添加業(yè)務規(guī)則：每個Person與雇用它的Company間存在薪水屬性，這將發(fā)生什麼？薪水記錄、在何處？Person類還是Company類？答案是薪水是關聯(lián)本身的特性，對於Person對象和Company對象之間的每個雇傭關聯(lián)，都存在特定薪水。CompanyPerson**CompanyPerson**salary:doubleJob關聯(lián)類

關聯(lián)類由類、關聯(lián)和虛線組成軟體需求分析C1:CompanyP1:PersonP2:PersonC2:CompanyP3:PersonJ11:JobJ12:JobJ13:JobJ21:JobJ25:Job對於給定的Person對象和給定的Company對象，才有一個Job對象。換言之，每個Person與給定的Company對象之間只有一個Job對象。軟體需求分析如果對於給定Person對象和給定的Company對象之間具有多於一個Job，那麼你不能使用關聯(lián)類，語義不匹配！解決方案：採用正常類。CompanyPerson1*salary:doubleJob*1P1:PersonJ11:JobJ12:JobJ13:JobC1:CompanyC2:Company軟體需求分析聚合：鬆散的對象間關係。例如，電腦和它的週邊設備之間的關係。組合：非常強的對象間關係。例如，樹和它的樹葉之間的關係。一些對象弱相關，像電腦和它的外設一些對象強相關，像樹和樹葉聚合組合軟體需求分析ComputerPrinter0..10..*整體或聚集部分聚合聚合語義：聚集有時能夠不依賴部分而獨立存在，有時又不能；部分可以獨立於聚集而獨立存在；如果有一些部分遺失，聚集在某種意義上是不完整的；部分的所有權可能由幾個聚集來共用。聚合是一種整體-部分關係，其中聚集由許多部分組成。軟體需求分析聚合是可傳遞的AB如果C是B的部分，B是A的部分，那麼C是A的部分C聚合是非對稱的Product自反對稱**A:ProductB:ProductC:ProductD:Product不允許迴圈軟體需求分析Product自反對稱**A:ProductB:ProductC:ProductD:Product軟體需求分析組合是一種更強形式的聚合，也具有類似的語義，但是更加受約束。組合具有傳遞性和非對稱性。組合也與聚合的關鍵區(qū)別在於：在組合中，部分脫離了整體就不能獨立存在，此外，組合中的每個部分至多屬於一個整體，也只能屬於一個整體；在聚合中，一個部分可以由幾個整體共用。Treeleaf10..*組成部分組合軟體需求分析依賴：依賴表示兩個或多個建模元素之間的關係，對於一個元素(提供者)的改變可能影響或提供資訊給其他元素(客戶)。類型語義Usage(使用)客戶使用由提供者所提供的服務以實現(xiàn)它的行為。Abstraction(抽象)這表示客戶和提供者之間的關係，提供者必客戶更加抽象?！案映橄蟆币馕吨峁┱吆涂蛻籼庫堕_發(fā)中的不同階段，例如，提供者處於分析模型，客戶處於設計模型。Permission(授權)提供者為客戶提供某種許可權以訪問提供者的內容，這是一種提供者控制和限制對其內容訪問的方法。軟體需求分析使用依賴：存在五種類型的依賴：<<use>>、<<call>>、<<parameter>>、<<send>>和<<instantiate>>。<<use>>：下列任何一種情況產(chǎn)生<<use>>依賴：類A的操作需要類B的參數(shù)；類A的操作返回類B的值；類A的操作在實現(xiàn)中使用類B的對象，但是不是作為屬性來使用。Afoo(b:B)bar():BdoSomthing()B<<use>>提供者客戶軟體需求分析<<ca