前言
就一個完整的軟體系統而言，程式碼只是系統(本體)的一個觀點(View)而已，而模型(Model)也是系統(本體)的一個觀點。當Android應用開發者來說，若既能從程式碼看應用系統，又能從模型看它，就相當於人們都有兩隻眼睛來看前方的一切事物。一旦發現兩者有不一致的情形，就表示兩者可能有所失真(即遠離本體)了。這樣的訊息，可讓開發者提前知道未來開發路子上，可能發生的錯誤，以便防患未然。同樣地，在模型大觀點裡，也含有許多小觀點，例如：
l 架構觀點：一般採用UML 類別圖(Class Diagram)
l 使用觀點：一般採用UML 用例圖(Use Case Diagram)
l 順序觀點：一般採用UML 順序圖(Sequence Diagram)
l 狀態觀點：一般採用UML 狀態圖(Statechart Diagram)
在本文裡，將說明如何就上述的4個小觀點，來構成模型大觀點，然後再與程式碼觀點匯合，成為一個穩定可靠、簡潔高雅的Android應用系統。然而，特別留意的是：模型觀點與程式碼觀點兩者不一定要有明確的先後順序關係。兩者之間，到底何者先，而何者後，並非重點。因為最好的狀態是：在腦海裡先兩者並存，先領悟構思，然後才畫出UML模型圖，也寫出程式碼，但都不一定是完美的。隨著兩個觀點的對比，發現不一致現象，就像兩隻眼睛發現前方物體的呈像不一致時，兩者自然而然會逐漸修正(Iterative & Incremental)，止於至善。
本文範例
本文舉一個簡單範例：一個Activity的子類別，以及一個遠程的(Remote)的Service 子類別。兩者透過 Android的IPC機制相互溝通。
多種UML類別圖呈現各種架構觀點
所有的模型圖都是人們對某項事物本體認知的心智觀點，隨著觀點和抽象的角度之不同而改變其所呈現之面貌。例如，當我們覺得Android框架裡的基類(即抽象類)是最重要的，只要呈現它即可，此時類別圖就呈現如下：
圖1 獨尊Android框架的類別圖
如果覺得應用子類別也是架構裡的重要元素，需要與框架裡的基類別一起呈現出來，則此時類別圖就呈現如下：
圖2 兼具框架與應用的類別圖
當然也有許多人習慣於獨尊應用子類別，而認為不需要呈現幕後的框架基類別，則此時類別圖就呈現如下：
圖3 獨尊應用子類別的類別圖
此外，還有人習慣於獨尊介面(即接口)，而對幕後實作類別視而不見，則此時類別圖就呈現如下：
圖4 強調介面(即接口)的類別圖
以上都只強調架構裡的元素(如類別和介面)，還有人認為這些元素之間的互動(Interaction)與合作(Collaboration)是非常重要的，需要表現出來，此時類別圖就呈現如下：
圖5 強調互動的類別圖
UML用例圖呈現使用觀點
類別圖是基於架構師的觀點，偏向系統的內觀(Internal View)。至於用例圖(Use Case Diagram)則是基於使用者(即用戶)的觀點，偏向系統的外觀(External View)。許多人堅持需求至上(Requirement-based)的開發者，非常重視這項UML圖，終究用戶是買家，就行銷的角度來看，用戶觀點當然非常重要囉。例如，針對上述範例的UML用例圖呈現如下：
圖6 強調用戶觀點的UML用例圖
UML順序圖呈現各項活動發生順序
如何去實現上述的用例呢? 為了實現上述的用例，系統必須執行一連串的活動(Action)。有人認為這些用例幕後的活動執行順序是很重要的，就使用UML順序圖來表達之，例如，針對用例「Run」可繪製其幕後活動的執行順序，如下述的UML順序圖：
Use Case: Run
圖7 Run用例幕後的活動順序圖
再如，針對用例「Exit」可繪製其幕後活動的執行順序，如下述的UML順序圖：
Use Case: Exit
圖8 Exit用例幕後的活動順序圖
UML狀態圖呈現UI畫面的千變萬化
由於 Android是屬於事件驅動(Event-Driven)的平台系統，有許多人主張善用UML狀態圖可對眾多事件分而治之，於是在清晰的狀態之下，會執行明確的活動。例如，下述的畫面可接受來自Android和用戶所引發的事件。
此時，可以採用UML狀態圖呈現UI變化之觀點，如下圖：
圖 9 呈現UI畫面狀態變化的UML狀態圖
以Java語言表達程式碼的觀點
至今天，還是有許多人維持傳統的觀點：
l 畫UML模型圖在先，撰寫程式碼在後。
l 程式碼是UML模型的實踐。
l UML模型較為抽象，程式碼較為具體。
這項傳統觀點並沒有對與錯。但是，近年來，愈來愈多的人們持著新的觀點：
l UML模型圖與Java程式碼是兩個同位階的觀點。
l 兩個觀點的一致性是確保系統穩定可靠、簡潔高雅的重要途徑。
l 傑出的Android開發者應該兼具兩個觀點。
扫一扫
1144
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
