next up previous
Next: 4.3 Aspect weaving Up: 4 Action semantics at Previous: 4.1 Object-oriented refactoring

4.2 Design patterns

Design patterns summarize and formalize good software design experiences, which can be reused in different contexts to increase modularity, stability, reusability, an so on [GHJV95].

Applying design patterns to the model design is desirable, because they are proved (either theoretically or practically) to be very good designs. The new model designs benefit from reusing these good designs.

However, an initial design may not conform to a design pattern even if it could. This is not always because of a simple-mindedness: the designer may choose to first design the model in a more straightforward way and test it; if the test result is satisfactory, design patterns are considered to improve the performance, modularity, and so forth.

Applying a design pattern to multiple models can be achieved in one step and automatically. The designer first identifies a design pattern or a variant of a design pattern, which improves the current model(s). Then a small program is written in action semantics to reconstruct parts of the model(s). For class diagrams, this reconstruction results in adding or deleting classes or associations. The difference between applying a design pattern and refactoring is the former approach also changes the model behavior. For instance, when applying the proxy design pattern, proxy classes are added between external access and the real objects. The proxy intercepts the access requests made to the real objects, relays refined requests to the real objects, and then sends back the results. This pattern makes the external design less dependent on the object's internal implementation.

For statecharts, new states may be automatically created, and the existing state hierarchy is also subject to change. An example is, in an initial statechart design, many integer variables are used to preserve states. However, to achieve a pure statechart design, only states preserve states and no variables are allowed, since they make it difficult if not impossible to analyze the model. Then an integer design pattern can be automatically applied to restructure the model by first discovering all the integer variables in use and then removing these variables and inserting new states in appropriate places to provide the same functionality. If the very large amount of additional states are written manually, it is an extremely boring and error-prone process.


next up previous
Next: 4.3 Aspect weaving Up: 4 Action semantics at Previous: 4.1 Object-oriented refactoring
Thomas Feng 2003-04-18