Software Cinema

不是正式的 Pattern Documentation, 只是隨手記記, 這種情況其實還蠻常遇到的. 但需要進一步討論的是, 如果我們說 Programming Languages 的選擇決定通常是在 Design Phase 末期或是 Implementation Phase 初期, 那麼這個情況是否 應該出現 呢 ? 而如果出現了, 是否下面的 能夠使用 呢 ?

Context

Used when components developed in different programming languages, which with low interoperability between each other, have to communicate and collaborate together.

Solution

Use a common infrastructure as a language-independent third party media, and develop a common protocol as communication standard.

The ProtocolAdapter is responsible for maintaining the Protocol, translating language-specific message into message under Protocol, and vice versa.


Example

An example using socket and TCP/IP network is illustrated bellow.


Consequences

• Increase the reuse of components implemented in different programming languages.
  
• The language-independent third party media usually contributes to constraints on usage of the applied application. Usability may be somewhat sacrificed.
  
• There will definitely be performance issues.
  

Associated Patterns

• Mediator Pattern
• Adapter Pattern
  

這篇 Short Paper [1] 以及所建立的 Tool ADORA, 包含重點大致可以歸納為兩點.

首先是使用 Fisheye View 的概念改進目前大部分 Tools 在協助使用者瀏覽整張 Software Design Diagram 時的問題. 既有的 Tool 在面對相當複雜且巨大的 Diagram 時大多無能為力, 往往需要使用者自行將 Design Diagram 從 Object Analysis ( 如果是在 OO Paradigm 中 ) 以後, 分為 Class Level 0, Class Level 1, ...... 等詳細程度不同的數張 Design Diagrams, 方便在不同的 Abstraction Level 間切換. 少部份 Tools 可以自動隱藏 Details, 但是當進行 Zoom In / Zoom Out 時卻是會對於整張圖作變化, 無法自由地只 Zoom In 想要進一步觀察的部份. Fisheye View 則讓此操作方式成為可能. ( 以下 ADORA 圖片皆取用自 [1] 並稍加編輯, 且無修改圖片本身內容 )


