軟體工程(Software Engineering;SE)

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

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

簡介
軟體工程
軟體開發架構的演進
系統分析與設計
- 結構化技術
- 物件導向技術
統一塑模語言(Unified Modeling Language,UML)
樣式理論(Pattern Theory)
資料庫正規化
CMMI(Capability Maturity Mode Integrated)
參考書目
網路資源

簡介

1968年秋季，NATO（北約）的科技委員會召集了近50名一流的編程人員、計算機科學家和工業界巨頭，討論和制定擺脫“軟體危機”的對策。在那次會議上第一次提出了軟體工程（softwareengineering）這個概念。
大多數軟體開發項目的失敗，並不是由於軟體開發技術方面的原因。它們的失敗是由於不適當的管理造成的。遺憾的是，盡管人們對軟體專案管理重要性的認識有所提高，但在軟體管理方面的進步遠比在設計方法學和實現方法學上的進步小，至今還提不出一套管理軟體開發的通用指導原則。
「新技術一直冒出來，學都學不完了，那裡有空搞軟體工程」、「計畫趕著進行，做都做不完了，那裡有空搞軟體工程」...... 就在這一個又一個的藉口中，原本可以幫助軟體產業進步的軟體工程，竟然變成他們口中阻礙軟體產業進步的絆腳石似的，怎不令人對他們的無知感到心寒。
寫程式的難度愈來愈低，因為程式語言越來越高階，API 越來越多，開發工具越來越好用，寫程式的門檻自然就大大地降低了。想要開發出有價值的中大型系統，軟體工程就很重要了，以蓋房子來說，你可以隨便找一兩個工人用磚或木材來蓋一棟矮房，但是如果想蓋一百多層樓的101大樓，你非得有良好的工程規劃不可，軟體不也是如此？程式設計師名片上的頭銜都是工程師，雖然和建築工程師、機械工程師... 一樣都被稱為工程師，但比較起來，軟體產業的工程師卻是最不工程導向的。

軟體工程

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

軟體開發技術包括軟體開發方法學、軟體工具和軟體工程環境。
軟體專案管理包括軟體度量、項目估算、進度控制、人員組織、配置管理、項目計畫等。
軟體工程是為了解決軟體危機而誕生，近來最熱門的技術有
- UML
- Design Patterns
- re-engineering
- XP
軟體架構已成為軟工熱門的研究之一。
開發流程由強調瀑布式流程(waterfall)轉為強調反覆式流程(iterative)。反覆式流程的主要精神是分析一些，設計一些，實作一些，執行一些，也就是將整個開發流程切割成數個週期(iteration)，每個週期都是一個叫小型的直線式流程，並且強調週期結束時都有可以執行的結果，而每個週期都是以前一週期的結果為基礎，在新增需求的方式進行，直到所有的軟體需求都滿足為止。因此反覆式流程也是一種漸增式流程(降低風險)。以結果來看，瀑布式流程只會交付一次產品，反覆式流程會交付多次產品。

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

process

Quality Assurance
Configuration Management
Project Management
CMM

software system

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

safety critical system

常用的formal工具 : Petri Nets

Petri Nets 的 reachability graph 常因可能的狀況太多而不可能分析，所以有許多論文會討論如何簡化它
現今也常用在電子商務上

軟體開發架構的演進

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

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

接下來，讓我們來瞭解程式開發架構是如何由1-Tier走向N-Tier的

單機架構(1-Tier)

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

檔案型的資料有傳輸浪費頻寬與異動需鎖定等問題
商業邏輯或使用者介面改變，需重新部署

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

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

商業邏輯或使用者介面改變，需重新部署
資料庫伺服器容易成為效率的瓶頸，例如Client端的連線數會增加伺服器connection紀錄負擔 //因此我們應該只在取用資料與將資料回存時才進行connection
商業邏輯應該放在client或server端的問題
- 放在前端，資料庫可不受限制的抽換，但商業邏輯改變，需重新部署
- 放在後端，通常是利用Stored Procedure，但這樣就不易抽換資料庫軟體

