CHAPTER 4
SYSTEM DESIGN
4.0 OVERVIEW
After identified all the functional requirements for O/R mapping algorithm,
ORMapper and ORGraphic in previous chapter, this chapter will focus on the logical
and physical design specification that will act as a blueprint for implementation and
coding. Logic modeling for ORMapper and ORGraphic will be described. The
development tools (software and hardware), program specification, system
requirement specification and development methodology or plan will be documented.
4.1 SELECTION OF MAPPING PATTERN
As refer back to Table 2-2 in Section 2.7.1, there are some alternative O/R mapping
patterns. The most powerful mapping pattern is BLOB, which can map all the three
object’s relationships (namely composition, inheritance and association). BLOB is
“supported” by Microsoft Access™’s SQL data type (see Table 4-1) in the form of
OLE object. To avoid the complication dealing with byte level data manipulation
using binary files, BLOB is not used in this project. The next powerful pattern is
“foreign key” mapping which can map both composition and association, and
therefore will be used in this project for mapping composition and association.
For mapping inheritance, “one class one table” pattern is chosen. This is
because “one inheritance tree one table” pattern will result in large database file size
with many null entries in the table (especially if there are many private fields which
are not inherited by subclasses). Since we will be using Microsoft Access™ running
38
on desktop computer with relatively low processing speed as compared to database
server, large database file size may result in low performance. For “one inheritance
path one table” pattern, the mapping algorithm will be much more complicated and
lengthy and will cause longer processing time. Therefore, “one class one table” is the
best resolution among all the patterns for mapping inheritance in this project.
4.2 LOGICAL DESIGN OF ORMapper
Java™ will be used to develop the ORMapper class which can be reused by Java
program only. Java 2 Standard Edition Development Kit version 1.4 (J2SE SDK 1.4)
will be used for development. Microsoft Access™ that runs on desktop computer will
be used for the relational database (RDB).
For the storeObject(object) method of the ORMapper class, the reflection
classes (such as Field, Modifier) contained in a standard Java built-in package, i.e.
java.lang.reflect, will be used to inspect the makeup of any arbitrary object/class.
Appropriate classes from another standard Java built-in package, i.e. java.sql that
supports Java Database Connectivity (JDBC) API, will be used to write the “object”
to the relational database as well as to read the “object” in the relational database
when executing the storeObject() and retrivedObjects() method.
4.2.1 Why Java Is used For ORMapper
Java is a pure OOP language [2]. In contrast to other programming language (such as
C++ that is a hybrid of OOP and procedural programming), its clean and simple
hierarchical class structure and the absence of multiple inheritance (a mechanism that
allows one class to inherit from more than one superclass) greatly simplifies the
39
storage of objects into RDB such as Microsoft Access. Otherwise, other more
complicated database model such as network database (which may not be readily
available due to the resource constraint) will have to be used and this complicates the
initial development of ORMapper tool.
4.2.2 Why Microsoft Access™ Is Used As RDB
Microsoft Access, although is not a full-fledge DBMS for large-scale application, but
it is used in this project because it is easily obtained and simple for this initial O/R
mapping project.
4.2.3 O/R Mapping Algorithm
As mentioned in the chapter of literature review, the detail O/R mapping algorithm
used in this project can only be determined based on the development tools, OOP
language and the RDB used.
4.2.3.1 Structure Of The Access Database File (RDB) Generated By ORMapper
A hierarchy of Java class is used for the purpose of explanation and validation
through out this thesis. It has three levels of inheritance hierarchy as described in class
diagram below. Since the ORMapper class stores fields only but not methods, no
methods are defined in the classes below (but in actual application program, they may
have methods and this will not affect the functionality of ORMapper as can be seen in
next chapter).
40
Class
name
modifier
XSuper
Legend:
public int public_XSuper
private long private_XSuper
protected double protected_XSuper
Abstract
class
Class or inner
class
Data type
Super
public int public_Super
private int private_Super
protected int protected_Super
final protected char hh = 'E'
protected InnerClass3 in3
public long public_Inner3
protected byte protected_Inner3
private short private_Inner3
The field’s identifier is named
as modifier_className for
better understanding or
during validation. It can be
any valid Java identifier in
actual application, such as
aaa, studentName etc.
Reference data type
or inner class
(composition)
Sub1
Sub2
public int public_Sub1
static private int private_Sub1
final protected int protected_Sub1
final public String ps = "A constant public
string here"
private InnerClass1
public double public_Sub2
static private int private_Sub2
final public String ps = "A constant public
string here"
public float public_Inner1
protected char protected_Inner1
private String private_Inner1
private InnerClass1
public float public_Inner1
protected char protected_Inner1
private String private_Inner1
protected InnerClass2
public int public_Inner2
protected char protected_Inner2
private boolean private_Inner2
Fig. 4-1: A Class Diagram (Hierarchical Tree) For Explanation And Validation
41
The mapping algorithm is best to be explained by looking at the structure of the
relational database file generated by ORMapper as below. Figure 4.2 shows the
database file generated by ORMapper for the hierarchical tree as shown in figure 4.1
above.
Fig. 4-2: Structure Of Access Database File Generated By ORMapper
42
The following 3 tables must exists in the database generated by ORMapper:
1. Table hierarchy1 –
Fig. 4-3: Table hierarchy1
This table stores the inheritance hierarchical tree of the classes (except inner class
because in this project, inner object is only a reference data type and not present in the
class hierarchical tree).
This table always contains only one row of record. The first column is tree and is
the primary key. In fact, this column has no practical use (unless for future
enhancement which will consist of more than one row for multiple inheritance as
described in last chapter), but just to adhere to the requirement of having a primary
key for the table only. The remaining column names denote the classes available in
this inheritance tree, no matter they are abstract or non-abstract. The format of the
column name is either class0ClassName or abstract0ClassName where ClassName
can be any names depend on the Java application. A zero is used as a separator
between class type and class name because in Java, no class name can begin with
digit. The value of the cell denotes the hierarchical level in the tree. The column/class
with the cell value 0 is the root of the tree. For the other column, the cell contains the
name of its direct superclass. There is only one direct superclass for each class
because this project does not consider multiple inheritance which is not supported by
Java.
43
2. Table OID –
Fig. 4-4: Table OID
This table ensures that all objects have unique object ID (OID) and also for better
object management in future enhancement (as described in last chapter).
This is the table that stores the OID for all objects except inner objects. There are
only two columns. The first column OID is the primary key which actually stores the
object ID. The second column is the class name that the object belongs to. Note that
the class in this table must not be abstract class because abstract class cannot have
instances or objects.
3. Table IOID –
Fig. 4-5: Table IOID
44
Similar to table OID but it stores the inner object ID (IOID) and class name of the
inner objects or the reference data type. The IOID will be the foreign key in table
class0 or abstract0 (as describe next) to implement the composition concept in OOP.
The remaining tables in the database are used to store the objects based on
“one-class-one-table” (to map inheritance) and “foreign key” (to map composition)
O/R mapping pattern:1. Table with name begins with class0 as below:-
Fig. 4-6: Table For Non-abstract Class
This means that this is an instantiable class (non-abstract class). The primary key for
this table is OID which store the object ID, and the remaining columns are the data
value or fields for each object. The format of the column name is:
modifier_dataType0identifier. The reason of using a zero as separator between
dataType and identifier, is also because in Java, no identifier name can start with
digit. For example, if there is a column name private_int0age, meaning that the class
data value’s is of private modifier, data type is integer and the identifier name is
“age”. An extra keyword final_ will prefix the column name if it is an instance
constant. Each row represents one object and the value of the cell will be the value of
the class data value for each field.
45
For reference data type, the data type is inner (such as private_inner0Inner3).
This column will store the foreign key IOID that can be found in table IOID and table
name that prefixed with inner0 as described later.
2. Table with name begins with abstract0 as below:-
Fig. 4-7: Table For Abstract Class
This means that this is an abstract class. The column naming convention is also same
as table class0. It may also contains reference data type similar to table class0.
3. Table with name begins with inner0 as below:
Fig. 4-8: Table For Inner Class
This is the table that stores the inner object or the value of reference data type of its
container objects. The column IOID is the foreign key in the container object/table,
either table class0 or abstract0.
No relationship is defined among the table in the database because the
relationship among the class (or table) is implemented by the program logic in
ORMapper.java and ORGraphic through the interpretation of the data stored in table
46
OID, IOID and hierarchy1. Therefore, this Access file generated by ORMapper shall
not be opened and modified with Microsoft Access otherwise the user may destroy
the object’s semantic relationship among the tables.
Note that individual table is used for each non-abstract class, abstract class and
inner class to store the declared field only. The data of the field inherited from
superclass is not stored in the table of a particular class. This is in accordance to the
notion of “one class one table” O/R mapping pattern.
A foreign key (i.e. IOID) is used to link a class to its inner-class table, in
accordance to “foreign key” O/R mapping algorithm.
4.2.3.2 Logic Modeling For ORMapper Using Structure English
This structure English describes how the ORMapper can walk-through the object
(being created by the OOP application), extract the access modifier, data type,
identifier and value of each fields (including inner-class) declared by the object’s
class, find out its superclass and inherited fields, and store them into relational
database. This will be used as a guide for the coding of storeObject() method.
START
When the storeObject(obj) method is called together with the parameter obj (i.e. an
object of any arbitrary class to be stored into database), its class name is determined.
Add a new record in table OID (Fig. 4-4) with a unique object ID and its class name.
Extract the information of each field for this object, i.e. access modifier, data type and
identifier.
Check the relational database if the table class0ClassName (Fig. 4-6) exists.
Continue to (01).
47
(01)
BEGIN IF
If table class0ClassName exists, ensure all the fields have the corresponding
column in the table. Otherwise, insert new column in the table. This is
because even if the table exists, it could be created by previous storeObject()
method call that store a subclass object which doesn’t inherits private field
and hence that column is not exists yet. RETURN
ELSE
Create table class0ClassName with primary key OID, and corresponding
columns for each field declared in that class. The format of the column name
is as described earlier (i.e. modifier_dataType0identifier), and the SQL data
type is as described in section 4-6. RETURN
END IF
Stores the value of each field to the respective columns in table class0ClassName.
BEGIN IF
If the field is an inner-class, the value stored in the column is the inner-object
ID, i.e. IOID. Add a new record in table IOID (Fig. 4-5) with a unique object ID
and the inner-class name. Then repeat (01) to check if the table
inner0InnerClassName (Fig. 4-8) exists but this time no further inner-class
nor superclass.
END IF
Check the superclass of the object.
WHILE still has higher level of user-defined superclass
BEGIN IF
If there is a user-defined superclass, then repeat (01), but this time
ignores all the field with access modifier private (because private
class member is not inherited by subclass).
Read table hierarchy1 (Fig. 4-3). If column class0ClassName or
abstract0ClassName not exists, add a column class0ClassName or
abstract0ClassName with cell value SuperClassName.
ELSE
Else if there is no more user-defined superclass and if column
class0ClassName not exists, add a column class0ClassName or
abstract0ClassName in table hierarchy1 with cell value 0 (zero
indicate no superclass, i.e. it is the root of the inheritance hierarchy).
END IF
END WHILE
END
48
Explanation on the reversed operation of O/R mapping algorithm (i.e. how to
read “objects” from the database and recreate them in retrieveObjects() method) is
tightly related to the Java programming code, and hence it will be described in next
chapter. However, the next section will describe how the ORGraphic retrieves the
“objects” in relational database, interprets them and display them graphically on
screen, which is in fact similar to retrieveObjects() method in term of logical flow.
4.3 PHYSICAL DESIGN OF ORGraphic
ORGraphic will be developed by using Microsoft Visual Basic™ 6.0. It is selected
because of its simplicity of event-driven programming and built-in library that can
create the hierarchical tree graphic easily.
4.3.1 Graphical User Interface Of ORGraphic
There is only one main interface or output screen once the ORGraphic program runs.
It consists of a left frame showing the class hierarchy and a right frame showing the
fields of each object for the selected class on the left frame. The user shall able to
expand or collapse some branches in the hierarchical tree by clicking the + or –
symbol. The fields for the selected object shall be displayed in the order of declared
fields, and followed by inherited fields from first level of superclass until the highest
level of superclass. Users can select another RDB file by using the File >Open menu.
Besides, there are other dialogue and message boxes which will appear upon certain
events as described in Appendix G (user manual).
49
File
About
Class Hierarchy
Object’s Fields
Selected class is
highlighted
Animal
(abstract)
Reptile object: 1 of 4:
Next
Previous
(+)Reptile
Declared fields:
protected int MaxTailLength=5
final public WeightOfEgg = 2.5
(-) Bird
SeaBird
Inherited fields (from Animal)
protected string Name = “lizard”
protected string Color = “grey”
protected inner1:
public float a = 32.4
private int b = 142
(+)Mammal
Fields for inner
class/object or
reference data type
Fig. 4-9: ORGraphic Interface Physical Design
4.4 LOGICAL DESIGN OF ORGraphic
Logic modeling for ORGraphic is described using structure English. As a reminder to
previous discussion, each class may have one or more superclass (but only one
immediate superclass because of single inheritance), and/or one or more inner-class.
The superclass may also has one or more inner-class. Inner-class has no superclass
nor further inner-class.
START
Upon launching of ORGraphic.exe or when user selects pull-down menu File >
Open, an Open File dialogue box appears for user to select a file.
(00)
BEGIN IF
50
If the selected Access files does not contains a table called hierarchy1, then display
an error message “This is not a valid file for this application, please choose another
Microsoft Access database file that created by ORMapper”
Else
Read the column names in table hierarchy1 (remember that there will be only one
record in this table). Then built the hierarchical tree in the left frame according to the
value of the cells (i.e. superclass names) for each column/class as described earlier.
END IF
After the left frame is built with the hierarchical tree, the right frame only display a message
“Please choose a non-abstract class to view the objects of that class”
(01)
After the user has selected a class or node from left frame’s hierarchical tree:
BEGIN IF
If the selected class is an abstract class, display error message “The
selected class is an abstract class. No objects for abstract class.”
Else
if the class is empty (no record in table OID), display error message
“The selected class is empty or without objects.”
Else
Read the class name for the selected class, then read the table OID to find out the
OID for all objects of the selected class. Store these OID values into an array or
recordset.
Then read table named class0ClassName.
END IF
(02)
WHILE still has next record (or next element/object in the OID array or recordset) after user
clicked NEXT button (previous record if user clicks PREVIOUS button)
WHILE still has next column
Read the column name, extract the modifier, data type and identifier from the
column name with format modifier_dataType0identifier.
IF
DataType = “inner”, read the value of the cell which is the inner object ID
(IOID), go to table IOID to search the class name of the inner class. Then
read the table inner0InnerClassName to search for the record for the inner
objects with that IOID.
51
Then, read the column name, extract the modifier, data type and identifier
from the column name with format modifier_dataType_identifier.
Goto (03).
ELSE
Goto (03)
END WHILE
END WHILE
(03)
WHILE still has higher level of user-defined superclass
Display the right frame data by showing the extracted modifier, data type and
identifier and the value of the field that stored in the cell. Then from the hierarchical
tree, search the direct superclass of the currently selected class. Read that
superclass table and search for the record with the same OID. Repeat (02) but this
time ignores the column with null entry (because they are private field which is not
inherited by subclass). Keep repeating (03) until no more superclass. RETURN.
END WHILE
BEGIN IF
If user select another class from left frame, goto (01).
Else
If user select menu File > Open again, repeat (00).
Else
If user select menu File > Exit, quit the application.
END IF
END
For example, an instance of class Super (which has one superclass (XSuper) and one
inner-class (Inner3) ) requires the searching procedure as described in Figure 4-10 to
get all the data value, whether declared, inherited or reference data type.
52
Fig. 4-10: Flowchart To Get All Data Value Of A Super Object
53
4.5 MAPPING OF JAVA AND SQL DATA TYPES
As mentioned in the literature review, discussion on mapping the data types of OOP
language to SQL data type in RDBMS is delayed to this chapter because it is related
to the OOP language and RDBMS being used. Since it has been determined to used
Java and Microsoft Access, the mapping is determined by comparing the Java data
type (as in Table 3-1) and SQL data types supported by Microsoft Access as below
(extracted from Microsoft Access 2000 help file):Setting
Type of data
Size or space occupied
Text
Text or combinations of text, symbols Up to 255 characters.
and numbers
Memo
Lengthy text
Up to 65,535 characters
Byte
Stores numbers from 0 to 255 (no
fractions and negative value)
1 byte
Integer or int
Stores numbers from –32,768 to
32,767 (no fractions)
2 bytes
Long
Stores numbers from –2,147,483,648 4 bytes
to 2,147,483,647 (no fractions)
Single
Stores numbers from
–3.402823E38 to
–1.401298E–45 for negative values
and from
1.401298E–45 to 3.402823E38 for
positive values.
Double
8 bytes
Stores numbers from
–1.79769313486231E308 to
–4.94065645841247E–324 for
negative values and from
1.79769313486231E308 to
4.94065645841247E–324 for positive
values.
Decimal
Stores numbers from –10E28-1
through 10E28 -1
AutoNumber A unique sequential (incremented by
1) number or random number
assigned by Microsoft Access
whenever a new record is added to a
table.
54
4 bytes
12 bytes
4 bytes
1 bit
True/False
Yes and No values and fields that
contain only one of two values
(Yes/No, True/False, or On/Off).
OLE object
An object (such as a Microsoft Excel Up to 1 gigabyte (limited by
spreadsheet, a Microsoft Word
available disk)
document, graphics, sounds, or other
binary data) linked to or embedded in
a Microsoft Access table.
Table 4-1: Data Type Supported By Microsoft Access
The selected Access data types must able to store the maximum and minimum
value of Java data type but not to go over-board in order to conserve memory space.
After comparison between Table 3-1 and Table 4-1, the data type mapping is as
below:Java data types
byte
Microsoft Access data types
Integer
Microsoft Jet SQL data types
SHORT
short
Integer
SHORT
int
Long
LONG or INT or INTEGER
long
Long*
LONG or INT or INTEGER
float
Single
SINGLE
double
Double
NUMBER or DOUBLE
boolean
True/False
BIT
char
Text with field size=1
CHAR(1)
String
Memo
MEMO
Table 4-2: Data Type Mapping From Java To Access
*Microsoft Access cannot support the full range of value for Java long data types.
Note that in Microsoft Jet SQL server, the keyword used to specify the data
type in the SQL statement in the program may differ from Microsoft Access as shown
in the third column in table above.
55
4.6 PROGRAM DEVELOPMENT METHODOLOGY
Incremental development strategy will be employed in developing the ORMapper
class and ORGraphic graphical user-interface, i.e. to begin from a simple and limited
version step-by-step until final version.
Below are the stages and tasks for each stage:a. Stage 1
In Stage 1, development begins from the ORMapper class to retrieve and display the
data value of the objects created in the application program as per the following
tasks:i. Create the initial ORMapper class that can retrieve and display the instance
data value (or field) of primitive data type of any object on MS-DOS prompt
screen. The reflection classes (such as Field, Modifier) contained in standard
Java built-in package, i.e. java.lang.reflect will be used to inspect the makeup
of any arbitrary object/class [2] [3].
ii. Enhance the ORMapper class so that it can display the data value of reference
data type or the fields in the inner-class.
iii. Enhance the ORMapper class so that it can display the inherited data value
from all its user-defined superclass.
iv. Modify the ORMapper class into an instantiable class that can be reused (by
composition i.e. class in another class) in any other objects of any other
classes.
v. Validation to ensure that the code will not break in any complex class
inheritance hierarchical structure, such as a class with a few level of superclass
56
and which may in turn has its own inner-class. A test case will be developed to
validate the code.
b. Stage 2
Stage 1 completes the initial ORMapper class version that just displays the value of
the fields of the objects on MS-DOS prompt screen. The next tasks will be the actual
coding on the object storage and retrieval to/from the relational database:vi. Enhance the ORMapper class so that it can store the instance data value to a
relational database in Microsoft Access, i.e. to write the objects into relational
database. Appropriate classes from standard Java built-in package, i.e. java.sql
that support Java Database Connectivity (JDBC) API [2], will be used.
Although the O/R mapping algorithm is basically based on “one class one
table” and “foreign key” O/R mapping pattern, but it will only be implemented
and finalised at this stage of ORMapper class development because of the
consideration and limitation of the SQL capability supported by Microsoft
Access and the JDBC-ODBC bridge driver. This task completes the coding for
method storeObject().
vii. Enhance the ORMapper class so that it can retrieve the value of the instance
data value from the RDB (i.e. the reversed operation), recreate the objects and
initialise its instance data value, i.e. to read the “objects” from the RDB. This
task completes the coding for method retrieveObjects().
viii. Create a simple end user application in Java to demonstrate the use of
ORMapper class as a tool or interface between the end user application and
RDB, i.e. to store/read objects from an OOP program to/from RDB.
57
c. Stage 3
After successfully generated the RDB using ORMapper class, ORGraphic will be
developed using Visual Basic 6 as below:ix. Create the ORGraphic user-interface that can retrieve and display the
“objects” and their instance data value of the “objects” from RDB (generated
by ORMapper) in an object-oriented look-and-feel. The inheritance
hierarchical tree on the left frame will be created, then follow by the right
frame that displays the objects’ fields.
4.7 CONCLUSION
It has been shown logically and technically that the O/R mapping algorithm is
workable and can be implemented with the available development tools. Coding can
be started next based on the above plan and specification. The coding, results and
validation of the program at the end of each stage will be explained in next chapter.
58