It’s now 2012 and it’s time to put ABSE and AtomWeaver on the map. On the model-driven development map, that is. 2012 will be the real dissemination year for the ABSE approach and the AtomWeaver IDE. The take-off year. Well, it should be…

This year, and for the first time, I’ll be attending the Code Generation Conference (CG2012) in Cambridge, the most important European event in this area. As of today, it’s guaranteed that I will be participating in the 2nd Language Workbench Challenge (LWC) to be held the day before the conference (March 27).

I’ve also submitted three speaker proposals for the conference. The accepted speaker results are not out yet, so the presence of ABSE/AtomWeaver could be extended beyond the LWC.

The Language Workbench Challenge was created to compare the strengths and weaknesses of modeling/language workbenches, based on solutions for a predefined set of cases. These cases are accessible to everyone, on the LWC web site.

See you at CG2012!

For decades, software engineering has “dreamed an impossible dream”, to build software as easily as building Lego houses, says James.

There’s a talk by James Noble on InfoQ about this subject. In this talk, James Noble imagines a world where the dream has been realized, where software parts can be found in worldwide repositories, where most software is built by reusing existing software, and where we’ve “finally been freed from the mundane necessity of programming”.

Of course, it’s a dream but, how close (or how far) are we from such dream? I, for one, have certainly been working in that direction with ABSE:

ABSE allows you to create the building blocks of your software systems that, though simple constraint mechanisms, allow you to build your software by snapping them together, just like Lego.

Specifically, PBE is a specialized approach to asset-based development that focuses on patterns, a specific type of reusable asset. PBE provides guidance and support for using patterns in a systematic, disciplined, and quantifiable way.

You can use these types of patterns to support design, testing, deployment, and other aspects of the software development lifecycle. In performing these tasks, you use patterns in many ways such as documenting, generating, refactoring, and harvesting. As a result, you are able to use patterns to boost productivity, improve quality, leverage expertise, simplify, and improve communication within an organization. The goal is to ensure that as you use and create patterns, you are doing so in a way that adds value and boosts the agility of your projects.

Similarly, ABSE uses reusable patterns (a.k.a. “Atoms”) as the basis of its model-driven approach.

ABSE patterns are coupled with metadata, giving them the necessary variability to deal with real-world applications. ABSE Atoms have borrowed concepts from OOP like inheritance and composition, allowing you to create pattern families, and build “patterns of patterns”. Atoms are glued together like Lego to form a model that has a tree-like structure. A code generator “executes” the model to obtain the desired generated artifacts.

If you want to learn to use and apply ABSE, you may start by introducing yourself to the Patterns-Based Engineering approach. It will give you a thought process and logic foundation that will be quite useful to fully understand and take advantage of ABSE and its IDE, AtomWeaver.

To buy the book, contact the authors or if you are just plain curious about PBE, stop by the PBE site.

Software reuse is then of growing importance as a major factor in alleviating some of the problems resulting from the Software Crisis.

At first glance, software reuse appears a natural way to develop software, but in practice this does not happen. The challenges are numerous and require a fresh approach to the entire range of activities involved in the engineering of software. Every time new software is needed, developers tend to write it from scratch rather than harness components developed through previous projects.

In the first four decades of computer history the emphasis was on hardware developments, but now the emphasis has shifted toward human concerns. In the mid-1950’s, 90 percent of application costs were devoted to hardware but now, at least 90 percent of these costs are software. This reversal reflects not only the decline in hardware costs and the increase in programmer salaries, but also the recognition that systems must be carefully designed and developed to accommodate human users.

Software is essentially a symbolic product. It differs from the vast range of other products produced by conventional engineering techniques. Software, once designed, has no manufacturing phase and does not deteriorate, although changing environments will usually require software modifications.

The most often cited reasons why software is not reused are:

• lack of tools to support a developer in trying to reuse components
• lack of training for developers to create reusable components and to use reusable components
• lack of an educational methodology and motivation towards reuse and its benefits

The fact that software reuse has not been widely accepted questions the suitability of existing management practices, organizational structures and technologies involved in the development of software.

In short, a rethink of the software development process is long due.

AtomWeaver 1.0 is the materialization of an idea I had 10 years ago: Why not creating patterns of my own development skills, so that I don’t have to repeat myself over and over? At that time, I knew nothing about model-driven development, although I have already built a small code generator ten years before that.

This idea kept coming and going over the last decade when finally I decided that I had enough ideas to try and build a “variable-driven” code generator. Three and a half years later, and after three iterations of the ABSE concept, the whole decade-long project faces the outside world.

It has been a long journey. Still, I’ve just reached the “10%” milestone. My vision for ABSE and AtomWeaver is much larger. Version 1.0 is really just the tip of the iceberg.

It has been quite a long journey… so many headaches, so much fun!

Some people say that “if you’re not ashamed of your first product release, then you haven’t released it soon enough”. So I followed that advice and I released as soon as I could. Well, it could have been sooner, but I thought it would be cool to release it on my birthday!