分散式架構(N-Tier)

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

AP Server 與 Database Server除了穩定運作的需求外，也易成為效率的瓶頸
需要能將商業邏輯包裝成元件的技術，門檻較高

網路服務(Web Service)

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

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

資訊系統的種類

交易處理系統(Transaction Processing System;TPS)
管理資訊系統(Management Information system;MIS)
決策支援系統(Decision Support System;DSS)
高階主管資訊系統(Executive Information System,EIS)
專家系統(Expert System;ES)
- 使用者介面
- 推理機
- 知識庫
操作性系統(Operational Systems)
辦公室自動化系統(Office Automation Systems;OA)

資訊系統的建置策略

公司內部獨力完成
- 使用者自建(End User Development;EUD)
- 資訊部門發展
公司外部取得
- 委外開發(Outsourcing)
- 套裝軟體(Application Package)
其他方式
- 與軟體公司合作等

系統開發模式(SoftWare Process Model)

瀑布式(Waterfall)

~~編碼與修正模式(Code-andfix Model)~~
~~階段模式(Stagewise Model)：Benington(1956)~~
瀑布模式(Waterfall Model)：Royce(1970) = 系統發展生命週期(System Development Life Cycle;SDLC)
- 特徵
  - 適用於需求明確，領域知識(Domain KnowHow)容易取得的專案
  - 強調開發過程需有完整的規劃，分析，設計，測試及文件等管理控制
  - 前一階段完成後才能進入下一階段，各階段僅循環一次
  - 沒有明確規定要劃分成多少個階段，每一階段皆有文件產出
- 至少劃分3階段
  - 分析
  - 設計
  - 實施
- 通常劃分5~7階段不等(每一家學說都不同,掌握精神即可)
  - 初步調查 (Preliminary Investigation)
  - 系統分析 (System Analysis)
  - 系統設計 (System Design)
  - 系統開發 (System Development)
  - 系統實施與評估 (System Implementation and Evaluation)

反覆式(Iterative)

漸增模式(Incremental Model)：Mills(1971)
- 強調需求可分成幾個部分
- 開發週期可反覆進行
雛形模式(Prototyping Model)：Bally(1977)
- 適用於需求不明確，專案小，應用領域不熟悉或高風險之專案
- 強調雛形之快速開發，以雛形作為使用者與資訊人員溝通之工具，使用者高度參與等
- 雛形策略
  - 演進式雛形(Evolutionary Prototyping)
  - 用後丟棄式雛形(Rapid Throwaway Prototyping)：因成本較高，故適用於風險最高的情形
螺旋模式(Spiral Model)：Boehm(1988)
- 強調「風險分析」結合了SDLC與雛形模式
- 螺旋模式的4個步驟
  - 找出系統目標，可行方案與限制
  - 依目標與限制評估方案
  - 開發雛形
  - 使用者評估，決定下一步驟
同步模式(Concurrent Model)：Aoyama(1993)
- 構想源於製造業的同步工程(Concurrent Engineering)目的在於縮短產品開發時間，適用於套裝軟體的專案
- 同步模式的構想
  - 活動同步(Activity Concurrency)：不同團隊平行開發
  - 資訊同步(Information Concurrency)：不同團隊資訊共享
  - 整合性的管理系統：協調各種資源的互動關係

需求擷取與分析

使用者需求的分類

巨觀需求：欲電腦化的環境，作業程序與範圍，輸出與輸入所需之資訊或表單及系統目標，限制，主要功能等，盡可能在需求分析階段中釐清與確定。
細部需求：使用者介面之要求，例外狀況之處理，錯誤及輔助訊息之顯示，通常到設計階段處理。

需求的擷取方式

