Jorge Manrubia » Model Driven Engineering

The role of models in Agile and Model Driven Development approaches

Jorge Manrubia — Sun, 05 Apr 2009 23:31:59 +0000

When I was at the university, I remember being very interested in the suggestion that building software was like building bridges, and that software should have blueprints as sophisticated as those needed to build a bridge. I remember to has been told that you will never find a book on “How to build bridges in 7 days” but you will find the equivalent on “how to learn C++ in 7 days”.

Today, I’m not so convinced that this analogy is a good one. I can’t agree more with this quote from Dave Thomas (the Pragmatic Programmers proposed a new analogy that I’m pretty sure not everyone can digest):

Software development is neither. Nor is it art. It’s just software development. People who look for the “software is like xxx” analogies are missing the point. Software development is like software development. Let’s decide what works for us, and have fun while doing it

If you are interested, Martin Fowler explains the reasons why the building bridges analogy fails. I think, there is a sentence in his article that summarizes the problem very well:

Can you get a design that is capable of turning the coding into a predictable construction activity? And if so, is cost of doing this sufficiently small to make this approach worthwhile?

This question is, obviously, rhetorical. You won’t. Traditionally, the gap between models and code has been huge. If you ignore this gap, then you may think that you have to make great efforts in creating very rich models, so the low-skilled and no-talented programmer can translate them into working code. And if you can create these models, then nothing stops you from planning the full development process up-front. Since the construction phase is mechanical and predictable, then you only have to calculate how much time you will have to spend in modeling. And since modeling is about drawing (if we use this development approach we are using UML for modeling everything for sure), this estimation should be easy too. After all, drawings, like Word documents or Power Point slides, always compile and work. Of course, this scenery would mean that software projects are delivered on time, that the waterfall approach works, and that no matter wether the developers are talented or not.

In my opinion, the fact that models can’t be converted into code easily is addressed by the two development approaches I am more interested in:

Agile development
Model Driven Engineering (MDE)

Although both approaches are perfectly compatible, they propose different ways when it comes to use models. Both approaches see models as a communication tool, as a resource that let us, as humans, reason and elaborate solutions that solve complex problems. While agile practitioners warns you against using models for anything more than this, MDE practitioners propose to take the next step and convert models into first-class development artifacts.

The two approaches give different answers to the question of being able to create designs that can turn the coding into a predictable activity:

Agile developers’ answer is “no”. In fact, they propose to use many good development practices and exhaustive testing as a shield against problems when coding. Coding is not an ugly phase, neither is cleanly separated from design. There are not designers and programmers, there are developers. They will use models as a way to collaboratively obtain the best designs that solve the problem, not as a way of documenting it. And since they assume they can’t predict how the full process is going to be in earlier stages with detail, they are going to estimate and develop the project iteratively, using an empirical estimating approach.
The MDE answer is a little bit more complex to say, since the paradigm is in its earlier stages. But if we manage to have MDE solutions where we can define the best DSLs to describe a problem, and to specify how this input is translated into a working application, then, if these DSLs are defined in a way that are reusable in different instances of the same problem, we would be very close to being able to answer “yes” to that question.

By the way, a confluence of both approaches can be seen in the BDD (Behavioral Driven Development) frameworks: such as RSpec, Concordion or Cucumber, but I think that topic deserves a post on its own.

Errors in my post on Comparing EMF Models

Jorge Manrubia — Wed, 19 Nov 2008 01:01:26 +0000

There was an error in the code originally posted in my article on Comparing EMF models. Thank you so much to Jim Showalter for warning me. The post has been updated with the right code. Now it’s also included an Eclipse sample project that compares two UML models.

Comparing EMF Models

Jorge Manrubia — Sun, 06 Jul 2008 16:37:26 +0000

At work, we needed a mechanism to compare EMF models. We are developing a system that uses ATL model to model transformations. We wanted to validate the transformations with JUnit unit tests. We needed a mechanism that let us compare expected models with transformed output models.

