The Hello World sample is a nice starting point to show the syntax and capabilities of every new language. This test is also useful for code generators and Domain Specific Languages (DSLs) also as a proof of concept.

Following this honorable tradition, I have created a video showing the capabilities of Essential: the tool I am working on for doing agile Model Driven Development.

In this 10 minutes video you will get a general idea of the DSL the language provides to create:

• metamodels
• models
• templates
• and control transformations

In order to see the details, jump to Vimeo, activate the High Definition mode (HD) and set full screen (sorry embebed version is not good enough).

Essential IDE – Hello World sample from Pedro J. Molina on Vimeo.

More info about it and 12 usage scenarios in the last Code Generation 2010 presentation about Tailored Code Generators.

Share your impressions!

Currently, the main efforts on MDD, MDE, MDSD (model-driven-whatever you prefer…) are focused in the development of this kind of tools perceived as a hot research area for Software Engineering.

In this scenarion, Cambridge, at Code Generation 2010 was the perfect place for sparkling the idea of promoting a contest to show and compare the advances of different language workbenches.

The Language Workbench Competition born with the objective to serve as a point of comparison between different tools in this exciting and fast moving area.

The competition is now open to the public. So anyone interested can enroll and implement the proposed challenge just published.

On the other hand, if you want to know more about Language Workbenches, modeling and code generation add this page to you bookmarks and come back in few months to see some proposals.

The promoters of the idea are: Markus Völter, Eelco Visser, Steven Kelly, Angelo Hulshout, Jos Warmer, Bernhard Merkle, Karsten Thoms and myself.

So this a call to arms but with sportsmanship!

Angelo and Markus has already started the calling.

When creating a DSL (Domain Specific Language) one of the most important choices is to decide about what items in your domain are going to be considered variable, changeable and which ones are going to be considered fixed, carved in stone.

The former need to be specified in your DSL, in your design or may be coded. The latter are considered immutable and will remain static for all your derived applications for ages.

Considering that everything is static it is obviously useless. On the contrary, considering every aspect variable drives to another no-end getting nothing tangible again as a result. Therefore, in the middle we will have to search for the virtue.

The main issue here is to study a domain and ponder between variable parts and fixed parts. It is not a trivial thing to do from the very beginning. Experience in DSL construction and specially, experience in the domain helps to train your smell, but there are not clear rules for it, nevertheless.

It is not only about knowing your requirements. It is about trying to predict how your requirements will change across time and what types of requirements have more likelihood and tendency to change.

Adding variability

A variable part could be, for example, the background color of your application. If so, you need to add syntax and semantics to your DSL to capture such property. Let’s say you can express somewhere in your specification:  { background-color = peach; }

We can select the peach color for app1, and may be ivory for app2.

However, nothing is for free and this freedom comes with the followings possible drawbacks:

• You need to increase the size of your language (DSL), editors, model checkers, compilers and code generation or interpreters.
• Users have to provide a value for such property unless you have also provided a sensible default value in case of missing information.
• Homogeneity across applications vanishes with respect to background-color. Now it’s a user choice (the one in control of the modeling tool).
• Specs are more complex.

Adding commonality

On the other hand, if you consider the background of your application should be always the same because you are following, for example, a user interface style guide then, the background color is a fixed issue. Its value is provided by design by a style guide, by an architect, or design choice and the user modeling has no control over it.

In this scenario, the DSL is smaller. No need to specify the background color, it is implicit, it is no included in the model/specification.

With this kind of choice, we are betting for standardization. A shared library, a runtime framework or an interpreter will take care of supplying the right color in the right moment.

• Users can not change the background color, specs are smaller.
• Standardization is improved across applications.
• User has no control on the feature.

But, what is the right choice?

It depends. There is no right choice with the information given till the moment. To answer the question we need to consider if the background color is a fundamental feature in our domain and it is needed to be different from application to application or may be, on the contrary, the color should be used in an homogeneous way following a predefined style guide.

