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 軟體設計思維 會員登入 會員註冊

"知道你要什麼 (What),再來決定你要如何做 (How-to)。"」 我一直覺得,在導入時間管理的應用工具前,這個要先想通。 我越來越覺得, "Do the right thing (做對的事情)""Do the thing right (把事情做好)",這兩句話可不只是表面說的那麼簡單,不是只有口號而已,裡面是蘊含了極有智慧的道理。要作一個所謂成功的人,我確定的是,這兩者缺一不可。 或者這兩句話也可以濃縮成明代大思想家王陽明所倡導的「知行合一」。通曉根本道理,並懂得能在現實的環境中務實應變,更重要的是,坐而言,還要能起而行!

"Do the right thing",就是對於要做的事情上,給予一個方向上的指引,是要能瞭解對自己在人生上的目標以及價值觀的認知;"Do the thing right" 就是要確實能有效率地執行要做的事情,不過我更覺得,那個有效率倒不如說是要能學會分辨與過濾雜事,只專注在最重要的事情上。

基於上述的分析與體認,我當然會希望現實的工具應用上,能協助我涵蓋到這兩大部分。

  • "Do the right thing (做對的事情)" 重點在於 目標設定與中短期的專案規劃 (project planning)上。
  • "Do the thing right (把事情做好)" 重點會在於 以週為單位,先預先規劃每週的行程安排,與每週約 3~6 件最重要的事項;然後再分解為較小的工作,分散放在每日的工作上。而每日的工作,必然要先規劃出最重要的 1~3 件工作,優先完成它!

在目標的設定規劃上,我還是認為 心智圖 是最佳的應用工具。從 3個月~1年的短期目標、1年~3年的中期目標、3年以上的長期目標;從自我省思、家庭生活、財務、健康、專業、心靈、學習等各面向,利用心智圖呈現出你想要的是什麼,再倒推規劃 (backward planning)具體可執行的行動 (action)方案,漸進循環 (incremental and iteration)地往目標推進、修正、調整,一個個地達成所設定的階段里程碑 (milestone),最終完成所設定的目標。

專案 (project)是目標還是工作? 我以為,專案可以是短期,可能約為一年內可以量化的目標;也可以是一組工作的集合 (a group of tasks)。 專案內的工作因為有關連性,所以往往會有樹狀複合結構 (composite structure)的關係;工作是有時限的,所以需要設定完成的優先順序與完成到期日。

重要需要優先完成的事情,是基於從你的目標設定而來的,是根據你的價值觀認知而定的。 諸多貓頭鷹或無尾熊型的動物性格,經常是把不必要的事情做得太好—這往往是源自於上司主管所交代,無論是合理或不合理,但是這些工作不一定是符合你的人生目標;請記得,務實不會是妥協於現實,但也不是昧於現實。是要能學會在現實與理想之間找出哪一個平衡點,在適切的時機,要能勇於踏出一步,發掘出屬於你自己的乳酪的。

不要花太多時間在不必要的事情上,只專注在最重要的事情上。 所以,對於許多 GTD (Getting Things Done) 工具給我的感覺是,太過繁瑣了些。這個方法論它連小事情都可以協助規劃的很好。對於紀律嚴謹、比較一絲不苟的人來說,它是很好的工具;但對於如我這樣較慵懶個性的人來說,它會給我壓力,看到每天有很多待辦的工作事項,我會心情很不好。但是,我仍希望可以規劃我自己的人生—只專注在我認為重要的事情上。如果每週只要能完成 3~6 件重要的事項、每天優先處理最重要的 1~3 件工作。事情少卻精,列在工作清單上也不會長,看起來也就不會那麼有壓力,甚而完成時還會有那種成就滿足感。最大最難吃的青蛙在每一天的一開始就先把它吃完了,那麼,這一天就再也沒有難得倒你的事情了,其它的只是小碎石,有多餘的時間去處理他當然不錯,即使沒有時間完成,卻也不是那麼重要了。

