Introduction

Objects by Design is pleased to bring our readers this interview with Geoffrey Sparks, CEO and founder of Sparx Systems, the creators of Enterprise Architect. The recently released version 6.1 of Enterprise Architect is one of the first UML tools to extensively support the new UML 2.0 specification, and has allowed Sparx Systems to leapfrog the competition - at a very reasonable price.

UML 2.0

SZ: It appears that Sparx Systems may be the first vendor to release a UML product supporting the UML 2.0 specification. Can you describe some of the most important additions to UML 2.0 which you now support?

Geoffrey Sparks: UML 2.0 provides a new and rich palette from which to model a wide range of situations and domains - from business processes to traditional software projects, real-time and embedded systems. On the surface it appears somewhat more complex than its predecessor, but in practice the complexity is actually there to help simplify models, by offering the right modelling element for a given situation.

Some of the significant changes which I see as pivotal to the success of UML 2.0 include:

Composite Structures - UML 2.0 provides some interesting enhancements to help model and work with complex structures. Ports and Parts provide the ability to model typed elements (like Attributes) using graphical elements. Ports in particular are a very useful means of tightly specifying an element's interaction with its environment. Composite Structure diagrams are an excellent way of both visualising and specifying complex logical relationships.

Extended Activity Syntax - I am a great fan of Activity diagrams, and I was very pleased to see many of the enhancements in UML 2.0 which improve the level of detail which you can employ when specifying behaviour.

Improved Sequence / Interaction Diagrams - Sequence diagrams have gone through some very interesting changes with UML 2.0. The whole idea of "interaction fragments" and the ability to model using discrete interaction chunks seems to work very well in practice. Modelling conditional execution, parallel threads and other complex behaviour has become significantly easier in my opinion. In addition, the two new diagram types derived from Sequence diagrams, Timing and Interaction Overview diagrams, provide a higher level of expressiveness not possible under earlier versions of the UML.

Improved Component and Deployment Model Support - It is also good to see that the ability to model the more physical side of any solution has been extended. Additional elements and connectivity make working with deployment and component diagrams much easier, and make it possible to capture significantly more detail about how and where a solution is constructed and deployed.

I believe these changes greatly improve the precision and expressiveness of UML models and provide the basis for an even wider range of modelling applications.

SZ: How hard was it to add support for 2.0?

Geoffrey Sparks: Initially I was a little apprehensive about the daunting task ahead - UML 2.0 is a giant leap ahead of its predecessor and I was anticipating quite a few issues along the way and plenty of sleepless nights! Although the development process wasn't a walk in the park, it did proceed far more smoothly than first envisaged - so much so that we were able to include some of the items we initially planned to include in an earlier version, such as Timing Diagrams.

We had a lot of support from our beta testers and it was fulfilling to see the UML 2.0 specification "come alive" in EA after many months of simply reading and digesting its contents. We have a terrific team of developers and technical writers, and their commitment and effort has been pivotal in the success of implementing UML 2.0.

SZ: Does Enterprise Architect fully support UML 2.0? If not, what is missing?

Geoffrey Sparks: EA currently supports most of UML 2.0, including all 13 diagram types. There are a few minor omissions, such as Loop Nodes, State Inheritance, Parameter Sets and Power Type, which we hope to support in EA in the next couple of months. The other feature we are keen to get up and working as soon as possible is XMI import/export for UML 2.0, including diagram interchange. XMI is a great technology for sharing information and I am hopeful that the schema-based validation available under XMI 2.0 will help to solve some of the problems inherent in earlier versions of XMI.

XMI

SZ: Enterprise Architect has excellent support for exporting a UML model in XMI 1.2 format. We noticed that Compuware's OptimalJ MDA tool includes EA as one of the three vendors whose XMI output it will import. That is a good endorsement of the quality of your XMI! How have your customers used XMI, how important a feature has it been for EA, and how do you see EA leveraging this facility in the future, especially now that MDA is becoming more popular?

Geoffrey Sparks: XMI is an absolutely pivotal technology in my opinion. A UML model is a very precise and powerful abstraction, and the ability to plug that information into other tools is extremely powerful. It is definitely our intention to support XMI as fully as possible. The main issue we have struck in the past is that the DTD-based validation of XMI files is extremely loose - so it is possible to create valid XMI output that another tool will not be able to read in full. As a result there are many 'flavours' of XMI, and it is difficult to provide support for them all. I am hopeful that schema-validated XMI conforming to UML 2.0 will provide a more tightly validated model with less room for mismatches between tool vendors.

We use the XMI export/import extensively in EA for providing version control, export of model elements, model to model transfer of information and even as an extension to the automation interface - allowing automation clients the ability to pick up EA fragments in XMI output for processing and transformation. Many of our clients use it in the same way - using XMI to input to other MDA tools, combined with style-sheets to generate documentation, and for sharing of information with users of other modelling tools.

I think the ability to share information amongst tools is one of the most creative uses of UML/XML. The number of potential applications for UML model information is huge, and a single tool will never provide all the possible functionality and transformation engines required to satisfy this potential. XMI importing and exporting is an impressive way of publishing information for consumption by other tools to help satisfy the need for highly specific targets .

Windows Platform

