The two EMFs

In a recent thread on the EMF newsgroup, I came to realize that there are (at least) two EMFs, each belonging to a different class of product, and attending completely distinct requirements.

EMF’s native metamodel, Ecore, is a generic, lean object-oriented metamodel based on a subset of UML.

EMF’s runtime framework provides Java applications with runtime support for object models “including change notification, persistence support with default XMI serialization, and a very efficient reflective API for manipulating EMF objects generically” (source).

I am a happy user of EMF’s Ecore metamodel as a poor man’s UML (EMF team, please take that as a compliment). From Ecore-based models, using a compatible template engine, I can generate all code/artifacts that are prone to automation, be they Java code or not.

The runtime aspect of EMF is certainly useful to many applications, but certainly not to all or maybe even most. That is not to say that the EMF runtime does not provide a lot of value, as it clearly does given its popularity. Nor does it imply that the EMF runtime API has design flaws that prevent its use to be more widespread. The fact is that frameworks, while designed for extension, always impose a certain set of architectural decisions in order to provide value out-of-the-box. Those decisions are bound to make its use more suitable to some scenarios and applications than others. The goal is to make as many people happy as possible. It is clear that the EMF team has pulled off that trick. But that does not mean that using EMF-generated model code is appropriate for every Java application out there.

Model driven development maximizes reuse via a complete separation between problem domain and technological concerns. This separation is critical to allow us to build software in an obsolescence-proof way. EMF’s Ecore provides a good foundation for MDD in this sense, regardless the technology choices for the software being developed. The EMF runtime framework, albeit a valuable tool for a significant range of applications, brings with it a specific set of choices in terms of design and implementation decisions, and as such has a less universal applicability.

However, time and again I read comments in the EMF newsgroup that lead me to believe that this duality might have been accidental, and that the sole reason Ecore was created was to support the generation of Java applications based on the EMF runtime. If that is really the case, this is something that both amuses and worries me. My concern is that if the EMF team does not acknowledge the importance of Ecore as an independently useful product, technical decisions in the evolution of EMF might break the use of Ecore in contexts other than EMF-based Java applications.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

UML 101 with TextUML: multiplicity (or [*])

One weird thing about UML is that there aren’t collection types or array types. Basically, multiplicity and typing are totally independent concerns, represented by the metaclasses TypedElement and MultiplicityElement.

A typed element is a named element that has a type, and that is all about it. Examples of typed elements are value specifications, properties, parameters, pins and variables.

A multiplicity element, on the other hand, is an element that when instantiated potentially admits a collection of values. An optionally defined lower bound value (defaults to 1) can determine the minimum number of instances expected. Whether multiple values are in fact admitted will depend on the upper bound of the multiplicity element, which defaults to 1 (no multiple values allowed), but can be set to any positive integer, or infinity. A multiplicity element that can actually be multivalued can also be characterized regarding ordering (whether values can be accessed by position) and uniqueness (whether values can be repeated).

Some kinds of elements are both typed and support multiplicity (such as properties, parameters, pins and variables), however a few are one or the other (let’s ignore those in this discussion).

Mapping UML to Java

To try to illustrate all that was said above, let’s see a few examples of Java variable declarations and the equivalent declaration in UML (using TextUML syntax):

declaration Java TextUML
single-valued Client c c:Client
multi-valued Collection<Client> c c:Client[*]
Client[] c
ordered List<Client> c c:Client[*]{ordered}
unique Set<client> c c:Client[*]{unique}

There are few interesting differences though:

  1. in UML, it is the typed element itself that defines multiplicity, and not the type
  2. c:Client, c:Client[1] and c:Client[1,1] are all equivalent
  3. c:Client[*], c:Client[1,*] are equivalent
  4. if a value is optional, the lower bound must be specified to be 0 (example: c:Client[0,1]). There is no Java equivalent for that.
  5. unique and unordered are the default in UML (you can use the modifiers ‘nonunique’ and ‘ordered’ to override the defaults)

There are some implications related to assignment when the source and destination are multiplicity elements:

  1. the upper bound of the destination must be the same or greater than the upper bound of the source, or a type mismatch will ensue
  2. what happens if source and destination differ on ordering or unicity? The UML spec does not sem to cover that (let me know if you think otherwise). In TextUML, any required transformations are performed automatically behind the scenes. For example: if the source is non-unique and the destination is unique, duplicates will be silently suppressed, or if the source is unordered and the destination is ordered, an arbitrary order will be defined.

