himalia.net | community blogs

Talking with Daniel Görlich during the MDUCDE 2007, he told me about the new workshop he was organizing in the context of MODELS, "Model Driven Development of Advanced User Interfaces". Digging into the conference, I found this other workshop that also sounds interesting: Models @ Runtime. For me, it's funny because every time I present Himalia, the question about code generation -vs- runtime interpretation is on the table.

What I actually think is that it shouldn't be a public discussion. The user need to obtain good response times, fair processor consumption, etc. but how you provide that shouldn't be his problem. For example, I don't care if SQL Server or Oracle are generating specific code for each database definition or if they are interpreting each DB model in each query. And that's good, it should behaves as a black box for me. 

I think there are basically 4 things to take into account:

1. It is really one faster than the other one? People would usually think that the interpretation strategy is slower, but I think it highly depends on the quality of the generated code versus the quality of the runtime and the performance advantages you could take of having the model live @ runtime (for example, DBMS use optimization techniques as learning from the queries at runtime to obtain better response times).

2. In the resources consumption field I think interpretation is better, because you don't need to replicate everything each time, and so, you can let the underlying layers do their optimization work in a better way. 

3. Extensibility/Flexibility is the only field -as far as I can see- where generating code could be the better approach. In the DSL Tools book there is a very interesting discussion about what they called the "Customization Pit" and what kind of things you need to take into account when you support code-generation scenarios. Basically, if you are not providing the right hooks in your high-abstraction language, you should provide the ability to inject the customization somewhere in the process, and so, code-generation and partial classes could be the answer if you don't know which customization scenarios would you need to provide.

4. Before of partial classes, maintainability was a big problem for code-generation tools. Nowadays I think there is no big difference between both approaches.

Finally, sometimes, you just need the model live @ runtime, and so, if you decide to generate code you are at least duplicating the effort. For example, you may need it to modify it, to learn from it, adapt it, etc.

With Himalia, I followed the runtime approach. Why? Because I think that in the long run, having the model live @ runtime will be far better in order to: let the end-user modify his user interface, learn from the model, etc. Obviously, as I don't want to be hoisted by my own petard, I have to dig very well into the customization scenarios and support the required hooks.

Luckily, this is the first time in a long time I found many people converging into this point, as more and more frameworks are being interpreted, and now, there is a conference about the topic :) 

Labels: Conference, DSL Tools, Himalia, MDUCDE, Runtime

# posted by leovernazza : 11/09/2007 01:20:00 PM  3 comments links to this post

