DETAILED DESIGN DOCUMENT

TECHSOFT
Mohammad Sadoghi
Nitakulan Maheswaren
Champika Fernando
Mansoor Siddiqui

Table of Contents
Part 1: Design Overview . 3
Architecture ... 3
Technologies .... 4
Part 2: Back-End .. 5
Database Tables... 5
Entity Classes ... 5
Data Access Objects. 5
Controller Data Access Objects. 5
Connection Pooling.. 6
Generic Programming.. 7
Part 3: Application Logic........ 9
Controller Classes. 9
Tools Classes.... 9
User Session Class...... 9
Part 4: Front-End10
View/Dialog Classes..... 10
RCP Classes .... 10
Part 5: Exception Handling
TSException... 11
Part 5: Design Rationale
Architecture Rationale...... 12
Coupling and Cohesion ... 12

Appendix A: Database Detail Design......13

Appendix B: UML Package Diagram.......14
Appendix C: UML Class Diagram............15

Part 1: Design Overview

Architecture
TIQTrac will be structured as a two-tier application. Rather than performing the
business logic on an application server (as is done in a three-tier architecture), the
application logic will be packaged with the front-end, and installed as a standalone
application on all client machines. The client application will be able to connect and
interact with a database (local or remote), where the application data will be stored.
We will adhere to the following design principles:
Abstraction: Generalize or simplify design.
Information Hiding: Only expose relevant information in classes/components.
Modularity: Each component should be replaceable and testable by itself.
Functional Independence (high cohesion, low coupling): Maximize functionality
each component and minimize interdependence between components. In most cases
we have achieved data cohesion using the appropriate interfaces and abstract classes.
According to the conventions of the 2-tier architecture, our software
implementation will consist of a client that has all the application logic and a thin server
that only contains the back-end MySQL database and artifact files. An advantage to this
design is that the client does not have to wait to download the user interface as in many
web-based applications, which can make a big difference in the case of applications
with many different views. The only information that needs to be transferred between
the client and the server is the application data itself. This architecture will simplify the
development and maintenance phases as well. In addition, because we are using
Eclipses Rich Client Platform (RCP) architecture to develop our client application, it not
only has Javas cross platform compatibility, but also the efficiency of a native
application. Thus our software is able to run on any platform with the look, feel and
efficiency of a native application, and at the same time provide a user-friendly
experience by reducing wait-times.
Our system will be organized in terms of a closed layered format. It will consist of
a front-end GUI interface, a middle layer containing the business logic and control
functions and a back-end for data storage.
Front-end
(User Interface)
Business Logic
Back-end
(Database)

Technologies
The application will be implemented using J2SE v1.5.0 (5.0). It will be developed
using IBM Eclipse v3.1 and will utilize Eclipse RCP (Rich Client Platform) for the
applications GUI components. For the applications back-end, MySQL 5.0 and JDBC
3.1 will be used. In addition we are using the many tools in forms of eclipse plug-in to
help use improve development time. These tools allow us to rapidly design, develop and
test our system.
Here is the list of eclipse plug-in that we have used so far:

CVS Repository
o To synchronize our files between team members
Code Analysis Plug-in 1.2.0 (CAP --- JDepend 2)
o To analyze our code dependencies and instability
Eclipse CheckStyle Plug-in 4.0.91
o To follow Standard Java Coding Style (i.e.: magic numbers)
Eclipse Modeling Framework
o To design our classes
Graphical Editing Framework SDK 3.1.1 (Visual Editor)
o To create our front-end GUI, we used Visual editor strictly to create our all
of front-end interfaces
UML Plug-in
o To design our classes
JUnit
o To perform Unit, Integration and System Testing

Part 2: Back-End
Database Tables
Tables within the database can be divided into two categories: entity tables and
lookup tables. An entity table represents some business entity such as a project, a TIQ
or a user. In addition the entity tables hold references to other Entity object if there
contains any Foreign Keys. Finally, lookup tables store values that are expected to
remain static over the running of the application. For example, the TIQ_STATE table
stores a list of all possible TIQ states; tables such as this one are read, but never written
to during runtime. The rest of this section concerns itself mostly with entity tables.
Entity Classes
Entity tables within the underlying database are represented within the
application by entity classes. An entity class generally contains variables for the
attributes of the table that it represents, as well as getter and setter methods for those
variables. Attributes that are common to all tables (primary key, last modified date, etc.)
will be externalized to a class called DatabaseObject, which acts as a super class to all
entity classes and provides an interface to other classes. DatabaseObject also inherits
our custom cloneable interface, therefore every entity classes is also cloneable.
Data Access Objects
Every entity object has a corresponding DAO (Data Access Object). DAO
classes contain methods that perform database operations which use or return an
instance of some entity class (or an array of entity objects in the case of queries that
return more than one result). Each DAO extends the DataAccessObject class, which
contains abstract methods for the most basic database operations (insert, select,
update and remove). More advanced operations are performed using CDAOs (more
on this later) DAOs do not perform any complex querying because each DAO is
meant to provide a simple one-to-one mapping between an entity and a database table.
This decreases the amount of application-specific logic that these classes contain,
causing DAO objects to have high cohesion.
In the case of query operations, the DAO performs the query, then it instantiates
whatever entity objects it needs to return and initializes them based on the query result
set. For operations that persist some changes to the database, the DAO accepts some
fully-initialized entity object and constructs a create or update SQL statement using the
data contained in the entity object, then executes it.
Controller Data Access Object
These classes perform database operations that involve more complex queries
than simple one-to-one table-to-entity mappings. The superclass for all Controller Data
Access Objects (CDAO's) is the ControllerDataAccessObject class. These classes

follow the same design pattern as the normal Data Access Object described above,
however, rather than providing a one-to-one mapping with some entity, each CDAO has
a one-to-one mapping with each controller class in the application layer.
Connection Pooling
For improved performance, connection pooling will be used so that a database
connection does not have to be created for each DAO operation that is executed.
Instead, the DAO will simply grab an existing connection from the connection pool. This
logic will be implemented within the DataAccessObject class since it is common
functionality that applies to all DAOs.

Generic Programming
Another distinct feature of our backend is that we are taking full advantage of
Java 1.5s new generic programming capabilities. All of our backend classes are
generic which allow us to improve our coding design and efficiency. This should
provide us with the advantage of being able to hand any entity class and any DAO class
to some method, for example, without having to verify whether the DAO class is
compatible with the entity class.
Here is snapshot our some our generic code. The class that extends this must
be of type DatabaseObject. More importantly the return type of clone object is also a
DatabaseObject. This helps enforce low coupling between classes:
public interface Cloneable<Entity extends DatabaseObject>
extends java.lang.Cloneable {
public Entity cloneEntity();
}

Also, note the way the DatabaseObject implements the cloneable interface:
public abstract class DatabaseObject<Entity extends
DatabaseObject> implements Cloneable<Entity> {

This is how we create our entity classes: it extends DatabaseObject of type Tiq
and the cloneable method also returns a Tiq. Returning of type Tiq would have not been
possible with using pure OO design. In OO design we had to return DatabaseObject
instead.
public class Tiq extends DatabaseObject<Tiq> {
.
public Tiq cloneEntity() {
.
}
}

This is how we create an abstract DataAccessObject which specialize each method.

Each abstract method accept as parameter an Object that inherits a DatabaseObject
public abstract class DataAccessObject<Entity extends
DatabaseObject>{
.
public abstract int insert(Entity entity) ;
.
}

This is how we are creating specific DAO object for each entity. You can see that
TiqDAO is implementing DataAccessObject of type Tiq. Therefore, in the header
definition of our insert we would have Tiq. We could not have achieved this using just
OO design. The alternative was that insert method accept DatabaseObject and we had
to cast to Tiq in order to have access to Tiq specific method that are not in the
DatabaseObject.
public class TiqDAO extends DataAccessObject<Tiq>{

synchronized public int insert(Tiq tiq) {

Another important feature of backend design is that all of our classes is of type
Singleton reference, therefore only one of copy of the class exists in the java virtual
machine. Moreover, if you look closely at the definition of the methods, they are thread
safe, indicated by synchronized keyword.

Part 3: Application Logic

Controller Classes
The application logic will be implemented within controller classes, each of which
provides static methods for some major component of TIQTrac. For example, there will
be a controller class for the dashboard view, a controller class for the staff tracker, and
so on. These classes are responsible for the data processing that occurs between the
GUI and the back-end. It uses entity classes and DAO objects to communicate with the
database. Each method in some given controller class performs an action that relates
to its core purpose.
Tools Classes
We have a set of packages under the tools classes: TSException and Log
packages. The TSException package described in further detail in Part 5. The other
set of packages under the Tools section is the Log packages, which allow us to audit
every user action. This is not part Phase A requirement, therefore, this is add-on
feature that we felt would be very beneficial to our system.
Session Classes
This package creates a session for the current user of the system. Therefore,
once the user logs into our system, a Session which contains all the detail information of
the particular user is created. Again, this was not part of the requirement for Phase A,
but it is for the security components (add-on feature) and also is used in the
applications logging components (recording username and timestamp).

Part 4: Front-End
View / Dialog Classes
Each screen within the application has a corresponding View or dialog class
(though similar screens may be grouped together into a single form class, if possible).
Form classes generally consist of variables for the fields that are contained within that
screen. All screens that are related to some major component of the application will
utilize the same controller class. For example, all dashboard screens will utilize the
dashboard controller class (though they may call different methods to perform different
related actions). These classes are created using the Eclipse Visual Editor plug-in which
follows the best practices standard in the creating GUI components.
RCP Classes
The flow of moving between screens is managed from within the RCP code itself.
This eliminates the need for a controller class that manages the application flow. Most
of these classes are very generic and contains the metadata for the each of view and
plug-ins.

10

Part 5: Exception Handling

The TSException Class
TSException is the general exception class used by TIQTrac. Subclasses may
be derived from it, though the base class itself should prove sufficient in most cases.
This exception is thrown from within the database layer of the application, as well as
within the logic layer, and is expected to be caught within the layer above the layer from
which it is thrown.
This provides the benefit of having each layer not have to worry about the
particular exceptions that the layer below it encounters in its logic. For example if we
receive an SQLException in the back-end, then we create an appropriate TSException
and pass that to the front-end. Therefore the front-end is not bounded the java.sql
classes, thus providing easier maintainability and re-usability.
All instances of the TSException class must contain a user-friendly error
message that may be displayed to screen to inform the user about the error that has
occurred. This ensures that any exceptions that are thrown all the way to the front-end
will have a ready-to-display error message within them.

11

Part 6: Design Rationale

Architecture Rationale
Two-tier architecture was decided upon because it allows the logic to be
performed on the client side, rather than having the logic all performed on an application
server. This is advantageous for several reasons. First of all, if all of the logic were
performed in a single place, this could place quite a load on the application server
during periods of heavy use. Secondly, the lack of an application server means that no
hardware has to be dedicated to performing the business logic (since it will be
performed no the client machines).
Finally, and most importantly, configuring a web/application server is not a simple
task. Given the tight time constraints of the project, it is preferred that no teammate
spends unnecessary time configuring a web server. Similarly, if any clients purchase
the application, a separate web/application server would have to be installed for each
client, and this may be a tedious, time-consuming process.
Developing TIQTrac as a standalone application means that these problems can
be avoided (saving both time and resources) without sacrificing any of the required
functionality. Furthermore, by using some external GUI library (instead of using web
interfaces), we also gain the advantage of having advanced GUI features such as tabs
or collapsible/expandable trees at our disposal.
Coupling and Cohesion
All design decisions were made primarily with the goal of enforcing low coupling
and high cohesion kept in mind. The entity classes were going to be designed such that
they would provide methods for basic database operations (namely create, select, and
update), but this idea was discarded for two reasons. First of all, entity classes should
be responsible only for encapsulating the information of whatever business object it
represents. By giving entity classes methods to perform database operations, their core
purpose becomes blurred because they are doing two tasks which are related only in
the sense that one task must be performed before the other (procedural cohesion). (For
example, the data fields within an entity class have to be initialized before a create or
update operation is performed.)
The use of DAO classes resolves this problem, providing high cohesion (since
each module has a clear purpose) and low coupling (the controller class simply needs
to import the entity class and the DAO, and to use their methods, resulting in import
coupling).

12