Java 2 Enterprise Edition has made Java a full enterprise-scale language - in all senses. Improvements in functionality, scalability, and performance have made it possible for more and more enterprise applications to be undertaken with Java technology.
Java projects are growing both in terms of complexity and the amount of code required to complete them. Developers need to turn to the types of methodologies and tools they've used with other development technologies - including modeling.
Modeling is a visualization process for constructing and documenting the design and structure of an application. As a matter of good practice, developers should make at least some outline of their application to show interdependencies and relationships between application components and subsystems. Modeling tools make this possible. Because modeling is dynamic, as one change is made in the model, the developer can see the ripple effect of the changes throughout the project. Modeling can also be introduced in the middle of an existing project; most modeling tools can read existing code and create a visual model based on the existing code base, giving developers a high-level view of what would otherwise be thousands of individual lines of code to review.
The Universal Modeling Language (UML) is the standard language used by the many modeling tools on the market. UML was designed to unify the many proprietary and incompatible modeling languages and create one modeling specification.
Modeling tools are increasingly being applied to Java development projects. Still, more than a few programmers use a text editor, and many developers haven't even thought about using modeling to create their applications. With the increasing complexity of enterprise Java applications and Java components, modeling will become a necessity for reducing development time and ensuring that a program is well written the first time around.
In a recent question-and-answer session, Ted Farrell, chief technology officer of WebGain, talked about his view of the growing role of modeling in the development of Java applications.
Q: At what point should you, as a developer, say you really need UML?
A: UML diagrams are designed to capture abstract thought before the programming begins. A use case or sequence diagram is a common starting point for many of our developers. You can model a flow of a method or several methods, and when programmers look at that diagram, they can see how it would translate into function calls in code.
The larger your application and the more people involved, the more apparent the need is for a UML modeling tool. But that decision isn't a definite line. The size of the application you're building and the number of people involved could be used as a driver of whether or not a UML modeling tool is a good choice for your project.
Q: How portable are models? Can I take something from Rational Rose and read it into any UML tool and vice versa?
A: It's getting there. There's a standard developed. It's an XML standard called XMI, or XML Metadata Interchange Format. It's UML described in XML. The next release of WebGain's UML tool, WebGain StructureBuilder, will support reading and writing XMI files. Rose right now has utilities to do that. This will be a good interface for exchanging XML information between different products.
Q: What are some of the features to look for in a modeling tool?
A: For the Java developer, it comes down to how in touch the modeling tool is with the Java language and the code they are developing. The further away the tool is from the actual language and development environment, the harder it is for the developer to use. Most UML tools are language agnostic. WebGain StructureBuilder is concentrated only on Java. You're talking in Java terms, not pure object-oriented terms anymore. You're talking in terms that any Java programmer would know as part of the language. They don't have to do that mental translation in their heads. If the tool is talking in generic object terms or doesn't keep in sync with the code, it becomes a lot more difficult for the programmer.
Programmers need a UML tool that is aware that Java code is present during different phases of the development cycle, and that the modeling isn't only done at the beginning of a project. Today, a lot of design is done up front, but as the developer starts coding, the application evolves. With Internet demands causing development cycles to shrink from years to weeks, a development environment must allow for rapid design, prototyping, and coding, while maintaining the integrity and quality of the code being developed. If you have a UML tool involved throughout the development cycle, you will have fewer deviations between your application and initial design. You will be able to identify differences during the coding phase, and either adjust your code or your design to meet the end requirements.
Q: How does modeling help with commercial or prebuilt components?
A: It doesn't make a difference whether it is software you are writing from scratch, or applications you are assembling from existing components and/or services, or both. Good design is always needed. Understanding the requirements of your software, and being able to articulate the design and flow of the application you are building, is essential. UML modeling tools allow you to do this in a consistent and effective manner.
Q: What role does modeling play in reuse of code?
A: The better the design of any code, whether it's a component or a standard software, the better and the more reusable the code will be. On the flip side, when reusing code, modeling can be invaluable in helping you understand the boundaries and dependencies of the different components you are using in your application.
Q: Can modeling be used to reverse engineer Java source code that wasn't written by a modeling tool and no model exists?
A: Absolutely. This is a very valuable feature. Developers and consultants use WebGain StructureBuilder to do this all the time. If they're going into an environment where they're not familiar with the code, or sharing code across a development or distributed development environment, a feature like this can literally save days worth of time. They can read in large amounts of code and WebGain StructureBuilder will build a set of diagrams for them. This helps them quickly visualize the areas of the code and what they do and lets them see how objects relate to each other.
Q: How much design information can you get from undocumented code?
A: Most of the structural information of the design can be obtained from the Java source code. Most of the relationship information is there. Information like whether a relationship is aggregate or composition can't be obtained from the code and would need to be identified by the user in the UML tool, but other than those, and other similar items, you can get a pretty decent representation of your object model straight from the Java code.
Q: What can't you get out of the code?
A: With Java, one-to-many relationships are harder to pull out of the code. The problem here is that Java collections, like Vector and Hashtable, are not typed. Because of this, most UML design tools do not identify the one-to-many relationships in your software, and force the user to manually go through all of their classes and mark the relationships accordingly. WebGain StructureBuilder, on the other hand, is the only tool that we know of that does identify the one-to-many relationship right from the code, saving the user countless amounts of time in not having to identify all those relationships manually. It just reads in your classes, and shows you the one-to-many relationships instantly.
Q: What are some of the pitfalls of code generated by modeling tools and how do you avoid them?
A: There are two major problems with code generated by modeling tools.
The first one is that most of the time the code generated is just structural stubs - it actually doesn't do very much. Now this is better than having to write this code by hand. There is much more that can be done. WebGain StructureBuilder, for example, will allow the user to quickly generate working code and code patterns with just a click of the mouse. Everything from constructors, singleton patterns, setters, getters, equals and compares routines, to any customized templates that the user wishes to add.
The second, and far bigger, problem of code generated from modeling tools is that the code quickly becomes out of sync with the model. Changing the code after generation results in a mismatch of information between the code and the model, and synchronizing that information can be a time-consuming and painful experience for the user, which is why many users choose not to go back to the model after the code has been generated. WebGain StructureBuilder solves this problem by using the source code as its base for the model information. Therefore there is no synchronization. If you change the code outside of the product, the next time you bring up the diagrams, the information is always up to date. Since it's all one data source, no synchronization is necessary.
Q: So if I model something in a traditional UML modeling tool, export the code generated, and start working on it, will these tools be able to read it back in and recognize it?
A: Many of them will read the code back in - there's a synchronization process. And if you changed too much in the code, then they will flag you and you have to go in manually and tell it what you did. You can generate C++ from the model data or Visual Basic, etc. Without being tightly tied to the target language and/or the development environment, synchronization will always be more difficult.
Q: Is there such a thing as too much modeling?
A: There can be too much modeling. At a certain point you need to start prototyping code and see how your initial designs look. That curve is different depending on the project, organization, and people.
Q: What's the best way to introduce a modeling tool to developers, especially to those who've never used it in the past?
A: We've found it's best to introduce UML to programmers a little at a time. Use it on different types of diagrams. The Class diagram has the most synergy with the actual Java software structure. So someone who's designing object-oriented software is doing designs of class diagrams whether they know it or not. The boxes show relations between objects. Any Java programmer viewing a class diagram will recognize it immediately.
Other diagrams are more abstract. State or activity diagrams really show a program or method flow, but show it at a high level, like a flowchart. Sometimes a programmer might view this and have a disconnect with the code they are writing.
Q: So what do you think will be the future of modeling for Java? What do you think will be the next major development in this area?
A: In the past, UML has been viewed as a "techie" type of language - real hard-core technology. Object guys understood it, some programmers did and some didn't, and business people definitely were scared away from it. I think you'll see more user-friendly UML. It needs to be less intimidating and used across the organization to share information and communicate between groups during the development process. It's imperative for the people who are defining the business requirements of the product to be involved at all stages to make sure that the requirements are being met as the application is being developed.
I think the next major development will be positioning UML as more usable and more approachable by everyone in the organization - not just the people designing software.