Diverse patterns

Yesterday was spent with two colleagues from our Gothenburg office at SAAB here in Linköping. Together with SAAB we at Know IT are one of the partners in a Vinnova project focused on electrical architecture (more information about our Vinnova commitments will be posted on our homepage in due time). It was a very interesting day with a lot of discussions around functional system safety and patterns. I think above all what struck me was the very competent first impression the two SAAB-employees made, they really knew their way around the block with regards to embedded development and safety. Inspiring!

Yesterday's patterns concerned safety; today the patterns are focused on separation of concern. I’m trying to compile a few but meaningful slides about MDA in order to help a co-worker. MDA for me is more than just transforming models to code; I tend to give the word a somewhat bigger scope than that. For me MDA, done correctly, can be used to bring leverage not only to the product itself but also how you build your organization. Of course if you are a software company MDA can facilitate HW-independent development and re-usable code generation but from my perspective you don’t have to have a programming department in order to gain benefits from an MDA sense of mind.

The basic MDA pattern. The x can be both S and I depending on amount of layers.

[P:Platform, M:Model, S: Specific, I:Independent]

Execute this

I am currently having a late evening with the report on Model Driven Architecture and executable/translatable UML.


One thing that intrigues me is that during research, on MDA in particular, the notion of platform in the context of PIM and PSM (Platform Independent Model and Platform Specific Model) seems quite single-sided. In most MDA-papers I have yet to find a different meaning to platform than language + compiler + hardware. In other words MDA shall basically only be used to separate us from the implementation in software.

Why is there so little written about PIM/PSM where platform is put in a product context? Where the PIM is your model of the functionality independent on which final product in your palette it will end up in? And where the “PSM” is your “PIM” (in normal terms) for that specific product? This is nothing new and breath-taking in e.g. PLA-ideas but there isn’t a lot of practical reading where those two have been put together.

A practical approach from PIM, P for product or project then, to PIM (if needed) to PSM would be interesting to see (or create).

For a larger product company enabling this would probably yield a substantial improvement.

Time for a break and some serious running in -6degC.

Write, writing, written

A full day of this pattern is soon to end: