Chapter 4          Design of the Framework for Object-Relational

                                            Mapping

 

Previous

Table of Contents

Next

 

4.0 Introduction

When a software system or any other type of system is being developed it is important to use a methodology to design it (Schach, 1997).  This will help in achieving the best design for the system and result in improved performance and end user satisfaction.  The system to be designed and developed will be implemented using Java, an object oriented language, thus it is appropriate that an object oriented methodology is selected to design it which covers the entire life-cycle of the project.

 

Traditional software development methodologies placed the emphasis on how things were to be done and proved to be costly in the latter stages of the project life-cycle.  In contrast to this, object oriented methodologies focus on the building blocks or objects (Williamson & Moran, 1997) that make up the system, placing the emphasis on the earlier stages of analysis and design (Rumbaugh et al., 1991).  By thinking first about the objects in a system, this leads naturally to designing their behaviour and function.

 

The life-cycle of an iterative object oriented methodology is shown in fig 4.1.  While it may appear similar to the traditional waterfall model (Schach, 1997) there are important differences.  The object oriented approach is best suited to implementing an iterative design process through the complete life-cycle of the system.  This enables problems encountered to be dealt with effectively by repeating an earlier stage with the particular problem in mind, preventing a snowball effect during the latter stages.

 

There are many object oriented methodologies being used to develop object oriented systems, examples are; Fusion (Coleman et al., 1994), Booch (Booch, 1994) and the Coad/Yourdon approach (Coad & Yourdon, 1991).  In this project the Object Modelling Technique (OMT) is used.  OMT is one of the more popular object oriented design  methodologies being used world-wide (Chonoles & Quatrani,1996).

 

 

4.1 The Object Management Technique

OMT was first introduced and described by Rumbaugh et al. in 1991, it is mainly used by object oriented system and software developers as it provides support for full life-cycle development.  OMT incorporates the best techniques of other methodologies such as Booch and Jacobsen (Carmichle, 1994).  The main stages during OMT is analysis, object design, system design, implementation and testing as shown in fig4.1.

 

 

OMT uses three models to describe the system being created.  The three models used to describe the system are;                     

·      The Object model.

·      The Dynamic model.

·      The Functional model.

The three models are initially developed during the analysis phase of the system and are subsequently used and added to during all stages of development.  This three pronged approach to application design and development is important as each model enables the designer to view the system from different perspectives.  The object model identifies and describes the objects used to build the system, the dynamic model represents the interactions between the various objects, and the functional model identifies the data transformations of the system.

 

Chonoles & Quatrani (1996) describes OMT as a set of activities that need to be performed to construct a system.  The activities can be performed in several different orders as well as simultaneously, depending on the needs of the project at hand.  When the activities are performed there is a considerable amount of overlap and iteration.  When developing this project, a modified version of them will be performed in an iterative fashion.  The first stage of the software development process is analysis.

 

4.2 Analysis

During analysis a model of the real world system is developed, according to Rumbaugh et al. (1991);

“The analysis model serves several purposes: it clarifies the requirements, it provides a basis for agreement between the software requester and the software developer, and it becomes a framework for later design and implementation”

Analysis forms the basis of the OMT specification which serves the same function as the plans of a house i.e. it provides a clear illustration of what work must be done.  But it does not specify how the builder will carry out the work.  The output of analysis is a document containing a written problem statement and diagrammatic representations of the object model, the dynamic model and the functional model.  The contents of the analysis document is not written in stone as it is intended that both the problem statement and the three models of the system will change and be added to as work progresses.

 

4.2.1 The Object model

The main model of the system is the object model, as it will identify all the objects that will make up the system, their attributes and relationships with other objects.  Derr (1995) identifies guidelines that are followed when developing an object model, they have been modified slightly to suit the scale of this project as follows.

1.   Develop a problem statement.

2.   Identify the object classes and their attributes and associations.

3.      Discard unnecessary and incorrect classes, attributes and associations.

4.      Use inheritance to share common structure.

 

The first stage of any project is conceptualisation (Chonoles & Quatrani, 1996).  Conceptualisation is the process of deriving the idea for the system along with the requirements.  When an idea is generated a feasibility study is often carried out to ensure the idea is justifiable and that the proposed system will be beneficial to the organisation and financially feasible.  The output of conceptualisation is a problem statement.  Conceptualisation is the first stage of analysis.

 

