Saying No is cheap

Elementary
Although it sounds logical, there is a danger in standardizing in software. Since I started worked on software automation, modelling and software factories I have had very different reactions.
The positive ones are like this:

• Wow, this cuts down development time with at least 75%
• So you are saying we don't have to redevelop when technology advances?
• Great, so we can specialize development roles and make everybody way more productive in their own tasks

But the negative ones more or less say:

• This is not standard software you are using (or it is not Microsoft, Red Hat, IBM, Google, Apple, ....)
• You have great tools and we would like to use it, but you are not on our preferred suppliers list
• Great, but I am not sure if we have the technical knowledge to be able to understand the open source software stack you are using so we better stick to something we can ask any development company to do for us

Prove it

We have been hearing this for almost 20 years now, and in the beginning there was also some talk about the bigger companies coming up with something like that soon. That never really happened, but the other arguments remained. 

Even in companies were we implemented our process and tools and saved millions of euros every year and got 100% success rate on every project year after year, the discussion remained the same. 

Yes or No

The point I would like to make is the underlying philosophy when choosing 'standard' software and 'proven' tools over advanced technology: "it is better to do development like most of the industry so we are not depending on 'smart people'". I think here are three flaws with this line of reasoning:

1. You underestimate the potential of your developers when you enable them
2. The consequence of this argument is you prefer doing things 'not so clever' to enable everybody to do it for you....
3. Ultimately you are waiting for your competition to be the first to do it smarter and advance the standard

Saying NO to an idea is cheap, but in the end there might be an implicit YES to something connected to that NO, that is a lot worse. Just like in politics it is easier to get a lot of people say NO to an idea, than it is to make them say YES. When you are able to get a true YES, it can change the world so we keep telling our story. Like the people on the Software Development Automation conference in a couple of weeks!

That extra push

Sitting at Cleveland Airport right now after a very interesting week in the US. First there was EclipseCon2009 with a lot of good presentations, tutorials and interesting people to meet. I learned about the latest developments and ideas around Eclipse and the modelling community which is very valuable for our Software Factory solutions.
My PMF presentation went well I think considering the number of interested parties and people asking questions afterwards. There was a lot going on in the UI space:

• declarative UI
• e4
• Redview dynamic views
• live models

All had a different perspective on UI development so it was good to get more detail on these approaches. PMF focuses on the platform independent level and I was reassured that it still fills a void there. We do need a little extra push to get the project created and a first unified release out to satisfy the demands.

Talking about extra push, I visited the Cleveland Cavaliers last night and was realy impressed by the event. I have been wanting to see an NBA game live for about 25 years so it was special anyway, but the King impressed me. I had floor-level seats behind the basket on the side of Cavs bench so I could see them up close. As Lebron is the main man, you can imagine the sell-out crowd making some noise after he is hit with a flagrant foul. He was an all-state football player and stands at 6-8 and 250 pounds so he can take a hit. I was just thinking that may pump him up a little more and a few seconds afterwards he goes backdoor and throws down a great pass with authority. Take a look here to see for yourself. You might even see me in the yellow 'Witness' shirt behind the basket. Even LJ sometimes needs an extra push to rise to the top level!

EclipseCon is always an extra push for me. Hope to recover from the jetlag to get back to work and bring UI development to a new level...

Truth hits

Every once in a while you hear a song and either through the music or the lyrics alone, it touches you deeply. For me, someone who touched me a lot with his music is Van Morrison. "Cleaning windows" was the first time, as I recognized myself as a "working man in his pride", but there are numerous songs by Van the Man that hit home.
During a tough period in my life Elvis Costello's "I want you" went straight through my heart. To have a paragraph of text in a mailing list touch you deeply is extermely rare. Still that is what happened when I read one of Ed Merks' contributions last year on the e4-dev mailing list about choices in architecture. I have been meaning to blog about that statement for a while and I will try to talk to him about it at EclipseCon2009:

Given that architecture involves tradeoffs, optimal is not at an extreme end of some simple curve. There are saddle points as well as various hills, dips, and valleys. So not only is optimal difficult to find, it's difficult to define. So, a design is ultimately arrived at that makes specific tradeoffs. Then someone new comes along and finds a specific tradeoff they feel is less than optimal. They call this a fatal flaw and it represents the reason for a new expedition to explore the territories to find the top of a higher mountain. They'll likely only find another hill and likely it will be no higher (since height is ill defined), but most certainly it will be in a different location, thereby ensuring that the process will always repeat. Given enough exploration, I can hope folks will see the similarities between the hills.

