＊＊＊ 第一個階段子目標 ＊＊＊

1. 確實在 Eclipse IDE工具內建立可以完整開發 Spring-based 的應用程式。
2. 新增 middle-tier性質專案(純粹是 java class，沒有 UI)，撰寫 {員工薪資管理Control.java} 這個控制物件的程式碼框架 (skeleton)，新增一個 Spring Beans 的 XML設定檔 (config file)，在設定檔內設定該控制物件的相關屬性。
3. 利用 JUnit 測試框架 (Test Framework, Eclipse 內建)，馬上撰寫該控制物件的功能測試程式碼。

一、新增專案

1. 選擇 [File]  [New]  [Project…]，當出現 [New Project] 的 wizard 對話框時，選擇 [Spring]  「Spring Project」，然後按下【Next】，出現 [New Spring Project] 對話框內，輸入新增的專案名稱： HRDemo，其它選項照預設即可，按下【Finish】完成，並將 eclipse的視界 (perspective)切至 Java EE。

   
   圖 3、新增 Spring Project 的對話框

2. 在 [Project Explorer] 的專案視窗內，將滑鼠移至專案的根目錄 (HRDemo)下，右鍵點選 [Build Path]  [Configure Build Path …]，出現 [Properties for HRDemo]的對話框，然後將標籤切換至 [Libraries]，並點擊【Add Libraries…】，當出現 [Add Library] 對話框後，選擇 [User Library] 然後點擊 【Next】。

圖 4、Add User Library 的對話框

出現 [User Library] 對話框後，點擊 【User Libraries…】，再點擊 【New…】，在 [New User Library] 的對話框內填入自訂的 Library 名稱，在此例填入：「Spring 2.x Framework」 完成後點擊 【OK】。

圖 5、填入 User Library 名稱

點擊 【Add JARs】。Spring-based 的專案，至少必須載入三個相關的 jar： spring.jar, commons-logging.jar, log4j-1.2.14.jar。此三個檔案位於在上述所解壓縮 Spring Framework Library (此例目錄為 C:javalibspring-framework-2.X)，路徑內的 /dist, /lib/Jakarta-commons, /lib/log4j 目錄下。

圖 6、Spring 專案必要參考的三個 jar 檔

二、撰寫類別控制程式碼

1. 從 [Project Explorer] 專案視窗內，按下滑鼠右鍵，選擇 [New]  [Class]，在 [New Java Class] 對話框內，在 「Package」欄位內，填入： hr.demo.hsdc；在 「Name」欄位內，填入：員工薪資管理Control。

   
   圖 7、新增 Java 類別 (Class)的對話框

2. 在 eclipse 程式碼編輯視窗內，撰寫下列 java 程式碼：

   員工薪資管理Control.java

   	package hr.demo.hsdc;
   	import java.util.ArrayList;
   	public class 員工薪資管理Control {
   	public float 計算員工薪資(String id){
   	return 0f;
   	}
   	public ArrayList 計算所有員工薪資(){
   	return null;
   	}
   	}

   ＊＊＊ 在這個階段重點是建立程式碼框架，而不是在細節的正確性。所以只要宣告好該控制類別所需要的功能 (method)、參數、回傳值即可；至於 method 內實做的細節，在建立起整個開發環境的框架後，再回頭來補充實做細節即可。(這是 Iteration 作法關鍵之所在，知道每一個階段的重點目標為何)

3. 新增第一個 Java Class 程式後，eclipse IDE 的 Java EE視界如下圖所示：

   
   圖 8、新增第一個 Java Class 後 Java EE 的 Layout

三、新增 Spring Beans 設定檔 (Config File)

1. 從 [Project Explorer] 專案視窗內，按下滑鼠右鍵，選擇 [New]  [Other…]，然後在 Wizard 對話框內，選擇 [Spring]  [Spring Bean Definition] ，然後點擊 [Next]。

   
   圖 9、選擇新增 Spring Bean XML 設定檔

   在出現的對話框內的 [File Name] 填入自訂的設定檔名稱 (在本例中為 beans-config)，並選擇該檔案儲放的位置在 src 目錄下。

   
   圖 10、填入 Spring設定檔名稱與儲放位置

   點擊 [Next]，在出現選擇 XSD namespace的對方框內，點選 [bean] 後，在下方的對話框，改選 XSD 定義為符合 Spring 2.0 (spring-beans-2.0.xsd)，然後點擊 [Finish] 完成。

   
   圖 11、改選符合 spring 2.0 規格的 XSD 定義

   此時在 [Project Explorer] 專案視窗 src 目錄下，即會新增一個 beans-config 檔。在程式碼編輯視窗下編輯該設定檔內容為：

   beans-config:

   	<?xml version="1.0" encoding="UTF-8"?>
   	<beans xmlns="http://www.springframework.org/schema/beans"
   	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   	<bean id="EmpControl" class="hr.demo.hsdc.員工薪資管理Control">
   	</bean>
   	</beans>

   
   圖 12、新增 java spring 設定檔後 Java EE 的 Layout

