Flawed Attribute Type Matching

From FetchWiki

Jump to: navigation, search

Contents

[edit] Status

  • Problem described.
  • Solution implemented.

[edit] Problem description

We have found in one of our cases that the types of merely 1.299 of the 13.141 attributes are resolved. While their declaredType, and declaredClass is correctly filled in, the TypedEntityResolver currently stops looking for the attribute type in case its declaration is not found in the include path.

[edit] Impact analysis

Attributes,Functions and Methods are subclasses of the TypedEntity type. (Note: in the future, GlobalVariables should also be considered as a TypedEntity subclass).

A TypedEntity has two fields indicating the type of the entity, and two fields indicating the source location of the type of the entity

  • declaredType -- a string representing the type as declared in the source (e.g., Foo<Bar,Baz>[] *)
  • resolvedType -- the name of the class at the core of the declaredType (e.g., Foo)
  • dst_sourceFile -- the file name declaring the resolvedType
  • dst_lineNr -- the line number at which the resolvedType is declared in the dst_sourceFile

During the construction of Attributes,Functions and Methods, the declaredType is initialized by the constructor itself. The other three fields mentioned above are initialized by the TypedEntityResolver.

In the processing of each TypedEntity, we ask the TypedEntityResolver to resolve the resolvedType, dst_sourceFile and dst_lineNr. In case the TypedEntityResolver is able to resolve the type of the entity (e.g., the type of the Attribute or the return-type of the Method or Function), these attributes are initialized.

When writing Attributes,Functions and Methods, the declaredClass field of the corresponding FAMIX entities is left blank in case the resolvedType attribute is empty. In case the dst_sourceFile and dst_lineNr are not empty, a destinationSourceAnchor field is written.

On its turn, CDIF2RSF does not create AttributeHasClassAsType relations unless (i) the declaredClass and destinationSourceAnchor fields of the Attribute FAMIX entity are filled in; and (ii) there is only a single class declared at this destination with the given name.

[edit] Relevance

In certain dependency analysis scenario's, there is a need to gather references to attributes of certain types. Currently, this is severely hindered by the fact that we know the types of merely 10% of the attributes.

[edit] Suggested Solution

In case we only know about a single declaration of a class with the specified name (the attribute type), than we shouldn't botter checking whether it is in the include path. This will both speed up things, as well as improve completeness.

Personal tools