Kenmingの鮮思維 » 軟體設計與分析

[軟件書推薦] Ringle 著作－UML團隊開發流程與管理第二版

Kenming Wang — Sun, 31 Jul 2011 10:22:27 +0000

UML團隊開發流程與管理第二版
-----------------------------------
作者：賴信仁
出版社：悅知文化
出版日期：2011年07月20日
ISBN：9789866072246

內容簡介
　　■從情境案例學習UML 2.3版中，14張圖形的應用時機
　　■完整分析如何透過UML正確表達軟體設計的精神
　　■可依據不同平台的需求，學習使用Java或C#為軟體開發工具
　　■內含LAB練習單元，可藉由實作確實了解軟體開發的種種面向
　　■使用工具的進階功能，了解團隊合作開發的基本精神

對於軟體設計的初學者來說，面對大量資訊時，往往不知從何處著手。本書作者依據多年教學經驗，以情境案例為教學主軸，適合以下需求的讀者作為學習指引：

想要了解UML及其應用時機
本書第一篇設計了一個完整案例，並將UML的14張圖形應用在該案例中，利用對話的方式，說明14張圖形的基本精神及應用方式，讓讀者可以透過實際案例了解UML的基礎。

想要了解如何在實際專案中應用UML
本書第二篇設計了另一個完整案例，搭配工具軟體，並配合UML、MDA及不同平台的程式語言（Java、C#），藉此可學習到如何在實際案例中應用UML，並提供LAB練習單元，讓讀者可以「從做中學」。

想要學習如何充份發揮軟體開發團隊合作模式
本書第三篇設計了團隊合作的情境案例，透過虛擬專案的進行，讓讀者可以了解團隊中的各個角色，以及如何挑選適合的工具。

想要了解Enterprise Architect 8如何使用
Enterprise Architect是一套完整的UM L支援工具，完整支援UML 2.3版的14張圖形，並支援多種程式語言及資料庫，且提供了強大的客製化空間。書中範例使用此軟體進行實作，藉此提供軟體操作及客製化之技巧。

去年底 Ringle 的著作－「UML 團隊開發流程與管理 (繁體/簡體版)」第一版就已賣光。原來他答應出版社作些錯誤修正後就準備要在今年初再版，結果他竟然又再整本書內容重寫過一次，足足花了兩個多月的時間，甚至再加上 Java 程式碼的範例 (第一版只有 VB.NET)，不得已再版日期也就延宕到七月中旬，總算鋪貨到各經銷書商了。

所以，所謂的第二版不是只有小小的改版而已，而是整本再翻過重寫！除了同時提供兩大平台的程式碼範例外，也再順應 UML 2.3 規格，新增了一張所謂的總則圖 (profile diagram)的介紹與應用時機。

除了原來就已經在第一版中為其書中的內容作過基本的介紹說明後，我倒覺得出版商為其撰述的〔內容簡介〕還蠻不錯的。強調本書是屬於情境式的教學，也附上 Lab 實作練習與解答，並說明了適合本書的讀者是想了解 UML 應用的時機與相關知識，以及 UML 工具的應用 (本書是利用 EA, Enterprise Archiect)還有團隊開發的管理與合作模式等。

我這邊是再補充並再次強調最關鍵的部分：UML 只是畫圖的語法，是應用在軟體領域上；它本身不代表軟體設計，也並非是物件導向的技術。

在 Ringle 所著作的這一本書內容，他只是藉由 UML 來表現出現實系統開發上，各所職開發人員所應具有的軟體設計觀念及面向，並且透過一連串精要的設計，而能達成順暢的溝通並導出到程式寫碼的實作階段。UML 可不是被用來作文件報告、用來作假交差了事而已，那只會更加重軟體人員的負擔 (可惜，現實上太多專案開發充斥這類作假現象還不自知)。

當然，原作者 (Ringle)還算是挺用心的把他多年來所累積的實務經驗，包括專案開發、顧問輔導，與課程教學上等，將其所看到的問題與心得的體驗，盡量表達在書中的內容。原作者 (Ringle)正是想透過本書的傳達，來喚醒軟體人員對設計的重視。

※ 延伸參考：
o 「UML 團隊開發流程與管理」新書正式出版(6/12)
o 「UML 協同開發管理」新書序言 Preview。
o Ringle 即將出版的新書─「UML 協同團隊合作開發」。
o 簡體版－UML 與 Enterprise Architect 7.5 團隊開發實務手冊（附贈CD-ROM）。