Well, that was it for today. If you have questions, suggestions or think I got something wrong here, feel free to add a comment.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

UML 101 with TextUML: the Templates package

One of the least known and understood concepts of UML is templates. Section 17.5 on version 2.1.1 of the UML specification covers the Templates package in 31 pages. What follows is an attempt at providing a summary of the mechanism in a way that is easy to understand without actually omitting any important details.

A simple example

The following example in TextUML should be easy to understand for any developer familiar with C++ parametrized types or Java generics:

class Foo
end;

class Bar<T>
    attribute prop1 : T;
    operation op11(par1 : T);
end;

class Fred
    attribute attr1 : Bar<Foo>;
end;

Class ‘Bar’ is a template class, whose template signature contains a single parameter: ‘T’. The type of the property ‘prop1′ is defined as the template parameter ‘T’. Class ‘Fred’ declares ‘someOp1′, an operation that takes a parameter whose type is a binding of the template class ‘Bar’. ‘Bar”s template parameter ‘T’ is bound to the class ‘Foo’. Implicitly, the type of ‘Fred.attr1′ when expanded against Foo should look something like:

class BarOfFoo
    attribute prop1 : Foo;
    operation op11(par1 : Foo);
end;

Note that the expanded class has actually no name, but I am calling it ‘BarOfZoo’ for pedagogical reasons.

Looking closer at the abstractions

  • TemplateableElements - abstract super-class for elements that can be declared as templates, or that can bind other templates to a set of parameters. Four kinds of elements can be declared as templates in UML 2.*: Classifier, Operation, Package and StringExpression, and thus only those metaclasses specialize TemplateableElement*.
  • ParameterableElements - abstract class that is specialized by any type of element that can be used as parameters to templates.
  • TemplateSignature - a template signature is owned by a template element and contains the set of parameters declared by a template element.
  • TemplateBinding - a template binding represents the “instantiation” of a template in the form of a directed relationship between a template signature and a a bound element, another templateable element. In addition to tying the template to the bound element through the template’s signature, the template binding contains a set of template parameter substitutions. Which takes us to the next abstraction…
  • TemplateParameterSubstitution - a template parameter substitution is created for every template parameter declared by a template signature. It binds an open parameter to an actual parameter, which is a ParameterableElement.

Would you like to play with templates in UML? For now, you will have to look elsewhere. There is some support for templates in the TextUML Toolkit 1.0 M2, but it is, to put it mildly, half-baked. Full template support is planned for M3 (whenever it happens), and that is exactly what I am working right now. I know I am close to getting it right, but assignment compatibility involving template/bound classifiers get be really tricky to implement. Well, whenever I am done, you will learn it first here.
*in the Eclipse UML2 API, Property also specializes TemplateableElement. That seems to be a deviation from the spec, and a bug report has been submited.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

TextUML Toolkit M2a – Java 5 users please read

A user has just reported that the TextUML Toolkit M2 build did not work at all for him. Ouch. Thankfully, the user included in the bug report all the information I needed to allow a quick diagnostic: turns out he was using a Java 5 VM, and he was getting exceptions like this:

java.lang.UnsupportedClassVersionError: Bad version number in .class file

 at java.lang.ClassLoader.defineClass1(Native Method)

 ...

I then realized that for the M2 build some of the plug-ins were accidentally compiled having Java 6 as the target platform, and thus wouldn’t work on a Java 5 VM. This is being fixed as I write this, and a new M2a build will be available shortly.

So, for those of you running with a Java 5 VM, please make sure you download the TextUML Toolkit M2a build. Otherwise, if you are using a Java 6 VM, you should be fine with M2, no need to download the build again.

Thanks to Jon for reporting the issue. Keep those bug reports coming!

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

UML 101 with TextUML – Profiles and Stereotypes

Profiles and stereotypes form a lightweight mechanism for extending the UML metamodel.

A stereotype allows you to tag elements in your model so they can be interpreted differently from ordinary model elements, much like annotations work in languages such as C# and Java. These tags can then be used to drive code generation, for example, so for every class marked as “persistent”, appropriate persistence code should be generated.

A profile is a special kind of package intended to contain stereotype declarations that extend UML to cover some specific domain or platform.

