5 Design Method

In this chapter there is a description of the object oriented design method chosen to use when designing ArgoPrint. We also describe the sequence of work during the design.

Notice that the architectural design doesn't follow every step in the specified method but since this document is supposed to be a link between the requirements specification and the detailed design, later steps in the design work should also be mentioned.

5.1 Chosen and discarded methods

In Development Manual [Vahlberg, 2000] it's stated that the only design method capable of the two desired properties is OOD. Other methods just don´t fit in the development of ArgoPrint.

Testing is made easier since the subsystems can be tested separately and together. There are also existing testing frameworks, see chapter 4.2.3.

We have chosen to use a OOD method called JOOM because it is more suited for the project's size than the standard OOD method.

5.2 JOOM

JOOM (Johan's Object Oriented Method) was constructed by Johan Fagerström, active at the Department of Computer and Information Science, LiTH. It is a generic OOD method developed to bring forth the core ideas of the OO approach.

JOOM consists of one phase for analysis and one for design. These phases will be briefly described below. For a more verbose depiction of the phases see "Objektorienterad analys och design" [Fagerström, 1995] and RUT 7.5 JOOM [Johansson, 2000].

5.2.1 Analysis phase

In this phase the problem core is identified and an understanding of the system's capabilities is created. An overview of the system's different parts' content is given and the dependencies between the objects and the system's dynamic properties are declared.

The phase consists of multiple steps and is iterative. This means that when all steps are completed you start over to look for missing objects and relations. The analysis is considered finished when no more objects or relations can be found.

5.2.1.1 Object identification

5.2.1.2 Object classification

The objects are grouped into classes depending on what properties they hold.

5.2.1.3 Class description

The purpose of the classes, what services they offer and their knowledge is described.

5.2.1.4 Description of Relations

The connections between classes are made clear with lines and symbols that define the connection type.

5.2.1.5 Testing

The requirements are meticulously checked against the requirements specification [Engström, 2003] and the stated use-cases are tested. During the tests new objects or missing requirements may be discovered. If this is the case, a new iteration must be performed. For further details on testing, see the test plan [Albertsson, 2003].

5.2.2 Design phase

This phase begins when the analysis phase ends. The classes' attributes and methods are decided, interfaces are defined for the parts of the system that communicate with one another and the formats of the files are decided.

5.2.2.1 Creation of the system design

The system design describes how the different parts of the system relate to the surroundings, human users as well as input and output units. Processes that in reality run in parallel must often do so in the system as well.

5.2.2.2 Infrastructure

the system's infrastructure is the communication between components, the format of stored files and the interface to ArgoUML.

5.2.2.3 Detailed design

Being forced to merge or split classes during the adaption is not uncommon.

Examples of tasks that are performed during the detailed design are the following:

Utilization of external sources (class libraries etc.) is specified.

For a more detailed description and sequence diagrams for ArgoPrint, see the design specification [Sidebäck, 2003]

The design work is completed when the detailed design has been completed and stays that way if no errors are discovered. If errors are discovered one is to return to the analysis phase.

5.2.3 Adaption of JOOM

Because JOOM is a generic design method it has to be adapted to each project.

Some parts of the system can and will be implemented before the design is completed for the entire system. This is possible for the ArgoPrint GUI, which has a very simple design, and this will lead to higher efficiency in the project group, since the implementation group can begin their work early.

Some testing can be performed before the final design is finished as well. This goes for testing of the XML-parser and the ArgoUML model. See chapter 6.4.1 for a brief description of testing.