1、第九章 軟體工程,9-1 寫程式 9-2 軟體開發生命週期 9-3 軟體品質保證 9-4 UML,9-1 寫程式,程式碼簡短並不一定好，適可而止即可 K.I.S.S Keep It Simple and Stupid 程式碼不是只用一遍 維持程式碼簡單又乾淨，有好的Readability 可讀性 (Readability): 命名(naming) : 以清楚、有意義、統一為原則ex: int a,b; 語意不清int dividend, divisor; 語意較清 排版 : 該換行就換行，讓版面整齊不擁擠,可讀性程式碼範例,可讀性程式碼範例 (cont),可靠性程式碼範例,可靠性是指程式牢靠穩
2、定, 禁得起使用者的操作,程式碼與註解,程式碼與註解: 程式碼是給機器讀的，註解則是給程式人員看的 程式碼透過compiler，assembler等等處理而轉化成機器可讀的machine code C語言中註解的種類:/*這是註解*/ or /這是註解,程式碼與註解 (cont),註解的用意: 此段程式碼的功能，變數的意義，使用何種演算法，撰寫或是改版的日期etc,程式碼與註解範例,9-2 軟體開發生命週期,週期5大階段: 需求分析、設計、編碼、測試、維護 軟體開發兩大分類: 瀑布式模型(waterfall)、螺旋式模型(spiral),瀑布式模型: 5大階段是採取線性進行的 優點: 適合開發
3、商業用軟體 一個版本一個週期 缺點: 發覺錯誤的時間點太晚，風險太大,螺旋式模型開發,螺旋式模型: 每一個螺旋都代表了一點點的需求、設計、實做、測試，沒問題才繼續做下一圈的螺旋 優點： 在發展初期找到可能問題，避免日後重大錯誤的發生 缺點 : 發展時間過長 不適合商用軟體的開發,軟體開發的過程及角色分工,軟體開發流程,需求分析: 理解市場的需求或是客戶的需求 設計: 使用者介面設計、系統架構文件設定、測試文件設定 編碼: 由上而下 (Top- Down Approach) 由下而上 (Bottom-Up Approach) 測試: 黑箱測試: 不知程式之邏輯設計直接測試 白箱測試: 針對程式之
4、邏輯設計測試是否運作正常 維護,9-3 軟體品質認證,軟體的定義: 軟體是計算機程式、程序、規則, 以及任何相關的文件以及在執行上所必須要用到的資料 80年代美國聯邦政府提出對軟體承包商的軟體發展能力進行評估的要求 卡內基美濃大學軟體工程研究所於2000年發表CMMI (Capability Maturity Model Integration),CMMI,CMMI五個層級,第一級: 初級 (Initial) 軟體發展的過程是散亂的，有的時候甚至會陷入混亂(chaotic)的情況。 發展過程中只有少數的程序(process)是被定義好而執行的。 整個開發的成敗關鍵取決於少數精英的奮鬥及其突出的
5、表現，並非仰賴團隊合作而成。 所有的開發經驗對於之後的開發並沒有留下可利用的價值。,CMMI五個層級 (cont),第二級: 可重複的 (Repeatable) 已經擁有最基本的需求管理，撰寫出專案企劃書，能夠監控專案的發展，並且能夠針對成本、時間、功能進行量化的測量及分析。 針對發展的過程及出產的成品，能夠給予品質保證(Quality Assurance, QA)。能夠監控發展過程的需求。 所有的程序都能夠是先計劃，再執行，能夠量化測量執行情況，並且一切能在掌控之下。 在計劃中的進度檢視日期到來時，能夠看到工作的進度。 擁有簽章同意文件，相關主管在審視合格之後必須加以簽章負責。 產品能夠符合
6、開發之初所訂下的規格標準及目標。 基本的開發原則能夠在日後遇到相似的專案時再度拿出來使用。,CMMI五個層級 (cont),第三級: 已定義的 (Defined) 軟體發展中所有的程序，包含開發及管理等都已建檔文件化、標準化。 所有的程序都有其特殊意義並且確實被眾人了解。 能以團隊的方式進行開發並且能夠進行開發風險管理。 組織內有訓練，並且能夠針對做出的決定進行分析及評估。 組織能夠發展出自己的一套標準程序並且隨著時間的演進而修改。 所有項目的開發和維護都在得遵循標準程序而進行。 組織的標準程序能夠跨部門的一致執行。 所有的專案都必須經由簽章核准之後才能夠進行,CMMI五個層級 (cont),
7、第四級: 量化管理 (Quantitatively Managed) 能夠量化管理專案的進行。 能夠理解開發程序的好壞，量化測量產品的品質。,CMMI五個層級 (cont),第五級: 最佳化 (Optimized) 建立回饋機制，透過將過往開發經驗定量後，檢討並能衍生出創新的方法進行專案開發。 能夠明確指出開發過程的缺陷問題發生在哪。 定期檢討開發過程並且根據成果檢討修改商業計劃。,9-4 UML,結構化設計 代表：瀑布式模型 特性：線性的進行流程 缺點：無法替軟體維護所需要的龐大花費帶來有效的解決方案 軟體生命週期中各階段花費的相對比例如下圖：,物件導向模式,物件 特性：把相關資料的處理程序
8、都定義在物件上 便於維護的理由 我們可以輕易的找出要修改的地方 修改的地方會被侷限在局部的程式 碼中 UML（Unified Modeling Language） 提供物件導向模式設計的工具 基於OMT（Object Modeling Technique）和Boochs technique等所發展出來 受到眾多軟體的支援和具有廣大的應用,物件,物件特性： 屬性：定義物件的資料部分 方法：定義物件的行為部分 封裝：將行為和資料一起直接定義在物件上。 類別：物件的集合 類別階層 上類別（super class）：比較大的集合，譬如：學生 下類別（sub class）：部分集合，譬如：資工系學生 繼
9、承 :下類別直接具有上類別的所有屬性和方法,物件導向分析設計步驟,定義使用情況 從使用情況找出可能的類別 建立類別間的基本關係 定義類別階層 找出每個類別的屬性 列出和屬性有關的方法 指出類別或物件如何相關 建立行為模式 注意 ：步驟會遞迴重複,UML的圖形化的工具,類別圖（class diagram）：描述系統中有哪些類別，及類別內的資料和方法 使用情況圖（use case diagram）：顯示使用者和系統之間的互動，特別是使用者執行系統時會進行的過程 活動圖（activity diagram）：描述系統內各個元件間工作執行的流程 實做圖（implementation diagram）：顯示系統架構內所設計的軟體元件和硬體元件，以及元件之間的互動,使用情況圖範例,類別圖範例,活動圖範例,