然而,GTD 方法論的確可以協助增進處理事情的效率。我很欣賞它其中的一些觀念,全面收集各類資訊;集中放置到一個待處理的工作匣內;快速針對每一個資訊,決定是否處理它;當要處理則放入下一步的行動 (next action)清單內。還有,我也很喜歡那個 情境 (context) 的表達,它讓你可以用邏輯 (logical)、比較鬆散性質的標籤 (tag)分類,快速地列出哪些工作,是在什麼樣的情境 (或場景)下要做的事情。 例如 @shopping,是要購物的工作;@blog,是在整理部落格相關性的工作;@business,是屬於業務上的工作 ...等。 不要繁瑣,只想要保留 GTD 的精髓,所以,崇尚簡約之道的 ZTD (Zen to Done),正是與我的期望及要求不謀而合!

要能兼容「目標管理」與「執行效率」的時間管理工具,那種要能符合心目中完美的那一面,看起來好像不容易找得到。 但請記得,人是要學會與應用工具,而不是被工具給束縛住你的想法。 "Remember the milk",是一個很簡單的免費線上工作管理 (task management)系統,但利用它,再搭配了心智圖做目標規劃,我幾乎已實現了符合我所要求的時間管理系統。關於我是如何規劃設定這套工具,來建構出符合上述期望功能的時間管理系統,就留待下一篇文章來作說明。

remember the milk - screenshot
(點小圖可看原圖)

※ 延伸參考
 o 兼容「目標管理」與「執行效率」的時間管理術—心得篇

副標題:運用物件導向思維與 UML 語法,來保存企業最重要的資產。

Business Patterns at Work
 Business Modeling With UML: Business Patterns at Work
 -----------------------------------
 作者/Hans-Erik Eriksson/Managus Penker /著
 出版社/Wiley
 ISBN/ 0471295515
 Amazon 評鑑:四顆星

內容簡介
Until now, the Unified Modeling Language (UML) has been primarily used to design software, but should you use it to model your entire business as well? That's the intriguing argument of Business Modeling with UML, a text that combines leading-edge enhancements to UML with some solid thinking about business. Written for any manager with some technical background, this book looks at the possibilities of UML used to model entire organizations.

The book makes a strong case for the advantages of modeling businesses in UML. With models, an organization can provide better software, define and implement new goals, and even decide whether to outsource certain operations. The Erickson-Penker Business Extensions for UML, invented by the authors and presented within the text, permit UML to document the entire business enterprise. This book shows how to model businesses, from business architecture to processes, business rules, and goals. Short case studies--for Web-centric and more traditional companies--are used to illustrate key concepts here.

Later sections of the book will perhaps take a little more background in software engineering to appreciate fully as the book presents a handful of business patterns, which offer reusable solutions to common problems (just like software patterns). The authors also look at how to leverage a business model to create better software.

In engineering, a new car is modeled and thoroughly tested on a computer before any physical prototype is ever built. As the authors point out, a business that has accurate models can test out new ideas cheaply and then adapt to changing market conditions quickly. This title makes a case that UML--a tool traditionally used by software developers--is ready to tackle the job. Read this notably informative and intelligent book to see the possible benefits of business modeling in UML for your organization. --Richard Dragan

Topics covered: Business modeling basics, UML notation and Erickson-Penker Business Extensions, class diagrams and powertypes, object diagrams, statecharts, activity diagrams and swimlanes, sequence and collaboration diagrams, collaboration and use case diagrams, component and deployment diagrams, stereotypes, business architectures, business processes, resources, goals, business rules, Object Constraint Language (OCL) and collections, business views and patterns, business goal allocation, business goal decomposition, business goal-problem, and software architectures

Review
"...excellent value for money." (Computer Bulletin, September 2000)

前言

一般軟體設計人員以為UML 塑模 (modeling) 的範圍僅限於軟體資訊系統,其實不然,我們也可以把企業當成是塑模的對象,利用物件導向的手法,有效地來保存企業重要的資產。企業塑模的意義就是在於將企業當成是一個系統 (system),把系統視為是一個整體 (whole),我們就可以區分外部的需求觀點與內部的結構觀點。確立了系統範圍的好處在於可以找出系統 (企業)的主要參與者 (primary actor)與支援性的參與者 (supporting actor),前者會需要企業來提供整體性的服務,而它也往往是企業主要的經濟來源與命脈;後者則是企業需要其它關係企業、或子公司的服務支援,以提升企業整體服務的能力。然後,我們再透過觀察內部的組成結構,找出共用性的部分,藉以來支撐外部的需求。企業內部包括靜態的結構元素,可能會有內部工作人員 (internal worker)、軟體資訊系統 (information system)、企業內部經常溝通的術語、概念、實體 (entity)等;還有以及觀察在動態行為期間,為了服務需求,這些元素是如何互動的合作,而構築成所謂的企業流程 (business process)—包括了供應鍊 (supply chain)與內部行政事務的流程等。