延伸閱讀：

大業務流程塑模的MSS三層次原則

Kenming Wang — Sat, 30 Jul 2011 13:29:50 +0000

越是大型公司的 IT 資訊單位，無論是外包或是自行維護/開發的系統，在作「需求分析」階段時，往往都會表達到所謂的「業務流程 (Business Process)」。

甚麼是業務 (或稱為企業)流程？這裡節錄 Jacobson 《Object Advantage》一書中，將企業流程定義為：

Put simply, a business process is the set of internal activities performed to serve a customer.（《Object Advantage》, Ivar Jacobson, 1994, p. 3）
（簡單地說，企業流程就是要能夠服務客戶的一連串企業內部的活動）

或者更簡單的解釋，業務流程表達的就是：某個人在某個時間點所作的某件事 (而這些事會呈現出關聯性與先後順序)。

而甚麼是「大業務流程」？簡單的說，就是業務流程範圍更為廣泛，參與的人更多，所涵蓋的時間更長。而且往往因為現實上基於功能執掌，還是不同部門或不同地點就有不同的作業規範與範疇，但彼此這些作業之間仍需要連串在一起。

例如，物流零售業領域，為了表現出從門市的「訂貨/退貨」，到總部的「進貨/出貨」，乃至於轉入財會單位的「帳務處理」，每一個業務範疇，就有其作業流程/作業規範；而把「訂貨/退貨」→「進貨/出貨」→「帳務處理」等作業流程串聯成更大的流程，即為所謂的「大業務流程」。