Again, the domain imposes the rules to follow. Studding the domain and its variability is crucial to create a consistent DSLs focused in gathering the key features of the domain in a model: the important and variable ones. The important and fixed ones must be also identified but they shouldn’t be included into the model, but into the framework or the runtime.

Standards, policy assurance, compliance

Everything related to standard procedures, compliance and in-house stile guidelines are first-class candidates for standardization. If done in that way, your developers will not have to remember all that weird standard and compliance rules when developing a specific artifact.

A code generator will provide the right value for them. It will do it silently, without errors neither oversights. All the boring code dedicated to plumbing applications like: naming guidelines, service publication, serialization, persistence, adapters, proxies, skeletons, stubs, DAO code are driven by strict standards and best practices and are natural candidates for strong automation by code generators.

Moreover, if the regulation or the standard changes, the change will have impact in the following assets:

• a single change to a framework will be enough
• or a change to a code generator and then forcing a regeneration process and redeploy.

In both cases, it is cheaper that manually reviewing a set of in-production applications.

For example, think about replacing your data-layer access code from a DAO pattern and SQL to an ORM based approach like Hibernate.

Business Know-How

The core of the business Know-How is the important and the variable parts we are interested in to be collected in a specification. Such features need to be modeled, and if possible, abstracted from the technology that will implement it.

If we do it in this way, the model can survive the current technology.

Why we could be interested in do it in such a way?

Just because technology evolves like fashion. Today everyone likes red T-shirts, tomorrow blue jeans will be sublime! Basic, Cobol, C, Java, C#, Ruby… what is the next language to use in 5 years time?

Use your best bet, whatever platform better fulfills your requirements, but I it could be nice to see the business process surviving the technology.   We don’t know in which direction, but technology will evolve, and will change for sure.

Maintaining a language or a DSL

When a DSL or a language needs a review you will be probably considering adding new features to the language.

Each new feature will increase the variability and increase the complexity of the language. Before deciding to add a new modeling feature make a cost/benefits analysis and double check that the valued added by the improvement is greater than the cost of implementing it.

I like to follow the golden rule proposed by Gordon S. Novak about automatic programming:

“Automatic Programming is defined as the synthesis of a program from a specification. If automatic programming is to be useful, the specification must be smaller and easier to write than the program would be if written in a conventional programming language.”

Conclusion

Whenever is possible:

• Business Know-How should be captured by models, specs, DSLs.
• Technical Know-How should be captured by code generators, model interpreters, best practices and patterns.

So, at the end of the day I like the following pair of quotes to sum up about what to include in a model:

• The Spanish writer Baltasar Gracián in the XVII century said “Lo bueno si breve, dos veces bueno.” (a literal translation from Spanish could be: “Good things if brief, twice good.”)
• On the other side, Albert Einstein (XX century) counterpoints “Things should be as simple as possible, but not simpler.”

The Programme for Code Generation 2010 has been published.

This year Mark has invited me to give an introductory session to Model Driven Software Development (MDSD) oriented to begginers.

Also, I will discuss in a second session about creating tailored code generators.

See you in Cambridge in June!

A title like this could sound utopian and probably it is in the extreme, but at the same time provides two advantages:

1. a suggestive title brings more blogs readers , and
2. these kind of Quests keep me active developing and testing my ideas about MDD.

Sorry for 1, the joke. But Let me explain 2 a little further if you are interested:

Some months ago, I started to develop a new tool for doing Model Driven Development. I always start new developments with contained expectatives. I consider most of them throw away propotypes just to test a new way of doing the same thing, but luckily, with less effort and better productivity. But when you found the way, you follow it again whenever you need it, isn’t it?

So, this time is one of those moments: I am quite happy with the results, and I will continue building on the top of it to make it grow.

Today (almost?) everyone agrees on code generation can make your life notably easier as long as you have:

1. a stable domain,
2. a clear knowledge of your domain (domain expert) and,
3. tools: modelling editors, model checkers, and code generator adapted to your domain and your chosen target architecture and language.

