Complexity Metrics Extensions for Multitasking Systems

As it has been shown in Section 4, both the Software Science metrics and the cyclomatic complexity do not capture chosen characteristics of multitasking systems or to be more precise, the language constructs associated with specific characteristics of multitasking software are recorded as all other similar constructs in the program. A modification of both metrics is required to extract the desirable characteristics.

5.1. Proposal of Complexity Metrics Extensions for Multitasking Systems

In case of the Software Science metrics, a slightly modified approach presented by Tso et al. in [15] can be applied. For that purpose, a set of items associated with chosen characteristics of analyzed software has to be identified. In the presented solution, the set of items, called a characteristic vocabulary, consists of:

 numerical identifiers of messages exchanged between the tasks,

 name of a function used to receive messages from the task’s message queue,  name of a function used to send messages to other tasks’ queues,

 names of functions used to set and cancel timers.

Each operator or operand that is found in the characteristic vocabulary is classified

as a characteristic operator or characteristic operand.3 _{Such classification allows to}

specify the following input parameters:

 n1c – number of unique characteristic operators,

 n2c – number of unique characteristic operands,

 N1c – total number of characteristic operators,

 N2c – total number of characteristic operands,

for the process of calculation of the Software Science described in Section 1. To distinguish new values of Software Science metrics from the standard ones a prefix characteristic is added for each of the metrics. The results are presented in Table 2.

In case of the cyclomatic complexity, an approach similar to the proposed by McCabe design complexity [9], and specified data complexity [10], can be applied. The main idea standing behind the calculation of both metrics is to specify nodes in the control flow graph that have a certain property and to apply a set of rules presented in Figure 6 in order to reduce the input control flow graph. The value of the metric is equal to the cyclomatic complexity calculated for such reduced graph.

Figure 6. Graph reduction rules proposed by McCabe [9]

In the presented approach, all nodes that contain items from the previously defined characteristic vocabulary are treated as characteristic nodes. The results obtained for the proposed characteristic cyclomatic complexity are presented in Table 2.

3

There is no need to create separate sets of items for operators and operands, because during the parsing process function names are classified both as operators and operands, and all remaining identifiers, constants and variables are classified as operands.

Table 2. Results of calculation of extended Software Science metrics and cyclomatic complexity for all versions of the manager task (the first column contains results for the task’s main routine, the second column contains results for the whole task).

Metric Version 1 Version 2 Version 3

N1c 1 5 1 7 1 11 n1c 1 2 1 2 1 4 N2c 5 13 7 19 9 27 n2c 5 10 7 14 9 18 Nc 6 18 8 26 10 38 nc 6 12 8 16 10 22 Vc 15,51 64,53 24,00 104,00 33,22 169,46 Ec 7,75 83,89 12,00 141,14 16,61 508,38 ec 13 33 17 45 21 55 nc 10 42 12 56 14 66 ac 0 0 0 0 0 0 pc 1 13 1 17 1 19 vc(G) 5 17 7 23 9 27

Figure 7. Reduced control flow graphs of the main task routine of the manager task in versions 1, 2 and 3 (from the left to the right).

5.2. Initial Evaluation of Proposed Metrics

For the extended Software Science metrics, the interpretation of the results seems to be the most meaningful on the task level, on which the following observations concerning the input parameters can be made:

 total number of characteristic operators N1c is equal to the sum of one call to the

function retrieving messages from the task’s queue, a number of calls to the fun- ctions sending outgoing messages and a number of calls to timer related functions,

 number of unique characteristic operators n1c is equal to a number of distinct

 total number of characteristic operands N2c includes the total number of charac-

teristic operators N1c plus the sum of all occurrences of message identifiers (in

case of the version 3 of the presented scenario, there are 2 additional occurrences of timeout messages identifiers passed as parameters to the function setting timers),

 number of unique characteristic operands n2c includes the number of unique

characteristic operators n1c plus the sum of all message identifiers.

It can be observed that values of metrics increase with the increase of general complexity of the communication pattern, but although all input parameters are directly connected with the multitasking characteristics pointed in Section 4, it is difficult to give the appropriate interpretation of the extended Software Science metrics through an analogy to the original description of the Halstead‘s Software Science metrics. For

example, in case of the characteristic predicted effort Ec, by making a similar assump-

tion as in the Halstead’s work [4], that a skilled programmer makes about 18 elemen- tary mental discriminations per second, the period of time required to understand the communication pattern of the most complex version of the presented example by looking at its code would be about half a minute. The result is probably closer to the period of time required to understand the presented communication scenario by looking at the diagram on Figure 3. Still, it seems that the proposed metric may indeed have some connection with a mental effort required to understand the presented com- munication pattern, but its usefulness, as in case of remaining metrics, has to be proved during the empirical verification.

Interpretation of the characteristic cyclomatic complexity metric is much easier as the subject has been already discussed by McCabe for the design complexity and specified data complexity metrics. According to McCabe [4], [5], a value of the cyc- lomatic complexity calculated for reduced graph is equal to a number of independent paths in the program, which need to be executed during the integration tests, in case of the design complexity, and for example, during regression tests after the modification of code using the specified data, in case of the specified data complexity. A similar interpretation may be given for the proposed characteristic cyclomatic complexity. The results presented in Table 2 show that along with the increase of general complexity of the communication pattern, it is the complexity of the main task routine and a number of modules of the task that contributes to the overall value of the metric for the prog- ram. The characteristic cyclomatic complexity of the main task routine increases by a number of distinct incoming messages recognized by the task (see Table 2 and in Figure 7). All other modules are reduced to single execution paths, for which the characteristic cyclomatic complexity equal to one. By an analogy to the already presen- ted interpretation, each of the independent paths of the main task routine should be executed during tests of the communication mechanisms, while it should be enough to enter each of remaining modules of the task only once.

The results obtained with the use of the proposed characteristic cyclomatic complexity are very encouraging. It should be noticed though, that the information connected with calls to timer related functions, which have been placed in message handler routines with a relatively simple flow of control, was lost during the reduction process. Such property of the reduction process suggests that, as in case of cyclomatic complexity, an additional perspective, possibly the one applied in the proposed characteristic Software Science metrics, should be used.