可以發現到,應用物件導向分析與設計 (OOAD)的思維與技巧,以及利用標準的 UML 語法與視覺化的圖形表達,簡單又易學、幾乎沒有學習曲線,就可以將企業與軟體資訊系統用一致性的分析手法很平順地互補與轉移,而且可以協助從各種不同的角度來看待組織與企業,不僅只看流程 (這是比較傳統的紀錄方式),還能找出企業核心的本質 (結構)。可以說,企業塑模的價值遠大於軟體資訊系統。除了瞭解企業的運作與規則,也可以知道哪些活動或製程需要資訊系統的支援,如此可以提昇企業的效率與整體競爭力,這也是 BPR (business process re-engineering),企業流程再造的範疇,同時又可以成為專案委外 (outsourcing) 規劃與管理重要的參考依據。

企業塑模真的很有趣,同時又可以擴展軟體人員的視野與格局,不會只是單純僅考量到實作技術面的議題而已。那麼,又如何能建立企業塑模的正知與正覺呢? 我是強烈建議研讀本次書評的主角,它除了說明了 business modeling 的真諦,還教導讀者如何保有多重的觀點 (multiple views)來看待系統,以及如何利用物件以及流程,表達出各個觀點之下的設計圖 (diagrams),不是只有涵蓋理論而已,是絕對可以應用在實務的開發。本書可以說是作者的經典代表作,也是 OMG 系列強力推薦的實用叢書。

從架構與觀點著手,才能掌握整體,瞭解企業塑模的精要

本書我是買精裝硬皮的,質感甚佳,也比一般書籍的 size 大了些,而且看起來好像很厚,約 450 頁左右,這也使得許多讀者望而卻步。但其實印刷的字體還算大,且有著大量豐富的設計圖。我是建議不要逐字細讀 (那太辛苦且沒效率,而且往往很難堅持從頭看完),要能觀其大略。例如我會一開始先研究一下本書的大綱,大概知道一下每一章節要表達的重點為何;在我的心中建構了整體觀之後,然後就會先翻閱到與整體比較有關的章節,然後再看重點標題,當然,基本上圖形大概就可以讓你瞭解到該節想要表達的意義為何。而若是不懂該設計圖的意涵,再去佐以看看那些文字敘述的解釋,大致上瀏覽、能瞭解其意就可以了。我是覺得,本書的編排非常好,讓我閱讀起來是真的很輕鬆。

本書共分為十一個章節。第1章開宗明義,解釋了企業塑模的意義與價值,以及為何是利用 UML 設計與規劃企業流程、企業規則等。第2章是對 UML 語法的簡單介紹,諸如靜態結構的類別圖,以及表達動態行為包括活動圖、狀態圖等,尤其是活動圖,這會是本書後續所常用的。第3章最重要了,它揭露出企業架構的塑模手法。本書最有價值的一張設計圖,正是由兩位作者所自創的語法構成的,由於長得很像火箭,我常把它戲稱為 火箭圖 (其實正確的學名為 Eriksson-Penker Business Extensions,也可以把它視為是活動圖的擴展),用來表達鉅觀的企業流程。而事實上,它也成為我在輔導比較大型 ERP 系統開發時所常用的流程設計圖。一般我經常看到系統分析人員常常把流程畫得很複雜,細細麻麻的長得好像電路圖。其實這就是因為比較沒有層次的觀念,來適時地封裝不必要的細節。火箭圖正是用來表達更高層級的流程活動,它甚至封裝了活動圖所表達的業務流程,只表達出火箭的輸入、輸出、參考與支援的資訊,更有價值的是,它還凸顯出流程處理完之後所能達成的目標 (goal)為何。火箭圖會應用在如 ERP 常講的業務循環,當訂購循環處理完之後 (訂購火箭),輸出會轉到如採購循環或出貨循環 (出貨火箭)等。然後當要觀察每一個火箭內部的作業時,只要打開它,再利用活動圖來瞭解其活動的細節。層次分明、簡單呈現,這正是塑模的精要 (essential)。

