The Object Oriented SDLC and JDeveloper
Dr. Paul Dorsey, Dulcian, Inc.
Introduction
Last year, I was hired by an insurance company to talk to
them about object-oriented (OO) programming, JDeveloper and the Software
Development Life Cycle (SDLC). They had a first-rate Oracle development team of
expert users of Designer and Developer, who had achieved virtually 100%
generation of Oracle Forms. Their sophisticated development methodology is
model-driven and well supported by their tool set.
The information technology professionals in this organization
had done due diligence in preparing for our meeting. They had a stack of books
about UML, OO theory, Java, etc. The question that they had been grappling with
and were unable to resolve was as follows: What is the appropriate SDLC for a
project using OO analysis tools (specifically UML) at the outset and JDeveloper
to build JavaClient or JSP applications?
Use cases, scenarios, analysis-level class and activity
diagrams had all been investigated. The developers at this organization had
also experimented with building Business Components for Java (BC4J) projects
and Java application code, but the problem of how the OO design and JDeveloper
application code should be linked still remained. How can you go from an OO design
to building Oracle-based applications in JDeveloper?
An entire team of people discussed this issue for a few days.
I believe that this question is an important one for the industry to answer in
order to go forward with J2EE-based systems architecture and tools such as
JDeveloper.
SDLC Options
There are two obvious SDLC candidates for building
object-oriented, relational systems. The traditional relational systems
development life cycle as implemented in an Oracle environment is well
established and reasonably successful. However, this approach has never been
contemplated in the context of an OO environment. The other alternative is the
traditional OO SDLC which, similarly, has been reasonably successful in
building OO-based systems but had paid little attention to solid relational
database design. In our new environment, we want to have OO software sitting on
top of a relational database. How can this be accomplished? This paper will
address the following questions:
·
What is the goal of combining a traditional
relational system and an OO system?
·
How can the relational SDLC be modified to build
this new type of system?
·
How can the OO SDLC be modified to build this
new type of system?
·
What are the ways in which these two approaches
can be combined?
·
What is the appropriate SDLC for this new type
of system?
I. What is the goal of combining a traditional relational system and
an OO system?
This appears to be a simple enough question. One would think that the answer is simply to build a good relational database and then to build good OO software to talk to the relational structures. However, there are different philosophies and attitudes toward the two types of systems. Most Java programmers pay little attention to the data structure. They want to create class diagrams that correspond to the Java classes and are satisfied as long as Oracle tables provide storage for persistent copies of objects. The core of the design rests within the application rather than the database.
Database architects focus on a well-designed data structure before writing any code, only making denormalizations and modifications to the database as necessary to make the applications perform adequately. Relational databases (ignoring the dubious OO extensions) have the functional limitation of not being able to nicely handle basic OO concepts such as inheritance and encapsulation. The relational database grammar of tables, columns and foreign key constraints is inconvenient for building a complex generalization path in a design model. However, being able to model using logical inheritance is a very powerful design tool that should be available to database designers. Similarly, some of the other modelers within the Unified Modeling Language (UML) such as the Activity Modeler are also very useful and should be included as one of a system designer’s tools.
Thus the goal for each system seems to be different. The logical conclusion, then, seems to be that the goal should not be to cater to either the database or OO application code, but instead, the process should begin with the superior modeling techniques of the UML and both the database and application code should be developed directly from this analysis. The result of this process would be a solid database based on the best relational design practices (including normalization) with a structure that is more OO-friendly than a completely traditional database design. The application code (Java classes, BC4J, entity objects, etc.) would be congruent with the elements in the relational database as well as an application with which a traditional OO programmer will be comfortable.
Building databases this way will deviate somewhat from traditional database design. (For a more complete discussion of this topic, see the whitepaper “Using UML to Design Data Structures” on the Dulcian website – www.dulcian.com). Building OO applications will also likely deviate from a traditional, pure OO system. Each tradition brings its own strengths. Systems based on OO applications that communicate with a relational database are a new kind of hybrid that requires some new thinking.
II. How can the relational SDLC be modified to build OO-friendly
systems?
The traditional relational SDLC is the standard waterfall SDLC that predates relational databases. It was first described by Nolan (Managing the Computer Resource: A Stage Hypothesis, Richard L. Nolan, ACM Press, 1973). This evolved further in Barker’s CASE methodology (Case Method Entity Relationship Modelling (Richard Barker, Addison Wesley Publishing Company, 1990) and was revised in the Oracle Designer Handbook (both 1st and 2nd editions, Dorsey & Koletzke– Oracle Press, 1996, 1998) with the CASE Application Development Method (CADM).
This SDLC could be used to build these new types of systems since there are similar elements for what is needed in the UML in the old Oracle Designer SDLC with ERD models, and primitive process flows with the Process Modeler. However, much work would be required to adapt this method. ERDs would need to be extended to support the same level of business rule representation that the UML affords. The Designer Process Modeler is close to a UML Activity Diagrammer although neither allows for a full articulation of a business process.
The biggest argument against attempting to adapt the Designer-based SDLC to an OO-friendly methodology is that the UML is now the industry standard for management of the design and development process in the OO environment. There is growing recognition that the UML/OO approach represents the primary direction in which the database industry is moving. These directional shifts are often caused when industry leader companies make certain decisions. In the case of Oracle, the UML has been selected for use in future products. Therefore, although technically feasible, adapting the traditional SDLC/ERD-based approach would be likely to fail.
The Designer SDLC never paid adequate attention to the analysis phase. As the business rules-based approach takes hold, the Designer SDLC appears significantly out of step with the times.
III. How can the Object-Oriented SDLC be Adapted to Support
Relational Database Systems?
There is a well-established existing body of OO literature to
describe the OO SDLC. A full discussion of this is beyond the scope of this
paper (see The Unified Software Development Process by Ivar Jacobson, Grady
Booch, James Rumbaugh, Addison-Wesley, 1999). The UML is the standard
representational language for OO design and development. The UML design process
follows a standard waterfall process (Strategy, Analysis, Design, Develop)
although different labels are used for the steps.
What is different about the OO process are the tools used.
For Analysis, use cases are employed. Use cases are analysis rules grouped by
the role of the individual executing a particular business event. A typical use
case involves an actor (Customer, Employee) performing a particular action
(Purchase,
There are eleven other tools in the UML modeling environment.
The most important of these are the following three:
Class Modeler – The Class Modeler produces a diagram that
superficially looks similar to an ERD and fulfills the same basic function in
the system design process. UML class diagrams provide a number of diagrammatic
elements that do not appear in ERDs. However, there are also a few elements in
ERDs (unique constraint primary key specifications) that do not appear in UML
class models. Since UML is explicitly extendable, it is easy to incorporate
these elements into a class diagram. A sample class diagram is shown in Figure
1.
Figure 1: Class Diagram
Activity Diagram – Activity diagrams resemble familiar
process flows showing a sequence of steps, often visually represented in swim
lanes. Activity diagrams are inadequate to completely represent a process but
can be extended to support full process specification. For further discussion
of this topic see the paper BRIM®
State Transition Engine Syntax at http://www.dulcian.com/BRIM.htm. An example of
an activity diagram is shown in Figure 2.
Figure 2: Activity Diagram
Sequence Diagram – Sequence diagrams show a flow based on the
concepts of objects, links, and messages showing how a process moves from one
agent to another. These diagrams show module interaction as shown in Figure 3.
Figure 3: Sequence Diagram
Creating Code from Diagrams
How is code created from these three diagram types? The
traditional OO SDLC turns class diagrams into Java classes, which are used to
generate the relational database tables. Activity, sequence and other UML
components are used primarily for documentation purposes. These diagrams guide
the coding process. Traditional OO
designers pay little attention to database design. They are frequently happy if they can make
tables that allow them store persistent copies of their objects.
The conclusion is that the traditional OO approach is not
suited for designing this new kind of system any more than is the traditional
relational SDLC.
IV. How Can the Relational and OO Approaches be Combined?
In the traditional relational SDLC, transitions are made from
the ERD to table design which, in turn, generates the relational database.
There is no awareness of OO analysis or design in the relatively limited ERD
vocabulary. The OO SDLC provides a very rich analysis and design environment
with a myriad of modelers and diagrammers. However, this process produces a
sub-optimal database design.
As part of the consultation with the insurance company
mentioned in the introduction, they worked on drawing a class diagram that
closely resembled an ERD using UML class diagram syntax and created activity
and sequence diagrams to seemingly capture the structure of their system. The
class diagram showed objects of interest and business processes were
represented by activity and sequence diagrams. Armed with these tools, they
booted up JDeveloper and then got stuck.
The reason that they were stuck is that there is no clear
path from OO analysis and design to creating a working production system based
on a relational DB. Putting aside what JDeveloper is capable of doing, it is
still necessary to devise a plan for how to proceed. To get started, all
process-related rules were put aside since they seemed to be more difficult to
support. A number of possible ideas that would result in a relational database
were proposed. Each will be discussed separately.
Idea 1
The first idea proposed involved starting with the class
diagram and using this diagram to generate BC4J view objects which, in turn,
generate the BC4J entity objects and finally generate the database. The Java
classes in the application would naturally be generated from the BC4J view
objects. This approach is shown in Figure 4.
Figure 4: Initial approach – Idea 1
Upon examination, this approach had several flaws:
·
In JDeveloper, the only currently supported
portion of this SDLC is the creation of Java classes from view objects and the
creation (albeit poorly) of database objects from BC4J (
·
This approach doesn’t make logical sense. Going
from class diagrams to BC4J view objects is an adequate approach. However, the
transition from view objects to entity objects to the database is not an
obvious or simple process.
Fundamentally, all business rules are captured in the
analysis and design phases. A large portion of these are contained in the
original class diagram. However, once the view objects have been generated, it
is not possible to continue generating the entity objects and database with
ease. It is possible to manually implement this process to support the Idea 1
approach; but it would be difficult to maintain a good design at the database
level.
Idea 2
A second idea for consideration involved starting with a
class diagram and immediately generating the relational database. The next step
would be to build BC4J entity objects based on the created database followed by
the view objects and Java classes.
Mapping the class diagram to tables would be accomplished
with Dulcian’s Business Rules Information Manager (BRIM®) tool and JDeveloper for the remaining transformation steps as
shown in Figure 5. BRIM® was
selected for generation of the database as being the most sophisticated class
diagram to relational database mapping tool.
Figure 5: Using BRIM® and JDeveloper approach – Idea 2
This approach was clearly viable and supported by existing tools and does allow good OO systems to be built.
Idea 3
After looking at Ideas 1 and 2, it still seemed that a better
approach might be devised. A third proposal was to start with a class diagram
for analysis and design. The class
diagram would then be used to generate of all elements from database tables to
Java classes. A diagram of this approach is shown in Figure 6.
Figure 6: Ideal Approach – Idea 3
If the system’s business rules have been fully specified in
the analysis and design phases, there should be enough information in the
repository to accurately generate the system. This seems to be the right
approach but is not a well supported vision.
Idea 4
If there is no way of mapping a class diagram to a relational
database (e.g. BRIM is not an available alternative), the best available SDLC
is to perform OO analysis and design and manually translate the design into an
Oracle Designer ERD which can then be used to generate the relational database
as shown in Figure 7.
Figure 7: Designer/JDeveloper Approach – Idea 4
At this point, JDeveloper could be used as in Idea 2 for the
remainder of the SDLC. The syntax between class diagrams and ERDs is close
enough that, depending upon the product used for the class diagrams, a
translation utility can be written to export the class diagrams and import them
as ERDs into Designer.
Idea 5
The supported version of an OO approach uses the class model
to create the BC4J entity objects used to generate the tables. JDeveloper could
be used to help build Java classes and BC4J view objects as shown in Figure 8.
As previously mentioned there will be limited database modeling starting version
10g of JDeveloper.
Figure 8: OO Approach – Idea 5
JDeveloper currently completely supports this approach and is
actually being used to build a real system in this way. However, this SDLC may
ultimately produce an unsound database and therefore result in an unstable
system.
Idea 6
The complete BRIM®
environment extends Idea 2 one step farther. In addition to generating the
database, BRIM® uses an
extension of UML activity diagrams to generate application code so that all
process-related code is generated directly from the UML repository as shown in
Figure 9.
Figure 9: BRIM® - Centric Approach – Idea 6
This solution is completely supported with a combination of
JDeveloper and BRIM®, but is a
long way away from the vision articulated in Idea 3 where all of the business
rules are fully specified in the analysis and design phases, so that the
repository can be used to accurately generate virtually the entire system.
What is the Appropriate Combined SDLC?
This paper has presented a number of possible answers to the
question of finding the right SDLC to support an OO-based SDLC being used to
create a relational database system. Idea 3 where everything flows from the
analysis and design phases is conceptually the right approach. Any approach
with multiple generation steps where tables, entity objects, view objects and
Java classes are sequentially generated moves farther away from the original
design and gathered business rules. Ultimately, the best approach is to start
with a complete representation of the business rules, allowing the entire
system to be generated from the specified rules repository.
The UML elements described in this paper (use cases, class
diagrams, activity diagrams, sequence diagrams) form an adequate set of tools
to fully represent and auto generate a system. Unfortunately, no product
currently exists to support this vision. In the meantime, a design methodology
will have to be selected assuming that a significant portion of the work will
need to be done by hand for the foreseeable future.
About the Author
Dr.