查閱文件
實地觀察(Observation)
訪談(Interview)
- 開放式訪談(Open Interview)：類似交談
- 結構化訪談(Structured Interview)：類似詢問
問卷
- 簡單隨機抽樣
- 分層抽樣
- 便利抽樣
- 判斷抽樣
開會討論
聯合開發(Joint Application Development;JAD)
1. 範圍界定
2. 關鍵人員的熟悉
3. 會議準備
4. 會議進行
5. 文件產生

需求的表達工具

流程圖(Flow Chart)
- □：表達作業處理，可配合處理描述
- ◇：表達流程控制
- →：表達資訊流向
- 波浪形：表達資訊的展示與儲存，可配合藍圖(Drawing) 與資料詞彙(Data Glossary)

需求分析文件的樣版

問題描述
新系統目標
新系統限制
使用者需求
- 流程圖
  1. 處理描述
  2. 藍圖
  3. 資料詞彙

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

結構化技術：將資料與流程分開考慮
- 流程塑模：主要透過資料流程圖(DFD)
- 資料塑模：主要透過實體關係模式(E-R Diagram)
- 使用者介面塑模
物件導向技術

結構化技術

結構化設計(1960)：強調系統的結構化與可維護性，決定系統應有哪些模組(模組名稱,輸入,輸出,內部資料,處理邏輯)

結構化技術所需工具
文件	經驗法則	評估準則
結構圖(Structure Chart)	模組大小：小模組200行以內	內聚力
HIPO圖(Hierarchical Input Process Output)	控制間距：(Magic Number 7±2)	耦合力
處理規格描述(Process Specification) 結構化英語(Structured English) 程式設計語言(Program Design Language;PDL)	影響範圍
資料字典(Data Dictionary;DD)	控制範圍

結構化分析(1970)：利用圖形化文件工具(Graphic Documentation Tools)進行企業流程及企業資料格式塑模
- 事件列(Event List)
  - 資料流導向：客戶輸入代號
  - 時間導向：下午3點要簽發支票
  - 控制導向：系統的開啟或關閉
- 環境圖(Context Diagram)
  - ○：系統
  - □：外部實體
  - →：資料流
- 資料流程圖(Data Flow Diagram;DFD)：表達系統作業處理與資料流之關係
  - 表示符號
    - □：外部實體(Entity)
    - →：資料流(Data Flows)
    - ○：處理(Process)
    - 二：資料儲存(Data Store)
  - 建構方式
    - 由上往下分割(Top-Down Partitioning)
    - 由中間往外分割(Middle-Out)：Yourdon-1988
- 實體關係圖(Entity-Relationship Diagram;ERD)
  - 表示符號
    - 矩形：代表實體類型 (Entity Type)
    - 菱形：代表實體類型與實體類型間之關係 (Relationship)
    - 橢圓：代表實體類型或關係之屬性 (Attribute)
    - 直線：把屬性連結到實體類型或把實體類型連結到關係
    - 基數率(Cardinality Ratio)：代表實體類型與實體類型間之關係程度。常見的基數率是「1:1」、「1:N」及「M:N」三種
    - 參與限制(Participation Constraint)：個體的存在是否藉由與另一個個體之間的關係而存在。參與限制分為「全部參與（Total Participation）」、「部份參與（Partial Participation）」兩種。
- 處理規格描述(Process Specification)
- 狀態轉移圖(State Transition Diagram;STD)
結構化程式設計(1969)：Dijkstra提出，避免GOTO所造成的混亂
- 循序(Sequence)：compute,read,write
- 選擇(Condition)：if then else, case
- 重複(Repetition)：do while
由上而下發展
- 由上而下設計(Top-Down Design)
- 由上而下編碼(Top-Down Coding),由下而上編碼(Bottom-Up Coding)
- 由上而下實施(Top-Down Implementation)由上而下測試(Top-Down Integration Test)
  - 白箱測試：由上而下或由下而上依功能測試
    - 單元測試
    - 整合測試
  - 黑箱測試：情況極端與例外的測試
    - 系統測試
    - 驗收測試

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

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

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

