{iThome 書評} UML 精華第三版中譯本

UML精華第三版--標準物件模型語言
— UML Distilled Third Edition UML精華第三版–標準物件模型語言 — UML Distilled Third Edition
———————————–
作者/Marting Fowler/著
譯者/趙光正/譯
出版社/碁峰出版
ISBN/9861540393

前言

我教授軟體設計課程多年來,經常對學員建議要常看書,但不是看使用手冊這類的操作性 How-to 書籍,工具書若是因為工作需要,擺著幾本當作參考無妨;或者,若能學會如何交一位好朋友—Google 那更好。從它那裡,可以找到太多 How-to 性質的答案。而到最後你就會知道,學會快速操作使用,原來就是要懂得如何下對搜尋的關鍵字,如此而已。How-to 是越來越容易從網路上找到答案,相對來說,軟體開發人員,就可以把更多的時間與心思擺在軟體設計的思維上。而著重軟體設計的書籍,還真的是只有國外幾位頂尖軟體大師的著作可以學習。只是軟體人員一般會對原文書籍有恐懼感,以及,經常會有一種讀書的壞習慣—想要把它看懂。嗯,想要看懂是壞習慣,沒錯! 所以看書才會覺得有壓力,才會想要從第一頁看到最後一頁,然後大多數都只看到前三章就看不下去了。閱讀軟體設計書籍就是要不求甚解,沒必要想要得到所謂 “唯一的答案”。就是如同看漫畫、金庸小說般,那是一種享受,是對某一主題來作思考與體悟。當然,你起碼就要能分辨,你所選閱的軟體書籍是否原作者有自己的 “想法”,那很重要! 沒有自己想法的書籍,實在相當多,難怪乎有許多讀者 “看不懂” 坊間所謂的 “物件導向系統開發” 的書籍,我覺得是蠻正常的。當你能 “感受到” 作者想要透過書中的文字,來表達他的想法,甚而,還逐漸能猜得出作者內心中的 “假設點”,那麼,你就能知道,這是一本可以值得學習的好書!

「UML 精華(UML Distilled)」,是軟體設計叢書中,最能表達出作者自我又帶著創意性的想法。只是以閒話家常的方式,以口語白話的文字表達,只有薄薄的一本書,卻能精彩活化描述出 UML (Unified Modeling Language, 統一塑模語言) 十三張設計圖的精髓。我覺得 Kobryn (UML 規格制訂主席) 在推薦序文內說得最好:「自古以來,天縱英才的架構師與最具智慧的設計師都瞭解何謂 “簡約之道 (the law of parsimony)”。」 他甚而還引用了佛家禪宗的心法來解釋簡約之道:「禪宗的心是初學者的心」。而軟體與佛家的智慧是一樣的,是不受時空限制的,其要旨均在於如何將繁雜的表象萃取其本質 (essence),讓形體 (form)可以很協調地與功能融合在一起。

Martin Fowler,正是軟體界具有真正智慧的軟體大家! 所謂的 “簡約之道”,真正在本書中發揮得淋漓盡致。他就是能用迷人、口語化的寫作風格,來寫出「UML 中最有用的一小部分」,而這一部份,正是可以幫你完成百分之八十工作的百分之二十的精髓 (8/2 法則)。 Fowler 是我在軟體業界最為景仰的大師,想想看,有誰能從架構、分析設計至實作的垂直層次寫出這麼多的經典書籍呢? 包括了 “Analysis Pattern”、”Refactoring (重構,國內由侯捷大師翻譯)”、”Patterns of Enterprise Application Architecture” 等。 對於 Martin Fowler,真的也只能想到 “天縱英才” 這樣的字眼,來表達出我個人對他的尊敬與崇仰。

先瞭解本書的架構大綱

從一本書中的目錄,大概可以知道作者所要表達的核心思維會擺在哪裡。前兩章論及了軟體開發方法論 (methodology),這裡理所當然會介紹 UML 的簡介,以及現今主流的開發流程;然後從後續的章節,就是以每一個章節來介紹 UML 十三張圖;而關於類別圖,Fowler 則是用了兩個章節來作說明。而且蠻特別的是,第三章就開始介紹類別圖了,這可是與一般軟體設計書籍最大的不同之處—先從需求分析著手。至於需求面的設計圖,包括了使用案例圖與活動圖,則是擺在中間的章節,從第九章起才開始介紹。從這樣的編排來看,你就可以知道 Fowler 最為重視的會是軟體的結構分析,而這也是本書最精彩之處,包括類別圖與循序圖的介紹與其想法的論述。

