The Object Oriented SDLC and JDeveloper
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:
1.
What is the goal of combining a traditional relational
system and an OO system?
2.
How can the relational SDLC be modified to build this
new type of system?
3.
How can the OO SDLC be modified to build this new type
of system?
4.
What are the ways in which these two approaches can be
combined?
5.
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.