中 華 大 學

中 華 大 學 碩 士 論 文

題目：物件導向式電子商務平台之建模與實作方法 Object-Oriented E-Commerce Platform

Modeling and Implementation Method

系 所 別：資訊工程學系碩士班 學號姓名：M09202007 曾苑菁 指導教授：曾秋蓉 博士

中華民國九十四年七月

摘要

隨著網際網路的蓬勃發展，上網人數不斷增加，伴隨許多網路商機的興起。為了因 應此趨勢，許多企業紛紛成立電子商務網站，網路交易版圖成為各企業體必爭之地。

為了滿足網路族群喜愛嚐鮮的心理，以搶佔網路購物的市場大餅，靈活的行銷策略 以及多變化的促銷手法是經營電子商務成功的重要因素之一。這些行銷策略及促銷手法 的實現，都必須透過修改網站程式或是擴充網站功能來達成。然而一般傳統電子商務平 台的建構方式多為程序導向式，不僅程式維護不易，且功能擴充耗力費時，無法在多變 的網路環境中取得競爭優勢。

本研究提出一套“物件導向式電子商務平台之建模與設計方法”，期望藉由將電子商 務平台設計方式規格化、模組化，物件化，使得以此方法開發出的電子商務平台在管理、

維護及擴充上更為容易；並進而以此方法達成物件共享、再利用的目的。

透得本論文所提出之方法，可使得電子商務平台的開發與維護更為快速，提升電子 商務的競爭力。

關鍵詞：物件導向、電子商務、網站分析、網站設計、網站建模

Abstract

With the rapid growing of World Wide Web (WWW) technologies, a lot of business opportunity is raised on the Internet. In such a trend, the development and maintenance of e-commerce platforms become an important issue.

To keep network shoppers active, new promotion methods should be continuously introduced in a successful e-business, which results in frequent updates of E-commerce site.

Traditional e-commerce platforms are mostly designed by procedure-oriented method. Under such a design, different functional modules may use the same database tables. The web sites are hard to be maintained and expanded as modifying one module may causes errors occurred in another module.

This thesis proposes an Object-Oriented E-Commerce Design and Modeling method (abbreviated as OOECDM), which utilizes the three advantageous properties of object-oriented design: encapsulation, inheritance and polymorphism, to shorten implementation, maintenance and expansion of an e-commerce platform. Implementation techniques are also given for mapping the object-oriented design to real web programs.

Although the design cost is higher, preliminary experiments show that the implementation and maintenance cost of object-oriented design is lower than the traditional procedural design. As the design process is only a one-time job, OOECDM is advantageous in its high maintenance efficiency, which promotes the competitiveness of e-businesses.

Keywords：Object-oriented, E-commerce, Web analysis, Web design, Web Modeling, Web engineering

致謝

由青澀到成熟，由無知到一篇論文的完成和發表。首先要感謝我的指導老師－曾秋 蓉教授對我孜孜不倦的教誨，於問題思考方向的啟發，以及專業知識觀念的引導，並感 謝學弟學妹的協助，讓本篇論文得以完成。論文的完成對我來說，象徵著由一位研究生 的角色轉換成一位社會新鮮人，是結束也是開始。結束學生的生涯，開始嶄新的社會歷 練，欣喜也帶點膽怯。

在研究進行的過程中，不僅使我在學術領域上有所成長，也從老師身上學到許多做 學問的態度與方法。而在這段日子裡，要感謝的人很多，感謝系上老師的細心教導；感 謝實驗室夥伴的互相幫忙；感謝好友的鼓勵與安慰。最後要感謝家人一直在我背後默默 地支持著我。尤其是我的父母，您們的支持與鼓勵，是引導我前進的最大動力;您們的 包容與體諒，讓我能專心致力於研究上無後顧之憂。感謝是源於內心，而我會將在校所 學，實際的貢獻於社會與職場中，絕不讓大家失望。

目次

摘要...i

Abstract ...ii

致謝... iii

目次...iv

表目錄...vi

圖目錄...vii

第一章 緒論...1

1.1 研究背景...1

1.2 研究動機...2

1.3 研究目的...3

1.4 論文架構...4

第二章 相關文獻探討...5

2.1 物件導向系統分析設計方法...5

2.2 超媒體設計方法（HDM） ...6

2.3 關係管理方法論（RMM）...7

2.4 強化物件-關係模型（EORM）...8

2.5 物件導向超媒體設計方法（OOHDM） ...10

2.6 劇本為基礎的物件導向超媒體設計方法論（SOHDM） ... 11

2.7 超媒體設計方法之比較...13

第三章 物件導向式電子商務平台之建模方法（OOECDM） ...14

3.1 物件導向式電子商務平台之建模方法簡介...14

3.1.1 系統需求分析...15

3.1.2 概念模型設計...17

3.1.3 導覽模型設計...20

3.1.4 系統介面設計...23

3.2 概念模型之組成架構...25

3.3 概念模型之繼承架構...25

3.4 概念模型之多型架構...26

3.5 應用實例...29

第四章 物件導向式電子商務平台之實作方法...37

4.1 ASP.NET 平台介紹...37

4.2 組成架構之實作方法...39

4.3 繼承架構之實作方法...41

4.4 多型架構之實作方法...42

4.5 應用實例...43

4.5.1 系統開發環境...44

4.5.2 組成架構實作成果...45

4.5.3 繼承架構實作成果...47

4.5.4 多型架構實作成果...49

第五章 實驗分析與探討...54

5.1 實驗設計...54

5.2 實驗成果...55

5.3 實驗探討...57

第六章 結論與未來展望...58

6.1 結論與貢獻...58

6.2 未來研究方向...58

參考文獻...59

表目錄

表 2.1 超媒體設計方法之比較...13

表 4.1 開發環境列表...44

表 5.1 實驗設計...54

表 5.2 實驗結果...55

表 5.3 超媒體設計方法比較表...57

圖目錄

圖 2.1 RMM 之架構...7

圖 2.2 EORM 之架構 ...9

圖 2.3 OOHDM 之架構 ...10

圖 2.4 SOHDM 之架構 ...12

圖 3.1 電子商務平台之系統開發流程圖...15

圖 3.2 線上購物網站之使用案例模型...16

圖 3.3 線上購物之循序圖...17

圖 3.4 線上購物網站之概念模型...18

圖 3.5 線上購物網站管理平台之概念模型...19

圖 3.6 線上購物網站導覽模型之類別架構...22

圖 3.7 線上購物網站導覽模型之脈絡架構...23

圖 3.8 線上購物網站商品介紹物件之介面設計...24

圖 3.9 線上購物網站訂購系統物件之介面設計...24

圖 3.10 組成架構圖...25

圖 3.11 會員系統...26

圖 3.12 訂購系統...26

圖 3.13 查詢資料之多型架構...27

圖 3.14 新增資料之多型架構...28

圖 3.15 修改資料之多型架構...28

圖 3.16 刪除資料之多型架構...29

圖 3.17 完整購物網站之使用案例...30

圖 3.18 完整購物網站之循序圖...31

圖 3.19 完整購物網站之概念模型...32

圖 3.20 完整購物網站管理平台之概念模型...33

圖 3.21 完整購物網站導覽模型之類別架構...34