The trickiest one to get is, not surprisingly, the third one. And this issue: the quality and the applicability of the MDD tools is the main stopper when considering applying MDD for a software development project.

So, my motivation during years is not only to create code generators one more time, but do it in a way that it will be cheaper to obtain results in next projects. Therefore, reducing the requirements for the entry level will help the MDD adoption to gain speed.

Ok, wait a minute, are you reinventing the wheel again? Building another meta-code-generator?

Yes I know, there are very good and mature tools for doing MDD: such as EMF/GMF, XText, ATL, TextUml, Metacase, MS DSL Tools, etc.

However, guided by my intuition and the experiences in the domains I have worked in, I have a strong opinion on of how some things should be done and for the moment I didn’t found the perfect tool to satisfy my needs.

But, instead of complain, I decided to take to the action and add my two cents implementing my view about MDD tool support: taking the good ideas of the standards available and reinventing the parts that don’t fit.

The tool

After this introduction, the name of the tool is not going to surprise you. It is named Essential.

The goals of the project are following ones:

• to declaratively describe metamodels, models, templates, and transformations using textual DSLs
• to provide a comfortable editor for each of these four pillars,
• to provide model checkers to assure the integrity of the four, and
• to build code generators and transformation interpreters to achieve the output we are looking for.

In the next posts I will depict the DSLs used in Essential and some architectural choices. This will help us to discuss the essence of the problems found in MDD.

I want to thanks Javier Hernandez for his constant help, good discussions and counterpoints about choosing design alternatives for Essential. And also to Nicolas Cornaglia and Ángel Marín for their active beta testing as early adopters and providing good test fields.

I want to share with you a set of videos to show what I understand when talking about Forward Engineering applied to MDD.

First of all, a legal disclaimer: my apologies for the quality of the videos and for my rusty English: I am starting to play with video editing tools and recording software so I expect to improve my recording and editing skills on the way. Anyway, I found (I hope) they have enough quality to explain the main ideas. So seeing it is totally up to you! You have been warned! 

Also note: see the videos in High Quality mode (HQ) in Youtube. Otherwise, details of the samples probably will not be visible.

In a previous post I introduced a sample of the code that can be generated from a very basic conceptual model. I have created three videos to show you the main steps involved.

1. Modeling (Video 1/3). The first video uses a minimalistic class model created inside Visual Studio 2005 with Microsoft DSL Tools. The sample creates a basic blog structure in less than 5 minutes. Note that in the specification there are no technological choices (neither the types are bind to a concrete language representation).
2. Code Generation (Video 2/3). A quick step: Selecting a code generation (selecting a target architecture), fixing the design choices offered by the code generation and pressing the red button: Generate! A full .NET Solution is generated in less than 5 seconds ready to compile.
3. A quick code review of the generated code (Video 3/3). Finally, I am sure you have curiosity to take a look to the output code, don’t you? This third video shows a walkthrough to show:
   • DB Scripts (table creation, foreign keys, drop scripts)
   • Database creation
   • Logic layer: POCOs (Plain Old CLR objects), NHibernate mappings and a Business Service Layer with fully functional CRUD operations.

So this is it. It is a proof of concept of how fast and direct MDD tools can be starting from a minimalistic model.

When talking about using or buying modeling & code generation products my advice is:

• Don’t use models just for documentation. They will be outdated soon or later. On the contrary, a living (generating) model is always in sync with its target application.
• Don’t resign yourself to just using code generation of skeletons. As you just have seen the current technology allows you to generate much more.
• Don’t be content if anyone try to sell you a model too close or tied in any way to a given target language. Today we have just generated C#, but tomorrow may be we prefer Ruby? Python?
• Don’t resign yourself to use a tool married with a specific database. You know, technology changes faster that we usually expect.

A good way to avoid such confusion is to make explicit a short clear definition of the terms used.

Following this idea, today I want to share the Conceptual Map I traditionally use to explain the areas involved in code generation. This map helps me to explain how more complex interactions and natural dependences and properties arise in this domain. See embedded video.

We will start considering MDD using two orthogonal dimensions:

