UML è stato sviluppato come linguaggio per modellare sistemi completi di software. Pero si adatta anche motlo bene per descrivere solo parti di sistemi. Qua è tuttavia piu necessario que nel primo caso di fissare precisamente la semantica di esso. Non solo la definzione informale dei costrutti contribuisce a malintesi, ma anche la loro assenza. Nel seguente allora sia descritto quando, per quale motivo e in quale modo specifcazioni possono essere lasciati liberi  senza perdità di informazione.

Beispiel 1:

In figura 1 una classe isolata senza super classe e diagramma statechart    è dichiarata. Argumentando su un livello sintattico solo essa non ha un comportamento (representabile da un diagramma statechart).  Diu fatto pero le operazioni dichiarate debbano essere invocate una dopo l`altra. Ha senso allora di assumere il diagramma  statechart dipinto in figura 2 (solo una delle due transizioni e visibile, saluti a Rational). Così le operazioni, dopo che  l`oggietto sia stato creato, possono essere invocate in sequenza, finchè l`oggietto sia distrutto. É sicuramente né necessario né realistico di dipingere ognun diagramma statechart per tutte le classi con tutte le operazioni. Si consiglia questa prima interpretazione di un diagramma statechart mancante.

Tuttavia la cosa diventa interessante solo, quando una classe aparte di attributi e operazioni eredisce anche uno statechart diagram dal suo super classe come dipinto in figure 3 e figura 4.

La sottoclasse definiendo nuove operazioni, che non appariscono nel suo statechart, ci sono al meno tre interpretazioni.

1. La operazione va bene con un certo schema risultando dalla superclasse.
2. La operazione puo sempre essere invocata.
3. Abbiamo trovato un errore che non puo essere risolto automaticamente.

Nel secondo caso la situazione é molto piu facile. La operazione puo essere definito come una operazione recorsiva da tutti i stati.

lavori in corso. :-((