Bidirectional feature group connection produces incorrect connection instance

[thari]

Summary

Osate produces connection instances with both source and destination being the same port.

Expected and Current Behavior

Osate instantiation of a system with bi-directional feature group connections between parent and sub components produces the backward connection instance incorrectly. It is supposed to make a connection instance from a leaf level component out port to the top level component's out port. However, Osate connects back to the leaf level components out port.

Steps to Reproduce

1. Instantiate the toplevel.i system from the provided model
2. Check for the connection instances
3. The second connection instance's source and destination are same

package FeatureGroupTest
public
	
	feature group abstract_fg
		
	end abstract_fg;
	
	feature group refined_fg extends abstract_fg
		features 
			test_feature1 : in data port;
			test_feature2 : out data port;
	end refined_fg;
	
	system abstract_toplevel
		features 
			fg_port : feature group abstract_fg;
	end abstract_toplevel;
	
	system toplevel extends abstract_toplevel
		features
			fg_port : refined to feature group refined_fg;
		properties
			Classifier_Substitution_Rule => Type_Extension; --HT
	end toplevel;
	
	system implementation toplevel.i
		subcomponents
			sub : process subsystem.i;
		connections
			conn:  feature group fg_port <-> sub.fg_port;
	end toplevel.i;
	
	process abstract_subsystem
		features 
			fg_port : feature group abstract_fg;
	end abstract_subsystem;
	
	process subsystem extends abstract_subsystem
		features 
			fg_port : refined to feature group refined_fg;
		properties
			Classifier_Substitution_Rule => Type_Extension; --HT
	end subsystem;
	
	process implementation subsystem.i
		subcomponents
			th : thread subsub;
		connections
			conn2 : feature group fg_port <->th.fg_port;
	end subsystem.i;
	
	thread subsub
		features 
			fg_port : feature group refined_fg;
	end subsub;
	
end FeatureGroupTest;

Other Observation

1. Even when the connection instance of two different ports are made, the connection reference with same source and destination exists

2. Bug exist with and without the feature group refinement

Environment

• OSATE Version: 2.7.0, 2.7.1 and the latest master branch development environment
• Operating System: Mac

[AaronGreenhouse]

Updated the example to see what happens when the connections are declared in the other direction (that is, change the roles of the src and dest in the connection declarations):

package FeatureGroupTest
public
	
	feature group abstract_fg
		
	end abstract_fg;
	
	feature group refined_fg extends abstract_fg
		features 
			test_feature1 : in data port;
			test_feature2 : out data port;
	end refined_fg;
	
	system abstract_toplevel
		features 
			fg_port : feature group abstract_fg;

			fg_port2 : feature group abstract_fg;
	end abstract_toplevel;
	
	system toplevel extends abstract_toplevel
		features
			fg_port : refined to feature group refined_fg;
			
			fg_port2 : refined to feature group refined_fg;			
		properties
			Classifier_Substitution_Rule => Type_Extension; --HT
	end toplevel;
	
	system implementation toplevel.i
		subcomponents
			sub : process subsystem.i;
		connections
			conn:  feature group fg_port <-> sub.fg_port;

			conn_other:  feature group sub.fg_port2 <-> fg_port2;
	end toplevel.i;
	
	process abstract_subsystem
		features 
			fg_port : feature group abstract_fg;

			fg_port2 : feature group abstract_fg;
	end abstract_subsystem;
	
	process subsystem extends abstract_subsystem
		features 
			fg_port : refined to feature group refined_fg;

			fg_port2 : refined to feature group refined_fg;
		properties
			Classifier_Substitution_Rule => Type_Extension; --HT
	end subsystem;
	
	process implementation subsystem.i
		subcomponents
			th : thread subsub;
		connections
			conn2 : feature group fg_port <->th.fg_port;

			conn2_other : feature group th.fg_port2 <-> fg_port2;
	end subsystem.i;
	
	thread subsub
		features 
			fg_port : feature group refined_fg;

			fg_port2 : feature group refined_fg;
	end subsub;
	
end FeatureGroupTest;

The results are interesting in that the error doesn't exists in the other direction:

[AaronGreenhouse]