2. 值得留心的是，若程式碼有用到中文名稱 (如中文類別名稱)，那就必須變更 eclipse 預設的編碼，否則在設定檔內有中文名稱的話，會出現 "Invalid byte 1 of 1-byte UTF-8 sequence" 的錯誤訊息。在 eclipse 的功能表 [Project]  [Properties]，點選 [Resources]，在右邊的「Text file encoding」，把原來是系統預設的編碼，改為 「UTF-8」。

   
   圖 13、改為 UTF-8 編碼，以避免中文問題

四、撰寫控制類別的測試程式碼

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

1. 在 [Project Explorer] 內，選擇 {員工薪資管理Control.java}，按下滑鼠右鍵，選擇 [New]  [Other…]，然後在 Wizard 對話框內，選擇 [JUnit]  [JUnit Test Case] ，然後點擊 [Next]。在出現的對話框內，填入以下資訊：
   • 點選 「New JUnit 4 Test」。 (新版本的測試框架可以根據 Java 5.0 以上版本的新特徵特性來建構；更簡單、易於使用，以及更敏捷的初始化與清理等工作)
   • Package： hr.demo.hsdc.test (端看 Developer 的習慣，這裡是採用將測試程式碼均放置於原始程式碼所在位置的子目錄下)
   • Name：員工薪資管理ControlTest (測試類別命名的建議為 原類別名稱+Test)

   • 勾選 setUp() method (讓測試類別可進行初始化的工作)

     
     圖 14、新增 JUnit 測試程式碼的對話框

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

   
   圖 15、選擇要測試的 method

2. 編輯測試程式碼內容

   員工薪資管理ControlTest.java

   	package hr.demo.hsdc.test;
   	import static org.junit.Assert.*;
   	import org.junit.*;
   	import hr.demo.hsdc.*;
   	public class 員工薪資管理ControlTest {
   	private 員工薪資管理Control control;
   	@Before
   	public void setUp() throws Exception {
   	control = new 員工薪資管理Control();
   	}
   	@Test
   	public void test計算員工薪資() {
   	assertEquals(0f, control.計算員工薪資("001"));
   	}
   	@Test
   	public void test計算所有員工薪資() {
   	assertEquals(null, control.計算所有員工薪資());
   	}
   	}

3. 執行測試。
   在 eclipse 的工具列 (toolbar)中，選擇 [RUN] (綠色右箭頭符號圖示)，在此例中點選「員工薪資管理ControlTest」後，在下方的 [JUnit] 標籤即可顯示測試的結果。 (綠棒代表通過；若有至少一個錯誤，則會出現紅棒)

   
   圖 16、執行 JUnit 測試

＊＊＊ 至此已完成第一階段子目標 ＊＊＊
整個專案目錄備份至 /Stage-1 目錄下。 程式碼下載

※延伸參考
　o Java Spring 簡單範例操作與學習指引〈1〉

對於大型系統利用 DoDAF 規格的架構規劃，其實均有個共同的特點，也就是有多個節點(Node)、多個資訊系統(Information System)。 包括軍事領域的聯合作戰指揮系統、以及政府單位防救災系統的架構規劃等，均是有這樣的特點：如何表達表達多個節點之間的關連性、如何表達多個資訊系統之間的互動。

兩個主要的觀點： Operation View and System View。 又依照每個觀點所涵蓋的層次(layer) 與 功能性質的不同，又分為 OV1~OV7, SV1~SV11。 有趣的是，即使是 Operation View，也會利用如 UML 的循序圖(sequence diagram)，如 OV6，來表達節點之間的動態互動情形。 而 UML 循序圖一般是被用來表達軟體系統內部，參與物件之間的互動合作關係。 其實這隱含什麼意思呢？ 很簡單的道理！ 在 Operation View，也可以運用物件導向分析的手法，與 System View 所不同的只有：一個是把 Node 當物件；另一個是把 System 當物件；但是相同的是：兩者均用物件導向分析設計的思維來作塑模(Modeling)。

