五、抽象層的結構設計 (abstract structure design)－Cloud Server System
- Control (控制)
每一個使用案例，對應並規畫一個控制物件 (controller)。控制物件名稱，一般命名建議為「Use Case Name + Control」。例，「彙整林書豪新聞資訊」，則控制物件名稱為：「彙整林書豪新聞資訊Control」。
（點擊圖片鏈接看原圖）圖9、控制物件類別圖
[案例研討] 雲端與安卓系統分析與實作－以豪小子App為例-03
四、為每一個使用案例，撰寫使用者需求陳述 (requirement statements)
o 雲端系統 (Cloud Server System)
（點擊圖片鏈接看原圖）圖5、「彙整豪小子消息」使用案例陳述
（點擊圖片鏈接看原圖）圖6、使用案例陳述的細節性紀錄
| Use Case Name | 彙整豪小子相關消息 |
|---|---|
| Pre Condition | 1. 排程系統已設定排程啟動時間。 |
| Brief Description | 排程系統定時啟動「彙整豪小子相關訊息」的系統服務，系統 (Cloud Server)會請 Google Custom Search Server 搜尋相關的新聞資訊，並將搜尋結果儲存以供後續系統的取用。 |
| Basic Course of Event. | 1. 排程系統依照 [設定時程] 啟動系統服務。 2. 系統依據 [搜尋設定條件] 請 GC2S (Google Custom Search Server)系統至所指定的網址搜尋新聞資訊。 3. 系統取得 [搜尋結果] 後，依照 [分類規則] 進行新聞資訊分類。 4. 系統將 [搜尋結果] 儲存至私有的資料庫。 |
| Requirements | [設定時程] 由系統管理者進行排程設定，預設 (default)為每 10 分鐘啟動系統服務。 |
[搜尋設定條件]
|
|
| [搜尋結果] 標題 (Title) 內文Sample 類別 (Class) 符合度 |
|
| [分類規則] 依據類別分配到不同的類型(目前分為三類)中 1. Vedio 2. Piicture 3. Text |
|
| Exception | [搜尋結果傳回錯誤代碼] 3a：GC2S 傳回的搜尋結果為錯誤代碼 1. 系統紀錄[搜尋異常訊息]。 2. 系統將此異常訊息透過電郵寄給系統管理者。 |
| References | 1.「Google Custom Search Server」Reference Guide. |
[案例研討] 雲端與安卓系統分析與實作－以豪小子App為例-02
三、 利用使用案例 (Use Case)圖界定系統範圍與定義系統功能
o 雲端系統 (Cloud Server) use case model
（點擊圖片鏈接看原圖）圖3、Cloud Server use case model
- o Use Case (使用案例)：表達系統功能 (system functions)。
- 彙整豪小子相關消息。
- 設定豪小子搜尋條件。
- 查詢豪小子新聞訊息。
- o Primary Actor (主要參與者)：使用系統所提供的服務 (系統功能)。
- Scheduler System (排程系統)：定時啟動「彙整豪小子新聞資訊」批次作業 (Batch Job)。
- Administrator (系統管理者)：管理者可編輯並設定豪小子搜尋的條件 (condition)。
- Android App System (安卓豪小子App)：安卓App至雲系統查詢已整理過的豪小子新聞資訊。
- o Supporting Actor (支援性參與者)：系統需要取得外部系統支援的服務。
- Google Custom Search Server：雲系統所下的搜尋條件，透過 Google Search APIs 將搜尋的結果儲放至該伺服器內。後續的程序再由雲系統取得已搜尋的結果。
[案例研討] 雲端與安卓系統分析與實作－以豪小子App為例-01
前言
這是今年 (9月底)至大陸「深圳」軟件園區－「北京大學產學研究中心」授課所使用的案例研討 (case study)。
短短兩天的授課時間，展現如何整合「雲端 Cloud) 資料彙整」與「安卓 (Android) App」的系統分析開發至程式寫碼等涵蓋一個開發循環 (iteration)。
第一版的 Model 檔在此提供下載，可作為一個小型專案的範本參考 (Java eclipse 源碼待至後續論及開發寫碼時提供下載)。讀者可至 EA Saprx System 下載免費的 EA Viewer 以讀取該 Model 檔。
o 豪小子_雲端與安卓系統分析 Model 檔。
o EALite.exe (free, EA UML Viewer)
案例簡述
HSDc. 軟件設計公司 打算因應「林來瘋 (Lin-Sanity)」熱潮，開發一個手持式裝置的行動App (暫先命名為 「豪小子」 )，初步的版本先以「安卓 (Android)」系統為開發平台，後續的版本則準備擴展至「iOS」、「Windows Phone」等主要系統平台。
主要的功能需求 (functional requirement)，行動用戶可以透過「豪小子App」隨時得知關於「Lin-Sanity」的相關新聞 (news)。用戶不需至各個相關的網站自行搜尋關於林的新聞，而是已由「雲系統 (Cloud System)」彙整其相關的新聞資訊，行動App僅需連至「雲系統」取得相關新聞的索引鏈結 (index link)即可。
「雲系統」的建構可以至「ISP (Internet Service Provider)」租賃，以減少建置與維護成本。本例的「雲系統」係架設在「Amazon EC2 (Elastic Compute Cloud)」。
一、利用 EA UML 工具規劃塑模 (modeling)專案目錄
（點擊圖片鏈接看原圖）圖 1、利用EA UML工具規劃塑模專案目錄
- 重點摘要：
- UML 目錄規劃如同文件管理一般，每個人/每個團隊 均有屬於自己風格的整理方式，沒有絕對的規範。
- 文件管理以「資料夾 (folder)」為容器 (container)收納單位；UML 專案則以「套件 (package)」為容器單位。
- 一般建議的「root-package」有兩大面向－「需求 (requirement) view」與「結構 view」，但這也不是絕對。
- 「package」內可容納「sub-package」與「uml 元素 (elements, 如同 files)」。
[案例] 推特(Twitter)系統分析使用案例
這是前年底至大陸「深圳」的「中國移動」軟體部門授課的案例。當時我們花了兩個多星期的時間製作此案例，並包含可執行的雛形應用系統與手機 App 的前端介面。因也事隔一年多了，所以無保密問題，在此就把基本的系統分析使用案例 (use case)提供分享參考，同時也把 EA Model 檔供下載參考，可作為一個小型專案的範本參考。讀者可至 EA Saprx System 下載免費的 EA Viewer 以讀取該 Model 檔。
o 推特 (Twitter) 系統分析 Model 檔。
o EALite.exe (free, EA UML Viewer)
推特系統功能模組 (System Functional Modules)
（點擊圖片鏈接看原圖）圖 1、推特系統功能模組
推特系統模組－General
（點擊圖片鏈接看原圖）圖 2、推特系統模組－General
[轉貼] EA 與 Visio UML 工具比較
這一份 EA (Enterprise Architect) 與 Visio 的比較表，是由我們 HSDc. Cathy 小姐找了許多資料，用心所整理出來的功能比較表。
EA 怎麼會與 Visio 來作比較？ 其實這是國內某大銀行 IT高級主管所要求的，必須附在產品採購內的評估報告。
一開始的直覺是，這兩樣能作比較嗎？ Visio 算是一種繪圖製作的工具，提供了諸多各類型，包括網路、基本流程、甘特圖、乃至於 Mindmap, UML 等圖形元件 (Widgets)的模版 (Template)：而 EA 則當然是 UML 專業設計的工具。
但是，我還真問了許多已經使用過這類如 EA, RSA (Rational Software Architect), Together 等工具的軟體開發者 (Developer)，到底與 Visio 的主要差異為何，沒想到絕大部分還真回答不出來，以為就是在繪製 UML 圖形的便利性與否而已。
不然！ 其實以 EA 這等專業 UML 工具，為何售價需要近萬元？ 必然是有 Visio、或者一般免費 UML 工具所無法比擬的特點。但可不是繪圖容易與否這類問題上，真正的主要差異在於：
- 有效調和專案 (Project)開發過程中，不同角色 (Role)的開發者所設計出來的 UML 產出 (Artifacts)，並在這些產出之間，有效監控並期能保持一致性。
更簡而言之來說，當專案是需要團隊協同開發時，則專業性的 UML 工具則是有其必要的，且更能有效保存軟體開發過程中的設計產出，成為團隊甚或企業的有效資產。
至於 EA 與 Visio 兩者的ㄧ些主要功能差異，則可以參考底下 Cathy 小姐所整理出來的比較表：
