some historical statistics on modeling formalisms

Some historical statistics about the use of formalisms for modeling automated systems since 1800. Here is a chart about how frequently a particular name of a modeling formalism was used in literature. I’ve picked Automata, Petri nets, Process algebra, Statecharts, and UML.

You can get the full chart (and add your own favorite formalism) using Google Ngram. What I find surprising is that Petri nets were at some point as relevant in literature as automata (which have been discussed since the 1800s already). I’m not surprised that UML peaks all of them by far. On second throught also UML’s decline is not suprising as the hype returns to normal levels. What I do find surprising is that process algebras are much less referenced in literature than even the very particular, though successful, technique of statecharts.

 

proper interface descriptions for your service

A service is, in computer science terms, a functionality (of a software or of a device), that hides its implementation details to the user. To be able to use the service, the service has to declare what the service does at its interface. In the old days, you would get a manual, in the new days you would descriptions in some fancy service description language.

Besides discussions how to write down what a service does, I feel there should also be some thoughts about what all should be described about a service. It’s quite easy to miss something important as the following video from our new building shows.

Using a Coffee Machine Service

15 minutes for everyone

If every person living on earth today wanted his/her 15 minutes of unrivaled fame, it would take ~193778 years from now. We should get started.

Every day 96 people can have their 15 minutes of fame. That means for an estimated 6.79 billion people living on earth today, we need about 70,729,167 days to get everyone famous. That’s just about 193778 years.

from the other side of the review form: why papers get rejected and what the BPM community can do about it

I’ve been reviewing papers for the International Conference on Business Process Management (BPM) over the last 3 or 4 years, in 2011 and 2012 as a member of the Program Committee. In that time my evaluations of submitted research papers have been to reject the paper in the very vast majority of cases. This year the best score I gave was a borderline on one paper, and a reject on all other papers (8 in total), other years were a bit better, but not much. In the following I’d like to share my view on why the papers were rejected. Paper authors may find this interesting to learn how they can improve their chances of getting a paper accepted. Perhaps more importantly, it also sheds a light on publishing standards within BPM research and what the BPM community as a whole can do to promote these standards.

number of ways students name an activity in a process model

I am currently evaluating data of a modeling experiment conducted with a number of colleagues. In that experiment, students were given a textual description of the NFL drafting process (which NFL scouts use to pick future star players), and students had to come up with a graphical process model of that process. We had 113 students participating. Obviously, different students will create different models. We also expected students to name the activities in the process model differently. Yet, we found a variety of ways of naming an activity that strikes me.

One sentence in the process description was the following

Afterwards the scouting team attends games of the player they are interested in live in the football stadium.

For this particular activity, we received 84 different ways of naming it (see complete list at the end of this post) – in other words, 2/3 of the students derived a different formal concept from this sentence. I think these observations hint at what needs to improved in teaching modeling. And also shows where real-world problems are in aligning process models to formal or informal descriptions.

no ordinary building

Our faculty moved. This is no ordinary building. A user needs a manual to get in, be well inside and get out safely: computer scientists get what they deserve.

tutorial : eclipse rcp e4 with 3.x views like project explorer, properties, etc.

This tutorial shows step-by-step how to add classical Eclipse 3.x views like Project Explorer and the Properties View to an Eclipse e4 Rich Client Platform (RCP) Application.

Eclipse 4.2 was released a few weeks ago with the new e4 platform that basically uses an EMF model to describe how your application looks and feels. While this is neat, the caveat is that e4 currently (August 2012) does not provide views for a number of core features of the old Eclipse 3.x platform including things like the Project Explorer, a Properties View and the like.

Eclipse 4.2 comes with a “Compatibility Layer” that makes all the old features that were not ported yet to e4 available. However, I could not find a site that tells me how to use it. There are a few quite instructive tutorials out there on how RCP applications with e4 work, for instance http://www.vogella.com/articles/EclipseRCP/article.html. But none showed me how to add a Project Explorer and all the IDE views that I needed for my projects (http://service-technology.org/seda and http://service-technology.org/greta in case you want to know). So I went for the usual approach in the Eclipse-verse: trial and error. Here is what I figured out and works for me.