During the development of real-time embedded system, the use of UML models as blueprints is a common practice with a focus on understandability rather than comprehensiveness. However, further in the development, these models must be completed in order to achieve the necessary validation and verification activities. They are typically performed by using several formal tools. Each tool needs models of the system at a given abstraction level, which are precise and complete enough with respect to how the tool processes them. If UML is appropriate for capturing multiple concerns, its multiple partial views without a global one increase the difficulty of locating inconsistency or incompleteness issues. Therefore, ensuring completeness is time consuming, fastidious, and error prone. We propose an approach based on the use of a UML textual syntax closely aligned to its metamodel: tUML. An initial prototype is described, and examples are given.
Using sketchy models is common during software systems development. Such models (also called contemplative models) are just drawings that cannot be automatically processed (e.g., transformed into code, or verified). In the use of such models as blueprints, the focus is on communication rather than on completeness. The UML language is a good candidate for that kind of practice. It is primarily a graphical notation, and it offers a relatively large set of diagrams for representing various concerns. Moreover, as it is a standard, one can expect that it is known by developers, and also by stakeholders. Therefore, it helps communicating a better understanding about the system under study, and supports a better collaboration with various specialists.
However, such contemplative use of UML models is only partially satisfactory.
Part of the effort to produce them cannot be automatically reused in further
development phases. Going from contemplative to productive models is a key
challenge of model-driven approaches [
In real-time embedded system development, this is even more important. The reliability and complexity of such systems require numerous verifications and validations activities all along the development process. These activities are based on the use of tools such as model checkers, theorem provers, code generators, and test generators. The use of UML in this context presents some issues. It has no standard formal semantics, and many semantic variation points. A many-diagram model may contain inconsistencies, and no global view helps their discovery. UML is semi-formal: a given drawing may have different interpretations. UML expressivity is not completely satisfactory for this domain.
Solutions to these issues have been developed. UML extensions have been
defined (e.g., the MARTE1 profile) to adapt it to the real-time domain.
Numerous works propose a variety of translations from part of UML to different formal
languages [
These solutions require that the verified model parts be precise, complete, and
unambiguous. Other parts may remain sketchy [
In this work, we propose an approach to bridge the gap between sketchy and (partially) precise models. We put some efforts in making it as independent of specific UML editors as possible. It is based on the use of a specific textual syntax called tUML that closely follows the UML metamodel structure, as well as on the use of additional constraints on models. Neither text nor graphical is better than the other. However, by complementing graphical tools with textual ones, we can get both their respective advantages.
We illustrate our approach with the pacemaker case study presented in [
Section 2 presents the approach in four steps: an overview of tUML (Section 2.1), a description of our prototype (Section 2.2), an explanation of its usage (Section 2.3), and a discussion (Section 2.4). Then, Section 3 compares tUML to some related works. Finally, we conclude in Section 4. 2 2.1
tUML Presentation tUML is a textual concrete syntax for a subset of the standard UML metamodel. A detailed definition and justification of this subset is beyond the scope of this
paper. Roughly, it consists of the parts of the UML metamodel that correspond to
the three following diagrams: 1) class diagrams, 2) composite structure diagrams,
and 3) state diagram. These diagrams are typically the ones used to model
realtime embedded systems. We do not attempt to cover the whole UML metamodel,
but built our subset bottom-up, making sure we can verify what we model [
In order to illustrate: 1) the tUML textual syntax, and 2) its relations with
the standard graphical notation, we use the pacemaker case study introduced in
[
Listing 1 is an excerpt of the corresponding tUML definition. Class Cardiologist is defined as implementing two interfaces (line 1), and using a third one 2 All interface names from original case study have been simplified to increase clarity.
Listing 1. Cardiologist excerpt 1 class C a r d i o l o g i s t behavesAs S M C a r d i o l o g i s t implements
,→IC ar dio log ist _P rov ide d , I L e a d _ R e q u i r e d { // [ ports ] private operation an al yse Mod e ( ) ; private operation g e n e r a t e P u l s e ( ) ; public operation g e t A c c e l e r a t i o n ( ) ; stateMachine S M C a r d i o l o g i s t { region Region0 {
// [ state machine contents ]
2
3
4
5
6
7
8
9 }}}
10 usage Usage0 of I L e a d _ P r o v i d e d by C a r d i o l o g i s t ;
+ dcm:DeviceControlMonitor[
System
<<ClientServerPort>>
+pgCom:I_DCM[
Composite Structure. Figure 2 (Figure 5 in [
Listing 2 is an excerpt of the corresponding tUML definition. Class System is
defined at lines 1-4 as consisting of a PulseGenerator part at line 2, a
DeviceControlMonitor part at line 3, and a connector at line 4. Class PulseGenerator
is defined at lines 5-9 with a port at line 7. This class is also composite but its
parts (line 6) and connectors (line 8) are not detailed here. Class
DeviceControlMonitor is defined at lines 10-11, and only contains a port (line 11).
State Machines. Figure 3 (Figure 12 in [
Listing 2. System composite structure
1 class System {
2 public composite pg [
Listing 3 is an excerpt of the corresponding tUML definition. State
TriggeredPacing is defined at lines 1-9 as consisting of region Region0. This region
itself consist of an initial pseudo-state (line 7), two states StartingPulse (lines
8) & WaitingPulse (line 9), and four transitions (lines 3-6). Each transition has
a name. Each transition with a trigger refers to an event by name (escaped
between double quotes because they contain spaces). Events are defined in a part
of the model not shown here. Finally, the two transitions having an effect specify
it as an empty opaque behavior (lines 5-6), with only its name specified.
Now that tUML has been presented, we will describe its current prototype
implementation. Eclipse Modeling3 has been used in the following way:
– Eclipse UML provides the UML abstract syntax implementation (very
close to the standard), on top of EMF (Eclipse Modeling Framework). Tools
based on Eclipse UML (e.g., Papyrus) are directly compatible with tUML.
– TCS [
Listing 3. Cardiologist state machine except 1 state T r i g g e r e d P a c i n g { 2 region Region0 { 3 Initial0 −>S t a r t i n g P u l s e : Transition0 ; 54 WSatiatritnignPguPluslese−>−>S tWaarittiinnggPPuullssee :: TTrraannssiittiioonn12 :: ”” TSEE −− cSuernrseendtPMuoldsee ”. RP/” / ; ,→opaqueBehavior g e n e r a t e P u l s e ; ; 6 WaitingPulse −>S t a r t i n g P u l s e : Transition3 : ” TE − currentMode .
,→pulseDelay ” / opaqueBehavior g e n e r a t e P u l s e ; ;
7 i n i t i a l pseudoState Initial0 ;
8 state S t a r t i n g P u l s e ;
9 state Wa iti ngP uls e ; }}
– ATL [
The PlantUML export enables graphical rendering of tUML models.
Figures 1 and 3 have actually been generated through this process. Figure 2 is
however still the original from [
Our prototype notably has the following limitations. Conversions between textual and abstract syntax currently work on whole models, and graphical information is not synchronized yet. Fine-grain synchronization would be helpful but is not mandatory in our approach. Apart from tools based on Eclipse UML, only a Rhapsody import has been implemented so far. 2.3
The previous sections gave an overview of tUML and of its prototype implementation. This section will give an overview of how they can be used to fix sketchy models. Before creating models and fixing them, it is first necessary to consider how they will be used (e.g., for code generation, or verification). Then, an expert can define what a correct model precisely is in that context. This will typically lead to a list of custom validation constraints. This work does not need to be performed for each model, but only for each usage of models (e.g., for a given code generator, or for a given verification tool).
The user typically follows the five-step process described below: 1. Creating Sketchy Model. A modeling tool is first used to create a sketchy model. This is generally done with a graphical UML editor. 2. Converting to tUML. Using the extraction tool presented previously, the user serializes the model in tUML.
3. Identifying Problems. Issues are identified by applying standard UML constraints, as well as custom constraints if applicable. They are shown in the tUML editor. If no problem is identified, then we can go to step 5 4. Fixing Problems. The user can tune the model in order to fix problems.
This is often easier to do textually because all information is presented at once. In comparison, a graphical editor often requires opening various property sheets. Then, we go back to step 3 in order to check if the tackled issues are fixed, and if some issues remain. 5. Use Fixed Model. Now that all identified problems have been fixed, the model can be used in four notable ways: 1) reloading the model in the original UML tool, or another one, 2) generating code, 3) verifying the model using formal methods, and 4) rendering the model using tools such as PlantUML (see prototype description).
Our pacemaker example was initially created as a sketchy model, not to be
automatically processed. Later, we decided to attempt to use some verification
tools [
After presenting tUML, its implementation, and its usage, we now discuss the advantages and drawbacks of our approach. Firstly, tUML has all the benefits of a textual language, such as: 1) global search and replace, 2) relatively easy editing with no need to click through numerous property pages, 3) support for diff/patch and text-based version control systems, and 4) no need to focus on graphical layout (indentation being much easier). Other advantages of tUML when compared with the standard UML graphical notation include: – Transparency. All model elements are immediately visible, and no aspect of the model is hidden away in property sheets accessible via multiple clicks. – Global view. Whereas the graphical notation fragments the model into separate diagrams, tUML provides a single global view. – Reduced redundancy. There is no need to duplicate elements (even partially) across various diagrams. – Proximity to metamodel. The textual syntax of tUML follows the UML metamodel very closely.
Proximity to the UML metamodel notably has the advantage that it is relatively easy to figure out where a given aspect of the UML metamodel can be accessed. Moreover, this enables relatively precise reporting of errors as text markers, even though they are actually identified on the abstract syntax. Graphical editors cannot always do this. For instance, in Papyrus, some errors on class members are shown on their owning class in the class diagram.
Although this is not due to the textual nature of tUML, the automatic generation of views presents some advantages as well. Even though tUML models typically come from graphical UML editors, this has the advantage of reformulating the models in a different way, possibly helping to spot issues. Moreover, the non-standard context diagram is especially helpful in finding messages that are missing (e.g., when their emission or reception are not properly modeled).
Of course, tUML also has some limitations: – Verbose. All model elements have to appear in a single text file. Therefore, even though they are visible, details of interest may actually be drowned in unnecessary details. Global view is thus both an advantage and a drawback. To mitigate this issue, generation of partial textual views should be investigated. Synchronization with the whole model may become an issue. – Non-standard. Because it is not standard, tUML needs to be learned even by UML experts. This adds one difficulty to its usage. – Incomplete. Only a subset of UML is currently supported. This subset is especially targeted at real-time embedded systems. Using tUML in other contexts may prove difficult (e.g., if one needs activities). – Textual. Finally, even though most advantages of tUML are due to its textual nature, some users may not accept to type UML code. 3
UML is best known for its graphical notation, but tUML is not the first proposed UML textual notation. The OMG has notably standardized two of its ancestors5: – HUTN initially seems to provide a solution since it promises automatic derivation of a human-usable textual notation from any metamodel. However, this genericity leads to relatively verbose syntaxes.
– Alf defines a specific textual syntax for a UML subset. The OMG thus acknowledges the fact that HUTN is not fully adapted to this kind of use. Unfortunately, Alf is limited to a different subset of UML, which is not adapted to real-time embedded systems. tUML is thus significantly different from Alf. Notably, Alf only provides activities to specify behavior, whereas tUML focuses on state machines. Moreover, Alf specifies a new metamodel that is closer to its concrete syntax than the standard UML metamodel. Although a bidirectional mapping to the standard UML metamodel is also provided, such a gap between textual and graphical notations may make the job of fixing models for formal verification purposes more difficult.
Most non-standard textual UML notations aim at producing sketchy models by leveraging auto-layout tools. We cannot describe them all6 here, but two notable ones are: – TextUML7 is relatively close to tUML but does not follow the UML metamodel as closely (notably wrt. its action language). – PlantUML has the advantage of being less verbose and more permissive than all other mentioned approaches. However, its objective is only to automatically generate visual diagrams. It does not follow the standard metamodel. Moreover, it is so permissive that many elements (e.g., class members, and transition labels) can be represented by arbitrary text. Apart from following very strict conventions, there is no way to guarantee that these elements actually follow the UML syntax.
Some approaches like UML/P [
In this paper, we have presented an approach that helps fixing incomplete UML models to make them suitable as input for verification and validation activities and tools. This approach relies on tUML: a specific textual notation for UML that notably follows its metamodel very closely. A prototype implementation has been used on a couple of case studies (including the pacemaker one presented here), and half a dozen different models. tUML significantly helped in discovering issues, and therefore in fixing them.
We have so far demonstrated the worth of the approach, but its development is still in progress. It should be further studied and refined, notably by applying it to more case studies, including industrial ones. This would lead to a complete evaluation. This should bring out more kinds of constraints to check on models, 6 See http://modeling-languages.com/uml-tools/#textual for a bigger list.
as well as help figuring out in which direction the supported UML subset should be extended. All sketchy models issues cannot be resolved automatically. It could nonetheless be useful to provide quick fixes8 in order to not only pinpoint issues, but also partially automate their resolution.
A possible extensions of our work on tUML would be to propose it to the OMG as an extension of Alf, which notably lacks support for state machines. 8 A technique coming from programming environments (see http://wiki.eclipse. org/FAQ_What_is_a_Quick_Fix%3F).