I think this is view is essential when you work on software tooling, libraries and API's. I have tried to bring this point across in many discussions, but never managed to put it as eloquently as Ed did. You make choices and you try to find a sweet spot. It is always easy to find an aspect that can be improved and say you better start fresh and take care of that aspect better. Refactoring is another matter, but throwing it away to do it al yourself is what they call the NIH syndrome. Especially in an Open Source project where people invest a lot of personal time and effort into it, leaving your own 'baby' and work on someone else's software to improve it, is not always easy. In the end though, most of the time it is better to work on it together and try to bring it from good to great.

The Eclipse community is a showcase of what can be achieved if you follow that philosophy. EclipseCon is the ultimate venue to talk to people who develop software this way. Only 8 days and counting!

PMF BOF, say what?

It's only a few weeks to EclipseCon2009 and the excitement is growing. In the last couple of months several organizations approached us to take part in PMF or at least express their interest. It assured me that the project fills a void in the Eclipse project set, but it also created a sense of responsibility. We have to do this right and serve the community well in the spirit of the Eclipse Modeling Project. If we do it right, different efforts can take advantage of each other and we can advance the state of the art in UI development. With UI Modeling the MDSD stack can cover another crucial part of the software development process.

Maybe you are wondering what PMF has to do with StUIML. Well, what's in a name? StUIML is very hard to pronounce for non-Dutchies and PMF is not a one man effort. The ideas and concepts of StUIML are taken to PMF and the name is more in parallel with other Eclipse Projects.

When you talk about user interfaces and the presentation layer in general there is such a broad spectrum to cover. From abstract modeling to very specific target platform API's, but also from developer editors or content management to enterprise application flows.
That is why I think the PMF BOF (Birds Of a Feather) is so important. We need to know what the community needs most when developing UI's. Also, it is a word that used to make my stomach hurt and my heartbeat rise, but I have to admit: 'expectation management' is important...

If you are visiting EclipseCon and you are interested in UI development or have ideas you would like to share on this subject, please come and speak out. If you want to speak out for a smaller crowd or completely anonymous drop me a line. I am very good at keeping secrets and protecting my sources....

As stated in the BOF proposal, we would like to collect ideas for example applications that all of the PMF participants can target. We can create a lab of showcases for the public to evaluate different approaches to UI modeling and MDSD development in general. We are convinced that UI modeling can make MDSD more accessible to the development community.

So speak out now, or....talk to us later!

Who's King?

The interest in UI modeling has grown during the last year, resulting in a quite impressive group of interested parties and participants for our Presentation Modeling Framework project at Eclipse. During ESE and afterwards we had a lot of discussion about modeling UI's at different abstraction levels. PMF aims to cover the whole spectrum hopefully creating a vibrant ecosystem of models and tooling to pick from.

There are quite a few examples of UI modeling using annotations or marking models to define a UI. The idea behind it is to use the information from the domain model to quickly define a user interface. The advantages are ease of specification and direct use of the domain model available. In my opinion this is great for basic editors and CRUD-like user interaction, but will break down for enterprise level administrative applications where the process and task structure is dominant. It's a question of "who's king?". If you just need property editors and developer style user interfaces, direct representation of domain objects on the UI is sufficient. If you need different viewpoints using various combinations of domain data in numerous scenarios, naked objects will not get you there. Process, task and user interface are king!
A full DSL (on any abstraction level) is needed to support the demanding UI requirements of modern day end users. The UI model is the starting point. The UI model will reference domain concepts and constraints and work together with process descriptions. This is ofcourse what will be provided in the PMF project and shown for the first time during EclipseCon 2009.

I am very excited about everything happening around UI modeling and I hope our PMF talk at EclipseCon will raise the awareness of all the possibilities. Hope to see you there.

Another thing I am looking forward to besides EclipseCon and the great modeling people is the day after EclipseCon. As an ex-basketball dutch international I always wanted to attend an NBA basketball game. In 2009 this will finally happen as I have tickets for the Cleveland Cavaliers game on the 27th to see King James in action! No question who's king in Cleveland. Like in modeling land it does depend on where you are and who you talk to. In LA the question: who's king will get you a completely different answer...

Happy holidays

Jim

See you at ESE2008

Sorry for the long silence. After EclipseCon2008 which was great and generated a lot of attention for UI Modelling I planned to write the next blog about the publicly available metamodel.
Due to IP issues and working hard on a large Client project using StUIML, I have not been able to do just that.
It will happen though! Just a few more weeks now...
To keep you in the loop and talk about all the great possibilities of having a PIM level UI Model we could meet at ESE2008. I can show you cool stuff and tell you about the plans we have for a PMF project (Presentation Modelling Framework) at Eclipse and integration with other projects.
I am also very interested in any modelling and software factory projects you are working on.

Magnum PI