SZ: EA is built using the Windows platform and provides a very good Windows native look-and-feel. We are impressed by the quality of the diagrams. What are some of the advantages and limitations you have found of using the Windows platform and how are these reflected in the product?

Geoffrey Sparks: I have always been a great C++ fan, and have had extensive experience with the Windows API going back many years, so a Windows based solution was always going to be my starting point. We have worked very hard over the last 6 years to not only refine and optimize both the drawing and data access routines to provide a comfortable and efficient user experience; but also to enhance interoperability between EA and other tools by providing the Automation Interface and Add-in model to EA.

Though there have been a few instances where we have needed to resort to custom low-level routines to overcome minor limitations in the Windows API, In general I would have to say that the Windows platform has performed extremely well in providing us with the necessary API on which to build EA.

SZ: Recently you announced a version of EA for Linux using a Windows compatibility layer on Linux. How well is that version working?

Geoffrey Sparks: We are extremely pleased with how well EA works under Linux using the WINE derivative, Cross-Over Office. It is no easy task porting a large application like EA to other platforms, and the WINE based solution has made it possible to offer EA to Linux users with minimal compromise. The compatibility layer appears to be very stable and efficient, and we were quite surprised at how few issues there were in getting EA up and running.

SZ: Have you seen a demand in the Linux market?

Geoffrey Sparks: We have always had a general interest from users in seeing a Linux based version of EA. In fact, many already use VMWare to run EA within a virtual Windows machine under Linux. Most of the interest seems to have come from companies that run a mixture of Linux and Windows workstations, and were keen to run EA on both platforms. It will be interesting to see over the coming months how popular the Linux version of EA is amongst our clients.

Java and J2EE

SZ: Does the fact that EA isn't written in Java hamper its ability to provide UML support for the Java language and for J2EE development?

Geoffrey Sparks: I don't believe so. It has always been our intention to provide a wide range of support for different languages, and to provide the mechanism for customizing code generation. Through the use of the core UML elements coupled with UML Profiles, Code Generation templates and custom Add-Ins, it is possible to model and produce almost any Java (or other language) structure that is desired.

We are scheduled to provide additional pre-built UML Profiles for J2EE later this year, and are hoping to provide interoperability with the Eclipse platform in the not too distant future. EA does not rely on the pre-existence of compilers or language tools for any of the currently supported languages, but instead uses custom parsing and code generation templates. I believe this approach improves the abstraction of our UML model and the ability to transform the content to target languages such as Java, Delphi, C++, PHP etc.

UML is all about abstraction and the ability to transform models into target implementations. As we move forward with the development and extension of EA, I see the builtin support for defining new targets and elaborating existing ones continually expanding. As the generic code modelling, generation and reverse engineering process is extended over time, all internally supported languages are benefited, rather than just having one with which we are tightly coupled.

What's Next

SZ: Can you give us a glimpse into the future of EA? Where do you take the product next? What features would you like to see implemented? Which languages would you like to support?

Geoffrey Sparks: The main focus of our development over the next 12 months is on interoperability with other tools, support for additional languages, and the elaboration of the EA plug-in architecture.

Interoperability is a critical factor, with the capability to export standard XMI that can be consumed by various MDA generators a primary consideration. The ability to exchange complete models between modelling tools is perhaps less compelling than the ability to feed the ever growing number of specialist tools that are being developed to transform standard XMI into code, schema, database models and other targets.

The plug-In architecture of EA is also critical to its long term success. We are constantly extending this and providing additional hooks for 3rd party developers to build highly integrated tools within the EA IDE. In fact, we are using this architecture to build an integration layer between EA and Visual Studio.NET at the moment, and hope to have this released shortly. Once this is in place we intend to use the same approach to integrate with Eclipse and other IDE's. I think there are an enormous number of interesting things one can do with UML, and a potentially even larger number of useful transformations that can be made.

We are planning to have additional language support for CORBA and MIDL soon, plus we are looking at a variety of other target languages and specifications that fit in with EA and use UML to model, describe, construct and deconstruct software.

There is an incredible amount of information modelling going on now, and EA is being used in a very wide range of industries, for a multitude of purposes. Some of these industries are software-centric but others have nothing to do with the generation or development of source code. All of them are concerned with information: both the capturing of information and the production of some physical target. This target may be documentation, XML Schema, source code, configuration files, meta-models, or something else. EA facilitates the capturing, importing and storing of information from disparate sources in UML models which is then linked to builtin and pluggable transformations of those models to a wide range of targets.

Victoria, Australia

SZ: What's it like in Victoria Australia? It sounds like an interesting place. Can you describe what it looks like?

Geoffrey Sparks: Sparx Systems operates out of Creswick, a small town established in the Victorian goldfields last century. Our head office, in fact, is a historic 'Gold Bank', built to handle a large portion of the gold mined in the local district last century. The surrounding countryside is essentially farmlands and bush, with Melbourne only an hour or so away. Coupled with high speed Internet access, it is a great place to work as it allows us to focus on our core objectives without the distractions that come from working out of a large city.

Sparx Systems is only a few minutes away from the city of Ballarat, which is a much larger provincial centre, with an excellent University, considerable IT infrastructure and support services. The local region boasts some fascinating and spectacular national parks and forests, and when the time is available, a little bushwalking is an ideal balance to the pressures of software development, testing and marketing.