Q: Are there UML constructs that should not be used in embedded systems?
Q: Are there UML constructs that should not be used in embedded systems?
25.08.2008 12:21
The UML was originally created for use in "native" systems.
Are there constructs that can not be used on embedded systems? or constructs that must be used in a specific way?
Re: Q: Are there UML constructs that should not be used in embedded systems?
27.08.2008 17:53
One important thing is, to avoid dynamic allocation. A better way is to use static allocation. To achieve this you should not use "*" associations on Associations for multiplicity. Better is, to use a fixed size of elements. In Rhapsody for example leads this to static allocation if there a linked associations between objects.
See also: How to create static object with multiplicity (a simple example in Rhapsody)
Re: Q: Are there UML constructs that should not be used in embedded systems?
27.08.2008 18:06
Also important is to avoid too many state-chart constructs like history connectors. This will generate more code.
Also try to let the OO principles do the work for you. Similar Classes can often be mixed if you think about it carefully. An example: I recently saw a model where somebody had 2 classes: com1 and com2. The programmer hadn't realize that com ports are just classes that have run-time objects that must be mapped on physical addresses (volatile) and then the ports are equal. Saved a lot of code.
Another example is a menu system where the progarmmer created a class for every menu item. We rewrote it to a more general "menu" class that was linked to itself and save a massive amount of code. So the advice is: Be aware of the constructs that you use but do not be afraid of them!