圖 3.22 完整購物網站導覽模型之脈絡架構...35

圖 3.23 完整購物網站購物車之介面設計...35

圖 3.24 完整購物網站最新消息之介面設計...36

圖 3.25 完整購物網站電子報之介面設計...36

圖 4.1 會員系統物件...45

圖 4.2 商品系統物件...46

圖 4.3 訂購系統物件－填寫付款資料...47

圖 4.4 購物網站首頁...48

圖 4.5 固定式公告系統...49

圖 4.6 會員管理系統查詢會員物件之查詢畫面...50

圖 4.7 會員管理系統查詢會員物件之查詢結果...51

圖 4.8 訂單管理系統查詢訂單物件之查詢畫面...52

圖 4.9 訂單管理系統查詢訂單物件之查詢結果...53

圖 5.1 購物車物件...56

圖 5.2 暢銷商品排行榜...57

第一章 緒論

隨著網際網路的興起，各企業在電子商務上競爭激烈，為了滿足網路族群喜愛嚐鮮 的心理，以搶佔網路購物的市場大餅，靈活的行銷策略以及多變化的促銷手法是經營電 子商務網站成功的重要因素之一。為此我們提出一個物件導向式電子商務平台之建模與 實作方法，希望能透過此方法，加速電子商務平台擴充新功能的時間，並且簡化系統管 理、維護之困難；進而以此方法達成物件共享、再利用的目的，使得新電子商務平台的 開發與維護更為快速，能在多變的網路環境中取得競爭優勢。

在接下來的幾個小節裡，我們將在 1.1 節研究背景中，說明目前電子商務平台之近 況；在 1.2 節說明研究動機，針對電子商務平台之特性做一分析，並描述其遭遇到的問 題與瓶頸；1.3 節研究目的，主要強調本篇論文的研究重點以及貢獻；最後將對本論文 之架構做概略性的說明。

1.1 研究背景

根據資策會[52]最新的調查顯示，截至 2005 年 3 月底為止，我國寬頻網路用戶數 達 371 萬戶，較上一季增加約 11 萬戶，成長率達 3%；經常上網人口達 925 萬人，網際 網路連網應用普及率為 41%；依據統計資料顯示，我國商用網際網路帳號總數（不包括 學術及政府網路用戶）於 2005 年 3 月底達 1,192 萬戶，較上一季增加 70 萬戶，成長率 達 3%，顯示網際網路市場十分活躍。

由於網路的普及與發展，上網人數不斷的持續增加，有利於電子商務的蓬勃發展。

網際網路快速發展，造就網路的普及與寬頻時代的到來，也使得網路交易日趨頻繁。網 路交易不受時間與空間限制，為企業帶來新的商機。透過網路交易不僅能大大節省消費 者出門購物所花費的時間，也能為企業省下許多經營管銷的成本。同時，透過網路能快 速提供最新的訊息給消費者，也能提升良好的企業形象。

根據經濟部商業司表示，1999 年我國網路購物只有 16.3 億的市場規模；在 2003 年我國 B2C 市場規模達 220.9 億。於 2004 年，網路市場規模已達 347.2 億元，短短的 5 年時間，成長超過 20 倍。可見上網人數飆漲時，網路交易市場的規模亦直線成長，顯 示國內消費者在網路購物的習慣正逐漸養成，一旦市場成熟時，爆發力將不容小覷！

入口網站蕃薯藤公佈 2003 年網路大調查，國內上網人口的年齡層更寬廣，購物經 驗、頻次及金額等均呈明顯上揚。2003 年有網路購物經驗的網友從 57％提高到 64％，

購物頻次在半年內購物超過 7 次的網友佔 33％，比 2002 年的 13％增加 20％，半年內 網路購物總金額 1 萬元以上也從 2002 年的 18％增加到 2003 年的 26％，顯示未來網路 購物商機將會是持續高度成長。

由以上之調查結果可知電子商務商機還有很大的成長空間，為了因應此潮流，許多 企業紛紛成立電子商務網站，網路交易版圖成為各企業體必爭之地。在電子商務成為 E 世代重要消費模式的趨勢之下，電子商務平台的開發及維護便成為一個重要的課題。

1.2 研究動機

為了滿足網路族群喜愛嚐鮮的心理，以搶佔網路購物的市場大餅，靈活的行銷策略 以及多變化的促銷手法是經營電子商務網站成功的重要因素之一。因此網站經營者必須 要構思一些與眾不同的回饋或消費方式，吸引消費者的注意，並且引起購買的興趣，來 達到經營電子商務的最佳成果。目前網路上的行銷機制大部份都與傳統商場上實施的行 銷手法相同，沒有創新與吸引更多顧客的動能，有些甚至並不適用於網路消費，不僅無 法增加網站的營收，並可能會讓網站受到不良的評價，導致商譽受損。

由於網站架設的成本、進入障礙及消費者的忠誠度均較傳統商店低，使得電子商務 網站間的競爭非常劇烈，競爭環境也變化迅速，因此網站經營者必須快速地即時推出各 種新的行銷對策，以便在此環境下脫穎而出。然而這些行銷策略及促銷手法的實現，都 必須透過修改網站程式或是擴充網站功能來達成。

但一般傳統電子商務平台的建構方式多為程序導向式，不僅程式維護不易，且功能 擴充耗力費時，因此常使得傳統電子商務平台無法在多變的網路環境中取得競爭優勢。

例如：在程式維護方面，當資料庫伺服器移動 IP 位址或是資料庫名稱修改時，必須將 所有連線到資料庫的程式同步修改，如此需要修改的程式將會非常多，同時若是有未改 到的部份，則會使得程式無法存取資料庫的資料，而發生錯誤或無資料顯示之情形。在 功能擴充方面，如原先在查詢訂單資料時，已將連結資料庫和查詢訂單資料之程式開發 出來。在新增暢銷商品排行榜的功能時，必須重覆撰寫連接資料庫和查詢商品訂單資料 之程式，不但開發需要較長的時間且必須同時維護 2 份程式非常麻煩。以上問題皆因傳 統程序導向式設計方法之程式與資料混合撰寫，缺乏封裝之概念，並且無法將已開發之

程式發揮其重覆再使用的優點。因此本論文希望藉由目前程式設計方法最常用的物件導 向概念來分析與設計網站，希望由此來改善傳統電子商務平台之缺點。

目前國內外有許多用來協助網站分析與設計之相關研究，但大多缺乏繼承和多型之 概念，無法充分發揮物件導向觀念中對原有物件之重複使用（Reuse）的優點。

為了加快電子商務網站更新以及擴充功能的速度，我們應用近年來在軟體工程領域 廣為使用的物件導向觀念及技術，提出一套電子商務平台的建模與實作方法，期望能突 破目前電子商務平台在開發及維護上所遭遇的困境。

1.3 研究目的

本研究的主要目的為提出一套“物件導向式電子商務平台之建模與實作方法”，期望 藉由將電子商務平台設計方式規格化、模組化，物件化，使得以此方法開發出的電子商 務平台在管理、維護及擴充上更為容易；並進而以此方法達成物件共享、再利用的目的，

使得新電子商務平台的開發更為快速。

根據軟體工程在物件導向技術上的研究[4][30][44]，發現物件導向化有以下幾個特 點：

