HSDc. 定於端午節過後的隔一個星期六 (06/14)舉辦為期九週共 54 個小時的系統分析暨實作課程。底下是該課程介紹與課程大綱，相關的課程資訊，亦可參考：
http://www.hsdc.com.tw/course_signup/20080614_sa_sd_to_implement_by_java

【台北場】2008/0６/１４ 起，每週六白天，每次上課為六個小時(AM 9:30~PM 4:30)，共九個星期。
o 預定上課日期：0６/１４, 06/21, 06/28, 07/05, 07/12, 07/19, 07/26, 08/02, 08/08 。

HSDc. 於 2008 年度推出了完整的系統分析、設計至實作的課程，期能協助軟體開發人員在現實的工作中，能瞭解完整的開發流程與各個角色的工作執掌與產出。在基於以架構為中心來建立團隊具共識的整體觀下，能聚焦在適切開發單位的功能點內，快速地從需求分析導出到實作，找出並克服開發過程中，包括溝通、技能與技術等風險因子。而後基於這樣的框架目標內，得以對系統的結構作重整，卻又不至於影響已有的功能前提下，得以對程式碼施以重構的技巧，讓系統更有延展度與彈性。

傳統系統分析與設計的課程，經常是「昧於現實」，將需求分析/結構設計與程式碼實作拉得太遠，而造成軟體設計與實作的不一致。殊不知，所謂的軟體塑模與程式碼的實作必然是軟體系統的一體兩面，在軟體開發過程中，必然是要保持一致性，所以設計是要作精，而不是籠統的文件報告。關於文件，只是利用工具的文件產出功能，將平時已確實所作的設計，產出美輪美奐的文件報表而已。不要為文件而文件，還去加班熬夜，傷了身體，又浪費生命在不必要的地方，實在沒有意義。

還有系統開發與實作也不是「妥於現實」，利用 IDE 工具從 Web/Windows Form 直接連接資料庫的這種開發方式，只是讓軟體人員變得更笨，只要需求變動就導致牽一髮而動全身，系統是不會有任何的延展與彈性的。最起碼的一點設計良心，又能處在國內嚴苛的環境中，對於短線時程的專案，先將系統的命脈—企業邏輯的核心，全給統籌集中在中間層，也就是企業邏輯層—先求有！ 再來才是求好！— 待系統能確實上線，能滿足使用者的需求後，再則老闆與客戶對開發團隊有了信心，肯給予更多的資源—包括人跟錢，團隊的技能也有了增長與更好的溝通默契。外在與內涵的條件均俱足下，就可以專致於對系統結構的重整，並對程式碼施以重構的技巧，而又不會影響既有的功能前提下，讓系統更具可重用性與延展性，甚而轉成產品以服務更多同類型性質的客戶，又能快速的客製化每一個單位的特殊化需求。

基於這樣的理念，我們主張系統分析與設計是要「務實」，不是「昧於現實」，也不是「妥於現實」，而是在現實與理想中找到那一個平衡點。所以課程規劃是分為兩個階段。第一個階段就是捕捉系統功能需求，快速設計，立即產出程式碼。重點就是要瞭解如何作好系統的需求分析與對應到程式碼的實作。本階段需要培訓的技能有物件導向的基礎知識、從使用者角度看待系統時的外部功能分析，抓出適切的功能點開發單位、從畫面、中間層物件到連結資料庫的實作能力等。還有，一定要配套的兩個設計措施，一為撰寫測試案例與功能測試程式碼，實現自動化的測試機制；另一為活用分析類別，先利用中間層的控制類別，集中與控管從畫面與資料庫而來的企業邏輯。 第二個階段就是傳統系統分析所說的 SD(System Design), 傳統是以資料庫的 E-R(Entity-Relation) 分析，在物件導向則是稱為領域模型的建立—包括找出物件與適切的分派責任。這可不是一件容易的事，事實上應該說要具備的抽象能力要相當高，所以為何我們覺得那種 SA->SD->PG 開發流程是不務實的，因為 SD 很難作得好，然後還要 PG 去等該階段的產出，又大部分是不正確，可以說是浪費開發資源與時間。程式碼可以直接反應功能的需求，但不一定要等結構分析，集中在控制控制類別的好處就是，我們可以很容易地對結構作重整、對程式碼作重構，卻又不會影響既有上線的功能。本階段的重點當然就是對所謂結構的分析技能培養，我們會兩種方式，一為從需求抓名詞的傳統方法、另一為揭露出以交易為核心的交易樣式，可以輕易地抓出一大串的企業元件。

總的來說： 作好功能需求分析-> 影響系統能不能做出來 ； 作好結構分析-> 影響系統有沒有彈性

觀念的傳授、設計的圖形化塑模表達、程式碼的實作三層次，是我們對於系統分析設計與實作課程的基本原則與態度。修習本次系統分析的學員們，也可以拿到完整的教材、完整案例的 Model 檔與實作程式碼的對應。程式碼是以 Java 再搭配最夯的 JSF/Spring/Hibernate Framework，當然，要直接對應 .NET 的實作程式碼，那也是相當直覺不是難事。我們期能讓學員們上完課後，能以我們所提供的案例，包括設計模型與程式碼，當成範本而可以應用於工作實務上，甚而可以創造所屬自己的 "Pattern"。 HSDc. 軟體開發團隊，關心每一位軟體人員的持續成長．．．。

§ Iteration #1 (36 hrs)
o 課程階段目標： 捕捉系統功能需求，快速設計，立即產出程式碼

一、軟體開發方法論—開發流程與塑模 (6 hrs)
　o 開發模式的介紹
　　o 瀑布、循序的典型開發模式
　　o 漸增(Iteration)與漸進(Incremental)的主流開發模式
　　o 主流開發流程的簡介 — RUP/XP/AGILE
　o 簡介專案開發的工作流程
　　o 專案中各個角色人員的工作執掌
　　o 專案中各個階段的產出(artifacts)介紹
　o 軟體開發的最佳實務
　　o 以架構為中心(architecture centric)的開發
　　o I&I(Iteration and Incremental) 漸增與漸進
　　o 視覺化的方式設計軟體模型 (Visually Model Software)
　　o 需求的變動管理與持續驗證軟體的品質
　　o 侷限與收斂軟體的變動性
　o 軟體塑模— 統一塑模語言(UML, Unified Modeling Language)的綜觀介紹
　　o 利用完整案例導引來介紹 UML 的十三種圖形

二、物件導向觀念養成與應用 (6 hrs)—觀念、模型與程式碼的三面表達
　o 介紹「概念(concept)」與「抽象(abstraction)」的觀念
　o 確實瞭解「類別(class)」與「物件(object)」的區別與關係
　　o 結合(association)、組合(aggregiation)與
　　　一般-特殊化(generalize-specialize)關係的說明
　o 封裝(encapsulation)與多型(polymorphism)的設計觀與應用
　o 瞭解繼承(Inheritence)與介面(Interface)」的設計原理
　o 程式碼範例—
　　o 利用 Java 程式碼表達類別的結構關係(結合,組合,一般-特殊化)
　　o 利用 Java 程式碼呈現介面與多型的設計實作

三、需求面的功能分析設計—Modeling by UML 三劍客 (15 hrs)
　o 建構使用案例模型，實現企業流程的需求
　　o 利用使用案例圖表達系統的功能需求
　　　o 如何界定系統範圍(System Boundary)
　　　o 如何找出使用案例與參與者(Actor)
　　　o 使用案例之間的關係— include and extend
　　　o 利用使用案例圖表達架構觀點
　　o 從表達企業流程(Business Process)的活動圖導出到使用案例圖
　　o 使用案例敘述(Description)的寫作實務
　　　o 如何寫出高品質的使用案例敘述
　　　o 如何依據使用案例範本完成使用案例敘述的撰寫
　　　o 如何表達正常、替代、擴充與例外事件流程的敘述
　　　o 寫好每一條動作步驟陳述的要領
　　o 針對每一個使用案例，撰寫測試案例 (Test Case)
　　o 利用 EA "Document Generation" 機制產出美輪美奐的需求報表文件
　o 使用案例的實現(Realization)與實作(從使用案例到循序圖到產出程式碼)
　　o 利用類別圖設計與創建 Use Case 控制物件，以實現使用案例的功能需求
　　o 利用循序圖表達程式碼物件的互動設計
　o 利用 EA "Code-generation" 功能產出控制物件的程式碼框架
　o 測試先行—在 IDE 工具內撰寫該控制物件的測試程式碼
　　o 利用虛擬碼(Pseudo Code)撰寫程式碼內部的細節
　o 實際執行應用程式碼的部署與執行功能測試
　o 利用 EA 反向工程功能，在 IDE 環境內修改程式碼，並反轉(Reverse)回 UML Model。

四、實做面 by Spring Framework (9 hrs)
　o Spring Framework 綜觀介紹
　　o 輕量級(light-weigh)的應用系統容器架構介紹
　　o Spring 在實體 3-tier 的角色定位與架構設計
　　o Spring 重要特性介紹，包括 IOC與相依性關係、Domain-driven 的設計設計觀
　o 利用 JSF(Java Server Faces) 實做 Web Form
　　o 將 UI 與企業邏輯確實分離的基礎設計觀
　　o Web 表單連結至中間層控制物件，實現 MVC 設計樣式
　o 利用 Hibernate 實現永續性機制
　　o Hibernate 設定與實作
　　o HQL 語法與 O-R Mapping 原則
　o 從中間層控制物件連結資料庫
　　o 利用 EA 快速建構資料庫表格
　　o 利用 Java 撰寫程式碼 (從控制物件透過 Hibernate 連結 DB)

五、案例分析與實作 - Iteration #1 (實做部分涵蓋於上述課程內)
　o 利用 EA UML 工具
　　o 實做使用案例模型(Use Case Model)、類別圖與E-R圖、循序圖
　　o 利用 Code-Generator 機制，產出程式碼框架
　o 利用 Java Eclipse IDE 撰寫
　　o JSF Web 表單
　　o Java 控制(Control) 物件 by Spring
　　o Java 資料存取物件(DAO) by Hibernate
　o 利用 JUnit 撰寫功能與單元測試程式碼
　o 應用程式的部署(Deploy) - JBoss Application Server

§ Iteration #2 (18 hrs)
o 課程階段目標： 重構程式碼與類別結構，讓系統更有彈性。

一、軟體結構面的分析與設計 (12 hrs)
　o 運用交易樣式(Transaction Patterns)找出核心交易物件
　　o 從使用案例的敘述中找出潛在的概念物件。
　　o 利用 Peter Coad 的交易樣式(transaction pattern)
　　o 利用 UML類別圖 建構領域的物件模型
　　o 從類別圖產出資料庫表格，並利用 EA 部署至資料庫
　o 物件的責任分派(responsibility assign) — 屬性與行為的分析
　o 活用設計樣式(design pattern)
　　o 合成(composite)樣式的設計 — BOM 表的最佳呈現
　　o Facade and Adapter 樣式，表達在 Control and Boundary 物件的設計原則
　o 進行分析類別(Analysis Class)的設計
　　o Control 物件
　　o Entity (Business)物件
　　o Boundary 物件

