系統分析與設計王堯天第12章 物件導向開發方法

第12章 物件導向開發方法

1.請說明物件的意涵與物件的基本特性。
【參考答案】：
所謂「物件」（Object）的意涵是指：「一種具有識別子（Identificator）、狀態（State）與行為（Behavior）的實體或抽象化的概念。」換言之，物件是人類對於實體世界的事物產生的一種有意義的觀念或實體。以物件的特性而言，識別子是用來識別不同的物件，屬性是物件具備的一些重要特性，屬性的描述允許使用文字、數字或文數字、布林代數等不同方式。其次，物件為了傳遞溝通的訊息須要透過訊息傳遞（Messages Passing）的過程，經由訊息的傳遞改變物件的狀態，常見的訊息有呼叫、傳回、送出、創造與銷毀等類型。
茲將物件的基本特性說明如下：
一、抽象化─抽象化（Abstraction）的意涵是指：「將物件的重要特性加以淬取出來，以圖形或數學公式予以表現出來的一個過程。」一般而言，抽象化是從功能的觀點，將事物的屬性與操作等重要特性予以淬取出來，將注意力集中在相似性（Similarity），忽略其中的細節並且進行系統化的分類活動。因此，抽象化是針對物件的特性、狀況與流程之相似性，經由抽象化的過程有助於一個系統的描述、分析與設計工作的進行。
二、階層化─階層化（Hierarchy）的意涵是指：「將物件進行定義、分類、排序，使一些物件之特性相近者加以聚合而達到有效管理的目標。」基本上，階層化的分類方式有一般化與組成兩種關係。一般化的關係是屬於一種類別(a kind-of)的關係，另外一種是組成的關係，它是屬於一種元件組成(a part-of)的關係。階層化的目的是將一群的物件做有系統的分類與管理。如此可以簡化物件的類別，使物件類別的數目大幅度減少，提升物件類別的處理效率。
三、模組化─模組化（Modularity）的意涵是指：「將一群物件進行系統化的組合，以達到某一個特定功能的過程。」其主要工作是定義模組的介面與決定模組的基本功能。模組化的目的是將一個系統細分（Decompose）為若干個內聚力強與低耦合力的模組，採取上述的作法可以使需求的改變的影響達到最低的程度。
四、封裝─封裝（Encapsulation）的意涵是指：「將物件的資料與方法包裝成一個物件。」因此，物件與外部物件傳送訊息時，可以不必考慮該物件的內部結構與行為。
五、繼承─繼承（Inheritance）的意涵為：「子類別繼承父類別的特性包括屬性、操作與訊息傳遞等。」一個子類別除了繼承父類別的屬性與操作以外，亦可以自行重新定義屬於自己的屬性與操作。
六、多型、多載與覆載─多型（Polymorphism）的定義為：「一個物件對於不同形式的訊息可以依據本身的特性來給予不同的回應。」當不同物件進行相同操作時，可以定義多種不同方法來執行不同的處理內容，將不同方法整合成一個操作，由執行程式來判斷呼叫物件的作法稱之為「多型」。多載（Overloading）定義為：「同一類別可以使用相同操作名稱，但是可以定義不同的參數。」換言之，子類別可以使用相同的操作名稱，重新定義多個參數型態。此外，另一種做法是覆載（Overriding）子類別可以使用相同操作名稱，將父類別定義過的方法重新定義自己的方法。

