【转】UML建模与Android应用程式开发(上)
前言
????就一个完整的软体系统而言，程式码只是系统(本体)的一个观点(View)而已，而模型(Model)也是系统(本体)的一个观点。当Android应用开发者来说，若既能从程式码看应用系统，又能从模型看它，就相当于人们都有两只眼睛来看前方的一切事物。一旦发现两者有不一致的情形，就表示两者可能有所失真(即远离本体)了。这样的讯息，可让开发者提前知道未来开发路子上，可能发生的错误，以便防患未然。同样地，在模型大观点里，也含有许多小观点，例如：
l 架构观点：一般采用UML 类别图(Class Diagram)
l 使用观点：一般采用UML 用例图(Use Case Diagram)
l 顺序观点：??一般采用UML 顺序图(Sequence Diagram)
l 状态观点：一般采用UML 状态图(Statechart Diagram)
?
????在本文里，将说明如何就上述的4个小观点，来构成模型大观点，然后再与程式码观点汇合，成为一个稳定可靠、简洁高雅的Andr??oid应用系统。然而，特别留意的是：模型观点与程式码观点两者不一定要有明确的先后顺序关系。两者之间，到底何者先，而何者后，并非重点。因为最好的状态是：在脑海里先两者并存，先领悟构思，然后才画出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?语言表达程式码的观点
????至今天
1312
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
