abstratt blog

Using UML2 in a server-side application? Read this.

25th January, 2011 - Posted by rafael.chaves - 3 Comments

For those of you who didn’t know, AlphaSimple, our web-based modeling tool, is strongly based on Eclipse technologies:

• the server runs Equinox with the web server (Jetty) running as an OSGi bundle
• we use UML2 for building models (during model compilation), or for traversing them for execution, code generation, diagram rendering etc

UML2 is quite a piece of software. It implements the huge UML spec more thoroughly than any other alternative library (open source or not). Much of what I learned about UML in the last 5 years I learned by dealing with the UML2 API. Kenn Hussey and James Bruck have done a great job on the front of compliance.

On the not-so-great side, development seems to have stopped. IBM, which founded (and funded) the project, apparently pulled the plug last year. The current UML version supported is 2.2 whereas UML 2.4 is coming out soon. The newsgroup has no one that actually knows the code answering questions (I try, but I am far from familiar with the internals of UML2). This is not only an impediment to adoption, but may scare existing adopters away.

But even ignoring those strategic issues, there are technical problems as well: the one we faced with UML2 is thread-safety, which currently makes it unusable for long-running/highly concurrent applications. For a server-side application like AlphaSimple, that is a showstopper. Case at hand: even if we create, load and dispose UML2 resources in a single thread, internally UML2 uses a singleton object that caches cross-references between elements – for all models, and across all threads. That  introduces unnecessary contention between threads that are doing fundamentally unrelated work, but worse, this cache is not fully thread-safe (see bugs 335135 and 332057), and I suspect can’t be made thread-safe by design.

Q: how does one deal with showstoppers? A: with drastic measures.

In the case of AlphaSimple, where we explicitly unload all UML2/EMF resources in the same thread we loaded them (instead of relying on garbage collection), there really is no place for a singleton complex data structure that is intensively used for anything model-related. So our drastic measure (which I am not proud of) was to patch UML2 so the cache adapter is thread specific (by replacing CacheAdapter.INSTANCE with CacheAdapter.getInstance() and returning a thread-specific “singleton”). Luckily the changes required were quite small:

org.eclipse.uml2.uml/src/org/eclipse/uml2/uml/internal/impl/ElementImpl.java

retrieving revision 1.43
diff -r1.43 ElementImpl.java
818c818,819
< 		return CacheAdapter.INSTANCE;
---
> 		//RC - hack to avoid thread safety issues with CacheAdapter
> 		return CacheAdapter.getInstance();

org.eclipse.uml2.uml/src/org/eclipse/uml2/uml/util/UMLUtil.java

retrieving revision 1.88
diff -r1.88 UMLUtil.java
197,198c197,198
<
< 			CacheAdapter.INSTANCE.adapt(stereotypeApplication);
---
> 			//RC - hack to avoid thread safety issues with CacheAdapter
> 			CacheAdapter.getInstance().adapt(stereotypeApplication);

org.eclipse.uml2/plugins/org.eclipse.uml2.common/src/org/eclipse/uml2/common/util/CacheAdapter.java

retrieving revision 1.26
diff -r1.26 CacheAdapter.java
119,120d118
< 	public static final CacheAdapter INSTANCE = createCacheAdapter();
<
537a536,546
> 	//RC - hack to avoid thread safety issues with CacheAdapter
> 	private static final ThreadLocal<CacheAdapter> INSTANCE = new ThreadLocal<CacheAdapter>() {
> 		protected CacheAdapter initialValue() {
> 			return createCacheAdapter();
> 		}
> 	};
>
> 	public static CacheAdapter getInstance() {
> 		return INSTANCE.get();
> 	}
>

This is not a real fix in the sense that it may not work for all applications – for instance, applications that read/create models across different threads. So now we need to manage this patch instead of just getting UML2 from the target platform. But comparing to having a server that keeps failing, we are quite happy with that.

If you can see an issue with this workaround, or if you think I am wrong by believing UML2 cannot be made thread-safe without radical modifications, speak up.