二、程式碼的重構 (6 hrs)
　o Java Spring 的進階設計觀
　　o IOC 與 相依性的分析。
　　o Domain-driven 的設計原則。
　　o AOP 對非功能性需求的 crosscut(橫切) 與 Concern(考量)的設計觀念。
　o 分析類別在 Middleware 的實現
　　o 實現 Controller by Java Spring
　　o 實現 O-R Mapping by Hibernate
　　o 實現 企業物件 by POJOs(Plain-old Java Objects)
　o 利用委託(delegate)的設計原則，從控制類別分派責任給企業物件

三、案例分析與實作 - Iteration #2 (實做部分涵蓋於上述課程內)
　o 利用 Eclipse 重構程式碼結構
　o 利用 EA 更新類別與E-R圖，並重新部署 DDL DB Schema 至 MySQL DB 內
　o 利用 EA 實現正反向工程，達成程式碼與 Model 的同步
　o 利用 Iteration #1 所撰寫的測試碼驗證與修正被重構的程式碼

§ 整體開發流程總複習
　o 檢視兩個循環(Iteration)開發所各自產出的設計圖與程式碼
　o 回顧每一個流程開發階段的產出與所運用的設計、技術與技能
　o 學員課程中的問題提問與回答總整理

§課程名稱： 系統分析設計與實作—活用 UML 塑模 與 Java (５４ Hrs)

§課程簡述：
o 本課程引導與協助學員先對系統開發流程有全貌的認識，並傳授軟體設計必備的基礎功夫，然後才去了解如何利用 UML 表達設計思維，從系統外觀與結構等各個構面產出有效的設計。並強調馬上就可以從設計導出符合 J2EE 的實體三層式架構，還利用了最具彈性的 Spring Framework，結合 JSF 與 Hibernate，開發出高品質的 Enterprise 系統。快速產出程式碼(包含功能測試碼)的目的在於可以應付專案的交付，並且可以提昇團隊的信心(眼見為憑)，然後在第二個開發的循環(Iteration)，將程式碼重構，專注在系統的結構重整，而得以讓整體系統俱足彈性、延展性與可重用性。

§課程特色：
　1. 帶領學員實際走過(實戰練習與操作)兩個開發循環(Iteration)：
　　　o #1. 從使用案例轉循序圖，快速產出程式碼 — 實現系統功能，提昇團隊信心。
　　　o #2. 重構程式碼，活用設計樣式(design pattern)，專注核心結構設計 — 讓系統的結構更有彈性。
　2. 贈送電子教學光碟：
　　　o 讓學員可以帶回家，透過自動安裝方式，即可擁有實際的開發平台與應用系統。
　　　o 包含了 Linux, J2EE Frameworks, JBoss, Eclipse IDE, 以及具體可執行的應用程式與原始程式碼。
　3. 提供最少兩個完整的案例研討(Case Study)，自然又流暢地整合：
　　　o 開發流程，包含了各階段的設計產出(artifacts)與文件。
　　　o 系統分析與設計 — 提供 UML Model 檔。
　　　o 應用程式的實作與部署 — 提供每一層(tier)的原始程式碼。
　4. 本課程均保留與提供了學員免費再旁聽乙次同樣課程的權利，以一次低廉的收費，就可以擁有兩次上課的收穫，課程的師資、內容與品質，我們有信心是不會讓學員們失望的。

§課程目標：
　1. 讓你瞭解：
　　　o UML 2.0 各類設計圖的設計意涵與應用。
　　　o 軟體設計必須修練的哲理，包括物件與類別、封裝、介面與多型等觀念。
　2. 讓你知道：
　　　o 軟體開發流程的全貌，包括了開發人員的角色與職責，以及各階段的實際產出。
　　　o 如何利用 RUP 流程框架，制訂敏捷式(Agile)的開發流程，來找出適合自己團隊性格的流程。
　3. 讓你活用：
　　　o UML 三劍客，包括表達系統需求與功能的使用案例，表達系統靜態與動態結構的類別及循序圖。
　　　o 只要能寫好使用案例，就可以確保直接快速產出程式碼。
　　　o 如何利用正反向工程，來保持 Model 與程式碼的一致性。
　4. 讓你學會：
　　　o 如何應用 Spring Framework 在 J2EE 3-tier 的整體架構設計，包括：
　　　　o 如何利用 JSF 設計 Web UI 程式。
　　　　o 如何利用 Hibernate 設計永續性物件，並連結 MySQL 資料庫。
　　　　o 如何利用 Java Bean 設計企業物件。
　　　o MVC 層次分明的物件合作與連結 — 從 Web 至 Middleware 至 Database。
　　　o 如何善用 EA UML 塑模工具與 Java Eclipse IDE 工具的整合。
　　　o 如何作好驗收測試，包括撰寫測試案例與利用 JUnit 撰寫功能測試碼。