軟體開發方法論 — UML 與 開發流程

所謂的方法論包括了兩大要素:溝通的機制與開發流程。 UML 正是利用圖形標準化的模式語言,來作為團隊開發之間溝通的最佳機制。Fowler 在對 UML 的簡介裡,說明了 UML 的發展歷程—由三巨頭的統一方法論而成形的;歷史的典故瞭解一下就可以了,不過,Fowler 很幽默,還提及了在 95 年的 OOPSLA 大會上,Rumbaugh 的高聲一曲來作為慶祝 0.8 版草案的問世。嗯,大家都希望那會是最後一次聽到他的歌聲。 🙂

Fowler 也提了對 UML 的用法,有分為草稿式與藍圖式。前者是將 UML 圖形作為溝通的機制,不講究精確的語法;後者則是要求精確性高的設計,而以此可以讓程式設計師依樣畫葫蘆寫程式。嘿,我也與 Fowler 的想法是一致的,比較偏向草稿式的作法。道理很簡單:1. 你不能假設你的設計會是正確無誤的;2. 絕大部分的軟體人員,連 “畫出來” 都不太有勇氣了,更何況要求僵化的工程模式? 那可會嚇跑一堆軟體人員,而違背圖形模式開發的的本質—溝通。

雖然是介紹 UML 語法,不過 Fowler 還是特別開出一個章節來介紹開發流程。在該章節中,首先就比較了所謂反覆式(iterative)與瀑布式(waterfall)的開發風格。現今主流的開發流程都一致認同反覆的開發方式,但卻很難做得到,因為會衍生不確定性的恐懼感,與專案管理的議題。Fowler 用了一個很有趣的字眼,「偽反覆式開發方式 (原文是用 pseudo,我覺得真的很客氣,不是用 fake)」:雖然大家都宣稱正在採用反覆式開發方式,不過實際上卻仍是瀑布式的開發方式。哈,這與我經常在課堂上常提,導入如 RUP 軟體製程的開發公司,大部分是 “藍皮綠骨”,因為他們根本就作不到使用反覆的開發方式;因為,他們會重視制度與管理,卻經常忽略了人本—而這正是反覆式導入成功與否的關鍵所在。

章節後面則簡述了關於 “敏捷式(Agile)”、”極致軟體製程(XP, eXtreme Programming)”、”RUP (Rational Unified Process)” 的比較。我覺得 Fowler 在這部分道出了開發流程的本質:流程僅是框架,只是一種建議、一種範本,可千萬不要傻傻的以為導入某一開發流程就可以解決軟體的根本複雜問題。我最喜歡其內的一個字彙:裁適 (tailor)—要懂得裁減開發流程以符合專案的需要。

軟體系統的根本—結構的分析與設計

UML 最重要的一張設計圖就是類別圖 (Class Diagram),作為軟體大家,Fowler 是最為重視軟體的結構分析與設計,而這也是軟體根本所在—非從表象的需求來看待系統的開發,而是直指核心,找出軟體的本質。

兩個章節中,基本概念是介紹了類別圖的基本語法,而在高等概念則是說明了類別之間的關係,與一些比較少見,如關連類別、範本類別等的說明。要看這兩個章節,最好能有對所謂物件導向觀念有基礎功夫,如什麼是物件、類別 (老實說,即使對老手而言,可能還不一定清楚物件與類別的區分)。高等概念其實不容易看懂,更何況,這還只是介紹語法而已,並沒有教你如何抓本質性的類別,那會是很需要抽象高層次的悟性,是與 IT 技術沒有多大關連的。

真要談到程式設計人員會關心的,反而不是類別圖,而會是表達物件互動的循序 (Sequence)圖了。Fowler 提到了所謂集中式與分散式的控制設計方式,這裡他寫的真是精彩,相當有趣! 你會發現到,Fowler 沒有說集中式控制方式的不好之處 (事實上,這是最容易的開發方式,但嚴格說來,它根本不是物件導向),他用了另外的說法:就是強烈要求寫集中控管的軟體人員採用分散式的設計風格,也不說明為什麼,但總有一天,他們會恍然大悟,這時候,他們的腦袋將彷彿重生。這真是最高段的損人不帶任何髒字:重生之前到底這些軟體人員的腦袋是長什麼樣子?