功能內聚力(Function Cohesion) ：單獨處理一件工作
順序內聚力(Sequential Cohesion) ：模組順序執行，一個模組的輸出會成為下一組的輸入
溝通內聚力(Communication Cohesion )：使用相同的資料
暫時內聚力(Tempral Cohesion)：模組執行無順序關係但須在一定時間內完成一件工作
程序內聚力(Procedural Cohesion)：按照順序執行而不共用資料
邏輯內聚力(Logical Cohesion)：根據上層模組傳來的參數決定執行的功能
偶發內聚力(Coincidental Cohesion)：模組可做好幾件不相干工作，各模組具有功能內聚力

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

資料耦合力(Data Coupling)：模組間藉由資料傳遞參數
資料結構耦合力(Stamp Coupling)：模組各自使用資料結構的一部份
控制耦合力(Control Coupling)：A模組傳遞旗標控制B模組
共同耦合力(Common Coupling)：兩模組使用相同的資料區
內容耦合力(Content Coupling)：A模組可使用B模組的程式碼或改變其變數

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

針對日趨複雜之軟體需求的挑戰，軟體業界發展出了物件導向 (OO) 的軟體發展模式，作為針對「軟體危機」的最佳對策。
物件導向之觀念起源於模擬語言(1966, Simula 語言)，以物件模式來描述真實系統，並將資料抽象化(Data Abstraction)、封裝、繼承與同名異式的觀念融入於物件系統開發中。
第一個純粹的OOP語言：1980全錄(Xerox)公司的PARC研究中心所開發的 Smalltalk-80

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

物件 & Message
繼承性(inheritance)
封裝性(encapsulation)
動態連結(dynamic binding)

抽象化(Abstraction)

抽象化所描述的過程，就是由許多物件中抽離出重要的特性來，而這些特性，足以讓被抽象化的物件，與別的物件分別開來。同時，對於物件抽象化的結果，也因我們的需要不同，而有所變化。
所有的抽象化都是系統的發展，為了維繫存在，必須適應變化的唯一路途。
抽象化的目標與物件導向一樣，就是『讓我們更容易模擬世界，並加以處理』。

物件(Object)=案例(Instance)

由一群具有相同資料結構與相同行為的物件所描述的集合中，某一個特定且存在的物件。
物件是一個具有狀態(State)、行為(Behavior)與識別(Identity)的實體或抽象化概念(Abstract Concept)，且其行為會影響其狀態。
物件是一個封包，包括了名稱(name)、屬性(attribute) 及操作(operation) 3部分。
- 在C++中稱為資料成員(Data Member) 與成員函式(Member Function)
在Java中稱為欄位(Field) 與方法(Method)
每一個物件都是一個被class所分類的instance (Every object is an instance of a class)

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

由一群具有相同資料結構與相同行為的物件描述，所形成的集合，經由抽象化(Abstraction)後稱之為類別。
類別是一種定義(Definition)、描述(Description)、樣版(Template)，故可以類別建立新的物件。

封裝(Encapsulation)

將資料與操作此資料的方法包裝成一個物件稱之為封裝。
封裝後物件的結構分為2部分 1.介面(Interface)2.實作(Implementation)
封裝將物件的實作細節隱藏，使其與外界環境隔離，只允許該物件所包含之操作修改其資訊，稱之為資訊隱藏(informatiion hiding)。

繼承(Inheritance)

所謂繼承就是從基底類別(base class)，建立衍生類別(derived class)。衍生類別除了繼承基底類別的所有特性外，可依據需求建立新的功能或修改，其基底類別不會受任何影響。繼承可提升程式碼的重複使用性(reusability)。
- 多重繼承(multiple inheritance)：一個類別可以直接繼承多個基底類別─網路結構。多重繼承最常引發的麻煩便是「模稜兩可」(ambiguity) 。
- 簡單繼承(single inheritance)：一個類別最多只能直接繼承一個基底類別─樹結構。
類別間的層級關係
- 父類別(Superclass)、泛化、一般化(Generalization)：萃取類別的相同屬性與操作所成的上層類別。
- 子類別(Subclass)、繼承、特殊化(Specialization)：在既存類別下，加上專門的特性所成的下層類別。
- 「is a」的關係：子類別 is a 父類別，如鋼琴是樂器。

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