§使用工具：
　o EA(Enterprise Architect) 7.1(Trial) UML Tool、JDK 1.6、Java Eclipse IDE、JBoss Application Server (均會附於教學光碟內)。
§授課講師：
　o 賴信仁(Ringle Lai)、王克明(Kenming Wang)、宋敏如(Cathy Sung)、鄒順安(Steve Chou)。
　o 擅長以非常淺顯易懂的比喻及說明，將複雜的系統抽絲剝繭，重新釐清脈絡，讓學員一清二楚，並善於引導學員具備設計應有的反思能力。
§適合學員：
　o 系統分析/設計(SA/SD), PM, Programmer 等在職軟體開發者。
　o 學校資訊講師/在學相關資訊科系學生。
　o 學員最好有基本的程式設計能力(基本即可)。
§課程費用：
　o ＄１４８００ (含稅)。 (同等課程原價學費為 ＄２５,０００ 以上)
　o 曾經上課過本公司的「單元系列課程」學員，優惠 ＄１２８００ (含稅)。 (請記得註明為舊生，本公司查詢確認即以優惠算)
　o 三人同行，或同時報名另一單元課程，亦比照舊生的優惠折扣，每位只需＄１２８００ (含稅)。
　o 大學/研究所 資訊相關科系講師、助教或教授，出示相關證明，我們會以建教合作方式計費。(請另以電話聯絡)
　o 清貧或由家扶中心推薦，能出示相關證明，所有費用 免費！！

§報名資訊：

授課日期：
　o 2008/06/14 起，每週六白天，每次上課為六個小時(AM 9:30~PM 4:30)，共九個星期。課後並留半個小時供學員自由提問。
　o 預定上課日期：0６/１４, 06/21, 06/28, 07/05, 07/12, 07/19, 07/26, 08/02, 08/08 。
　o 遇國定假日或颱風等因素，則延至下一週上課日(本中心會主動通知學員)，以此類推。
授課地點：
　o 開羅會議中心，地址：台北市光復南路65號B2 (光復南路、市民大道交接口)。
　o 參考交通與地圖。 http://www.hsdc.com.tw/education/cario_map

o 由於本站線上報名系統尚未測試啟用，煩請報名學員填寫下列資料報名 (下列欄位前為 * 者請務必填寫)，並以 Email 寄至： service.hsdc@gmail.com
　　-------------------------------------------------------------------------------------
　　* 姓名：
　　* 電子郵件：
　　* 聯絡電話：
　　任職公司與職位：
　　備註(請填上如 ATM 轉帳帳號(後五碼即可)與新生或舊生等資訊)：

　　-------------------------------------------------------------------------------------
　o 報名經確認後，本站即會寄送確認通知信給報名學員。
　o 報名系統分析與實作班學員，請先以 ATM 轉帳預約費用($1000)，並請於報名表備註欄位內，註明您的轉帳帳號末 5 碼與轉帳金額。
　o ATM 轉帳帳號： 新光銀行 (103)　帳號： 0772-50-100979-9
　o 本課程上課學員需滿 20 人以上，若未達上課人數則延期至下一梯次開課，已報名學員，本中心會電話通知，並主動辦理退費(或可保留至下一梯次)。

副標題：紮實的物件導向設計基礎功夫是奠定系統彈性穩固的基石。

Object-Oriented Methods A Foundation 　----------------------------------- 　作者／James Martin/James J.Odell /著 　出版社／Prentice Hall PTR 　ISBN／ 013-905597-5

內容簡介
This book presents those concepts and techniques that support almost any system development approach--whether it involves computers, people, or machines. It considers object structure, object behavior and more advanced concepts such as composition, structural constraints, rules, using rules and diagrams, meta-modeling, and power types. Shows how to represent OOA constructs--modeling object structure, modeling object behavior, modeling state transitions and event diagrams, scenarios. Outlines considerations for design, discusses object-oriented programming, and considers object-oriented design and "instant" CASE. --This text refers to an out of print or unavailable edition of this title.

前言

截至目前為止的書評，我發現到並沒有真正介紹到適合於初學者的軟體入門書籍。大部分所介紹的還是偏向實用性的設計類叢書，即使如 Booch 那本 OOAD，雖然是理論基礎用書，但那本其實難度不低，用字又艱深。事實上，所謂的「物件導向」基礎入門書，要能寫得好，其實非常困難。作者除了觀念要相當透徹外，用字遣詞又要言簡意賅，把複雜的事情簡單的呈現，並不是一件容易的事。不過本次的書評— {Object-Oriented Methtods}，兩位作者均同名為 James 的 Martin and Odell，寫出了絕對會是留名軟體青史的代表性著作。即使許多讀者會恐懼於閱讀原文書籍，但本書的英文用句，真的相當淺顯，不太懂文法也是可以讀起來毫不費力。誠如作者在前言裡所提及適合於本書的讀者程度，並不需要具備任何的前置知識，包括程式語言等。更為誇張的是，他們說書中諸多元素用語，已被用來教導約七歲年齡的孩童。這讓我想起，曾經在某購書網站看到，{UML 精華} 那一本書，適用對象竟然是寫為國小程度，哈，許多軟體人員真的是有夠汗顏的了。(其實那是網站筆誤的)

Martin & Odell 可是 OO軟體業界早期相當具知名度的先驅，他們的著作甚多，Odell 除了是物件導向社群的領導者外，也是 OMG UML 規格制訂的主席；而 Martin 看他寫作的資歷，你真的會嚇一大跳，從 1960 年代開始，我都還沒出生的時候，就已經出書了，至今已發表超過 100 本以上的專業書籍，包括軟體、資料庫、電傳通訊、即時性系統等，所涉獵的專業範圍實在廣泛。至今他除了在知名大學教授外，還仍茲茲不倦地研究與寫作。我真的好是佩服，這才是真正致力於軟體之道的大家啊。

清晰明確的術語定義，才能奠定 OO 紮實的基礎