系統的外觀—需求分析

第九章以後 Fowler 才提到了需求的分析,使用案例模型 (Use Case Model) 與活動 (Activity)圖。使用案例模型包括了案例圖與敘述,Fowler 在此並沒有著墨甚多,只是針對基本的語法作說明。事實上,在案例敘述這一部份,他其實是參考了 Cockburn “Writing effective use case (中文譯名:使用案例寫作實務)” 一書。然後他還特別提了:對於使用案例,請把自己的精力放在說明文字,而不是在圖上,使用案例敘述才是全部價值之所在。喔,正是由於這段敘述,我並不那麼為然,還特別開了研討會來說明使用案例圖的價值與妙用。其實呢,要先釐清假設點:需求敘述對需求分析人員是最重要的,那沒錯;但是,使用案例圖則是軟體架構師的利器—用來界定系統開發範圍,區分內與外,決定那些要作、那些不作。

其它的設計圖

Fowler 很有意思,他不覺得重要的設計圖,即使是一個章節,大概就是一頁的文字說明,再加上一張範例圖就結束了,也不囉唆。例如部署(deployment)圖、互動概觀 (interaction overview)圖、時序(timing)圖 (讓我想起電子實習的示波器,真是噩夢)等。我是把這些設計圖稱之為 “雞肋” — 食之無味、棄之可惜。

倒是還有兩張蠻有價值的設計圖:狀態(state)圖與複合結構(composite structure)圖。 第三版改版最多的部分就是在狀態圖的說明,它會與嵌入式系統設計或者複雜的畫面狀態設計有相當的價值貢獻;而複合結構圖則是 UML 2.0 規格最有價值的一張新視圖,它同時結合了類別與元件(component)圖的優點—表達整體系統對外的介面,以及系統內部的結構組成元素。

結語

這本書目前出到了第三版,我則是每一版都買,而且你會發現到,Fowler 在每一版的制訂,並不是新增補充而已,而是會把他當下對 UML 的心得與體悟,給整個重新寫到修訂的版本內,但仍還是可以維持那麼 “薄薄的一本”。三不五時,我仍會拿出來翻閱,還不時會發出會心的微笑;而且你會發現到,新手看了本書,收穫甚多,而老手再重新看時,卻又仍有不同的深刻體會,這本書就是如此的精彩!

譯者趙光正先生,他翻譯過許多相當棒的軟體設計好書,甚而在下一期我準備介紹的書評—「UML 與樣式徹底研究」,也是由他所翻譯的。而這兩本,正是我極力推薦每位軟體從業人員都應該要必備的好書! 也因為有如此高品質的翻譯本(幫光正君掛保證,他翻譯的每一本書都很棒),使得初學人員不致因原文的學習障礙而打退堂鼓 (當然,就長期而言,軟體人員還是要學會與習慣於閱讀原文書籍)。

※參考之前寫的書評

【公佈】五,六月份的軟體設計課程—台中場UML與非正規學分班系統分析課程

各位 台中地區 的朋友們大家好:

開課日期: 2007/05/26、27(星期六、日) 共兩日

HSDc. 今年在教育訓練的計畫是,在中部與南部至少每三個月舉辦巡迴性的「軟體設計單元性」課程,能讓中南部地區有志於學習軟體設計各類議題的朋友們也多了一個充電學習的管道。HSDC. 已與「逢甲大學」洽談場地教室與資源等合作事項,台中地區的學員們,得享有交通便利、且環境清幽的上課環境。

同時,我們也熱烈邀請,台中地區大學資訊科系的助教、講師們,歡迎蒞臨旁聽,完全免費
另外,關於 HSDc. 的所有課程,只要是 出具家扶或清貧 等證明的學員們,也是完全免費

更是歡迎報名的學員,能將在日常工作上的設計與實做所碰到的各類問題,課餘或課堂中,HSDc 講師們均會熱心協助提出解決方案的...

課餘結束後,HSDc. 會在星期六舉辦晚餐的聚會(成本問題,煩請與會人員們自備晚餐費用),屆時更是期待能在茶餘飯後之餘,一同來探討軟體各類事項的議題,那是非常有意思與有趣的活動。


