4 Runtime Verification using UML and OCL
4.4 Abstraction Concepts
One of the main advantages of our monitoring approach is the possibility to validate an implementation in an abstract way. By using UML as the modeling language, one auto-matically gets a first abstraction by the support of associations. By using associations, related instances can be identified more easily in diagrams than by using attributes.
However, there are other abstractions that can be used by our monitoring approach.
Three of them are described in the next sections.
4.4.1 Abstracted Superclass
Since a PAM does not need to contain all implementation classes, but still needs to keep track of instances of possibly unmodeled subclasses, the concept of an abstracted superclass is introduced (shortly described in [A17W]). An abstracted superclass is a class in a PAM that collects instances of unmodeled subclasses of the implementation to still be able to access all instances of an incomplete modeled generalization tree.
Consider the inheritance trees shown in Fig. 4.12 on the next page. On the left side, the complete inheritance tree regarding settlements of the implementation of FreeCol is shown, whereas on the right side only the classes considered by the PAM are shown. To
4.4 Abstraction Concepts
Figure 4.12: Example of an Abstracted Superclass
still be able to navigate from a unit to its location, all instances of the implementation classIndianSettlementand the corresponding links must be available. In this example, the class Settlement acts as an abstracted superclass by saving instances of the class IndianSettlement as instances of itself inside a snapshot.
This concept adds additional information to cover into the basic monitoring metamodel discussed earlier. The relevant parts of the metamodel are shown in Fig. 4.13 on the following page. The concept of an abstracted superclass adds two additional operations and new constraints to the metamodel, which are shown below the figure. The operation isAbstractedSuperclass()identifies a class as an abstracted superclass, if it is mapped to a runtime type that has at least one subtype that does not map to a class in the PAM.
Note that only direct subtypes are considered. If an indirect subtype is not mapped to a class in the PAM, there could be another abstracted superclass in between. To retrieve all covered types for a given class in the PAM the operation abstractedTypes() is introduced. The operation calculates all implementation types for which instances need to be mapped to the PAM class. The operation needs to examine the whole inheritance graph, since an unmapped type can have other unmapped types. However, if a direct or indirect subtype is covered by another abstracted superclass this type and it subtypes are not included into the result.
In addition to the previously explained operations the constraints for a valid runtime snapshot need to be aligned. For a given class of a PAM, all of its objects need to be mapped to the runtime instances of all covered runtime types:
1 context MClass inv c o v e r e d I n s t a n c e s :
2 s e l f . o b j e c t . vmObject = s e l f . a b s t r a c t e d T y p e s ( ) . i n s t a n c e
Figure 4.14 on page 71 shows the instance of the metamodel part used in this section that represents the example given in Fig. 4.12 including two different runtime instances.
superclass subclass
*
*
supertype subtype
*
* VMType name : String
isClassType : Boolean allSubTypes() : Set(VMType)
VMObject MObject
MClass name : String
isAbstractedSuperclass() : Boolean abstractedTypes() : Set(VMType)
subclass*
superclass
* vmType 0..1 pamClass
0..1
vmObject 1
pamObject 0..1 subtype*
supertype
*
instance
* 1 type
object * clazz 1
1 context MClass : : i s A b s t r a c t e d S u p e r c l a s s ( ) :Boolean def:
2 not s e l f . vmType . o c l I s U n d e f i n e d ( ) and
3 s e l f . vmType . subtype−>e x i s t s ( vmSubType |
4 vmSubType . pamClass . o c l I s U n d e f i n e d ( ) )
5 context MClass : : a b s t r a c t e d T y p e s ( ) :Set(VMType) def:
6 Set{ s e l f . vmType}−> c l o s u r e ( s t | s t . subtype−>s e l e c t (
7 pamClass . o c l I s U n d e f i n e d ( ) ) )
Figure 4.13: Relevant Parts of the Metamodel for Abstracted Superclasses
The runtime instancejamestownVMof the runtime typeColonyis linked to the snapshot object jamestownPAM of the class Colony, whereas the runtime instance xaymacaVM of the runtime typeIndianSettlementis linked to the snapshot objectxaymacaPAM, which is an instance of the abstracted superclassSettlement. Using the described approach it is ensured, that no information is lost at association ends or attributes of the type of an abstracted superclass. The navigation from Unit to the association end locationstill leads to all settlements including the unmodeled classIndianSettlement.
To be able to determine that an object is not a runtime instance of the given class, a monitor implementation can provide special attributes, for example, an attribute for the concrete class name.
4.4.2 Connected Instances
For runtime verification, it is sometimes necessary to include classes that are not only specific to the application model [51]. During runtime, all instances of them would be covered by a snapshot, including those instances that are not connected to any instance of a relevant PAM class. For example, if the monitoring of the Java collection class ArrayList is required, the monitor would include all lists contained in the runtime.
Since lists are used heavily in different parts of the JRE this would lead to a much
4.4 Abstraction Concepts
settlementVM:VMType name='Settlement' isClassType=true
xaymacaPAM:MObject
jamestownVM:VMObject colonyVM:VMType name='Colony' isClassType=true
settlementPAM:MClass name='Settlement'
xaymacaVM:VMObject locationVM:VMType
name='Location' isClassType=false
locationPAM:MClass name='Location'
jamestownPAM:MObject colonyPAM:MClass
name='Colony' indianSettlementVM:VMType
name='IndianSettlement' isClassType=true
vmObject pamObject
subclass superclass
instance type
subtype supertype
subtype supertype
subclass superclass
object clazz
vmType pamClass
instance type
object clazz
vmType pamClass
subtype supertype
vmObject
pamObject
Figure 4.14: Instance of the Monitor Metamodel with an Abstracted Superclass
bigger snapshot than required. To avoid this, the USE monitor supports the annotation property onlyConnectedwhich enables the monitor to exclude instances not connected to the graph of objects defined by a PAM. Note that this feature requires a lot of computation since the monitor needs to determine for each instance whether it is used by a class of the PAM.
4.4.3 Excluding Sub-Calls
While the previously described features consider structural abstractions, also abstrac-tions for the dynamic behavior were recognized as being useful. One of such features is the possibility to exclude the monitoring of all sub-calls inside an operation, even if the called operations should be monitored. This can be used reduce the validation overhead by excluding irrelevant parts and also to reduce the complexity of the resulting diagrams.
As an example, consider the excerpt of a Java console application shown in Listing 4.3 on the next page, which asks a user for a regular expression, an input string to match, and prints all found matches to the console. Monitoring the operationfind()of the class Matcher would unveil that the Java implementation of the console also uses a matcher to format the given output string, which may contain a format pattern, as shown in the
Listing 4.3: Simple Java Console Application
1 . . .
2 p a t t e r n = P a t t e r n . c o m p i l e ( c o n s o l e . r e a d L i n e ( "%nEnter your r e g e x : " ) ) ;
3 i n p u t = c o n s o l e . r e a d L i n e ( " Ent er i n p u t s t r i n g t o s e a r c h : " ) ;
4 matcher = p a t t e r n . matcher ( i n p u t ) ;
5
6 while ( matcher . f i n d ( ) ) {
7 c o n s o l e . f o r m a t ( " I found t h e t e x t \"% s \ " s t a r t i n g a t " +
8 " i n d e x %d and e n d i n g a t i n d e x %d.%n " ,
9 matcher . group ( ) , matcher . s t a r t ( ) , matcher . end ( ) ) ;
10 }
11 . . .
sequence diagram in Fig. 4.15 on the facing page. To suppress the monitoring of these calls, the operationreadLinein the PAM can be annotated as follows:
1 c l a s s C o n s o l e
2 operations
3 @Monitor ( i g n o r e S u b C a l l s =" t r u e " )
4 r e a d L i n e ( prompt :String, a r g s :Sequence(OclAny) ) :String
5 end
Using this annotation excludes the internal usage of the class Matcher and removes the calls inside the gray box and the now unused objects including their lifelines from the shown sequence diagram. The resulting trace is now more focused on the intended monitoring.