5 Design MethodIn 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 methodsIn 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 JOOMJOOM (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 phaseIn 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.
126.96.36.199 Object identification
188.8.131.52 Object classification
184.108.40.206 Class description
220.127.116.11 Description of RelationsThe connections between classes are made clear with lines and symbols that define the connection type.
18.104.22.168 TestingThe 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 phaseThis 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.
22.214.171.124 Creation of the system designThe 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.
126.96.36.199 Infrastructurethe system's infrastructure is the communication between components, the format of stored files and the interface to ArgoUML.
188.8.131.52 Detailed designFor 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 JOOMSome 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.
Voice: (512) 719-3399
Fax: (512) 719-3606