台中場次】UML 2.0 觀念引導與實務操作入門 (星期六、日) — (05/26、27)

課程大綱  我要報名


課程簡述:
  • 以 "問題-解決方案(Problem-Solution)" 的觀念傳授與實做方式,引導學員實際針對案例分析並利用 UML 工具畫出 UML 2.0 十三種圖。
課程特色:
  1. 示範與引導學員實際操作與練習。
  2. 第一日上課時即會發送給學員教學光碟,內容提供 EA 自動安裝與教材內容及範例。
  3. 提供兩個完整的案例研討(Case Study),自然又流暢地整合:
    • UML 2.0 13張 設計圖 (包括企業流程、系統需求、內容結構、動態行為等構面)。
    • 提供 UML Model 檔(EA 6 格式)。
  4. 本課程均保留與提供了學員免費再旁聽乙次同樣課程的權利,以一次低廉的收費,就可以擁有兩次上課的收穫,課程的師資、內容與品質,我們有信心是不會讓學員們失望的。
課程目標:
  1. 畫每一個 UML 圖之前,會先以一個問題的陳述,來說明應用該圖形的時機與場合,然後提出具體的解決方案。
  2. 課程提供兩個案例,並涵蓋串連整個 UML 13 種圖。
  3. 完全以實務為主,指導學員如何利用 EA(Enterprise Architect)學會畫 UML 2.0 的圖形。
  4. 學員於課堂上實際親自操作 UML 工具,由講師示範與指導畫每一張圖的技巧與圖形的元素說明。
授課日期
  1. 2007/05/26、27(星期六、日) 共兩日。
  2. 每日上課為六個小時(AM 9:30~12:30、PM 1:30~4:30),課後並留半個小時供學員自由提問。
授課地點:
  1. 逢甲大學會議廳教室,地址:台中市西屯區文華路100號。
  2. 上課前一週會通知上課所在教室位置(待本部與該校總務處確認教室後公佈)。
  3. 報名人數滿 10 人即開班(同時保留 5 名學員重新選修該課程)。
適合學員:
  • 系統分析/設計(SA/SD), PM, Programmer 等在職軟體開發者或在學學生。
  • 想實際學會如何利用 UML 工具來畫 UML 2.0 十三種圖。
  • 看了很多 UML 書籍,仍然無法在正確的時機畫出正確的 UML 設計圖。
課程費用:
  1. $3,600, 含稅。
  2. 曾經上課過本公司的「單元系列課程」學員,優惠 $3,200,含稅。(請記得註明為舊生,本公司查詢確認即以優惠算)
  3. 三人同行,或同時報名另一單元課程(兩日),亦比照舊生的優惠折扣,每位只需$3,200(含稅)。
師資簡介:
  • 賴信仁(Ringle Lai),王克明(Kenming Wang)
  • 擅長以非常淺顯易懂的比喻及說明,將複雜的系統抽絲剝繭,重新釐清脈絡,讓學員一清二楚,並善於引導學員具備設計應有的反思能力。
使用教材:
  1. 由授課講師提供講義,包括內容、案例分析與 UML 13 種圖範例。
  2. 學員可攜帶相關 UML 參考書籍,並對於書中內容有問題者,可以直接提問。
開發工具:
  1. EA 6.5(Trial) UML Tool。
備註:
  1. 教室設備包括白板與投影機,由講師親自說明與操作示範。(學員可攜帶錄音筆)
  2. 學員最好能攜帶 Notebook,可以於課程中實際操作與練習。
  3. 報名滿 10 名即確定開班,同時保留 5 名學員重新選修同一課程(請攜帶原上課講義)。開課前兩日會以電子郵件聯絡與通知學員。
  4. 為確保報名足額人數,煩請先以 ATM 轉帳預約費用($1000),並請於報名表備註欄位內,註明您的轉帳帳號末 5 碼與轉帳金額。(若實在不及轉帳者,仍可現場報名,但請在報名表內註明現場繳費)。
  5. ATM 轉帳帳號: 新光銀行 (103) 帳號: 0772-50-100979-9
課程諮詢:

聯絡電話: (02) 2722-7179
Email: service.hsdc@gmail.com
專業論壇: http://www.hsdc.com.tw

各位好:

