More JFall highlights: MDA and OCL, Java and scripting, Project Jackpot and the XP Game.

From last week’s JFall conference I picked four of the most interesting sessions I visited to report on:

• Combining the Power of MDA and OCL: Generating Java Code from OCL (and UML) Models – Jos Warmer
• Scripting in Java – Martin Wolf
• Project Jackpot: Refactoring on Steroids – Wilfred Springer
• XP Game – Martien van Steenbergen

MDA and OCL: how to write less code

The subject of this talk was how MDA (Model Driven Architecture) can take advantage of new features in OCL, the Object Constraint Language. To illustrate this, Octopus was presented, an open source tool that generates Java code from OCL expressions.

MDA

MDA, Model Driven Architecture, is an approach to software development that aims to generate large parts of an application from a UML model. Usually additional handcoding is required to inject additional (business and presentation) logic. It is crucial that the generated and the handmade code are merged gracefully, i.e. without overwriting each other, because this way the generated code can be maintained by maintaining the model and the generator, followed by regeneration of the application.

OCL

OCL, the Object Constraint Language, is part of the UML standard. As the name suggests it was originally concieved as a platform independent language for constraints, used for the specification of pre- and postconditions, invariants and guards in UML models. Since version 2.0 OCL has become more powerfull, it has effectively evolved into a general purpose query language. The phrase Object Query Language would be more appropiate by now.

In comparison to other query languages, OCL 2 is at least as powerfull as SQL. Anything that can be expressed using SQL can be expressed using OCL as well. In addition the OCL syntax is more compact and easier to read.

OCL usage

Since version 2 OCL can be used in all types UML diagrams. Next to the traditional usage (pre- and postconditions, invariants, guards) it can be used to express program logic like initial values, derived values, derived attributes, query operations and conditions. From an MDA perspective, anything expressed with OCL can be used for the generation of code, so the more OCL is used, the less needs to be coded by hand. In addition, codegeneration is particularly attractive for business logic like validation rules that usually need to be implemented in multiple tiers of an application. Since the code in each tier is generated from the same OCL expressions, the usual maintenance problems of duplicated logic are avoided.

The use of OCL is supported by many UML casetools, including some of the free options. Inclusion of OCL expressions in UML models can be achieved using either the visual syntax (in diagrams), or textual syntax (in separate textfiles).

Octopus

Octopus (OCl TOol for Precise Uml Specification), available as an Eclipse plugin, provides an IDE for OCL expressions, and the ability to generate a complete prototype application from a UML model. As part of this a javamethod is generated for each OCL expression.

During the demo, it was interesting to compare the generated methods to the original OCL expressions. Clearly the implementation of a single OCL expression can result in a significant number of lines of code. Moreover, most of these lines consist of boilerplate code like iterating over collections and exception handling, and only few lines (often just one) contain actual business logic.

An issue that remains is how to gracefully merge the generated and the handmade code. But, as Jos said, Octopus must be regarded as a continuously evolving work in progress, rather than a finished product.

Conclusion

OCL has become a powerful language to express conditions and queries. When using MDA, OCL expressions can be useful to put more of the logic in the model, leaving less to be written by hand. If you want to go down that road, Octopus is worth looking further into.

Scripting in Java – why not?

This talk dealt with the use of scripting languages in Java projects, and surrounding issues.

Scripting languages

When is it appropriate to call a programming language a scipting language? There are no hard boundaries, but arguably one or more of these characteristics set a scripting language apart:

• intended for small automated tasks
• no explicit compilation step
• loose structure: e.g. implicit variables and types, best-effort error-handling

ava developer be interested in scripting? First of all, chances are you’re doing it already. After all, when was the last time you used XSLT, JSP, Ant target or a Unix/Windows shell script?
Apparently there are situations where a scripting language can prove to be a better alternative to Java:

• rapid development
• configuring (business) rules that drive an application, without the need to (re)compile
• providing a macro language for an application
• as a special purpose language for specific tasks

ady many scripting languages that mix well with a Java environment. Some popular options include Groovy, Rhino, Jython and JRuby.

The potential for mixing Java with scripting will further improve in future versions of Java, as these features will be included:

• JSR 119, Java compiler API: exposes the java compiler as a public API, allowing programs to be compiled from sourecode and executed on the fly.
• JSR 223, scripting framework: provides language bindings and a scripting API.

scripting language

Making a choice between the available scripting languages comes down to evaluating a few characteristics:

• target audience: Java developers versus less a less technical audience
• language maturity and (future) stability
• how much java integration is required?

egration, Groovy comes first. It can be embedded in Java, used as a stand-alone scripting language, or compiled to bytecode (classfiles) that runs on the JVM. Moreover it leverages existing Java API’s, so there is less need to learn new API’s. On the downside, the language is still very young and evolving. It needs time to become stable and prove itself, though a Groovy language specification is in progress (JSR 241). Depending of the amount of maturity that is required, it may be the ideal choice for a Java developers target audience.

On the other side of te spectrum are Java ports/bindings of mature scripting languages that have already proven themselves outside the Java arena. Like Jython, also described as Python for Java, or JRuby. Because of their maturity and proven trackrecord, these may be a better option for a target audience with no Java experience.

Issues

Introducing of scripting in a project brings up a number of issues that need to be addressed:

• user interaction: What happens in case of scripting errors? How and to what extend are users allowed to update of submit scripts?
• security:Who can update or submit scripts? What are these allowed to do? Can these be trusted?

