designspec_method.html

This chapter describes the design method used. The chapter also describes the notation that has been used to illustrate the structure of the system and its dynamic behavior.

There are many recognized methods that can be applied when doing object oriented design. The design group however, felt that it would be overkill to use these methods since they mostly target projects much larger than this one. Therefore the group developed it's own design method. The method was named "Whiteboard workshop method".

This diagram below gives a general idea of the flow of the design work.

The design work started by looking at what objects are present in the AudioJury domain. In other words, what are the objects that AudioJury operates on? The central objects were quite obvious:

With guidance from the module diagram in the architecture document [Johansson, 2003], some additional non-data centric but necessary objects were introduced, for example:

The idea of the whiteboard workshop is to get as many points of view as possible on the chosen design and then iteratively improve it.

In practice, this means that UML diagrams are drawn on a whiteboard. Members then discuss and revise the model until it is approved.

This does not necessarily have to be accomplished in one session. A session can be extended over several occasions.

Discussion is performed about what the class is supposed to do, what properties and methods it needs and what relations it has to other classes. Since UML is used, the step of going from model to class is very small.

In this step, the created or modified classes are being looked at and it is determined in which layer the class belong. See the modules and layers chapter of the architecture document [Johansson, 2003] for information. For a final view of the layers and which classes are contained in them, see chapter 8, "Classes"

In this step a check is performed to see if the class has fulfilled or helped out fulfilling any requirement in the requirements specification [Larsson, 2003].

Maybe the current classes needs a helper class or a new class must be added. Does the class do what it is supposed to do as discussed in section 3.2.4?

The current solution is discussed with the architecture guidelines in mind. Is the solution simple, robust and clean enough? If not, the solution has to be redesigned. If true, the solution is approved.

A new (sub)solution is proposed by looking at what was not good in the old one, according to the requirements check section 3.2.6 and discussion in 3.2.7.

Here, the whole design is scrutinized once more to make sure that all requirements are met, no flaws are present and that everything has been considered.

The design model is entered in our modeling tool. The modeling tool generates diagrams as well as code and comments to be used in the implementation phase. The diagrams can be found in chapter 8, "Classes".

During the design work described in section 3.2, "Method overview", the design group had the following two design patterns in mind which helped in achieving the architectural goals of simplicity and extensibility. See architecture document [Johansson, 2003] for details.

An alternative name for this design pattern could be "plug-in pattern" in the AudioJury case. It is used wherever there is a component (called subject in proxy design terminology) that we do not want to access immediately. The reason for this is simply that we want the component to be exchangeable.

The singleton design pattern is used when a class should be instanced only once for some reason. In our case we only want to work on a single project and test at a time to avoid concurrency problems. To enforce this we use the singleton design pattern.