開課日期: 2007/6/30 每週六白天,共九個星期。
54 Hrs、完整軟體系統開發、分析與設計的課程,只要 NT$9,000
(同等課程原價學費為 $25,000 以上,其它差額,係由教育部與本中心吸收補助。)
(家扶清貧同學,只要出示相關證明,與本中心聯絡報名,費用全免!!)

這是教育部委由 HSDc. 於台北地區舉辦之{教育部非正規學分課程}系統開發分析與設計 課程。上完本課程,即可取得大學同等資格之三個學分(大學、研究所承認資格, 已奉教育部台社(一)字0950154417號核定)。

本課程為教授以大學水平為對象及對系統分析、設計入門的學員,課程內容儘量採淺顯、凸顯主題,卻又不失實務,讓系統分析與設計不會背離現實的平台與開發環境。除了適合想修習軟體資訊工程、取得學分的同學外,對於一般已擔任軟體開發職人員,想習得正規軟體開發的方法與正則的系統分析與設計的思維,更是應該把握本系列的課程。

P.S. 高雄地區同等課程可參考: http://www.taiwan-cspa.org 諮詢報名


{教育部非正規學分課程}系統開發分析與設計 (54 Hrs, 06/30 開課, 每週六白天)

課程大綱  我要報名


課程說明
  • 本課程係為本顧問中心與教育部合辦之「軟體資訊開發與管理」系列之大學教育訓練課程。學員上完本課程(54 Hrs),即可取得大學同等資格的三個學分(大學、研究所承認資格, 已奉教育部台社(一)字0950154417號核定)。
課程目標
  1. 瞭解軟體開發的模式,以及符合現代 e化系統開發的流程與方法論。
  2. 瞭解物件導向本質觀念與在軟體上的應用。
  3. 瞭解系統需求分析與結構設計的觀念與塑模能力。
  4. 學會正反向軟體工程與應用程式碼的部署。
上課日期
  1. 2007/06/30 起,每週六白天,每次上課為六個小時(AM 9:30~PM 4:30),共九個星期。課後並留半個小時供學員自由提問。
  2. 預定上課日期: 6/30, 7/7, 7/14, 7/21, 7/28, 8/4, 8/11, 8/18, 8/25。
  3. 遇國定假日或颱風等因素,則延至下一週上課日(本中心會主動通知學員),以此類推。
授課地點
  1. 開羅會議中心,地址:台北市光復南路65號B2 (光復南路、市民大道交接口)。
  2. 參考交通與地圖
適合學員
  • 具高級中學同等學校畢業、或同等學歷資格、或年滿22歲以上等人員。
  • 學員最好有基本的程式設計能力(基本即可)。
  • 當然,本課程也極為適合想瞭解與學會整套軟體系統開發、分析與設計的軟體開發人員。
課程費用
  • 9,000元,每學分3000元,計三學分 (含講義、稅金,但不含參考書籍)
  • (同等課程原價學費為 $25,000 以上,其它差額,係由教育部與本中心吸收補助。)
師資簡介
  • 賴信仁(Ringle Lai)、宋敏如(Cathy Sung)、陳明儀(Simon Chen)、王克明(Kenming Wang) 。
  • 授課講師均具有 10 年以上專業開發、輔導與授課經驗,必能帶給學員最正確的觀念與技術。
使用教材
  1. 由授課講師提供講義,包括內容、案例分析與 Model/程式碼 等範例。
  2. 學員可攜帶相關軟體設計參考書籍,並對於書中內容有問題者,可以直接提問。
  3. 建構選讀參考書目:「Applying UML and Patterns(Craig, Larman, 有中文翻譯版, 活用 UML 與樣式, 趙光正譯)」, 「UML User Guide(Grady Booch, Ivar Jacobson, James Rumbaugh)」, 「Object Oriented Analysis and Design(Grady Booch)」。
核發證明
  • 本課程學期中與期末均會舉行測驗,每次測驗時間為三個小時。
  • 測驗成績達 60 分以上,缺課未超過總上課時數六分之一,由教育部核發學分證明書(有效期為十年)。