Let’s see how to declare and use profiles and stereotypes with the help of the TextUML Toolkit.

Declaring a stereotype

To declare a stereotype in TextUML, one uses the following syntax:

profile <profile-name>;

stereotype <stereotype-name> extends <metaclass-1 [,...metaclass-n]...]
[<property-1>; [... property-n;]...]
end;

end.

In other words, a stereotype can be declared as applicable to one or more metaclasses (i.e. types of elements in a UML model), and a stereotype can optionally declare properties (more on properties later) . For instance, a classes could be tagged with the <<persistent>> stereotype:

profile business_apps;

import uml;

stereotype persistent extends Class
end;

end.

Or operations could be marked as <<transactional>>, meaning that a transaction will be started whenever the operation starts executing, and finished when its execution ends:

profile business_apps;

import uml;

stereotype transactional extends Operation
end;

end.

Any UML element can be affected by stereotypes, but stereotypes are declared as targetting (potentially multiple) specific element types. For instance, the UML specification has an example of a profile for Enterprise JavaBeans that defines a <<Session>> stereotype for session beans. The<<Session>> stereotype declares a property that allows modelers to define whether the session bean component is stateful or stateless.

profile EJB;

enumeration StateKind
  STATELESS, STATEFUL
end;

stereotype Bean extends uml::Component
end;

stereotype Session specializes Bean
  property kind : StateKind;
end;

stereotype Entity specializes Bean
end;

end.

Applying a stereotype

Now that we know how to declare stereotypes, lets see how to use them. First of all, you must apply the profile defining the stereotypes to the model declaring elements you want to apply stereotypes to:

model bank;

apply business_apps;

/* other model elements here */

end.

You can then attach stereotypes defined in the applied profile to the suitable model elements in your model:

model bank;

apply business_apps;

[persistent]
class Account
    attribute accountNumber : base::String;
    attribute balance : base::Real;
    attribute changes : AccountChange[0,*];
    [transactional] operation withdraw(amount : Real);
    [transactional] operation deposit(amount : Real);
    operation balance() : Real;
    [transactional] operation transfer(other : Account, amount : Real);
end;

end.

In the example above, we applied the <<persistent>> stereotype to the Bank class, and the <<transactional>> stereotype to the withdraw, deposit and transfer operations. In order to have access to these stereotypes, we had to apply the “business_apps” profile to our model.

Conclusion

In this post/article on UML basics using TextUML, we saw how to declare stereotypes and apply them to elements in UML models. We learned that a stereotype must explicitly declare the metaclasses they are applicable to, and that optionally stereotypes might declare properties. Finally, we saw that before a stereotype can be used in a model, the profile declaring the stereotype must be applied to the model.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

Rendering UML2 models with Graphviz

2011-03-10 – UPDATE: this same facility is used in AlphaSimple for rendering UML models online.

The primary goal of the EclipseGraphviz project is to support Eclipse-based applications that want to use Graphviz as an easy way of producing non-interactive structured diagrams without requiring the complexity of GEF or GMF.

The TextUML Toolkit is the only application currently known to be based on the EclipseGraphviz project. To support rendering UML models generated using the TextUML textual notation, EclipseGraphviz has now the ability of rendering any UML model generated using the Eclipse UML2 API.

In this screenshot, you can see the UML model used in the article “Getting started with UML2” rendered with EclipseGraphviz:

getting-started-with-uml2-small.jpg

The main benefits are that the EclipseGraphviz graphical rendering of UML2 models is quite lightweight, and Graphviz produces great layouts automatically. The main caveat is that the diagrams are not interactive. Not to mention that EclipseGraphviz is still quite in its early stages, so it lacks maturity and features. And it does not run yet on non-Windows platforms.

There is where you can make a difference. Check out the project from the Subversion repository, give it a try, and contribute with bug reports, feature requests and patches.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

TextUML Toolkit 1.0 M2 is available!

After a few minor bug fixes and improvements to the test build, the M2 milestone of TextUML Toolkit is available. With this milestone you can:

  • create UML models using the TextUML textual representation
  • visualize the model created using the conventional graphical notation for class diagrams

This milestone does not support non-Windows platforms. But progress is being made in that direction. See below a screenshot of TextUML Toolkit running on Ubuntu Feisty Fawn:
ubuntu-first-small.jpg

