Activity Diagram and SwimLanes

Question

Should activity diagram include detailed information about how the system functions from the start of the application?

Say for example i am making a swing application in which the app loads a JList with images when the application opens, so should i specify that in activity diagram even though user isn't himself performing the task of loading the images in the JList.

Also should swimlanes in activity diagram be divided according to the possible classes my swing application might have.

For example having 1 swimlane for model, view and controller each in a simple swing application. Below are the Image's that I made,

OR

I feel that even though the first image is correct,the second one helps me visualize how the class diagram is going to shape up in a much better way. So should I use the second Image?

Answer 1

Swim-lanes have absolutely no model meaning. They are just a line. I recommend to use pools/lanes which are (BPMN stereotyped) UML elements. They are classified accordingly (usually with an actor) and the single actions go into each of those. This gives the activity a clear structure and it also shows responsibilities.

Answer 2

As always, the answer is "it depends." The level of detail is not dictated by the type of diagram, but the context in which the diagram is used.

If the diagram is intended to show the flow through a use case, it should probably restrict itself to showing the activities performed by the actor(s) and the system as a whole, rather than the parts of the system.

If on the other hand the activity diagram shows the flow through a use case realization, it should definitely show the different parts of the system.

Let's say that halfway through the project you decide to change the design and not use MVC. This means the diagram needs to be redrawn. If the diagram is part of a use case realization, that's to be expected (because that's what you've done, you've decided to realize the use case in a different way). But a diagram that's part of the use case itself shouldn't need to be redrawn just because you've changed the design; the flow of interactions between the actor(s) and the system-as-a-whole shouldn't change.

That said, MVC is such a well-known way of breaking down a user interaction that it may be permissible to go to that level of detail even in a use case. So, assuming that you're documenting a use case and not a realization, if in your project or company user interactions are always designed as MVC, then I say go right ahead -- but keep it strict and use "model" rather than "image service". If the decision to use an MVC design cannot be taken during the use case analysis phase, I'd advise against it.