• 沒有找到結果。

物件導向分析與設計方法

物件導向(Object-Oriented, OO)方法是以物件(Object)為中心,

結合了資料結構及行為的離散物(Discrete object),作為其組成的元 件,而物件與物件間則透過訊息的交換傳遞,相互影響其行為,以共 同完成某項目的。所強調的是物件及系統的可再利用、可擴充性及易 於維護等特性。一般來說,使用物件導向方法有以下之優點:

1. 可將真實世界中使用者所實際看到與接觸的物件,均視為資訊系 統的一個物件,因此不會產生分析者與使用者之間認知上的差異。

2. 物件導向方法將真實世界中,屬於或存在於物件中的資料及操 作,全部封裝(Encapsulation)於物件中,因此物件導向方法即兼具 有程序導向方法及資料導向方法之優點。

3. 運 用 物 件 導 向 方 法 進 行 系 統 設 計 時 是 採 用 物 件 分 解 (Object decomposition)觀念,每個企業物件可直接對應到軟體物件,讓使 用者能容易瞭解軟體的特性,也易於偵錯改正,使調整或抽換之 彈性大幅提昇。

物件導向的觀念,傳統上常運用於物件導向程式設計、使用者介 面等技術層次上,其觀念也延伸到系統的分析、設計方面,使系統發 展方法能全面採用物件導向觀念,提高無縫性,以提升系統品質。而 著名物件導向方法論介紹如表 2-4 所示:

表 2-4 物件導向方法論

方法 概述 Booch Method 以類別圖、物件圖、模組圖及程序圖來分析系統的靜態面,以

狀態轉移圖及時序圖來表現系統的動態面。

OOSE

以使用案例及外部行為者間互動關係來表達系統的需求,並分 別以介面、實體、控制三大類別來描述系統,其發展程序包括 分析、構建及測試等階段。

OMT 以三個模型來描述系統,分別是物件模型、動態模型及功能模 型,主要的進行程序為分析、系統設計、物件設計及實作。

UML 為整合 Booch 與 OMT 方法,透過各種圖示,從結構及行為等角 度來表現系統的靜態及動態的作業流程

2-4.1 Booch Method

布希(Booch)的物件導向方法論在 1986 年提出,以四種模型及 六種圖是來表示系統的動態及靜態行為,依照邏輯的程序,做一完善 的系統設計。

此外,布希(Booch)的方法論還提供(1)多模式化工具,具有 完整的文件。(2)各種活動的產出和機制。(3)發展步驟明確,且無 間隙性。等優點,但其缺點是圖示工具較為複雜。

2-4.2 OOSE

物 件 導 向 軟 體 工 程 ( Object-Oriented software Engineering, OOSE)是由 Ivar Jacobson 所提出,將整個流程於以模式化,採取「使 用個案(User-Case)」來記錄使用者對系統的需求,並分別以介面、實 體、控制三大類別來描述系統。

「使用個案」將每一個使用者視為一個行動者,當行動者引發系

統執行某項任務時,會發生一連串與系統有關的處理,將這些處理記 錄下來即為「使用個案」。

2-4.3 OMT

物件模式技術 OMT(Object Modeling Technique)針對系統所要處 理的資料、軟體時,所採用的演算方法或程序,以及系統與外界相關 環境的互動關係,提供了物件模型、動態模型和功能模型,分別以三 種不同的角度分析系統,執行程序如圖 2-4 所示。

首先,由使用者、管理者、領域專家、開發者不斷的對問題進行 描述並不斷的更新,直到符和系統真實的需求為止。再來,則把問題 的描述建立成靜態的物件模式,表現物件交互作用的動態模式,與表 示物件內資料轉換的功能模式。最後,藉由分析而得到的類別、屬性 及關連,轉換成電腦領域的資料結構。

產 生 需 求

結 構 及 物 件 設 計 建 立 模 型 使 用 者

知 識 領 域 專 家 管 理 者 發 展 者

