Which UML diagram is more adequate to represent a multithread process with loops

Question

I have a process that I have been able to drawn somehow with a flowchart.

This process involves several classes, loops and several threads of execution.

However I am unsure which (if any) UML diagram could be adequate to represent it.

I thought first Sequence Diagrams since it includes loops and can represent-I think- threads of execution, but I am not sure what goes along the lifelines. It seems that I cannot represent anything of what is happening.

Then I thought about Activity Diagrams but my textbook does not include loops in it. However looking at examples such as these ones it seems that loops can be represented simply in Activity Diagrams.

I suppose that I can represent threads through Forks and Joins but I am open to listen to suggestion from more experienced designers.

Answer 1

I have a process that I have been able to drawn somehow with a flowchart.

Great you already have it documented, the industry approach would probably be just use this already existant diagram.

This process involves several classes, loops and several threads of execution.

there is no need to limit yourself to a single diagram, if multiple diagrams help you communicate use multiple diagrams. remeber the end goal in industry is usually about communication your design, uml is just a tool for that, but you may also use text or non uml diagrams, there is rarely a requirement in industry to capture everything in UML (not since CASE tools in the 90s anyway)

However I am unsure which (if any) UML diagram could be adequate to represent it.

I thought first Sequence Diagrams since it includes loops and can represent-I think- threads of execution, but I am not sure what goes along the lifelines. It seems that I cannot represent anything of what is happening.

Life lines can show individual object lifetimes, threads, whole processes, its up to you really, the diagram as a whole will show logical time ordering of messsages, it will not show state

Then I thought about Activity Diagrams but my textbook does not include loops in it. However looking at examples such as these ones it seems that loops can be represented simply in Activity Diagrams.

yes activities can loop, activity diagram should be the closest match to your existing flow chart as they do show states and decisions.

I suppose that I can represent threads through Forks and Joins but I am open to listen to suggestion from more experienced designers.

Who is the diagram for? and what are you trying to communicate to them? this is your best guide as to what to do. e.g. if its for other programmer i might skip diagrams and show code, if its for non-programmers I might use UML, but probably not at the level of showing individual object or thread lifetimes, just showing whole processes is probably enough

Answer 2

A flowchart models a control flow, with the following characteristics:

• at any given moment in time, only one element is active. No parallelism is foreseen;
• the arrows between the elements represent a sequential relation in time (i.e. next action);
• looping is represented by going back to a previous element ("previous" in the sense that there is a possible path from that element to the current element).
• some ambiguity is possible when some symbols are used as source or destination of data with arrows represneting a dataflow instead of a sequence.

The closest UML diagram is the activity diagram. The AD is defined in a very precise way, allows to mix control flow and object flows, and provides for concurrency.

A flow chart can in general be converted to an activity diagram (see a simple example in this article). Even cross-functional flow-charts: these can be converted to partitioned activities. The main difficulty in the conversion is related to the input/output/data elements, that require a more careful mapping to object flows, and the respect of come constraints.

There is no loop. But there are several alternatives to show them, for example:

• using guarded branching to previous nodes as in flowcharts when you don't use the loop symbol.
• move the inner part of a loop to a callable action (to make it more readable)
• express the loop in the action description.

Now, be aware of the risk of over-diagramming: activitiy diagrams are meant for modeling complex activities and processes. It is not advisable to use them for modeling line by line the instructions in the code. If you work at such higher level of abstraction, the need to explicitly represent loops fades away (e.g. you will no longer document a loop on user input, but you'd document a process that is triggered for every user input to be processed).