本書共分為六大部分，剛好整整 400 頁，厚薄適中。最後一部份為附錄，除了語法的說明，還有一個訂購系統的分析範例。另外最值得推薦的是附錄D (Toward a Formalization of OO Analysis)，是以論文的型態闡述了關於分類的關係、一般化/特殊化、功能/屬性/角色 等在分析過程中，經常會運用到的基礎技能。

第一章是對泛OO系統的概念性介紹。而在前兩部分章節，則為 基本OO的基礎知識。第一部份(2~11 )介紹物件的結構(structure)、第二部分(12~17)介紹的是物件的行為(behavior)。我覺得第一部份可以精讀，那真的是奠定最為紮實的理論基礎了。例如，我們經常說開發的是所謂的物件導向式系統，好吧，那你能否明確的說明出分析的物件從何而來？ 再問一個更“俗”的，能不能定義出什麼是物件呢？ 嘿，許多軟體人員還會愣住，無法回答出來呢。第二章開宗明義就指出，物件源自於概念(concept)，“An Object is anything to which a concept applies. It is an instance of a concept. (物件是概念可以被應用的任何事物，它是概念所呈現的個體)”。 由此定義也可以得知，“物件”與“個體(instance)”這兩個術語，其實是具同義詞性質的。將“概念(concept)”作為認知的對象時，所產出的“個體(instance)”即為物件。但概念會牽涉到人們對於觀點、角度等認知，而會有不同的體認。例如站在遊客的角度，他所看到在森林裡面的樹木，是一個個的“個體”，會從樹木之外的角度來欣賞樹木的茂盛與宏偉，是一種整體性的認知；但站在植物學家的角度，他要研究組成樹木的結構元素，所以會把樹木分為“樹幹”、“樹枝”、“樹葉”、“樹根” 等多個組成樹木的“物件”，從結構的觀點來研究樹木的內部組成。這同時也就代表了，雖然到處都是物件，但並不是任意地將物件給“塞”入軟體系統內，物件導向的設計，是將問題領域(problem domain)的概念，呈現與對映(mapping)至軟體系統內，那麼，如何正確地捕捉(capture)問題領域的概念成為物件，就成為是軟體設計中，最為重要的技能與素養了。 你可以看看，當你能對這些基礎概念術語有很明確的定義時，你就可以很容易地衍生出諸多看來好像很複雜的呈象，但卻又不會違背這些基本的原則。我常戲說，練好這些軟體蹲馬步的基本功，才真正夠得上是武當名門正派的正宗內功！

當能分辦出 物件與類別的區別後，然後再進而瞭解類別之間普遍的三種關係：關連、整體/局部、一般化/特殊化 。透過關連，我們可以分析類別的相依性(dependency)，以瞭解耦合(coupling)的程度；透過 整體/局部，我們可以封裝(encapsulate)細節，並以整體的服務呈現給 client；透過 一般化/特殊化，我們把相同的部分抽象出一般化類別，而把特殊或需要擴展的行為分別實現在特殊化的類別，而造成所謂多型(polymorphism)的效果(這也是程式語言中常稱之所謂的繼承)。再來論及的是物件的行為面。從對狀態(state)的說明，然後到狀態的轉移，而發生轉移的觸發(trigger)即是所謂的事件(event)。所以當然就會需要瞭解到事件的種類、事件的處理等，而這也是在當今元件化的系統，在動態期間常會需要用到的機制，在設計上也是相當重要的範疇。

第三部分(18~23)是OO進階的介紹，這裡提及到了限制(Constraints)，也就是在類別關係之間如多重性是如何的表示；還有提到了規則(Rules)的表達，是如何呈現在設計圖上。我是覺得這類議題反而比較偏向細節性，倒是不一定要規範如此嚴謹，我是比較主張設計盡量活潑彈性一點，再慢慢地抓出團隊設計的共識即可，至於嚴謹性，倒不如在程式碼驗證即可。

第四部分(24~29)是關於物件導向分析(OOA)的說明。由於這裡涵蓋的議題太過廣泛了，諸如需求面的功能分析、結構面的類別設計、實作面的物件互動等，短短幾個章節不可能詳述清楚的。這裡我也只是大概瀏覽過即可，然後再對上述各個主題，從別的專書中再深入去探究。

第五部分只有一章(30)，主題更是嚴肅，設計與實作的考量。開玩笑，一大堆所謂的物件基本教義派就是“掛”在無法將他們理想中的設計具體化呈現在現實的技術平台上，例如所謂的“O-R (Object-Relation) Mapping”，每種平台的實作都不一樣，那也是要相當去深入研究的；還有諸如交易控管、權限控管、分散式 …等，這些都是在實作上必然要面對的挑戰，10 本書都不一定介紹得完，遑論僅有一章？

軟體非“以用為本”

本書在 Amazon 也是頗受佳評的四顆半好書，印刷尤為精美，是我目前唯一有著紅與黑的兩色印刷書。除了 UML 設計圖外，還有許多生動有趣的插圖，佐以解釋主題的呈現。最好是不要抱著從“用”的角度來看待此書，那麼你可能會失望，因為它不一定能馬上讓你可以應用在現實的工作上。當你好奇於為什麼主流的程式語言都採用物件導向式的實作機制、為什麼系統分析/設計也強調所謂的 OO 思維，到底 OO 是要協助來解決什麼樣的軟體設計議題 …，還有當你真正有志於從事軟體專業之路時，本書絕對是修習基礎內功的必備聖典。

這一次倒不是要 "批判" 博X來的訂購系統，而是想藉由該資訊系統，來聊聊需求分析的設計議題．．．