EMF Compare

I started evaluating the EMF Compare Framework. This framework targets model comparison by building a EMF model of the differences found during the comparison process. It let you evaluate differences pretty exhaustively. It evaluates source and target models by trying to match parallel elements. For related elements, matching is applied recursively.

The differences model is build of matched and unmatched elements. Matched elements let you examine the similarity of the matching (a number between 0 and 1). It seems as if two elements match just by having the same metaclass. Then, the similarity is set depending of how similar are their attributes. If the two models are identical, the root elements matching similarity is 1. If you change the value of two attributes, for example, then this precision was over 0.9. If you just change the order of two nodes, the precision was again under 1, even when the references in the metamodel weres unordered. This behavior wasn’t very good for our purposes, since models under comparison could have different orders in their references.

If you think in the semantic of the comparison, two models can be identical when their unordered references don’t have the same order, don’t they? I suspect that EMF Compare probably would let you configure different comparison strategies easily, but we found a simpler way to achieve what we wanted.

Modifying the `EcoreUtil.EqualityHelper` class to ignore order in references

A friend told me have a look at the equals() method provided by the org.eclipse.emf.ecore.util.EcoreUtil class. It receives two EObject elements and compare them recursively. The two models have to had exactly the same structure in order be equal (no matter wether references were ordered or unordered). Again stabbed with the same problem. A look at the source of the method revealed that it delegates completely the functionality in a helper inner class: EqualityHelper. This class code is well factorized and it can be understood easily. The comparison of two list of elements was properly contained in an equals(List, List) method. So we try to hack this method in order to ignore orders when comparing.

After spending some hours trying to make a very complex modification of the method, another friend proposed the simplest way to compare two lists: sort them both and then compare sorted lists expecting exactly the same order. The solution was as obvious as wonderfully easy to implement: we already had the exhaustive comparison so we only needed to center our efforts in sorting the lists.

The last thing we needed was to find an EObject comparison criteria in order to implement the proper java.util.Comparator. This wasn’t that easy and we finally ended up parsing the toString() method result so we can obtain the attributes list string (the attribute’s name is hard coded in the EMF generated code of each concrete toString() method).

Below the source code of the modified EqualityHelper is shown.

public class EMFComparator extends EcoreUtil.EqualityHelper {

class EObjectComparator implements Comparator<EObject> {
public int compare(EObject object1, EObject object2) {
String targetString1 = extractComparisonString(object1);
String targetString2 = extractComparisonString(object2);

return targetString1.compareTo(targetString2);
}

private String extractComparisonString(EObject object) {
return object.toString().replaceAll(
object.getClass().getName(), "").replaceAll(
Integer.toHexString(object.hashCode()), "");
}
}

@Override
public boolean equals(List list1, List list2) {
Comparator comparator = new EObjectComparator();

List<EObject> sortedList1 = new ArrayList<EObject>(list1);
List<EObject> sortedList2 = new ArrayList<EObject>(list2);

Collections.sort(sortedList1, comparator);
Collections.sort(sortedList2, comparator);

return super.equals(sortedList1, sortedList2);
}

Conclusion

I was a bit surprised of not finding this problem solved when googling for it. I’m sure more people have had this need and have solved this problem before. When you are transforming models, you need a formal way to compare real output models and expected output models. I wouldn’t develop a complex transformation system with a lot of transformation rules without this system. Lateral effects when modifying transformation rules can break the system and being easily unnoticed. If transformations are an essential mechanism in a data loading system, like our case is, this danger is not acceptable.

Update (2008-11-19)

There was an error in the code originally posted. The method extractComparisonString() received an String object, when it should receive an EObject (it didn’t make sense). Thank you so much to Jim Showalter for warning me. I should have copy/pasted from what I coded at work, instead of rewriting at home.

You can also download an Eclipse sample project that compares two UML models. It includes the source of the comparator.