Scheduler - Software Development Case Studies in Java - page 48

Analysis technique . During the analysis phase, we used abstraction to find
the commonalities between two apparently different application scenarios
and we recognize they fall into a well-known problem. The literature in the
field, together with our experience and knowledge of the domain, helps us in
identifying the basic concepts that form the analysis model.
Modelling notation . We used the cornerstone notation of object-oriented
development: class diagrams. They present the classes and the relationships
among them.
Development approach . During the design phase we assigned responsi-
bilities to the classes previously identified during analysis. We decided to
split all the computation related to the scheduling algorithm among the
classes Scheduler , Resource and Activity .
The two, apparently different, application scenarios show several similar-
ities, which have been captured in the first prototype. Its implementation
highlights the use of collections of objects. Pattern Iterator (Gamma et al .
1995) represents a common design practice when dealing with collections.
The second prototype has shown the basic features of the AWT and Swing
component library for building graphical interfaces. Pattern Model - View -

Controller describes the common architecture of graphical interfaces.

Pattern Iterator

Context Visiting the objects of a container class.

Problem Decoupling the visiting algorithm from the container data structure.

Forces or tradeoffs In order to enhance reusability, visiting algorithms (e.g. sorting or searching

algorithms) must not worry about the particular sequence of objects they
are operating on. Container classes cannot be abstract and generic.
Container class implements different data structures to optimize specific
performance criteria, e.g. memory occupancy, access speed, etc.

Solution Visiting algorithms do not have direct access to the component objects

through the container class. Instead they use iterator objects. An iterator
is an instance of a class that implements the Iterator interface. Its methods
are used by the visiting algorithm to navigate inside the container class.
Using the Iterator , any container is seen as an ordered sequence of objects.
Every container class is associated to a concrete iterator class that
implements the Iterator interface as shown in the following class diagram.

<<interface>>
Collection

<<interface>>
Iterator

! add( obj : Object ) : boolean
! remove( obj Object ) : boolean
! iterator() : Iterator

! hasNext( ) : boolean
! next( ) : Object

ConcreteCollection ConcreteIterator

0 collection : Collection

! add( obj : Object ) : boolean
! remove( obj Object ) : boolean
! iterator() : Iterator

! hasNext( ) : boolean
! next( ) : Object

iterator() {
return new ConcreteIterator(this);
}