從 Google 書籤看標籤與資料夾的設計觀 ─ 觀念篇

我使用 Google 書籤已有一年多餘的時間了,並非是為了好用,而是為了 "可攜性"。 因為我有多臺電腦,而且也常在外面透過筆電或 Vm 上網,也常切換 IE or Firefox Browser,書籤的管理,就變得是一個問題了。 而使用過眾多的書籤管理同步工具,仍是覺得相當麻煩,所以還是回歸到使用最簡單,Google 所提供的書籤管理機制,只要上網登入 Google 帳戶後,就可以存取網路上的書籤,相當便利。

先看看我的書籤是如何規劃的吧,參考下圖。

圖 . Google 書籤的管理規劃-01
(點擊圖片鏈接看原圖)圖 . Google 書籤的管理規劃-01

先瞭解一件事, Goodle 書籤的管理,是沿用 Google 平台傳統的機制,就是利用 TAG (標籤)來組織分類。 Gmail 是如此, Bookmark 也是如此。

所以,我若要 Bookmark 某個遊戲網站的書籤,TAG 大概就是標記如 "Game" 名稱之類的。 那麼當遊戲類的書籤一多的時候,又該如何管理呢? 舉個例,我光是當時玩「魔獸世界」時,保存相關的書籤就有近百個之多,所以你可以同時標記的 TAG 可以有 "Game", "魔獸世界" 兩個;而若是圍棋的書籤則可以標記 "Gmae", "圍棋" 兩個。 當標記的 TAG 越來越多時,你會發現到標籤的顯示會相當凌亂。 若你希望某個書籤雖然是標記成多個 "TAG",但又希望這些 TAG 的顯示有些關聯性,那麼,就可以如我上圖這樣的規劃一般,就是把 TAG 標記為 "Game", "Game_圍棋", "Game_魔獸世界" 這般,這樣的話在書籤的顯示上就能有循序性的列表了。

閱讀全文 »

報名系統分析課程(06/27)免費送 Linux 軟體開發平台 DVD 光碟

HSDc. 團隊近日費心製作了「Linux 軟體開發平台」DVD 光碟。 目的是為了讓學員可以擁有與講師相同的軟體開發環境,只要帶回家啟動光碟後,不需作任何設定,就可以方便對講師所提供的實做案例自行練習 (當然,也可以開發所屬於自己的應用程式)。

