J2EE applications are fundamentally complex. A typical system may contain thousands of EJBs, Java classes, JSP pages, and servlets, which are linked into an intricate web of numerous dependencies. Managing this complexity is the key to building stable and flexible J2EE applications. To deal with complexity, it is important to focus on the structure of the dependencies between all components in the system. Excessive, unnecessary dependencies lead to chaotic, unmanageable, and costly systems. On the other hand, stable software is always well-structured and does not contain extraneous dependencies.
Cutting-edge science supports the importance of dependency-centric thinking. The emerging Complexity Science studies common patterns and themes in biological, economic, social, and physical systems. These systems are made of parts organized into a network, or a Dependency Web. The interactions between the parts of this network give rise to the greater whole -- the system itself.
From this perspective, any software can be thought of as a network of components and interactions. Complexity Science says that the structure of the overall Dependency Web is one of the determining factors in the stability and longevity of the entire system. This article will illustrate how to apply the concepts of Dependency Web Theory to your J2EE applications.
The structure of a J2EE application is the Dependency Web of components and the relationships between them. The rule is: if component A knows about component B, it depends on it. Put differently, if the code of component A refers to component B, then component A depends on component B.
For example, in Pet Store,
customer.jsp contains the following
This implies that
customer.jsp depends on
Similarly, the following code in
CustomerEJB dependent on
public abstract void setAccount(AccountLocal account);
You can map dependents and dependencies for every EJB, JSP page, or servlet. Put it all together to create the Dependency Web for your J2EE application.
Figure 1 -- example of an UML Dependency Web in Java
To analyze a Dependency Web effectively, you need to make sure to identify all nodes and dependencies correctly.
First, let's look at a simple example. Instead of considering all nodes of a J2EE Dependency Web, let's consider the basic ones that come from the Java language. In Java, the nodes are Classes, Interfaces, and Packages. Classes and Interfaces are linked by means of standard UML relationships: Uses, Contains, Extends, and Implements.
Figure 1 shows an example of a piece of Java code translated into its
corresponding Dependency Web. The class
Frame and implements
SwingConstants, so it depends on
Frame class and the
keyEvent method of
JFrame takes a
KeyEvent class as an argument, which makes
KeyEvent. The method
Component, which implies that
JFrame depends on the
Component class. Finally, since
JFrame contains the variable
rootPane of type
JFrame class depends on the
J2EE has a richer Dependency Web than J2SE. In addition to classes, interfaces, and packages, J2EE has Enterprise Java Beans, JSP pages, servlets, HTML pages, XML configuration files, and .jars.
Let's take a look at an example of a J2EE Dependency Web from Pet Store. We
will consider the dependencies in the neighborhood of the
We will only focus on the dependencies that are specific to the Pet Store application; that is, we will ignore the core Java and J2EE classes and interfaces. We will also ignore the dependencies on inner classes and exceptions.
Figure 2 --
Figure 3 --
Figure 2 shows how the method signatures in the
interface give rise to the four Uses dependencies. Based on this code,
CatalogDAO uses the
In Figure 3, you see extracts from four different files that show the
dependents of the
CatalogDAO interface. First, we see that
CatalogDAO in the
GenericCatalogDAO depends on the
CatalogDAO interface because it implements it.
CatalogEJB both depend on
CatalogDAO because they contain an instance of this interface.
In any Dependency Web, if component A depends on component B, we say that A
and B are one degree away from each other. So all immediate dependents and
dependencies of the
CatalogDAO interface are considered to be one
degree away from it. However, the complete Dependency Web of
CatalogDAO may be very large, since it includes all objects that
are in some way linked to this interface.
We will now show how you can build the second degree Dependency Web for
CatalogDAO. For this, we simply need to consider the dependents
and dependencies of the objects that are one degree away from this
CatalogDAOFactory, the dependencies are identified in exactly the
same way that we described above. We want to focus instead on additional
dependencies that are induced by
CatalogHelper is used in several JSP pages. For example,
product.jsp contains a use bean tag that refers to
CatalogHelper bean (see Figure 4), so
depends on the
Figure 4 --
Figure 5 illustrates yet another kind of J2EE dependency. The XML deployment
ejb-jar.xml for the
CatalogEJB refers to
the bean and, thus, depends on it.
If we put together all of the described dependencies, we get the following Dependency Web:
Figure 6 -- a second-degree Dependency Web for
Note that arrows always point from the independent object to dependent, creating the direction of the flow of change.
Let's look at the interdependencies between the classes that surround
CatalogDAO to make sure that we understand what we are seeing.
CatalogDAO interface. This implies that they should
Product, and this is exactly what we see in Figure 6.
In this article, we have shown how you can construct a simple J2EE Dependency Web. Dependency Webs are representations of the intricate networks of dependencies within your software. Thinking about dependencies helps to simplify complex J2EE applications.
Dependency Webs are important because they offer compact visual representations of local and global structures in our systems. While we are buried knee-deep in code, we often forget to think about the big picture. The visuals of the Dependency Web are always informative and revealing. By looking at and analyzing Dependency Webs, we often uncover the unexpected or unnecessary dependencies.
Alex Iskold is a founder of Information Laboratory, a New York based company that created Small Worlds, a Software Analysis and Visualization tool.
Daniel Kogan is a founder of Information Laboratory, a New York based company that created Small Worlds, a Software Analysis and Visualization tool.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.