z 利用“封裝＂（Encapsulation）概念將程式模組化 z 模組間利用訊息（Message）做溝通

z 增加系統功能只需新增模組及訊息傳遞，系統擴充容易 z 以模組為單位維護系統，維護成本低廉

z 物件可重複使用，開發新應用快速

本研究從物件導向的角度來審視電子商務平台的分析與設計，並針對電子商務平台 的需求提出一套完整的物件導向模型。不同於以往的相關研究[7][10][28][31][32][34][37]

多半僅利用到物件導向封裝的特性，本研究除基本的封裝之外，亦利用到物件導向繼承

（Inheritance）以及多型（Polymorphism）的特性來建構整個電子商務平台的分析與設 計模型，使其更能發揮物件導向分析與設計的優勢。

一般概念模型的建構方法常會面臨無法與實作環境對應，導致程式設計師必須同時 維護概念模型與所撰寫之程式，徒增維護程式時之困擾。本論文除了提出一套完全物件 導向化的電子商務平台建模方法之外，同時也提出一套實作方法可實現本論文提出之建 模方法所設計出之概念模型。

為了驗證此發展程序之可行性，本研究以開發一個購物網站為例進行實作，證明此 發展程序配合 UML 之應用，可幫助系統開發人員釐清系統間之物件行為，並開發出具 有物件導向特性之電子商務平台。

1.4 論文架構

本論文分為六章，其內容架構如下所述：

z 第一章為緒論，簡單說明本篇論文研究背景、研究動機與目的及論文架構。

z 第二章為相關文獻探討，主要是先介紹物件導向的基本概念，並對目前常見的網站 分析與設計方法之相關研究各別做說明，最後根據電子商務平台最重要也最常用之 目的－快速擴充與更新，整理出每種方法的對其目的之優缺點分析。為了達到這些 目的，我們提出ㄧ個新的電子商務平台之建模與實作方法，以因應電子商務靈活變 化的特性。

z 第三章為物件導向式電子商務平台之建模方法，本章為此論文的核心所在，將介紹 物件導向式電子商務平台之建模方法的分析設計步驟，並詳細說明本研究方法之主 要延伸架構，最後以一應用實例對此方法做一完整性的分析與設計。

z 第四章為物件導向式電子商務平台之實作方法，以ASP.net網站開發平台為開發環 境，詳細解說本研究分析與設計方法之結果與實作程式之對應及轉換。

z 第五章為實驗分析與探討，本章將透過先前分析與設計方法實作出一線上購物網 站，並以實驗來驗證本研究方法之實施效率，最後對本實驗結果進行評估和探討。

z 第六章為結論，將整個論文做個總結，包含結論與貢獻及未來研究方向。

第二章 相關文獻探討

由於現在網路的發展趨勢，Web 已成為應用程式的重要發展平台，為了提升 Web 程式開發的效率，目前國內外有許多用來協助網站分析與設計的方法與工具，本節將介 紹與本文相關之研究。本文以物件導向為基礎，首先先在 2.1 節介紹基本的物件導向系 統分析設計方法，之後會針對目前網站分析與設計方法之相關研究個別做一說明，如 2.2 至 2.6 節。其中 2.2 節將介紹超媒體設計方法（HDM）；2.3 節介紹關係管理方法論

（RMM）；2.4 節介紹強化物件-關係模型（EORM）；2.5 節介紹物件導向超媒體設計方 法（OOHDM）；2.6 節介紹劇本為基礎的物件導向超媒體設計方法論（SOHDM），最後 將在 2.7 節做一比較分析與總結。

2.1 物件導向系統分析設計方法

物件導向系統分析設計方法（Object-Oriented Analysis/Object-Oriented Design，簡稱 OOA/OOD）是一套以重複使用為基礎的系統分析、設計及程式製作一氣呵成的方法。

物件導向分析（OOA）較著名的方法有物件建模技術（Object Modeling Technique，

簡稱 OMT）[30]、Booch Method[4]、Schlaer-Mellor Method[44]及使用案例分析（Use Case Analysis）等等。這些方法除了使用案例分析之外，其他的方法大體上都是以物件模型

（Object Modeling）為主，再輔以動態模型（Dynamic Model）及功能模型。其中物件 模型是用來描述真實世界的靜態關係，所談的內容是物件、物件及物件之間的關係，如 組成關係、繼承關係、多型關係或其他各式關係。

一般而言，物件導向模型應該具備下列三種特性[4][30][44]：

1. 封裝（Encapsulation）

封裝是把資料和處理資料的方法包裝起來建立成物件。封裝將物件的實作細節隱 藏，使其與外界環境隔離，而只允許該物件所包含之操作修改其資訊，稱為資訊隱藏

（Information Hiding）。使用物件時，僅需知道物件提供何種操作，而不需知到其內部 之資訊或行為是如何表達或執行。外界之物件僅能透過訊息傳遞要求該物件提供服務，

而無法逕自改變該物件之資料內容。封裝之特性使物件導向的系統較容易維護。

2. 繼承（Inheritance）

繼承是類別間之關係，在此關係中某類別之資料結構與行為可供其關係中之類別分 享。繼承是物件的再利用，當定義好一個類別後，其它類別可以繼承這個類別的資料和 方 法 ， 並 且 新 增 或 取 代 繼 承 物 件 的 資 料 和 方 法 。 繼 承 之 特 性 可 利 用 一 般 化

（Generalization）與特殊化（Specialization）的原則，萃取相關子類別（Subclass）的相 同屬性和操作，並將之歸類為一個父類別（Superclass）來達成。在物件導向技術中，

繼承概念之運用對軟體工程有革命性之影響，如達成程式碼再用（Reuse）與減少重複 描述，產生可靠度較高的軟體等。

3. 多型（Polymorphism）

即利用相同的操作，以不同的方式處理不同類別的資料，或者送訊息的物件不須知 道接受訊息的物件所屬的類別，接受訊息的物件可屬於任一類別。運用多型之特性在程 式設計上，可允許不同的物件定義相同的操作名稱，當程式執行時依動態連結（Dynamic Binding）的方法，判斷訊息參數的種類與類型來決定運作的物件。運用多型之目的是 希望以相同的介面來處理不同的物件，以簡化系統發展的複雜性並增加其彈性。

一個同時具備封裝、繼承、以及多型這三種特性的物件導向分析與設計模型，才能 充分發揮物件導向的優點，達成百分之ㄧ百的物件化。

2.2 超媒體設計方法（HDM）

超媒體設計方法（Hypermedia Design Model，簡稱 HDM）[12]是由 Garzotto et al. 於 1993 年首先提出的，為超媒體設計方法之先驅。其設計方法的概念模型中包含了許多 的實體（Entities），也就是一些資訊區塊（Information Chunks）的結構。一個實體表示 在領域（Domain）裡的一個物質或是一個概念上的物件，為一個應用中最基本的自主

（Autonomous）單位。實體可以根據不同的特性分為不同的種類，而實體本身代表一 個由元件（Components）所組成的階層架構（Hierarchy），其中每一元件則是由基本單 位（Units）所構成。