即日起,只要報名【系統分析課程】系統分析設計與實作—活用 UML 塑模 與 Java (06/27, 54 Hrs),即免費贈送學員 DVD 光碟乙片 (不要忘了,線上報名還有免費贈送 Ringle 的親筆簽名新書喔)。 光碟內容相當豐富,包括課程所使用的教材電子檔、完整的實做案例 (包括 UML Model 檔與可執行的應用程式碼); 當然,還包括了如下完整的 J2EE 開發環境 (爾後 HSDc. 會對其系統與應用平台版本的更新而持續 Update):

  • OS: Fedora 10.0 Traditional Chinese
  • XWindows: GNome
  • VMWareTool
  • Java SDK 1.6.0_0b12
  • JBoss Application Server 5.0.1
    (Install in /usr/jboss-5.0.1.GA)
  • MySQL Server 5.0.77 (Fedora Default)
    MySQL GUI Tools 5.0r12
    MySQL JDBC Connector 5.0.8
    (Install in /usr/mysql-connector-java-5.1.7
  • Eclipse 3.3 with J2EE
  • Spring Framework 2.5.5
  • Hibernate 3.3.1 Code and Library

安裝的Server以及Java Library

底下同時列出幾幅開發環境的 Screenshot 圖片:
UML Development Tool (EA, Enterprise Architect) under Fedora Linux:
利用Wine執行EA

閱讀全文 »

Ringle 即將出版的新書─「UML 協同團隊合作開發」

我的超人 Partner Ringle,最近正主導開發 "Sequence Generator" 工具之餘,在我喋喋不休、半強迫的威脅下,利用兩個餘月的時間,把他以前,包括顧問輔導的實際案例、上課的教材與專案的開發等相關文件,作一次整理,集結成書,書名就定為:「UML 協同團隊合作開發」,預計下個月(六月份)出版。

書籍內容約有 4、500 頁以上之多。 書的編排除了不免俗的有 UML 基礎介紹外,Ringle 還為每一張 UML 設計圖 (共 13張)構思個別但又可以整個連貫起來的案例 (Case Study),並利用 UML 開發工具 (Enterprise Architect) 以 Step by Step 的循序方式實現。 所有的設計圖實做出來後,即完成一個小型的系統。當然,Ringle 是相當重視理論與實務的並重,所以當然包括程式碼的實做 (包括實際連結資料庫、外部系統等)。 絕非是一般的系統分析書籍,只是寫幾個 "Sample Code",做個樣子、紙上談兵而已。 他甚至考量到初學者對 OOP 語言的接受度,所以選擇以 VB.NET 作為程式碼實現的機制。 (書本還附上光碟片,內含 Model 檔與實做程式碼等,供學員可自行操作練習。)

※※ 說 Ringle 為超人實在不為過,原來已經給出版社,四百餘頁的原稿,因他覺得仍不甚滿意,竟然全部重寫!! 甚而連示範圖形全部重新再操作過,剪下的貼圖。 短短兩個月的時間,完成了 Ringle 所謂的 Iteration-2 稿件。他可是不眠不休,晚上熬夜鍛鍊出來的合金肝這樣寫成的著作。

再則,整個開發過程中,工具應用的 Know-how,的確很重要。更甚者,協同開發的議題,例如如何利用工具整理共用的需求、設計圖、程式碼等、如何利用版本控管的機制來作共用的管理等,在本書也有詳細的示範解說。 書中是利用 Subversion + EA 就能達成共用管理的機制 (舉一反三,讀者當然可以利用其它工具來實現)。 協同開發環境的建置,僅利用上述的工具,就能達成 CMMI level2~4 的目標水平。

這本結合 UML, 工具, 程式, 以及協同開發的控管等應用,算是偏向實務性質的實用書籍,是 Ringle 第一本初試啼聲的著作。 事實上,Ringle 真正的天賦在於對軟體抽象能力的領悟與觀察力,對於如何捕捉各領域 (Domain)的核心物件,並利用現實的 OOP 機制實現出有彈性的結構,可以說真的是無人能出其右。 這也是未來期許他出版第二本書的主題。

在書籍尚未出版之前,我特別請 Ringle 為自己的著作先作個簡單的新書介紹,同時也順便列出本書的書目大綱。

閱讀全文 »

【系統分析課程】系統分析設計與實作—活用 UML 塑模 與 Java (06/27, 54 Hrs)

※※※ 即日起,線上預約報名本課程,即贈送 HSDc. 團隊 Ringle Lai 所寫的新書(含親筆簽名)─「UML 協同團隊合作開發」。
這是作者個人所期許的: 「寫一本十年前的我看到以後一定會想買的書」! 相當令人期待。

HSDc. 所公佈六份月的完整系統分析課程。


§課程名稱: 系統分析設計與實作—活用 UML 塑模 與 Java (54 Hrs)
§課程諮詢(HSDc. 軟體設計專業顧問團隊):
 o 諮詢專線:TEL: 02-27227179
 o 服務信箱:service.hsdc@gmail.com
 o http://www.hsdc.com.tw

【台北場】2009/06/27 起,每週六白天,每次上課為六個小時(AM 9:30~PM 4:30),共九個星期。
 o 預定上課日期:06/27, 07/04, 07/11, 07/18, 07/25, 08/01, 08/08, 08/15, 08/22
 o 遇國定假日或颱風等因素,則延至下一週上課日(本中心會主動通知學員),以此類推。

--------------------------------------------------------------------------------------------------------------
o 由於本站線上報名系統仍有問題,煩請報名學員填寫下列資料報名 (下列欄位前為 * 者請務必填寫),
  並以 Email 寄至: service.hsdc@gmail.com
  -------------------------------------------------------------------------------------
  * 姓名:
  * 電子郵件:
  * 聯絡電話:
  任職公司與職位:
  備註(請填上如 ATM 轉帳帳號(後五碼即可)、開立發票資訊、以及新生或舊生等資訊):
  -------------------------------------------------------------------------------------

§課程費用與報名:
 o $15800 (含稅)。 (同等課程原價學費為 $30,000 以上)
 o 報名經確認後,本站即會寄送確認通知信給報名學員。
 o 曾經上課過本公司的「單元系列課程」學員,優惠 $13800 (含稅)。 (請記得註明為舊生,本公司查詢確認即以優惠算)
 o 三人同行,或同時報名另一單元課程,亦比照舊生的優惠折扣,每位只需$13800 (含稅)。
 o 大學/研究所 資訊相關科系講師、助教或教授,出示相關證明,我們會以建教合作方式計費。(請另以電話聯絡)
 o 清貧或由家扶中心推薦,能出示相關證明,所有費用 免費!!
 o 授課地點:開羅會議中心,地址:台北市光復南路65號B2 (光復南路、市民大道交接口)。
 o 參考交通與地圖。 http://www.hsdc.com.tw/education/cario_map

 o 報名系統分析與實作班學員,請先以 ATM 轉帳預約費用($1000),並請於報名表備註欄位內,註明您的轉帳帳號末 5 碼與轉帳金額。
 o ATM 轉帳帳號: 新光銀行 (103) 帳號: 0772-50-100979-9
 o 本課程上課學員需滿 15 人以上,若未達上課人數則延期至下一梯次開課,已報名學員,本中心會電話通知,並主動辦理退費(或可保留至下一梯次)。
--------------------------------------------------------------------------------------------------------------
§課程簡述:
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. 本課程均保留與提供了學員免費再旁聽乙次同樣課程的權利,以一次低廉的收費,就可以擁有兩次上課的收穫,課程的師資、內容與品質,我們有信心是不會讓學員們失望的。

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

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

閱讀全文 »

HSDc. 最近正開發程式碼與 UML 循序圖的互轉工具

我們團隊 (HSDc.) 從今年 (2009) 初就定下了策略目標,其中一項主軸就是內部要開發出小而巧又實用的軟體相關產品。 農曆年後,經過一個下午的 Meeting,腦力激盪得到的共識就是開發一個可以協助 程式 Coding 人員,利用視覺化的 UML 循序圖 (sequence diagram),來呈現出程式碼在某一個情境下,物件相互之間動態連結關係的工具。 嗯,就暫且命名為 "Sequence Generator" 好了。

主要功能就是兩個: 一為從程式碼的某一個類別 (Class)的 method 開始 (進入起點, entry point),然後可以定義呼叫物件遞迴 (recursive)的深度層次(例如深至 5 層),按下按鍵,即可產出物件合作的循序圖; 另一個功能就是從循序圖轉出到程式碼 (當然,要先規範好類別圖)。 如此可以輔助類別圖的轉換,將如 a.method1() 呼叫 b.method2() 的關係,給呈現在程式碼的結構內。
HSDc Seq. generator - Use Case 圖

目前同類型的 UML 工具中,EA (Enterprise Architect) 是提供 "Run-time" 的環境,可以從程式碼產出到循序圖,但反之不行。 而且主要的問題是,要將 EA 設定成可以執行 .NET or J2EE 的環境,相當麻煩,要對 command-line 的指令執行模式相當熟悉才行。

另一個功能最強大,截至目前為止我認為最好用的是 Borland Together。 它是以靜態處理的方式 (這也是目前我們產品的作法,不需要建立動態的環境),而得以實現上述兩種功能。 只是,1. 它可不便宜,一套開發工具可要 10餘萬以上;2. 從循序圖產出的程式碼無法成功經過編譯 (compile),而這也是我們現在要努力的目標 ─ 可以達成部份實作且成功經過編譯。

目前我們預定是先開發出 Plugn 在 EA (Enterprise Architect) 的環境,所以會以 Addon 的形式包裝在 EA。 價格絕對是相當低價,連 EA 的一半價格 (絕對不到 NT$5000) 都還不到。 支援的程式碼最少是 C#, VB.NET 與 Java。 未來也不排除支援 C++ 甚至 PHP 等。

整個開發的框架大致已建立起來,也已經完成了一個小小的雛型 (可以從 C# 程式碼轉循序圖)。 而且,我們也針對該工具產品 (它也是一個問題領域, problem domain) 建構了物件模型,並且使之與 EA Plugin 的 APIs 隔離,所以相對來說,要移轉 (migrate) 到如 RSA or Free UML 工具 (前提要有提供可擴充的 API 介面),所花的 Effort 就不會太重了。
HSDc Seq. generator - 開發Class 圖

預計再過兩個月,應該會提供出 beta 版本,供有興趣的程式人員下載測試,並可請提供諸多寶貴的意見。

底下是目前開發中的幾個畫面 (screenshot)...

閱讀全文 »

讀者對使用案例的幾個提問 (針對另文「三論博客來的使用案例分析」)

網友 Thomas,在我個人發表過的一篇文章:「三論「博X來」— 訂購商品與結帳是否是同一個使用案例?」,提問了對使用案例分析的幾個相當不錯的問題與觀點。 老實說,這讓我精神為之振奮起來,已經許久沒有人與我討論使用案例分析的議題了。 我曾提及,使用案例是易學難精,沒有把握基本精要與原則,很難把圖給畫好 (不容易界定出系統範圍),更何況是用純文字來寫出需求陳述。而且,使用案例如同學習圍棋一樣,每一個階段的學習與思考,又能再有著對其本質更深一層的體悟。 相對來說,應用在實務的需求分析上,也會來得更為得心應手。

這裡就 Thomas 所提問的問題,獨立出來另以本文來回覆。 同時也算是對上述該篇文章的補充論述。

您好:
對與你的無私與熱心真的令人佩服
看了你這篇文章感覺上有一個地方有點不解之處,想跟您請教一下
一般來說 使用 Use Case 時最怕受傳統結構化的影響,而將 Use Case 畫成功能分解,但看了你的 Use Case Diagram 的圖,其中訂購商品這個 Use Case 又去 include 查詢商品資訊及放入購物車,坦白講感覺有點像是功能分解的方式,要是我畫這張圖,我可能只會有查詢商品資訊及放入購物車,不會有一個訂購商品這個 Use Case,查詢商品是使用者一進來就會使用的功能,對使用者來講是一個獨立的價值,他就是喜歡逛逛而已,而放入購車又可視為一個獨立的需求,至於訂購商品應該是一個企業流程,這個企業流程包含很多有價值的事情,實在不適合當成一個 Use cASE 反而比較適合成為此 uSE Case 的系統邊界,除非你這張 use case 的層級是在討論企業層級的 use case,而不是在討論 系統層級的 use case
不知您以為我的觀點是否正確
謝謝

關於上述問題的回覆:

  1. 我們要先對使用案例的本質弄清楚。Use Case 確然就是功能分解!! (這點最重要,要先分清楚使用案例的分解方式為何)
  2. 與傳統的模組化功能分解不一樣的是,模組化的功能分解係以功能樹 (functional tree)的方式將大功能分解成小功能,每一個小功能又各自分解更小的功能,直至每一個小功能可以成為一個開發的單位為止。
  3. Use Case 的功能分解,係以目標導向 (Goal-oriented) 的方式,從使用者 (參與者)的角度,在特定的期間 (session) 內,能完成他對系統的操作期望。每一個 Use Case,均可以被視為是一個迷你的系統,是可以被各自獨立來實現 (realize)。
  4. 回至本例,我在圖中係凸顯了系統需滿足使用者兩個主要的功能 (期望),一為訂購商品;另一為結帳商品。 至於為何是分為兩個使用案例,我已在文內有敘述。
  5. 為何我是把主要的 UC 名稱定為「訂購商品」而不是「放入購物車」,原因在於我想凸顯它是 參與者 (Actor) 操作系統的一個重要目的。若用英文命名,會更為恰當。名稱即為 「Place a Order」,如此也比較不至於從字面上引起誤解。 另外,可要注意的是,「訂購商品」正是該資訊系統最重要的交易型使用案例,若把它拿掉,那麼這個資訊系統的價值可就完全不見了。 (其實,我在文內均已有描述這樣的論點,您可以再仔細研讀。)
  6. 「訂購商品」與「訂購業務流程」是兩個完全不同的層次,一個是資訊系統操作層級;另一為業務流程層級。 兩者我其實是各自分開來表達的。前者我利用使用案例圖,後者我是利用業務流程圖的。 可以參考我另外一篇文章:「從企業流程(活動)圖找出資訊系統的使用案例。
  7. 至於為何在圖形上,「訂購商品」會包含 (include) 兩個 Sub-UC (一為查詢商品,另一為放入購物車)? 我在文內其實特別還說明,我是把這兩個 Sub-UC 視為是參與者在「訂購商品」期間內,重要的子程序。
  8. 那麼,「查詢商品」是否可以被視之為另外一個獨立的 Use Case? 答案是 Yes! 但是,可不要把「查詢商品」與在「訂購商品」內所包含的「查詢商品」混在一起。 前述已提,每一個使用案例,是可以被獨立來實現的。 一個獨立的 UC 與另一個被包含的 UC 雖然可能有著相同的程序,但是,在 Use Case 的需求分析階段時,儘量不要去涉及到公用的議題,而是留待到結構分析設計的階段。
  9. 最後,所謂的企業層級的使用案例,與資訊系統層級的使用案例,其實這個就是系統邊界界定的問題了。 幾年前寫過一篇:「從鳥瞰的觀點看 Use Case Diagram」,可以參考之。
軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal