4 Architectural Design Decisions

In this chapter, the architectural design decisions are stated and motivated.

4.1 Module identification

The modules have been identified to encapsulate solutions of well defined tasks. Each module and other system entity is described in more detail in chapter 6. Reasons for the identification of each of these entities are made clear by defining the task of the entity.

4.2 Development environment

4.2.1 Programming language

All parts of ArgoPrint will be written in Java. Since ArgoUML is written entirely in Java, using some other language to implement ArgoPrint would be unnecessarily complicated. It is also important that ArgoPrint doesn't require a different version of the JRE and JDK from the one of ArgoUML, and therefore Java2 version 1.3/1.4 will be used.

4.2.2 Coding environment

The coding environment that will be used when implementing ArgoPrint is the development tool Eclipse. It can be downloaded from www.eclipse.org and has a lot of benefits. One being that it's free and it`s also possible to run it on both UNIX and Windows systems. It features auto-completion of code and a structured view of projects similar to the one in Visual Studio. It also includes support for CVS.

4.2.3 Testing framework

To simplify testing of code, a testing framework called JUnit will be used. ArgoUML already uses this framework and it's natural to make ArgoPrint do so as well. JUnit is an open source project on SourceForge, developed by Erich Gamma and Kent Beck and can be studied in detail at the official website (www.junit.org).

4.2.4 CVS

Tigris (www.tigris.org), where the ArgoUML project is stored, provides a CVS. This CVS will be used for ArgoPrint as well.

4.3 Properties

During the development of the architecture, the following properties have always been kept in mind. They can seem a little loose but are handled further in chapter 6.4.

4.3.1 Testability

It's important to make the system testable. This is obtained by splitting the functionalities into several modules, and making sure every module is testable outside its' final environment.

4.3.2 Code reuseability

To be able to present the best system possible to the customer, parts or modules of the system that have already been developed should be used and not redeveloped. This will save a lot of time and let the project group concentrate on parts that have to be developed from scratch.

4.3.3 Extendability

In the future, one might not only want to fetch data from the ArgoUML model to the generated document, but also from other sources. An example of this could be an SQL database which contains information about the project which is to be documented.

4.3.4 General solution

The output of the system should not be specified by ArgoPrint but by the writer of the document template. Also the language in which to write the template files should not have any connection to ArgoUML whatsoever.

4.4 Xerces

We have decided to use Xerces to parse the templates. Xerces is an XML-parser written in Java. It is a project of the Apache Foundation (www.apache.org). Xerces is able to read an XML-document from a file and convert it into a Java representation and also provides algorithms for retrieval and modification of the information in the XML-document. The decision to use Xerces is based on several reasons:

It conforms to our goal of code reusability.

The Xerces parser is already used by ArgoPrint and thus it will not need to be delivered with ArgoPrint minimizing the size of the application.

It is widely used and well tested.

It is standards compliant, we can if necessary choose to replace it with another implementation of the same standards.