During the MDUCDE 2007 in Seoul, just before my presentation, Asaf Degani did a great presentation about his work on UI correctness. Basically, he exposed how inconsistencies between the user model (what the user thinks about what the application does) and the user interface model can produce very frightening problems. The example he presented was a inconsistence in the aircraft autopilot... (I have the full paper in my notebook but I couldn't find it online).

"The conceptual approach for generating correct and succinct user-models is based on the fact that not all the system’s internal states need to be individually presented to the user".

That is, the user interface is a projection/view of the application. So, the user model is different from the user interface that is also different from the application/machine. Asaf modeled the user model from the user manual and he found that with the aim of reducing information overhead sometimes what the manual teach is not what the application/machine actually does.

Suppose the plane is planning at 5000ft, if the pilot enters 10000ft in the autopilot interface, then the plane will climb until that height.

Then if the pilot set a new lower height after the airplane has passed a special point, then the airplane turns into an undetermined state, and continues climbing indefinitely. The problem arises because the pilot thinks (because the user manual tells him) this special point is calculated in a way that is not the real way. From the pilot point of view, the machine is behaving in a non-deterministic way: sometimes it works as expected, sometimes it doesn't but he doesn't know why. Why did they write the manual in this way?  Well... because with the information available in the user interface, the pilot couldn't calculate the real special point, so they decided to avoid "the details" [1].

Obviously, Asaf concluded that the UI is incorrect because it doesn't give the user all the information he needs to do the task. Maybe the manual is incorrect too, but what actually matters is that they are inconsistent.

From my point of view, this is a particular case of a wider topic that came again and again during the conference, in all the forms you can imagine (from cars to aircraft autopilots and smart factories). When you use different languages for each world you have to do a lot of extra work in testing to ensure you are keeping it consistent, because basically, what you are doing is to add more translations. The bigger the difference between the languages, the bigger is the probability to produce translation errors between them. In some fields, it may be still too difficult to unify both worlds in one only language, but in others, we are just not taking the right approach to solve the problems.

However it also happens in other models: software design, implementation, etc. If we were able to merge them, we could avoid testing the translations.

Some time ago I had a similar conversation with Andrés about this topic (he had written a post about it). We agreed that when you express things at the right abstraction level, testing is useless, because it becomes a tautology. Would you test that the += operator is working properly in C# or Java?. I wouldn't. 

To put this in the context of Asaf's work, if the aircraft autopilot and the manual are made with the same language, his work would be useless. You wouldn't need to prove the UI correctness because it will always be consistent with the user model [2].

Obviously, taking this approach ought you to test your high-abstraction language... it is a trade-off, but in most of the cases this is a far simpler and better limited task than testing all the user interfaces, and sometimes it can also be "outsourced for free" as we do with the += operator.

I think Eugenio Pace said exactly this in a different way a week ago, talking about SaaS in the Genexus Meeting. He proposed something like the Law of Conservation of Mass for complexity and software. He said: you can't avoid complexity, but you can redistribute responsibilities and that is what SaaS is about.

I think it is also what DSLs are about, translating complexity until some day, when magically a lot of testing and translations disappear and you can focus on what is really important for your business.

[1] Yes, this is how an aircraft autopilot works today, but don't panic, it is a very strange situation and I believe they can take the airplane control again in any case. I can't remember the special point name, and the exact calculation, but it's not the important thing here.

[2] Asaf is currently working on how to automatically generate the UI from a reduced user model and avoid the testing by producing correct user interface by design.

Labels: airplane, Conference, DSL Tools, MDUCDE

# posted by leovernazza : 10/02/2007 06:52:00 PM  0 comments links to this post

It's very strange to see part of your work in someone else book...

Thank you Andrés for the book!

I will take the book to the conference to read during my loooong flight to Seoul. I will post some thoughts about it when I come back home.

Labels: DSL Tools, Himalia

# posted by leovernazza : 8/31/2007 12:55:00 AM  0 comments links to this post

Watching this Chris Anderson's interview, he explains the new development methodology they are using in the Connected Systems team.

He says they are going beyond Testing-Driven Development (and obviously Behavior-Driven Development), they are not thinking how to test the code they are writing, they are thinking how to write the book that explains the technology while they write it!!!

Really, I don't know if it is true, but it sounds good.

TDD and BDD are based on how your consumer will use your technology, and in this kind of team, their consumers usually read the book while they use the technology. I don't believe you can rigorously follow this methodology, but it could be an interesting principle to have in mind while creating new stuff. 

P.S: BTW, he also thinks that WPF is a "tipping point" for model-driven development. May be the start for model-driven user interfaces? Who knows..

Labels: Developers, DSL Tools, TDD, WPF

# posted by leovernazza : 7/27/2007 02:37:00 PM  0 comments links to this post

As Steve Cook points out, the DSL Team's Book is almost ready for sale.

I want to congratulate the DSL Team, they have made a fantastic work with the tool itself and I am sure the book will be great too.

Gareth Jones indicated that you can read it online using Safari.

You can also look for "Himalia" inside it using this online tool ;)

I told you.

Labels: DSL Tools, Himalia

# posted by leovernazza : 5/18/2007 12:45:00 AM  1 comments links to this post

There is a new wave around the software factories and the domain-specific languages now. However, we have tried specific languages from the very early beginning and along the whole software history: Server languages, Script Languages, Query Languages, etc.

From this point of view, I think that SQL (Structured Query Language) is the most successful DSL in the history.

Why SQL is a DSL?

Just because it's a language designed to solve a specific problem: "to define databases and retrieve information from it".

I think one of the most important things when you are trying to create a language to solve a specific problem is to target a well-defined problem. That is, it should be bounded, focalized and easy to communicate. 

Besides, two things could make it the most successful one: to have a lot of people wanting to solve the same problem, and to support a good extensible approach form the beginning.

Who need SQL?

Most of the last 30 years applications need databases. You may think in writing your own code each time, to avoid constrains involved in the SQL and the DBMS, but it would have no sense for most of us if you think in the costs.

Have it got an extensible approach when the model is not enough?

Well, yes and no. Many SQL statements were impossible in the beginning and remained in this state until a few years ago. The model had to be improved year by year.

This is a gold rule in the DSL approach that everyone should understand: you should improve your specific-language while you learn from your specific-problem. Or, what is the same, the language won't be perfect from the first time. The model is stable right now, 37 years after the first approach written by E. Codd.

I think we have learned a lot and new DSL's should take less time to get stable ;)

Labels: DSL Tools, Technology

# posted by leovernazza : 3/15/2007 03:18:00 PM  0 comments links to this post

Microsoft (through Wilson Pais) invited me to talk in the first Architect Forum of the year in Santiago de Chile.

I also used this opportunity to visit a friend of mine who lives there, Hugo Cortés. I meet him for first time in March 2004 when he come to Montevideo -as a member of Un Techo Para Chile- and helped us to create Un Techo Para Uruguay, a non-governmental organization that help houseless people in my country. I'm outside the organization now (because you can't do everything at the same time), but I really feel as a member of it... technically, I'm one of the founders ;)

Back to the Architect Forum, Alejandro Pacheco made a discussion about the available technologies for the presentation layer. After that, Martín Cabrera introduced Domain-Specific Languages, and showed a mini-example. Then I presented Himalia and finally, Carlos Carminati and Luis Molfino presented their company and what are they doing.