備註
  1. 教室設備包括白板與投影機,由講師親自說明與操作示範。(學員可攜帶錄音筆)
  2. 學員最好能攜帶 Notebook,可以於課程中實際操作與練習。
  3. 報名學分班學員,請先以 ATM 轉帳預約費用($1000),並請於報名表備註欄位內,註明您的轉帳帳號末 5 碼與轉帳金額。
  4. ATM 轉帳帳號: 新光銀行 (103) 帳號: 0772-50-100979-9
  5. 本課程上課學員需滿 20 人以上,若未達上課人數則延期至下一梯次開課,已報名學員,本中心會電話通知,並主動辦理退費(或可保留至下一梯次)。
課程諮詢
  • 關於課程內容與學分等問題,可直接聯繫本中心。
  • 諮詢電話: (02) 27227179 聯繫郵件: service.hsdc@gmail.com

類別之間的關係(Relationship) — 一般化—特殊化(Generalization-Specialization) (3) — Basic

說明

從生活面的觀點來觀察時,當發現到兩個以上的類別有其相似之處(但又不盡相同),我們可以把相似之處抽象(abstract)放在更高層次的一般性類別。例如,觀察「貓」與「狗」兩個類別,是否有可能抽象化成為一般性的類別? 兩者的品種完全不同,但其實也存在著某種程度的相似性,事實上,若我們要開發一個 “寵物店管理系統”,那麼,其實很自然,就可以將此兩個類別抽象成為「寵物」這個一般化的類別。相對來說,只要是符合「寵物」一般化類別共同特性的其它類別,包括可愛、能取悅、陪伴主人等特徵與行為,就可以成為「寵物」的特殊化類別。一般化—特殊化關係的 UML 表示法如下圖。

 

範例、一般化—特殊化的 UML 表示法
圖1、範例 一般化—特殊化的 UML 表示法

概念上,所有貓、狗的個體(instances)從定義來看也都是「寵物」的個體,那麼就可以將「貓」、「狗」等視為是「寵物」的子型態(sub-type)。由此可以看出,「貓」是一種特別的「寵物」。其中一個重要的觀念在於,所有與「寵物」有關係的特徵(features),包括關連、屬性(attributes)與操作(operations),對「貓」、「狗」、「烏龜」來說也都是成立的。

從軟體的觀點來看,對一般化關係的具體實作就是 “繼承(inheritance)” : 「貓」是「寵物」的子類別(sub-class),在主流的 OOP 語言,包括 Java 與 .NET 等,子類別會繼承超類別(super-class)的所有特性,而且還可以覆寫(override)任何超類別的方法(method)。

一般程式設計人員最容易誤解物件導向的繼承觀念就在於,以為繼承是被用來 “可重用(re-use)”的:可重用既有的程式碼。其實繼承的最重要原則是在於 “可被替代性(substitutability)”,而這正是物件導向另一個非常重要的思維– “多型(polymorphism)”:讓外界(Client)能以「一視同仁」的角度來看待多個特殊化類別所抽象出的一般化類別!

關於 "多型" ,留待在在進階主題內再行詳述。請記得,多型同時也是解決軟體複雜度的一個重要原則。

閱讀全文 »

【設計樣式】「Chain of Responsibility」的範例與說明

範例描述

“敗家子” 是一部經典的武功喜劇,關於本片的劇情介紹,可以參考:【老片分享】經典功夫喜劇片—敗家子
其中,元彪所飾演的 “敗家子”,好打架,經常製造許多麻煩,但他又是九代單傳的寶貝兒子。父親怕他受傷,所以派了一個隨從 “派通街”,在背後協助解決所製造的麻煩。

敗家子是 “麻煩製造者(trouble maker)”,而派通街是 “麻煩處理者(trouble handler)”,敗家子所闖的禍,均交由派通街來處理。

而隨著製造的麻煩越多,派通街需要更多的助手來「分門別類」地處理,這些處理者逐漸有系統性地形成一種 “串鍊(chain)”,當麻煩透過派通街送進來時,第一個處理者認為麻煩不是他所處理的,就會交給後續的(successor)處理者來處理,如此依序跑完整個 “串鍊”,若沒有人可以處理,則拋出 “無法處理” 的訊息。

CoR(Chain of Responsibility) 的說明

敗家子永遠不用擔心 “誰” 來幫他處理麻煩,只要將麻煩丟給一致的介面(interface)–派通街處理即可。

視麻煩的程度或種類,交由串鍊中某一個處理者來處理,當然也有可能因麻煩大到無法解決,而沒有處理者可以處理。