Just go to the download page and fetch it, it is free with no restrictions (or guarantees). Make sure to check out the tutorial. Your feedback is most appreciated.

Now off to a long weekend on the beach…

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

A detour from a detour from a detour (or how a graphical viewing framework for Eclipse was born)

In the context of providing class diagram visualization for TextUML Toolkit, I have developed a simple graphical viewing framework for Eclipse. It is content type based, and allows you to view anything a content provider has been registered for. For instance, any image file supported by SWT:

Graphical viewer showing image files

But you can also view the graphical representation of a Graphviz DOT file, and it will even update as you edit the file:

Graphical viewer showing DOT files

And finally, and also the reason why I had to develop support for DOT visualization in the first place, you can also visualize a UML model (here showing a model created using the TextUML Toolkit):

Graphical viewer showing UML model

All these features (except for the TextUML Toolkit itself) are part of the EclipseGraphviz project, which is open source (EPL). No releases yet as this is still very new, but you can grab the source from the Subversion repository. If you would like to contribute to the EclipseGraphviz project, or to the graphical viewing framework, your help will be most welcome.

RC

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

Full code generation from UML class, state and activity diagrams

2011-03-10 – UPDATE: Interested in UML/TextUML and full code generation? You can now do that online using AlphaSimple

UML has become the lingua franca for modeling applications using the object-oriented paradigm. People use UML in many different ways (see the post on UML modes), ranging from as a communication tool to as a full fledged programming language that supports full code generation. This last way of using UML should puzzle most readers – how can UML models lead to full code generation?

UML has two diagrams that are used for behavior specification: the activity diagram and the state diagram. These two diagrams (more one than the other, depending on the nature of the subsystem being modeled), plus the class diagram (for modeling the structural aspects of the object model) provide the framework that supports the design of complex applications in a way that is fully complete (and thus allowing 100% code generation) while still implementation independent (see earlier post on platform independence). All the other diagrams (use case, sequence, collaboration) are interesting for gathering requirements, but are useless in modeling a solution that can be automatically transformed into a running application, and thus we will ignore them here.

Specifying structure with the Class Diagram

The class diagram is the most well understood of all diagrams in UML. You can model all structural aspects of your object model in the form of classes, attributes, operations and relationships between classes. This specification of structural aspects can then be used for generating (boilerplate) code, database schema, configuration files and so on so forth. This is great already, as that is most of the work. But without including behavioral aspects, it is impossible to do full code generation solely from the class diagram, you are forced to fill the empty methods with handwritten code (unfortunately this is how most vendors expect you to do model-driven development). Still, the class diagram is a fundamental one in which it provides a base framework the other diagrams can build upon.

Specifying dynamics with the State Diagram

The UML state diagram (derived from David Harel’s state charts) allows for a full design of the dynamic aspects of a system. One can model complex state machines using the state diagram, always in the context of a class described in the class diagram. Many mainstream applications do not have any interesting dynamics though, so in those cases the state diagram has limited value. However, in applications for certain industries (such as robotics, telecom and automotive) it is the most important diagram.

Specifying business logic with the Activity Diagram

The most underrated of the UML diagrams, the activity diagram has a key role: it is the only one to allow the modeler to specify behavior in a precise way. The Activity Diagram provides elements (such as actions, pins, data and control flows, signals) that allow specifying the meaning of a behavioral element (such as the body of an operation from the class diagram, or the effect of a state transition from the state diagram).

But no matter how important the UML activity diagram is, it has one strong limitation: it demands too much detailed information in order to be fully defined (and thus actually useful in the context of code generation). Any simple logic that could be written in a few lines in, say, Java, requires a graph with so many nodes that it is virtually impractical to use it with the graphical notation, severely hampering its more widespread adoption.

Have I just suggested that activity diagrams are useless for any serious usage? No! It is just the case that the graphical notation is too cumbersome, and it is not just a problem with the specific choice of symbols – there will never be any graphical representation that can be as expressive and concise for specifying behavior as your programming language of choice (even if your favorite language is as verbose as COBOL). So it is a matter of representation: a textual notation is much more appropriate than a graphical one. The activity diagram itself is fine, thanks.

