|
|
We are finally in the class diagrams, the diagrams where we start the generation of code! As we mentioned in chapter 7, a class diagram is a graphical representation of the classes in a system and the various kinds of static relationships that exist among them. It depicts the abstractions into which we have decomposed the problem domain during our analysis. While step 5 dealt with the conceptual view of the system, this step deals with the specification and implementation views (see par. 7.2). More advanced concepts of class diagrams are described here.
One way to view a class is that it consists of
two parts: the interface and
the implementation. The interface can be seen and used by other objects (e.g.
clients of the class); the implementation is hidden from clients. In other words,
the interface is the set of public methods of the class (see next paragraph).
Hiding the implementation details of an object is called encapsulation
or information hiding. Encapsulation offers two kinds of protection:
it protects an object's internal state from being corrupted by its clients as
well as client code from changes in the object's implementation.
Figure 12 shows class icon details:
+ Public visibility means that other classes have direct access to the attribute or operation
# Protected visibility means that only methods of the class or of a subclass have access to the attribute or operation
- Private visibility means that only methods of the class have access to the attribute or operation
/ Derived attribute (association) means that it can be easily calculated from other attributes (associations). Derived features indicate a constraint between values.
An abstract class is a class that has no instances. It exists primarily to represent a common abstraction to a number of subclasses. Abstract classes are shown with their name in italics inside the UML class symbol. A type is a descriptor for objects with abstract state, concrete external operation specifications and no operation implementation [Detsis, 2000]. It provides a specification for external behaviour. An interface is the use of a type to describe the externally visible behaviour of a class. In Java an interface is similar to a protocol. The notation for an interface in UML is shown in Figure 7. Interfaces in Java can also have method specification, public static final constants and structure. Class scope (i.e. static members) is represented with underlining.
Figure 12 Class notation details
Figure 13 shows the notation for a parameterized class. Java has no support for such type of class. For more information see [Fowler, 2000a].
Figure 13 A parameterised class, T: an object type, k: FArray length
Polymorphism is the ability of different objects to respond differently to the same message. It allows re-use of a method name by different objects. E.g. a circle and a rectangle object respond differently when a client calls their draw() methods.
Overloaded methods are new versions of the methods that act on different arguments of the same class. E.g. the two methods: draw(int x1, int y1, int x2, int y2) and draw(Point p1, Point p2) are overloaded methods.
Dynamic binding (also known as method resolution) allows a single variable to refer to different kinds of things, and provides support for leaving until runtime the decision as to which piece of code is appropriate to implement an opration on that variable. It allows new objects and code to be interfaced with or added to a system without affecting existing code and eliminates switch statements. Examples of dynamic binding are on overloaded and overridden operations.
Overloading uses the same operation name but a different signature (parameters), while overriding uses the same signature of a superclass in a subclass. Overriding offers you the ability to call an operation without knowing what kind of object you are calling.
The produced classes should satisfy the following criteria [Booch, 1991; Detsis, 2000]:
