UML 2.0 Diagram 的分類與說明

依照型態,UML2.0 規格可分為兩大類別:

  • 動態行為–Behavior Diagram
  • 靜態結構–Structure Diagram

動態行為–Behavior Diagram:

  • 描述系統或企業流程(Process)的行為特徵。
  • 包括 Activity, State machine, Use Case Diagrams及四個Interaction Diagrams。
  • Interaction Diagrams
    • Behavior Diagram 的子集合。
    • 著重及強調在物件(Object)的互動行為。
    • 包括 Communication, Interaction 。 Overview, Sequence and Timing Diagrams 。

靜態結構–Structure Diagram:

  • 著重在實體(Entities)的結構。包括 實體的分類(classifications)、實體之間的關連(relationships)、實體的屬性(attributes)及操作(operations)等。
  • 包括 Class, Composite structure, Component, Deployment, Object and Package Diagrams。

UML 2.0 圖型態的分類
(縮略圖,點擊圖片鏈接看原圖)

***紅色方框表示是 UML 2.0 規格所新增的;藍色方框則表示 UML 1.X 已參考應用,但未納入正式規格,直至 UML 2.0 時才正式成為標準規格。

從 Google Gmail 的 Label 來看設計的觀念 ~

使用 Google Gmail 所提供 Web 版的郵件處理介面,有個挺特別的功能: Label

基本的觀念在於,所有接收的信件全部集中放在 “郵件匣”,並不需要另外建立 folder 來分門別類存放郵件,而是將欲分類的郵件 “貼上” 標籤(Label),標示它是屬於某某類別。
這很方便,因為一封實體的郵件可以被 “貼” 上多個標籤,同時代表它屬於一至多個種類。
而如 Outlook 等其他郵件軟體,則是以實體的 “folder” 來存放郵件。正好反映了兩種設計的思維:實體與虛化的設計。

同樣地設計應用,沒想到我又在 Apple 的 iTunes 看到了,打開 iTuine,第一個動作即在於載入位於實體檔案各處的音樂檔(如 mp3),載入後集中 “儲存(其實只是 index)” 在一個 universal database 內。
一開始很不習慣,因為使用 media player 久了,一般當你載入音樂檔所在的 folder 時,即會以該 folder 的名稱作為類別名稱,方便你選擇播放。
但 iTunes,則是讓你自行 “create” 新的標籤,然後再把你想設定為該標籤的音樂檔 “拉” 進該 Label,該 Label 就成為目錄的名稱。
所以,你可以依你的喜好來對 Label 命名,例如以 歌手、曲風、最喜歡的歌曲…等,每個 Label 可以設定你所喜歡的播放方式。甚至,iTune 還幫你預設好如 “派對隨選的播放”,也就是該 Label 可以隨機播放位於資料庫的歌曲。

以實體 Folder 作為群組的單位是一種設計;而使用邏輯虛化的 Label 作為群組的單位又是另一種設計。將實體與虛擬分開來,一個簡單的觀念,但卻能使應用的彈性提升更大。

舉一個例子,國內某知名購物網站 PX-HOME,它的購物系統實在是不可思議的 ~ 差勁。
昨天我買了三個商品:三個懷爐、一組懷爐用的精油、一套華康字型軟體。
竟然,要重覆購物三次,要刷三次卡 @!#!
看了該網站客服的 FAQ,理由竟然說因為貨源是不同的廠商所提供,所以使得線上購物的商品必須一件一件個別購買。
這什麼跟什麼? 明明就是購物系統的設計非常明顯有問題! 不懂得將虛的設計與實體的貨源抽離出來。

再來,還有一個,我從來不認同 Java 以實體的檔案結構作為 package 的分類依據是理想的。原來 Java 設計小組應該是考量到 “結構化” 的配置問題,只是其實做卻是以實體的檔案結構來作為 “結構化” 的分類依據。這是一種 “bad design”,使得開發人員做如 “Deploy” 的工作是一件辛苦的事。
相較於 .NET,它反而是以虛化邏輯的 “name space” 來作為程式碼的分類,而不用考量程式碼的實際儲存位置。這點則來得有彈性的多了。