關於第一點在去年底我們實驗室有一位同仁在進行實驗室會議報告 Paper 時也有提到類似的概念, 當時他是用 StarCraft 當作例子, 在 StarCraft 中同時有主操作畫面 ( Local ), 以及左下方的微縮地圖全圖 ( Global ), 來說明如果 Design Tool 有類似的支援好像不錯. 當時大家討論都集中在使用方式上, 看了 [1] 的實做, 好像在 Layout 計算位置上也不是那麼容易實現, 畢竟要兼顧到整張圖的 Re-arrangement, 不能因為 Fisheye 使得整張圖亂掉. 我想這也是 [1] 裡面要強調可恢復性 (Stability) 的原因. ( 以下 StarCraft 插圖引用自 http://spyhunter007.com/game_over.htm )


第二是對於 Single Integrated Model 的理想. 在 Paper 尾段嘗試性的把不同時間點的一些 Diagrams 疊合在一起, 包含 User & Context, Use Case Diagram, 以及 Class Diagram. 可以想見的, 這樣一來就可以透過 ADORA, 在 Software Development Phases 之間快速自由的移動, 瀏覽相關的 Analysis Diagrams, Design Diagrams.


不過我認為 Single Integrated Model 的需求, 使用時機及模式, 以及呈現方式都還有很多探討的空間, 在本篇 Paper 中也沒有再著墨太多. 像是上圖左, Use Cases 跟 Classes / Components 混在一起的感覺就很奇怪, 也沒有因此曝露更多 Information. 如果改用 Use Case Map [2] 來作整理可能會好點. ( 話說 Use Case Map 是怎樣, 不紅到原本的介紹網頁都消失了, 現在只依附在 jUCMNav 底下了 XD )

或許之後在 Software Design Tools 中會出現更多這種 Visualization Information Mash-Up 的應用.


References

[1] T. Reinhard, S. Meier, R. Stoiber, C. Cramer, and M. Glinz, "Tool Support for the Navigation in Graphical Models," Proceedings of the International Conference on Software Engineering, pp.823-826, 2008
[2] R. J. A. Buhr and R. S. Casselman, Use Case Maps for Object-Oriented Systems, Prentice-Hall, 1995

在 Design Pattern [2] 書中對於 Observer Pattern 舉了一個 Graphical User Interface 上的例子作說明. 底層的 Application Data 可能會不斷地更新, 而 Presentation Objects 需要不斷地獲得最新的資料以便進行畫面的更新. 透過 Observer Pattern 設計, 可以處理在此問題下的 Data Object 與 Presentation Object 之間的 Coupling 問題, 同時能夠應付未來可能新增的 Observer Classes.

而 Pablo Iaría 以及 Ulises Chesini 整理的 Middle Observer Pattern [1] 則進一步考量了一個問題 : " 如果我想在這些 Presentation Objects 之間, 保持各個 Data Objects 被呈現時的 Colors 各自是一致的, 同時易於進行調整, 該如何設計 ? "

關於 Colors 的資訊, 與時常會被更新的 Data Objects 內容並不相同, 因此不適合放在 Observer 身上, 當 Observer Classes 數量多時會造成額外的 Data Redundancy 問題 ( 對於 Subject 來說也是會有同樣的問題 ), 同時不利於重新進行 Colors 調整. 如果由 Subject 透過特殊的 Interface 告知 Observers ( 或是提供 Observer 查詢 ), 則會造成兩者之間額外的 Coupling, 這也不是原本的 Observer Pattern 想要的. 利用兩個 Observer Pattern 的作法就更加不可能了.

這個問題可進一步延伸成為, " 如果 Data Objects 除了更新的資料需要被通知 Presentation Objects 之外, 還需要伴隨著其他的 Metadata, 那麼這些 Metadata 應該如何被管理 ? "

作者採用的解法是加上一個額外的 Object : Middle Observer.


Middle Observer 負責對於 Metadata 的管理以及提供 Concrete Observers 查詢 Metadata 的能力. 對於 Subject 來說, Middle Observer 的行為跟一般 Observer 相同, 而對於 Concrete Observer 來說, Middle Observer 提供了跟 Subject 一模一樣的介面. 唯一不同的是可以透過 setExtraState/getExtraState interface 去得到 Metadata 的資訊, 以及用來維持所有 Observers 之間的 Metadata Consistency.


在 [1] 中也說明了與此 Pattern 概念相關的其他 Design Patterns, 包含 Decorator, Proxy, Mediator, Singleton, 以及 Chain of Responsibility Patterns. 不過我覺得最關鍵的還是讓 Middle Observer 扮演雙面人的想法.

從上圖中其實看得出來 Middle Observer 也是做了他份外的事 : 幫忙 Delegate 來自於 Concrete Subjects 與 Concrete Objects 之間的溝通. 如果把 Middle Observer 獨立開來, 只做 Concrete Observers 之間的 Metadata Coordination 動作, 也是足以完成同樣的事情. 但是效果就會類似於使用兩個 Observer Patterns 作組合, 對於 Concrete Observers 來說要同時參與兩個 Observer Patterns 感覺是累了點 :p , 況且 Metadata 的更動其實並不頻繁. 因此讓 Middle Observer 扮演了雙面人, 則 Concrete Observers 就只需要參與一個 Observer Pattern 的運作即可.


References

[1] Pablo Iaría and Ulises Chesini, "Refining the Observer Pattern: The Middle Observer Pattern," Proceedings of Pattern Languages of Programs (PLoP), 1998, PDF file on PLoP

[2] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995

就在剛剛, 因為需要把某個 object (implemented in Python) 利用 Singleton Pattern 整理成為較正確的 design, 因此驚覺我不知道怎樣在 Python 中完成 Singleton Pattern ^^b

稍微試寫了一下都不太正確, 只好上 Google 找救兵, 結果找到幾個 solutions, 各有差異, 同時也有討論空間的, 就此紀錄一下. 以下的 1. 跟 3. 的名稱是我自己取的, 2. 則是提出者原本就賦予的名稱.

1. Singleton Manager

此種作法是以額外的一個 Singleton Manager 來管理該是 single instance 的 class instances, 在 ASPN 上有一個 example. 這種做法的結果是不同的 client code 會使用不同的 singleton manager object, 但是所有動作是利用 Delegation Pattern 由 Singleton Manager 傳給 class instance.

2. Borg Pattern

Borg Pattern (取名自 StarWar ?) 則是允許該是 single instance 的 class 可以有許多 instances, 但是各個 instances 共享一份 data. 換句話說, 可以看成是利用多個具有相同 behavior 的 object, 但是各個 object 的 state 一致來達成. 在 ASPN 上也可以找到一個 Borg Pattern 的 example.

嚴格來說 Borg Pattern 跟原本 Singleton Pattern 是有點不一樣, 雖然可以說 singleton 的目的是達成了, 但是以 Object-Orientation 的觀點來說, 在 Borg Pattern 內的 objects 彼此之間的 encapsulation 被破壞了, 同時 object identity 也不一致.

3. Inherited Singleton

由於上面的 Singleton Manager 做法在程式碼上來說我覺得不太直覺, 為什麼不能直接把目標 class 變成 singleton class, 而要透過一層 Singleton Manager 的介入 ? 而 Borg Pattern 的缺點上面也說了. 因此繼續往下找, 結果找到一個是 Inherited Singleton 這個 solution. 這是在 Python In A NutShell 書本裡的 example (初版, chapter 5.2.3.2) , 原始來源我就不知道了.

一個簡單的範例如下 :
<br /><br />class Singleton(object):<br /> _singletons = { }<br /> def __new__(cls, *args, **kwds):<br /> if not cls._singletons.has_key(cls):<br /> cls._singletons[cls] = object.__new__(cls)<br /> return cls._singletons[cls]<br /><br />class Target(Singleton):<br /><br /> def __init__(self, name=None):<br /> self.name = name<br /><br />s1 = Target('a')<br />print 'name of s1:', s1.name<br />s2 = Target()<br />print 'name of s2:', s2.name<br />print 'name of s1 after s2 created:', s1.name<br />print 'identity of s1:', id(s1)<br />print 'identity of s2:', id(s2)<br /><br />
如此一來所有繼承 Singleton 的 class 就自動會是 singleton class, 在 __new__ 不被 override 的情況下, 只會有一個 instance.

這樣的做法其實等同於把 1. 的 Singleton Manager 給 "embed" 到 Target class 裡面, 而看起來我們可以直接使用 Target class 作為 singleton class.

我最後當然是選擇 3. 啦, 感覺上比較容易維護.

昨天在註冊申請 Lijit 的服務時, 在過程中發現一個有意思的 Progress Indicator Pattern [1] 的實現例子. 在說明該例子前, 先簡單回顧一下 Progress Indicator Pattern, 在這裡我採用 Tidwell [1] 的整理.

在 Tidwell 書內主要利用 What, Use When, Why, 以及 How 來描述 UI Patterns 的 Metadata, 對於 Progress Indicator Patterns 而言 , 分別是 (我用中文摘要說明, 詳細內容可以參考 [1] ) :

• What : 當進行一個 time-consuming 的工作時, 讓使用者可以明確地認知目前的工作進度
• Use When : 當 User 在 UI 的操作上, 會因為此 time-consuming 的工作而中斷操作, 或是不影響操作, 但是需要把此工作的進度放在背景讓使用者可以監督時
• Why :
  
1. 在需要 software 進行較長 (使用者會明顯感覺被打擾) 時間運算的工作中, 如果使用者不知道目前的進度, 可能會因為不耐煩, 或是以為 software 不正常運作, 而出現無法預料的行為, 造成其他的錯誤操作
2. 根據實驗統計, 如果使用者能夠被告之進度, 即便進度內容不見得反應真實的情況, 使用者也會比較有耐心等待系統完成任務, 甚至認同系統目前正在 "思考"
• How :
  
1. 利用動態 (animated) 的指示元件 (Indicator) 來讓使用者知道目前的工作進度, 在指示元件的呈現上, 可以選擇使用文字語句型的 ( Verbally ), 或是圖形化的 (Graphically), 或是兩者合用也可, 一搬來說會呈現下面的資訊
• 目前在完成哪個工作
• 目前完成的進度百分比
• 預估還需要多少完成時間
• 是否可以停止此工作, 以及如何停止
  
2. 原則上不需要要求顯示進度與實際進度要達到非常精確的地步
   

一般常見就是 Windows 上的進度對話視窗 (Progress Dialog), 另外書本內也舉了 KDE bootsplash 畫面當例子.

而回頭來看看 Lijit 上的例子, 在填完申請之後, 會進入環境自動建構以及產生搜尋引擎的的過程, 這要花一點時間, 在這裡 Lijit 也應用了 Progress Indicator Pattern,


而 Lijit 的實現中比較特別的地方在於, 他的文字部分並非只是用取代的方式迭代, 而是會有淡出的效果 :

看上面從我的網址資訊變成 Create Search Engine :


另外 Lijit 的實現還有一個有趣的地方, 但是我沒辦法回到前幾個步驟去截圖. 在前幾個步驟, 當某個步驟特別長時, 他會出現不同的說法在描述同一個進度, 像是一開始可能跟你說他在進行 optimization, 然後可能會變成跟你說正在根據你的網站特性進行更好的 optimization 等等, 其實講的是同一件事, 只是他用的語氣偏向比較輕鬆的對話型語氣, 而不是制式的告知你進度, 這跟過往看到一般 software 的 progress indicator 文字部分有很大的差異.

從上述的兩點我不禁聯想到, 在 Design Pattern 與他的 Realization 之間, 究竟存在多少直到 implementation level 才會決定的點 ( Tuning Point ), 而足以影響此 Pattern 最後的結果好壞呢 ? 像是上面的淡出效果, 是不一定要這樣做的, 但是卻更加符合 Progress Indicator Pattern 的動態 ( animation) 要求, 而進度訊息文字的內容顯然也沒有規定應該怎麼寫, 但是如果在這部分填入了一些一般使用者無法看懂的專業術語, 是否就有違 Progress Indicator Pattern 在 Why 上面的要求呢 ? 反過來說, Lijit 的做法就比讓使用者看的懂還要來的更好.

是否我們可以針對各種 Design Patterns, 找出這些點, 變成使用該 Design Pattern 時的注意清單 ( Checklist ), 進而更加補足 Design Pattern 的 Metadata 呢 ?

References

[1] J. Tidwell, "Designing Interfaces : Patterns for Effective Interaction Design," O'Reilly, 2007

UNITED_BOTTLE 是在 2007 德國紅點設計獎 (International Red Dot Design Award) 的得獎作品之一. 其基本概念是認為產品設計應該考量到預設用途之後的其他用途 ( future design should think beyond the product ), 因此在塑膠水瓶的例子中, 對於水瓶的外部設計, 除了考量到容易拿取不滑落的需求外, 其實水瓶的形狀跟是否能夠裝水的主要功能 (functionality) 是關係不大的.

但是用過的水瓶事實上可以變成是一種一般的容器, 就向有的家庭會把好看的玻璃瓶拿來裝別的東西, 當作花瓶, 或是作為裝飾. 在這裡是考量到可以把用過的水瓶拿來裝沙土, 就有了類似沙磚的效果, 可以用來快速建造臨時性的房屋, 避難所, 甚至可以建造永久性建築, 過可能需要搭配其他的黏性固定材料.


在這樣的應用中, 關鍵在於怎樣的外型設計可以方便裝沙土的水瓶作為磚塊使用, 可以快速地堆疊, 以及搬運. 創作者是以固定數量的水瓶可以組成一個單位的角度來進行設計.

嚴格來說, 雖然水瓶的形狀跟功能性關係不大, 但是卻會跟 marketing 有關係, 因此這樣的想法是否會獲得廠商支持倒是很難說.

在進行 software design 時, 我們也往往需要考量 design for reuse, 然而, 在 software component 身上, 是否也找的到類似水瓶的形狀的特徵 (attributes), 是跟主要的功能關係不大, 但是可以直接被用來橫量此 component 的 reusability 的呢 ? 是否我們可以就此列出一張清單 (checklist), 當我們面對什麼樣的 software components 時, 只要檢查此清單上的項目, 就可以撰寫出一份此 component 的 design for reuse 文件呢 ?

UMLSpeed 是一個 light weight 的 UML edition 以及 layout tool, 以 text-based 方式撰寫 UML-based design, 同時 UMLSpeed 則幫忙產生 SVG UML graphical layout, 以及支援轉換成 XMI 輸出, 或是其他 programming language 的 code generation.

UMLSpeed 作者之所以開發的理由包含 : (引用修改自 UMLSpeed 網頁)

1. Graphical UML tools in general suck - why should we, as programmers have to drag and drop stupid graphical things and use a mouse when we could express what we want 10 times faster with a text editor and a simple notation?
2. A declarative approach is closer to the mental model used by developers when designing systems.
3. Why should we layout diagram components when the computer could do it for us?
4. Graphical UML tools are bloated, huge, memory and disk-hogging monsters.
5. Graphical UML tools use either a binary data format or XML, which is not particularly friendly to source code control systems.
   

基本上我同意第 2, 3, 4 點, 但是對於 1, 5 則不完全同意.

以第 3 點來說, 雖然說 layout 不可能完全由 computer 取代, 身為吹毛求疵的 designer, 就算 tool 能夠自動幫我做 layout, 八成還是會對結果動手動腳的. 但是基本上 layout 結果的好壞是可以用一些 graph complexity metrics 去評量好壞的, 因此自動產生的結果是可以趨近 designer 會感到滿意的結果, 因而還是可以省下不少功夫, 更別說可以根據 designer 的喜好產生專用的 layout style. 第 4 點的問題應該常用許多 IDE 的 designer 都有相同的感覺吧, 有時候想要功能比較強, visualization 比較好看的 IDE, 卻會有需要大量 resource 的問題. 而 light weight 的 tool 往往功能上就比較被侷限住. 不過這基本上是個很難兩全其美的問題. 唯一的 solution 可能是能夠有一個 easy-customizable 的 IDE, 使得在不同的 environment 下可以很容易作 customization, 得到最需要的功能就好. (不過至今沒有這樣的 IDE 出現, 連 Eclipse 也還做不到)

同樣地對於第 1 點來說, grphical editor 在 visualization 上有他的優勢在, 我相信 graphical software design 只是還沒有突破性的發展, 但是 visualization 在 software design 上至少可以同時結合 design layout 與 design document (design code) 之間的 traceability, 但是像 UMLSpeed 這樣的 tool 就沒有支援這樣的 traceability, 只是因為 UMLSpeed 功能不強大, 所以這樣的缺點也就沒有被放大. 第 5 點也是見仁見智的問題, 採用 XML-based solution 是為了標準化以及延伸性考量, 如果不考慮此點當然可以批評採用 XML 的做法. 但是相對來說, 採用自家標準的 tools 往往容易被淘汰, 至少我就不太會想用, 因為 data 無法被不同的 tools 共用, 換句話說無法被長久保存, 這是很困擾的事情. 要是 UMLSpeed 沒有支援 SVG 或是 XMI 輸出, 我大概也不會想用了.

UMLSpeed 的使用是以 C-style 的 text-based code "programming" 展開, 看圖就很清楚了, (下圖取用自 UMLSpeed 網站 )


而輸出是以 SVG 格式的檔案輸出, 另外支援 XMI UML 文件輸出. 另外從網站上看來, UMLSpeed 目前支援 use case diagram, class diagram, sequential diagram, 以及 deployment diagram.

基於 UMLSpeed 的特性, 我認為有幾個不錯的額外用途 :

1. Software project 階段性的 design review, code review : 在 software project 進行過程中, 偶爾會需要進行 design review 或是 code review. 這通常是由於 design 或是 source code 已經有點混亂, 因此該部分的 leader 會召開會議, 把所有負責各部分的 designer / programmer 集合起來, 針對整個 design / source code 作 review, 確認每個部分的用途, 以及解決方法是否足夠好. 由於會議人數眾多, 同時進行會議中可無法容忍慢吞吞的大型 IDE, 或是時不時出現的 IDE 怪問題. 因此像是 UMLSpeed 這樣能夠快速進行 pure text-based modification 以及自動 layout 的 tool 應該適合使用. 但是要達成此點, UMLSpeed 跟其他 project 會用到的主流 IDE 之間的 data consistency 問題可能需要被解決.


2. Design on mobile devices : 可能會想要這樣功能的人很少, 但是我就是其中之一 :p . 在 mobile devices 上, 或是如最近的 ASUS EeePC 上要跑平常的 IDE 幾乎是不可能的(很辛苦), 但是畢竟我想要的只是在等人或是喝個咖啡時, 可以思索一下最近手上計畫的 software architecture 的一小部分 design 而已, 一個 light weight, 可以馬上產生圖的 tool 就足夠使用了. 這些需求 UMLSpeed 看起來通通符合 :)


