jim yeh on 八月 7th, 2008

除了軟體功能之外,開發者還必須兼顧性能的設計,其中當然包括兼顧操作的人性化需求外,還必須思考如何減少因為設計不良而造成操作錯誤的機會。

Continue reading about 可用性與可靠性的設計考量

     
jim yeh on 七月 10th, 2008

許多採用使用案例建模方法進行需求分析的開發者,對於不需要使用者介入的系統自動作業,通常會用工作排程者來當成使用案例的主要參與者。讓系統工作排程來啟動使用案例以與系統互動,這對系統開發者而言,可以讓他們了解系統應該如何與外界互動以完成系統所提供的功能,這樣看起來是可行的需求塑模手法。 不過,工作排程者牽涉到系統設計的觀點,如果我們不想讓需求相依於系統設計,那麼我們就必須將工作排程者變成更共通而抽象化的概念。工作排程者的抽象化概念是什麼呢?我們不難理解,工作排程者也只不過是實現時間概念的具體設計。因此,照理時間才是系統自動作業的主要參與者。 然而,當我們把時間當成系統自動作業的主要參與者時,我們會遭遇到另一個問題。那就是基於黑箱的角度來看系統,使用案例應該是以使用者或外部系統來看系統,瞭解如何系統與互動而達到特定目的或產生價值。很顯然地,系統自動作業並沒有辦法為「時間」達到任何的目的或創造價值。 換句話說,我們並未找到系統自動作業的真正使用者,即使我們把工作排程者當成使用者,以使用系統的組織觀點來看,我們將會無法了解系統自動作業和組織目標的達成有何關係,而遺漏了相當重要的使用案例觀點(use case view)。

Continue reading about 系統自動作業的主要參與者

     
jim yeh on 六月 30th, 2008

在現實世界中,通常很難找到不僅懂得軟體開發的技能,又同時具備問題領域知識的人才。而且軟體開發專案本身存在時程與成本等限制,多半不允許系統分析師花太多的時間與成本學習問題領域知識。因此,要期待系統分析師學習問題領域知識是不切實際且又不符合經濟效益的做法。 系統分析師要如何展現出系統分析的專業,才能整合問題領域與解決方案領域的知識,有效地提出具體可行的問題解決方案?

Continue reading about 展現系統分析專業的七種能力

     
jim yeh on 一月 18th, 2008

我們必須為應用服務設計減震點來緩衝需求變動所帶來的衝擊,並且讓應用服務可以很有彈性地被重組,使得應用服務的開發變得更有效率。而且這個減震點必須可以支援跨系統甚至是跨平台或程式語言的需求,因為這樣才能不會受限於不同的技術領域,而達到完全地整合各種異質性系統的目的。

Continue reading about 應用服務的減震點

     
jim yeh on 一月 11th, 2008

記得在前一陣子,同人曾與 Joy 討論過有關如何表達觀點的話題。他提到在 funP 大量閱讀後,常常會去思考如何用更恰當的方式來表達觀點。而某一天,我突然領略到觀點的組織其實就是將想法概念化的抽象思考過程,而這個的觀念正好可以做為如何恰當地表達觀點的一個思考方向。

Continue reading about 觀點表達的概念抽象化

     
jim yeh on 十二月 5th, 2007

這樣一來,在遠端呼叫的情況下,設計與實作就很難分離了。因為呼叫端的程式必須知道 RPC 的呼叫方式,它相依了 RPC 的實作細節。不同 RPC 的技術實作,會讓呼叫端必須更改呼叫的程式碼,因而產生了沒有必要的複雜度。

Continue reading about 跨越遠端界面呼叫的藩離

     
jim yeh on 十一月 12th, 2007

本文係投稿於 CNet / ZDNet Taiwan 的初稿,並分為上下兩篇文章刊出,未經 ZDNet Taiwan 編輯,其內容可能會略有差異。 如眾所週知的,軟體開發專案具有高度不確定的特質。因此,為了降低需求變動的風險,在專案初期,軟體開發者往往會花費許多的心思,設計出具有彈性的軟體架構以適應未來可能的需求變化。大部分的開發者都了解軟體需求是不可能不改變的,但他們希望不管軟體需求如何變化,軟體開發的設計概念都不會因此受到影響或改變,如果可以做到這一點,軟體開發就會變得比較有效率,同時也能確保所開發之軟體的品質。 然而,現實總是和理想存在著一些落差的,專案的演變往往會超乎開發者事先的預期。尤其是當專案的驗收日期愈來愈接近時,專案可運用的資源也會愈來愈少,專案或許已不如剛開始時充滿了未知與不確定性,但相對地,專案的可變動性也愈來愈小。因此,在專案後期出現專案問題,或是需求的變動,相較於相同專案問題或需求變動在專案初期出現而言,會顯露出更為嚴重的危機與壓力的。 每個人都希望寧願事前多做一些風險管理,勝過事後的危機處理,而且後者的壓力是很容易讓做錯事的。然而,軟體易變的特質及專案環境的不確定性讓人難以捉摸,更不用說預測變化了,卻只能在事後才徒然留下「千金難買早知道,萬金難買後悔藥」的感嘆。但問題還是要解決的,到底軟體開發者在遇到這種危機時該如何處理呢?