懂得將 “虛” 的觀念應用在設計中,往往僅是多那麼一點簡單的創意,實際不需花上額外開發的時間。但所造成的效果,卻可以是更加地便利、更來得有彈性。

Apple iTunes 的 Label 應用實例

{Draft} Open Source 的 “Business Model” 思考

從 Jimmy 網站一文:「專案成功的要素」

才知道,原來 Jimmy 參加了「國際開放源碼」的研討會,聽了一場Patric McGovern(Director, SourceForge.net)的演講。

最重要的是, Jimmy 節錄了 “Open Source 成功的關鍵” (感謝!對我實在太有幫助了) ^^”

全球最大open source開發網站的主持人,他不但用Apple的Keynote製作了超炫的3D轉場投影片,還提到了一個有趣的觀察;他認為一個成功的開放原碼專案通常有這些關鍵:[全文:]

1. 要有趣!讓人覺得有吸引力
2. 可與其他的軟體相互結合(e.g. blog + photo album + wiki + forum + …)
3. 傾聽使用者的回應
4. 提供良好的vision給使用者參考
5. release early, release often

這一年來,我個人也一直在觀察思考 “Open Source” 這個 “社群”。
前四點,我大概都有想到,但第五點,完全沒有想到!!
哇哈哈 ~ 讓我在對 “Open Source Business Model” 研究的思考上提供了太大太大的幫助了。

閱讀全文 »

{How-to} 將 jBPM-2 的預設資料庫改成 MySQL

說明:jBPM-2.0 預設所使用的資料庫系統為 “HyperSonic”,主要作為開發測試用,並不適合在企業的環境下使用。jBPM2 是以 “Hibernate” 作為 O-R Mapping 的 Frameowork 機制,可以支援多種資料庫系統。底下的步驟說明如何改成 MySQL 資料庫。

環境:

  • jBoss 3.2.5 above
  • jBPM 2.0
  • MYSQL 4.0.x above
  • J2SE SDK v 1.4.2_03 above
  • Apache Ant version 1.6.1 above
  • Eclipse 3.0.1

步驟:

  1. Check-out or download jbpm source-code from jBPM2 OpenSource Project
  2. 打開 Eclipse,新增一個空白的Java Projec (ex. jbpm2)
  3. 將jbpm的原始碼Copy至Eclipse的Workspace目錄的適當位置
  4. 更改jbpm下的build.property,設為自己的位置
  5. 更改jbpm的Project Property,將Ant_Home以及JBoss_Home設成自己開發環境的絕對路徑
  6. 將My Sql的JDBC Driver:mysql-connector-java-3.0.14-production-bin.jar複製到JBPM的Library(%jbpm.home%\lib)中
  7. Check-out or download jbpm source-code from jBPM-2

  8. 更改build.xml,在”configure.jboss.3.2.6+”中加入一段:
  9. 新增一個Library:mysql-connector-java-3.0.14-production-bin.jar至jbpm的Project Property中
  10. Eclipse Properties for jBPM2

  11. 在MySql中新增一個Database,jbpm2。以儲放jbpm所需的Table,另新增 mysql 帳號管理 jbpm2 的資料庫。(username/password: jbpm2/jbpm2)
  12.  
  13. 更改core/src/java/org/jbpm/persistence/hibernate/HibernateSession.java中的latestDefinitionQuery Property的程式碼為
    "select d from d in class " +
    "org.jbpm.model.definition.impl.DefinitionImpl " +
    "where d.name = ? order by d.version desc";
    
  14. 更改web/src/jbpm.war/WEB-INF/classes/ jbpm.properties如下:
  15. ### HIBERNATE configs #########################################
    hibernate.dialect=net.sf.hibernate.dialect.MySQLDialect
    hibernate.connection.driver_class=com.mysql.jdbc.Driver
    hibernate.connection.username=root
    hibernate.connection.password=
    hibernate.connection.url=jdbc:mysql://localhost/jbpm2?useUnicode=true&characterEncoding=utf-8
    hibernate.c3p0.min_size=2
    hibernate.c3p0.max_size=2
    hibernate.c3p0.timeout=120
    hibernate.c3p0.max_statements=50
    

    P.S. 中文支援問題
    對于MySQL,hibernate相應的driver設定成︰jdbc:mysql://localhost/jbpm2?useUnicode=true&characterEncoding=utf-8

  16. Run Ant,Build並且執行configure.jboss.3.2.6+
  17. 啟動jBpm
    (start the jbpm configuration of jboss with ‘%JBOSS_HOME%/bin/run.bat -c jbpm’)
  18. Run web\build.xml,執行deploy及deploy.process.archives
    in directory ${jbpm.home}/web run ‘ant deploy’.
     in directory ${jbpm.home}/web run ‘ant deploy.process.archives’.
  19. 查看MySQL Database即會發覺在Database中已經有JBPM相關的Table在裡面 (總共有 16 個Tables,下圖後兩個 Table 為自行開發時所新增的)
  20. jBPM Tables in MySQL

  21. Run
    http://localhost:8080/jbpm

    出現 jBPM 的Demo Workflow 的登入畫面

  22. jBPM2 的登入執行畫面