And so it happened. The first released public beta version (0.9.0) of AtomWeaver sucks, lacks lots of crucial documentation, has blatant bugs and omisions, and the website is even worse: it has just four pages and two screenshots.

But I had to push myself off the cliff, I had to release one day…

Now I will follow the mantra “release early, then iterate like crazy”. That’s what I am going to do. New releases and website updates will occur on an almost daily basis. I released 0.9.0 yesterday but I already have 0.9.1 today! The update roller coaster will begin. Hopefully the update intensity will slow down as the product reaches an acceptable state.

A new era is starting. Let me take a deep breath…

The objective of the Early Access Program is to get valuable early feedback from professionals that are actively engaged in Model-Driven Software Generation, or code generation in general. With this controlled alpha release, AtomWeaver has seen the real world, and real developers are putting their hands on this new approach to software development.

While most people have yet to report back, some justifying to be severely constrained by their current work, I am starting to get reactions on their first “impact” with ABSE.

I’ve yet to receive a neutral or negative comment about ABSE, which is encouraging. First reactions have been positive, with adjectives varying from “interesting” to “promising”.

I am also learning a lot about how to properly convey the ideas and philosophy behind ABSE, in terms of documentation and tutorials. As with any new, disruptive technology, newcomers always feel confused about the new concepts, and hardly know where to start or where to go. It is a challenging task to put ourselves in the shoes of a newcomer when we are precisely on the opposite side of the knowledge scale. This is called “the curse of knowledge“.

Well, I should be talking about women in technology. I don’t know many in a personal level, and none of them are particularly notable. I’ll restrict my choice to my field, programming, and my country, Portugal.

So in the spirit of the Ada Lovelace day, I would like to mention Cândida Ferreira, a Portuguese-born researcher which have made some notable achievents in programming. Here is a shameless copy of her online bio:

Cândida Ferreira studied Biochemistry at Kharkov University (1985-1990) in the former USSR and received her Ph.D. from Lisbon University in Biology in 1995. She joined the Department of Agricultural Sciences at The Azores University in 1994, where she was Assistant Professor of Biochemistry since 1995 till October 2001. She invented the revolutionary Gene Expression Programming technique in 1999 and in 2000 co-founded Gepsoft to develop and commercialize software based on the GEP technique. She now works full time at Gepsoft as Chief Scientist. Her research spans the interplay between molecular biology, evolution, and machine learning.

You can learn more about her achievements at gene-expression-programming.com.

Celebrate Ada Lovelace Day!

I hope this series to be a very simple and easy way for developers to get acquainted with ABSE, to know what it can do, and what they can accomplish with it. It won’t take you more than two minutes per day.

New post announcements will be added to ABSE/AtomWeaver’s twitter account, and the fact pages can be found inside the ABSE section of the community site.

I take the opportunity to invite those that want to learn about ABSE and follow its evolution, to join its official community at http://atomweaver.ning.com.

Let’s see some good (valid) points about DSL’s:

• It’s domain-specific (duh!)
• Encapsulates boring details
• Can increase abstraction to the next level

And other not so valid points:

• It’s a Shiny New [mainstream] Thing. Most developers love that
• It’s cool and I can do it too

The first are very enticing, valuable, and sought for, and most of DSL’s attraction I guess comes from these features. But, will it pay off?

I really don’t have much experience with DSLs, so I won’t use my own arguments. I’ll let the community speak for myself. Here is a tiny sample of DSL criticism:

http://c2.com/cgi/wiki?DomainSpecificLanguage

… the Tower Of Babel effect that results from having so many languages that a person needs to be familiar with (if not master) in order to get common jobs done.
…
writing a good DSL that is robust and reusable beyond a limited context, is a lot of work. It requires persons with both domain expertise and language design expertise (not necessarily the same person) to pull off. A truly reusable DSL will require reasonable documentation, otherwise it won’t survive the departure of its designers.

http://www.theserverside.com/news/thread.tss?thread_id=42078

The other mistake some folks make is they think that with a DSL that “non-coders” can actually use the DSL.

But since a DSL is designed for automation of an underlying objet model, writing in a DSL is just like writing in any language — whether it’s DOS .BAT files or Java, and it takes a coding mindset and understanding of the underlying domain as represented by the computer in order to make effective use.

There was much more written on this thread. You can go to the original page to read more opinions.

As general use of DSLs become mainstream, so become the complaints about their shortcomings. If we take so much time to master a general purpose language, should we invest a comparable amount of time in limited-use languages? How can we get support for a DSL, apart from its own creators? Where’s community support? What happens after the departure of the language’s creator? What’s BNF? Do I need it?

DSL critics say really useful DSLs are hard and expensive to create. DSL supporters answer that DSLs are not designed, they evolve. Well, won’t any of those “evolutionary steps” risk breaking the entire development based on that DSL, much like a broken app build? Will the evolution in the language be severe enough to trash what has been done so far? Can you imagine yourself developing a complex C++ software system while C++ itself was still being designed and developed?

Still too many unanswered questions.