第4章則是提及了上述所講的企業觀點問題 (business views)。我這裡再次提醒讀者,記得當把企業當整體單一系統時,起碼保有兩種觀點—外部的需求觀點 (用的角度);內部的結構觀點 (靜態的結構元素關連與分類,動態的流程互動行為)。第五章則是提及如何利用 OCL (Object Constraint Language)來記錄企業規則 (business rule),這倒不是絕對的方法,我個人本身就不太願意被限制如何表達這些規則。6~8 章則是揭露出各種對企業的設計模式 (business patterns),包括了結構、流程、資源、規則與目標規劃等模式。我會建議不用先去看它,等到有身體力行,應用在實務遇到一些想法或問題時,再回來翻閱,會比較有感覺。第 10 章是討論如何從企業塑模轉移到軟體架構的設計階段。我是覺得,本章並沒有一個很明確的轉移規則,算是一種觀念的引導而已。如何從企業轉移到軟體塑模,在我所實際顧問的專案中,是已經釐出一些規則出來。簡單的說,無論什麼領域 (domain),只要能“想辦法”轉移到資訊系統的使用案例圖,那實作上就絕對不會是什麼問題了。最後第11章,是提供一個案例分析,從企業願景 (vision),到結構的結構、行為與流程等,這些設計是如何被產出,以及這些產出之間的關係又是為何。

企業的資產,是由領域與軟體專家們的合作所累積而成的

從企業塑模的層級可以得知,領域專家 (domain expert)是可以與軟體專家合作完成在企業面的設計。對領域專家而言,流程的設計與規劃,是屬於 "企業流程再造的範疇,而對於軟體專家,是可以把 "企業當系統" 來看待,然後利用 企業塑模 的技巧,來協助企業流程、規則等的設計與記錄,真正企業的資產,就是將領域專家們的智慧,經過“企業塑模”所粹取之後的產出(Artifacts)!! 而後參考企業塑模的產出,就可以很清楚地瞭解與規劃,哪一些企業流程的活動,是可以經由資訊系統的協助,來達成自動化或減輕工作人員的負擔。

Windows XP/Vista 32bit 的作業系統無法跑足 4GB 記憶體(只能認得 3.2GB )是已公認的事實。 本來還以為 Vista SP1 有支援,結果只是可以顯示你有多大容量的記憶體,但實際上仍是只能跑 3.2GB。 所以我的筆電插滿 4GB 記憶體(2GBx2),卻有約 768MB 給浪費掉;而去年七月底硬體升級的桌上型電腦,也只買了 3GB(1GBx3)的畸形規格,以免浪費。

看來要能解決的唯一辦法是升級到 64-bit 的作業系統,但是,目前的應用程式幾乎是 32-bit,升級上去,相容問題肯定多多。我的桌上型跑 Windows XP 是絕對不考慮的,因為我有很多 3D電玩;而我的 T61 筆電,卻又是無法向廠商取得正式授權的 64-bit 版本,詳見「與 IBM Lenovo 要求索取 Vista-64 bit OS for T61」。

沒想到日前閒逛一些硬體系統等討論串時(數位產品敗家資訊與硬體系統DIY,一直仍是我很有興趣的),看到這篇:[教學] Ramdisk 簡易按裝圖文教學與自動備份製作,以及這篇:[心得]有4G以上RAM的可以參考。 原來可以利用一套免費的 RamDisk 工具:Gavotte,它有個特異功能,可以吃 Windows XP/Vista 32bit OS 無法所使用到的 3.2GB 以上的記憶體,而成為 RamDisk。

哇! 這太棒了,馬上透過該討論串教學下載與安裝 Gavotte RamDisk 在我的 T61 筆電跑 Vista 32-bit SP1 環境下。 真的耶,完全沒有問題,RamDisk 跑足 768MB,是 Vista 所無法認得的那剩餘的 RAM 空間。 稍微注意一下的是,前提是主機板 BIOS 要能識別插在主機板的記憶體容量,目前 965晶片組以上的基本上應該都沒問題;再來就是要啟動作業系統的 PAE(Physical Address Extension) 功能。在 Vista 作業系統環境下,以管理員權限登入,在命列列模式下輸入:
 >BCDEDIT /SET PAE ForceEnable

即可。 效果真是好,效能馬上大幅提昇,因為我把 PageFile、系統環境變數、瀏覽器的暫存資料夾等都指向了 R 磁碟,也就是 RamDisk 預設的磁碟代號。