• Types/Classes vs Instances &
• Two levels of abstraction: Programs/code (technology dependent, concrete)  vs Models (technology independent, abstract).

Key concepts

1. Model: A description of the problem to be solved.
2. Metamodel: A type description for providing the modeling language.
3. Template: A pattern representation of the code you want to create.
4. Transformation: Application of an algorithm to transform one or more models in one o more outputs.
5. Output: Your target asset: source code, doc or models again.

Additional concepts

• Mappings = Template to Metamodel item bindings
• Architecture Know How = Mappings + Templates (embedding best practices and patterns)
• Business Know How  = Metamodel + Model
• Model Checker = Validation of Model with respect to Metamodel
• Generator = Transformation(Templates, Mappings, Model) –> Output

A pair of properties to mention.

Stability:

1. Metamodel: Quite stable once developed.
2. Model: Stable till the business change (requirements change).
3. Template: Stable till not changing or evolving the technology (2-3 years cycle?).
4. Transformation: Impacted by technology or metamodel changes.
5. Output (Source code): Regenerated as needed. Discardable.

Dependences:

1. Metamodel: Not dependent of third parties.
2. Model: Altered if metamodel changes.
3. Template: Not dependent of third parties (just the technology).
4. Transformation: Impacted by template changes, mapping changes and  metamodel changes.
5. Output (Source code): Impacted by everything. Regeneration is a good property as seen before. But now is a necessity.

Changes in the formers will cascade to the latter.

Strong Separation of Concerns & skills

Apart of the classical advantages provided by MDD approaches such as quality, productivity, time to market, & technology independence; one of the good properties no so times recalled is the strong separation of skills that this method of software engineering provides:

• Business analyst can concentrate efforts in using modeling editors to describe the business and provide feedback to enhance metamodels (when needed)
• On the other side, Software Architects and technology gurus can concentrate in tuning the technical architecture to achieve the most performing implementations they can provide.

One you achieve this stage, you can start thinking of reusing and evolving your business models and architectures at speeds that most of traditional SW developers never seen before.

There is one famous quote from Grady Booch saying:

“The entire history of software engineering is one of rising levels of abstraction (abstraction is the primary way we as humans deal with complexity).”  Grady Booch

As many others, I think that MDD is the next step to adopt in such direction. When it will happen globally is just a question of achieving the critical mass:

• having good enough tools,
• and having practitioners enough and success cases to prove the value in the “not so new” way of working.

I’m optimistic about it. We are in the way and getting speed…

The call for speakers of Code Generation 2010 is now open.

If you are a practitioner, researcher or a tool maker in the MDD arena this is your conference.
You have till January 15th 2010 to send your submission.

See you there!

As commented before, my expectatives were exceeded. The Genexus Event organized by Artech has a great quality level: more than 3.600 participants, having more than 120 sessions in tree days. I’m impressed! These kinds of things are not improvised, and the organization did a wonderful job for the event. Congrats!

In this post I will comment about the things I saw and liked (specially sharing the links to the videos and abundant material) and about my, now, better understanding of the tool Genexus.

Note: There is a some of material with on-line translation to English, the rest is only in original version (Spanish).

The Event

Once finishing performing my MDD Session on Monday, I had free time to relax and follow the rest of the event and try to learn new things.

So, I wanted to know a bit about the Microsft vision of the Cloud and followed:

Eugenio Pace in action.

• Steve Marx’s (Microsoft) session about Azure “Deploying to the cloud” and
• “Thinking in the cloud? Factors to keep feet on the ground” by Eugenio Pace (Microsoft).

Both of them provide a good overview about the factors to have in mind in order to use this computing paradigm and how Microsoft is preparing its cloud platform called Azure.

Another interesting block for me was the RIA & Javascript sessions:

• “Javascript to the extreme” by Andres Levin (Artech)
• “RIA with Genexus Now!” Nicolas Cardelino (Artech)
• “Future of RIA applications with Genexus” Alejandro Silva (Artech)

