The Object Oriented SDLC and JDeveloper
Introduction
Recently, I was hired by an insurance company to talk to them about object-oriented (OO) programming, JDeveloper and the Software Development Life Cycle (SDLC). This was 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?
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 entity objects.
·
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.
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.
V. 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. Paul Dorsey is the founder and president of Dulcian, Inc. an Oracle consulting firm specializing in business rules and web based application development. He is the chief architect of Dulcian’s Business Rules Information Manager (BRIM™) tool. Paul is the co-author of six Oracle Press books on Designer, Database Design, Developer, and JDeveloper, which have been translated into seven languages. He is President of the New York Oracle Users Group and a Contributing Editor of IOUG's SELECT Journal. In 2001, Dr. Dorsey was honored by IOUG as volunteer of the year and by Oracle as one of the six initial honorary Oracle 9i Certified Masters. Paul is also the founder and Chairperson of the ODTUG Business Rules Symposium, now in its fourth year. He can be reached via email at paul_dorsey@dulcian.com.