The value of UML (or lack thereof) in the development process

10th January, 2011 - Posted by rafael.chaves - 5 Comments

[What follows was adapted from a discussion on LinkedIn on why companies developing software don't use UML more]

UML proponents argue that by using UML one gains the ability to properly represent important knowledge on the problem domain and intended solution design. That leads to good things such as improved communication and better quality of the software.

I certainly don’t question that. The ability of devising a solution at the right level of abstraction is extremely important. Yet, that on its own is not enough. It doesn’t help if the language that allows you to specify a solution at the right level of abstraction does not lead to running code (via code generation or direct execution). If one has to specify a solution again by implementing by hand (say, in Java or C#) what the model describes (i.e. using the model as a reference), that greatly offsets any gains from modeling. As the agilists say: Don’t Repeat Yourself. I won’t bore you with the consequences of breaking that simple rule, it must be obvious to any developer worth their salt.

If you are going to be pragmatic, and you cannot generate running code from your models, from a developer’s point of view, there is no much value for UML in the development process.

Developers play an increasingly important role in software product development. Non-executable UML models are seen as fluff, an unnecessary burden to software developers, and hence the poor reputation with that crowd, as the majority of the places using UML is unfortunately using it that way.

I see two solutions for this: either get models to be executable, or get programming languages to support a higher level of abstraction. Even though I am a believer of the former (and our work at Abstratt follows that approach – see AlphaSimple and TextUML Toolkit), I won’t be surprised if the latter ends up being the winning approach (see RAD frameworks such as Grails and Rails).

Do you agree? Which approach do you prefer? Why?

Take control over UML class diagrams in AlphaSimple

5th January, 2011 - Posted by rafael.chaves - No Comments

As recently announced, shared models in AlphaSimple now sport UML class diagrams thanks to Graphviz support in the Google Charts API .

What I didn’t mention is that you can customize how diagrams are rendered by specifying query parameters on the image URL. For instance, compare the basic diagram from the previous post with the customized diagram below (click on it to see the URL). Can you spot the differences?

Here are all supported options:

• showAssociationEndOwnership (boolean)
  
• showStructuralFeatureVisibility (boolean)
• showAssociationEndMultiplicity (boolean)
• showAssociationName (boolean)
• showAssociationEndName (boolean)
• showClassifierCompartmentForPackage (Current, Immediate, Any)
• showClassifierStereotypes (boolean)
• showElementsInOtherPackage (Never, Immediate, Always)
• showEmptyClassifierCompartments (NotEmpty, Never, Always)
• showFeatureStereotypes (boolean)
• showParameterDirection (boolean)
• showPrimitives (boolean)
• showRelationshipStereotypes (boolean)

Give it a try (don’t forget you need to share your projects, and republish for changes to become visible to others). Are there more control options you would like to see?

Generate UML diagrams online (using AlphaSimple)

2nd January, 2011 - Posted by AlphaSimple Team - 5 Comments

As briefly mentioned in a previous post, you can now render UML class diagrams using AlphaSimple. This is how you do it:

1. sign up for AlphaSimple (it’s free)
2. create a project
3. create your models using the TextUML notation (tutorial, reference). Make sure you use no extension or use .tuml as file extension.
4. once your project is valid, publish it
5. back to your project list (“My Projects”), share the project by clicking the open lock button. Note that when you do that you make your project available for any users to see and copy.
6. now on the shared project list (“Shared Projects”), find and open your project – you will see a “Model Diagram” tab – there is your diagram! If you want to share your diagram with others, you can copy the image location and pass that URL around.

Here is an example of diagram produced for project “Lesson #5 – All together now“:

How does it work?

If you are interested in understanding what is involved here:

1. AlphaSimple uses the TextUML compiler from our open source TextUML Toolkit project translating TextUML source files into UML models (using the Eclipse UML2 format).
2. AlphaSimple also uses the TextUML Toolkit component (based on the EclipseGraphviz project) for generating Graphviz dot diagrams from UML models.
3. For rendering the actual diagram from the dot description, instead of directly using Graphviz, AlphaSimple uses Google’s Chart API support for rendering dot diagrams.

This is all very new, so there may be some rough spots. If you have any issues, or have suggestions, send them our way.

New features in AlphaSimple: editor tabs and class diagrams

17th December, 2010 - Posted by AlphaSimple Team - 1 Comment

This week we deployed two cool new features in AlphaSimple.

The first feature is editor tabs:

With editor tabs, you get the entire browser window width for your source files, which in the past would have required you to collapse the file list (and lose context of what other files exist in the project).

The second feature is rendering of class diagrams:

Rendering of models as class diagrams provides yet another view into your model, in addition to the textual notation and the prototype. This feature needs more work but we wanted to get it out quick even if not fully baked to get some early feedback.

We hope you like it. Either way, we are eager to hear your opinion.

Read More

On model-to-model transformations

21st November, 2010 - Posted by rafael.chaves - 1 Comment

There was some strong (but polite) reaction to some comments I made about the role of model-to-model (M2M) transformations in model-driven development.

My thinking is that what really matters to modeling users (i.e. developers) is that:

1. they can “program” (i.e. model) at the right level of abstraction, with proper separation of concerns
2. they can automatically produce running code from those models without further manual elaboration

In that context, M2M is not a requirement. That is not to say that to support #2 above, tools cannot use model-to-model transformations. But that is probably just an implementation detail of that tool, all that modeling users care is that they are able to model their solutions and produce working applications. Of course, modeling experts will be interested in less mundane things, and more advanced aspects of modeling.

Also, my comments were about model-driven development (MDD), and not model-driven engineering (it seems most people disagreeing with me are from the MDE camp). To be honest, I didn’t even know what MDE meant until recently (and I know that MDE contains MDD), and have just a superficial grasp now. To be even more honest, I am not interested in the possibilities of the larger MDE field. At least not for now. I will explain.

You see, I think we still live in the dark ages of software development. I want that situation to change, and the most obvious single thing that will let us do that is to move away from general purpose 3GLs to the next level, where developers can express themselves at the right level of abstraction, and businesses can preserve their investment in understanding their domain while at the same time being able to take advantage of technological innovation. Hence, my deep interest in making MDD mainstream.

I see value in the things beyond MDD that MDE seems to be concerned with (mining existing systems for models, model-level optimization). I just don’t think they are essential for MDD to succeed. Thus, I prefer to just cross that stuff off for now. We need to lower the barrier to adoption as much as we can, and we need to focus our efforts on the essentials. The less concepts we need to cram into people’s minds in order to take MDD to the mainstream, the better. It is already hard enough to get buy-in for MDD (even from very smart developers) as it is now. It does not matter how powerful model technology can be, if it never becomes accessible to the people that create most of the software in the world.

AlphaSimple: Easier repository browsing

27th August, 2010 - Posted by AlphaSimple Team - 1 Comment

Earlier this week we deployed a great new feature: project browsing mode. You can now open any of the shared projects, and view prototype and model side-by-side:

It is now much easier to learn how a model relates to the prototype. If you are logged in, and you like a project, you can clone it and start working on your own version right away. Try now!

AlphaSimple gets a REST API

23rd August, 2010 - Posted by AlphaSimple Team - No Comments

AlphaSimple just got a REST API. For any shared projects, you can get the project model (which includes access to source and XMI files) with a URI in the form “http://alphasimple.com/mdd/publisher/{userid}-{projectid}/”. For example, for:
http://alphasimple.com/mdd/publisher/rafael-26/

you get: (more…)

AlphaSimple: Doors wide open

14th August, 2010 - Posted by AlphaSimple Team - No Comments

During the beta period registered users have access to the full service for free. The advantage of signing up is that your files are stored on the site and you can always come back and continue from where you’ve left off.

Sign up now and let us know what you think.

AlphaSimple: Syntax highlighting is back!

12th August, 2010 - Posted by AlphaSimple Team - No Comments

We have turned syntax highlighting back on. It looks a lot nicer to prototype. Also, you can use Ctrl+S for saving, and the file list can be collapsed.

There are also some improvements for IE although we still recommend using Firefox, Chrome or Safari.

Go ahead, try it out and tell us what you think!

Model interpretation vs. code generation? Both.

7th August, 2010 - Posted by rafael.chaves - 4 Comments

Model interpretation vs. code generation? There were recently two interesting posts on this topic, both generating interesting discussions. I am not going to try to define or do an analysis of pros and cons of each approach as those two articles already do a good job at that. What I have to add is that if you use model-driven development, even if you have decided for code generation to take an application to production, it still makes a lot of sense to adopt model interpretation during development time.

For one, model interpretation allows you to execute a model with the fastest turnaround. If the model is valid, it is ready to run. Model interpretation allows you to:

• play with your model as you go (for instance, using a dynamically generated UI, like AlphaSimple does)
• run automated tests against it
• debug it

All without having to generate code to some target platform, which often involves multiple steps of transformation (generating source code, compiling source code to object code, linking with static libraries, regenerating the database schema, redeploying to the application server/emulator, etc).

But it is not just a matter of turnaround. It really makes a lot more sense:

• you and other stakeholders can play with the model on day 1. No need to commit to a specific target platform, or develop or buy code generators, when all you want to validate is the model itself and whether it satisfies the requirements from the point of view of the domain. Heck, you might not even know yet your target platform!
• failures during automated model testing expose problems that are clearly in the model, not in the code generation. And there is no need to try to trace back from the generated artifact where the failure occurred back to model element that originated it, which is often hard (and is a common drawback raised against model-driven development);
• debugging the model itself prevents the debugging context from being littered with runtime information related to implementation concerns. Anyone debugging Java code in enterprise applications will relate to that, where most of the frames on the execution stack belong to 3rd-party middleware code for things such as remoting, security, concurrency etc, making it really hard to find a stack frame with your own code.

Model-driven development is really all about separation of concerns, obviously with a strong focus on models. Forcing one to generate code all the way to the target platform before models can be tried, tested or debugged misses that important point. Not only it is inefficient in terms of turnaround, it also adds a lot of clutter that gets in the way of how one understands the models.

In summary, regardless what strategy you choose for building and deploying your application, I strongly believe model interpretation provides a much more natural and efficient way for developing the models themselves.

What are your thoughts?

TextUML Toolkit 1.6 declared!

5th August, 2010 - Posted by rafael.chaves - 7 Comments

The TextUML Toolkit version 1.6 has been released. It is the same RC1 build mentioned here a week ago. The listing on the Eclipse Marketplace has been updated, so in addition to the regular update site (http://abstratt.com/update/), if you are using Eclipse 3.6, you can get it even more conveniently using the brand new Eclipse Marketplace Client.

Take a look at the new notation features:

• preconditions on operations

operation withdraw(amount : Real);
precondition { amount > 0 and amount < self.balance }
begin
    self.balance := self.balance - amount;
end;

• derived properties

reference employees : Employee[*]

/* calculated field */
derived attribute employeeCount : Integer := ():Integer { return self->employees.size() };

• initial values on properties

attribute available : Boolean := true;

You can also try these new features online on AlphaSimple. Sign up or start a guest session to create, validate and run your models on the spot, there is nothing to install!

TextUML Toolkit 1.6 RC1 is now available

26th July, 2010 - Posted by rafael.chaves - 4 Comments

TextUML Toolkit 1.6 RC1 is now available! You can install it using the Marketplace Client or by pointing Eclipse to the update site:

http://abstratt.com/update

If you find any problems installing this build, please let us know asap so it can be addressed before the final release.

New features

Much of the work in this release went into improving the model building infrastructure to be even more notation agnostic. That work is still ongoing and should be completed in 1.7. But there were plenty of user-facing feature additions as well:

• preconditions on operations (2986923 and 3002571)
• support for a default notation (so file extensions can be optional) (2995372)
• support for implicitly applying profiles/stereotypes (so models are less verbose) (2981580)
• support for derived properties (2928428)
• support for initial values in properties (2115439)
• advanced features (closures, constraints) are now implemented using profiles instead of metamodel extensions (2933692)

In other news

The reason it took so long for a new TextUML Toolkit release to come about was that I have been busy working on AlphaSimple, which went on public beta today. AlphaSimple is an online tool for domain-driven prototyping that currently uses TextUML as modeling notation. Thus, AlphaSimple is also the driving force behind most of the changes that happened in the 1.6 cycle, and you can try them right away by starting a guest session and studying the example projects.

AlphaSimple public beta starting today!

26th July, 2010 - Posted by AlphaSimple Team - 1 Comment

It’s official. AlphaSimple is now available in open beta for anyone who wants to try. Take a look and let us know what you think. This initial release brings a simple yet effective web-based environment for domain-driven prototyping.

Don’t know what AlphaSimple is?

AlphaSimple is an environment for rapid prototyping. You compose your domain model using an in-browser editor. The model is automatically validated every time you save. Play with your prototype right away. Rinse. Repeat.

AlphaSimple is an online tool for collaborative creation. Once you are happy with your prototype, publish it and send the URI to clients, team members, anyone you would like to see it no matter where they are.

AlphaSimple is a place for sharing. Feeling proud of your work? Share your projects for others in the community to learn from you. It’s just a button away.

AlphaSimple is a place for learning. Don’t know where to start? Browse the catalog of public projects, play with a prototype, and clone it to make it your own. No easier way to learn. If you still need help, the AlphaSimple community forum is there for you (and there is some documentation too).

What are you waiting for?

Take AlphaSimple for a spin. If you are unsure about signing up, try it as a guest. Except for sharing/publishing projects, guest sessions are full-featured.

UPDATE on browser compatibility: the browsers we have been testing on are Chrome and Firefox. Syntax highlighting is broken on Safari, so it has been turned off by default (you can turn it back on). AlphaSimple does not work on Internet Explorer at this time. Flash is required for running prototypes.

AlphaSimple: Public beta around the corner

4th June, 2010 - Posted by AlphaSimple Team - No Comments

We are currently working on the first public beta of AlphaSimple, which should happen early this Summer. The AlphaSimple private beta generated some good feedback, and we are making sure the best ideas and suggestions make it into the product. We also want to make this first public beta so solid you will want to use it in your work right now.

It should not take long now. Bear with us, we don’t think you will be disappointed.

AlphaSimple: First private beta coming soon!

25th April, 2010 - Posted by AlphaSimple Team - No Comments

We are working hard to get the first private beta version of AlphaSimple out of the door.  Stay tuned! If you would like to participate, just send a note to support, or head to the forum.

UML may suck, but is there anything better?

8th February, 2010 - Posted by rafael.chaves - 19 Comments

UML has been getting a lot of criticism from all sides, even from the modeling community. Sure, it has its warts:

• it is a huge language, that wants to be all things to all kinds of people (business analysts, designers, developers, users)
• it has a specification that is lengthy, hard to navigate and often vague, incomplete or inconsistent
• it is modular, but its composition mechanism (package merging) is esoteric and not well understood by most
• it is extensible, but language extensions (profiles and stereotypes) are 2nd-class citizens
• it lacks a reference implementation
• its model interchange specification is so vague that often two valid implementations won’t work with each other
• its committees work behind closed doors, there is no opportunity for non-members to provide feedback on specifications while they are in progress (membership is paid)
• <add your own grudges here>

However, even though I see a lot of room for improvement, I still don’t think there is anything better out there. The more I become familiar with the UML specification, the more impressed I am about its completeness, and how issues I had never thought about before were dealt with by its designers. And it seems that the OMG recognizes some of the issues I raised above as shortcomings and is working towards addressing them. Unfortunately, some fundamental problems are likely to remain.

In my opinion (hey, this is my blog!), for a modeling language to beat UML:

• it must be general purpose, not tailored to a specific architecture or style of software
• it must not be tailored to an implementation language
• it must be based on or compatible with the object paradigm
• it must not be limited to one of the dominant aspects of software (state, structure, behavior)
• it must be focused on executability/code generation (and thus suitable for MDD) as opposed to documentation/communication
• it must be modular, and user extensions should be 1st class citizens
• its specification should follow an open process
• it must not be owned/controlled by a single company
• it must not require royalties for adoption/implementation

My suspicion is that the next modeling language that will beat the UML as we know today is the future major release of UML. Honestly, I would rather see a new modeling language built from scratch, focused on building systems, that didn’t carry all that requirement/communication/documentation-oriented crap^H^H^H^Hbaggage that UML has (yes, I am talking about you, use case, sequence, instance and collaboration diagrams!), and developed in a more open and agile process than the OMG can possibly do. But I am not hopeful. The current divide between general purpose and domain specific modeling communities is not helping either.

So, what is your opinion? Do you think there are any better alternatives that address the shortcomings of UML without imposing any significant caveats of their own? Have your say.

Myths that give model-driven development a bad name

6th February, 2010 - Posted by rafael.chaves - 17 Comments

It seems that people that resist the idea of model-driven development (MDD) do so because they believe no tool can have the level of insight a programmer can. They are totally right about that last part. But that is far from being the point of MDD anyways. However, I think that unfortunate misconception is one of the main reasons MDD hasn’t caught on yet. Because of that, I thought it would be productive to explore this and other myths that give MDD a bad name.

Model-driven development myths

Model-driven development makes programmers redundant. MDD helps with the boring, repetitive work, leaving more time for programmers to focus on the intellectually challenging aspects. Programmers are still needed to model a solution, albeit using a more appropriate level of abstraction. And programmers are still needed to encode implementation strategies in the form of reusable code generation templates or model-driven runtime engines.

Model-driven development enables business analysts to develop software (a variation of the previous myth). The realm of business analysts is the problem space. They usually don’t have the skills required to devise a solution in software. Tools cannot bridge that gap. Unless the mapping between the problem space and solution space is really trivial (but then you wouldn’t want to do that kind of trivial job anyways, right?).

Model-driven development generates an initial version of the code that can be manually maintained from there on. That is not model-driven, it is model-started at most. Most of the benefits of MDD are missed unless models truly drive development.

Model-driven development involves round-trip engineering. In MDD, models are king, 3GL source code is object code, models are the source. The nice abstractions from the model-level map to several different implementation artifacts that capture some specific aspect of the original abstraction, combined with implementation-related aspects. That mapping is not without loss of information, so it is usually not reversible in a practical way, even less so if the codebase is manually maintained (and thus inherently inconsistent/ill-formed). More on this in this older post, pay attention to the comments as well.

Model-driven development is an all or nothing proposition. You use MDD where it is beneficial, combining with manually developed artifacts and components where appropriate. But avoid mixing manual written code with automatically generated code in the same artifact.

What is your opinion? Do you agree these are myths? Any other myths about MDD that give it a bad name that you have seen being thrown around?

Rafael

Interview at Modeling-Languages.com

25th January, 2010 - Posted by rafael.chaves - No Comments

Last December I had the pleasure of being interviewed by Jordi Cabot, the maintainer of Modeling-Languages.com, a web site on all things model-driven. We talked mostly about the TextUML Toolkit project, but Jordi also asked about my opinions on more general subjects, such as modeling notations, textual modeling frameworks, DSLs, UML and trends in modeling.

Jordi has recently made a transcription of the interview available on his web site. Take a read, feel free to leave a comment, I am very keen on discussing on any of the topics covered.