定義相同名稱的操作，以不同的方式處理不同類型的資料。
多型在程式執行期利用動態連結(Dynamic Binding)的方式判斷訊息參數的類型與個數來決定運作的方法。
達到物件導向中「多型」的方法
- 抽象類別 (abstract class)：抽象類別是為了讓方法的使用更多樣化，物件轉換型別為抽象類別後，即使方法名稱相同，其實作的內容與執行結果卻不同。

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

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

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

這種反覆的開發方式，在每個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

初始階段(inception)
詳述階段(elaboration)
建構階段(construction)
轉換階段(transition)

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

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

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

使用個案觀點(Use Case View)：以使用個案充分表達軟體功能需求
設計觀點(Design View)：以物件的觀念，表達出軟體設計結果 (Logical View)
流程觀點(Process View)：
實施觀點(Implementation View)
佈署觀點(Deployment View)

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

使用個案塑模：使用個案圖
物件資料結構塑模：類別圖、物件圖
物件互動行為塑模：互動圖(包含了循序圖、合作圖)
作業行為塑模：活動圖、狀態圖
使用者介面塑模：
系統元件與組織結構塑模：元件圖、部署圖

物件導向的軟體維護

軟體的維護就是軟體的再生，維護較開發而言要花更多的金錢與時間
軟體維護的思維上就是要考慮到可維護性(Maintainability) 與可重複使用性(Reuseability)
傳統的重複使用方案並無法兼顧可維護性與可重複使用性的目標，物件導向設計的重複使用方式可在含有宏觀商業邏輯的抽象層次的上層結構來考量，以達到可維護與可重複使用的目標。
物件導向類別設計的法則
- 開閉原則(Open-Closed Principle ; OCP)
- Liskov代換原則(Liskov Substitution Principle ; LSP)
- 依賴倒轉原則(Dependency Inversion Principle ; DIP)
- 介面隔離原則(Interface Segregation Principle ; ISP)
- 組合/聚合重複使用原則(Composition / Aggregation Principle ; CARP)
- Demeter原則(Law of Demeter; LoD)

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

模組應當敞開擴充大門，但關閉修改之窗。
如何達成開閉原則，關鍵在抽象化。
不允許更改的是系統的抽象層，允許擴充的是系統的實作層。
OCP的另一個角度是EVP對可變性的封裝原則(Principle of Encapsulation of Variation)即找到一個系統的可變因素，並將之封裝起來。
可變性必須被封裝，那不同的可變性呢？應用繼承來處理，因此繼承應被視為封裝變化的方法，但繼承的層數避免超過2層以免不同的可變性混和。
應避免將單純的流程控制轉移語句改寫成多型，除非內含了某種商務邏輯。
所有的設計樣式(Design Pattern)都是針對不同的可變性封裝，使系統在不同的角度上達到開閉原則。

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

子類別應該可以使用其基礎類別替代。
Liskov代換原則是繼承之所以能重複使用的基石，只有當衍生類別可以替換掉基礎類別，且軟體的功能不受影響時，其類別才算真正的被重複使用，而衍生類別也才能夠在基礎類別的基礎上增加新的行為。
Liskov代換原則要求凡是基礎類別使用的地方，衍生類別一定適用，故衍生類別必須包含全部基礎類別的介面
針對違反LSP設計時可行的重構(Refactoring)方式
- 當類別A錯誤的繼承類別B時，可建構一個新的抽象類別C，作為2個具體類別A,B的父類別
- 當類別A錯誤的繼承類別B時，可重構為類別B委派(Delegate)類別A

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