In the picture, from left to right, you can see to Martín Cabrera (Microsoft), Carlos Carminati (d2B), Luis Molfino (d2B), Alejandro Pacheco (Microsoft) and me. 

My presentation was specially discussed with the people, so I think they enjoyed it ;) I already know that the Himalia proposal is disrupting, and it's great when people keep thinking about these ideas.

This photo was taken by Luis Molfino, as you can see he's an artist :)

I want to thank you to Martín Cabrera and all the Microsoft Chile team. Surely we will meet again in the near future...

Labels: DSL Tools, Himalia, Talk, Travel, WPF

# posted by leovernazza : 3/06/2007 12:55:00 AM  0 comments links to this post

One of the first task after the beta release was to redefine the Presentation Model Designer (the one under the "Layout" node in the solution explorer).

It should be intuitive, useful and simpler.

As you can see, we were very uncomfortable with the ease-of-use of the 0.8 version, but it was just the first presentation designer version.

The Presentation Model Designer is also made with the DSL Tools, and in the next released version, will looks something like this.

The new features include:

• . Screen resolution design-time testing. It allows you to change the target screen resolution and see how it looks.
• . Transitions were included in the model itself as arrows... It's far more intuitive!
• . Area control was merged with the area definition in order to make it simpler to understand.
• . Propagation rules were removed. Now you should set the landmarks and/or the propagating child (the model is still using propagation rules, but you don't have to care about it anymore). The landmarks are shown in the diagram, decorating the area with the navigational element icon.
• . You can define visual effects (fx) for any transitions, like in Power Point. This feature will change the world ;)
• . All the diagram decorators can be shown/hidden with in one-click. The decorators are: Docking, Transitions, Effects, Area names, Constrains, Landmarks and Propagation rules. In this way, you can focus in the specific aspects you are modeling at each moment.

Labels: DSL Tools, Guilder, Himalia

# posted by leovernazza : 3/03/2007 01:16:00 PM  0 comments links to this post

The beta was released on December 12, two month ago. Now, I want to to share some news with you:

• . On December 19 I was invited to talk in the Microsoft Architect Forum, in Montevideo.
• . Steve Cook contacted me. He and his team are writing a book about DSL Tools and they want to include Himalia as a real-world application using their new toy. We'll be glad to appear there.
• . I was also invited to talk in the Microsoft Architect Forum in Santiago de Chile (February 27 28).
• . We started to work in smooth design-time integration between Himalia and DeKlarit (the first alfa-prototype is working right now).
• . The guys from TangibleArchitect contacted us too; we will work with them in the near future in order to integrate both products.
• d2B decided to be the first company to develop controls for our platform. We are just starting to work together...
• . In the meanwhile, we had near 200 downloads... and several other "in process" things I can't still talk about.
• But, the community cannot grow without documentation and interaction. So, I am pleased to announce the new Himalia Community Forum and the first documentation package. We know we are still far away from a "good documentation", but we are in the road now, and the forum should help in the meanwhile.

Labels: DSL Tools, Himalia, Talk

# posted by leovernazza : 2/08/2007 01:22:00 PM  0 comments links to this post

Finally, we included the four editors in this first beta version of the Himalia Designer for Visual Studio (a.k.a. Himalia Guilder).

Most of them have been made using the DSL Tools, but the Layout Editor is an extension of the typical WinForms editor. It is taking some more time than was expected but the result will be an "almost full" functional version.

You can check new screenshots at the Preview Center.

Labels: DSL Tools, Himalia, VSX

# posted by leovernazza : 5/31/2006 04:59:00 AM  0 comments links to this post

Labels: DSL Tools, Himalia, VSX

# posted by leovernazza : 4/27/2006 01:26:00 PM  2 comments links to this post

Himalia generated (and interpreted) user interfaces are built upon a service layer.

In fact, the user interface use an adapter (in the GoF term definition) to communicate with the real services layer. That makes the user interface completely independent from who gives the services, and only knows about the contracts they must implement.

Last week, reading some DSL blogs, I found a Edward Bakker' example. He is creating a DSL for services, with contracts, implementations, etc...

So, it could be great to join both approaches in the near future.

Labels: DSL Tools, Himalia

# posted by leovernazza : 4/06/2006 01:47:00 AM  0 comments links to this post

As you may know, I've been working developing Himalia for a long time.

At this moment, I am working with the DSL Tools to make a VS2005-Addin for Himalia Projects. y first approach was to make the Use Case State Machine Model and the Navigation Model. In a few days I will post here some news about it.

The DSL Tools are very easy to use and interesting (forgetting pre-release problems like hand-check cross-references from XML and domain model definition).

Labels: DSL Tools, Himalia, VSX

# posted by leovernazza : 4/06/2006 01:36:00 AM  0 comments links to this post