UML建模Android应用程式开发.docVIP

【转】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?语言表达程式码的观点 ????至今天，