Abstract

The most important characteristic of object-oriented designs is their degree of reusability [Wirfs90]. All literature in the field mentions this feature as the key aspect in the object-oriented paradigm. In general, reusability means that a piece of design is used in more than one application of the same or different domains. The latter reaches the ideal degree of reusability, and it generally happens at the level of single classes or, on the other end, with abstract designs (design patterns).

However, reusability occurs when various applications have been built, and particular classes as well as pieces of designs have been subject to many modifications and have reached certain maturity. Therefore, experienced designers are mainly the ones that can have a hand in reuse.

The above paragraph raises the question of how students in a teaching environment can evaluate the reusability of their design, when they do not have built many applications in the same or different domains.

This paper is focused on a characteristic of object-oriented designs that can be measured in a single application and that also leads towards reuse: that is variability or extensibility of a design.
 

1. Introduction

The degree of reusability of an object-oriented design is the best measure of its quality. However, in a teaching environment, it is most of the time a very abstract concept for students to grasp. It usually turns very difficult for them to evaluate whether their design will be reused in other applications in the same or different domains, given that they do not have experience. A teacher may say to a student that a piece of design is not reusable, and the student will not understand the reason.

Therefore, how can teachers evaluate the designs of students in a way that they can understand and imitate? How can teachers evaluate designs of small or medium-sized applications without making reference to the bigger picture of the entire domain?

This paper answers the above questions with the notion of variability or extensibility of an object-oriented design. We think that an excellent method to evaluate designs in a teaching environment is to analyze how much extensible or "open to changes" the design is. We will explain some approaches to measure variability of a design in a systematic manner.

Before expanding our topic, it is worth setting the assumptions: the designs that we are going to evaluate are correct, that is they solve the problem specified to the students.
 

2. Forces: Agents of Change

Every domain has its own rules, which make it possible to estimate future (reasonable) changes. One change is produced as a result of the action caused by a set of forces, which are in essence "agents of change" within a specific domain. In [Lea], it is clear expressed that "· natural forces cause successive artifacts to better adapt to and mesh with their environments, almost always ultimately finding points of equilibrium and beauty·".

Not only is true that each domain has its own forces, but also different problems within the same domain can be affected by distinct forces. For example, (financial) banking domain developers deal with different kind of applications, which share (in many cases) classes, objects, UI, databases, final users, etc.; but a "settlement-delivery" application will not be affected by the same forces that would affect a "pit-ticket" manager application.
 

3. Evaluating Variability

We propose evaluating the variability of a design in a systematic manner. The first step is based on analyzing the compounding forces of the problem, the second one tries to test the design with new forces found within the domain. The last step avoids over-specification of the solution.

3.1 Finding Forces

Firstly, the forces of the problem should be found. The next step consists on picking a force, assign to it a priority over the others and confront it with the design. Is the design capable of supporting that priority of the forces? If it does, it should be included as a positive consequence of the solution. On the other hand, if the solution is not flexible enough to support that priority of the forces, it should be noted as a negative consequence.

Each of the forces is picked in turn and the same is applied. At the end, we will have a much complete list of consequences of the design. If we are not satisfied with the consequences, another solution should be designed and the same technique is applied.

We will present the classical example of the personal telephone book in order to show how the activity of finding forces in a simple domain could be used in the classroom.

When a force is prioritized, new examples of a variation can be found. Suppose that we want to give more emphasis to Force 1 (Book-able entities could vary). We can think of new kind of entities as companies, which not only have their telephone and address but also have contacts in different areas, etc.

3.2 Testing with New Forces

The second activity in evaluating variability consists on finding new forces to the problem, forces that arise from an adequate analysis of the domain. These new forces should be provided by the teacher, in order to prevent students from creating unreal new requirements.

Following the personal telephone book example some new forces could be presented in order to enhance the design (see table 2);
 

Table 2 presents three new forces that could be applied on the problem. These forces are used to analyze the impact of the resulting changes on the original design, such as: do relationships among certain classes need to change?, canthe architecture easily support a new hierarchy?, may the instantiation process be changed in order to support new classes and hierarchies?, etc.

3.3 Avoiding Over-Specifications

The last step tries to set boundaries on the degree of variability. Many times we find students that over-specify in unnecessary ways, that is, their designs handle some unreal requirements. In a few cases, when we can give a complete and perfect specification to the students, we can ask them to keep close to the specification and do not imply anything that is not in there. However, a complete specification is only given with the first homework. As the course develops, we want students to derive new forces of the problem, so we rarely give them complete specifications. Nevertheless, we can teach them to find boundaries to their solution by helping them find opposite forces of the problem. Examples of opposite forces are:

1. losing variability, when the student subclassifies a class creating a hierarchy that did not appear in the problem;
2. preventing derivation, when the student builds a bad composition, bad meaning that the composite delegates everything to the component without adding any new functionality. Students usually do this for adapting the componentâs interfaces to what they find more appropriate for the particular application.

This paper presents a way to evaluate object-oriented designs. We claim that it is possible to understand a problem in terms of forces, which are finally agents of (future) changes. Afterward, forces are key elements in order to find those points where the designer has to prepare its solution for future changes. This is a clear way to produce a draft design of a framework as it is presented in [Pree96], where future variability is expressed in term of hot-spots. One of the problem in developing reusable software is that it often has to be reorganized [Gamma95]. Design patterns provides a good chance to understand how to reorganize a design, but the designer needs to has a clear idea about what elements of the domain could affect (in the future) the problem definition.

5. Acknowledgments

We would like to thank Gustavo Rossi for spending his time discussing with us about object design and ways to evaluate students, and Alejandro Fernandez for sharing his teaching experience improving our vision about homeworks and exercises.
 

6. Bibliography

[Gamma95] E. Gamma - R. Helm - R. Johnson - J. Vlissides "Design Patterns. Elements

of Reusable Object-Oriented Software". Addison-Wesley, 1994.

[Lea94] D. Lea "Christopher Alexander: An Introduction for Object-Oriented Designers". ACM Software

Engineering Notes, January 1994.

[Pree95] W. Pree "Design Patterns for Object-Oriented Software Development"

Addison-Wesley, 1995.

[Wirfs90] R. Wirfs - Brock - B. Wilkerson ö L. Wiener "Designing Object Oriented

Software". Prentice Hall, 1990.