我們知道，博X來的訂購系統，存在的最大價值，就是提供客戶「訂購商品」的服務，而為了滿足客戶最終能買到所訂購的商品，所以會有包括如「放入購物車」、「快速結帳」等程序。如果妳是一位需求分析師(RA, Requirement Analyst)，那麼在分析以使用案例 (use case)為功能點單位 (functional point)的時候，妳會分析出 "多少顆" 使用案例呢 (只涉及到上述討論訂購商品的範圍)？

我經常思考這類的需求分析議題，也曾就該問題與其他資深分析師討論，有人認為是兩個，也有人認為是一個，當然也有人認為是三個、四個...等。 好像是見仁見智，沒有所謂標準明確的答案。 我是在想，能否有一種簡易判斷的 "準則"，來決定使用案例是一個或多個呢？ 老實說，從諸多國外名家 (包括創始者 Ivar Jacobson)對使用案例的定義，我仍不容易釐出那個準則，所以我是想透過觀察使用案例的行為，來找出那個判斷的原則為何。

先觀察實體書店一般的購物程序：客戶走入書店，瀏覽與選擇欲購買的商品 (書籍)，並放入購物籃內 (拿在手裡也算，代表已準備好欲購買的商品)，並拿到櫃臺，結帳並付款。

所以幾個使用案例呢？ 我肯定是認為一個：《購買商品》，因為客戶來這個系統 (實體書店)的主要目的就是 購買商品，而為了滿足該目的，他必須經常放入購物籃、結帳等程序，而且整個交易事件的程序 (從放入購物籃到結帳)是有持續的，約幾分鐘到幾個小時就可以完成 (＊注意此點)。關於傳統書店使用案例圖的表達，可以參考下圖1。

圖 1、實體書店購買商品的使用案例圖

在使用案例圖的表達上，看起來好像是三個使用案例，其實本質上只有一個：《購買商品》。這裡利用《include》這個 stereo type，只是來凸顯《放入購物籃》與《結帳商品》這兩個子程序而已。

再回到博X來網路訂購系統來看，那麼是否訂購商品的程序與傳統實體書店的購買商品程序是一樣的呢？ 看起來很像，都有 放入購物籃 (網路上稱為購物車) 與 結帳 兩個程序。只有一點不一樣，放入購物車 與 結帳 可以是兩個不同時間點的交易事件。什麼意思呢？ 當客戶瀏覽商品資訊，若是看到打算購買的商品，就把它放入到購物車內，但是客戶並不需要馬上結帳，他可以等過幾天再決定是否結帳。所以很明顯的觀察到，這是兩個可以在不同時間點個別可以獨立完成的交易 (＊這一點與實體書店不一樣)。 (不過，這兩個交易事件好像又有些關連存在，要 結帳 前必須先有商品 放入購物車，關於此點，留待後述來討論。)

所以，我的觀察與心得是什麼？ 我會以為，若是可以獨立在某個時間點可以完成的交易事件，我會把它就視為是一個使用案例。或者再用更通俗的一句話來說，就是參與者在使用這個系統，從上線到離開的過程，可以 "一氣呵成" 地來完成一個功能案例，該功能案例就可以獨立成為一個使用案例。 所以，博X來訂購系統對於 訂購商品 的主要目標上，會有幾個使用案例？ 我是會把它切為兩個：《訂購商品》與《結帳商品》，參考下圖2。

圖 2、博X來訂購商品與結帳的使用案例圖

為何使用案例是命名為《訂購商品》而不是 放入購物車？ 我會從 參與者 (Actor,本案例為客戶)的角度來看，客戶的目的是訂購商品，而放入購物車只是在訂購程序中的其中一個子程序。同樣地，這裡也是利用《include》來特別凸顯 放入購物車 這個重要且必要的程序； 而在《結帳商品》這個使用案例，客戶的目的的確就是要處理結帳，所以命名上這樣是適合的。但是因為如前所述，這兩個使用案例又有某些關連存在，可否使用《include》來表達這兩個使用案例的關係？ 不可，絕對不可！！ 我很肯定此點，從使用案例圖來看時的一個最大迷思就是，許多 RA 會以為被《include》的那個使用案例是另外一個使用案例，其實不是。 再強調一次，參考如圖2所示，《訂購商品》 "包含 (include)" 《放入購物車》，它們是同一個使用案例！ 要表達兩個完整獨立使用案例的先後順序關係其實很簡單，就是在《結帳商品》這個使用案例敘述的 precondition 欄位中，說明使用該使用案例前，必須先完成《訂購商品》的使用案例即可。或者也可以直接這樣描述：要使用這個使用案例前，在該用戶的購物車內必須要有待結帳的商品。

另外，依照該訂購系統的實際結帳程序來看，我也會在案例圖上特別來凸顯兩個子程序： 選擇付款方式 與 更新基本資料。 前者是必然需要執行的程序，所以是利用《include》來表達；而 更新基本資訊 則是不一定需要執行，所以是利用《extend》來表達它是一個可具選擇性 (option)的子程序。 然後在 選擇付款方式 這個子程序上，因為它可以具有多樣化的付款方式，所以在該子程序的文字敘述上，只會在這個子程序上描述付款的基本行為，然後會在各種的付款案例上再來描述個別的付款行為。利用《extend》來關連主程序會來得有彈性許多，未來若是又有新的付款方式的需求，那麼只要再加上一個特殊化的子案例即可。