我走訪過許多大型的 IT 單位，包括顧問輔導或教學等。檢視從該單位 SA (System Analyst, 表示為需求分析師)所整理的業務流程設計圖，無論是使用傳統的流程圖 (flow-chart)，甚或採用 UML 語法所表達出來的活動圖 ((activity diagram)，幾乎普遍是存在兩大問題：

想要利用一張圖表現出所有的細節。
把資料作為主體，呈現的就是資料傳遞的流程。

第二個問題最難解，這裡牽涉到的就是「資料導向 (data-oriented)」 vs. 「服務導向 (service-oriented)」的分析/設計態度。

若從上述對業務流程的定義，或是後續利用使用案例 (use case)的分析技術，國外軟體大家的最佳實務經驗 (best practices)，均是偏向「服務導向」的開發模式。簡而言之，就是將資料封裝 (encapsulate)至服務之內，如此可避免過早揭露繁瑣的細節。

第一個問題則比較容易調整，主要就是把握住一個最基本的原則：設計圖要能維持「簡潔」。

「簡潔」的目的在於要能適切突顯出「焦點」之所在，而把諸多繁瑣的細節給封裝住。待決定集中的焦點後，再來才是將其內部「剖開」，探究細節的組成與關聯性。

而要能達成簡潔，就需要考量兩個構面－「廣度」與「深度」，要讓設計有「層次感」。

簡而言之，「廣度」考量的是所涵蓋的範圍；「深度」則是考量所揭露出細節的精細度。

以「大業務流程」的設計呈現，我這裡推薦採用「三層次」的表達，我把它稱為 MSS (Multiple - Single - System) 塑模表示法。

M (Multiple) Process－表達多個業務流程 (Business Process)之間的關聯性，利用「Erickson Penker (俗稱火箭圖) 流程擴展語法」表達。
S (Single) Process－表達單一業務流程內的作業活動 (activities)。利用 UML 「活動圖」表達。
S (System) －表達資訊系統所擔負的功能。利用 UML「使用案例 (use case)圖」表達。

這裡就直接借用 Ringle 著作－「UML團隊開發流程與管理(第2版)」，其中 8-1-2 章節內的範例－「電子化採購系統的企業流程」，來說明 MSS 三層次表達的重點。

第一層－火箭圖

圖1. 「請/採購業務流程」－火箭圖 (Erickson-Penker extension notion).

當想表達多個業務流程之間的關聯性，並觀察期間重要的輸入/輸出產出物、參考資訊，以及各作業流程所突顯的目的 (goal)，建議使用火箭圖表達，它非常適合表現出所謂的「總覽 (overview)」呈現。

以上圖1.而言，就可以從其中看得出主要表達兩個業務流程－「請購」與「採購」流程，以及各作業流程主要所參與的人員 (供應商、採購人員)，還有兩個流程之間的中介產出－請購確認資訊。更重要的是，突顯出每個流程運作的目的－「請購流程」決定供應商順位優先順序；「採購流程」期望採購高品質物料。

強烈建議，火箭圖與活動圖的參與人員，宜用角色/部門/組織等表示，也就是從傳統 "人" 的角度來看流程的運作，而沒有資訊系統的參與。資訊系統會延宕至第三層的使用案例圖來呈現。

主要的原因，在初期的分析階段，過早決定資訊系統的範圍並不妥當，它已經需要從企業經營的角度轉移到資訊系統的規劃，而資訊系統一般則是由軟體架構師 (architect)作整體性的系統規劃，過早加入資訊系統的角色於傳統企業流程上，會造成責任分派上的混淆，且相對也造成設計圖上的複雜度。
第二層－活動圖

圖2. 請購作業流程－活動圖 (activity diagram).

UML 活動圖適合用來表達單一業務流程內的活動細節。觀察上圖1.火箭圖，當欲進一步探究「請購流程」內的作業活動，則可將其 "剖開" (UML 工具可利用超鏈結關聯火箭與活動圖的連結)，並利用活動圖展現內部的作業活動情形。

從圖2.就可以清楚的看出有兩個角色 (或組織單位)參與「請購流程」的作業活動，並於不同的時間點有著各自需擔負的活動工作。與火箭圖一樣的是，盡量不要在兩個層次內表達「資訊系統」角色的參與，盡量強調的就是傳統「人本」的業務流程。

活動圖最不容易區分的是「活動 (activity)」與「行動 (action)」的界定。簡單的說，在一個「活動單元」內，可包含多個行動。而如何適切界定「活動」的單位，則另文再介紹說明之。
第三層－使用案例圖

圖3. 電子化採購系統－使用案例圖 (use case diagram).

從上圖2.活動圖只表達「人本」的作業活動，再來更進一步來觀察有哪些活動是需要資訊系統的支援，以及是哪一個資訊系統 (名稱)。而當活動轉成由資訊系統來實現時，即成為資訊系統所需擔負的「功能」，也就是稱之為「系統功能 (system functions)」。

利用使用案例圖 (use case diagram)來表達系統的功能，可說是最佳的利器。因為它可以界定系統開發範圍 (system boundary)、誰來使用系統，以及系統是否需要其它系統的支援。每一個系統功能即成為一個使用案例 (use case)，而後再撰寫已過濾的使用案例需求陳述，即可以非常直覺且順暢地橋接至程式寫碼與結構設計 (包括物件與資料模型)階段。

觀察圖3.使用案例圖，可以理解要開發的資訊系統為「電子化採購系統」，擔負的系統功能 (亦即橢圓形的使用案例)諸如「比價」、「產生請購需求」等；使用系統的參與者 (actor)有 ERP 系統、採購人員、供應商；而系統需要透過「通知系統 (Notify System)」的支援，來達成傳遞通知訊息的需求。

關於如何從活動圖的活動，轉化至使用案例圖的使用案例，可參考先前寫的一篇：「從企業流程(活動)圖找出資訊系統的使用案例」。

設計圖是否能作為有效的溝通與系統開發依據，務必要能適切的表現出焦點之所在。而要能「聚焦」，設計圖就要要能表現出「簡潔」。「井然有序，層次分明」，溝通也比較不致於陷入細節上的紛爭，如此開發節奏才會更能順暢。

目前沒有相關連的文章.

[烏龜訂購系統開發與實作-10]－從 EA 工具建立資料模型，並產出 DDL SQL敘述

Kenming Wang — Fri, 27 May 2011 07:35:31 +0000

下列步驟主要目地在於建立資料庫的資料表格，並實現由中間層控制物件連結至資料庫，以達成實際存取資料的目地。

十、從 EA 工具建立資料模型，並產出 DDL SQL敘述

透過 EA 建立資料模型 (Data Model)的原因，在於 EA 具備了視覺化的資料塑模機制。且透過其轉換 (transform)功能，可以產出支援多達十數種資料庫的 DDL (Data Definition Language) SQL敘述。
當然也可以使用如 eclipse 插件 (plugin)的資料庫管理工具，來規劃與建立資料表格。

在 [Logical View] 套件內，新增子套件 (sub-package)名為「Data Model」。
在該套件內新增一設計圖名為「Order Model」，設計圖類型為「Data Modeling」。

打開設計圖，從工具箱 (toolbox)中將「Table」圖形元件拖曳至設計圖內。本例會使用到兩個表格，其表格名稱與資料欄位參考如下：

CREATE TABLE ORDER
(
	id INTEGER AUTO_INCREMENT,
	item_no VARCHAR(3) NOT NULL,
	order_date DATE,
	PRIMARY KEY (id)
)
CREATE TABLE Item
(
	id VARCHAR(3) NOT NULL,
	name VARCHAR(24),
	price INTEGER,
	PRIMARY KEY (id)
)

在 Table 的屬性 (property)視窗內，填入「Name」、「Alias」、「Database」等資訊。在本例中，可以選擇支援標準 SQL 語法 (ANSI-SQL)的 MySql 資料庫。

（點擊圖片鏈接看原圖）圖 16、設計資料表格屬性、指定轉換資料庫版本
切換至 [Table Detail] 標籤，點擊 [Columns/Attributes]，在出現的 Columns 視窗內，新增 column 與設定相關的屬性。

（點擊圖片鏈接看原圖）圖 17、新增 Column，設定相關屬性
產出 DDL (Data Definition Language) SQL 敘述檔 (純文字檔)。
點選 [Project Browser] → [Data Model] 套件，右鍵選擇 [Code Engineering] → [Generate DDL...]，在出現的對話框內，指定所產出 DDL 檔案的目錄與檔名，以及勾選相關的資料庫設定項目，按下 [Gererate]。

（點擊圖片鏈接看原圖）圖 18、產出 DDL SQL 敘述檔

延伸閱讀：

[案例研討] 烏龜訂購系統開發與實作 by UML and Java－09

Kenming Wang — Mon, 25 Apr 2011 00:26:16 +0000

九、撰寫控制類別的功能測試程式碼框架

＊＊至本實作步驟可以先把 EA Model 檔與 Eclipse Java 專案存檔。將整個專案目錄備份至 /Stage-1_1 目錄下，視為第一個開發階段的版本。＊＊
　o 下載 Java 專案與 Model 檔－Stage1_1.rar

在 eclipse 環境下要撰寫測試程式碼是非常簡單的一件事，原因是 eclipse 已內建了 JUnit 測試框架 (JUnit Test Framework)，作為一位程式撰寫人員，最起碼要為每一個控制性的功能(服務)類別撰寫功能測試程式碼 (functional test code)，可以說是軟體品質的最基本保障，也是應該要具備的責任與良心了。

在 Eclipse 內的 [Project Explorer]，選擇「訂購烏龜_Control.java」，按下滑鼠右鍵，選擇 [New] → [Other…]，然後在 Wizard 對話框內，選擇 [Java] → [JUnit] → [JUnit Test Case] ，然後點擊【Next】，在出現的對話框內，填入以下資訊：
- 點選「New JUnit 4 Test」。 (新版本的測試框架可以根據 Java 5.0 以上版本的新特徵特性來建構；更簡單、易於使用，以及更敏捷的初始化與清理等工作)
- Package： com.order.test (端看開發人員的習慣，這裡是採用將測試程式碼均放置於原始程式碼所在位置的子目錄下)
- Name：訂購烏龜_Control_Test (測試類別命名的建議為原類別名稱 + _Test)
- 勾選 setUp() method (讓測試類別可進行初始化的工作)。
（點擊圖片鏈接看原圖）圖 13、新增 JUnit 測試程式碼的對話框

點擊【Next】，在出現「選擇測試的 method」對話框時，點選該控制類別所宣告的 method。一般而言，功能測試的重心會在於測試功能性類別所揭露出的企業邏輯 (business logic)，這些企業邏輯的演算核心均會被封裝 (encapsulate)在功能性類別所宣告的 method 內。

（點擊圖片鏈接看原圖）圖 14、針對類別選擇要測試的方法

編輯所產出測試程式碼的內容。
訂購烏龜_Control_Test.java：

package com.order.control.test;
 
import static org.junit.Assert.*;
import org.junit.Before;
import org.junit.Test;
 
import java.util.*;
import com.order.control.*;
import com.order.dto.*;
 
public class 訂購烏龜_Control_Test {
	private 訂購烏龜_Control control;
	private VO_結帳資訊 mOrder; 
 
	@Before
	public void setUp() throws Exception {
		control = new 訂購烏龜_Control();
	}
 
	@Test
	public void testList烏龜清單() {
		ArrayList<VO_烏龜資訊> expected= null;
		ArrayList<VO_烏龜資訊> result = control.list烏龜清單();
 
		assertNull(result);
	}
 
	@Test
	public void test結帳() {
		VO_訂購確認資訊 expected = null;
		mOrder = new VO_結帳資訊();
		VO_訂購確認資訊 result = control.結帳(mOrder);
 
		assertNull(result);
	}
 
	@Test
	public void testSaveOrder() {
		//將 mOrder(結帳資訊) 寫入至 Database.
		boolean result = control.SaveOrder();
 
		assertFalse(result);
	}
}

目前所撰寫的測試程式碼仍偏向是框架 (skeleton)性質的，不過已先加入欲測試的控制類別，以及為其初始化。目前就是先讓其可以通過 JUnit 的測試即可。

執行 JUnit 測試。
在 [Package Explorer] 內，點選待測試的控制測試類別，本例為「訂購烏龜_Control_Test.java」。在 eclipse 的工具列 (toolbar)中，選擇 [RUN] (綠色右箭頭符號圖示) → [Run As] → [JUnit Test]，執行後即可顯示測試的結果。 (若所有方法均測試通過，即顯示綠棒；若其中一個方法測試失敗，則顯示紅棒。)

（點擊圖片鏈接看原圖）圖 15、在 Eclipse 內執行 JUnit 測試

延伸閱讀：

[案例研討] 烏龜訂購系統開發與實作 by UML and Java－08

Kenming Wang — Mon, 11 Apr 2011 08:01:27 +0000

八、新增 Java Model 專案，撰寫控制類別程式碼

1. 新增 Java Model 專案：

（點擊圖片鏈接看原圖）圖 12、在 Eclipse 下新增 Java 專案

2. 撰寫控制 (control)類別與資料傳遞 (data transfer)類別的程式碼框架 (skeleton)

訂購烏龜_Control.java：

package com.order.control;
 
import java.util.*;
import com.order.dto.*;
 
public class 訂購烏龜_Control {
	public ArrayList<VO_烏龜資訊> list烏龜清單() {
		return null;
	}
 
	public VO_訂購確認資訊 結帳(VO_結帳資訊 m_結帳) {
		return null;
	}
 
	public boolean SaveOrder() {
		return false;
	}
}

VO_烏龜資訊.java

package com.order.dto;
 
public class VO_烏龜資訊 {
	public String getId() {
		return id;	}
	public void setId(String id) {
		this.id = id;	}
	public String getName() {
		return name;	}
	public void setName(String name) {
		this.name = name;	}
	public int getPrice() {
		return price;	}
	public void setPrice(int price) {
		this.price = price;	}
	private String id;
	private String name;
	private int price;
}

VO_結帳資訊.java：

package com.order.dto;
 
public class VO_結帳資訊 {
	public String getId() {
		return id;	}
	public void setId(String id) {
		this.id = id;	}
	public int get數量() {
		return 數量;	}
	public void set數量(int 數量) {
		this.數量 = 數量;	}
	private String id;
	private int 數量;
}

VO_訂購確認資訊.java：

package com.order.dto;
 
public class VO_訂購確認資訊 {
	public VO_烏龜資訊 getV烏龜() {
		return v烏龜;
	}
	public void setV烏龜(VO_烏龜資訊 v烏龜) {
		this.v烏龜 = v烏龜;
	}
	public int get總價() {
		return 總價;
	}
	public void set總價(int 總價) {
		this.總價 = 總價;
	}
	private VO_烏龜資訊 v烏龜;
	private int 總價;
}

筆記重點

控制類別的類別與方法 (class and method)名稱均是源自於上圖 4 於 EA 中所設計的 UML 控制類別。
訂購烏龜_Control.java 所宣告的三個公用方法 (public method)即是反映「訂購烏龜」使用案例內的動作步驟，參與者 (未來透過 JSP 實作)與系統 (本控制類別)之間的互動共有三次。
目前僅定義程式碼的框架 (skeleton)，故私有方法 (private method)省略，且回傳值僅回傳空值 (null)即可 (事實上，這可以視團隊開發節奏與寫碼熟悉度而加深細節)。
控制性的類別被歸類於「com.order.control」；而資料傳遞 (data transfer)類別則被歸類於「com.order.dto」。
以目前 Java 世界的主流，仍以資料物件 (data object)作為物件之間互動的參數傳遞與回傳值型態。相較於 .NET 作法，則以 DataSet (本質為 XML)為參數與回傳值的資料傳遞。
命名為 VO_ 開頭的物件 (如 VO_結帳資訊.java)即為資料物件。這類物件僅單純只有「getter、setter」的取值方法，所以也被稱為「值物件 (value object)」。這些資料型物件就被歸類置於「com.order.dto」套件 (package)內。
切記！ VO 物件不等同於企業物件 (business object)－著重在企業邏輯的運算，或資料庫內的表格 (從邏輯分析而言應稱為 Entity，實體)－著重在領域概念 (domain concept)的資料結構。它僅是做為方便物件之間 (尤為在不同 tier 的傳遞，如 JSP → Control Object。)傳遞的參數與回傳值而已。
一般 VO 物件的設計規劃，並不需要特別嚴謹 (甚至是抱著快速且隨便的態度)。以本例而言，所設計的三種 VO 物件 (VO_烏龜資訊, VO_結帳資訊, VO_確認訂購資訊)，僅是在滿足表單與控制類別之間的資料傳遞而已。
至於資料庫的表格設計，一般稱之為 E-R (Entity-Relationship)設計，因會考量到共用性需求，所以會嚴謹許多。在未來的系統設計整合階段，VO 物件需經過轉換程序，透過 O-R Mapping 機制 (如 Hibernate)，寫入至資料庫 (反之亦然)。

延伸閱讀：

[案例研討] 烏龜訂購系統開發與實作 by UML and Java－07

Kenming Wang — Wed, 30 Mar 2011 15:33:51 +0000

七、Java 開發環境平台與建置

1. 下載與安裝所需 Java 開發工具

下載 JDK, Elipse IDE, Web Container, Portable Database：
- Java JDK v1.6
  http://www.oracle.com/technetwork/java/javase/downloads/index.html
- Eclipse IDE for Java EE Developers v3.6 (Helios)
  http://www.eclipse.org/downloads/
- Apache Tomcat 6.0
  http://tomcat.apache.org/download-60.cgi
- Apache Derby (Pure Java DB) v.10 以上版本
  http://db.apache.org/derby/

Tomcat 的角色如同在 Visual Studio .NET IDE 的 IIS，均是充當在 Web 專案開發下的 Web Container 機制。
VS.NET 幾乎無可選擇地，均是採用 IIS 作為 Web Container；而 Java Eclipse IDE，則可以選擇多種類型的 Web Container。本實作案例，以採用最普遍的 Tomcat 作為 Eclipse IDE 的主要 Web Container。
除了 Web Container，當然也需要有開發 (兼測試)用的資料庫。相較於 VS.NET 採用自家 SQL Express 作為開發用的資料庫，Java Eclipse 則從以往所常用的 hsqldb，如今更多開發人員推薦的是更為開放、輕巧的 apache derby、可被內嵌於 eclipse 的輕量級 (lightweight)資料庫系統，且亦可以利用 eclipse DTP (Data Tools Platform) 輕易地操作存取 derby 資料庫。本實作案例，即採用 apache derby 作為開發與測試用的資料庫系統。

2. 設置 Tomcat 成為 Eclipse 開發環境內的 Web Container：

詳細安裝說明，可參考：
http://www.zulutown.com/blog/2009/01/18/setup-tomcat6-on-eclipse/
Eclipse 選單 [Window] → [Preferences] → [Server] → [Runtime Environments]，【Add…】按鍵選擇「Apache Tomcat 6.0」並設置其 Runtime 環境 (一般預設即可)。
在 Eclipse Server Panel 內，右鍵選擇 [New] → [Server]，在出現的對話框選擇「Tomcat v6.0 Server」，一般照預設設定即可，然後按下【Finish】完成 Eclipse Web Container 設置。

（點擊圖片鏈接看原圖）圖 7、新增 Tomcat 6 為 Eclipse Web Container

3. 確認已安裝 WTP (Web Tool Platform) plugin of Eclipse：

詳細安裝設定，可參考： http://www.vogella.de/articles/EclipseWTP/article.html
可透過 Eclipse Update Manager, 確認下述類別內的套件已安裝：
「Web, XML, and Java EE Development」套件內所有子套件 (除了「PHP Development」套件)。

4. 安裝 DTP (Data Tools Platform) plugin of Eclipse (資料庫管理工具)：

透過 Eclipse Update Manager, 確認下述類別內的套件已安裝 (預設未安裝)：
「Database Development」→「Data Tools Platform Enablement Extender SDK」。

（點擊圖片鏈接看原圖）圖 8、安裝 eclipse DTP plugin

5. 安裝 Derby plugin of Eclipse：

詳細安裝與相關設定，可參考：
http://db.apache.org/derby/integrate/plugin_howto.html

從 http://db.apache.org/derby/derby_downloads.html 下載：
derby_core_plugin 與 derby_ui_plugin 兩個插件。 (以本例所下載的版本為：
derby_core_plugin_10.7.1.zip, derby_ui_doc_plugin_1.1.2.zip)
將上述兩個 .zip 壓縮檔解壓縮，並放置於 %ECLIPSE_HOME%/plugins 目錄下。注意，因壓縮檔的檔案均放置於 /plugins 目錄下，所以應該是解壓縮至 %ECLIPSE_HOME%；總之，在 %ECLIPSE_HOME%/plugins 目錄下，當解壓縮後，會新增如下三個子目錄 (視所下載的版本)：
org.apache.derby.core_10.7.1, org.apache.derby.ui_1.1.2, org.apache.derby.plugin.doc_1.1.2
重新啟動 Eclipse。在爾後任何所創建的 Java 專案，點擊專案名稱後，按下右鍵後應會出現 [Apache Derby] → [Add Apache Derby nature]，選擇後即可加入 Derby函式庫 (Libraries)。

（點擊圖片鏈接看原圖）圖 9、在專案中新增 Derby Library
新增 Derby 函式庫後，再點擊專案名稱，按下右鍵，在所出現的本文選單內，即會出現 Apache Derby 的管理選項，包括啟動 (Start)、停止 (Stop)「Derby Network Server」。

（點擊圖片鏈接看原圖）圖 10、Apache Derby Network Server 啟動選項
啟動 Derby Network Server，在 eclipse [Console] view 中，會顯示相關的啟動訊息。例如：
「Apache Derby 網路伺服器 - 192.168.1.168 - (1040133) 已啟動，並且準備接受連接埠 1527 上的連線」。

（點擊圖片鏈接看原圖）圖 11、Console 會顯示 Derby 啟動的相關訊息

延伸閱讀：

[案例研討] 烏龜訂購系統開發與實作 by UML and Java－06

Kenming Wang — Thu, 24 Mar 2011 09:33:20 +0000

六、利用循序圖表達系統內部物件的互動

對每一個要實現的使用案例，開發人員可以利用一到多張的循序圖 (包括正常劇本、例外處理與擴展性的劇本)，表達未來程式碼在系統執行期間 (Run‐time)的物件互動情形。

在循序圖內，大致列出主要參與的物件角色 (較偏開發人員所設計的物件，而非系統面的物件)。
請注意，循序圖內主要表達的是物件之間的互動，所以在如 EA 工具中，將位於「Project Browser」視窗內所拖曳至畫面內的 UML 圖形元素時，需要設定為「物件 ( instance)」，而非用連結 (link)。參考如下圖 5所示。

（點擊圖片鏈接看原圖）圖 5、循序圖內的元素主要為物件

循序圖內的物件配置，主要分成兩大類：
- 利用棒形人偶圖示所表達的參與者。包括 UI 表單畫面、資料庫系統、外部系統，均以該圖示表達。
- 位於中層間開發人員所設計的物件，包括控制、邊界 (boundary)、領域 (domain)、資料、工具 (utility)或系統服務等類型。一般均使用長方形的 UML 物件圖表示。
為了方便觀察物件之間的訊息互動傳遞，可以在循序圖的最左側中，新增一個“註釋 (Note)”，然後把該使用案例的主要文字敘述“貼 (Paste)”在 Note 內容內。

（點擊圖片鏈接看原圖）圖 6、在循序圖內規劃主要參與的物件與其之間互動的訊息

觀察上圖 6，有些訊息名稱前面加上 “//” 即代表註解 (comment)的意思，代表的是與該物件的互動，並沒有一個特定的方法 (或 API)可供呼叫。
例如與 RDB 的連結，它僅能透過 SQL 敘述的呼叫，所以用如 “//SELECT SQL” 與 “//INSERT SQL” 等來代表控制物件與資料庫的互動意涵。

請注意！循序圖不是要表達的精細。重點是在為了完成某個功能 (從使用案例敘述的分析而來)時，值得所關注的參與物件，以及這些物件之間的訊息傳遞。
已經有一些 UML 工具，可以透過程式碼的靜態掃瞄，而能模擬在系統在動態期間，所產生的物件與之間的訊息傳遞互動，並反轉 (reverse)為 UML 循序圖以供開發人員檢視物件的動態相依與訊息追蹤，相當實用。
可以參考 HSDc. Sequence-generator plugin for EA：
http://www.kenming.idv.tw/source-code_with_uml_class_seq_diagram_relationship-04

延伸閱讀：

[案例研討] 烏龜訂購系統開發與實作 by UML and Java－05

Kenming Wang — Tue, 22 Mar 2011 01:18:37 +0000

四、表達使用案例與實作的實現關係 (Use Case Realization)

（點擊圖片鏈接看原圖）圖 3、表達使用案例與實作的實現關係

若以物件導向的觀念實現使用案例，則系統內部的設計當以物件互動的合作 (collaboration)，如 UML 循序圖 (sequence diagram)、溝通 (communication)圖等來表達。其作用為突顯該使用案例的功能，由 1 到多個物件 (一般指位於中間層, middleware 內的物件)，在系統執行期間 (run-time)，透過訊息 (message)的傳遞，來達成功能的實現。

五、為每一個使用案例，設計並配置一個功能性的控制類別

（點擊圖片鏈接看原圖）圖 4、為每一個使用案例配置控制類別

控制類別在本例係使用 pure Java 撰寫。被部署 (deploy)於中間層 (middle-tier)，擔任 MVC 架構中控制者 (controller)的角色。
控制類別的命名建議：「使用案例名稱」+「_Control」。
以「訂購烏龜」使用案例為例，其控制類別的命名為「訂購烏龜_Control」。
控制類別內的操作 (operation)、在 Java 語言則稱為方法 (method)，為來自於使用案例敘述的動作步驟說明。
在「訂購烏龜」UC 的動作步驟分析中，得以發掘出 "訂購烏龜_Control" 類別與參與者 (actor, 在本例為客戶)的互動次數共有三個：「列出烏龜清單()」、「結帳()」、「SaveOrder()」。
至於「計算訂購金額()」則為該物件內的私有方法 (private method)，並不需要讓外界物件來操使用。
每一次的互動，即為系統的"代理人"，也就是控制類別會提供讓參與者來呼叫 (call)的方法；另外也可以透過觀察在設計循序圖時，參與者與控制物件互動的過程中，其訊息 (message)的互動傳遞情形，再由其定義出控制類別的"方法"、"參數"、"回傳值"等。
(一般而言，這兩種方法會在設計過程中交替運用，並沒有絕對的先後關係。)
若為了要能確實將在 UML 表達的設計類別，與實作的程式碼同步，則同時需要設定控制類別未來要"code-gen"的程式語言，以及控制類別所在的命名空間 (name space)。
在本例中，控制類別要"code-gen"為 [Java]，命名空間 (name space) 則置於「com.order.control」package 內。
在 EA 的工具中，還需要指定"code-gen"時的 "name space" 根目錄為"com"。設定方式為在 [Project Browser] 視窗中，滑鼠右鍵點擊 [Logical View] → "com"，選擇 [Code Engineering] → [Set as Namespace Root]。
UML 類別與程式碼的直接對應，並期望藉由工具能達成一致性的同步關係，稱為軟體的正反向工程 (software forward/reverse engineering)。
建議中小型且開發人數不多的專案，不要為維護正反向工程 (保持一致性關係)耗費太多精力與時間。寧願將 UML 的設計圖，包括類別與循序圖，比較偏向是草稿式 (draft)的作法 (如此才能專注發揮腦力激盪的設計工作)。
而相關於精確性的細節 (例如類別的參數、回傳值等資料型態)，則直接落實於程式碼的實作即可。
在本例中，只利用 EA 工具所設計的控制類別，只包括類別名稱與操作方法名稱。至於參數與回傳值等資料型態等，則直接在程式碼內實作即可。

延伸閱讀：