Model Analysis / Transformation

Here are a bunch of links which are interesting:

•  Mola
•  

The passionate programmer by Chad Fowler

I was thinking a lot about the different attitudes IT professionals have regarding the business they are doing. Some work 9 to 5 doing the tasks they have been asked to do while others are continuously rethinking and improving  their work. The book 'the passionate programmer' by Chad Fowler gives various insights on this topic. So if you want to make a difference in your work - read the book and apply the stated actions. And - if you have lost the passion for programming or IT - it may be the time to move on ...

Enterprise Model Repository

An interesting blog post about using CDO, EMF and alike to create an enterprise model repository can be found here http://tinyurl.com/yaqew2h

Versioning

Versioning is a tricky thing. Versioning systems usually do not know the semantics of the things they version. The determine differences based on syntactic issues. The question is if a change in the whitespace (e.g. a new blank) should really be treated as a new version.
This sounds like a non-issue. The problem is that there may be simple rules in place which say that each change in the sources has to be tested. The implication is that just a little bit of prettyprinting or fixing spelling in comments is considered a change.
I think we need semantic version control systems going forward .....

Links related to modeling ...

Three existing modeling projects

MOSkitt, Topcased and Papyrus

are currently being merged into one building an Eclipse modeling platform

Visiting the zoo

The atlantic model zoo is currently somehow hard to find as many links to it are broken. It can be found here.

Model versioning ...

At least the following projects look into this topic:
modelcvs
AMOR #1
AMOR #2
anyway ... love is all you need!

Modeling and Versioning

During the modeling symposium at the ESE I explained why I think that versioning for models or elements thereof is a challenge today and that this is a topic which will require more thoughts going forward. Today I saw that Sparx System is looking for input on this topic .

If it is not elegant it is wrong ....

Some time ago I did start to collect quotes related to the topic complexity on my web site. A friend of mine has now suggested to add "if it is not elegant is is wrong". He did hear this phrase often during his studies.
If the essential complexity can be represented in an elegant way, then this makes a problem for sure easier to understand. I don't think that there is always an elegant representation - if there is none, then the problem may still be understood correctly.
Absolutely not true is the opposite - many things are very elegant and also completely wrong. For this I can quote the movie "A beautiful mind" where Nash says "It's elegant, but wrong" to
Alicia Larde about her work. Nevertheless she does marry him later on.

Barbarian Hordes

Have a look at Pat Helland's blog and have some fun with Transaction Processing and the Barbarian Hordes.

CDO Webinar

The CDO webinar which just took place is highly recommended to all who are interested in modeling using Eclipse. Thanks to Ed and Eike for the presentation!

Textual DSLs

A good way to reduce complexity is to directly solve problems in the language of the domain expert using the right abstraction level. This can be done ideally using domain specific languages (also known as DSL's).

Textual DSL's as provided by XText as part of openarchitectureware or later by TCS in Eclipse are excellent choices for scenarios where the domain experts are text centric. A textual DSL allows the domain expert to create and manipulate models just using a simple text editor or with a custom editor in Eclipse if automatic checking and some further support like syntax highlighting are desired.

Accidential Complexity

It sounds wrong but actually it seems to be true. Small mistakes in basic things in a system can turn out to be the biggest mistakes. Over time it get harder and harder to correct them ...

Think about insufficiently defined data types (e.g. times without considering time zones) which are then used over and over again. Some people may spot the problem and fix it somewhere but usually not at the root. Changing and correcting such issues becomes more and more difficult over time. The worst is that these things go often wrong as they are considered to be trivial and not worth too much effort.

Avoid such accidential complexity by spending enough time and brain to do the small things right. It saves you a lot of time in the future.