【UML2.0/EA 軟體設計系列講座 – **免費**】UML 2.0 綜觀介紹

歡迎對本次講座課程有興趣者,請至:
http://www.hsdc.com.tw/modules/newbb/viewtopic.php?topic_id=10&post_id=14&order=0&viewmode=flat&pid=0&forum=9#forumpost14

報名!

  • 講座主題:UML 2.0 Overview 及 EA 對 UML 2.0 的支援
     
  • 內容:
    1. UML 2.0 Overview — 概觀介紹 UML2.0 13種圖及應用。
      — Behavior diagrams
      — Interaction diagrams
      — Structure diagrams
    2. EA (Enterprise Architect) UML 工具對 UML 2.0 的支援。

     

  • 時間:2005/1/15 (星期六) PM13:10 ~ PM 16:30
    (三小時的上課時間,並留半小時供學員提問)
     
  • 對象:對軟體設計有興趣者,包括在職軟體開發人員及相關資訊科系講師及學生等。
     
  • 地點:台北市重慶南路一段57號10樓(暫定,視報名人數調整)
     
  • 主辦單位:HSDc 軟體設計顧問團隊
     
  • 講師:賴信仁(Ringle Lai) and 王克明(Kenming Wang)
     
  • 報名方式(請選擇其中一種方式報名):
    1. 請於此本討論區回應留下報名資料 (不需註冊會員)。
    2. 請 email 給聯絡人,並留下報名資料。

    ** 報名資料請留下: **
    ——————–
    姓名:
    任職公司及職稱:
    Email:
    聯絡電話:
    ——————–

  • 承辦人:
    Steve Tsou(鄒順安), email: shunan.tsou@msa.hinet.net
    TEL: 02-27227179, FAX: 02-27234296
     
  • 備註:
    1. 本次講座預計開放 35 個名額,完全免費。
    2. 參加學員可免費索取 「EA 試用光碟」、「UML2.0 相關文件及規格」、「本次講座教材」等。

關於設計思維的落實 — 自問自答

Q1.為什麼程式設計師不太重視設計(Design)?
A1.

  • 傳統 “Top/Down” 分析->設計->實做 的迫害,使得程式設計師根本就不相信設計圖與程式碼是一體兩面;設計圖是空談、設計圖是文件、設計圖是造假(嚴重了!)
  • 太麻煩,無法看到立即可執行的產出(應用程式)。人們往往要 “眼見為憑”,尤其是 PM、老闆。
  • 不知該如何表達,用 UML?覺得好像是要去學另外一種語言,粉累… @$~
  • 傳統的包袱、本位主義,認為程式設計師就是該用原始程式碼來溝通。

Q2.是否應該把想法表達出來在設計圖上?
A2.

  • 當然,用嘴巴講不清楚、用程式碼除了 “同類” 的看得懂(要看懂別人寫的也要花很多時間滴~),PM/SA/SD,怎麼看得懂?
  • 用圖來溝通最簡單了,只要不要畫得太過抽象畫,大約解釋一下為什麼這麼畫,應該可以讓團隊成員很快就看懂你的 “塗鴉”。
  • 往事用圖來回味是最輕鬆愉快的了~,若是用程式碼,嘿嘿,光自己三個月前寫的,自己都已經看不懂了,更何況別人?

Q3.那麼,該如何將腦海裡的想法表達出來?
A3.心中先有個標的:

  1. 你要表達什麼(What)?
  2. 你要表達給誰看(Who)?
  3. 為什麼(Why)是這樣表達?
  4. 你該如何(How)表達?

例如,Client/Server,畫兩個圈圈,一個圈圈代表 “UI Form”;另一個圈圈代表 “Database”。”UI Form” 圈圈畫一個箭頭指向 “Database”。如此從圖就可以看到,兩個元件(Component)的相依性(Dependency)關係:”UI Form” 圈圈元件相依於 “Database” 圈圈元件。

同樣,你有幾個 “Class”、”Class” 之間又是怎樣的呼叫來、呼叫去的,如何表達?
就把每個 Class 畫一個圈圈,然後再用箭頭連起來;若是要呼叫的 Class 是在另外一個系統上,那麼,被呼叫的 Class 就是小圈圈 — 被框在該系統大圈圈內囉~

用什麼工具來畫圖比較理想?
用 VISIO? WORD? 乾脆直接一點,畫在紙上,應該夠簡單了吧?

擔心語法表達的問題?
唉呀,先把圖畫出來吧,就像小朋友那樣…
我想到什麼,我就畫出來,你看不懂?我來說給你聽,或是我再來把圖修正一下吧。慢慢的,你就能看得懂我想表達什麼囉~