4.2.1.1 Problem Statement

The information required for drafting a problem statement is normally obtained from; company literature, interviews and observation.  The development of a problem statement for this project was based on the issues identified in chapter three.  An important consideration when developing a problem statement is the end user.  This is of vital importance to the accuracy and usefulness of the problem statement being written.  Various authors highlight this and stress the importance of asking questions regarding the user’s working environment, familiarity and experience with computers and their attitudes towards the proposed system (Avison & Fitzgerald, 1995; Kendall & Kendall, 1995; Lee, 1993).

 

This system is being designed for software developers of varying experience in developing Java-database applications.  The end user of the system will be a Java software developer with varying experience in object-oriented programming.  The system will cater for both advanced and novice users as the repetitive low level tasks such as communicating with the database will have been achieved.  This should generate a positive attitude among the users and promote acceptance of the system.

 

The system can be used to develop database applications that operate across an Intranet or the Internet and as a result will be implemented as part of either a two-tier or three-tier solution.

 

The basic idea behind the system is to provide an easier method for Java programmers to access a relational database and perform the necessary queries in the object domain rather than having to use the JDBC API in the relational domain.  To achieve this, a framework for object relational mapping will be developed, which will provide a higher level abstraction on top of the JDBC API.

 

It is important to note that the project is a prototype and will provide a subset of the functionality offered by JDBC.  It is hoped though that it may provide the basis for which further work can be carried out in the future to develop a fully functional system.  A second important point is that in order to fully understand the needs of the programmer, the needs of  the end user must be understood.  To facilitate this a simple database application is designed in parallel with the framework.  This is to enable the framework to be tested and to evaluate its usefulness to the programmer.  Based on the issues raised in chapter three and from a thorough understanding of  a database programmer’s needs the following problem statement has been derived:

 

An object-oriented framework based on JDBC is required which will enable a Java programmer to write database applications more easily than by implementing JDBC.  The framework will enable the programmer to operate directly with objects, while the methods will provide functionality such as opening connections to a database, retrieving and viewing stored information, updating existing information and data definition tasks.  The user needs to be able to specify parameters such as the database to be connected to, a username, a password, query details and optionally a database driver.  When using the framework for object relational mapping it is desirable that the user be able to carry out all of the above tasks without having to issue any SQL statements at all.  Tasks such as creating new objects and storing their attributes for the first time should be completely automated.  When a new object is stored for the first time a new table should be created which will map directly to the attributes of the object.  An object must be easily stored within the database or retrieved from it.  It must be possible to search for a particular object based on search criteria, and to display and manipulate the retrieved objects.  It must also be possible to update the stored attributes of an object.  This must all be possible using object oriented semantics and operations.  It is assumed that the information contained within an object will map directly to a database table which is in third normal form.

 

4.2.1.2 Identifying object classes

Object classes can be derived from the noun/noun phrases in the problem statement (Abbott, 1983), or by examining the application domain and from general knowledge.  Other classes may also be found during the design phase when considering how to implement a solution to the problem at hand.  After examining the candidate classes derived from the problem statement and removing classes that are redundant, irrelevant, vague; are object attributes; are operations or implementation constraints; or because they reflect roles the following object’s classes remain:

            Database Connection.                           Attribute String.

            Database Resutlset.                              Attribute Int.

            SQL Statement.                                    Attribute Double.

            Mapping.

The next step that is normally carried out is to create a data dictionary, but the size of this system did not justify one.

 

4.2.1.3 Identify associations between classes

The next stage is to add associations between the classes.  Relationships can be identified from verb/verb phrases in the problem statement.  They can also be identified from possessive grammar such as “has a”.  All the potential associations are extracted from the problem statement and unnecessary and incorrect associations are discarded.  Associations derived for this project include:

            SQL Statement uses Database Connection.

            Database Resultset describes SQL Statement.

            Mapping object generates SQL Statement.

            Mapping object contains FString, FInt and FDouble.

Fig 4.2 shows the object diagram which depicts the selected object classes and their relationships.  Multiplicity is used to show the number of instances of one class in relation to the number of instances of another class.

 

 