既然可以成功應用在我的筆電上,那麼想當然爾也能應用在我桌上型 Windows XP 的系統下了。 昨天中午迫不及待,過去「光華商場原價屋」,買了兩條金士頓 2GBx2 =4GB 的記憶體模組。有個小插曲,其實我並不想專程跑到「光華商場」的,想說能在中和附近購買是最好了,查看了 Y 拍,中和附近真的有家標榜是記憶體批發商的。看了價錢,一條2GB的報價約比光華貴上 $50~$100 左右,想說也還好,但是打電話過去想要親自去拿貨,竟然對方還說自取價每條還要再加上 $30! 這什麼跟什麼,自取價比網路報價還要貴? 這什麼生意邏輯呢? 還有他們應對態度也不太好,那個 "起檬子" 不爽,乾脆就開車直奔光華了。

我買的是品質最佳的金士頓 DDR2 2GB 模組,比起其它廠牌的,硬是貴上 $100~$300 左右,要價 NT$1300。 本來察看我原有的記憶體,也是金士頓的,1GB 單條,但是時脈是 667,所以是有些擔心屆時系統會不太穩定,不過那個「原價屋」女店員掛保證,若不穩七天內都可以無條件退款。想說誠意很夠,也就買回家囉。

DDR2800 金士頓 2G 記憶體模組

DDR2800 金士頓 2G 記憶體模組

DDR2800 金士頓 2G 記憶體模組

買回家後,主機板內的記憶體插槽一般只會有四個,所以我必須拿掉其中的一條1GB,然後把兩條2GB插入,所以一共是 6GB 的主記憶體。 系統重新開機,先進入 BIOS 設定畫面確定主機板是否真的有認識 6GB;然後進入 XP OS 後,可以下載免費的 CPUz 就可以再更進一步的確認了。 不過,透過系統的工作管理員或是 Everest 檢測工具,確實只能有 3.2GB 的記憶體空間可用,也就是說,我約有 2.8GB 的 RAM 空間全給浪費掉了。
我的桌上型電腦跑 6GB 記憶體

我的桌上型電腦—未安裝 RamDisk 前

再來就是安裝免費的 Gavotte RadmDisk 了。 記得可是要下載討論串的那個特別版,原因是它裡面有個 ram4g.reg 註冊檔,雙擊後就可以讓 RamDisk 認得 3.2GB 以上的記憶體空間; 還有記得就是要啟動 PAE 功能,在 Windows XP 系統下,是要編輯 C:Boot.ini,在開機選項內再加上 /PAE 參數。本來認為這是相當簡單的事,沒想到從下午弄到深夜,PAE 一直就是無法啟動,如何知道? 利用 Everest 系統檢測軟體,在 主機板→記憶體 最底下有個 PAE 資訊欄,察看是否那個作用中(active)是否為 Yes 就可以知道是否有啟動了。 察看國內外相關討論資訊,還是沒找到解答,弄到我真的快放棄了,想說可能我的主機板(GigaByte GA-965P-S3)沒有支援可以啟動 PAE。 結果那個也很愛玩系統設定的 Steve 傳了篇文章鏈址:Boot Parameters to Configure DEP and PAE。 嗯,就再試試看吧,後來我的 Boot.ini 內的參數是設成這樣:
 /noexecute=optout /fastdetect /pae

耶! 重開機後竟然可以了耶。 原因為何我也不知道,但是我看其他網友的設定是不需要這樣下參數,反正能跑就好了。設定好 RamDisk,看看 R 碟的容量吧,2.8GB 耶,完全吃到 3.2GB 以上的記憶體空間!! 然後透過 Everest 察看記憶體使用情形,也不會因設定了 RamDisk 而少掉了 3.2GB 以內的記憶體呢。可用空間扣掉拉哩拉渣的服務與常駐程式等,還有 2GB 可用呢。
我的桌上型電腦—RamDisk容量

我的桌上型電腦—安裝 RamDisk 後

所以,現在我的桌上型電腦跑 Windows XP,所有只要是有暫存的處理資料,都一股腦全給設定到了 RamDisk,包括解壓縮、燒錄、圖檔運算、系統環境變數、IE/Firefox 暫存Cache資料、PageFile ...等。 系統好像跟飛得一樣,硬碟燈也不會再一直閃了,爽度真是百分百。 D

