next up previous
Next: 4.2 Design patterns Up: 4 Action semantics at Previous: 4 Action semantics at

4.1 Object-oriented refactoring

Refactoring was introduced in [Opd92] to make the source code more understandable and readable. This is a behavior-preserving transformation, but it helps programmers to manipulate common language constructs, such as class, method and variable, of an existing application, without modifying the way it works [SPH+01].

The same idea is used in the UML model design. A good example is to refactor a class diagram, which happens to be ill-designed.

Ill designs are usually found in models, i.e. identifying a composition relationship with an inheritance (or generalization) relationship and thus an invalid inheritance is formed. In this case, an action defined in action semantics is used to discover all these design flaws and, if found, correct them. (Of course this process is very limited and also requires a lot of human work.) As mentioned above, action semantics uses the OCL dot-notation to navigate among all the objects in a model, it is able to look into every detail of the model design.


Table 5: An example of refactoring
\centerline{
\begin{tabular}{l}
Package::removeClass(class: Class)\\
pre:\\
\h...
...e.features $\to$\ forAll(feat:Feature $\vert$\ feat.owner
= nil)
\end{tabular}}


Table 5 shows another example of removing all the useless classes. Such classes are not referenced by any other class and they have no subclasses (or no features) [SPH+01]. Two functions, addSuperClass and delete are not defined in action semantics. They are defined by the programmer to add a generalization to a subclass and delete a class accordingly.

More examples on refactoring class diagrams and statecharts can be found in [SPTJ01].


next up previous
Next: 4.2 Design patterns Up: 4 Action semantics at Previous: 4 Action semantics at
Thomas Feng 2003-04-18