2.何謂「物件塑模」?主要工作項目與原則爲何?
【參考答案】：
所謂「物件塑模」（Object Modeling）是指：「針對現實世界複雜的現象，利用物件模式予以表示出來的一個過程。」因此，物件塑模是採取物件導向的觀點，描述實體世界中發生的事件與產生的現象。圖一是物件塑模的示意圖，對塑模作業而言，塑模的輸入資料包括實體世界的現象、流程、功能、需求、實體或概念等，至於塑模的產出則是一些圖表、模型、公式、符號或規則的描述等，處理部分則包括抽象化、資訊隱藏、模式化、….等。換言之，物件塑模是一個轉換過程，主要目的是簡化實體世界的錯綜複雜問題與現象，對於一個上述問題的處理有極大的助益。
圖一：物件塑模的示意圖
基本上，一個完整的資訊系統之物件塑模作業必須涵蓋以下觀點﹕
(1) 劇情觀點針對系統功能與活動的需求進行描述，包括行為者與系統的互動關係，系統或子系統的投入、處理與產出。
(2) 設計觀點主要重點工作是物件的結構、資料表格與資料型態或邏輯處理之描述。
(3) 互動觀點主要重點是物件的行為、物件之間的訊息傳遞、物件之間互動關係的描述。
(4) 開發觀點以開發觀點，描述將物件結構與行為模式轉換為原始碼的方法。
(5) 部署觀點從實體觀點，具體的描述實體物件例如處理器與設備的節點以及實體物件之間的關係。
因此，物件塑模的工作項目包括﹕
(1) 表達視覺化（Visualization）利用圖形、自然語言或雛型等工具，將系統之複雜現象或特性以視覺化方式呈現出來。
(2) 系統規格化（Specification）將系統的特性以精確、不模糊與完整的規格進行詳述。
(3) 協助系統的建置作業（Construction）將模式轉換為C++、VB、Java的原始碼。
(4) 文件化（Documentation）將需求、架構、設計、程式、專案計劃、測試、雛型、操作等進行描述工作。
茲將物件塑模作業的基本原則敘述如下：
（1）需求導向針對不同對象、規模、複雜度與資訊系統要求品質等決定。
（2）重點化對於重要程度較高的資訊系統設計過程，應付出較多的時間
與人力。
（3）簡單化將一些複雜的問題進行簡化作業。
（4）有效性符合實際世界的需求，有效解決問題。
（5）彈性化模式設計宜保留彈性，使模式的修改更具彈性。
（6）實用性能夠解決企業的問題，具有實用性價值。
（7）績效具有良好的作業績效例如降低成本、縮短時程或提升作業效率。
3.請問物件塑模的實施步驟爲何?
【參考答案】：
茲將物件塑模的實施步驟說明如下:
（1）選定適合塑模的對象深入了解問題的特性進行領域分析，熟悉應用領域知識及一般作業流程以後，再選擇適合塑模的對象。
（2）進行需求分析針對物件的特性、結構、與作業流程進行深度化分析。
（3）物件模式之表達利用物件結構與行為模式表達系統的運作與功能，
（4）物件模式的評估與修正物件模式的評估包括有效性、績效、信度與實用性等，不斷進行檢討與修正模式的內容，一直到符合設計的需求為止。

4.請問物件導向的開發流程六階段的工作項目。
【參考答案】：
基本上，物件導向的開發流程可以分為六個階段﹕（圖二）
(1) 系統規劃階段主要工作包括時程、資源與成本的規劃與專案規劃書的製作。
(2) 軟體設計階段主要工作包括軟體需求分析、資料庫設計、介面設計與流程設計與設計規格書的製作。
(3) 軟體製作階段主要工作包括應用程式設計與程式規格書的製作。
(4) 軟體測試階段主要工作包括單元、整合、系統與驗收測試與測試紀錄。
(5) 驗收階段主要工作包括系統、軟體與文件的驗收。
(6) 維護階段主要工作包括軟體與文件的修正與改進。
如圖二所示，物件導向的開發方法是採取「漸進式」與「反覆式」的作法，在軟體設計、軟體製作、軟體測試與驗收等階段不斷的循環進行，一直到符合設計的需求為止。

圖二：物件導向開發的流程

茲將各階段的工作項目、系統文件、參與者、作業標準與軟體工具整理如表一。例如在軟體設計階段，主要工作項目是進行軟體需求、資料庫設計、介面設計、流程設計，遵循的作業標準是「軟體設計作業標準」，參與者是系統設計師、資料庫管理師。至於系統文件主要是軟體需求分析規格、系統設計規格、測試紀錄等，配合的軟體工具為CASE工具、繪圖器與進度管制工具等，其他階段的工作項目餘此類推。
表一：物件導向的開發流程
階段別 系統規劃 軟體設計 軟體製作 軟體測試 驗收 維護
主要工作 時程、資源與成本規劃 軟體需求分析
資料庫設計
介面設計
流程設計 應用程式設計 單元、整合、系統、驗收測試 系統與軟體驗收 系統與文件的修正與改良
作業標準 系統規劃
作業標準 軟體設計作業標準 軟體製作業標準 軟體測試作業標準 驗收作業標準 維護作業標準
參與者 專案經理
系統分析師
客戶代表 系統設計師
資料庫管理師 程式設計師 測試工程師 專案經理
客戶代表 維護工程師
系統文件 專案規劃書
系統規格書 軟體需求分析規格
系統設計規格 程式規格 測試規格 驗收紀錄 維護紀錄
軟體工具 排程軟體
成本估計軟體 CASE工具
繪圖器
進度控管工具 CASE工具
程式產生器
進度控管工具 CASE工具
程式分析器
進度控管工具 進度控制工具 程式分析器
進度管制工具

