Multidimensional characterization of evolutionary clusters: An experience report

• We describe what architects consider to be an unwanted coupling and how this knowledge can be captured in scenarios.
• We describe how these scenarios can be used to filter out the unwanted couplings according to that scenario.
• We apply this process to a large embedded software system with a development history of more than a decade.

Context: Software architects try to decompose software systems such that their constituent parts can evolve independently from one another. During the actual evolution, identifying groups of software entities from different parts which frequently changed together, is one way to help architects evaluate how independently the different parts can evolve. However, there may be many such groups from which the architects have to select the ones denoting issues in the decomposition worth addressing.ObjectiveIn this paper, we use a number of properties of those groups of entities, such as whether they involve more than one site, how many entities are involved, how often these entities are changed, and so on, to identify a subset of groups indicating issues the architect does want to address.MethodWe describe (1) a number of properties of groups of co-changing entities, (2) scenarios expressing issues to be addressed, in terms of values for the different properties, and (3) the mapping of such scenarios to queries on a set of groups of software entities that changed together. Executing that query results in a subset pointing to issues worth addressing according to that scenario.ResultsWe apply our method to a large embedded software system having a development history of more than a decade. For several scenarios worked out, the number of issues selected for further investigation by the architect is less than half the number of issues selected using only one or two properties.ConclusionOur experience suggests that using multiple properties of groups of co-changing entities is a useful way to accurately identify the set of issues an architect has to address when improving the decomposition of a system.