This paper provides a solution to the class responsibility assignment case using UML-RSDS. We show how search-based software engineering techniques can be combined with traditional MT techniques to handle large search spaces. This case study [1] is an endogenous transformation which aims to optimally assign attributes and methods to classes to improve a measure, class-responsibility assignment (CRA-index), of class diagram quality. We provide a specification of the transformation in the UML-RSDS language [3, 4] using search-based software engineering techniques (SBSE) [2]. UML-RSDS is a model-based development language and toolset, which specifies systems in a platformindependent manner, and provides automated code generation from these specifications to executable implementations (in Java, C# and C++). Tools for analysis and verification are also provided. Specifications are expressed using the UML 2 standard language: class diagrams define data, use cases define the top-level services or functions of the system, and operations can be used to define detailed functionality. Expressions, constraints, pre and postconditions and invariants all use the standard OCL 2.4 notation of UML 2. For model transformations, the class diagram expresses the metamodels of the source and target models, and auxiliary data and functionalities can also be defined. Use cases define the transformations and their subtransformations: each use case has a set of pre and postconditions which define its intended functionality. The postconditions act as transformation rules. A use case can include others, and may have an activity to define its detailed behaviour.
Copyright ⃝c by the paper's authors. Copying permitted for private and academic purposes.
In: A. Garcia-Dominguez, F. Krikava and L. Rose (eds.): Proceedings of the 9th Transformation Tool Contest, Vienna, Austria, 08-07-2016
The first part of the solution is an endogenous transformation (Figure 2) which (i) identifies the building blocks and places these in separate classes: the createClasses transformation in Figure 2; (ii) refactors the class model to reduce coupling: the refactor transformation; (iii) removes empty classes: the cleanup transformation. Finally, the measures transformation displays the CRA-index and other measures of the intermediate solution. These transformations are co-ordinated by the preprocess transformation. The metamodel is produced from the Ecore metamodel provided.
The rules (postconditions) for createClasses include creation of a default class, which contains all the methods that are not linked to any other feature (their sets of functional and data dependencies are empty):
and a rule to place a method (self ) into any class c which contains all of the attributes it depends on:
<: denotes the subset relation. Other rules create classes for each ‘chunk’ of a method plus the attributes which are exclusively or primarily depended on by that method.
The refactor transformation moves methods m and attributes a from one class self to an alternative class c, if there are more dependencies linking the feature to c than to self . Eg., for methods we have:
m : encapsulates@pre & m->oclIsKindOf(UMLMethod) & c : UMLClass & depends = m.dataDependency->union(m.functionalDependency) & depends->intersection(c.encapsulates@pre)->size() >
depends->intersection(encapsulates@pre)->size() => m : c.encapsulates Although this transformation may decrease the CRA-index, it generally reduces coupling.
Finally, cleanup deletes empty classes: UMLClass:: encapsulates.size = 0
=> self->isDeleted()
The preprocess transformation co-ordinates the other transformations. It has no rules of its own, but it has an activity to control the subordinate transformations, which preprocess accesses via ≪ include ≫ dependencies: while Feature->exists(isEncapsulatedBy.size = 0) do execute ( createClasses() ) ; while UMLClass->exists( c | c.name /= "Class0" & c.encapsulates.size = 1 ) do execute ( refactor() ) ; execute ( cleanup() ) ; execute ( measures() ) createClasses is iterated until all features are encapsulated in some class, then refactor is iterated until all normal classes have at least 2 features. 3
A general GA specification is provided in the UML-RSDS libraries (Figure 3). This can be reused and adapted for specific problems, by providing a problem-specific definition of the tness function, the content of GATrait items and values, and the functions determining which individuals survive, reproduce or mutate from one generation to the next. Math is an external class providing access to the Java random() method.
p : elite & q : population & q.fitnessval < p.fitnessval & GeneticAlgorithm.isCombinable(p,q) => p.combine(q) : recombined
evolve deletes unfit individuals (eg., those with fitness below the median fitness level), preserves the best individuals (those in the best 20%), and mutates and recombines individuals that meet the necessary criteria. Mutation consists of incrementing or decrementing the value of a randomly selected trait. Crossover takes place at a randomly-selected trait position. nextgeneration assembles the next population, and recalculates fitness for all individuals, and identifies the top fitness value.
To model the CRA problem in a GA, individuals represent possible assignments of features to classes, and have traits t for each feature f in the model, and item is the name of the feature. The trait value is the index number of the class to which the feature is assigned, ie.:
t:value = UMLClass:allInstances→indexOf (f :isEncapsulatedBy:any)
The fitness value is the CRA-index, computed using the definitions of [
The functions mmi and mai of [
cj.encapsulates->intersection(m.functionalDependency)->size() )->sum() ClassModel:: query static mai(ci : UMLClass, cj : UMLClass) : int pre: true post: result = ci.encapsulates->select( mi | mi : UMLMethod )->collect( m |
cj.encapsulates->intersection(m.dataDependency)->size() )->sum() Likewise, the coupling and cohesion ratios can be defined in OCL.
The ga(iter : int ) use case performs initialise to initialise the population with 50 copies of the model produced by preprocess, and 100 random individuals, then it iterates evolve and nextgeneration for iter times.
In a final phase, an optimal individual gmax produced by the genetic algorithm is mapped to a class model by the postprocess use case:
population.size > 0 & gmax = population->selectMaximals(fitnessval)->any() => gmax.traits->forAll( t |
E [str ] is the instance of entity type E with primary key value str . Following this, cleanup may be needed to remove any empty classes. 4
CRA after GA 3 2.75 0.6175 0.744 -8.1
All solution artifacts are available at www.dcs.kcl.ac.uk/staff/kcl/umlcra. The specification is in the file mm.txt, and the use cases and operations are listed in crausecases.txt and craoperations.txt. Solution models are in cresult.xmi, dresult.xmi, etc.
We have shown that a general-purpose genetic algorithm can be used in combination with MT to obtain good results for the CRA problem. General recombination and mutation strategies are used, for example, mutation simply moves one feature from one class to another. Improved results could probably be produced if specialised operators were used, eg., moving a method would also require moving the attributes that it exclusively depends upon. A significant aspect of our approach is that we have specified the GA and MT system components in the same formalism (UML and OCL), rather than using hetrogeneous technologies.