5.何謂「物件導向開發方法論」? 請針對下列物件導向方法進行詳細說明:
【參考答案】：
（1）OOSA
Shaler & Mellor於1988年與 1992年提出OOSA的方法，主要的進行方式有以下八個步驟﹕（1）將系統細分為若干個領域，（2）分析應用領域，（3）確認分析結果，（4）針對服務領域淬取需求，（5）分析服務領域，（6）規範架構領域元件，（7）建立基礎架構與元件，與（8）將每一個模式轉換為領域模式。基本上，OOSA提供資訊模式、狀態模式與處理模式，輔助圖表包括繼承圖、相依圖、類別圖、類別架構圖、事件表、控制圖、狀態流程表、狀態轉移表與專案矩陣圖等。
（2）OMT
OMT是Rambaugh 等人在1991年提出的一個物件導向開發方法，主要有觀念形成、物件導向分析與物件導向設計三個實施階段。第一個階段是觀念形成，主要作業包括界定範圍與主題，第二個階段是物件導向分析，主要作業是建立物建模式、動態模式與功能模式，第三個階段是物件導向設計，主要工作包括定義類別圖、資料字典、狀態移轉圖、訊息追蹤、物件操作、系統架構、軟體與硬體、介面與資料庫。OMT使用物件模式、動態模式與功能模式等三種模式來描述系統的架構、行為與功能，其中物件模式是描述物件的類別與關係，動態模式是描述系統行為，功能模式係包括DFD與內部流程，OMT主張以漸進方式進行物件導向的開發工作。
（3）OOSE
OOSE是一個精簡版的Jacobson的Objectory方法論。它是結合Jacobson與Rational公司的軟體開發流程架構的一個綜合版本。OOSE是一個相當完整的泛用性生命週期軟體開發模式。基本上，OOSE有以下三個實施階段（圖三）﹕
（1）分析階段主要工作重點在了解系統的需求建立一個概念性模式，主要工作項目包括：需求分析的建立功能需求、物件架構、需求模式、分析模式、物件圖與類別圖等，其次，進行強韌分析包括：建立實體、介面與控制模式。
（2）建構階段建立分析模式、建構系統、設計模式與實作模式，精練與調整物件架構、循序圖與狀態移轉圖。
（3）測試階段確認與驗證（Verifying and Validating, V&V）軟體的品質並且測試其功能是否滿足設計的需求。

圖三：OOSE的導入流程圖
（4）Booch 方法
Booch方法在軟體開發的應用過程，主要是觀念、分析、設計、進化與維護等五個實施階段。其中觀念階段的主要工作是蒐集核心需求，並利用使用個案來整理資訊；分析階段的主要工作是利用使用個案做劇情描述，建立類別、物件模式與行為模式；設計階段的主要工作是建立資訊系統的架構包括邏輯結構、行為模式與實體模式；進化階段主要是改良與精練已建立的物件模式；而維護階段的主要工作是維護已建立的物件模式。Booch方法提出六種塑模的圖形包括﹕（1）類別圖描述類別及彼此的關係，（2）物件圖描述物件及彼此的關係，（3）模組圖實體模組、類別與物件，（4）處理圖實體設計、處理器與節點的關聯，（5）狀態移轉圖狀態的改變流程，與（6）互動圖物件之間的訊息傳遞等。
（5）Coad/Yourdon方法
Coad/Yourdon提出的物件導向開發方法有三個實施階段（圖四）﹕
（1）物件導向分析（Object Oriented Analysis, OOA）階段主要工作是尋找抽象化類別與物件、確認物件結構以及物件的關係例如一般化、特殊化、整體與零件關係，其中類別物件圖（Class-and-Object Diagram）是系統的核心模式，它包含五個層次﹕（a）主題層次（Subject Layer）整體系統的區分（Partition）、巢狀主題之樹狀模式，（b）類別物件層次（Class-and-Object Layer）描述有關系統之抽象化與實體類別，（c）結構層次（Structure Layer）描述類別之間的關係例如一般化與特殊化、整體與零件關係，（d）屬性層（Attribute Layer）描述類別屬性與類別關聯，與（e）服務層次（Service Layer）定義類別的運算與物件訊息的傳遞等。
（2）物件導向設計（Object Oriented Design, OOD）階段主要工作是建立以下元件﹕（a）問題領域元件（Problem Domain Component, PDC）它包括初步分析的結果以及細部設計展開的組件，（b）人性互動元件（Human Interaction Component, HIC）類別之間的訊息傳遞以及視窗或選單的介面，（c）工作管理元件（Task Management Component, TMC）定義執行多重控制流程、處理與協調工作單元，提供服務的類別，與（d）資料管理元件（Data Management Component, DMC）定義儲存與讀取的物件、資料庫管理系統與資料庫的關聯表等。
（3）物件導向程式設計（Object Oriented Programming, OOP）階段主要的工作包括物件導向程式的規劃、撰寫與測試等。
綜合以上所述，Coad/Yourdon法提供類別物件圖之靜態模式，動態模式有行為圖描述操作與訊息傳遞、狀態移轉圖、描述簡單演算法與流程之服務圖等。同時，每一個階段與其他階段之間進行資訊回饋，持續進行至資訊系統開發完成為止。