利用 "一氣呵成" 這個原則來判斷是否為獨立的使用案例時，要注意的前提是：系統必須是軟體資訊系統，而不能是企業，也就是把企業當作系統來看待。 探究其原因就是對於所謂什麼才叫做是一個完整獨立的交易事件，軟體資訊系統與企業的界定方式並不一樣。 在軟體資訊系統，一個獨立的交易事件可以是幾分鐘到幾小時，但是再長似乎就不適合了 (事實上，對於 EC 系統，連幾個小時都可能不恰當，交易時間仍嫌太長)。而對於企業層級的使用案例，所延續的時間會相當長，甚至可能長達數十天、數個月。例如把「信仁慈善醫院」當系統，《看病》是一個完整的使用案例，但是看病的過程可能包括了掛號、看診、領藥等，這些程序可以綿延好幾天，所以利用 "一氣呵成" 來判斷就不適用了。那麼要如何判斷企業層級的使用案例呢？ 我是以為，從使用案例的 "價值" 來判斷，可能會比較恰當。想想看，雖然是「信仁慈善醫院」，但它仍需要要營收，而營收的主要來源正是病人來看病所得來的，所以 "看病"，會是一個很明顯有價值的企業層級的使用案例。

※ 延伸參考：
　o 再論 博X來「選擇 7-11 門市」功能設計
　o 實在難以忍受的網路購書流程

先前因為在 博X來 訂購書籍的過程時，卡在選擇 7-11 門市的小功能這邊(據稱當日有部 Server 故障)，有感而發寫了篇：「實在難以忍受的網路購書流程」。不過不滿歸不滿，後來我還是在該網站陸續訂購了有約 10 來本書籍，可以說是他們的忠實客戶。倒是後來該篇文章有許多網友們的諸多回應，其中也有提到了 EC系統整合 的議題。 系統整合？ 一開始看到我還稍微愣了下，雖然我本身的工作就是專注在軟體系統的架構整合，不過我倒是沒想過 {選擇 7-11 門市} 這個小功能有如此慎重。因為，從單一目的來看，真的很單純，就只是 {提供 7-11 門市} 的資訊，在這個時間點可沒有涉及到還有物流出貨什麼的，那是等系統收集到完整的訂購資訊之後，也就是真正客戶按下 {確認訂購} 按鍵之後，訂購系統才需要去處理的工作。但在收集訂購資訊的過程中，只要能取得如 門市代號, 門市名稱等未來可供出貨參考的資訊即可。可不要在此時就把出貨流程給牽扯在一起，諸多熟悉領域知識的 SA，有時候就是想太遠了，常常會把簡單的事情給複雜化。

不過，平心而論，該功能雖小，但就從系統責任分派 (responsibility assign)的角度來看，誰需要提供 {7-11 門市} 的資訊？ 統X EC系統。所以自然這就牽涉到了 「博X來訂購系統」 與 「統X資訊EC系統」兩者系統之間的整合，這是合理的。只是，以目前 統X資訊 是尋求從 Web 端網頁之間的互通來達成擴展服務的目的，技術上是可行沒錯，但就是給我一種 "說不出的古怪" 的感覺。思考系統整合的意義：「 系統整合，講究的是以服務為導向 (service-oriented)，透過標準界面 (interface)讓系統彼此之間互通，以達成能擴展更多樣化、效率、彈性的服務為目的。」 統X資訊 是服務的提供者 (service provider)沒有錯，但是，它是提供 "透過各種查詢的方式來取得 7-11 門市 的資訊"，卻沒有必要連 Web UI 使用者介面都要干涉參與。這感覺好像是本來是在 博X來 填寫結帳程序表單時，給 "綁架" 到了 統X EC系統，逼著點選門市資訊後，再給你送回原來的表單畫面，相當的不協調。 UI 最好是由提供主要服務的系統來統籌管理比較理想。在此例明顯就是由 博X來 的訂購系統來負責；而使用者在填寫表單與取得相關服務的過程中，不需要也不會知道這些服務是由哪些系統提供的，使用者只要知道現在幫他統籌服務的那一個系統 (訂購系統)能協助完成他的目的即可，而未來服務的提供者在後端換掉，也不會去影響到前端的 UI 畫面，這是系統整合設計的基本思維。 我是這麼以為，系統整合重視的不是在 UI 層的整合，而是回到源本，系統服務是由擔負企業邏輯 (business logic) 的中間 (Middleware) 層來負責的，自然，整合的焦點應該就是位於系統的中間層，這會比較合理，也會來得有彈性得多。 透過本案例，我想也可以分享一下，所謂的中間層是大概如何的作法，未來又可以有什麼樣的擴展彈性。

參考圖1，這是利用 使用案例圖 (use case diagram)來表達功能需求的觀點。使用者的主要目的是 "訂購書籍"，訂購的程序必然會 "包含 (include)" 《結帳》 的程序。而在《結帳》這個程序中，只有當你選擇 "至門市取貨" 時，才會使用《選擇 7-11 門市》這個子功能，所以在圖上的表達是利用 "extend" 這個 stereotype 來表達《結帳》與《選擇 7-11 門市》案例之間的關係。 當使用者要選擇門市時，門市的資訊是由 統X EC 系統來負責，在圖上是利用表達外部系統的參與者 (actor)來表示。

圖 1、博X來訂購系統《選擇7-11 門市》使用案例圖

先來看一下目前 博X來與統X 的作法，參考圖2 的循序圖。結帳的表單是由 博X來 訂購系統提供的，當要選擇 7-11 門市時，它會重導向 (Redirect)到 統X EC系統 所提供的網頁表單，讓使用者選擇完門市後再將所點選的門市資訊傳回原來的結帳表單。

圖 2、博X來利用網頁重導向方式選擇 7-11