Continue reading about 軟體開發者不應該自廢武功!!

     
jim yeh on 九月 26th, 2007

上次提到用服務層的概念整合業務流程與功能性交易,並指出因應交易流程整合的非同步呼叫考量的兩種技術實作方式,也就是 database sharing 與 message queue 的不同做法。兩種做法會殊途同歸,最後會依據處理狀態,呼叫後端的服務進行後續系統作業。 既然兩種做法會殊途同歸,那麼在設計上,可不可以設計出同時適用不同實作方法的非同步機制呢?依據這樣的設計思路,我們會希望把會變動的部分用界面封裝起來,如下圖所示。 在上圖的設計中,我們定義了一個 ServiceEvent,用以記錄交易識別碼、交易階段代碼及流程代碼等資訊,其中流程代碼的目的可提供系統進行更精細的控制,而交易識別碼及交易階段代碼則是用以取得交易目前處理狀態以讓系統繼續處理交易的後續動作。 ServiceEvent 由 EventAdvice 產生,並由 EventListener 讀取,而傳送及接收 ServiceEvent 的任務則交由實作 EventSender 及 EventReader 的類別來處理,如此便可達到不會因為不同的實作方式而更動到設計。

Continue reading about 流程與交易的整合(其二)

     
jim yeh on 九月 21st, 2007

「SOA 不只是技術」,是我們常聽到的一句話;然而,SOA 是否與技術無關呢?近日同人看到在 InfoQ 中文站有一篇文章,主題是〈SOA重在技术还是业务?〉,提到了網路上對此議題的相關討論,並表達了該篇文章的看法。 該篇文章引用《An Architectural look at SOA》中的一張圖(如下圖)來說明架構的技術觀點,並認為 SOA 畢竟是一種架構風格,與任何架構性工作一樣,架構者必須先想清楚架構性目標為何,並在作出技術上的選擇後,必須回頭重新審視架構上的決策。在技術、平台等全部到位之後,總有它們自身的一套架構、功能和限制。 該篇文章的結論是,技術是重要的,因為不管是 SOA 或任何專案的設計中,都不可能忽視技術。但對技術的定位而言,該篇文章卻認為,技術應該放在第二位,業務才是第一位的,對此,該篇文章留下了讓讀者思考的空間。

Continue reading about 技術在 SOA 是次要的嗎?

     
jim yeh on 八月 15th, 2007

在 OO 社群中,由人稱 GoF 所著的《design Patterns: Elements of Reusable Object-Oriented Software》[1]被認為是物件導向軟體設計的重要典範,但最近在 InfoQ中文站,有一篇文章的主題是 〈InfoQ: “四人帮”的设计模式经得起时间的考验么?〉,提到這本書最近被人質疑已經與時代的發展脫節,書中解決問題的方式已經可以由新的語言來做更好的處理,用書中的設計樣式[2]來解決設計問題還會增加不必要的複雜度。 這篇文章提到對設計樣式的反面意見主要包括了設計樣式是一種複雜性的表現形式、對設計樣式的樣板式代碼(boilerplate code)的需要,代表在設計思路上的問題,也就是開發者所使用的語言基礎結構出現問題的信號、以及設計樣式阻礙了《A Pattern Language – Towns, Buildings, Construction》這本建築架構思想的傳播,本書是被公認是激發了資訊科學領域內的設計樣式運動。 附註  中文版為由葉秉哲譯(2001),《物件導向設計模式》,美商普林帝斯霍爾國際出版。[↩]有關 design pattern 一詞,中文有兩種翻譯方式,設計模式與設計樣式,同人習慣用「設計樣式」來稱呼之。[↩]

Continue reading about 設計樣式已成明日黃花?