圖四：Coad/Yourdon方法的實施三階段

（6）UP與RUP
圖五是物件導向開發方法的演進過程，自1967年以來，物件導向開發方法一直持續的進展，由於物件導向開發重點在於物件塑模，因此，物件塑膜作業成為物件導向方法應用的重點。一般的作法是採用分治（Divide and Conquer）的手段進行分析工作，描述物件的結構與行為。同時，將一些功能相近的模組或物件等結合成為一個元件，增加物件的再用性。世界級手機大廠意利信公司首先發展出一種物件導向開發方法，它是以使用者個案為中心並以階層化方塊為塑模的依據，此一階段主要貢獻是發展一些靜態觀點的物件模式。1980年國際電話電報顧問委員會（CCITT）制定規格描述語言（Specification and Description Language, SDL）之主要規範，SDL即是第一種物件導向視覺化塑模語言。1987年，Jacobson於斯得哥爾摩創立Objectory AB公司，繼續延伸意利信公司發展的物件導向方法，發表一種新產品即Objectory。基本上，ObjectorySEP是一個涵蓋系統開發流程包括需求、分析、設計、實作與測試等過程，以圖表的方式表現一個資訊系統的物件模式。Objectory是一個程序架構（Process Framework），在實務應用方面，必須修改才能應用到各種不同的軟體開發過程。
1995年，Rational公司收購了Objectory AB公司，Jacobson開始致力於統一Objectory與Rational公司的軟體開發程序的工作。Rational 公司以4+1觀點即邏輯、程序、實體、開發加上使用個案等五個觀點建構一系列的物件模式，它是UP的理論基礎。同時，UP亦使用反覆開發（Iterative Development）的方式做為系統開發的一個重要手段，UP結合瀑布式生命週期法的概念，允許在軟體發生命週期當中進行動態的修正工作。因此，UP是一個開放式之軟體開發流程，而參與此一方法論制定的物件導向專家有Walker Royce, Rich Reitmann, Grady Booch與Phillippe Kruchten等人。1997年，Rational公司發表了新產品 Rational Objectory Process(ROP)即是Objectory與Rational 開發程序的一個綜合版本。其中ROP強化了Objectory 較弱的一環，例如在需求、使用個案、實作、測試、專案管理、部署、設定管理與開發環境等作業。同時，ROP亦引進一套風險分析架構並且定義架構描述（Architecture Description）的規範。此時，三位物件大師 Booch, Jacobson與Rumbaugh已經開始著手於UML的開發工作。
1998年，Rational公司發表RUP（Rational Unified Process）產品，它是由Rational公司開發出來的一種軟體專案開發程序，它是結合Rational Approach 與 Objectory Process發展出來的一種軟體開發模式，由Jacobson 等人在1998年完成RUP模式，由Rational公司持續進行研究與開發，再配合CASE工具的導入與實施。基本上，RUP是一種結合螺旋模式、反覆式與漸進式的軟體開發程序。目前，RUP已經成為一個實務界重要的物件導向開發方法論，對於軟體專案開發活動之影響既深且廣，受到產業界極大的重視。1999年，Jacobson發表了一本新著作即Unified Software Development Process(USDP)， RUP亦持續的進展中。以下擬深入介紹RUP的一些重要概念。
圖五：物件導向開發方法論之演進過程
基本上，RUP應用的四個階段如下所示﹕（圖六）
（1） 初始階段（Inception Phase）
本階段的主要工作是建立一個可理解的完整系統需求與範圍，定義出一些接受的準則與整體風險評估（e.g., 成本、時程與技術等風險, etc.），建立詳細的企業使用個案，並取得專案參予者的共識。
（2） 詳述階段（Elaboration Phase）
階段主要工作是處理設計、實施、測試系統導入等技術方面的工作。同時，考慮技術資源投入、績效與資訊安全等風險以及進行系統規格的製作。
（3） 建構階段（Construction Phase）
本階段的主要工作是建立一個初步可以運轉的系統版本，繼續執行建置工作，產生可以滿足使用者需求之內部版本(版)，最後完成一個功能完整的系統版本（版），並且提供系統安裝服務及支援技術文件的製作。
（4） 轉移階段（Transition Phase）
本階段的主要工作是使用者將資訊系統之使用經驗回饋給系統開發人員，精調（Refine）資訊系統的功能、組態管理與並加強資訊系統的可用性等，並且將開發完成的資訊系統交給客戶來使用，實施教育訓練、支援資訊系統維護與備份等工作。
基本上，RUP的工作流程分為以下九項作業項目：
（一）企業塑模（Business Modeling）
主要工作是建立企業資訊系統的主要需求結構、動機與期望，制定組織共同的努力目標並推導出一個新的企業模型。因此，建構的企業模型必須能夠描述企業組織發展的願景及定義新的企業流程、角色與責任，通常是採用使用個案與物件模式來表示。
（二）需求（Requirements）
主要工作是定義企業流程之作業需求，定義系統範圍、基準線（Baseline）與技術內容做為估計發展一個資訊系統的成本與時程之基準。同時，確定使用者之需求與目標，定義資訊系統之使用者介面等。需求流程的做法是根據資訊系統的目標，將制定的願景轉換為使用者個案模式，制定資訊系統之整體需求、描述應用與細部需求、管理需求的範圍與需求的變更等。
（三）分析與設計（Analysis and Design）
主要工作是將需求轉換成系統設計之規格。基本上，分析與設計主要工作是描述能夠滿足資訊系統目標之作業程序，選擇其中一個最佳可行性方案。在專案進行開發初期須進行強韌分析（Robust Analysis）以確認系統能夠滿足使用者的需求，不斷進行調整與修正工作以符合系統績效、安全、效率與品質的要求。有關強韌分析的作法請詳見本書第十五章的內容。
（四）實作（Implementation）
主要工作是產生資訊系統的程式碼、元件、實作類別與物件，對元件進行單元測試，並將實作的結果整合成一個可執行的系統版本。
（五）測試（Testing）
主要工作是發現軟體的缺點，評估軟體品質是否滿足使用者需求，驗證設計是否滿足規格，實作方面是否具體可行等。同時，針對軟體產品之完整性、一致性與正確性進行整合測試與驗收測試。
（六）配置（Deployment）
主要工作是確認測試合格的軟體在實際環境中是否可以順利執行，並將通過測試的軟體進行包裝、安裝、訓練終端使用者以及將資訊系統移轉至新的作業環境。
（七）組態管理與變更管理（Configuration Management and Change Management）
追蹤與保持專案開發過程之完整性（Integrity），若軟體更新時，必須執行版本管理以保持軟體異動之最新狀況。
（八）專案管理（Project Management）
主要工作是提供專案管理一個基礎架構，做為規劃、執行、訓練、監控專案之實務準則，提供管理風險的分析架構，針對反覆式發展程序、監督專案進度與度量做整合性的管理。
（九）環境（Environment）
主要工作是配置支援軟體開發流程必要之軟體工具，制定適合的企業流程與改善組織績效的技術服務。
（十）工作人員（Worker）
定義專案團隊人員的角色（例如專案經理、分析、程式設計師等）之工作流程、負責工作內容與必備的一些專業技能。
（十一）活動（Activity）
活動是指由一組開發團隊人員來執行與完成一個工作單元，每一個活動皆有其特定之目標與產出(e.g., 文件或原始碼, etc.)，每一個活動可以分配給一些工作人員並且詳細定義工作人員的執行工作項目。
（十二）工作流程（Workflow）
工作流程是一連串的活動組合，產生一些有價值的結果，主要是描述執行活動之順序以及活動彼此間的關係。
（十三）工作產出物（Artifact）
由活動與工作流程所產生的資訊例如企業個案或軟體(文件、系統規格書或原始碼)等。
綜合以上所述，RUP是針對一個軟體專案開發生命週期完整的定義軟體開發階段與核心工作流程，進行反覆式軟體開發工作，快速完成階段性之軟體版本，以漸進方式完成軟體的開發工作，可以大幅度降低軟體開發過程的風險。但是使用RUP方法論時，專案開發人員必須具備一定程度以上的專業能力，嚴格管控階段性的工作項目及產出的系統文件。茲將RUP的特性彙整如下：
1. 反覆式開發（Iterative Development）專案執行的每一個階段中，進行系統開發的主要活動包括需求、分析、設計、實作與測試的作業程序。同時，在專案進行過程中，逐次修正前一個階段的作業內容，使軟體能夠符合客戶的需求以確保資訊系統品質之正確性與完整性。如圖七所示，RUP是採取反覆式與漸進式進行資訊系統的開發工作，統一流程的核心流程包括五個活動為需求、分析、設計、實作與測試，輔助流程包括評估、規劃與專案規格文件製作等，在軟體開發過程中，核心流程與輔助流程彼此是互相合作與交替的進行。