這是一種 “責任的串鍊(Chain of Responsibility, CoR)”,Client 端(敗家子)不需要也不會知道 “誰” 來處理他所丟出的麻煩,如此可以降低 “Client” 與 “處理者” 的耦合(coupling)程度;但相對,”串鍊” 的處理者最好不要太多,否則因責任一直轉派的緣故,會降低處理效率。

CoR 類別圖(Class Diagram)說明

圖、CoR 的 UML 類別圖
(點擊圖片鏈接看原圖)圖、CoR 的 UML 類別圖

  • 把 “派通街” 角色設計為 “抽象類別(abstract class)”,他本身只負責制訂一致性的處理介面: handleTrouble(),與實作指向後續者(successor)的鏈結。
  • 來自 “敗家子” 的 “Trouble” 訊息,會依照麻煩的大小程度依序交給 “大、中、小” 三個具體的類別來處理;其中 “Null Trouble Handler” 類別,並非是空的,而是指麻煩超乎程度而無法處理了。
  • “大、中、小、Null” 四個具體(concrete)的類別,會覆寫(override) “handleTrouble()” 操作(operation),個別實作處理麻煩的方法。
  • “麻煩(Trouble)” 被當作參數從敗家子傳給派通街,實做上可以是 “字串”、”XML”、”物件” 等。

使用案例分析常見的幾個問題

前言

要能建構一份有效的使用案例需求模型 (Use Case Model),比想像中得難,使用案例是 “易學難精”,只是那麼幾個簡單的圖形元素來畫使用案例圖、以及僅用白話的文字敘述來紀錄使用案例的需求描述,但是,若沒有把持使用案例最根本的原則與精神,真的很難寫得好。筆者在諸多 IT 單位的顧問輔導經驗中,所看到多個單位所 “畫” 出的使用案例,10 個中就有8個有問題,探究其中最大的問題,在於寫使用案例的需求分析人員,很難擺脫掉 “既有傳統” 的束縛,例如會從企業流程 (Business Process) 的觀點來分析使用案例,或者是馬上就聯想到系統內部的實作問題,包括權限控管等問題。筆者常開玩笑的說,要能寫好使用案例,最好本身就是 “無知”,不知道企業流程的邏輯判斷規則、”看不到” 系統內部是如何實現(Realize)使用案例的。奇怪的是,要能 “逼” 自己 “無知”,對系統需求分析人員好像很難,而且往往就是在不知不覺中,就把既往對 “領域” 與 “平台” 的知識給表達在使用案例中,事實上,根本就是把使用案例當成是 “另一種” 需求記錄的工具而已。

很是可惜,筆者一直認為,使用案例絕對是以 “專案型態(Project-based)” 開發的最有效利器,它表達的就是 “純粹” 的資訊系統 “局部” 功能觀點的需求模型,只要能寫好使用案例,甚至在不需要作系統內部結構分析的情況下,馬上就可以轉移至程式碼的實作階段,而且是很快速直覺。再利用分析層次的類別 (analysis class),就可以建構符合三層 (3-tier) 結構的 MVC 模型,有效隔離 UI 與資料庫的變動性,同時,再加上一個極為重要的手段:
”對每一個使用案例”,都加上能驗證功能的測試程式碼!” 如此在每一次的功能需求變動,都能提醒開發人員注意變動的影響部分,包括功能測試碼也跟著要修正。

為了順應短線的專案開發生態,快速實現「使用案例」,馬上導出至系統的實作,是最有效與最現實的手段。然後加上兩個配套的措施,以確保專案的品質:以使用案例為單位,撰寫功能測試程式碼;利用分析類別,建構符合 MVC 的三層實體框架,以隔離 UI 與 資料庫的變動。

而當第一個釋出(release)的專案能滿足系統的功能需求後,因此而能取得更多的開發資源,以及開發人員的溝通默契與技能逐漸成熟後,且已有基本的框架結構,此時再針對程式碼施以重構(refactoring),以及對結構作重整(refine),兩者是屬於系統內部結構分析的範疇,如此而更有機會成為可再利用性高價值的產品(Product)。

