Component interface complexity assessment [Boxall 04]
The metrics presented in this section aim to assess the understandability of a com- ponent interface. Boxall and Araban assume that understandability has a positive influence on the reusability of software components. As such, a higher understand- ability leads to a higher reusability of the components.
Original specification:
Arguments Per Procedure (APP) represents the average number of arguments in publicly declared procedures (within the interface), and is defined in Eq. 5.1.
APP= na np
(5.1)
where:
na= number of arguments on the publicly declared procedures np= number of publicly declared procedures
The Distinct Argument Count(DAC) represents the number of distinct arguments in publicly declared procedures and is defined in Eq. 5.2. The Distinct Arguments
Ratio(DAR) represents DAC’s percentage on the component interface and is defined in (Eq. 5.3).
where:
A = set of the < name,type > pairs representing arguments in the publicly declared procedures
|A| = cardinality of the A set.
DAR= DAC
na
(5.3)
The Arguments Repetitiveness Scale (ARS) aims to account for the repetitiveness of arguments in a component’s interface (Eq. 5.4). In other words, it is used for mea- suring the consistency of the naming and typing of arguments within the publicly de- clared procedures of an operation.
ARS=∑a∈A|a| 2
na (5.4)
where:
|a| = count of procedures in which argument name-type a is used in the interface
Rationale:
The rationale for the DAC metric is that humans have a limited capacity of receiv- ing, processing, and remembering information [Miller 56]. The number of information chunks in the procedure definition (in this case, its arguments) should be limited. Box- all and Araban suggest that an increased number of arguments reduces the interface’s understandability and, therefore, its reusability.
The rationale for the DAR metric is that the repetitiveness of arguments increases the interface’s understandability, and, therefore, the component’s reusability. Accord- ing to Boxall and Araban, |a| is squared in this definition to create a bias that favors consistent arguments definitions in the interface. Boxall and Araban also claim that interfaces with a higher ARS “will tend to be dominated by fewer distinct arguments which are repeated more often”.
DAC is influenced by the adoption of a consistent naming convention for argu- ments in the operations provided by a component. If the same argument is passed over and over to the component’s operations, the effort required for understanding it for the first time is saved in that argument’s repetitions throughout the interface. The smaller the number of distinct arguments a component user has to understand, the better. Likewise, a lower DAR leads to a higher understandability. However, unlike
DAC, DAR is immune to the size of the interface, because its value corresponds to
Comments:
The original proposal of the APP metric uses C/C++ component interfaces to illus- trate the metric definition. Overloaded and overridden operations are referred to in the definition, but not inherited ones. We assume them to be outside the scope of this metric. If the component is implemented in an OO language, all public and protected OO methods should be counted, but not the private ones, as these will be invisible to component users. APP’s definition assumes a single, or at least unified, interface for the component. As seen in our example, components may provide or require more than one interface. As each interface has a set of operations, we can consider the “uni- fied interface” as the result of the union of the interfaces. We will also assume that the operation names will be qualified by the interfaces they belong to, so that opera- tions with a similar signature owned by different interfaces are counted as different operations, rather than the same.
In the DAC metric definition, Boxall and Araban consider a parameter as a dupli- cate of another if the pair < name, type > is repeated in different operation signatures. The same holds for the definitions of DAR and ARS.
Component internal complexity [Narasimhan 04] Original specification:
The Component Packing Density (CPD) was proposed by Narasimhan and Hen- dradjaya and aims at assessing the complexity of a component, with respect to the usage of a given mechanism. CPD represents the average number of constituents of a given type (e.g. lines of code, interfaces, classes, modules) in a component (Eq. 5.5).
CPDconstituent_type=
] < constituent_type >
]components (5.5)
where:
constituent_type = type of the constituents whose density is being assessed ] < constituent_type > = number of elements of constituent_type in the assembly ]components= number of components in the assembly
Rationale:
A higher density indicates a higher complexity of the component, thus requiring, as Narasimhan and Hendradjaya suggested, a more thorough impact analysis and risk assessment.
Comments:
CPD can be defined for a multitude of different constituents, but most of those suggested by Narasimhan and Hendradjaya are not available for users of black-box components. For illustration purposes only, we will assume the operations in all pro-
vided interfaces as the constituents of a component, in our formalization.
Component communication [Goulão 05b]
The metrics presented so far in this chapter focus mainly on the provided interfaces of components, and the operations defined there. In what concerns their definition, adapting these metrics to the required interfaces of components would be straightfor- ward. The ODM can also be used on other items of a component interface, such as events. Although there is no direct support for representing produced and consumed events in the UML 2.0, these can be suitably represented in other notations, such as the CCM. Furthermore, the UML lightweight extension mechanism (stereotypes) can be used to circumvent this limitation of the standard metamodel.
Original specification:
We can define Event Fan-In (EFI) to measure the number of provided events. In some metamodels, such as the CCM metamodel, these events are either emitted or published by a component1. Event Fan-Out (EFO) represents the number of events consumed by the component.
The paper in which we proposed both metrics [Goulão 05b] was dedi- cated to metrics defined upon CCM. EFI and EFO are defined as operations of the ComponentDef meta-class. The definitions rely on auxiliary operations PublishesCount(), EmitsCount(), and ConsumesCount(), also defined upon the same meta-class. For this initial presentation of the metrics, we will omit the auxiliary op- erations, and just leave the metrics definitions. Later, when presenting the formal def- initions for all the metrics presented in this chapter, we will revisit these definitions and complete them with all the necessary auxiliary operations. Listing 5.2 presents the defintions of EFI() and EFO().
Listing 5.2: The EFI and EFO metrics.
c o n t e x t C o m p o n e n t D e f
EFI (): I n t e g e r = self . P u b l i s h e s C o u n t () + self . E m i t s C o u n t () EFO (): I n t e g e r = self . C o n s u m e s C o u n t ()
Rationale:
For EFI and EFO, the understandability of the component interaction with other com- ponents gets lower as the number of events gets higher. In other words, a higher com- plexity leads to a lower understandability.
1The distinction between emitted and published events is not present in all component models. This
distinction is used in the CCM, for instance, but not in our extension of the UML 2.0 metamodel, where we will simply consider events as either provided or required (just like interfaces). A publisher com- ponent is an exclusive provider of an event, while an emitter shares an event channel with other event sources. In any case, components may subscribe to that event channel, to receive the events notifications.
Comments:
Events are not supported by all the component models currently available. There- fore, these metrics will not be available for component models that do not support their underlying model elements, either directly (as it happens with the CCM), or indirectly (as in UML 2.0, through the usage of stereotypes).