Figure 1. A sample component application
Until now most of the Java-based articles and books have addressed topics dealing with APIs, development tools, and the how-tos of using the various Java technologies. As Java becomes more mainstream in large organizations, it becomes necessary to address design-related topics, such as a Java development methodology.
In this article, we'll learn to develop robust applications using Smart Data Component Structure, a technology based on JavaBeans component architecture and Smart Data Structure.
By William Gu & Larry Wagner
Java can be used to develop applets, standalone
applications (GUI and console), and packages (library of reusable classes).
It is on its way to becoming mature enough to develop enterprise-wide applications.
For these kind of projects, the most careful and thought-out design can
still lead to utter confusion when the project grows beyond a certain manageable
size. Object-oriented design methodologies and programming languages have
come a long way toward improving this scenario. Even so, none of these
languages has truly answered the need for a fully reusable software standard.
The software component architecture, a recent technology in the software
development community, provides a much better solution to this problem.
From a systematic point, we also need a good structure for the system besides
the components. The Smart Data Structure proposed and implemented in C++
by Joel of RUSLE-2 has proved to be a good one. The problem is how to combine
these two technologies in the Java version of MOSES. This paper explains
a solution for it.
Change is embraced in the innovative world of software development probably more than in any other professional endeavor. Software enters a final commercial state for only a brief period of time, after which the next batch of enhancements and improvements is immediately planned and begun. Software developers are always under extreme pressure to work faster and deliver better results. To meet the deadline, software developers often are forced to cut corners in the midst of turning out applications. The result is that the code is highly dependent on the specific project. In other words, each new project is beginning from scratch. The software development community has been exploring the idea of reusable software for a while. Object-oriented language such as C++ was the most significant one. It allows reusability of C++ classes within the specific context. The real solution shouldn't only enable developers to easily reuse code within a particular application, but also across different applications/platforms and even in a distributed network environment such as the Internet.
A software component is a piece of software isolated into a discrete, easily reusable structure. Microsoft's VBX and OCX component architectures have had great success in the PC world, but they've done little to bridge the gap between other types of operating systems. JavaBeans is implemented as an architecture-independent and platform-independent application programming interface (API) for creating and using dynamic Java software components.
Figure 1. A sample component application
In the management view (figure 1), three visible components (called view components) are indicated, i.e. timeline, spreadsheet, and tree. Some other components may be invisible but can also be general enough to be a component. For example, a unit-conversion component.
Please refer Smart Data Structure at Joel's homepage.
Smart Data Component Structure is designed based on JavaBeans component
architecture and the Smart Data Structure. Most system can be divided into
two parts, i.e. the model data and the GUI components. The
model data has its own logic and may be represented in a tree structure
or other structures. For example, in RUSLE-2, it can be represented with
a tree structure.
The GUI components which represents the model data have a much more complicated
event-driven "web-like" structure. The relationship between GUI
component and its data sources (within the model data structure) can be
1:1, 1:n, n:1. In other words, one GUI component can show data from one
or several data sources, several GUI components may show data from one
data source. To get the best flexibility, we designed the Smart Data Component
Structure which is generally feasible to any kind of GUI systems.
In Smart Data Component Structure, we separate the GUI components from
the model data. Some GUI components may be connected to its model data
directly while others may need one or more middleware pieces to
establish this relationship. Middleware can function as a filter, an adapter
or a converter.
An Example
Figure 2. The structure of the MOSES management subsystem
In figure 1, we have identified that there are three view components
in this specific management subsystem. Without data, the components can
not do anything. In figure 2, we divide the system into three parts. The
left-hand side is the model data. This is the actual data we want to manipulate
and /or create. They can be read or write from/to file or databases locally
or remotely. In our example, it contains all the date, operations, residues
and related parameters. On the right-hand side, we show the three view
components. They are a customized spreadsheet, a timeline created by the
programmer and a general tree component. Most components are general and
may not be used directly on the model data. If this is true, we may need
to create some middleware to smooth the connection. In figure 2, we use
two filters to connect the model data to the timeline and the spreadsheet.
Of course, middleware can function as an adapter or a converter as well.
What are the benefits of Smart Data Component Structure?
The most significant benefit of Smart Data Component Structure is its flexibility.
The system is designed in a plug-n-play style. If the user does not like
the display format, it would be very easy to switch to another view component.
For example, the user may want to use a list instead of a tree to make
a choice, all the system needs to do is to create a new list view component
and "plug in". Likewise, if the model data structure is changed,
the effect to the view components are mimimal. You may only need to make
some minor changes in the middleware. This kind of flexibility is especially
important in MOSES where four erosion models share the same interface.
For instance, the operation parameters are different in the four models.
Thus the user will see different parameters while switching from WEPP to
WEPS. This is very simple to do with the above structure. What the system
will do is to create a new tree structure (the lower middleware in figure
2), and hook it to the tree view component.
Another benefit is that it will allow the programmer to use complicated
commercial components instead of coding the system from scratch. In our
previous version of MCREW (the management subsystem developed at WEPS),
we spent several months to build a spreadsheet. Even so, we still can not
provide certain functionalities such as cut and paste. With a commercial
package, we can do the same thing in several days. The reusability is another
benefit for using commercial packages. Most commercial packages are generally
developed and can be customized to a specific system. The components can
be used several times in a system. For instance, a spreadsheet can be used
for management view, output screen, etc.
Easy prototyping is another benefit. Even if there is no model data available, the GUI is still available for preview. Currently, we have partly developed the management subsystem. The following is a snapshot of the screen.
Figure 3. Management Subsystem Implemented with SDCS
Conclusion
The Smart Data Component Structure is still under constant changes.