TOC PREV NEXT INDEX

Put your logo here!


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

The desired method should be able to describe the following:
How calls in the system are made.
Relations between subsystems.
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.
The choice of OOD is good in other ways as well.
The implementation will be in java, an OO-language.
The UML-model that ArgoPrint will work on is OO.
The division into subsystems is simplified.
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.
The steps of the analysis are briefly explained below.
5.2.1.1 Object identification
Objects that the system consists of are identified.
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.
The steps of the design phase are the following.
The system design is created.
Infrastructure is specified.
Detailed design is developed.
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
In the detailed design all classes are carefully specified.
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:
Methods and parameters are specified.
Utilization of external sources (class libraries etc.) is specified.
Optimization is performed.
Support classes are introduced where needed.
Collaboration and sequence diagrams for events are created.
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.




Quadralay Corporation
http://www.webworks.com
Voice: (512) 719-3399
Fax: (512) 719-3606
sales@webworks.com
TOC PREV NEXT INDEX