Instantiator merges access connections

[joeseibel]

Consider the following model:

package pkg
public
    abstract aType
        features
            da: requires data access;
    end aType;

    system s
    end s;

    system implementation s.i
        subcomponents
            d: data;
            a: abstract aType;
            b1: bus;
            b2: bus;
        connections
            conn1: data access d -> a.da;
            conn2: data access a.da -> d;
        properties
            Actual_Connection_Binding => (reference (b1)) applies to conn1;
            Actual_Connection_Binding => (reference (b2)) applies to conn2;
    end s.i;
end pkg;

When instantiated, there is only one ConnectionInstance created. It is a bidirectional connection which is the merger of conn1 and conn2. Is this the correct thing for the instantiator to do? If so, what should the value of Actual_Connection_Binding be in the instance model?

[lwrage]

Check if not merging fixes issues with flows through access connections.

[AaronGreenhouse]

Merging happens in CreateConnectionSwitch.addConnectionInstance()

[AaronGreenhouse]

So this is interesting: If I have an explicit declarative bidirectional access connection, it creates a single unidirectional connection instance.

[AaronGreenhouse]

I shut off the merging of access connections into a single bidirectional connection. This seems to fix Issue #643.

But, as said bidirectional declarative access connections are not always instantiated correctly. Consider

package test_access_connections
public
    abstract aType
        features
            da: requires data access;
    end aType;

    system s
    end s;

    system implementation s.i
        subcomponents
            d1: data;
            a1: abstract aType;
            
            d2: data;
            a2: abstract aType;
            
            d3: data;
            a3: abstract aType;
            
            d4: data;
            a4: abstract aType;
            
            d5: data;
            a5: abstract aType;
    	connections
    		-- We connect both ways -- Should not be merged anymore
            conn1a: data access d1 -> a1.da;
            conn1b: data access a1.da -> d1;

			-- Bidirectional, should have 2 connection instances
			conn2: data access d2 <-> a2.da;
			
			-- Bidirectional, should have 2 connection instances
			conn3: data access a3.da <-> d3;
			
			conn4: data access d4 -> a4.da;
			
			conn5: data access a5.da -> d5;            
    end s.i;
end test_access_connections;

There should be two connection instances generated from conn2, and two generated from conn3. For conn2 we only get a connection instance for "d2 -> a2.da". Strangely, conn3 gives both connection instances.

The equivalent example using ports instead of data access creates the expected connections in all cases:

package test_regular_connections
public
    abstract aType
        features
            f1: in out event port;
    end aType;
        
	system s		
	end s;

    system implementation s.i
    	subcomponents
    		s1a: abstract aType;
    		s1b: abstract aType;
    		
    		s2a: abstract aType;
    		s2b: abstract aType;
    		
    		s3a: abstract aType;
    		s3b: abstract aType;
    		
    		s4a: abstract aType;
    		s4b: abstract aType;
    		
    		s5a: abstract aType;
    		s5b: abstract aType;
    	connections
    		-- connect both ways. should not be merged, should have 2 connection instances
    		conn1a: feature s1a.f1 -> s1b.f1;
    		conn1b: feature s1b.f1 -> s1a.f1;
    		
    		-- bidirectional, should have two connection instances
    		conn2: feature s2a.f1 <-> s2b.f1;
    		
    		-- bidirectional, should have two connection instances
    		conn3: feature s3b.f1 <-> s3a.f1;
    		
    		conn4: feature s4a.f1 -> s4b.f1;
    		
    		conn5: feature s5b.f1 -> s5a.f1;
    end s.i;
end test_regular_connections;

[AaronGreenhouse]

Above problem is submitted as Issue #1977