對了,開關機時,那些原來暫存在 RamDisk 如 Cache 資料怎麼辦? 當然是會不見,若是想保存,那麼倒是可以參考此篇:自動儲存 RamDisk 的方法。 其實很簡單,就是在關與開機時跑批次程式,利用 Rar 壓縮/解壓縮程式 備份及搬移檔案來回於 RamDisk 與實體硬碟間。 當然,這會導致開關機會多耗上一些時間,大約 1GB 資料吧,大概多個 5~15 秒,這我是可以接受的,目前我也是有設這樣的批次檔來儲存環境變數與瀏覽器的 Cache 等,一切都蠻順利的,沒有問題的。

上個星期六開始,連著週六、日與本星期六(昨天)共三日,是對高雄某家大型醫院的資訊中心教授軟體設計課程,這已經是連續三個星期到高雄授課了,而其中兩個單位都是醫院,還真是巧。

透過兩個醫院的授課,才讓我瞭解到,原來醫療系統幾乎都是內部的資訊中心自行開發的,這與我原來想像系統大部分是委外開發的,大有不同,而據他們告訴我的原因,主要在於維護性的問題,所以無法全權委外,因為變動性的問題,委外單位不足以快速反應變更。

然後再更進一步瞭解,開發的系統範圍很廣,從典型的門診掛號系統、看診系統、藥劑管理系統,到甚至是人事系統,都需要自行開發。喔,這就是典型的醫療 ERP 系統啊。我常戲稱,什麼叫做 ERP(Enterprise Resource Planning) 系統呢? 不知道開發範圍的,就是 ERP 系統啦。

此次該單位找我授課的主要原因是,他們希望透過所謂的 OO 物件導向技術,來協助他們改善系統的難以維護。因為他們導入了 OOP,但是怎麼覺得用 OO 設計出來的元件,一方面很難開發,二方面好像沒有感受到 OO 的美好,好像系統也沒那麼有彈性,所以希望我透過教學,並檢視他們的開發成果,能給予他們一些建議。

原來上星期的授課,是與之協調後決定要講授 「UML 三劍客」的課程內容,那是以使用案例的需求為優先,然後快速導出到實作,是很有效的一種務實的作法。 不過上課了一天後,該單位包括較資深的技術長等資訊人員,問了很多現實他們遇到的問題,也拿出了部分的開發成果請我協助檢視。 我發現到,他們更在乎的是系統的共用性議題,當然還有關於物件的實作議題。 這些反而不是需求性的議題了,而是在於系統內部的結構性設計議題,以及實作面如 O-R Mapping 的系統設計問題了。

我對課程內容的態度是,一切都是彈性可以調整的,不會是一成不變,是可以視各單位現實的需求,動態甚至利用他們的案例當場馬上作分析並導出到實作。所以第三天的課程呢,我就給它調到了對結構分析這部分的重點來了,並且此次也請了我們另一位講師 Steve,協助來講授從領域模型轉到 .NET Coding 實作的部分。

嗯嗯,為 OO 而 OO,一向是我最反對的。我發現到,有太多所謂 OO 的開發,對於物件在中間層的實作,幾乎都僅在於對資料的存取。 所以設計出來所謂的企業物件(business object),根本就是資料物件(data object)而已,而為了資料存取,去設計與實作出這麼多的資料物件,實在沒啥意義的。 設計企業物件的重點是在於對於企業邏輯的處理,如何分門別類、然後把責任(企業規則)分派在適當的物件上,才是所謂物件導向的精髓。 這可是相當不容易耶,領域概念轉成軟體物件,要能抓得好,又要能適切地分派責任,再加上還要能轉成到現實平台上,包括 O-R Mapping 的設計議題,以及包括對 Performance 的資源控管等,這可是要結合領域專家、IT平台專家、與軟體專家的,缺一不可。

仔細分析,若絕大部分只是資料的存取,而且一般仍對企業規則到底要分派到那個物件上,其實沒那麼重視 (若是產品的開發,這個就很重要了);不過他們很渴望能將分散在 UI表單(script-based)與資料庫(stored-procedure)內的企業邏輯,給集中控管到中間層來,這是相當合理的,也可以說是許多傳統 Client-Server 2-tier 的軟體系統,來轉移(migrate)到所謂 3-tier,降低 UI 與 資料庫的耦合(coupling)性,是最必然的設計開發議題。 將企業邏輯集中在中間層是正確的作法,只是倒不是要絕對馬上就設計所謂的企業物件,那個難度真的相當高,可是要耗費掉相當多的開發成本的。

