UML class diagram: how to model relations about calling a method or starting an activity or service

Question

I'm creating my first Android app. I have avoided to label associations with user or system interactions (e.g. I have labeled starts instead startsWhenClick; I have labeled starts instead startsWhenDetection). However, after reading this, I'm considering to change the starts associations by << create >> dependencies. I'm confused!

The app works as follow. When the app starts, LauncherActivity will call the methods of BaseActivity to start the activity marked in SettingsActivity (it could be SettingsActivity too). LauncherActivity will launch both services too. This is the diagram:

Note: this question is the continuation of this question.

Inchoate

Answer 1

It is not a real class diagram.

• Starts and calls belong to notes, or if you are sure you want to see them on connections, do stereotypes on DEPENDENCIES, not associations.
• You still have no associations, and they are the main part of the class diagram. Look here about how to work with them. You should create associations first. Only after that show the dependencies. (It is not a common rule, but you should do so for better understanding)
• As for the actions you are trying to show here, do State Machine diagram for them, then probably Sequence or Activity diagram. Don't use Interaction overview diagram, you'll get lost in it.

But stop putting so many actions on the class diagram

IMHO, because Activities have no or almost no structure dependencies, the appropriate class diagram will be very poor - simple blocks without associations. And dependencies all over the field... So, the class diagram is not useful on this level. It seems, I have told you already, that class diagrams are for classes that are in one same Android intent - one or more for an intent.

As for communication diagram, I think it is not your case. It is more common, close to user, than sequence or activity diagrams. It is for the case when you have very many sorts of messages and you are planning their routes. For Camel planning, for example. But alas - it has not implemented message patterns. So, it remains only for very common planning of systems with mass messaging. Your "messages" are starting, initiating components and so on. You can't show it with that diagram.

You can try Object Diagram, or Composite Structure diagram. If you want to show functionality on the class diagram, you can't do it, but you can move to these ones.

Limburg

So, if I understood well, it would be (we must use dotted lines, right?): 1) PowerButtonPushedDetectorService<··· <<call>> ···LauncherActivity. Could I use the stereotype <<start>> even if it is not here? 2) LauncherActivity··· <<use>> ··· settingsAtrribute···>SettingsActivity and LauncherActivity <··· <<call>> ···SettingsActivity. Could I label <<usesMenu>> instead <<use>>? – Inchoate

@Inchoate dependencies are slashed, not dotted lines. a- - - ->b – Limburg

@Inchoate No, please! You should create associations first. Only after that show the dependencies. As for the actions you are trying to show here, do State Machine diagram for them, then probably Sequence or Activity diagram. Don't use Interaction overview diagram, you'll get lost in it. *But stop putting actions on the class diagram * – Limburg

Maybe I will understand with an example. So for example, what could be the association between PowerButtonPushedDetectorService and LauncherActivity? The related code of the LauncherActivity is: Intent service2start = new Intent(getBaseContext(), PowerButtonPushedDetectorService.class); startService(service2start); – Inchoate

@Inchoate Divide classes from objects/instances. They are not the same in Java. As I see from the code, PowerButtonPushedDetectorService is an object. I am afraid many of things you are talking about are objects really. Look at object diagram, there you can use ports on the classes. Each port provide some service to other classes or objects connected to it. It seems more proper for your problem. – Limburg

@Inchoate If we are in class diagrams, then there is a one-direction navigable association from LauncherActivity to Intent Instance, with service2start as instance and attribute names. And from that intent instance another navigable association to PowerButtonPushedDetectorService. As for the name of the attribute, look into the Intent constructor code, where the second parameter is put. – Limburg

@Inchoate It is a problem here - class diagrams do not show such dependencies well. For example, the anonymous type in UML is a catastrophe. In class diagram. In sequence one it is OK. – Limburg

I understand that a Java Object is (according to the JLS) an instance of a reference type. There are instances of other types: int, char... The object diagram seems useful to show different values of the objects during the lifecycle. It seems out of the point for me. Do you maybe mean component diagram? – Inchoate

@Inchoate No. I mean object diag, or...Ok, Composite Structure diagram. If you want to show functionality on the class diagram, you can't do it, but you can move to these ones. BTW, thank you, you have nudged me to see more problems in Class diagram from UML standard than I knew before. Definitely +1 for it. – Limburg

OK, I think I got it. Almost all the classes here are called by the Intent class. So it would be an actually messy class diagram. Instead, I could use a component diagram (so I could avoid to include the Intent class in it). Is it? – Inchoate

@Inchoate I think, because Activities have no or almost no structure dependencies, the appropriate class diagram will be very poor - simple blocks without associations. And dependencies all over the field... So, the class diagram is not useful on this level. It seems, I have told you already, that class diagrams are for classes that are in one same Android intent - one or ore for an intent. – Limburg

@Inchoate You could use also State machine and Sequence diagrams - It seems to me, they could be very useful, for they set state/actions dependencies and action sequences – Limburg

I did an activity diagram for understanding & explaining the workflow. Then, I'm used to making the class diagram without problem. Thanks to Android and you, Gangnus, I have discover a lot of new UML diagrams. I have found two types of composite structure diagrams. The first one seems more intuitive to use and understand, but I think you are refering to the second one. – Inchoate

What about the UML communication diagram? :) – Inchoate

@Inchoate 1. yes, I mean this second CSD. 2. As for communication ona, I think it is not your case. It is more common, close to user, than sequence or activity diagrams. It is for the case when you have very many sorts of messages and you are planning their routes. For Camel planning, for example. But alas - it has not implemented message patterns. So, it remains only for very common planning of systems with mass messaging. Your "messages" are starting, initiating components and so on. You can't show it with that diagram. – Limburg

@Inchoate And plesae, notice, that thanks here on SO are expressed mainly by upvotes and checked answers :-) – Limburg

First, thanks for asking with assertiveness. I was thinking in voting up only to the main comments to facilitate the person who read it to follow the conversation. But you're right: that's the only way to say thanks, and I'm very thankful. Furthermore, we can always edit your answer to include the most important stuff of the conversation. – Inchoate

On the other hand, the only clear stuff is that the UML information about those diagram is very confusing: I read that Composite structure diagrams are used to show the internal structure of a class. Anyway, I think the best UML diagram for this purpose is the composite structure diagram. I think we also could use the component diagram, but each class would be a component (and we know that's strange for those diagrams). Could you update your answer? (I could do it for you, happily, if you prefer). – Inchoate