簡介

軟體工程內容:

SA -> SD -> coding -> test -> maintenance

process

  1. Quality Assurance
  2. Configuration Management
  3. Project Management
  4. CMMI

software system

  1. Business application
  2. web application
  3. real-time
  4. safety-critical : 常用的formal工具為 Petri Nets

 

軟體架構

隨著Internet的興起,分散式系統的環境日趨成熟,要將整個Internet視為區域網路般的存取資源與交換資料,程式設計上就必須考慮到所謂的3層式架構

展示層(Presentation Tier)
將UI的部分獨立出來,除了可讓專業的美工處理之外,還要考慮到程式邏輯的變動不會影響到畫面,或是畫面的變動不會影響到程式邏輯
商業邏輯層(Business Logic Tier)
將企業運作的邏輯獨立成元件,以方便更新程式碼時只需要異動相關的元件即可
資料層(Data Tier)
將關於資料存取的部分獨立出來,如此一來在變動資料庫架構時便不需要更改程式邏輯或畫面

單機架構(1-Tier)

展示層,商業邏輯層,資料層都在單機上處理,適用於文字處理,個人資料處理(PIM)等單機架構,其瓶頸為

主從架構(Client/Server , 2-Tier)

將資料層分離出來,儲存到資料庫伺服器,適用於多人存取資料的環境,其瓶頸為

分散式架構(N-Tier)

將展示層,商業邏輯層(放在AP Server),資料層(放在Database Server)都各自獨立,適用於平台不同,網際網路的環境。若展示層以一般開發工具開發稱為Rich Client,若利用動態網頁技術運作於瀏覽器上則稱之為Thin Client。其瓶頸為

網路服務(Web Service)

將整個網際網路視為區域網路甚或是作業系統般,徹底實踐分散式系統的美麗新天地,使用網際網路上的資源就如同取用單機資源一般容易,主要是利用XML作為資料轉換的標準,透過SOAP通訊協定穿過防火牆,打破網際網路的隔閡目前有Sun 的Java One架構與Microsoft的.NET架構可供參考。

 

系統分析與設計(System Analysis and Design)

資訊系統的種類

資訊系統的建置策略

  1. 公司內部獨力完成
  2. 公司外部取得
  3. 其他方式

系統開發模式(Software Process)

需求擷取與分析

使用者需求的分類

需求的擷取方式

設計準則

良好的設計希望達到模組的內聚力為功能內聚力,耦合力為資料耦合力

內聚力(Cohesion):衡量模組完成一件工作的程度

耦合力(Coupling):衡量模組間相互關連的程度

物件導向技術(Object-Oriented Technique)

OOP的先驅 Brad Cox 曾提出Software-IC的概念,而要達到軟體IC的概念,則需要下列特性

抽象化(Abstraction)

物件(Object)=案例(Instance)

類別(Class)=物件類型(Object Type)=抽象化資料型態(Abstract Data Type; ADT)

封裝(Encapsulation)

繼承(Inheritance)

Polymorphism 多型, 動態繫結(Dynamic binding)

物件導向的系統開發方法

物件導向的系統開發是一個反覆(Iterative)的過程,包括了三個階段

  1. 需求分析 ->
    (需求模式) 主要以使用個案圖、活動圖、藍圖、資料詞彙、介面元件等作為表達工具。
  2. 系統分析與設計 ->
    (分析模式) 將需求模式中的系統表達成一個物件架構,包括了物件圖與類別圖
    (設計模式) 將物件架構至現況之實施環境,包括了循序圖、合作圖、狀態圖、活動圖。
  3. 實施與測試 ->
    (實施模式)元件圖、部署圖。(測試模式)

物件導向的塑模

軟體開發如同建築設計,過程中須將需求、分析、設計、實作、佈署等各項工作流程之不同觀點予以呈現,即軟體系統之塑模(Modeling)。

Booch等人 / Rational Software 提出可從4+1觀點(4+1 view)來看軟體系統架構(凸顯使用個案的重要性)

根據上述5個觀點我們可以整理出6種塑模

物件導向的軟體維護

開閉原則(Open-Closed Principle ; OCP)

Liskov代換原則(Liskov Substitution Principle ; LSP)

依賴倒轉原則(Dependency Inversion Principle ; DIP)

介面隔離原則(Interface Segregation Principle ; ISP)

統一模塑語言(Unified Modeling Language, UML)

使用個案圖(Use Case Diagram)

行為者(Actor) = 參與者

使用個案(Use Case)

情節、劇本(Scenario)

使用個案中的某一個單一執行路徑,可能是基本路徑也可能是替代路徑。

建構使用個案圖的步驟

  1. 找出行為者:從環境圖找
  2. 找出使用個案:由行為者找出使用個案
  3. 描述使用個案:可用自然語言或事件條列式
  4. 找出使用個案間的關係:
  5. 繪製使用個案圖