4.2.1.4 Add attributes for objects and links.

Attributes are the data values held by the objects in a class.  Each attribute is unique within the class and they are what makes two instances of the same class different.  Attributes can be derived from nouns followed by possessive phrases in the problem statement, but it is generally easier to find them from knowledge of the application domain.

4.2.1.5 Using inheritance to share common Structure

Inheritance enables attributes and operations to be shared using the relationships among classes.  At this stage a new abstract class Fcomponent was specified.  FComponent is the parent of the FInt, FDouble and FString, and enables them to share common attributes and actions.

 

When implementing this framework the Mapping class will be a generic class which will be extended to create the classes which the programmer wishes to perform database operations upon.  This is described in more detail during the implementation stage.

 

4.2.2 The Dynamic model

The dynamic model reflects the changes to objects and their relationships over time, demonstrating possible control flows through the system.  Rumbaugh (1991) verifies this:

            “The dynamic model shows the time independent behaviour of the system and

            the objects in it”.

The dynamic model is important for interactive and real time systems.  It is vital for applications that depend on collecting information from the user.  The current project will not be directly involved with interactions with the end user, thus the dynamic model is not very important, but it is important to consider the dynamic model for the simple database application, as this will indicate the types of control flows expected from the object-relational framework.  An event trace diagram was not constructed as the same information can be derived from an event flow diagram and the size of the system did not necessitate one.  Fig 4.3 illustrates an event flow diagram for a simple database application.

As can seen  the user interface tasks and the database related tasks can be performed in a linear order for this application, but this might not be the case for another application with different needs.  Also the user must wait for the database to return information before the flow of control returns to the user interface.

 

 

This scenario is not acceptable if the database must search large volumes of information, or when operating across the Internet.  Thus it would be beneficial to implement the database related framework on a separate thread of control.  By doing so all database related tasks would run independently from the graphical user interface, allowing the user to perform several tasks at once.

 

4.2.2.1 Developing a State Diagram

A state diagram is used to illustrate the dynamic model of the system.  The state diagram for the simple database application is shown in fig 4.4.  States are represented by rounded rectangles, transitions are shown as arrows labelled with the event which was responsible for the transition in question.      

 

4.2.3 The Functional Model

The functional model shows how the input and output values of a program are derived.  It does this using data flow diagrams (DFD).  A DFD is a networked view of the system which represent the program’s calculations.  DFDs are made up of processes, data flows, actors and data sources.  A process which is drawn as an ellipse, changes the input values into output values.  The processes in the DFD correspond to the operations in the object model.  A data flow, represented as an arrow, illustrates the flow of data through a series of connected processes.  Data flows starts and finishes at either a process, actor or data store.  Actors are objects and are represented as rectangles located at the edge of the DFD.  Actors can be either sources or sinks of data.  Data stores are depicted as parallel lines and provide a location for the temporary storage of data.

 

 

According to Derr (1995) the OMT specifies that five steps are followed when constructing a functional model. When constructing the functional model for this project it is sufficient that the first two steps are followed;

1.   Identify input and output values.

2.   Construct a data flow diagram for the input and output transformations.

 

4.2.3.1 Identify input and output values

The identified input and output values are identified in fig 4.5.

 

 

The user is both a source and a sink of data.  The input and output values shown in fig 4.5 are the parameters between the database application and the outside world.  The input values that have been identified are database URL, query and update query.  The output values are the results of the specified query.

 

 

4.2.3.2 Build a Data Flow Diagram

Data flow diagrams follow the rules of abstraction.  First a top level DFD is drawn.  Each of the processes identified are continually broken up until they reach a level

where no further decomposition can occur.  At this stage each process can represent a class method.  As a result of this decomposition DFD’s are drawn as a series of diagrams.  A top level data flow diagram is drawn first fig 4.6, it can be seen that the input and output values start and end with an external source i.e. the user.  The generate results process can be further decomposed as shown in fig 4.7.

 

 

During analysis three models of the system were created; the object model, the dynamic model and the functional model.  These models along with the problem statement make up the analysis of the project.  Throughout analysis the focus was placed on what needed to be done, the next stage, system design, will focus on how to develop the application.

 

4.3 System Design

