UML Data Modeling in JDeveloper
The Unified Modeling Language (UML) is a standard environment for
object-oriented design and development. The most commonly recognized parts of
the UML Modeling environment are class diagrams, which somewhat resemble ERDs. Class diagrams were originally designed to support
object-oriented programming structures.
However, even the formal definition of class diagrams seems to support
their use for other things. “Class diagrams show the
static structure of the model, in particular, the things that exist (such as
classes and types), their internal structure, and their relationships to other
things.” (UML 1.4 spec p.294). This is not exactly a restrictive description.
In the relational database world, there
is a tradition of using class diagrams for various purposes. Back in 1998, the Oracle Designer team
released a UML class modeling product call Object Database Designer (ODD) that
was designed to support the creation of Oracle 8’s object extensions (nested
tables and VARRAYS). This inspired me to
make the shift to UML and to write Oracle8
Design using UML Object Modeling (Dorsey
& Hudicka, 1998, ISBN: 0078824745) for Oracle Press and give me the dubious distinction of
having written the first book on using UML class diagrams for data
modeling. Of course, the universal
non-adoption of the Oracle 8 object extensions and the eventual abandonment of
the ODD product did not make for particularly brisk sales of the book.
There is quite a lot of discussion with respect to whether UML class diagrams can be used for data modeling. Many go as far as to say that UML class diagrams cannot be used at all for data modeling. I am mystified by this belief. Class diagrams can clearly be used for data modeling. Obviously, there is some work to do. But with some thoughtful extensions, class diagrams actually provide a superior modeling environment in comparison to anything available in the traditional relational environment.
In the Oracle JDeveloper 10g release, class diagrams are used,
not only in the traditional way (to model Java classes), but also to help model
the middle tier structure to support connections to the database (Application
Development Framework Business Components (ADF BC) entities and associations). In JDeveloper, class diagrams even support
forward generation of these ADF BC entities as tables in the database. Oracle is moving towards eventual support of
full data modeling using UML class models. This paper will discuss the use of
UML for data modeling in general as well as how JDeveloper can support this
task.
Data Modeling Using the UML
Many people question whether any part of the Unified Modeling Language (UML) can be used for data modeling. Some have suggested creating a new tool to explicitly support data modeling. However, with some extensions, the UML can be used very effectively to design databases.
With the advent of increasingly complex systems, a clear and concise way of representing them visually became increasingly important. The Unified Modeling Language (UML) was developed by Grady Booch, Jim Rumbaugh, and Ivar Jacobson as a response to that need. In order too create a single system for modeling and documenting information systems and business processes, UML was created with an underlying object-oriented analysis and design philosophy. To build successful systems, a sound model is essential. It communicates the overall system plan to the entire development team. As stated in the UML Summary Document (UML Summary, version 1.1, 1 September 1997, Rational Software et al.), the primary goals in designing UML were the following:
·
Provide the users a ready-to-use visual modeling
language so they can develop and exchange meaningful models.
·
Provide extensibility and specialization mechanisms
to extend the core concepts.
·
Be independent of particular programming
languages and development processes.
·
Provide a formal basis for understanding the
modeling language.
·
Encourage the growth of the object-oriented
tools market.
·
Support higher-level development concepts such
as collaboration, frameworks, patterns, and components.
·
Integrate best practices.
For all of the reasons just stated, UML should be the language of
choice for building object-oriented systems.
UML is not just a replacement for entity relationship
diagramming. UML encompasses several parts that together provide a complete
object-oriented development environment. The part of UML that deals with data
modeling is the class diagram. This paper will discuss the UML class diagram
exclusively. We will only briefly mention any of the other parts of UML. It
should be noted that UML covers the entire system design environment, not just
data modeling. A complete discussion of UML can be found in any of the books
written on UML available in any computer book outlet.
The first version of UML included the following diagram types
1. Class
diagram This
is the data modeling diagramming language. It is similar in scope to ER
modeling.
2. Object
diagram This
is a class diagram for only one set of objects. Think of it as a data model
where you show example data rather than the whole data model. This is very
useful for explaining complex diagrams.
3. Use case
diagram A
use case is similar to the idea of a “function” in Oracle’s CASE method. A use
case diagram shows the interaction among actors (for example, customers and
employees) and use cases. There is no analogue to this diagram in Oracle’s
methodology.
4. Sequence
diagram A
sequence diagram shows an interaction of objects arranged in a time sequence.
This is similar to the process flow diagrammer in
Oracle Designer.
5. Collaboration
diagram (also
called communication diagrams) A collaboration diagram shows the objects and
messages that are passed between those objects in order to perform some
function. There is no analogue to this diagram in Oracle’s methodology.
6. Statechart diagram Statechart diagrams are standard state transition diagrams.
They show what states an object can be in and what causes the object to change
states. There is no analogue to this diagram in Oracle’s methodology.
7. Activity
diagram An
activity diagram is a type of flowchart. It represents operation and decision
points. This is similar to the data flowchart in Oracle Designer.
8. Component
diagram A component diagram shows dependencies and organization
among components.
9. Deployment diagram (also
called implementation diagrams) A
deployment diagram includes the run-time processing node configuration.
UML 2.0 added four new types
·
Interaction overview diagrams Variation of activity
diagrams that includes an overview of the system process flows
·
Package diagrams Subset of
class diagrams used to organize elements into related groups
·
Composite Structure diagrams These diagrams show the internal structure of items such as
classes or use cases including their interaction with other parts of the
system.
·
Timing diagrams These diagrams are
used to show changes in states over time.
The two most commonly used diagrams in data modeling are Class and Activity diagrams. This is equally true in JDeveloper where support is only provided for these two diagram types.
Extensions & Modifications to basic UML
One of the most challenging problems in mapping an object-oriented design into a relational database is how to implement generalizations. The traditional mapping of each class to a table generates logically correct but unusable systems. Redundant storage of inherited attributes along the inheritance path will be discussed as a strategy that allows modelers to use generalization without hesitation. Generalizations are used extensively consistent with UML syntax. Association classes are explicitly supported in a way consistent with UML syntax.
The associations between objects in the generic structure are physically stored in a SUPER ASSOCIATION table. To date, we have not found a compelling reason to use composition or aggregation other than for notational simplicity. Typically, we use strong composition to indicate a mandatory 1-to-many or weak composition (aggregation) symbol to denote an optional 1-to-many relationship between two classes.
On associations, we support relationships from n1…m1 to n2…m2 where n and m are positive integers or “*” (any number). We have not found any reason to support the more complex cardinalities such as “2, 4, 6” which are allowable in UML syntax. In the data models, we have designed, only on rare occasions have we used cardinalities other than 0..1, 1, 1..* and *. However, these other cardinalities do come in handy for specifying the maximum size of a committee or similar situations.
Methods
We are still relatively early in our exploration of how to use methods in this system. Display methods are used to drive application development. In order to display an object from a particular class, there must be a way to show the object. For example, in an Employee class, we want to display the employee ID and name. On an invoice, we want to display the invoice number, date and customer. It is useful to have methods stored in the data repository for this purpose.
Triggers
We have extended the Oracle concept of table triggers. Since our attributes are stored separately from the object, there is no UPDATE OBJECT trigger. Instead, CREATE OBJECT, DELETE OBJECT, and SET ATTRIBUTE. SET ATTRIBUTE is particularly useful validation triggers.
Primary Keys
Object-oriented development proponents don’t think in terms of primary keys. This is a mistake. Understanding and articulating what uniquely identifies an object beyond its ID is critical to good database design. We have extended UML to allow for primary key specification. In particular, primary key components are attributes or associations, just as in relational models. We have added the ability to make generalization a component of the primary key of a class.
Unique Constraints
Any number of multi-component unique constraints may be set on a class. Allowable components of unique constraints are the same as for primary keys, namely attributes, associations and generalizations.
UML extensions to support the creation of class tables
As mentioned above, each class in the UML data model is physically instantiated as a table. Each attribute in the class becomes a column. Foreign key relationships are handled using a reference to the master table OID rather than using the logical primary key.
Specialization classes include attributes along the generalization path. For example, in the EMP class, a Last Name and First Name column would be included if EMP is a specialization of PERSON. The UML engine is smart enough to handle an Insert or Update into EMP ASSOCIATED VIEW by inserting, updating or attaching to the appropriate person record.
We use keywords attached to UML objects to specify various physical column and class names. For example, to express a many-to-many relationship between two classes, you will need an association table between the two classes. If designers do not want to draw an association class, they can simply attach a keyword to declare what the name of the association table will be. Foreign key columns are named using the PARENT CLASS NAME_OID, but can be overridden via a keyword on the association.
Many-to-many associations between abstract classes become complex because an association table between any of the underlying subclasses may be needed as shown in Figure 1.
Figure 1: Many-to-many associations between abstract classes
In this case, the designer may want to have as many as twelve association classes because you will not only need association classes between all of the subclasses, but also the superclasses (an EMP-DEPT association class). How will these tables be named? As a keyword on the many-to-many association, the class pairings to be physically instantiated as tables are specified along with their names. It is beyond the scope of this paper to describe all of the notational nuances that we have used to extend UML.
Disadvantages of UML Diagramming
UML is not a panacea. It does not solve all the problems associated with entity relationship modeling, but does make our task somewhat easier. There are some disadvantages to UML. We are still missing a way of denoting time-related entities. These entities are an important type of class, just as they are an important type of entity requiring special treatment. It would be useful to be able to visually identify time-related classes. This problem in ERDs has still not been solved in UML.
UML in JDeveloper
JDeveloper is an integrated development environment (IDE) for Java programming. It offers a rich set of features for designing, developing, debugging, and deploying Java and other related files that are part of the Java 2 Platform, Enterprise Edition (J2EE) strategy. JDeveloper contains many wizards and code generators that make it easier to implement complex functionality in Java, enabling you to concentrate on solving business problems. It also offers strong code organization and configuration management.
There are two parts to the vision driving the JDeveloper product.
The first is influenced by the J2EE and broader Java development communities,
which strive to make JDeveloper
The second part of the vision that JDeveloper is pursuing is that
of a unified design and development environment. Here, JDeveloper is moving
towards being a single point of entry for systems analysis, design, development
and deployment. JDeveloper 10g
includes a UML Use Case Diagrammer, which allows
developers to enter use cases and generate HTML documents. The product also
includes the first generation of a database modeler using UML class diagrams.
The modeling portions of JDeveloper are still maturing and are not yet at the
point where they can be utilized as
Modeling in JDeveloper
In addition to the great strides made in J2EE development with the 10g release, some progress was also made in improving the modeling capabilities of the tool. JDeveloper still does not support the entire SDLC but it continues to move in that direction.
Some models called Platform
Independent Models (PIMs) may not map to specific
implemented targets. Some examples of PIMs include
UML use cases, classes and interfaces. Enterprise JavaBeans, web services,
database objects, business components, Java classes and interfaces can be
supported in JDeveloper by Platform
Specific Models (PSMs). PSMs
are specialized class modeler implementations. JDeveloper allows you to model
any of these structures on the same diagram.
Database Modeler
Developers want to be able to create models within JDeveloper. Full UML-based modeling including inheritance, aggregation and composition capabilities would be a welcome addition to JDeveloper at some point. The 10g release includes the beginnings of a solid data modeling tool using a limited subset of the UML. Conspicuously absent is the notion of generalization.
The Database Modeler cannot be used yet for logical and physical
database design. Oracle Designer should still be used for that purpose.
JDeveloper users without access to a full-featured database design tool like
Oracle Designer may find JDeveloper’s modeling capabilities adequate for
simpler applications. However, JDeveloper should not be considered a viable
modeling environment for enterprise level database construction.
Use Case Modeler
The Use Case Modeler included in JDeveloper 10g is a graphical
front-end that allows users to store an entire use case diagram as a single
HTML document. Text descriptions can be entered into a Microsoft Word-like
document suitable for high-level system documentation. The Use Case Modeler
provides a convenient graphical user interface for including this
Conclusion
JDeveloper 10g’s motto, “Productivity with Choice”, although reflective of the tremendous flexibility of the tool, sidesteps the additional complexity that has made traditional Oracle developers reluctant to embrace J2EE. The popularity of less flexible alternatives such as Portal and HTML DB demonstrates that, in addition to flexibility, developers also want guidance for systems development best practices.
The expected long-range vision is that JDeveloper will move closer and closer to being a unified design and development environment. However, progress towards this goal has been slower than hoped for in the last three years, mainly due to Oracle placing emphasis on creating an excellent J2EE product. In this respect, they have succeeded admirably. The question remains as to how much attention is given to the ultimate vision vs. deployment of resources towards tactical, technical J2EE topics.
About the Author
Dr.
About the Author
Dr.