要依賴於抽象，而不要依賴於具體。
依賴倒轉原則的策略是依賴介面或抽象方法及類別，而不是具體方法或類別，包括了下列情況都得遵循DIP
- 變數的類別宣告
- 參數的類別宣告
- 方法的傳回型態宣告
- 型態的轉換
抽象層級含有宏觀和重要的商務邏輯，具體層級含有與實作有關的演算法語次要的商業邏輯，而傳統的程序性設計或錯誤的類別規劃會讓抽象層級依賴於具體層級，因此依賴倒轉原則可倒轉此一現象，讓實作改變時，商業邏輯無須變動。
一個具體Java類別應當只實作Java介面和抽象Java類別中宣告的方法，而不應當給出多餘的方法。
若Java程式要參照一個物件，若此物件有一個抽象型態，則應使用此抽象型態作為靜態型態(Static Type)
- 靜態型態(Static Type) = 實際型態(Apparent Type)：變數被宣告時的類別
- 實際型態(Actual Type)：變數所參照的物件真實型態
若一個物件存在其抽象類別，就應當在任何參照此物件的地方使用抽象類別
Java語言中建構一個物件的程式是違背OCP與DIP的，但可在此類別被建構出來後過多型性使得使用端依賴於其抽象類別。
- List employees = new Vector();
DIP是最難實作的原則，因為會使用到物件工廠就會產生大量的類別。
DIP假定所有的具體類別都是會變化的並不完全正確，因為某些具體類別是相當的穩定因此並不需要為此發明一個抽象型態。

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

由客戶端指定的許多介面比一個一般用途的介面好。
使用多個專門的介面比使用單一的總介面要好，否則會造成對介面的污染(Interface Contamination)。
一個類別對另一個類別的依賴性應當是建立在最小的介面上的。

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

Demeter原則(Law of Demeter; LoD)

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

由Rational software corporation融合了物件導向三劍客的方法論，統一了以物件導向分析與設計的表示法，於1997年11月由 OMG(Object Management Group) 公布為物件導向視覺化塑模的標準，目前最新的版本為 2.0 (2003/06/01)
UML是一種塑模語言，而非方法論，它並沒有規範符號的使用時機與次序僅利用符號來達到溝通的目的，從分析，設計到實作都可以使用同一套符號來表達，因此應用時可以搭配適合的方法論。
UML之所以重要，就是因為他有助於軟體開發人員之間的溝通。我們必須在某種程度上使用他以協助溝通，而非阻礙溝通。
循序圖、合作圖合稱互動圖。
UML設計的理念
- 使用個案導向(強調以使用者的角度來定義功能需求)
- 軟體架構設計(強調系統開發要有藍圖)
- 往覆，漸增式流程(強調降低專案風險)

使用個案圖(Use Case Diagram)

以OO技術開發系統時在需求分析時常利用典型的情節(Scenario)來進行需求塑模，這種個案模式一直沒有統一的表達方式直到Ivar Jacobson等人(1996) 才將使用個案的表達正式化。
使用個案圖表示從使用者之觀點描述系統的行為者與系統間之互動行為與關係，包含了行為者和使用個案二個元件，此法在資料與展示格式上僅利用文字描述，若能搭配結構化中的藍圖與資料詞彙則可補強其不足之處。
使用案例是專業分工的依據，是專案進度評量的重要因素。

行為者(Actor) = 參與者

環境中與系統有互動關係的人或事物，有該使用個案的啟動者即主要行為者(Primary Actor) 與其他參與者即次要行為者(Secondary Actor) 。
參與者被繪製成一個火柴棒形狀的小人並將名稱置其下方。

使用個案(Use Case)