使 用 者 訪 談

發 展 者 管 理 者 經 驗 知 識 領 域 專 家

設 計 師

網 路 工 程 師 資 料 庫 管 理 師

系 統 設 計 師

問 題 描 述

物 件 模 型 、 動 態 模 型 、 功 能 模 型

詳 細 的 物 件 模 型 詳 細 的 動 態 模 型 詳 細 的 功 能 模 型

圖 2-4 OMT 系統分析與設計程序圖

2-4.4 UML

統合模式化語言 UML(Unified Modeling Language)則是集結 了 Booch、OOSE、OMT 三大觀念,而延伸的整合模式語言,在 UML 中提出了五個觀點,如圖 2-5 所示,其功能如表 2-5 所示。

圖 2-5 UML 的五大觀點

表 2-5 UML五大觀點功能

觀點 功能

使用個案觀點 描述系統功能性需求,找出使用個案與

行動者。

邏輯觀點 描述系統內部功能性作業的細部設計,

包過靜態結構和動態行為。

實作觀點 描述系統如何切分成軟體元件,進行實

作。

處理觀點 描述系統各組成部分整體運作的程序。

配置觀點 描述系統硬體或設備間的連結關係,及

軟體程序的配置情形。

除五大觀點外,UML 還提供了九種圖形來描述使用者與系統間 靜態與動態的作業行為,圖形歸類如圖 2-6 所示,圖形之功能描述於 表 2-6 所示。

循 序 圖

模 式

合 作 圖

靜 態 圖

活 動 圖

使 用 案 例 圖 類 別 圖 物 件 圖 元 件 圖 部 屬 圖

靜 態 觀 點 動 態 觀 點

圖 2-6 圖形之靜態與動態

表 2-6 UML的圖形功能

名稱 功能 Use Case diagram 敘述一個系統的功能, 以及此系統的使用者(不一定指

人).

Class diagram 描述一個系統的靜態結構, 或是如何建立此結構,而非他 的行為.

Object diagram

描述某一特定時刻系統的靜態結構, class diagram 描述 的是所有可能情況, object diagram 描述的是一個特定情 況.

State diagram 敘述一個類別的狀態(state)與回應(response), 它描述 一個類別對於外來刺激的反應.

Sequence diagram

敘述物件之間的互動關係, 這些關係被模組化為 message 的交換, 這些圖所關住的焦點在 class 及它們所交換的 message, 藉以達成某些預期行為.

Collaboration diagram

敘述 class 與結合關係之間的互相作用, 這些互相作用被 模組化成類別之間的訊息交換, 而訊息的交換是藉由類別 之間的結合關係來進行.

Activity diagram

敘述一個 class 的活動, 這些圖型類似 state diagram, 而且也使用相似的慣例, 但 activity diagram 所描述的 是一個 class 回應內部處理的行為, state diagram 則是 描述回應外部事件的行為.

Component diagram

敘述軟體實作 component 的組織結構及其相依關係, 這些 圖型包括 component, component 表示可拆散的實體單位, 包含 source code, object code, 及可執行程式碼.

Deployment diagram

敘述處理資源元素的組態(configuration), 以及軟體實 作 component 的對應方式, 這些圖型包含了 component 與 node, node 表示一種處理或計算的資源(resource),

圖 2-1 價值鏈流程類型 ...10 圖 2-2 ARIS 架構圖 ...13 圖 2-3 e-EPC 之示範圖...14 圖 2-4 OMT 系統分析與設計程序圖 ...19 圖 2-5 UML 的五大觀點 ...20 圖 2-6 圖形之靜態與動態 ...21 表 2-1 重現方法 ...9 表 2-2 IT 目標工具矩陣表 ...15 表 2-3 企業導入資訊管理系統之方式 ...16 表 2-4 物件導向方法論 ...18 表 2-5 UML 五大觀點功能...20 表 2-6 UML 的圖形功能...21