Anyone of my generation reading this title associates it with Tom Selleck. The PI that is a friend of Rick and T.C. stands for Private Investigator, but the PI in PIM I would like to blog about stands for Platform Independent.

MDA describes a transformation of models from PIM (or even CIM) to PSM to code. As StUIML is a PIM level UI Modelling language it should be platform independent. This is not as easy as it sounds, but very important. A lot of the DSL's and Software Factory approaches targeting the UI make use of elements like WebFlow or require a choice for a communication protocol.
Why is this bad? The whole meaning of the PIM level is to be able to reuse a single PIM for several technical platforms depending on the context or requirements. The advantage of using StUIML is that you can generate the models to a Web environment, a rich client desktop application, an embedded device or a character based screen without changing the PIM.

The implicit separation of aspects through the use of different modelling levels enables specialisation for each level. Just like more mature industries, we need specialisation to be able to be reliable, productive and cost efficient.

The StUIML workflow recognizes three separate tasks:

1. functional specification of the UI: specify the intentions
2. technical translation to the target platform: mapping the intentions to platform display technology
3. designing the look and feel: layout and styling

The levels are downward dependent so level 1 has no knowledge of choices made in higher levels. In future blogs I will elaborate some more on the issues we have encountered when keeping StUIML purely PI, but right now I will have to get my presentation ready for EclipseCon.

The root of all things UI

So what is that StUIML metamodel all about?
There are two main root metamodel elements in StUIML:

1. Dialogue
2. Process

A dialogue according to Merriam-Webster's dictionary is

"a conversation between two or more persons or a similar exchange between a person and something else (as a computer)"

In StUIML a Dialogue defines how information is gathered from a person or presented to a person by an application. There are a number of specialisations of Dialogue in the metamodel depending on the underlying intention, but we will dive into that later.
A Process can contain Dialogue-, Operation- and Process-calls depending on the type: an InteractiveProcess can contain Dialogues while an AutomatedProcess cannot.

Below you can see a stripped metamodel diagram of StUIML with the root elements.

StUIML is a PIM-level DSL for user interfaces. Because of this 'narrow' target domain StUIML depends on other DSL's to provide a domain model and constraints. In the past StUIML was used in combination with the following domain model languages: UML, ecore and two customer specific domain model DSL's. The UI target platforms where Swing and MFC for rich clients and JSF and ASP.Net on the web.
Just today I was asked to support a character based UI (charva) as a target platform and I see no reason why that cannot be done.

StUIML refers to the domain metamodel for references to basic OO concepts like classes, properties and associations. The domain model that is referenced from StUIML models does not have to be identical to a backend domain model. In the current SOA practice the domain model for the UI is based on the definition of service data.

All UIModelElements in StUIML have a context classifier that defines the starting point for navigation in the element. Another important property of all UIModelElements is the intention defining the goal of the element. Several types of conditions/constraints can be linked to the elements to enable dynamic behaviour.

In one of the next postings I will work out an example to show how these basic concepts can help you model UI's quickly. If you want to see live demos and coding examples come to EclipseCon2008 and visit my StUIML talk!

The StUIML principles

As my full articles are not ready yet (working around the clock on a Software Factories project for a large dutch Insurance Company), I thought it would be a good idea to reveal the basic principles that StUIML is based on:

1. The UI model should never pose requirements for the domain model


2. Reuse at the model level is key, so each UI model component should follow the 'strong cohesion, loose coupling' principle


3. The percentage of generated code should be well above 90% and preferable > 95%

The antipatterns that the principles above avoid can be seen in many UI development projects:

Allthough n-tier architecture is widely adopted it is still commonplace to add domain model features to accomodate the UI tier.

Programming logic, navigation and content inside a single screen class is another common trap, because of the RAD style of development where a single screen is the focus for developers.

If you only generate 40% or 60% of the UI, you quickly loose some of the advantages of MDSE, because of synchronisation and uncontrolled dependencies. There are too many DSL's that are only used in the first iteration. They are abandoned and the generated code is just a starting point for traditional manual labor.

Next time I will describe the key concepts (metamodel elements) in StUIML.

StUIML at EclipseCon2008

The upcoming EclipseCon2008 will show two StUIML related talks:

Intentional UI Modeling talks about the background and features of StUIML and the role of WYSIWYG in combination with DSL and code generation. The examples used are based on combining StUIML with UML domain models and generation of Java Swing.

Model-driven web applications talks about the use of StUIML in combination with Ecore and generation of Seam/JSF.

There is a lot of attention for modeling and the user interface so I am looking forward to the discussions.

Hope to see you there. As a warning: my picture on the EclipseCon2008 site is at least 15 years old. So look for a bolding middle-aged father of 4 instead...