HDM 首先提出了「觀點」（Perspectives）的概念，強調若一個實體有若干相關的觀 點，則其組成元件也因此都有其觀點，而一個基本單位便是一個元件針對一個觀點所表 達的部分，並且最後會對應到超媒體中的網頁。當以上模型完成後，可以根據超媒體所 定義的連結（Links）和開發者的設定，如瀏覽語意（Browsing Semantics），將概念模型 中各個單位和其間的各種關係產生各種不同的連結。藉由抽象化機制，設計者只需定義

階層架構一次，再定義數種觀點，即可自動產生數個相互連結的導覽結構；且經由設計 者自行定義的判斷式也可以自動導出其他所需的連結。

2.3 關係管理方法論（RMM）

關係管理方法論（Relationship Management Methodology，簡稱 RMM）[14]，由 Isakowitzs et al. 於 1995 年提出，其特點是同時可具有由上而下（Top-down）及由下而 上（Bottom-up）的作法，並使用七個步驟來設計及建構超媒體應用軟體，其架構如下 圖 2.1。

圖 2.1 RMM 之架構

Information / Navigation

Requirements Analysis

E-R Design

Entity Design

Navigation Design

Conversion Protocol

User-Interface Screen Design

Construction

Testing and Evaluation

Requirement document

ER Diagram

ER + Diagram

RM Diagram

RM + Diagram Conversion rules

Screen Design

Hypermedia Application

Focus of RM Methodology

Run-time Behavior Feasibility

Feasibility document

Hardware

Hardware Choice

Needs Objectives

Market / User Analysis Information

Source / Permissions Media Used

Distribution Channels Cost-benefit Analysis

其流程為: 實體－關係設計（Entity-relationship Design）、實體剖面設計（Slice Design）、導覽設計（Navigation Design）、轉換協定設計（Conversion protocol Design）、

使用者介面設計（User Interface Design）、執行時期行為設計（Run-time Behavior Design）、和建構與測試（Construction and Testing）。其對於應用軟體的設計主要是以實 體－關係模型（E-R Model）、超媒體設計模型（Hypermedia Design Model，HDM）、和 關係管理資料模型（Relationship Management Data Model，RMDM）來表示。

首先在實體－關係設計步驟中，實體及關係將被識別出來成為超媒體應用軟體中的 節點（Nodes）及連結（Links）。第二步－實體剖面設計，將決定如何呈現出第一步驟 中的實體來，而根據實體的屬性分群。每個實體剖面（Slice）會以超媒體應用軟體的一 個頁面出現，也就是「呈現的基本單位」（Presentation units）。下一步導覽設計則識別 出超文件的瀏覽路徑。在關係管理資料模型（RMDM）步驟是以基本存取指令（Access Primitives）來確定超媒體應用軟體的導覽方向，基本存取指令包括：連結（Links）、分 群組（選單）（Grouping（Menus））、索引（Index）、和引導瀏覽（Guided Tour）。轉換 協定設計是要把關係管理資料和實體－關係模型中的元件（Components）轉換成標的超 媒體應用軟體中的實存物件。使用者介面設計則重視每個模型中元素在網頁上的排列佈 置（Layout）。這些元素包含：基本存取指令、連結錨點（Link Anchor）、索引（Index）、

和一般導覽協助（General Navigational Aid）。RMM 所提出的使用者介面設計技巧主要 是在發展原型（Prototyping）。

RMM 的使用有助於 Database-Driven 類型 Web 應用程式的開發與維護。然而，RMM 沒有提供能適當表達企業邏輯及控制流程的機制。如同許多其他的軟體設計方法與設計 圖表示法一樣，RMM 的設計分析圖與實作程式碼是以不同形式分別存在，因此沒有辦 法避免設計分析圖形與程式碼無法整合，也就是「圖碼分離」的開發方法所有的各種問 題。

2.4 強化物件-關係模型（EORM）

強化物件－關係模型（Enhanced Object-Relationship Model，簡稱 EORM）[17]是由 Lange 於 1994 年提出。EORM 是定義為一個專注於將物件（連結）之間的關係表示為 物件而用來豐富物件導向模型的一個反覆的流程。強化物件－關係模型因為具有可擴充

的結構而在語義上變的豐富，加上可以加進其他的關係中，使它可以成為一可重用函式 庫的一部分，其架構如下圖 2.2。

圖 2.2 EORM 之架構

強化物件－關係模型由四個步驟組成：資訊分析（Information Analysis）、功能性分 析（Functional Analysis）、物件模型（Objecting Modeling）、和超媒體映像（Hypermedia Mapping）。而強化物件－關係模型主要是奠基於物件模型中的三個框架（Framework）

上：類別框架（Class Framework），複合組成框架（Composition Framework），圖形使用 者界面框架（GUI Framework）。類別框架是一個由類別定義組成的可重用函式庫，在 一 個 強 化 物 件 － 關 係 模 型 的 應 用 軟 體 中 皆 需 要 遵 照 標 準 的 物 件 導 向 技 術 來 識 別

（ Identify ） 所 有 的 類 別 ， 其 表 示 方 法 是 以 物 件 模 型 製 作 技 術 （ Object Modeling Technique，OMT）的符號表示。複合組成框架是一個由連結定義組成的可重用函式庫。

最後是使用圖形使用者界面框架的構成元素來設計圖形使用者界面，因此提出了以下的 步驟：先決定在這個應用領域中所需的視窗和每個視窗中要呈現什麼，再由各類別的屬 性和函式（Operation）取得欲呈現的資訊，決定什麼功能要放到那些視窗的選單中。

Identify Classes

Identify attributes, operations, inheritance

Identify Compositions

Identify cardinality, invariants, inheritance

Identify windows and presentations

Attributes fields / presentations Operations events / menus

Class Framework

Composition Framework

GUI

Framework

2.5 物件導向超媒體設計方法（OOHDM）

物件導向超媒體設計方法（Object-Oriented Hypermedia Design Method，簡稱 OOHDM）是由 Schwabe et al. 於 1995 年提出[34]。OOHDM 是一種適用於 Web 應用程 式開發的建模方法，可以用來滿足開發電子商務軟體的設計需求；由於 Web 應用程式 牽涉到超媒體（Hypermedia）、商業需求與流程，故而 OOHDM 採用以下模型來建立完 整的系統觀點，以符合 Web 應用程式設計的特殊環境需求。主要由四個步驟組成：概 念模型（Conceptual Modeling）、導覽設計（Navigational Design）、抽象介面設計（Abstract Interface Design）、和實作設計（Implementation），其架構如下圖 2.3。

圖 2.3 OOHDM 之架構

1. 概念模型（Conceptual Modeling）

概念模型是用來描述系統中的物件、關係以及功能的模型，在系統設計以前先將現 實物件（Domain Object）與商業模型轉化為概念模型，再將商業流程套用在這個模型，

以表現此一系統所需完成的功能。

2. 導覽設計（Navigational Design）

導覽設計可以用來描述使用者如何在 Web 應用程式所產的網頁（Node）間互動。

用來表現顧客行為的模型，能夠有效地幫助建立 Web 應用程式。導覽模型中以網頁為

Requirements Gathering

Conceptual Design

Navigational Design

Abstract Interface Design

Implementation

主要的物件，再以關連及方向表現出使用者瀏覽的行為；它和概念模型間具有對映的關 係，可以將導覽模型視為一個建立在概念模型上，表現出多媒體應用程式行為的模型。