嗯嗯,有兩個字彙,倒是軟體人員也可以思考一下。 一為 Revolution;另一為 Evolution。前者我把它翻譯叫做 "革命",後者我是稱之為 "革新"。兩者哪裡不一樣? 革命是要抱著不成功便成仁的二分法;而革新是採漸進的作法,一次只改一點點,有了成效後再往前推進。 前者當然會比較快,但要相當有決心。只是,說真的,我幾年來看到的幾位是物件基本教義派的先烈們,似乎... 要求老闆給他們資源,來導入所謂的 OO 系統開發,但好像不幸都壯烈成仁了,專案毀了,人也跟著離開軟體業界了~

喔喔,聽了我的說法,他們好像不願意採取革命的作法,所以問我革新的作法如何作? 其實呢,並不難,為每一個需求的案例設計一個控制型(control)的物件,先讓其真的有實體三層的結構,把從 UI 與資料庫的企業邏輯給集中起來。 事實上,控制物件往往也具有 BPO(business process object)物件的性質,它可以針對某一個特定的需求功能,至資料庫撈出所需要的關連資料作處理;也可以具有 "wrapper" 物件的角色,可以呼叫原來就已經寫好放在資料庫的 stored-procedure,"ReUse" 原來就有的企業邏輯。 要光是能做到這一個階段,算是功德無量了,這起碼已經進展了一大步(從實體的 2-tier 到 3-tier),風險也不高。 下一階段待老闆真的相信(不要太期待老闆會看得遠,大部分是很現實,他們要能眼見為憑),且肯願意投入更多的資源,此時真的要去找出所謂 "共用" 超穩定的企業物件,或是要從原來寫在 stored-procedure 的企業邏輯,抽絲剝繭,這就是結構重整的範疇了,從程式碼的角度來看,好像就是最近很熱的重構(Re-Factoring)—不影響既有功能的前提下,對系統內部的結構元素作重整,使得系統更有彈性。

很多問題,其實根本不是問題,常常是因為局部雜亂無章、沒有整體性考量,才去衍生出來的問題。只有透視問題的本質,找出根本的原因,釐清對的方向後,再來就是審視現有的資源與環境,採取務實的作法,一次只解決一個問題,而不是把所有的問題來拿出想要一次解決,這比較有可能把事情做好。沒這麼困難、沒這麼困難的啦。

昨天,最後一天星期六的課程結束後,我還與那個 Steve 走到高雄火車站附近的「六合夜市」吃小吃。 其實夜市規模不大耶,甚至還比我們家中和附近的「興南夜市」還小一些、人潮還少一些呢。 我們先是吃了有家是店面的「台南擔仔麵」,客人很多,哇! 麵與小菜等真是相當好吃,在台北還沒吃過哪麼好吃的,只是麵量蠻少的,而價錢其實還有些小高。 還吃了那個什麼 蛋蛋魚,以前都沒聽說過,那個攤位還有與人手臂一樣粗的花枝,開玩笑,對於大的東西,我一向不敢吃。然後又買了烤蝦、菱角酥、新疆烤肉、酪梨牛乳等,拿到高鐵火車內享受。 只是,不好吃,那個烤蝦啊,看來是先用開水燙過,然後客人要點時烤一下作個樣子而已,很不實在。 回程從夜市坐計程車到左營高鐵站, Steve 說,怎麼每條路都比台北的忠孝東路還寬,人潮又很少。 喔,高雄真的地大人少,天氣又好,真是個居住的好地方。

※ 延伸參考:
 o 連著三天在三個單位的輔導與授課 (2008/04/15~17)

從使用案例圖中,可以明確地定義出系統的設計範圍—系統需提供哪些服務(每一個功能點服務即為使用案例)、誰會來使用系統、系統是否需要其它系統的支援。這對開發團隊的每一個成員,能具有整體性的共識,是相當有助益的。 再來就是決定優先開發的使用案例,通常那是對系統的利益關係人(stakeholder)而言,最有價值的,優先開發! 屬於企業服務層級的系統,屬於商業交易型的使用案例,通常是最具有價值的。 以「博X來訂購系統」為例,《訂購商品》與 《結帳商品》兩個使用案例,會是該系統最有價值的需求服務,參考如下圖1。