So what is the textual notation for the activity diagram? There is none. I mean, not one defined by the OMG. Many companies have defined their own action languages (such as Pathfinder AL, Bridgepoint OAL, Kennedy Carter’s ASL) with compilers that provide a textual front-end for the UML activity diagram. TextUML itself has a bigger cousin (currently an ongoing work) that allows specifying UML activities in a way that is familiar to any programmer. Want to see what an action language looks like? Expect a new post on the subject (including our very own action language) here soon.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

Model-driven development improves reuse

One notable benefit of model-driven development that is often underrated is improved reuse. This is a direct consequence of appropriate separation of concerns promoted by this development approach. The more intertwined concerns are when addressed in a piece of code, the harder it is to reuse that piece of code. The reason is simple: whenever you tie a solution for one concern to a solution for another concern, you are in trouble: you cannot reuse that piece of code where only one of the concerns is relevant, or the solution for one of the concerns is not appropriate (even if the solution for the other concern is).

Model-driven development promotes an approach where problem-domain concerns are addressed separately from implementation concerns. That means artifacts dealing with problem-domain concerns are free from any specifics on target platforms, and also that artifacts addressing implementation-related concerns are totally unaware of any problem domain knowledge.

That is fantastic, and the reason is twofold:

  1. it makes it viable to build a repository of platform-independent problem-domain specific components, likely created by people that are experts in their domain, that can be reused on different target platforms;
  2. it allows implementation specialists to code their technology-specific implementation strategies as standalone artifacts (i.e. templates), which can then be shared and reused in applications for the most varied problem domains.

The software industry has been looking for a long time for a way of encapsulating knowledge about specific problem domains in the form of platform-independent software components. Model-driven development with true executable models enables that dream.

For many decades, valuable business logic has been imprisoned into obsolescence-prone implementation-specific artifacts. We are working hard on a product that will help stop this insanity and finally make the dream of truly reusable component repositories a reality.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

Platform independence in MDA

One key aspect of MDA is platform independence. However, even some of the brightest people in our industry misunderstand what platform independence means in MDA.

Platform independence has a different meaning in MDA than it has, for instance, in Java. Java promotes platform-independence by providing a common environment that insulates the application from platform details such as the instruction set and system API (for instance, for memory allocation, file system manipulation, networking, GUI, threading, etc). The application still has to address all these concerns, but it does that through API and mechanisms that work the same way regardless the actual underlying platform, and thus can run on any platform the Java environment is available. In other words, the Java environment is the platform.

MDA promotes platform-independence by adopting a design-centric approach. Models are removed from implementation related concerns and thus are inherently platform independent: a single design can be reused for building the same system for multiple target platforms. The implementation details are taken care of by target platform specific templates. The templates are applied to the user models then generating concrete platform-specific artifacts (running code, documentation, database schema, configuration files). Differently from Java (even if Martin Fowler says so), MDA does not promote another platform. What it does is to promote a clear separation between problem domain concerns and implementation concerns (as covered before here in the inaugural series entitled “Where we are coming from“).

The benefits of this separation are many: from unprecedented levels of reuse to better opportunities for work specialization. I plan to cover these benefits in detail on future posts.

RC

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

UML modes and tools

On his bliki, Martin Fowler eloquently describes the three different modes in which UML can be used: UML as sketch, UML as blueprint and UML as programming language. Let’s revisit the different modes from the perspective of tools for the job.

UML as sketch

Description: In this mode, UML is essentially a tool for conceiving and communicating ideas between team members. As such, there is no need for completeness or validity of the object models, and actually any information not essential for communicating the idea at hand is intentionally omitted for conciseness and clarity. UML as sketch is increasingly popular, even at shops where model-driven development is considered an abomination.

Tools for the job: developers don’t need special tools for using UML as a sketching tool, paper and pen or a whiteboard are great. The only flaws are when you would like to archive a drawing or send it to others by email. In that case, Visio (or any other generic diagram editor) is a common choice. Another less known option is Whiteboard Photo, that allows you to take a snapshot of your hand drawings (on a whiteboard or on paper) and have them automatically translated into great looking clean 2-D charts.

UML as blueprint

Description: in this mode, the focus is on having UML models used as an input to the implementation phase, and thus need to be valid and complete from the point of view of structure. Behavioral aspects are described in textual form (such as in use case descriptions) or by means of diagrams depicting scenarios (such as sequence or collaboration diagrams) and are inherently informally and incompletely described. The models can be submitted as input to code generation but the generated code has to be enhanced by hand to cover the behavioral aspects.