依據「DoDAF Deskbook v1」的建議，Architecture View 的開發步驟可以參考如下圖的各種視圖的先後開發順序。 當然，這不會是絕對的，對我而言，在抓這類大型系統的架構時，首要就是要先能界定出系統的整體框架。當把某一個設計的目標框架，界定為一個系統時，就會分 出 "外" 與 "內"，而兩者的分析手法與看待系統的角度就會不一樣了。 "外" 重視的是 "用"，所以會觀察系統所提供的服務，而服務就會衍生出，系統應該提供什麼 "介面(interface" 讓外部的參與者來用；再來 "內" 重視的就是系統的組成元素，這就是屬於結構分析的角度。結構分析觀察的兩個重點是，一個為靜態的結構關係、另一個就是，在動態為了完成某一個 "用" 的功能服務時，會有哪些元素的參與、它們彼此之間又是如何傳遞訊息的。 最終，你就會發現到，到底是如何 "界定" 某一個框架為一個系統，會是架構師最大的課題與其必備的素養了。

圖 1、 摘錄自「DoDAF Deskbook v1 p.2-5」

從上圖中可以看出， 「DoDAF Deskbook」所建議的開發步驟，是以 AV1 開始觸發、以 AV2 涵蓋所有的視圖。 事實上，AV-1 是什麼呢？ "Overview and Summary"。 其實它就是一份 SAD(System Architecture Document)。 文件內容大概就是包含了專案的目的、專案的描述與說明、架構規劃的標的、情境、任務、願景與目標 ...等。 也就是說，在未來展開這個系統的規劃時，範圍與目標均是在該文件所描述的範圍之內。 AV-2 呢？ "Integrated Dictionary"，它就是未來在涵蓋所有的視圖內，經常會使用的術語(terminology)，要能給予一個明確的定義及其該字彙的意涵。

所以， "All-View" 只是文件的報告而已，真正的第一張視圖是 OV1— "High Level Operational Concept"。 這一張也可以說是要能涵蓋所要規劃系統全貌最大格局的視圖了。 它是給指揮官以上的層級所看的概念性視圖，所以儘量不要以技術面的角度來表達這張視圖。 參考下圖：

圖 2、OV-1— 高階概念視圖

前述所提，架構師當能從任何一張視圖，看得出系統的 "外" 與 "內"。 並且在心中就要能轉化的出來能表達出整體框架的設計圖。 哪一張 UML 設計圖最適合被用來表達 "外" 與 "內" 呢？ 也就是說，要能表達的出 系統所提供的服務介面，以及系統內部的組件關係。 UML 合成結構圖(Composite Structure Diagram)，可以說是最適切的表達了。

圖 3、將 OV-1 概念視圖在心中轉為合成結構圖

所以，OV-1 的精要(Essential)為何呢？
利用視覺化的視圖協助高階決策者(如指揮官)，以 「鳥瞰」 的方式來看出系統的全貌 (包括系統的外與內部觀點)。

• 開發的系統為何？ (聯合作戰指揮系統)
• 誰觸發(Trigger)系統作業？ (通信雷達偵測系統偵測到敵空降部隊與敵軍機的來襲)
• 系統的外部支援為何？ (UDA, 台美聯防艦隊)
• 系統的內部組成元素？ (各節點，包括直屬部隊、陸、空軍作戰指揮中心、後勤中心等)

再來，我們就會利用戰情演練與情境描述等，來作為系統的架構規劃，以及持續驗證系統的作業。

戰情演練：
「海防部隊接獲情資，敵軍空降約一個營兵力的傘兵，於 0608:1200 在林口台地附近登陸，並往台北方向推進。約此同時，雷達偵測系統偵測敵 20 餘架戰鬥軍機於 0608:1230 往空降地點方向移動，預計約 10 分鍾後抵達林口台地，準備支援敵空降傘兵部隊。」

情境描述：
我軍聯合作戰指揮部 (Joint Force Commander，簡稱 JFC)，偵察與接收到敵軍來襲狀況，指揮官即刻下達決策命令：

• 即刻派遣直屬衛戍部隊，至敵空降單位守衛迎擊，並以殲滅敵登陸軍為主要作戰目標。
• 協調空軍作戰指揮部 (AirForce Commander，簡稱 AFC)，派遣軍機攔擊，並以殲滅敵軍機為作戰目標。
• 即刻派遣防砲部隊，擔負迎擊敵軍機防禦任務。
• 協調台美聯防艦隊 (Union Defense Armada，簡稱 UDA)，防衛與監控敵海軍艦隊，防止敵艦隊登陸。
• 聯絡陸軍作戰指揮部 (Army Commander ，簡稱 AC)，整備作戰部隊、並緊急動員後備部隊，以備後續支援作戰。
• 聯絡後勤補給中心 (Logistics Supply Center，簡稱 LSC)，派遣前線必要物資，啟動後勤補給戰備支援作業流程。

※延伸參考
　o 聊聊 DoDAF/MoDAF 規格與實作議題。