Visual Java Models

As Java continues to mature, all sorts of side projects are evolving around the language, including a standard for visually modeling Java programs. This is the idea behind the JG visual-modeling language, which is the brainchild of Kari Kaitanen of the Technical Research Centre of Finland, a government-sponsored research organization that investigates everything from industrial to information sciences.

JG is still in the birthing stage. Kaitanen maintains a Web site that includes a good description of JG, several sample JG diagrams applied to example programs, and a questionnaire. Kaitanen is (as of this writing) still soliciting feedback on the JG notation, though he told me he doubted the design would change much from what was on the site in early March. (You can find the JG Web site at http://www.vtt.fi/cic/java/java-g/ .)

The JG visual-modeling language is a database description language (DDL) for Java programs. Because it is a DDL, JG is geared toward producing visual descriptions of Java data components: classes, class relationships, objects, and data structures.

The JG specification includes standardized notations for interfaces, classes, objects, instance data, object and class relationships, and the other data-centric entities in a Java program. Note that the emphasis is on Java. JG is not a general-purpose DDL. (JG is based on Express-G, a general-purpose modeling language defined by the ISO.) It was its designer's intent that JG have such a close affinity with the Java language that you cannot model anything in JG that you cannot implement in Java. Conversely, you cannot write any Java code that you cannot model in JG.

Because JG models only data, it provides only a kind of static snapshot of one aspect of a Java program. That is, though you can use JG to specify the methods within a particular class, it provides no syntax for describing the behavior of those methods. This limitation isn't a character flaw within JG. Rather, it's the result of JG's being a DDL. JG is not designed to describe behavior, only data structure.

Nevertheless, this points out a missing adjunct to JG that program designers would need to be able to completely specify a Java program. Indeed, Kaitanen is already thinking about adding some type of dynamic model to accompany JG. He hopes to soon begin work on a dynamic-modeling language built on the best ideas derived from existing modeling tech niques. What the final result looks like remains to be seen. I shall be watching the JG Web site closely.