Tools for the job: generic tools won’t cut it here – you will need diagram editing tools that support all (or most) of UML diagrams, and (if you are taking the code generation route) persist your models in a format that your code generation tools can understand. Most UML tools out there support (or intend to support) this.

The TextUML Toolkit we provide supports this mode too. Your class diagrams are fully verified, and are persisted using a standard format.

UML as programming language

Description: In this mode, UML models must be complete both structurally and behaviorally as they must be simulatable and serve as input to code generation (by the way, Fowler really misses the point when he argues that a graphical language such as UML is not appropriate for fine grained behavior specification – who said UML is graphical anyway?).

Tools for the job: there are only a few tools currently in the market that support this mode, they tend to target embedded software development, and I bet you will not find how much they cost on their websites unless you call them.

Corcova Libra will support this, and when made available will visibly sport a reasonably fair price on our web site. Also, Libra will aim at mainstream business application developers, instead of focusing on specific vertical markets.

Conclusion

UML as sketch is cool and useful, but from the point of view of software engineering (our focus here) is meaningless.

UML as blueprint is increasingly practiced in shops where (partial) code generation has been adopted. It has benefits over writing the entire code by hand, but it still requires all the interesting code to be written manually, and there are a lot of issues with that.

Finally, UML as programming language (in other words, full blown model-driven development) is the most interesting of the three modes, even if there is a lot of skepticism and misinformation towards it. I will talk about that in an upcoming post.

RC

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

Graphical notation in the TextUML Toolkit

Even though a textual notation such as TextUML is much more productive when creating UML models, the graphical notation is still better for a high-level overview. So, for the next milestone of the TextUML Toolkit, the main feature planned is a model visualizer using the conventional graphical notation of UML.

The first option considered in implementing that feature was the UML2 Tools project, part of the Eclipse.org Model Development Tools project. UML2 Tools supports viewing and editing most of UML diagram types, and works seamlessly with models created using UML2 and EMF, which the TextUML Toolkit already uses, and that is great. However, it also requires GEF and GMF, what is bad because it significantly increases the download size for the TextUML Tookit (currently at 31MB), already high for the value it currently provides. Also, from some initial experimentation, it seems to be very computation and/or memory intensive. Because of that, it was decided a more lightweight alternative should be found, even more so if you consider interactivity and support for diagrams other than the class diagram are very low on our list.

Enter Graphviz and UMLGraph

Graphviz is an awesome tool for graph visualization. Graphviz takes simple text files (in the dot notation) describing the graph structure and produces great looking diagrams.

However, Graphviz is very generic, and does not know anything about the UML notation. That is when UMLGraph comes into play. UMLGraph produces dot files that generate OMG compliant UML diagrams (like the ones showing here).

So the direction is to adopt Graphviz and UMLGraph into a lightweight, non-interactive graphical viewer for UML class diagrams. We don’t dismiss having a more powerful graphical viewer (and editor) in the future, probably based on the UML2 Tools project, but the focus now is on simplicity.

There are two difficulties into adopting Graphviz and UMLGraph though:

  1. Graphviz is a native standalone tool, not a Java API
  2. UMLGraph, as a Java doclet, supports only one input representation: Java source with Javadoc comments

Turns out the first obstacle can be easily overcome by wrapping the Graphviz binaries into platform-specific fragments and providing a simple Java API on top of it.

The second obstacle is a bit trickier though. UMLGraph ties the usage of the doclet API into the generation of output in dot form. Breaking that coupling requires a non-trivial refactoring effort. I have been talking to UMLGraph author Diomidis Spinellis and he is keen on the decoupling, and that is the route we are going to take.

Would you like to see what it looks like? Make sure to check out the M2 milestone coming out in mid-June.

RC

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

A website and the first release!

There hasn’t been a post here for a while, but there is a good reason for that: we are glad to announce that we now have an actual web site (go see for yourself) and have simultaneously made the first public release! TextUML Toolkit 1.0 M1 is the first milestone of the tool we have developed for creating UML models in a way that is more natural to hard-core developers. If you want to know more, go read the overview, download the tool and try out the tutorial.

After a long period of silence, I almost pity that I have somehow crammed too many great news on a single post…

RC

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter