Branded and Exiled

2011-02-02T13:48:00.000-08:00

Almost one year has passed. A couple of weeks left until the EclipseCon 2011 starts.

SBB Rail Control System

2010-01-29T13:02:00.000-08:00

The swiss TV channel SF broadcasted a short documentary about the Zurich control center during the rush hour. You can see the RCS client application on the multi-monitor workplaces and some close ups of the diagrams.

Einstein vom 30.04.2009

Publications

2009-10-31T03:37:00.000-07:00

Infrarail Fair 2009, Birmingham, UK
As "Solution Director - Transportation Management Systems of CSC" I was invited to give a brief overview of the Rail Control System.

SBB IT Developer Day 2009, Centre Löwenberg, CH
Working with Eclipse in the RCS-D project and how we benefit from the Eclipse Platform.

EclipseCon 2009, Santa Clara/CA, USA
One hour talk about Eclipse as it is used at JPL and SBB.

EclipseSummit 2008, Ludwigsburg, DE
50 minute talk about the swiss railroad networks and how the Eclipse technology was used to create the swiss rail control system client application.

EclipseCon 2008, Santa Clara/CA, USA
I was helping during the 2hrs tutorial about Code Coverage Analysis in Eclipse.

SBB IT Developer Day 2007, Centre Löwenberg, CH
Explaining the server architecture and client component model for the swiss rail control system.

Russian-German Student IT conference 2007, Sankt Augustin, DE
Applying the Eclipse Distribution Model to Insurance Business.

[to be continued]

Decomposing Systems Into Modules

2009-09-07T04:48:00.000-07:00

I recently stumbled across a nice article about modular programming.

On the Criteria To Be Used in Decomposing Systems into Modules

Sidenote: Its written back in december 1972

This article contains some (very) smart statements, which are probably still effective for most current software developments.
What's left for me is the mission to find more articles and books about how to detect the right responsibility assignments for my components.
How to make the right design decisions *before* I begin with the layout of my modules?
Two (slightly modified) snippets from the document:

The most common approach to decompose a system is by choosing a flowchart. This is naive in the first place and almost always incorrect.

Maybe one can say the same thing in a more positive manner:

A component is characterized by its knowledge of a design decision. Its interface reveal as little as possible about its inner workings.

Excellent.