During system design high level decisions are made towards solving the issues raised during analysis.  Some of the decisions made during system design include: what database will be used and how it will be used; will the application run on multiple

platforms and what programming language will be used to implement the design.  For this project it was specified in the problem statement that the Java language would be used.  As a result of this the system can be easily ported to multiple platforms. Microsoft Access 95 (Gilford et al., 1996) was selected as the back end database, it was implemented via the Windows 95 ODBC drivers (Microsoft, 1998).

 

During system design the system is broken into a small number of components or subsystems.  A subsystem is a collection of classes, associations and actions that can share a common property (e.g. similar functionality).  They interact with the rest of the system using a clearly defined interface.  Derr (1995) states that each subsystem should be viewed as a black box.  As this will enable each subsystem to be designed independently, without affecting the rest of the system.  In larger systems, subsystems can be further divided into subsystems of their own, but this is not the case in this project.  Subsystems are identified using the object model, those identified in this system are shown in fig 4.8.

 

 

4.4 Object Design

During object design all of the details for fully solving the problem are specified.  During this stage of OMT the three models of the system are refined and detail added.  The high level design of both the user interface and the database query mechanism has been completed, now the subsystems for DatabaseConnect and object relational mapping will be dealt with.

To finalise the design for the DatabaseConnect class, the tasks the class must carry out are illustrated using illustrations as outlined by (Culwin, 1998).  The diagrams are based on a mixture of a combination of JSP, OMT and the unified modelling language (UML).  The DatabaseConnect class must enable the following database operations to be carried out:

1.      Open a database connection.

2.      Enable SQL commands to be executed.

3.      Enable results to be retrieved and viewed based on search criteria.

The main tasks of the DatabaseConnect class are illustrated in fig 4.9.

 

 

The DatabaseConnect class operates on top of the JDBC API.  It uses the JDBC classes Connection, Statement, ResultSet and ResultSetMetadata.

The Mapping subsystem operates on top of a higher level abstraction of JDBC, thus removing the need for a programmer implementing this framework to worry about how connections are opened and results are retrieved from the database, but the outputs will need to match the inputs of the lower levels.  The inputs for the lower level have already being identified during the functional model as being either a database URL, a create new table and a SQL statement.  The initial class diagram for Mapping is shown in fig 4.10

 

 

Mapping is designed as a generic class which will be extended so that any new object type can inherit its attributes and operations.  When creating a new object type and storing it for the first time the class must be self aware i.e. it must be able to identify and access its attributes, and the object  name, so it can issue the required SQL statement.  This information is stored in the createSql and attributes strings, and is placed there by calling the one of the three create() methods, which takes a FComponent as a parameter.  Objects attributes are stored using the types int, double and the String object.  It was not possible to derive the necessary information from them, so a new object for each was designed namely FInt, FString and FDouble.  These three objects share the same methods and attributes and were identified to have the same parent class FComponent.  These new classes enables the Mapping class to keep track of it’s attributes.  As all three classes are very similar only the FString class is illustrated in fig 4.11.

 

When a Fstring object is created it takes three parameters;

1.   The name of the string, which will map to the name of a database column.  This is only used for creating a new table and implements the addCreate method.

2.   The contents of the string, which is an attribute of the created object.  The addAttribute method is used to extract it for use by the Mapping class.

The size indicates the number of characters in the string, it is only used when creating a new database table.

 

 

An important consideration when storing an object’s attributes in a database is, how each object’s values will be uniquely identified.  To facilitate this a unique identifier is associated with each object and stored in the database table as the primary key.  This will be outlined in more detail in the next chapter.

 

The next stage in object design is to derive the algorithms to implement the operations.  This is done by first analysing the data flows in the functional model.  This will be developed further in the next chapter.

 

4.5 Conclusion

In this chapter OMT was introduced and used to design a high level framework on top of the JDBC API.  It was decided during analysis that a database application would also be developed to test the framework.  This will enable the framework to be evaluated and possibly determine any additional functionality required.

 

During system design, the system was broken into subsystems and high level strategic decisions were made.  During object design detail was added to the class diagrams of the classes identified in the object model.  The next stage of the OMT process is the implementation of the framework in the Java language, which will be carried out in the next chapter.

Previous

Table of Contents

Next

 

Home