3. 抽象介面設計（Abstract Interface Design）

抽象介面設計是使用者將會看到的介面物件規格，其靜態及動態方面在模型中以抽 象資料檢視（Abstract Data View）和狀態圖（State Chart）表示。

4. 實作設計（Implementation）

在這個階段，設計師實際地將先前的設計實作出來。設計師必須決定物件在網路上 的展現方式以達到最符合需求的狀態。

物件導向超媒體設計方法（OOHDM）是由上述四個步驟在一種混合遞增式的

（Incremental）、反覆式的（Iterative）、和奠基於原型的（Prototype Based）的發展型態 中施行的，亦就是每個步驟中都會建立物件導向模型來加強之前的反覆過程（Iteration）

中所作的模型設計。

OOHDM 以物件導向的特性進行網路應用程式的分析，在實作方面需要物件導向語 言的支援，但是現今最為普遍的 Web 應用程式專屬程式語言，例如：ASP、PHP 等網 路程式語言的特性仍然屬於程序導向（Procedural Oriented），因此設計分析與實作的整 合仍然必須花費相當的心力。

2.6 劇本為基礎的物件導向超媒體設計方法論（SOHDM）

劇 本 為 基 礎 的 物 件 導 向 超 媒 體 設 計 方 法 論 （ Scenario-based Object-Oriented Hypermedia Design Methodology，簡稱 SOHDM）[19][20]，是由 Lee et al. 於 1998 年提 出，其架構如下圖 2.4。

圖 2.4 SOHDM 之架構

它 由 六 個 階 段 組 成 ： 領 域 分 析 （ Domain Analysis ）、 製 作 物 件 模 型 （ Object Modeling）、檢視設計（View Design）、導覽設計（Navigation Design）、實作設計

（Implementation Design）、和建構（Construction）。這套方法和 RMM、EORM、OOHDM 等方法主要的不同在於利用劇本（Scenario）來描述使用者的行為，它是用劇本活動表

（Scenario Activity Charts）來對劇本做描述。

這些劇本在領域分析階段中被定義而在製作物件模型階段被使用。檢視設計階段包 括了決定一個物件導向的檢視（OO View）是由一個單一的物件類別或是由一些物件類 別的關係中生成。導覽設計階段利用劇本來決定取得結構節點（Access Structure Node）。它們被定義成一個好像選單的機制，可以讓使用者去取得一個超媒體中其他的 文件。這種取得結構再加上物件導向的檢視合稱為導覽單位（Navigation units）。最後 再識別了導覽連結（Navigational links）便完成了導覽設計階段。在實作設計階段使用 者界面、網頁、和邏輯資料庫圖式（Logical Database Schema）被作成模型。這套方法 呈現了一系列清楚的步驟，這得利於在分析階段就得到的劇本。

Domain Analysis

Object Modeling

View Design

Navigation Design

Page Design

User Interface Design

Logical Database Design

Construction Implementation

Design

Scenarios Context Diagram, Event List, Scenarios

CRC

OO Views

OO Views

Navigational Link CRC, CSD

CRC, CSD

OO Views

Page Schema

UI Specification Physical

Database

2.7 超媒體設計方法之比較

以下將比較先前討論過的超媒體設計方法，如表 2.1。

表 2.1 超媒體設計方法之比較

HDM RMM EORM OOHDM SOHDM

作者 Garzotto 等人 Isakowitz 等人 Lange Schwabe 等人 Lee 等人

年份 1993 1995 1994 1995 1999

基本模型 實體關聯 實體關聯 物件導向 物件導向 CRC 卡

劇本 適 當 的 應 用

領域 內容導向 內容導向 程序導向 內容導向 程序導向

導覽來源 實體關聯

關係

實體關聯 關係

物件導向 關係

物件導向 關係

劇本和 物件導向觀點 識 別 使 用 者

觀點的方法 HDM 綱要 片段 無 觀點 劇本和

物件導向觀點 識 別 綱 要 的

方法 無 無 無 無 關聯式資料庫

語意豐富度 相當缺乏 相當缺乏 相當豐富 相當豐富 相當豐富

設計階段

1.撰寫大範圍 的超媒體結構 2.撰寫細部的 超媒體結構

1.實體關聯設計 2.片段設計 3.導覽設計 4.轉換協定設計 5.使用者介面畫 面設計

6.執行行為設計 7.建構

1.類別框架 2.組合框架 3.圖形使用者 界面框架

1.需求彙集 2.概念模型設計 3.導覽模型設計 4.抽象介面設計 5.實作

1.領域分析 2.物件導向建模 3.視覺設計 4.導覽設計 5.實作設計 6.建構

組合概念 無 無 有 有 有

繼承概念 無 無 無 很少 很少

多型概念 無 無 無 無 無

由表 2.1 可看出目前的方法雖各有擅長之處，然而在物件導向之繼承與多型概念卻 並沒有任何方法提及。因此我們提出一物件導向式電子商務平台之建模與分析方法，針 對電子商務靈活度之特性，採用物件導向中之繼承與多型概念來達到快速擴充新功能之 目的。

第三章 物件導向式電子商務平台之建模方法

為提升電子商務平台之開發及維護之效率，本論文提出一套物件導向式電子商務平 台之建模與實作方法。本章將先介紹建模方法，而將建模方法之分析設計結果對應至系 統實作之方法於下一章介紹。

本論文所提出之物件導向式電子商務平台之建模方法（Object-Oriented E-Commerce platform Design and Modeling Method，以下簡稱 OOECDM）共分四個階段：系統需求 分析階段、概念模型設計階段、導覽模型設計階段以及系統介面設計階段。一般網頁建 模與設計方法在概念模型設計的部份僅以組成架構來做分析，對於網站功能的升級及擴 充並無助益。本論文在概念模型設計階段特別利用三種架構來做分析，包括：組成架構、

繼承架構以及多型架構。其中運用繼承架構及多型架構進行分析，可有效重複利用已開 發之網站功能模組以產生新的功能模組，因而可以達到快速升級及擴充網站功能的目 的，有效提升電子商務網站的競爭力。

本章共分為五節：3.1 節介紹 OOECDM 之四個分析與設計階段；接下來的三節則 分別介紹概念模型設計階段的三種物件導向分析架構：3.2 節描述概念模型之組成架 構；3.3 節描述概念模型之繼承架構；3.4 節描述概念模型之多型架構。前四小節中我們 以一個只包含商品系統、會員系統、以及訂購系統的“簡易線上購物網站＂為範例做各 分析階段的說明。最後在 3.5 節，我們將依本論文所提出的方法對一個大型且完整的“線 上購物網站＂進行分析並呈現其設計後之模型，以展示本方法的應用實例。

3.1 物件導向式電子商務平台之建模方法簡介

OOECDM 之分析與設計步驟分為系統需求分析、概念模型設計、導覽模型設計以 及系統介面設計等四個階段。其完整系統開發流程如圖 3.1。

圖 3.1 電子商務平台之系統開發流程圖

本節將利用四個小節分別介紹 OOECDM 之四個分析與設計階段：3.1.1 介紹系統需 求分析階段；3.1.2 介紹概念模型設計階段；3.1.3 介紹導覽模型設計階段；3.1.4 介紹系 統介面設計階段。我們以開發一個「簡易線上購物網站」為例來說明這四個階段的分析 與設計方法。該簡易線上購物網站之功能包含：商品系統、會員系統、以及訂購系統等 功能。

基於物件導向之概念，我們使用目前軟體工業與學界廣為支持的標準－統一建模語 言（Unified Modeling Language，UML）[5]的類別圖來表現出概念模型的內容，將現實 的物件以抽象的方式表現成類別，再以關連（Relationships）串連其間，組成穩定的系 統靜態結構。

3.1.1 系統需求分析

在需求分析階段主要在以使用者為中心，並由使用者的需求找出其目標再加以引導 出所需要的劇本。其中包含了使用者的種類、特性、目的、任務的描述。

根據網站系統的需求來制定網站策略與任務，並配合使用者的分類與其特性、需求

分析，由此來建構使用案例模型(Use Case Model)及劇本(Scenario)。

在「電子商務平台」中，我們以「簡易線上購物網站」為例，其使用案例包括：一 般使用者之瀏覽資訊、研究產品及線上註冊；會員除了一般使用者之功能外，尚可經由 帳號、密碼登入系統，以進行修改個人資料或訂購商品之後執行付款之動作；網站管理 員可先通過身份認證之後再進行系統設定或管理資訊，其中管理資訊包括會員管理、商 品管理、訂單管理及商品類別管理，以上使用案例繪製成圖形如圖 3.2 所示。

圖 3.2 線上購物網站之使用案例模型

本購物系統之劇本描述的是當一位使用者（User）要在線上購買一個商品，首先使 用者要先註冊（Register）成為會員，認證通過後，系統會回傳註冊成功給使用者，之 後使用者就可用註冊成功的會員帳號及密碼來進行登入（Login）動作，經過系統認証

（Authorization）通過後即完成登入程序。此時該會員即可在線上瀏覽商品，在了解欲 購買（Shopping）商品之資訊後，按下立即購買便可進入訂購（Order）流程，在確認 購物清單及填好送貨資料後，再選擇付款方式，進入付款（Payment）程序。當所有付 款流程皆確認無誤後，系統會回傳付款成功給訂購流程，最後訂購流程再傳回購物成功 訊息告知使用者已成功在購買該商品，其循序圖如圖 3.3。

mem ber m anage

product manage

order manage Web Manager

system configure

manage Information authorization

research product

register

Order ePaper User

browse Information

class m anage

Member

change data

payment

login order

圖 3.3 線上購物之循序圖

經由以上系統需求分析之使用案例與劇本之建構流程，可以藉此更深入了解購物網 站之使用者需求，並由此分析階段找出網站策略及目標。

3.1.2 概念模型設計

概念模型設計階段在於從各種不同的角度（Perspective）來分析網站，定義系統的 類別以及類別之間的關係，採用 UML 之方法來區分物件間之關係。

根據需求分析階段所得出的使用案例模型及劇本，將其分析的結果概念物件化，來 找出網站系統所關注之問題領域（Problem Domain）的各項系統類別，包括定義系統的 類別以及類別之間的關係（如網頁類別與系統類別之間的關係）等等。

我們所提出的概念模型設計方法，包含了組成架構、繼承架構、多型架構。將於 3.2 節介紹組成架構；在 3.3 節介紹繼承架構；3.4 節介紹多型架構。

user : <Actor Name> Register Login Authorization Shopping Order Payment

send register data

register success

input Uid,pwd

check Uid,pwd Validity login success

brower product send Pid

send payment data check order data

payment success

purchase success

根據使用案例及循序圖，我們可以依 UML 之類別圖來表示概念模型，由此可以了 解系統所需的基本元件。以購物網站為例，畫出其概念模型如圖 3.4 和圖 3.5。

圖 3.4 線上購物網站之概念模型

圖 3.4 中可知使用者可透過訂購商品而產生訂單；對每個商品而言都有其製造公 司；商品屬於一或多個商品類別，一個類別也會包含多個商品，且類別與類別間存有子 類別之關係；而網站管理者則可管理使用者資料、商品資料及訂單資料。

另外在管理平台方面，網站管理者可經由管理資料物件來新增、刪除、修改及查詢 資料，包括會員資料、商品資料、訂單資料及商品類別資料。如圖 3.5 所示。

Class Name

*

1

*

subclass

1 Company

Name Address E-mail Site

User ID

Password Name Telephone E-mail Zip Address

Register()

Login(ID, Password)

Modify(ID) Order

Qty

Order_Date

MakeOrder(order) QueryOrder()

Web Manager

ID Password

Login()

*

1

*

1

*

1

*

1

Product Name Description Keywords Price Size

Search() Rank() Recommend()

*

1..*

*

1..*

belong

*

*

*

*

order

1 * *

1

圖 3.5 線上購物網站管理平台之概念模型

依此概念模型分析可從中了解到問題領域之語意（Semantics），可用來建立後續 的導覽模型，並可和其他同一問題領域之應用程式的分析或設計模型相互參考、配合、

重用概念或分析設計。

本論文所提出之概念模型中除了表達系統類別與類別間之關係，另外可用組成架 構、繼承架構，以及多型架構這三種架構來達成快速擴充新功能之目的。我們將在 3.2 至 3.4 節祥細介紹這三種設計架構。

User Uid Password Name Telephone E-mail Zip Address

Add() Delete() Modify() Search()

Product Pid Name Description Keywords Price Size

Add() Delete() Modify() Search()

Order Oid Qty PID UID Totals

Add() Delete() Modify() Search() Add

Field Value Condition Table

Delete Condition Table

Modify Field Value Condition Table

Search Field Condition Table Manage Data

IP DB Name DB_password Web Manager

ID Password

Login()

Class Cid Name

Add() Delete() Modify() Search()

3.1.3 導覽模型設計

透過我們所定義之新的物件以及物件之間的關係，配合前一步驟所產生之靜態的概 念模型，可以定義出網頁物件之間的瀏覽關係以及網頁物件與實體物件之間的功能呼叫 關係。

因為網站資訊系統需滿足導覽、計算、溝通及合作，在導覽模型設計階段我們需將 此四種需求完全考慮進去，並在導覽模型中將之表達出來，來製作出能滿足各類使用者 資訊與應用需求的網頁規格與網站模型。

此階段主要的工作是利用循序圖所展現之使用者使用系統之動態行為，將概念模型 進一步的細化，並且透過對 Web 應用程式架構的分析，將每個類別對應至相關之 Web 應用程式架構。由於網站資訊系統是基礎於客戶端/伺服器端（Client/Server）的架構，

因此，哪些類別對應於客戶端，哪些類別對應於伺服器端也是此階段的工作之一。下一 階段便是針對每個網頁類別設計其使用者介面。

透過我們所定義之新的物件以及物件之間的關係，配合前一步驟所產生之靜態的概 念模型以及動態的循序圖，可以定義出網頁物件之間的瀏覽關係以及網頁物件與實體物 件之間的功能呼叫關係。

根據循序圖中，一個使用者對於網站資源的使用情形，分成兩種模式，第一種為網 頁之間的瀏覽（包含動態網頁的瀏覽），第二種為網頁與系統實體物件之間的功能呼叫 關係，進一步的在概念模型中找出對應之物件，細部定義其間的關係，例如網頁物件與 網頁物件之間的索引（Indexed）或是導覽（Guided Tour）關係。在此步驟所定義的只 是個別使用者的部分瀏覽模型（Partial Navigational Diagram）。

導覽模型設階段旨在定義網站資訊系統的超媒體結構。導覽類別模型（Navigational Class Model）定義超媒體概念模型的抽象檢視（View Over Conceptual Model），即在概 念模型中的類別所提供的資訊與服務如何出現在使用者的面前。導覽類別定義了網頁所 提供的資訊與服務項目，導覽類別模型定義導覽類別，其間的連結等關係。然而導覽類 別模型並非整個網站的結構元件的模型，要到導覽結構設計階段我們才會加入必要的中 介網頁（存取結構），並且詳細描述所有參與提供使用者所見網頁的元素。

建立一個包含所有使用劇本中出現的介面物件的類別模型，將要提供的資訊及服務 以屬性及函式表示；亦可將概念模型中的每一實體類別對應為一導覽類別，再刪去不必 要的類別與屬性，或插入其他類別的屬性（可插入被刪去類別的屬性）。

由使用劇本中介面物件之間的互動與概念模型中的語意關係找出其中可能的導覽 關係（Navigation），組成（Composition），一般化／特殊化（Generalization／Specialization）

關係。

在必要時分別為不同的使用者設計不同的導覽類別，並將不同使用者所使用的導覽 類別分別歸屬於代表使用者的脈絡（Context）裡。

導覽類別模型以 UML 類別圖定義導覽類別與導覽類別間的關係。在導覽類別模型 裡各類別為概念模型中出現的實體物件的檢視（View），部份在概念概念模型中的實 體在導覽類別模型有對應的導覽類別，而導覽類別中的屬性便由其對應的實體物件中的 屬性導出；然而有些實體物件並不會有對應的導覽類別，但其中一些屬性會出現在其他 的導覽類別中。

以圖 3.5 之概念模型類別對應到導覽模型之類別架構（Class Schema），所產生之 圖形，如圖 3.6。由於商品製造公司（Company）並不屬於導覽類別，所以可看到原先 在圖 3.5 中之商品製造公司在導覽模型中並無對應之導覽類別，反而在商品物件中多出 一個製造公司之屬性。因此可在此模型中看出類別與類別間的導覽關係

圖 3.6 線上購物網站導覽模型之類別架構

導覽模型之脈絡架構（Context Schema）包含：主選單（Main Menu）和商品之間 透過商品類別（Section）有商品種類（Categories）之關係；欲購買商品時，則可經由 訂購表單來訂購商品，其脈絡架構繪製如圖 3.7。

Order Qty

Order_Date

MakeOrder(order) QueryOrder()

Class Name

*

1

*

subclass

1 User

ID Password Name Telephone E-mail Zip Address

Register()

Login(ID, Password) Modify(ID)

Product Name Description Keywords Price Size

Search() Rank() Recommend()

*

1..*

*

1..*

belong order

Web Manager

ID Password

Login()

*

1

*

1

*

1

*

1

manage

1 * *

1

圖 3.7 線上購物網站導覽模型之脈絡架構

3.1.4 系統介面設計

系統介面設計必須符合先前步驟所產生的模型，設計出各網頁的介面及網頁與網頁 間訊息傳遞的關係。詳細規劃出每個網頁應具有的元素及資料。

圖 3.8 為一般購物網站之購物介面設計。其中包括了多種商品的目錄及各目錄下之 分類細目，還可看到產品名稱、價格、圖片、產品描述及詳細規格，如果消費者對其產 品有興趣，欲購買時可按下訂購按鈕進行購物程序。

Product_Name：string Price：string

ADV Product Introduce

Directory Category

Product_Pic：Image Sale_Text：string Picture

Description：Text Details：Text

Order：Button

圖 3.8 線上購物網站商品介紹物件之介面設計

而一般購物網站訂購介面則包含購物清單、訂購人資料、收貨人資料、付款方式選 擇及取消交易按鈕。其中購物清單包括訂購的商品名稱、價格、數量及總計金額。其介 面設計，如圖 3.9。

圖 3.9 線上購物網站訂購系統物件之介面設計

經由以上 4 個步驟的設計方法來設計網站，可以幫助系統開發者全面的分析網站整 體架構，使其在設計過程中更了解網站與使用者需求，進而規劃出與眾不同的網站特色。

接下來我們將根據概念模型階段去做一延伸，在原先概念模型中加入組成架構、繼 承架構及多型架構，依序說明於 3.2 至 3.4 節。

ADV Ordering

Delivery Data Order Data

Payment Method：Button

Cancel Order：Button

Shopping List

Product：string Price：int Qty：int Total：int

Customer：string Telephone：string Zip：int

Address：string E-mail：string

Receiver：string Telephone：string Zip：int

Address：string

ATM Credit Card Card installment

3.2 概念模型之組成架構

在參考大部分的購物網站後，首先歸納出一個購物網基本所需要的模組，接著詳細 規劃出每個模組的組成部分，以物件為單位，將各個功能分別撰寫再組合。此架構可讓 系統設計師新增功能容易，在模組間僅需用訊息做溝通，並能以模組為單位進行維護，

快速的找出問題所在。我們將購物網站依其主要功能分為會員系統物件、商品系統物件 及訂購系統物件，如圖 3.10。

圖 3.10 組成架構圖

而各個子物件又由其他物件所組成，其介紹如下：

z 會員系統物件是由會員註冊物件、會員登入物件及會員資料管理物件…等所組 成。

z 商品系統物件是由商品分類物件、商品介紹物件及商品管理物件…等所組成。

z 訂購系統物件是由購物車物件、付款機制選擇物件及各種付款機制物件及訂單 管理物件…等所組成。

3.3 概念模型之繼承架構

運用物件導向中繼承的概念，可將電子商務網站每個系統依照其不同之特性做不同 的規劃。可藉此達到系統資源的再使用（Reuse），降低開發成本。

根據每個系統不同之特性分別劃分為圖 3.11 至圖 3.16 之繼承架構。

商品介紹

商品分類 商品管理

會員註冊 會員登入 會員管理

商品系統

<< entity >>

會員系統

<< entity >>

購物網站

<< entity >>

購物車 付款機制

訂購系統

<< entity >>

訂單管理

會員系統依種類分為單一階層和多重階層，如圖 3.11。其中單一階層僅將使用者區 分為會員及非會員；多重階層則可將會員區分成多種等級，並依不同等級而給予不同之 權限。

圖 3.11 會員系統

訂購系統可由網路購物車、傳真訂購、電話訂購、競標訂購等物件繼承之，如圖 3.12。

圖 3.12 訂購系統

依照以上之繼承架構可將原有之物件繼承下來，再根據各個物件不同之需求新增或 更改其內容。如此一來，可重複使用原有之物件，達到快速擴充新功能之目的。

3.4 概念模型之多型架構

網路購物車 訂購紀錄 檢視購物車() 加入商品() 刪除商品() 修改數量() 確認結帳()

<< entity >>

競標訂購 追縱清單 競標紀錄 得標紀錄 競標流程() 結標流程()

<< entity >>

傳真訂購 傳真單 傳真作業()

<< entity >>

