Constructing Class Diagram for Android applications

Question

I have about 30 classes resides in 7 packages in my android application:

I want to make a class diagram and CRC ( class responsibility collaboration) cards for it. But I get confused because the class diagram will be a large and complicated diagram. According to this Answer form a previous question. I had to make a class diagram for the main classes like Fragment and services etc.

If anyone can give me advice about that. Also, I need to implement the layers of architecture ( Presentation layer, business layer , and data access layer ) according this:

But I don't know where to start since i am using a php service. Any tips ?

Answer 1

UML is a language for expressing your thoughts and concepts, so there is no fixed rule what to describe, what to leave out, and how to arrange everything.

If you want to describe your implementation in detail, you will in some way need to include all these 30 classes (which is not so terribly much). But there are ways to make readable class diagrams even from large class models, using the following ideas. Most tools allow you, from one abstract class model, to derive several diagrams that will always be kept in sync with the class model, so they'll always be consistent. What I like to have is

• one overview diagram, containing only the packages, the classes and relations between them without any details,

• diagrams of parts of the model, e.g. of just one package, showing the details like attributes, data types, and operations.

The overview diagram is a good place to show your layers. In your layer picture, I'm a bit puzzled about the business and domain layer, as those two terms generally mean much the same. Also, I wonder why you let the user communicate via web services. Human users of Android apps normally communicate with the presentation layer, which is subdivided into Android actions and views. As users aren't represented in a class model at all, you don't have to answer the philosophical question whether they interact with your views and/or activities. In general, the activities will depend on the views, but not the other way round, so you have layers activity - view - domain - data access.

PHP is most probably not on Android, but on a server application, so you'll have a similar layer structure for your server app, with some connector class in the Android app dependent on the server web service. I suspect that, in your picture, you didn't separate Android and server software clearly, as the PHP web service cannot call classes of the Android app.

Another approach is leaving some technicall fuss away and drawing a logical class diagram just of the application domain. In a well-designed application, this will be much the same as the classes of the domain layer. This will give the reader an insight into the essence of your software, without confusing him by too much technical detail.

Answer 2

There is an important difference between an UML model, which has to be comprehensive, and an UML diagram that is used to communicate the model:

UML 2.5 standard, annex A:

A UML model consists of elements such as packages, classes, and associations. The corresponding UML diagrams are graphical representations of parts of the UML model. UML diagrams contain graphical elements (nodes connected by paths) that represent elements in the UML model.

So there is no requirement to have a single diagram with 30 classes. Such a diagram would be far too complex for any reader to understand. So cut your class diagram into smaller understandable pieces:

• Intuitively, there could be much more relations between classes in the same package than between classes of different packages. This is why a decomposition using your packages could be the first candidate.
• On the other hand, your packages already have an implementation level of detail, making it difficult to get the big picture. So for your graduation, it could be more relevant to start showing abstraction of the problem that you're solving, i.e. starting with the classes relevant of the domain model (example) and then gradually dig into the design of your app.

The second diagram is more delicate, because it shows the behavioral interaction between actors and your system components, and the structure in layers of the architecture:

• The interaction between the actors (users + backend server) would ideally be represented in a high-level use-case (by the way, you should have one in you graduation report). But use case is not meant for documenting the structure of your software.
• The layered structure of your software could best be represented by a package diagram (especially if your java packages follow already the layer logic).
• But if you want to focus on the distribution of the architectural elements between servers and mobile devices, you could use a deployment diagram.