利用 EA UML 塑模工具設計 Database Schema

昨天我們協助一家診所設計病歷管理的系統,所有的訪談都是以 EA 來做紀錄,並將 E-R(Entity Relationship) Model 設計圖設計出來。

EA 的 E-R 圖,可以直接轉成 ANSI-SQL、Oracle、MySQL、MSSQL、Access … 等資料庫的實體 DDL SQL 敘述,以方便 “import” 至所指定的資料庫系統。

另,注意圖右邊的 “Project View”,這是針對所屬於我們自己團隊內部所自訂的 “開發流程(Precess)” 並利用 EA 設計成屬於我們團隊的 “Template”。
所以可以設計 Template 並表達成:

Architect View ; RA(Requirement Analyst) View ; HSD(High-level System Design) View ; DSD(Detailed-System Design) View ; PG(Program) View ; PM(Project Manager) View 。

EA UML for E-R Model Design Screenshot
(縮略圖,點擊圖片鏈接看原圖)

【好書分享】與熊共舞:軟體專案的風險管理

Waltzing with Bears: Managing Risk on Software Projects 與熊共舞:軟體專案的風險管理
Waltzing with Bears: Managing Risk on Software Projects

-----------------------------------
作者/湯姆.狄馬克、提摩西.李斯特/著
譯者/錢一一
出版社/經濟新潮社
ISBN/986788924X

內容簡介:
假如下一個專案一點風險都沒有,就別做。 風險越大,報酬就越大,對於軟體開發來說尤其如此。在充滿競爭的環境中,一味逃避風險的公司很快就會發現自己落後了,但如果專案經理對於可能造成失敗的威脅視而不見的話,又會使組織「過於冒進」。為了解決軟體開發人員「逃避又怕落後,冒險又怕失敗」的兩難,本書將教讀者如何辨識風險,並去擁抱「值得冒的風險」。作者還列舉出風險管理的好處,包括:使積極的冒險變為可行、防止盲目管理的發生、花最小的成本做好最起碼的防護措施、釐清責任歸屬、隔離子專案的失敗,使它不會衝擊到整個專案。讀者可以用本書提供的策略來加強專案的防禦工事,對付軟體專案中最普遍的風險:時程延宕、需求膨脹、人員流失、規格崩潰、績效低落。
《與熊共舞》將幫助您,在風險演變成致命的問題之前,就紓緩風險。風險就在那兒——它們本來就應該在那兒——而你當然有辦法管理它們。

