After many years of resistance it seems that modeling is gaining foothold in the area of embedded software development. I do not have any hard numbers about the acceptance though. Anyone able to provide a pointer here?
Development of embedded software has - like in other areas of software development - grown more complex and the pressure of delivering in ever shorter development cycles has increased. A natural way to deal with complexity is the use of software platforms and modeling.
Although embedded developers have no ears for the OMG's MDA, UML currently is the leading notation for modeling embedded software. The problem with acceptance of UML in embedded has several reasons, one of the most important ones is that UML is an object-oriented notation where much of embedded software development still is functional. UML thus requires developers to adopt another way of thinking about development, which - naturally - is meeting with heavy resistance. Furthermore, UML - as is - is poorly suited for embedded development. While reading about companies like ARTiSAN, I was surprised to see they basically have extended the UML metamodel with embedded-specific (read: domain-specific) concepts: time tags in the sequence diagram in order to add support for timing issues, tweaked UML diagrams in creating a system definition diagram and a system architecture diagram, and finally by adding a whole new diagram with completely new-to-UML-modeling concepts: a concurrency diagram. Nice job as they did haul Siemens VDO in with it, who are using their tool for engine management development.
After reading about it I wondered: Why not take it a step further? UML is missing a lot of notation possibilities to capture embedded software and systems correctly, it still requires developers to think in an OO-way, and even IF they already think in an OO-way then it still does not significantly raise abstraction nor support the design work: What does UML really say about engine management systems, about pacemakers, mobile phones, avionics or weapon systems? Yep....zilch.
If however you define a design language yourself, you have the ability to base it on which ever orientation (OO, functional, look & feel, generated output, hardware architecture, variability, domain concepts) is most suited for your situation. There will be no need to learn a whole new notation as you will use the same concepts (and rules that govern them) that you normally speak about (It will be much more easy to communicate with than with UML) and are familiar with. Additionally, it will not allow you to generate just 80% of the production code but 100%. Forget about reverse engineering....you won't need it anymore.
I will likely write more on this area, embedded development is extremely well suited for DSM.
Development of embedded software has - like in other areas of software development - grown more complex and the pressure of delivering in ever shorter development cycles has increased. A natural way to deal with complexity is the use of software platforms and modeling.
Although embedded developers have no ears for the OMG's MDA, UML currently is the leading notation for modeling embedded software. The problem with acceptance of UML in embedded has several reasons, one of the most important ones is that UML is an object-oriented notation where much of embedded software development still is functional. UML thus requires developers to adopt another way of thinking about development, which - naturally - is meeting with heavy resistance. Furthermore, UML - as is - is poorly suited for embedded development. While reading about companies like ARTiSAN, I was surprised to see they basically have extended the UML metamodel with embedded-specific (read: domain-specific) concepts: time tags in the sequence diagram in order to add support for timing issues, tweaked UML diagrams in creating a system definition diagram and a system architecture diagram, and finally by adding a whole new diagram with completely new-to-UML-modeling concepts: a concurrency diagram. Nice job as they did haul Siemens VDO in with it, who are using their tool for engine management development.
After reading about it I wondered: Why not take it a step further? UML is missing a lot of notation possibilities to capture embedded software and systems correctly, it still requires developers to think in an OO-way, and even IF they already think in an OO-way then it still does not significantly raise abstraction nor support the design work: What does UML really say about engine management systems, about pacemakers, mobile phones, avionics or weapon systems? Yep....zilch.
If however you define a design language yourself, you have the ability to base it on which ever orientation (OO, functional, look & feel, generated output, hardware architecture, variability, domain concepts) is most suited for your situation. There will be no need to learn a whole new notation as you will use the same concepts (and rules that govern them) that you normally speak about (It will be much more easy to communicate with than with UML) and are familiar with. Additionally, it will not allow you to generate just 80% of the production code but 100%. Forget about reverse engineering....you won't need it anymore.
I will likely write more on this area, embedded development is extremely well suited for DSM.
1 comment:
Thanks for your comments Angelo, they are very helpful as I plan to be writing more on this subject, not just on the blog.
Post a Comment