使用者透過介面要求系統所做一系列相關的事件流，包含了最主要的事件即基本路徑(Basic Course) 與其他衍生事件或可能發生的錯誤即替代路徑(Alternative Courses) 。
使用案例被繪製成橢圓形並將名稱置於圖形內部或底部來表示
使用個案間的關係：
- 關聯(association)：使用個案與行為者之間的關係，以實線段表示。
- 包含(Include)：一個使用個案會用到另一個使用個案，二個或以上的使用個案具有相同的行為模式時，可將該段行為模式獨立出來成為一個新的使用個案，再建立包含的關係，用一個虛線實心箭頭的線段並含有關鍵字 <<include>> 。
- 延伸(Extend)：在某情況下，使用個案會插入另一使用個案的定義中，用一個虛線實心箭頭的線段並含有關鍵字 <<extend>> 。
- 一般化(Generalization)：一個使用個案繼承另一個使用個案的行為，用一個實線空心箭頭表示的線段從子使用個案指向父使用個案，且箭頭朝向父使用個案端。

情節(Scenario)

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

建構使用個案圖的步驟

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

類別圖(Class Diagram)

表示系統存在之類別、介面及它們間之靜態資料結構與邏輯關係
通常以三層表示
- 類別名：正體字：具體類別，斜體字：抽象類別，介面：<interface>
- 屬性層：
- 方法層：
屬性與方法有四種封裝方式
- public:以符號 + 表示
- private:以符號 - 表示
- protected:以符號 # 表示
- static:以符號 _ 表示
描述介面的類別圖：沒有private的封裝
描述物件的類別圖：描述類別的實體，名稱下需加底線

關係

類別間的關係包括了

依賴 / 相依(Dependency)
- 使用的關係，表達一個類別會用到另一個類別
- 另一個類別的改變會影響到使用他的類別，但反之不必然
- 一類別的區域變數，方法參數，方法返回值，對靜態方法呼叫時是另一個類別時稱之
- 以虛線開箭頭表示。------->
一般化(Generalization)
- 繼承的關係，包括了類別間的繼承，介面間的繼承，類別對介面的實作等
- 以實線空心箭頭表示。
關聯/結合(Association)
- 同一層級的類別間靜態的結構關係
- Java語言中是使用實體屬性實作的
- 其關係有雙向與單向，建議多用單向
- 關係有基數(Multiplicity)，關係有名稱，但通常均予以省略
- 以實線段表示。 —
  - 依關聯的類別個數來分
    - 二元關聯(Binary Association)
    - 多元關聯(n-ary Association)
  - 依描述整體與部分的關係來分(不同層級的類別)
    - 聚合 / 聚集(Aggregation)：以實線且整體端加一個空心的菱形表示。◇—
    - 合成 / 組合(Composition)：整體物件需負責部分物件的生命週期，以實線且整體端加一個實心的菱形表示。◆—
實現化(Realization)
- 以介面實現其他類別之描述
- 以虛線空心箭頭表示。

基數(Multiplicity) =多重性

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

物件圖(Object Diagram)

描述系統於某一時間點的靜態結構，也稱為案例圖，包含了物件與連線二個元件。
物件間的關係稱為連線(Link)。

循序圖(Sequence Diagram)

以時間發生之先後順序來表達物件間的訊息傳遞與處理之程序，包含了類別之物件、訊息、操作、生命線與控制焦點等元件。
循序圖有2個象線
- 垂直象線依照訊息呼叫發生的時間順序，來描述訊息呼叫的先後次序。
- 水平象線描述一個物件實體傳送訊息給哪一個物件實體。

訊息(Message) =刺激(Stimuli)

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

生命線(Lifeline)

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

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

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

系統邊界 (System Border)

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

建構循序圖的步驟

確認物件
描述操作
描述訊息
繪製循序圖

合作圖(Collaboration Diagram)

著重表達物件間之連結結構，並能同時展現物件間的訊息傳遞與處理之程序，包含了類別之物件、連結、訊息與操作等元件。
Rational Rose可將循序圖直接轉換成合作圖。
合作圖與循序圖相比較，少了物件生命線與焦點控制，多了路徑與序數

