This page looks plain and unstyled because you're using a non-standard compliant browser. To see it in its best form, please visit upgrade to a browser that supports web standards. It's free and painless.

Kenming's 軟體設計思維 會員登入 會員註冊

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.) 從今年 (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」,可以參考之。

一般,SA (這裡是指與客戶作需求訪談的分析師) 若是需求規格作得不好,拿回來給自家的程式開發人員 Coding, PG (Programmer) 肯定會哇哇叫,覺得需求不明確,無法正確實作。 SA 與 PG,長久以來,總是存在著溝通上的隔閡,包括看待系統的角度、包括價值觀等,經常是大不相同的。

不過,我就認識一個實做能力相當高強的軟體工程師,年輕脾氣又溫和。 最重要的是,他對軟體設計有著相當高度的熱忱,在他所負責的開發專案,總是會把一些物件導向的觀念帶進專案實踐,反正,他的專案主管不會管他用什麼技術做 出來,對 PM (Project Manager) 而言,準時交付專案才是最重要的事。 有趣的是,他說全公司上百多人,雖然公司已走向 CMMI 甚至往 Level-5 的認證,但是全公司只有他一個人在用所謂的 O-O,其他人還是走向 Web-based, Form-driven 的二維開發方式。 反正,CMMI 認證可不管你用什麼開發流程或技術,只有一個重點,就是要能作出美美的文件,可以說服評審委員、取得認證,這才是一等一的重要。

話說,這位年輕工程師實做能力非常強,所以相對多少也有取得專案主管與同僚的信任,甚而說服她們採用一些 "新" 的技術,例如 使用案例 (Use Case)。 喔,這位年輕工程師雖然是典型的物件導向狂熱份子,但是可不會把所有所謂他所認知的 O-O 給整個 Apply 到專案上,就是只採用一些他認為是關鍵性的技術,例如在 O-R Mapping 中,他甚至自行研讀 Martin-Fowler 那本 "POEAA (Patterns Of Enterprise Application Architecture)" 裡面所介紹的一個設計樣式,Repository,來實踐 O-R Mapping 的機制。 反正就是以實驗的心態,然後利用現實所開發的專案來驗證之。

上面他的事蹟是順帶一提的,我真正佩服的是,專案很趕,他也從不叫苦,反正,他知道他自己在做什麼就是了,而且他也有他的興趣、熱情,以及未來期許 當個軟體架構師為目標。 這些都只是過程,而且往正面一點想,他有實際的專案可以拿來實驗,那還不好? 對比於此,我可是對那種對現狀很不滿但又看起來很無奈、經常哇哇叫的軟體人員總是不以為然,要嘛,就是皮一點待著,裝著很忙,作個樣子就好了;要嘛就是多 提昇自己的能力,待價而沽,自己選擇想待的單位。 喔,那位工程師所待的公司環境可是不好的,與他聊天才知道有些 "腦殘" 的大主管,竟然還會要他們自行開發如 Msn 這樣的 IM(Instant Message)用來作內部的溝通機制,真難以想像,難道你會開發出比這麼多大廠推出的 IM 還要好? 如果有這樣的志氣,那還沒話說,但是,就是只有用來團隊內部的溝通,真的是 "吃飽閒閒沒事幹"。

還沒還沒,最最佩服他的,不只是他不叫苦而已,與他 Cowork 的 SA,要交付的需求規格文件,主要是以使用案例來紀錄的。 但是,那個使用案例,除了案例圖有橢圓形 (代表一個個的使用案例),還有那小人 (代表 參與者,Actor) 長得是與標準 UML 制定的一樣外,實在喔,嗯,不知道該如何形容耶,反正就是 "披著橢圓皮的狼",一點都不叫做 "使用案例"。

要是我,肯定會哇哇叫,問題是我們這位仁兄,實在有大器,不管妳畫出幾顆橢圓,隨便畫,只要不變成正方形就好,他就是可以生出應用程式碼來,還真的 可以跑。 說真格的啦,中小型專案,的確最關鍵的還是在實做能力。 在需求分析與結構設計上的講究,不盡然是影響到實作,而其實主要是在於延展性與彈性度、可維護性等的考量。

為什麼我們這位年輕的工程師可以這麼包容 SA,從來沒有怨言,甚至會主動補足這位 SA 的不足。 後來我見到這位 SA 後,喔,換成是我應該也會有無限的包容了。 因為:

  1. 這位 SA 是可愛美麗又活潑的女孩子。
  2. 原來已經是變成了我們這位仁兄的女朋友了啦。>-<

所以啊,這也就是我為什麼一直主張 SA 最好是女孩子來擔任啦。 除了女孩子對客戶的需求訪談比較有耐性外,回到自家來,團隊內部的開發工程師也會比較包容、更能溫柔的對待了。

朋友啊,是非要溫柔,慈悲得公理,智慧少煩惱。 團隊能和諧,我們的專案一定會往幸福安定之路的美麗心境界。 :-)