In there, I found a good review about the pros & cons of current RIA platforms (Flex, Silverligth & AJAX) and the incoming new features of HTML 5. Alejandro made a special focus on how the code generators can be modularized to change parts in them to help changing the output architecture of your RIA application. It is totally sensible to do it in that way to promote reuse.

Alejandro Paniza (Artech) talk about “REST Webservices” and its usage related to code generation.

I met also Nicolas Jodal (Artech) and enjoyed with the rest of the participants in his great Keynote “It’s in our nature…” Nicolas argued about the human nature, the kind of thinks we instinctively do: mimic success, solve problems, communicate & share, belief in models… and how the technologies that exploit such human features tend to have more successes that other that don’t. Very inspiring talk!

On the softskills side, Jose Lamas (Artech) talked about “How to achieve quality discussions”. A nice and practical one, I’m going to put in practice as soon as possible.

On Tuesday, Juan Matteo (a.k.a. Nicolas Jodas again) talk about “Universal Data Models” to introduce alternatives to traditional relational databases in order to change the focus from rows to columns; from entities to attributes and relations. The performance of course of such change is not good for a general replacement of RDBMs, but for small sets of data, it can be quite productive to work in such a way and obtaining benefits like versioning, easy link exploration and on-demand extensibility.

One of the new features in “Genexus X Evolution 1” is the new generator targeting Ruby. Daniel Mendez & Sabrina Juarez (Artech) showed that work.

On Wednesday, Gaston Milano (Artech) reviewed the “Genexus Language Evolution” and the future plans to improve the language: introducing scalability thought modularization and improving the user interface specification in Genexus.

Angel Mahler's Orchestra

On the closing session, a very funny and enjoyable session was the following one: “When a team sounds good” by Angel Mahler. Here a band played several themes from movie soundtracks making emphasis on how an aligned collective work (team work) can achieve better results that the sum of individual ones (the so called an often abused term of sinergy). Nice perform!

Finally Breogán Gonda closed the Event with his keynote. I remember some quotes from him I liked showing his attitude and strong commitment:

• He recognizes that the first event (19 years ago) was created to talk with customers and acknowledge a problem they were suffering in such days. Just to acknowledge it and say they were working in the solution.
• Nowadays, he can’t promise that they will not be problems in the future, nobody can. But, on the other hand, he promise to continue working in the solutions with the customers, openly, as a real community. That’s the attitude I like!

The product

Certainly, I travelled to Montevideo with an unclear view of Genexus. I have never worked with it: It’s object oriented, UML oriented? It’s MDD? Fortunately, I came back with a better understanding of their approach.

Genexus is based on the specification of the conceptual data modeling and takes the assumption of given unique names to such business concepts such CustomerSurname or TotalInvoice. Under the curtains, a Prolog engine (a rule based ones) derives the final data model, the database to SQL. After this definition, Genexus provides different DSL to specify business logic, workflow, user interfaces, etc. A plus is that such specification is not dependent of the dababase structure, so it is easily retargetable and moreover re-normalizable.

One of the more impressive features of Genexus, impressive just because is something you don’t find in other modeling products, is the real Schema Evolution included out of the box: You can define your model, generate it, populate it and go life (go to production). Later on, you can change your model in a way it changes your data model and forces a reorganization of the database. In such scenario, when you regenerate again your application, a set of DB scripts are also generated and apply to move your living data to your new application version. That’s cool and not easy!

Of course, everything is abstracted away from the technology, making easy to generate to different platforms such as Cobol, AS400, Java, C#, Ruby, code for the cloud (Azure), to cite a few.

As commented by Artech staff, they need to work for improve the scalability of the tool for working with big projects and introduce better and easier User Interface specification.

Genexus is not UML, it has no Class Diagram, neither a Sequence Diagram. Don’t search for XMI or MDA profiles. Just because Genexus don’t need it.

It’s simply a different approach but it’s real MDD. As real as it has 20 years in the market.

Congratulations to the Artech team!

Keep going with the good work and demonstrating that code generation is the way to go in Software Development!