圖六：RUP的開發流程

圖七：反覆式開發流程
2. 使用個案驅動（Use Case Driven）資訊系統開發工作是以使用個案為核心，依序的展開相關的活動圖、類別圖、循序圖、元件圖與部署圖。
3. 以架構為中心（Architecture Centric）將一些常用的系統模組、函數或物件等，建立一些可再用性元件做為軟體設計的基礎架構。
4. 風險驅動（Risk Driven）在進行軟體開發活動以前，進行風險評估工作以降低專案開發失敗的風險。
5. 型態導向流程（Configurable Process）建立每一個專案的型態識別，做為資訊系統開發過程軟體的修改或版本控制的依據。
綜合以上所述，茲將RUP的特性敘述如下:
（1） 開發生命週期¾在軟體開發生命週期中使用UML建立一系列視覺化的工作模型。
（2） 應用領域¾適用在作業、管理、決策支援與崁入式系統的開發工作。
（3） 開發語言與作業平台¾提供物件導向資訊系統之開發語言與標準化作業的平台。
（4） 開發程序¾建立適用在物件導向資訊系統開發過程的統一開發流程，支援軟體開發的一套標準作業程序。
（7）XP
XP（eXtreme Programming）是Beck在1996年發展出來的一種軟體開發技術與軟體工程原則。XP的實施一共有六個階段：（圖八）
(一)探索階段（Exploration Phase）將重點置於發展初步的高階需求，同時，利用雛型法決定資訊系統的整體需求。此階段的主要工作項目如下：
（1）組成一個開發小組 一個專案的主要成員有監督者、輔助者、程式設計師、使用單位代表、客戶與測試人員等。
（2）發展初步的使用需求從使用者觀點，利用劇情故事來描述資訊系統的需求與預期的系統功能。其次，根據描述的劇情來估計資訊系統的開發時間，高階需求是規劃與開發活動的主要依據，在開發過程中，劇情的內容必須真正反應出需求的改變。
（3）建立系統需求的諭示（Metaphor）利用雛型法來定義簡單、高階系統需求的諭示，據以探索潛在系統的架構，諭示可以協助軟體開發團隊人員可以了解系統的需求。
(二)規劃階段（Planning Phase）估計每一項工作的作業時間，決定工作的優先次序，制定工作時程表以及第一個系統版本的工作需求內容。此一階段的主要工作項目如下：
（1）估計開發時程若有超過3週時間的工作，建議加以細分，若少於1週時，建議做合併。若估計工作需求不清楚時，建議利用雛型來協助以降低時程估計的風險與提升估計作業的品質。
（2）安排劇情發展的優先順序依據企業價值決定發展劇情的優先順序。
（3）規劃第一個版本選擇最小、最大價值的劇情作為第一個發展的版本。
(三)版本重複執行階段（Iteration to Release Phase ）利用XP的特定規則與實務作法以重複執行方式來完成第一個版本，平均是 1-3週為一個重複週期。此階段的主要工作項目如下：
（1）進行重複的規劃在每一個重複的週期開始之際，將劇情與失敗的需求重新做規劃，製定一份版本計畫。
（2）確認程式設計的工作開發人員將劇情進行細分的作業，將除錯的工作列入程式設計工作的ㄧ部分，建立劇情的索引卡。
（3）由程式設計師簽名認可與估計需要完成的時間每一個程式設計師自行估計完成預計完成時間。
（4）每日早上舉行專案的會報利用早上的開會時間進行溝通與解決問題。
（5）在整合環境下進行分析、設計、寫碼與測試的工作利用一個共享的程式儲存庫來儲存每一位開發人員完成的程式碼，同時，程式設計師可以利用測試工具來進行單元測試，其他團隊開發人員可以分享這些程式碼。接著就是進行持續的整合工作，將一些發展完成的程式碼放入儲存器，但是這些程式碼均須經過整合性測試工作。
（6）執行XP的例行性工作項目如下：
配對程式設計（Pair Programming）以兩位程式設計師為一個小組參予程式設計工作。
程式設計師使用「類別－責任－合作者」（Class Responsibility Collaborator, CRC）卡簡化程式設計的工作，其中CRC卡主要包含以下三個部份﹕（1）類別名稱類別的名稱、（2）責任類別的資料與行為、（3）合作者與該類別一齊完成責任的其他類別名稱。例如學生的CRC卡資料內容為（1）類別名稱Student，（2）責任Student number, Name, Address, Phone number, Enroll in a seminar, Drop a seminar, Request transcripts，與（3）合作者Seminar。
不斷進行重組（Refactoring）工作，簡化程式碼與消除程式碼的重複現象。
強制性要求每一個程式須符合標準格式的規定，以利開發人員之間的溝通與使用。
執行開發的輪調工作，主要目的是讓軟體開發人員可以熟悉所有相關知識，如此可以減少因人員結構的改變而造成的損失，減少軟體開發人員超時的工作負荷與程式設計作業的瓶頸。
 一週工作時間不超過40小時及2週1次的加班紀錄。