This is true for regular bidirectional port connections as well. That is, this is not a feature group problem.

package BiDirPortTest
public
	
	system abstract_toplevel
		features 
			fg_port : feature ;

			fg_port2 : feature ;
	end abstract_toplevel;
	
	system toplevel extends abstract_toplevel
		features
			fg_port : refined to in out event port;
			
			fg_port2 : refined to in out event port;
		properties
			Classifier_Substitution_Rule => Type_Extension; --HT
	end toplevel;
	
	system implementation toplevel.i
		subcomponents
			sub : process subsystem.i;
		connections
			conn:  port fg_port <-> sub.fg_port;

			conn_other:  port sub.fg_port2 <-> fg_port2;
	end toplevel.i;
	
	process abstract_subsystem
		features 
			fg_port : feature;

			fg_port2 :feature;
	end abstract_subsystem;
	
	process subsystem extends abstract_subsystem
		features 
			fg_port : refined to in out event port;

			fg_port2 : refined to in out event port;
		properties
			Classifier_Substitution_Rule => Type_Extension; --HT
	end subsystem;
	
	process implementation subsystem.i
		subcomponents
			th : thread subsub;
		connections
			conn2 : port fg_port <->th.fg_port;

			conn2_other : port th.fg_port2 <-> fg_port2;
	end subsystem.i;
	
	thread subsub
		features 
			fg_port : in out event port;

			fg_port2 : in out event port;
	end subsub;
	
end BiDirPortTest;

[AaronGreenhouse]

Simplified the broken port connection example:

package BiDirPortSimple
public
	system toplevel
		features
			fg_port : in out event port;
		properties
			Classifier_Substitution_Rule => Type_Extension; --HT
	end toplevel;
	
	system implementation toplevel.i
		subcomponents
			sub : process subsystem.i;
		connections
			conn:  port fg_port <-> sub.fg_port;
	end toplevel.i;
	
	process subsystem 
		features 
			fg_port : in out event port;
		properties
			Classifier_Substitution_Rule => Type_Extension; --HT
	end subsystem;
	
	process implementation subsystem.i
		subcomponents
			th : thread subsub;
		connections
			conn2 : port fg_port <->th.fg_port;
	end subsystem.i;
	
	thread subsub
		features 
			fg_port : in out event port;
	end subsub;	
end BiDirPortSimple;

[AaronGreenhouse]

EDIT: This went away after I restarted OSATE. Strange. Going to keep this comment for now in case it comes back.

More weirdness. I replaced the bidirectional connection in the above example with two directional connections:

package BiDirPortSimple2
public
	system toplevel
		features
			fg_port : in out event port;
		properties
			Classifier_Substitution_Rule => Type_Extension; --HT
	end toplevel;
	
	system implementation toplevel.i
		subcomponents
			sub : process subsystem.i;
		connections
			--conn:  port sub.fg_port -> fg_port;
			conn_other:  port fg_port -> sub.fg_port;
	end toplevel.i;
	
	process subsystem 
		features 
			fg_port : in out event port;
		properties
			Classifier_Substitution_Rule => Type_Extension; --HT
	end subsystem;
	
	process implementation subsystem.i
		subcomponents
			th : thread subsub;
		connections
			--conn2 : port th.fg_port -> fg_port;
			conn2_other : port fg_port -> th.fg_port;
	end subsystem.i;
	
	thread subsub
		features 
			fg_port : in out event port;
	end subsub;	
end BiDirPortSimple2;

This semantic connection from inside to the outside (sub component to the border of the toplevel) is fine. But the semantic connection from the outside to the inside (from the edge of toplevel to the subcomponent) is missing links to the declared connections.

However, if I comment out the declaration of conn and conn2 then the connection from outside to the inside is fine:

[thari]

osate2/core/org.osate.aadl2.instantiation/src/org/osate/aadl2/instantiation/CreateConnectionsSwitch.java

Line 585 in cf05234

boolean opposite = false;

Wondering if this initialization is correct. I am not sure in which situation where one segment of the connection instance is towards the destination and other is towards the source. I believe the recursive call should follow the same direction therefore the goOpposite argument must be equal to opposite parameter.