電話訂購 電話訂購紀錄 電話作業()

<< entity >>

訂購系統

<< entity >>

會員系統

會員登入()

<< entity >>

單一階層

<< entity >>

多重階層 會員等級

設定等級() 查詢等級()

<< entity >>

多型架構能將相同的活動分析出來，對不同的物件進行不同的處理方式，如此一 來，系統開發者只要開發一程式就能根據各種不同的管理需求而對應出不同的處理程 序。在系統維護上也僅需對一份程式進行修改，而不用同步對各個對應的物件進行更 新，大大地提升系統的一致性，也因此減少了系統維護時間。

由於在管理介面中的查詢、新增、修改及刪除資料動作通常都大同小異，只因對應 不同的物件而在其資料表和欄位而有所不同。例如：查詢資料在對應會員管理和訂單管 理時，其查詢的資料表和欄位不同外，其查詢資料的動作皆相同（先輸入查詢條件再輸 出查詢結果）。以此類推，在新增資料、刪除資料及修改資料時，皆是相同之概念。

依照物件導向多型的概念，將電子商務網站中管理介面的“查詢資料”、“新增資 料”、“修改資料”、“刪除資料”進行多型架構的分析，如圖 3.13 至圖 3.16。

圖 3.13 查詢資料之多型架構

會員管理 查詢(會員)

<< entity >>

訂單管理 查詢(訂單)

<< entity >>

商品管理 查詢(商品)

<< entity >>

查詢資料 資料庫名稱 資料表名稱 欄位 條件 查詢() 分頁()

<<activity>>

圖 3.14 新增資料之多型架構

圖 3.15 修改資料之多型架構

會員管理 新增(會員)

<< entity >>

訂單管理 新增(訂單)

<< entity >>

商品管理 新增(商品)

<< entity >>

新增資料 資料庫名稱 資料表名稱 欄位 值 條件 新增()

<<activity>>

會員管理 修改(會員)

<< entity >>

訂單管理 修改(訂單)

<< entity >>

商品管理 修改(商品)

<< entity >>

修改資料 資料庫名稱 資料表名稱 欄位 值 條件 修改()

<<activity>>

圖 3.16 刪除資料之多型架構

依上述之多型架構來分析網站將可節省系統資源，並降低系統維護上之成本。

3.5 應用實例

依據本論文提出之物件導向式電子商務平台之建模方法，我們以擴充簡易型購物網 站成為一完整的線上購物網站為例，按照上述之設計步驟，做一完整之分析。包括系統 需求分析、概念模型設計、導覽模型設計、系統介面設計。之後再以物件導向式電子商 務平台之實作方法，對建模方法之分析結果進行實作。

首先是系統需求分析階段，在此階段我們必須對該購物網站使用者之需求做分析，

由此找出其目標並進而完成劇本之描述。

在本實例中我們針對一般使用者（User）、會員（Member）及網站管理者（Web Manager）之需求加以探討。一般使用者主要是以瀏覽網站資訊包括：最新消息（News）、 廣告（AD）及常問問題（FAQ）、商品研究（Research Product）、註冊（Register）及訂 閱電子報（Order ePaper）；會員（Member）主要是以登入（Login）帳號、密碼確認身 份，之後可修改個人資料（Change Data）及進入購物流程，如把喜好商品加入購物車

（Shopping Cart），之後再進入訂購（Order）程序，最後為付款（Payment）階段；而 網站管理員（Web Manager）則是通過身分認證（Authorization）步驟之後，即可進行 系統設定（System configure）及資訊管理（manage information）之動作，其中資訊管理 包含會員管理（Member Manage）、商品管理（Product Manage）、訂單管理（Order Manage）、商品類別管理（Class Manage）、廣告管理（Advertisement Manage）、問題管

會員管理 刪除(會員)

<< entity >>

訂單管理 刪除(訂單)

<< entity >>

商品管理 刪除(商品)

<< entity >>

刪除資料 資料庫名稱 資料表名稱 條件 刪除()

<<activity>>

理（FAQ Manage）、電子報管理（ePaper Manage）及最新消息管理（News Manage）。

根據上述使用者需求之分析，繪製使用案例如圖 3.17，其中粗線之部份為新增之使用案 例。

圖 3.17 完整購物網站之使用案例

在循序圖上我們新增了購物車（Shopping Cart）部份，在使用者瀏覽商品資訊後，

對其欲購買之商品就可先行加入購物車，等所要之商品都加入購物車之後即可進入訂購 程序。在確認訂單之後，即可執行最後之付款流程，如圖 3.18。

member manage

product manage

order manage Web Manager

system configure

manage Information authorization

research product

register

Order ePaper User

News

AD

FAQ browse Information

class manage News manage ePaper manage FAQ manage AD manage

Member

change data

login Shopping cart order payment

圖 3.18 完整購物網站之循序圖

我們以購物網站為例，將原先在 3.1.2 小節中繪製之概念模型，如圖 3.4 和圖 3.5。

根據以上延伸之架構，繪製出完整購物網站之概念模型，如圖 3.19 及圖 3.20。其中虛 線框起來之部分為，原始之概念模型。在圖 3.19 裡可由購物車物件和產品物件之間可 看出組成架構；在最新消息和廣告物件中可找出繼承架構之關連。而在圖 3.20 中可看 到新增、刪除、修改、查詢物件與會員、商品、訂單、問與答、電子報、廣告和最新消 息物件有多型架構之關係存在。

user : <Actor Nam e> Register Login Authorization Shopping Shopping cart Order Payment

send register data

register success

input Uid,pwd

check Uid,pwd

Validity

login success

brower product

send payment data check order data

payment success

purchase success

send Pid,Qty

send shopping list

圖 3.19 完整購物網站之概念模型

在圖 3.19 中，新增了常問問題（FAQ）、電子報（ePaper）、廣告（Advertisement）、

最新消息（News）及購物車（Shopping Cart）之物件。網站管理員對常問問題有公佈之 關連；對電子報有發行之關連；對廣告則有刊登之關連；對最新消息發表之關連。而對 使用者而言，則有訂閱電子報之關連和將商品加入購物車之關連。

Order Qty

MakeOrder() QueryOrder() Shopping cart

Total

Shopping_Date Paying_Method Add(Order) Modify(Order) CalCost() Confirm()

Company Name Address E-mail Site

Class Name

* 1

*

subclass 1

Advertisement Ad_name Ad_pic URL priority start_time end_time

News Title content Date ePaper

sender subject content send_time receiver Order()

Product Name Description Keywords Price Size Search() Rank() Recommend()

*

*

*

* place

* 1..*

* 1..*

Mak e

* 1..*

* belong 1..*

FAQ Question Answer

List News News_count Show()

Random News News_count Random_count Set Random() Random Show() Random AD

AD_count Random_count Set Random() Random Show() Rotate AD

AD_count Rotate_time Set Time() Rotate()

List AD AD_count Show()

Rotate News News_count Rotate_time Set time() Rotate() Web Manager

ID Password Login()

*

1

* publish 1

*

*

*

* post

*

1

*

release 1

1 **

1

manage 1

*

1

*

notify

User ID Password Name Telephone E-mail Zip Address Register() Login() Modify()

*

* *

* have

1..*

*

1..*

subscribe *

*

1 manage

1

*