(四)正式上線階段（Productionizing Phase）工作重點在於第一個版本系統層次的確認與驗證工作，並將資訊系統導入在使用部門的作業環境。此一階段的主要工作項目如下：
（1）系統層次的確認與驗證每一個版本發行均要通過嚴謹的測試，經過使用者認可以後，資訊系統正式作業的準備工作才算是就緒。凡是驗收測試均要通過所謂回歸測試，每一個版本重複執行的期，若有發現錯誤時，設法在此一執行週期當中加以解決。
（2）正式進入上線作業新的系統版本一旦進入使用環境時，主要工作項目包括整合、轉換、精調、教育訓練與文件化等活動。
(五)維護階段（Maintenance Phase）將重點置於未完成的需求並將它導入在執行作業環境，XP是將維護工作視為資訊系統開發的一環。此階段的主要工作項目如下：
（1）例行性維護工作每一個劇情的改變須整合到目前的資訊系統，採取重複與漸進式的方式進行維護工作。
（2）產生新的版本新的版本均要通過嚴密的測試才行。
(六)結束階段（Death Phase）進行專案的結束工作，對於專案進行綜合檢討並且整理專案的相關文件。此一階段的主要工作項目如下：
（1）宣佈專案告的結束處理專案結束的作業包括技術、財務、法律與社會等方面的問題。
（2）事後的檢討與文件整理工作以十頁內容製作一份專案檢討報告，文件的內容是精簡的描述專案的工作重點與專案實際執行的經驗等。