3. UML programming on Wiki, Blog System : 我們實驗室使用的是 MoinMoin Wiki System, 偶爾會想在 Wiki 上畫個 UML 圖形來說明. 在 MoinMoin 上已經有類似的 plug-ins, 使用上跟 UMLSpeed 有點像, 只需要撰寫特定格式的 UML code, 就可以在頁面上被轉換成為 UML graph. UMLSpeed 應該可以提供在 Wiki 或是 Blog System 上的類似支援

另外 UMLSpeed 支援 SVG 輸出這點也使得他可以跟一些支援 SVG 的繪圖軟體合作使用. 例如我依賴的 Inkscape, 這樣要修改 UMLSpeed 的輸出結果, 用在準備 slides 或是 reports 也很容易. 小 tool 果然是 flexibility 高許多 :)

About a month ago, I found that several refactoring patterns are expressed with thumbnails [1]. The following figure is Evolving to the Strategy Pattern thumbnail, expressed by several refactoring thumbnails, referred from [1].


And yesterday, when I was checking the differences between JUnit 3.x and JUnit 4.x, I found it again in the document of JUnit 4.x [2] release. The following figure is referred from JUnit 4.x document.


This figure contains rich information, and clearly shows the global picture of how and the order design patterns were composed in the design of JUnit 4.x, without revealing the details.

I myself usually do the similar thing when sketching the initial design idea, however there is no patterns or fixed forms of my sketch. The lack of regulation in the sketches makes the design granularity and leveling hard to control.

It would be wonderful if there exists a design tool that can hold the design granularity and leveling control for me...maybe by the design thumbnailing support ?

References
[1] Refactoring Thumbnails, URL : http://refactoring.be/thumbnails.html
[2] JUnit, URL : http://www.junit.org/