所以,如何寫出有效能確實表達系統功能觀點的使用案例,可以說是專案開發成功與否最重要的關鍵。但如同前述,使用案例是「易學難精」,在此筆者列出幾個比較常見的問題,再以簡單的三言兩語來說明為何這些是問題、SA 大概是以什麼角度、假設點在分析使用案例的,然後筆者再提供修正後的建議。底下的每一個問題,是經過簡化,實際的案例,大部分是同時有著眾多下述的問題合著來的,而開發團隊卻經常有茫點,而無法理出問題會是在哪裡。

1、從企業流程的觀點描述使用案例之間的關係

問題:
這幾乎是因為太清楚領域知識與業務流程的 “資深 SA” 所畫出來的,經常都會把使用案例當成是企業流程的活動(activity),然後 “想辦法” 將這些使用案例依據業務流程的規則與順序給 “串起來”。請記得!! 使用案例是不表達業務流程的,業務流程的表達,會利用如活動圖(activity diagram)來描述,使用案例僅僅是表達參與者在某個時間點使用系統的局部功能觀點。

問題—從企業流程的觀點描述使用案例之間的關係
圖1、問題—從企業流程的觀點描述使用案例之間的關係

修正:
絕對不要把業務流程的觀點給表達在使用案例的,就是老老實實,根據參與者希望系統該提供 “哪些系統功能”,這些功能,就會成為一個個的使用案例。

修正—只 “老老實實” 表達局部功能觀點的使用案例
圖2、修正—只 “老老實實” 表達局部功能觀點的使用案例

閱讀全文 »

利用 UML 類別圖表達 CMMI Content 與範例說明

關於 CMMI

  • 與其說 CMMI 是流程框架(Process Framework),倒不如說 CMMI 是目標框架(Objective Framework)。
  • CMMI 是以 “流程區域(Process Area)” 為主要完成目標。無論是以 “Continuous” 或 “Staged” 的途徑(approach),均以 “Process Area” 為單位,來檢驗 “軟體能力” 的成熟度。
  • Ex. “需求管理(Requirement Management)” 為一個 “Process Area”,是 CMMI level 2 必須完成的主要目標。(level 2 需完成 7 個主要的 “Process Area”;level 3 需完成 14 個”)。
  • 每一個 “流程區域” 會細分為多個子目標。若該子目標只對應單一的流程區域,稱為 “特定目標(Specific goal)”;若子目標會涵跨多個流程區域,則稱為 “一般目標(Generic goal)”。
  • 每一個特定目標/一般目標會列出一到多個 “期望(expected)” 的特定實務(specific-practice, sp)/一般實務(generic-practice, gp)。實務為一段陳述(statement),表達了完成子目標時的作法。
  • 實務並非為絕對、唯一達成子目標的唯一作法,它是 CMMI 建議、期望的作法,但仍可就現實狀況來找出 “自己” 的的實務作法,重點是,能達成(achieve)子目標(GG/SG)的規範與要求。
  • 既然實務僅為敘述性的陳述,可以把它視為是 “抽象(abstract)” 的 “How-to”,要能找出符合實務的作法,可以從主流軟體開發流程,如 RUP/Agile/XP 等,找出實踐的具體手段。

CMMI 的 Model Content 為:Process Area, GG/SG, GP/SP。其中,Process Area 與 GG/SG 為達成軟體能力成熟度的必要元件(required component);GP/SP 則為 "期望(expected)" 的元件,屬建議性,並非絕對需要。若以 UML 類別圖表達 CMMI Content 之間的關連,如下圖1 表示。

利用UML 類別圖表達 CMMI Content 之間的關連

圖1、範例-利用 RUP/XP 方法論實現 Requirement Development -> SG3

CMMI Content 類別圖說明:

  • CMMI Level (2~5) 包含(aggregate) 多個“流程區域(Process Area)”。
  • 每一個流程區域會包含多個子目標(Goal),子目標依性質區分為“一般目標(Generic Goal, GG)”與“特定目標(Specific Goal, SG)”。
  • 將 GG/SG 設計為“Interface”的意涵在於,任一個具體(concrete)的實務(practice)類別,只要符合該子目標的介面規範即可,也就是說,CMMI 不規定“how-to”,只要能確實達成(achieve)子目標的規範即可。
  • GP/SP 可視為是“抽象(abstract)”的“how-to”陳述(statement),因此,具體實務類別也可以依循 GP/SP 內的陳述來具體實現。

閱讀全文 »

軟體思維顧問

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

Personal