圖八：XP的實施流程

6.請詳述物件導向設計的基本原則，請以實例說明之。
【參考答案】：
Martin（1991）提出物件導向設計的一些基本原則﹕
(一) 單一責任原則（Single Responsibility Principles, SRP）
單一責任原則的意涵為：「設計物件類別時，每一個類別只能擔任一個角色，一件工作只允許在一個模組完成，其意涵如同在結構化設計中，要求模組內聚力愈高越好。」單一責任原則的意涵為：「設計物件類別時，每一個類別只能擔任一個角色，一件工作只允許在一個模組完成，其意涵如同在結構化設計中，要求模組內聚力愈高越好。」如圖九(a)所示，Order_Delivery 類別包含不同類別的屬性與操作，只要有更改到屬性或操作的情形，容易造成類別結構的不穩定，根據SRP，吾人可以將它分開成兩個類別Order及Delivery，即可解決上述的問題如圖九(b)所示。SRP主要是利用物件模組化特性，將一些相同屬性與操作的資料集中在某一個類別之中。
圖九：單一責任原則的實例
(二) 開閉原則（Open Close Principles, OCP）
開閉原則的意涵為：「在不需要被更改的情形下被控充。」如圖十(a)所示，未實施OCP以前，類別 Person 擁有兩種交通工具Motorcycle及Bicycle，如果要增加一個新的交通工具時，一定要修改到類別的資料結構，容易造成類別結構的不穩定。根據OCP，吾人可以將它修改為圖十(b)，不論是要增加多少種新的交通工具時，也不會更改到類別的資料結構，可如此即可解決上述問題。為了保持設計彈性，利用多型的概念，將類別功能抽象化，如此即可對於物件類別、模組獲函式之擴充保持開放性，但是對於修改工作能夠維持封閉性。換言之，對於擴充時須改變應用程式時，不必修改模組的程式碼，因此，可以避免單一功能模組變更時，造成相關模組一連串的改變。
圖十：開閉原則的實例
(三) Liskov替代原則（Liskov Principles）
Liskov替代原則的意涵為：「當一個程式使用到父類別時，其子類別也應該可以讓程式所使用。」如圖十一所示，橢圓類別中的兩個屬性 focusA及focusB係代表橢圓的兩個焦點。由於子類別 圓圈是繼承了父類別橢圓的屬性，因此，圓圈也會繼承橢圓的兩個屬性 focusA及focusB，但是圓圈只有一個焦點，因此，focusA及focusB應該是相同的。Liskov替代原則是利用物件的覆載（Override）特性，將focusA與focusB設定為相同的值。

圖十一：Liskov替代原則的實例
(四) 介面分離原則（Interface Separation Principles, ISP）
介面分離原則的意涵為：「使用多個專用的介面比起使用單一個介面要好。」將介面功能獨立於模組之外，使用者可以不必相依於一些利用不到程式。因此，一個模組可以具備高度相關性，在繼承父類別時，盡量減少不必要的類別，以降低子類別需要一些不必要的介面。如圖十二(a) 所示，clientA, clientB, clientC皆共同使用到Service介面，如果有其中一個類別發生變動時，就會影響到Service介面，因此，容易造成類別結構的不穩定性。如果將它修改成圖十二(b)，個別類別只會影響自己的介面而不至於影響到別的介面，例如更改clientA時，只會影響到單一介面 serviceA，並不至於影響到總介面 Service。ISP主要是利用物件的抽象化與實現化的特性，減少下層物件變動所造成的影響。

