Cyclomatic Complexity for Activity Diagrams with Forks/Joins

[Alan]

I am trying to figure out how to handle forks and joins in
activity diagrams when calculating the cyclomatic complexity of those
diagrams. I don`t know how forks and joins map to the nodes/paths in
an exquivalent complexity diagram.

I have done some Googling and reading up on the metric, but I have
not found the answer.

Anyone know? Thanks, Alan

[Eric Smith]

Alan,

Probably ...

Activities = vertices

Forks = vertices

Joins = vertices

flows = edges.

Connected components are all the components at which control starts and stops. (Usually 2 for an activity diagram with 1 Start node and 1 End node.)

"The Cyclomatic number V (G) of a graph G with n vertices, e edges and p connected components is

                                                V (G) = e – n + p."

Therefore ...

V(G) = flows - vertices +  connected components.

Eric

--
You received this message because you are subscribed to the Google
Groups "SysML Forum" group.
Public website: http://www.SysMLforum.com
To post to this group, send email to sysml...@googlegroups.com
To unsubscribe from this group, send email to
sysmlforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en

[Alan]

Eric,
Thank you for those thoughts. To be clear, each activity is
not a vertex. A "block" of activities with no control structure is a
single vertex for the purposes of calculating cyclomatic complexity.
Flows into and out of such a block are edges. The intent is to count
each "path" through the diagram.

Forks and joins designate parallel paths, so I am thinking that a
fork/join should be treated as a single control structure. I think
this means that each flow out of a fork would count as one edge, each
parallel block of activities before the join counts as one vertex, and
each flow into a join would count as one.

Here is an example, which considers a fork/join structure in
isolation, ignoring for the moment the larger diagram structure): For
a simple fork to two simple activities that are then joined, the
complexity would be 4 - 2 = 2 paths. This makes sense to me.

For 3 activities that fork and are then joined, there would be 6 -
3 = 3 paths. When the structure between the fork and the join are
simply activities, it will always be equal to the number of vertices
(blocks of activities), since there are twice as many edges as
vertices.

I think this is sort of where you were headed.

Thanks, Alan

> >http://groups.google.com/group/sysmlforum?hl=en_US?hl=en- Hide quoted text -
>
> - Show quoted text -

[Eric Smith]

Alan,

Perhaps if there is pre-classification of what is a control-related node and what is not (such a pure activity), then the pure activities should not be shown as nodes on the graph.  

Also, with the formula being:

e = edges
n = control nodes (= "vertices")
p = connected components (= exit nodes)

                                                 V (G) = e – n + p.

Then, in your first example, with 1 fork to 2 edges (with pure activities) leading to one exit join node, the cyclomatic complexity would be:   V(G) = 2 - 2 + 1 = 1 .

The second example, with 1 fork to 3 edges (with pure activities, which are ignored as nodes) leading to 1 exit join node, the cyclomatic complexity would be:  V(G) = 3 -2 + 1 = 2 .

Notes:

1, An activity may be classified as a control node, given that a transformation of information (via a pre-programmed transformational activity) is a type of control. 

2, Ultimately, perhaps there may be a sliding scale as to what is a control node!

Eric