UML 的問題?
慢慢的,一點點的學習、一點點的修正,一點點的嘗試,慢慢會搞通的啦(搞不懂 UML 也無所謂,自家人都看得懂,又不外包的話,”Who Care?”)。

將想法用簡單的設計、簡單的方式來表達在圖上。
一個人開發的話,可以慢慢反思自己的設計… ; 團隊開發的話,成員之間可以分享彼此的想法、集思廣益。
不需要花超過一天,有初步的共識後,就直接寫程式來落實印證,然後再回饋(feedback)結果回來,做一些修正、加一點功能。如此循環 “簡單設計” 、“馬上落實”

這樣不是很好嗎?

“簡簡單單”的概述軟體開發流程與UML

或許?剛入門的軟體開發者還不一定很清楚軟體的開發流程(Development Process)與UML到底有何關連?
所以我想用簡簡單單的幾句話來概述為何是 UML?又,為何沒有所謂標準的開發流程?

軟體應用系統的開發,通常是以專案(Project)的方式來進行。由包括 PM(Project Manager)、Architect(架構師)、HSD(High-level system designer)、DSD(Detailed system designer, 接近 CTO 的角色)、Programmer(程式設計師)等各種角色所組成的團隊。在一定的時程內,運用有效的資源,來達成有效率的系統開發。

專案開發的期間,在每一個階段會由不同角色的開發人員,依據職責來產出包括需求設計、軟體設計圖、程式碼...等。在有限的時程與資源,如何做最有效率的專案控管,團隊之間的 ”溝通”與所制訂的 ”開發製程” 可說是影響整個專案成敗的最重要關鍵了。

UML(Unified Modeling Language),統一模式語言,已成為標準化、視覺化的塑模工具。無論作為軟體開發團隊內部溝通、或軟體設計與程式寫碼的兩地(如台灣設計、大陸施工)分工模式,UML 是唯一可以跨國界、無縫式地從企業流程分析、系統分析/設計、並銜接到系統開發階段的最佳表示法(Notation)。UML 並已成為軟體業界的國際標準。

至於開發製程,也有業界所推出 RUP(Rational Unified Process)、XP(eXtreme Programming)乃至於所謂的 “Agile Modeling Process”。
每種開發製程理論均有它的核心思維,但其目的均在於期望能在專案的四大變數:”成本”、”品質”、”時程” 與 “規模” 之間達成一定的均衡。

開發製程無法如 UML 一般可以成為所謂的 “國際標準”,原因即在於專案的性質及成員的素質等因素均不盡相同。但上述提及業界所推的開發製程,卻可以成為開發團隊在自訂自己內容開發程序時的最佳參考與範本(Template),甚而可以成為很好的輔導工具。

這麼說好了,團隊開發成員之間可以講相同的語言(UML),以利相互的溝通;但每個團隊要如何達成目標,則各有其方法與程序(Process)來達成任務。程序是 “How-to”,每個團隊的 “How-to” 是不會完全一樣的。

又,為何是用 UML 來作為溝通的工具?

由於擔任系統開發的各種不同角色的團隊成員之間需要能做有效率地溝通,傳統的系統開發,大部分是以所謂企業流程圖(Business-flow diagram)或以程式碼來溝通。
前者是從在企業內部擔任高階經理人的角度來看待系統,所表達的往往是系統的功能面需求(Functional Requirement),並不足以表達軟體系統的內部結構;而後者,又太接近與系統平台面相關的程式碼,且每個程式設計師的程式碼撰寫風格不盡相同,直接以程式碼來作為團隊之間的溝通,對 PM及SA/D等人的解讀障礙度非常高。
前者太粗糙(coarse-grained);後者又太細緻(fine-grained),都不足以成為團隊所有成員之間的溝通工具。

俗話說:「一圖勝過千言萬語」。使用圖形(Diagram)的方式來表達內心的設計思維,會是一個很好的溝通工具。
就如同建築業的建築師,在施工前會先以設計的藍圖來表達對建構實體高樓大廈的想法。且設計的藍圖會因為不同的作用而有不同種類的表達,例如鋼架結構設計圖、水電管線配置圖、室內設計圖...等,均是設計師與施工人員在施工之前作為溝通及確認施工前的最重要依據。

貝多芬用五線譜來創造音樂,我們用UML(Unified Modeling Language)來設計軟體;UML有如五線譜,兩者都是模式語言,只不過前者通用於軟體界,而後者通用於音樂界。

軟體思維顧問

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

Personal