圖十二：介面分離原則的實例
(五)相依反轉原則（The Dependency Inversion Principles, DIP）
相依反轉原則的意涵為：「依賴抽象，不依賴具體。」一種依賴或是抽象化方法及類別的設計策略，而不是依賴具體的類別或具體的作法，在元件化設計的作法經常使用到COM, CORBA, EJB等元件即是採取DIP的作法。如圖十三(a)所示，在具體事物經常改變的情形下，容易造成資訊系統架構的不穩定性，如果將它改變為圖十三(b)時，即可解決上述依賴游移性（Volatile）元件造成程式的不穩定的現象。

圖十三：相依反轉原則的實例

7.解釋名詞
【參考答案】：
（1）封裝
封裝（Encapsulation）的意涵是指：「將物件的資料與方法包裝成一個物件。」因此，物件與外部物件傳送訊息時，可以不必考慮該物件的內部結構與行為。而資訊隱藏（Information Hiding）的作法是將物件內部的一些細節予以隱藏起來，讓外部的物件無法直接進行存取，必須透過程式的訊息傳遞才能進行修改的動作，主要目的是保護物件內部資料的安全性，如圖十四所示。一般而言，經過封裝的物件有兩個部分，其中一個是介面，定義物件與外界溝通之行為，另外一個是實作部份，定義抽象化之描述及如何執行與外界進行訊息傳遞之動作。封裝的優點是簡化物件與外界溝通的作業程序，物件可以不受外界的干擾，使物件的維護工作更為容易進行，例如各位讀者觀看電視時，經常使用的遙控器就是一個封裝的實例，當您按下其中一個按鍵時，這一個動作實際上是執行一系列複雜的操作指令，物件的操作與訊息傳遞動作是持續進行的，一直到所有指令均執行完畢為止，因此，封裝對系統的外部使用者而言，具有高度的實用性、經濟性與方便性。

圖十四：封裝的概念

（2）多重繼承
一個類別允許有一個或多個父類別，如果子類別繼承了多個父類別的特性，稱之為「多重繼承」（Multiple Inheritances），如圖十五所示，兩棲動物繼承了 “陸上動物” 與 “海上動物” 的特性。由於物件的繼承特性大幅度的增加物件的再用性、減少資訊系統的總成本、降低開發過程之風險與縮短開發的時程，全面提升軟體設計的生產力與品質。

圖十五：多重繼承的實例

（3）多型
多型（Polymorphism）的定義為：「一個物件對於不同形式的訊息可以依據本身的特性來給予不同的回應。」當不同物件進行相同操作時，可以定義多種不同方法來執行不同的處理內容，將不同方法整合成一個操作，由執行程式來判斷呼叫物件的作法稱之為「多型」。
（4）多載
多載（Overloading）定義為：「同一類別可以使用相同操作名稱，但是可以定義不同的參數。」換言之，子類別可以使用相同的操作名稱，重新定義多個參數型態。
（5）覆載
覆載（Overriding）子類別可以使用相同操作名稱，將父類別定義過的方法重新定義自己的方法。
（6）抽象化
抽象化（Abstraction）的意涵是指：「將物件的重要特性加以淬取出來，以圖形或數學公式予以表現出來的一個過程。」一般而言，抽象化是從功能的觀點，將事物的屬性與操作等重要特性予以淬取出來，將注意力集中在相似性（Similarity），忽略其中的細節並且進行系統化的分類活動。因此，抽象化是針對物件的特性、狀況與流程之相似性，經由抽象化的過程有助於一個系統的描述、分析與設計工作的進行。
（7）階層化
階層化（Hierarchy）的意涵是指：「將物件進行定義、分類、排序，使一些物件之特性相近者加以聚合而達到有效管理的目標。」基本上，階層化的分類方式有一般化與組成兩種關係。一般化的關係是屬於一種類別(a kind-of)的關係，如圖十六所示，汽車有轎車、巴士兩種類型，轎車可以細分為吉普車、房車與箱型車，巴士可以細分為大型巴士、中型巴士與小型巴士。另外一種是組成的關係，它是屬於一種元件組成(a part-of)的關係，如圖十七所示，汽車是由車身與底盤兩種零件所組成，其中底盤是由引擎與懸吊系統所組成，車身是由車窗與車門所組成。階層化的目的是將一群的物件做有系統的分類與管理。如此可以簡化物件的類別，使物件類別的數目大幅度減少，提升物件類別的處理效率。


圖十六：汽車的類型 一般化的應用實例


圖十七：交通工具的類型組成的應用實例