軟體工程(Software Engineering;SE)

本網頁以打造無障礙閱讀為目標,可以用任何瀏覽器來觀看本網頁


軟體工程這門課程在國內教育上,資工與資科等系所會列為必修而資管僅列為選修而已,資管會列為必修的是系統分析與設計,但系統分析與設計只是整個軟體工程的一小部分而已,所以資管出身的資訊人是一定要瞭解的啦....。

簡介

軟體工程

軟體工程包括兩方面內容:軟體開發技術和軟體專案管理。

SA -> SD -> coding -> test -> installation -> maintance

process

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

software system

  1. bussiness application
    1. TPS,DSS,MIS,ES
  2. web application
    1. Web System
    2. Web Service
    3. E-service : marketing+MIS
  3. real-time
  4. safety-critical

safety critical system

常用的formal工具 : Petri Nets

軟體開發架構的演進

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

展示層(Presentation Tier)
將UI的部分獨立出來,除了可讓專業的美工處理之外,還要考慮到程式邏輯的變動不會影響到畫面,或是畫面的變動不會影響到程式邏輯
商業邏輯層(Business Logic Tier)
將企業運作的邏輯獨立成元件,以方便更新程式碼時只需要異動相關的元件即可
資料層(Data Tier)
將關於資料存取的部分獨立出來,如此一來在變動資料庫架構時便不需要更改程式邏輯或畫面
接下來,讓我們來瞭解程式開發架構是如何由1-Tier走向N-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架構可供參考。

系統分析與設計(Systems Analysis & Design)

資訊系統的種類

資訊系統的建置策略

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

系統開發模式(SoftWare Process Model)

瀑布式(Waterfall)

反覆式(Iterative)

需求擷取與分析

使用者需求的分類

需求的擷取方式

需求的表達工具

需求分析文件的樣版

  1. 問題描述
  2. 新系統目標
  3. 新系統限制
  4. 使用者需求

系統分析與設計的兩大技術

結構化技術

結構化分析與設計的評估準則

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

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

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

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

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

抽象化(Abstraction)

物件(Object)=案例(Instance)

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

封裝(Encapsulation)

繼承(Inheritance)

同名異式(Polymorphism)=多型=動態繫結(Dynamic binding)

物件導向的系統開發方法(Process)

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

  1. 需求分析 ->
    (需求模式) 主要以使用個案圖、活動圖、藍圖、資料詞彙、介面元件等作為表達工具。
  2. 系統分析與設計 ->
    (分析模式) 將需求模式中的系統表達成一個物件架構,包括了物件圖與類別圖
    (設計模式) 將物件架構至現況之實施環境,包括了循序圖、合作圖、狀態圖、活動圖。
  3. 實施與測試 ->
    (實施模式)元件圖、部署圖。
    (測試模式)
這種反覆的開發方式,在每個iteration(反覆的期間)結束後,希望能產生具備產品品質、測試、整合過的軟體出來,所以會有多個發行版本(release)存在
重要的物件導向的系統開發方法
方法名稱 方法論者(3 Amigo)
Booch Grady Booch
OMT(Object Modeling Technique)物件塑模技術 Jim Rumbaugh
OOSE(Object-Oriented Software Engineering)物件導向軟體工程 Ivar Jacobson
RUP(Rational Unified Process)Rational統一流程 Rational / IBM
XP(eXtreme Programming)極致程式設計 Kent Beck
要看看還有哪些系統開發方法,可參考: http://www.cetus-links.org/oo_ooa_ood_methods.html

Booch

Booch之方法將系統開發過程分為 觀念期、分析期、設計期、進化期、維護期,常用於大型軟體專案。

OMT

Rumbaugh之OMT方法將系統開發過程分為 觀念形成、物件導向分析、物件導向設計三個階段,常用於企業資訊系統。

OOSE

Jacobson之OOSE方法將系統開發過程分為 分析、建構、測試三個階段,以使用個案著名。

RUP

物件導向的塑模 = 軟體架構

軟體開發如同音樂譜曲及建築設計,其過程中必須將需求、分析、設計、實作、佈署等各項工作流程之不同觀點予以呈現,這就是軟體系統之塑模(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)

組合/聚合重複使用原則(Composition / AggregationPrinciple ; CARP)

Demeter原則(Law of Demeter; LoD)

統一塑模語言(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) =啟動條(ActivationBar)

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

系統邊界 (System Border)

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

建構循序圖的步驟

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

合作圖(Collaboration Diagram)

連結(Link)

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

訊息(Message)

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

活動圖(Activity Diagram)

狀態圖(State Diagram)

元件圖(Component Diagram)

部署圖(Deployment Diagram)

樣式理論(Pattern Theory)

關聯式資料庫的正規化(normalization)

定義

若關聯表中每一欄位的值都是唯一而不可分割的(Atomic),則稱之為正規化

關聯式資料庫的鍵(Key)

  1. 候選鍵(Candidate key):能在資料表中將各列分別出來的欄位(一個資料表可以有多個)
  2. 主鍵(Primary key):從候選鍵中選出來作為主要鍵的欄位
  3. 替代鍵(Alternate key):其他未被選為主鍵的候選鍵欄位
  4. 連結鍵(Concatenated key):指候選鍵是由多個欄位所組成

一階正規化 (First Normal Form; 1NF)

又稱為平坦檔(Flat File),若關聯表中的任一行與任一列的交叉格(Cell)上均只有一個值,但會有插入,刪除,更改等異常(Anomalies)

二階正規化 (Second Normal Form; 2NF)

符合一階正規化的關聯表,再除去資料的 部分功能相依(Partial Dependency)
(將1NF中由部分主鍵就可以決定其值的欄位移出成為另一個關聯表)

三階正規化 (Third Normal Form; 3NF)

符合二階正規化的關聯表,再除去資料的 遞移相依(Transitive Dependency)
(將2NF中由非由主鍵決定其值的欄位移出成為另一個關聯表)

Boyce-Codd正規化 (Boyce-Codd Normal Form; BCNF)

符合三階正規化的關聯表,再除去任何因功能相依所造成的異常結果

四階正規化 (Fourth Normal Form; 4NF)

符合BCNF正規化的關聯表,再除去所有的多值相依

五階正規化 (Fifth Normal Form; 5NF)

符合四階正規化的關聯表,再除去剩餘的所有異常情況

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

CMMI實施

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

軟體先進國家都已體認到CMM/CMMI的重要性。目前全球約有700餘個包括公司及組織的單位通過CMM認証。其中最難的四、五兩級,全球各自有73與67個單位獲得,多數集中在美國及印度,其他則以個位數分佈在澳洲、蘇俄、以、法、新加坡等國。

我國行政院於91年11月院頒之『行政院所屬各機關資訊業務委外服務作業參考原則』中,亦明訂通過CMMI 評鑑得列為採購加分項目。

參考書目

網路資源

主 網 站:http://peterju.notlong.com (目前轉址至 http://irw.ncut.edu.tw/peterju/) Sitetag Logo

Level Triple-A conformance icon | [歡迎使用任何作業系統、瀏覽器觀看!] | Valid XHTML 1.0 Transitional | Valid CSS! | [Valid RSS] | [創意公眾許可証]
This work is licensed under a Creative Commons License