再來看看透過中間層的作法，參考圖3 (這是一個比較精簡的作法，只凸顯加上一個控制物件而已，而在實務上，我是還會再加上如 "Query7-11_Adapter" 這樣的 Boundary 物件。另外，這裡也先忽略了與內部的資料庫溝通，只凸顯與外部系統的溝通。)。 只要 博X來 訂購系統需要外部系統的服務，不會是由表單畫面直接呼叫，一定會透過中間層的控制物件(在此例為 OrderControl)傳達需求的訊息。博X來 的訂購表單畫面可以設定查詢的過濾條件，查詢條件可以是 "縣市鄉鎮路名" 或者 "門市名稱" 等，這是為了避免實際去外部系統 (統X EC系統)一次就撈太多資訊，耗費不必要的頻寬。例如，我輸入 "興南" 或 "三民路" 等，控制物件就會依其查詢條件至外部系統回傳一到多筆資料，然後再選擇其中一筆確認後存回表單畫面的狀態。 統X EC系統只要界定好呼叫的介面就可以了，不用去提供 Web表單畫面 在那繞來繞去的。呼叫的介面可以是 Web Service, Message Queue, 自訂的傳輸協定 ...等，都可以的，大概就是注意一下傳輸效能、穩定與安全性等即可。

圖 3、利用控制物件連結統X EC系統，符合 MVC 結構

控制物件是用什麼寫的？ 那是 博X來 的決定，一般是建議用最簡單、可以使用最久的程式語言規格。例如，在 J2EE 系統，那就是 POJO —最 Pure 的 Java 物件；在 .NET，如標準的 C# or VB.NET 等物件。但不會是 ASP.NET 或者是 JSP, Struts, Servlet 等，那些是屬於展示層 (Presentation)的物件類型。可以發現到，加上一顆中間層的控制物件比想像得還簡單，而且透過該控制物件，最起碼已經隔閡了表單的變動 (未來變換 AJAX 技術或傳統 Windoes Form 呼叫，不會影響到控制物件與其內部)與內部的服務呼叫(是呼叫外部系統或內部資料庫，表單不需要知道)，而這其實只是 MVC (Model-View-Control)的基本應用而已。還有值得注意一點的是，控制物件必然會設計為 "Stateful"，也就是該物件的生命週期 (life-cycle)會持續一直保存狀態至該 session 的結束為止，如此它就可以 "keep" 住所查詢回來的 7-11 資訊，供使用者隨時點選或查詢更詳細的門市資訊 (如果有這樣需求的話)。

控制物件這裡我是設計為兩次性的呼叫，也就是表單第一次先以查詢條件過濾後會列出多筆的門市資訊。我想這裡 統X資訊 其實不用太過擔心效能頻寬等問題，統X EC系統可以設定過濾的把關條件，可能可以限制一次性的呼叫不得超過 100 筆等，這些都是可以規劃的。我是覺得以 "路名" 或 "門市名稱" 來設定條件最普遍理想了，輸入最普遍的 "三民路" 總該不會超過 100 筆吧？

真的很擔心效能？ 我是會視現實環境與未來變動性的考量等，可能估其 7-11 門市未來會成長到上萬家，而目前是五千多家，其實是可以乾脆一次就先把所有門市資訊一次給撈到內部的資料庫的，而成為內部系統的 "快照 (snapshot)"。假如估計每天門市成長一家，那麼可以設定一天或半天由排程系統定期去更新門市資料即可。此時需求的使用案例模型就會變為圖4。然後在內部訂購系統的設計上，只要再加上一顆共用性的 _虛擬DB (Virtual DB) 物件，而 虛擬DB，也沒那麼神奇，它就只是把資料以 RDB 的關連型態，儲存於記憶體而已，在實作上，會使用如 .NET 的 DataSet 物件來實現即可。參考圖5，這是反應加了 "Virtual DB" 後的設計，可以發現到，控制物件對外，根本不需要變動，而內部的變化，也不會去影響到表單的操作等。

圖 4、非同步更新 7-11 門市資訊的使用案例圖

圖 5、利用虛擬DB(Virtual DB)物件提供7-11門市資訊

也有人說，使用 AJAX 技術，可以解決上述所討論的問題。這裡我一併說明，無論是 ASP.NET, Struts, 或 AJAX 等，目的只有一個：就是如何將原來是 Stateless 的 Web 表單模擬成如傳統 Statefule 的 Windows Form。 因為，表單在按下 [Submit] 之前，仍然有許多需要與後端系統互動的機會，所以在互動的過程中，表單的狀態 (state)需要能被保存。 AJAX 可以讓 Web UI 呈現更多樣化簡易使用的使用者介面，但需要查詢或企業邏輯運算等，仍是需要連結後端系統的。這是設計的議題，絕對不會是有什麼所謂的 "銀彈" 技術幫你解決如軟體的變動性議題等。

我發現到，絕大部分 Web EC系統的開發，仍是傳統 2-tier 的思維，也就是 "Client-Server" 的架構，請記得， "browser + Web Server" = Windows Form，這是屬於同一個層級，就是 Presentation 層。在該層級，不要賦予它太多的責任，它只要能專心作好一個工作即可：呈現出美美簡易使用的使用者介面。 至於企業相關的邏輯運算等，那是中間層的責任，所以為何中間層又稱為 "Business Logic" 核心。所謂的三層架構，這是與技術平台沒啥關係的，這是一種設計的基本思維，也是軟體設計人員的責任與基本態度。我會建議 Web EC系統的開發人員，首先就先從瞭解 MVC 模式開始，在現實的實作上絕對會比你想像得還簡單，但系統的延展、彈性度與可維護性等，就起碼會進展一大步。