各界好評:本書是軟體專案風險管理方面最具影響力的著作。
發人深省的見解、精闢務實的建言,我們終於有了一本實用的風險管理指南。 ——Rob Austin,哈佛商學院教授
講得很露骨、很挑釁,但絕對實用。
一定會把這本書當成必讀聖經,你專案團隊中每一位成員、每一位經理,以及所有會影響專案的利害關係人,統統買一本送給他們。我已經為我最好的客戶們訂了20本。——Michael Schrage,MIT媒體實驗室電子商務市場創制協同主持人,《認真玩創新》作者 認真的軟體從業人員和專案經理。
書中妙語如珠,例如「事情做錯沒關係,就是不可以不確定」,光憑這些就很值回票價了——對於我們幼稚、不切實際的風險管理文化,那真是當頭棒喝。 ——Edward Yourdon,軟體界知名顧問與作者。

從以前就一直覺得所碰過的軟體專案,包括所耳聞或之前擔任某團隊顧問時所協助參與的(但並非我能負責,我還有老闆,由他決定作法),沒有一個會成功!

理由為何,因為,有太多的 "怪現象" 了。例如,從業務開始招攬一個數百、上千萬的案子,為了得標,老闆集公司所有菁英,不眠不休,每天有開不完的會、PM 熬夜要寫上百甚至數百頁的 "Proposal",不斷的演練該如何在投標會議中表達取得案子的決心與能力。

可能花了數星期、甚至數個月,案子得到了,老闆很開心、業務也很開心,PM 也跟著開心。
然後呢?嗯... 投標菁英部隊撤離了,PM 負責向老闆報告評估案子完成約需幾個 "人/月",PM 與 老闆就開始討價還價,希望要多幾個或老闆希望能少幾個 "人/月"。就如同菜市場一樣,媽媽們買菜向老闆希望能多 "凹" 幾根蔥,老闆又希望少給幾根蔥。
因為,對老闆而言,"人/月" 是多麼的珍貴 -- 牽涉到公司的經營成本啊~

人力決定後,也就代表資源決定好了,然後,由一個 "老鳥" 帶頭,帶領許多 "菜鳥們" 披掛上陣,讓這些 "菜鳥" 們從實戰中學習。
做不完?加班...還是做不完?假日來!...仍然做不完,糟了,這些 "菜鳥" 要檢討,能力是否有問題。

另,開發人員同時都是肩負著一個以上的專案,非常少有只專心開發一個案子的。

更有趣的是,這些現象,不是沒有人不知道,但沒有人敢說。要嘛就~

  • 昧於事實:老闆、PM 們幫專案團隊加油打氣!!你們是最優秀的,你們做得到,再加把勁,就可以完成了。絕對可以在期限內完成的。沒有不可能的事...
  • 迫於現實:因為,太多現實因素...我需要這份工作;我是國防役,無法離開;大家都這麼做,我也只好跟著這樣做...

回到主題,現實的問題是,太多的現象,都是會造成專案無法照預期的時間所達成。這種問題,依據以往的 "常識" 來判斷,有 9成5 以上的機率會發生。即使,再加上 80% 的延長期限,專案仍不一定能完成。
那麼,如此顯而易見的高度風險,到底,是如何採取措施來面對這種風險呢?
可悲的是,幾乎就沒有人願意面對這種 "潛在的嚴重問題"。

風險的評估與管理? 那是悲觀主義者才會有的論調。但當這些問題發生時,不會有老闆感謝這些極少數的 "悲觀主義者",反而,認為他們 "唱衰"、"不夠積極",才會發生專案種種的問題。

這本書就在於 "赤裸裸" 地告訴你軟體業的這些 "見怪不怪的現象",也教你該如何及正視這些 "務實" 的風險管理問題。

軟體思維顧問

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

Personal