Back to TTCN-3 Refactoring Catalog

Restrict Imports

Restrict import statements for smaller inter-module interfaces and less processing load for TTCN-3 tools.

Motivation

TTCN-3 offers the possibility to restrict import statements. The inter-module interfaces are minimized when only declarations are imported that are actually used. As a result, modularity and reuse possibilities are improved and the possibility for name clashes is reduced. Furthermore, the module dependencies and relationships become more clear. Depending on the implementation, the processing load of TTCN-3 tools may be reduced when the inter-module dependencies are minimized. Restrict Import can be applied whenever module dependencies or the internal structure of type declarations change (e.g. through application of Group Fragments. Note that the provided mechanics do not exploit all restriction possibilities of TTCN-3. Specifically group exceptions can make an import statement hard to understand and should be used only when absolutely necessary.

Mechanics

  • Find the declarations for all references which are imported from other modules and used in the source module.
  • Replace the existing import statements in the source module with new import statements (one import statement for each module on which the source module depends on) which are restricted by listing the concrete declarations names found in the previous step.
  • Compile.
  • If all declarations of a kind are listed within a restriction, remove all concretely listed declaration names of this kind and add a kind import for all elements of this kind (e.g. type all, altstep all, etc.).
  • Compile.
  • If all declarations of a group are listed within a restriction, remove all concretely listed declaration names of this group and add a group import.
  • Compile.
  • Compare the number of all concretely listed elements of a kind or a group to the total number of elements of their corresponding kind or group within their module. As a loose rule, if the difference is equal or less than three and the number of concretely listed elements is greater than three, this concrete kind or group import list should be replaced by a statement importing all elements of a kind or a group with these few elements as exceptions (e.g. type all except concreteDeclaration)
  • Compile and validate.

Example

The first listing contains two modules. ExampleModule? contains declarations which are grouped according to their types. DependantModule? uses only the constants from ExampleModule?, but imports all declarations. Hence, the inter-module interface is bigger than it needs to be.

module ExampleModule { 
	group consts { 
		const integer c_defaultSmtpPort := 25;
		const integer c_defaultSmtpSSLPort := 465;
	} 
	
	group types { 
		type charstring Answer;
		type charstring Question;
	} 
	
	group structured { 
		type record SmtpMessage {
			// ...
		}
	}	
} 

module DependantModule { 
	import from ExampleModule all; 
	
	testcase tc_exampleTestCase() runs on ExampleComponent {
		// ...
		theAddress.portField := c_defaultSmtpPort;
		theAddress.portFieldSSL := c_defaultSmtpSSLPort;
	}
} 

After applying the Restrict Imports refactoring, the situation is improved by adding a restriction to the import statement. In the first step, the restriction contains the concrete variable names c_defaultSmtpPort and c_defaultSmtpSSLPort. In the second step, this is optimized by replacing the two concrete imports with a group import.

module ExampleModule {
	group consts { 
		const integer c_defaultSmtpPort := 25;
		const integer c_defaultSmtpSSLPort := 465;
	} 
	
	group types { 
		type charstring Answer;
		type charstring Question;
	} 
	
	group structured { 
		type record SmtpMessage {
			// ...
		}
	}	
}
module DependantModule {
	import from ExampleModule { group consts }; 
	
	// ...
	
	testcase tc_exampleTestCase() runs on ExampleComponent {
		// ...
		theAddress.portField := c_defaultSmtpPort;
		theAddress.portFieldSSL := c_defaultSmtpSSLPort;		
	}
}

Back to TTCN-3 Refactoring Catalog