Off I go to Gothenburg and the west coast tomorrow; it’s time to talk at the IBC Euroforum conference “Electronics in vehicles”. If anything it will at least be nice to see some old colleagues from Volvo and meet my current Know IT ones.
Besides the very nice assignment at SAAB there’s currently a lot of Know IT business development going on, particularly I’m keeping myself occupied with some ideas around agile development as well as technology management for less mature (in terms of electronics and software) organizations. The space and time for these kinds of discussions and concept evolution is one of things I really like about KIT TM. Oh and not to forget the thread around MDA.
As far as Android goes the time for playing around with Eclipse and the SDK is rather rare but I have been able to play a bit reading sensor data. Besides the serious discussions around apps that I have with a Gbg-buddy of mine I’m keen to try something around augmented reality (after first talking a bit with Torkel and then checking out some demos on youtube).
Visar inlägg med etikett MDA. Visa alla inlägg
Visar inlägg med etikett MDA. Visa alla inlägg
onsdag 21 april 2010
tisdag 2 februari 2010
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.
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]
fredag 15 januari 2010
Analysis to design
Currently involved in a lot of more business related tasks but I get to squeeze in some technical thoughts in between as well.
One that I’m exploring a bit is how xtUML and “MDA” ideas could be used to create separation of concern between very abstract analysis (or maybe “architecture” if you like) models and design models. Of course it is not so much the separation of concern I’m after as the possibility to do model to model transformation, but “soc” feels like a necessary means to achieve just that ;)
In my head, maybe I’ve got it wrong, this is initially not so difficult to achieve but when you put it in context it suddenly become a tad more problematic. Especially since it is not the pyramid-structure of transformation I’m after (you know, the “Babushka” structure…) but something a bit more intelligent where the transformation would handle e.g. cases where you go to different levels of abstraction in your analysis (because different problems require more or less details to analyze), where you could apply different patterns to solve various problems etc etc
One question though, and slightly important too, is if there would be a business case to do it this way. Another way to do it would be to kick-start with analysis models and let them evolve into design models over time (this could be a beneficial option if you don’t connect any value to the analysis model themselves and want to be able to re-use them etc).
Anyone with thoughts/ideas?
Well back to more “management” tasks.
One that I’m exploring a bit is how xtUML and “MDA” ideas could be used to create separation of concern between very abstract analysis (or maybe “architecture” if you like) models and design models. Of course it is not so much the separation of concern I’m after as the possibility to do model to model transformation, but “soc” feels like a necessary means to achieve just that ;)
In my head, maybe I’ve got it wrong, this is initially not so difficult to achieve but when you put it in context it suddenly become a tad more problematic. Especially since it is not the pyramid-structure of transformation I’m after (you know, the “Babushka” structure…) but something a bit more intelligent where the transformation would handle e.g. cases where you go to different levels of abstraction in your analysis (because different problems require more or less details to analyze), where you could apply different patterns to solve various problems etc etc
One question though, and slightly important too, is if there would be a business case to do it this way. Another way to do it would be to kick-start with analysis models and let them evolve into design models over time (this could be a beneficial option if you don’t connect any value to the analysis model themselves and want to be able to re-use them etc).
Anyone with thoughts/ideas?
Well back to more “management” tasks.
onsdag 2 december 2009
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.
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.
måndag 30 november 2009
Supplier management
During last week I and three very senior colleagues had an interesting e-mail discussion with regards to supplier management. Our discussion started off as a simple question related to automotive where constant improvements are made and there is a constant drift towards more proactive OEM-engineering. The question was how supplier management is affected and whether or not it is taken care of properly. Think e.g. of the difference in degrees of innovative freedom between a ”build to print” supplier and a strategic partner.
If we are doing more and more model-based development with early verification etc are we reducing the suppliers to more and more ”b-to-p” or shall we involve them even earlier? There are a lot of options with different implications; the main point is that we should make a conscious choice.
Personally I think this dynamic is really interesting and sometimes I think it is not discussed (or planned for) enough and becomes more a happening based on purchase-model.
Well the mail-dialog ended up in some really good reflections and statements, if someone is interested I think Dennis should sum them up in a presentation since the subject is too big to just fire away in a short blog-post.
Or maybe you have some good ideas and will be the second one who dares to comment on this blog? Would be huge.
No more procrastination, time to get that report on xtUML and MDA going.
If we are doing more and more model-based development with early verification etc are we reducing the suppliers to more and more ”b-to-p” or shall we involve them even earlier? There are a lot of options with different implications; the main point is that we should make a conscious choice.
Personally I think this dynamic is really interesting and sometimes I think it is not discussed (or planned for) enough and becomes more a happening based on purchase-model.
Well the mail-dialog ended up in some really good reflections and statements, if someone is interested I think Dennis should sum them up in a presentation since the subject is too big to just fire away in a short blog-post.
Or maybe you have some good ideas and will be the second one who dares to comment on this blog? Would be huge.
No more procrastination, time to get that report on xtUML and MDA going.
Prenumerera på:
Inlägg (Atom)