Last Updated on Tuesday, 31 August 2010 10:53 Written by Dr.Onno van Roosmalen

The second problem with the STP (profile for Schedulability Performance and Time) or Real-time profile is more fundamental. UML 2 has already incorporated modeling approaches for Real-time in the form of composite structure diagrams. Various variants of composite structure techniques appeared during the nineties fairly independently. Some of these include: ROOM from Northern Telecom in Canada, Rhapsody from Ilogix (as the OO variant of Statemate), and closer to home POOSL (Parallel Object-Oriented Simulation Language) from the Electrical Engineering department of the TU/e and Koala from Philips Research. The importance of composite structures for Real-time lies in the fact that the sharing of objects can be accurately expressed in so called structured classes. In particular, multiplicities on connectors between parts of a structured class enable the determination of blocking on shared objects (resources) and to perform scheduling analysis. The use of Real-time annotations (in the form of stereotypes and tagged values) on structured classes is far superior to using such annotations on instance specifications as described in the SPT. The use of instance specification is at most specification by example while annotations on parts of structured classes, or on lifelines representing such parts, has a much more general semantics. Again, the concrete syntax introduced by the SPT profile is hardly affected, but the abstract syntax and semantics are. The abstract syntax is relevant for model-exchange between tools, e.g. between a design tool (like Rhapsody) and scheduling analysis tools. It seems to me, that the people who wrote the SPT did not understand the relevance of structured classes. In any case, I think that rewriting and updating the SPT is an important step for OMG to take.

Login to comment.