How "UML" looks at the UML diagram of Android

    There are many types of UML diagrams, only two of the most important and common-class and time series diagrams are discussed here. 1. Class Diagram

through the class diagram, we can easily understand the code architecture, clarify the relationship between the modules,

includes inheritance (inheritance), implementation (realization), dependency (dependency), composition (composition), Aggregation (Aggregation), Association (association), and so on.

The following is an explanation of the 7 kinds of relationship one by one given in the figure.

    1.1 Composition

Compostion is a association relationship, but it emphasizes the overall and local relationships between the two classes , implying that there is a same life cycle between the two classes,

For example, three in the figure 1.

•   W is one of the member variables of Viewrootimpl, W is also constructed in the constructor of the Viewrootimpl object, so when the Viewrootimpl is destroyed, W is also deconstructed, and their life cycle is consistent.

   public  final  class  viewrootimpl  Viewparent, View.AttachInfo.Callbacks, hardwarerenderer.hardwaredrawcallbacks {...  final    W Mwindow; ... mwindow  = new  W (this ); //  Refer to each other, so when one is destroyed, the other cannot exist.   

  view code
• Similar relationships exist between Windowmanagerservice and Windwostate.

1.2 Realization

Realization is implementation, embodied in Java as implements an interface class interface, there is no explicit interface concept in standard C + +, but abstract classes actually play a function similar to interfaces, because C + + The realization can be embodied as inheriting an abstract class. In the C + + code of Android, there is a special abstract class IInterface, which defines some basic methods of the PC interface class.

1.3 Association

There is a reference to the interface, and in UML one of the most common one-way arrows is the Reference (association) relationship. What it means is that an object uses an interface or property of another object . Typically, Assocation is obtained in two ways

•   dependency injection, through constructors or setxxx () interfaces, such as WindowState gets a reference to the Iwindow object by constructing the arguments passed in

   windowstate (Windowmanagerservice Service, Session S, Iwindow C, Windowtoken token, WindowState Attachedwindow,  int  Appop,  seq, Windowmanager.layoutparams A,  int  viewvisibility, final  displaycontent displaycontent) 

  view code
• Indirect fetch, returned by calling other object methods.

  Mactivitymanager = Activitymanagernative.getdefault ();

  View Code  

1.4 Android's IPC interface.

both C + + and Java interfaces support only in-process calls. To support the interface calls that are specifically used across processes, Android has made a few rules.

All interface classes defined in IXXXX can support IPC(of course, the interface defined by Ixxxx can also be invoked within the process).

When we see a ixxx interface class in the diagram, we can assume that this is a process boundary, and that his implementation and caller objects run in different processes (at least different threads).

in the case of Iwindow, the W object and the WindowState object have different colors to indicate that they belong to different processes, W runs in the application process, and winstate exists with the system Server process.

1.5 Aggregation

aggregations express the dependencies of two classes, but unlike composition, their lifecycles are different.

A classic example is the factory and the car, the factory built, the factory closed, the car can continue to open, and vice versa.

Policymanager and Phonewindow are similar relationships in the diagram.

1.6 Inherritance

is the most common inheritance relationship.

complex inheritance relationships are difficult to read and memorize, and it is much easier to use UML diagrams, and you can clearly see the inheritance relationship and understand the design ideas of inheritance.

For example, in the upper right corner of the diagram, Phonewindow inherits the window class, and Activity refers to its base class window object, but the real director behind it is the Phonewindow object, because Acitivy The window class object used is constructed by Policymanager. In this way, the implementation details of the Phonewindow are hidden by the Policymanager and Window base classes, which greatly reduces the chance of the application (Activity) changes.

This is one of the most famous factory models in design mode.

1.7 Dependence

dependencies are different from references, and dependencies do not have direct object references between them, usually the use of constants or static methods.

The activity uses the static method of the Policymanager class Makenewwindow () to create the Phonewindow object, which we say Acitivy relies on Policymanager this module, But it does not refer to Poclicymanager objects.

dependencies are usually represented by a one-way dashed arrow.

2. Timing Diagram

with time series diagrams, we can understand the invocation process of the code and examine potential problems that may be produced during the invocation, such as deadlocks.

The sequence diagram can be viewed in two directions, portrait and landscape.

portrait describes what an object does on the timeline, a block that represents a call to a function.

Landscape describes the invocation relationships between objects, including synchronous calls, asynchronous calls, returns, and so on.

In addition, in the time series diagram, we can assign different colors to the execution block, which means that they are running in different processes or threads, respectively.

Here is an example of a time series diagram that describes the process of launching a system server process in Android, and the pink note in the figure lists some of the information that we can learn.

    didn't I just say that we can see the deadlock from the sequence diagram? Is that the same picture? It's exaggerated! Yes, let's take a look at the following example!  

This is a very simple example, there are two threads in the diagram, Green is the app thread, it controls the player by calling the function of the MediaPlayer object, here it does two things, Start () and then Stop (). The pink part represents the driver thread, which informs the MediaPlayer about the underlying event through a callback function. This means that MediaPlayer is an object that is referenced by two threads at the same time and is a shared resource.

take it for granted, we used a lock to protect it, preventing him from being used at the same time to create a conflict. So, in the picture, the Green app first gets the lock when stop (). At this point, the Stop () process may be longer, midway through an event, the yellow note on the right side of the picture shows the situation, two colors of the bars overlap. This indicates that there is a resource conflict and also implies a potential deadlock risk. We assume that the ultimate goal of stop () is to deconstruct the Videodecoder object, but at this point, the EventHandler () of the Videodecoder call is not returned in another thread, and we naturally need to wait for it. Unfortunately, this time the deadlock has occurred, as shown in the red note.

by simply drawing such a diagram, it is easy to analyze a deadlock situation. How to solve it, you can avoid the picture of the different colors of the ribbon overlap. Take a look at the following solutions

    this time, we canceled the lock operation by adding a new thread (into 3 threads, 3 colors) thread, making the synchronous call asynchronous, and leaving the thread to do the background processing.     so there is no longer any overlapping of color blocks in the graph (the overlap generated by asynchronous calls is not counted), and both Stop () and EventHandler return (asynchronously), eliminating the existence of deadlocks.     This is why andriod designed asynchronous message processing mechanisms for Looper, MessageQueue and Handler, and is used extensively in the framework, because Android is an extremely complex multi-threaded/multi-process application environment, Locking-based synchronous invocation mechanism is difficult to ensure that the occurrence of deadlock is completely avoided.

That's OK, time series diagram is very helpful for analyzing the programming analysis of multithreading. We should use class diagrams and time series diagrams as much as possible in the design phase to help us avoid some common problems and help us draw a design that is as good as possible.

3. How do I draw an Android UML diagram?

Tools! Have to rely on tools, there are too many UML tools on the market, you just need to find a reverse engineering, the code is converted into UML data structure, and then the class diagram or time series diagram step-by-step drawing out.

Reference articles    Http://www.cnblogs.com/samchen2009/p/3315999.html

UML How to see UML diagrams for Android