連結(Link)

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

訊息(Message)

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

活動圖(Activity Diagram)

狀態圖(State Diagram)

元件圖(Component Diagram)

部署圖(Deployment Diagram)

樣式理論(Pattern Theory)

研究一再發生的典型事例，以便研究者可以研習至融會貫通，舉一反三，推陳出新的理論，叫做樣式理論。
樣式不是發明，而是發現
現代樣式理論：建築設計學家亞歷山大 Christopher Alexander提出
- 無名之質 (The Quality Without a Name ; QWAN)
- 門 (The Gate)
- 道 (The Way)：又稱作「永恆之道」(The Timeless Way)
Alexander認為透過追尋「道」，可以通過「門」到達「質」是任何一種工程設計的發展過程
「樣式是某外在背景環境 (Context) 下﹐對特定問題 (Problem) 的慣用解決之道 (Solution) 」。
樣式是不斷的重複發生，而有其重複性。但重複的不是問題的本身，而是問題的本質，所以要把不同問題以相同的樣式來處理，勢必要擷取其本質，也就是『抽象』。所以研究樣式必須重視問題本質而非問題的表象。同樣的問題的背景環境及解決之道也是抽象的。
設計樣式是對軟體設計模型進行不斷追求完善的使用工具，但樣式的使用無絕對的公式，需要經過大量的個人實踐才能熟練掌握。
重構(Refacotrying)是對不滿意的程式碼進行彌補的時候所需要的技術，因此重構的存在證明了樣式並非軟體設計的銀彈(Silver Bullet)
樣式的要素
- 名字(Name)
- 問題(Problem)
- 初始環境(Initial Context)
- 力(Forces)
- 解答(Solution)
- 舉例(Examples)
- 末態環境(Resulting Context)
- 推理(Rationale)
- 相關樣式(Related Patterns)
- 已知應用(Known Uses)
樣式的種類
- 設計樣式(Design Patterns)：GoF提出
  - 建構型樣式(Creational Pattern)
  - 結構型樣式(Structural Pattern)
  - 行為樣式(Behavioral Pattern)
- 架構樣式(Architecture Patterns)
- 分析樣式(Analysis Patterns)：Martin Fowler提出
- 反樣式(Anti-Patterns)
物件導向樣式的經典：四人幫(Gang of Four ; GoF) 即Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides等四人，於1995年出版之 Design Patterns - Elements of Reusable Object-Oriented Software這本經典著作，包含23種軟體設計樣式，例如MVC Pattern，將軟體設計分為Model、View和Control三個部分，Model是屬於企業邏輯的部分，例如網路購物的交易機制；View是使用者介面的設計；Control則串連Model與View的程式碼。

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

定義

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

關聯式資料庫的鍵(Key)

候選鍵(Candidate key)：能在資料表中將各列分別出來的欄位(一個資料表可以有多個)
主鍵(Primary key)：從候選鍵中選出來作為主要鍵的欄位
替代鍵(Alternate key)：其他未被選為主鍵的候選鍵欄位
連結鍵(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 的定義，軟體工程的成熟度分成五個等級，簡單介紹如下：

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

參考書目

Software Engineering 6th Edition; SOMMERVILLE; addison wesley;ISBN:020139815
吳仁和，林信惠;系統分析與設計;智勝出版 ISBN:9577292194
河合昭男;學習物件導向的第1本書;博碩文化; ISBN:9575275373
Fowler，Scott; UML精華第二版; 碁峰; ISBN:9575667557
閻宏 ; Java與樣式理論 ; 碁峰 ; ISBN:9864214179
賀元，賴明宗，劉燈 ; 世紀末軟體革命/C++,GUI與物件導向理論;傳徵(股)公司;ISBN:9579996504
賀元，賴明宗，劉燈 ; 世紀末軟體革命2;資訊人文化事業;ISBN:9579964092

網路資源

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

This work is licensed under a Creative Commons License