類別圖(Class Diagram)

關係

類別間的關係包括

基數(Multiplicity) =物件的數量關係

在類別連線上與類別之旁以數字標示與之關聯的數量。

物件圖(Object Diagram)

循序圖(Sequence Diagram)

訊息(Message) =刺激(Stimuli)

由某一物件傳送訊息至另一物件以啟動操作,以上下位置表示順序。

生命線(Lifeline)

表達物件再某時段的存在,以物件下與物件垂直之虛線表示。

控制焦點 (Focus of Control) =啟動條(Activation Bar)

表達物件執行某動作之時段,與生命線重疊且以高瘦的矩形表示。

系統邊界 (System Border)

系統與外界溝通之介面,通常放置在循序圖的最左側。

建構循序圖的步驟

  1. 確認物件
  2. 描述操作
  3. 描述訊息
  4. 繪製循序圖

合作圖(Collaboration Diagram)

連結(Link)

以直線連接二個物件也就是物件間的路徑(Path)。

訊息(Message)

訊息發生順序以自然數或杜威數等編號來表達。

活動圖(Activity Diagram)

狀態圖(State Diagram)

元件圖(Component Diagram)

部署圖(Deployment Diagram)

設計樣式(Design Patterns)

軟體能力成熟度模型(Capability Maturity Model Integrated, CMMI)

美國國防部對於軟體的策略是希望外包(outsourcing)的,但為了掌握軟體 產品的品質與進度,希望開發過程能夠透明化,因此於1980 年時,提出對軟體承包商的軟體開發能力進行評估的要求。於是美國國防部與卡內基美隆大學(Carnegie-Melon University ; CMU)共同設立了軟體工程研究所(Software Engineering Institute; SEI)。SEI於1988年研究發佈了軟體開發程序成熟度框架(CMM),提供了軟體開發程序評估和軟體能力評價兩種評估方法和軟體成熟度提問單,來自產官學的技術和管理專家陸續進駐該機構,開始對工、商、政府提供產品和服務。 1991年,SEI將軟體開發程序成熟度框架 提升為軟體能力成熟度模型(Capability Maturity Model For Software,簡稱SW-CMM),並發佈了最早的SW-CMM 1.0版。2000年底SEI發表了CMMI,整合軟體工程(Software Engineeing ; SW)、系統工程(Systems Engineering ; SE)、產品與流程發展(Integrated Product and Procss development , IPPD)與供應商來源管理 (Supplier Sourcing ; SS)的整合模式。從此以後,CMMI就與CMM並行。

CMMI的成熟等級

SEI 試圖在軟體界建立一套工程般的制度,讓個人和組織在軟體開發上能有改進的依據。SEI 的 Capability Maturity Model (CMM) for Software 已經成為許多軟體公司所採行的標準,用作為改進公司內部軟體工程的依據。根據 CMM 的定義,軟體工程的成熟度分成五個等級,簡單介紹如下:

  1. Level 1(initial):軟體程序漫無章法,程序未被定義。專案流程無統一程序,專案計劃的成功仰賴於工作人員個別的努力。
  2. Level 2(repeatable):已建立基本的管理與分析的程序(Measurement and Analysis ; MA),對成本、時程、和職務權責能加以追蹤、查詢。已有作業程序所須具有的紀律,所以有能力重覆使用相類似的專案成功的案例與經驗。
    1. 流程重點:需求管理(Requirements Management)
  3. Level 3(defined):屬於管理和工程的活動都已設計、定義好,並且文件化,完整地整合成組織內的標準作業程序。各個專案計劃延用標準程序或被認可的標準程序修改程序。
    1. 流程重點:需求發展(Requirements Development;REQD),驗證(Verification;VER),確認(Validation;VAL)
  4. Level 4(managed):組織可收集詳細的軟體程序以及軟體產品的量測資料。軟體作業程序和產品都有一組量測的數據,可讓工程師和經理們了解程序和產品的狀況。
    1. 流程重點:Quantitative Project Management(QPM)
  5. Level 5(optimized):評估革新性的新技術,做反省與提升,有規則地依序導入採用,以持續不斷地改進程序。
    1. 流程重點:Causal Analysis and Resolution(CAR)

CMMI實施

CMM是一種軟體開發的流程標準,可說是種軟體開發的品質保 証,就像ISO是組織管理的品質保証一樣。細分之下,CMM/CMMI分成五級,從第一級(level 1)到第五級(level 5),分別標示軟體公司流程管理的競爭力程度,第四級可做質量管理,第五級則為最佳化,可預防缺陷。

軟體先進國家都已體認到CMM/CMMI的重要性。其中最難的四、五兩級公司,多數集中在美國及印度。我國行政院於91年11月院頒之『行政院所屬各機關資訊業務委外服務作業參考原則』中,亦明訂通過CMMI 評鑑得列為採購加分項目。

Reference