圖 1、找出價值最高的使用案例優先開發
圖 1、找出價值最高的使用案例優先開發

對於需求分析師(requirement analyst,RA)而言,為每一個使用案例來寫出使用案例的需求陳述(use case description)才是最重要的。 使用案例敘述要能寫得好的訣竅就在於,只專注描述參與者(actor)與系統的互動對話;也可以這麼說,當參與者(一般為使用者)在使用系統上線的期間(session),RA 要能觀察出參與者與系統會有幾次的訊息傳遞(message passing),然後將之寫成具散文格式的動作步驟,到完成最後一個步驟時,系統即能滿足參與者使用系統的目的。

下表是針對上圖1 的每一個橢圓型使用案例來寫作使用案例敘述。 使用案例敘述的格式並沒有標準,不過最主要的欄位是必然會有一個表達正常情節(scenario)的事件流程(flow of events),以及一到多個表達例外(exception)或擴展(extend)情節的處理陳述。

看起來好像有許多個使用案例敘述? 其實不然,這就是圖形的迷思,雖然 UML 規格是定義被《include》或《extend》的每一個橢圓也算是一個使用案例,不過當從參與者的角度來看時,上圖1非常明顯,只有兩個目的:《訂購商品》與《結帳商品》,所以其實 RA 只要寫出兩個完成的需求案例敘述即可。若是堅持要遵守從圖形中為每一個橢圓來寫需求敘述,如此可能會太分散而造成沒有一致性閱讀的感覺,不過這到不是絕對的,每一個團隊可以找出適合自己風格的寫作方式。 在此例我是以後者的方式來寫作的,原因是在於可以利用 UML 工具的文件產出(document generazation)功能來快速整理出符合客戶或公司所需的需求規格報表(requirement specification report)。

還有一點要留意的是,使用案例的敘述內不要詳細的去記錄如 欄位明細、查詢條件、企業規則(business rule) 等,參考下表,我會把這些經常會變動的細節中括號起來,然後會註明在另一份的文件,或是利用如 EA UML 工具,可以將這些細節整理在在該使用案例其它欄位內(如 constraint 欄位)。

訂購商品
Pre Condition
1.	使用者已登入 (Logon)系統。
Basic Course of Events
1.	使用者可以瀏覽各類商品資訊。
2.	Inclue <<放入購物車>>。
Alternatives and Exceptions

放入購物車
Pre Condition
Basic Course of Events
1.	使用者選擇一件商品放入購物車內。
2.	系統列出 [購物車明細]。
Alternatives and Exceptions
*取消購物車內商品
2a. 使用者可以取消購物車內的商品。
Require
[購物車明細]
商品明細、優惠價、數量、小計、庫存數、商品總額。

結帳商品
Pre Condition
Basic Course of Events
1.	Inclue <<選擇付款方式>>。
2.	extension point <<更新基本資料>>。
3.	系統列出本次 [訂購明細], [付款方式與寄送資訊]。
4.	使用者確認並送出訂購資訊。
Alternatives and Exceptions
Require
[訂購明細]
商品明細、優惠價、數量、小計、現貨庫存、訂購總額
[付款方式與寄送資訊]
付款方式、聯絡人、寄送資訊

選擇付款方式
Pre Condition
Basic Course of Events
1.	使用者可以選擇系統列出其中之一的付款方式。
2.	extension point: <<選擇付款方式>>。

選擇7-11門市 
Pre Condition
Basic Course of Events
1.	使用者輸入 [選擇7-11查詢條件]。
2.	系統請 統X EC 系統列出符合條件的 7-11 門市資訊。
3.	使用者選擇其一欲取貨的 7-11 門市。
4.	系統記錄使用者所選擇的 7-11 門市。
Alternatives and Exceptions
Require
[選擇7-11查詢條件]
查詢條件可以是以縣市、路名或門市名稱。
※ 延伸參考:
 o 三論「博X來」— 訂購商品與結帳是否是同一個使用案例?
 o 再論 博X來「選擇 7-11 門市」功能設計
 o 實在難以忍受的網路購書流程