Techniques to address security issues:

ndard policy-based security (supported by Groovy).
• Controlling access with your own bindings.

While almost anything can be programmed in Java, there are cases where a scripting language would be more appropriate as it is easier, faster, or more fun! It’s good to see an increasing interest in these potentials.

Coming soon: Project Jackpot

Project Jackpot is the code name for a technology that enables developers to make sweeping source file changes safely. The first release of Jackpot is due to become available for download soon. This session provided a sneak preview of what is to be expected.

Jackpot

Jackpot is a new technology for searching, and safely and correctly transforming Java source code. Think of it as refactoring taken to a whole new level of functionality. It is implemented as a framework and a set of Netbeans modules.

Possible usage scenario’s:

• source auditing; detection of anti-patterns
• safe refactoring
• re-engineering

comes to mind, based on these description, is common refactoring tasks like renaming, moving and restructuring code, and nowadays supported by most popular IDE’s. However, the demo’s that followed showed that Jackpot is much more powerfull than that.

Example: replace all usages of Enumerator by Iterator. (Iterator was introduced as part of the Java Collecions framework in JDK1.2, and is a modern replacement for Enumerator. Enumerator is typically used mostly in code that predates JDK1.2.)
This transformation consists of these actions:

• replace Enumeration by Iterator in variable declarations.
• replace Vector method elements() by iterator().
• replace enumeration methods hasMoreElements() and nextElement() by iterator methods hasNext() and next().

more than a regular refactoring!

Other examples:

• rewriting code to take advantage of new syntax constructs introduced in Java5
• migrating a GUI application to different another GUI framework (in this case from the – very legacy – Microsoft foundation classes windowing toolkit to Swing!).

>

Looking under the hood, the foundation of Jackpot is based on three models of Java sourcecode, as created by the javac compiler: the abstract syntax tree (AST), the type system and the symbol table. Jackpot transformations are initially performed on these models, and such that if the initial model is correct (i.e. can be compiled), the resulting model is guaranteed to be correct as well.

The basic concepts regarding transformations are:
– search operator
– transformation operator
– rule: search/replace declaration
Transformations can be defined as a set of rules. Typically a rule combines a search pattern and a condition with a (substitution) action.

Usage

A lot of attention has been given to making this a userfriendly and unobtrusive tool. Using the Netbeans modules, the workflow is as follows:

• start a Jackpot session
• apply a transformation
• optionally browse the resulting modifications, or apply additional transformations
• rollback or commit the work, close the session.

f the sourcefiles occurs only when the work is committed. At this point the sourcecode modifications are applied in-situ, without affecting the surrounding code, effectively preserving all comments and formatting!

The Netbeans modules provide support for:

• rules editor
• a set of prepackaged refactorings
• formatting options for substituted code
• executing Jackpot sessions

put things into perspective, consider the evolution of (what can be generically be described as) sourcecode manipulation techniques. Once all we had was textbased search/replace operations with regular expressions. Nowadays many refactoring tools are available that support basic refactorings based on a parsed syntax tree. Jackpot represents an obvious next step in this evolution. Coming soon to an IDE near you!

XP Game: highly recommended

The XP Game wasn’t a regular session, but a simulation game, played by a number of small teams simultaneously, under the supervision of Martien and his assistants. The purpose of the game is to experience a mini (and partial) simulation of XP development, and provide a taste and feel for what XP is all about.

The game

First the audience is split in teams of three: one coach and two developers per team. Each team has to complete several iterations (“sprints“) of the XP development process. Some actions require a customer, in which case the teammembers assume the role of customer for the duration of that action. Further requisites included a supply of balloons, dice, a deck of cards, … and a set of storycards.

Each storycard describes a task to be executed, with a business value attached to it. The tasks were simple instructions like “inflate and knot 5 balloons to at least 40 cm circumference”, “build a 4 story cardhouse”, “take a deck of cards from which one card is missing, and determine which one is missing”.

A sprint

A sprint typically consists of these steps:

1. complexity estimation: Go through all storycards, and estimate the complexity of each task (complexity being defined as propertional to the time needed to complete te task).
2. velocity estimation: Estimate the time needed to complete the simplest story (determining the velocity).
3. planning: Go through all storycards again, and calculate the time needed to complete the task, based on the estimates from step 1 and 2.
4. story selection: Assume the role of the customer, and select the stories for the next release. The total time needed for implementation must be less than 180 seconds, using the estimates from step 3. In addition, the customer must try to get maximum business value within these constraints.
5. story implementation: The developers implement the selected task. The coach is in charge of evaluating the results (acceptance tests) and measuring the completion time of each task.
6. acceptance and release: The customer evaluates which tasks were succesfully completed within the available time, and determines the business value produced.

Now what had I learnt after one sprint?

exity of the tasks reasonably well, but with a tendency to underestimate the more complex tasks.
• We overestimated our velocity. Even the simplest task took much longer than we estimated.
• With everything carefully recorded, both estimates and actual achievements, a lot of data was available to recalibrate and improve our estimates for the next sprint.

e development: sounds familiar? Even after just one sprint I felt this had been a very usefull, educating and fun experience.

Typically an XP game goes throught three successive sprints, and I would expect to see a dramatic improvement of the estimates overtime. Regrettably, we had just enough time for one sprint. It’s ironical that thist session about planning was itself planned so bady, but to his defense I must mention that it was a first timer for Martien as well.

Want to play the XP game yourself? You can, everything you need is available for download. Highly recommended!