End to end flow instantiation broken for flows through threads

[lwrage]

Summary

Flow implementations in threads can go through subprogram calls in this case end to end flow instantiation fails because connection instances end at the thread.

Expected and Current Behavior

Flow implementations in threads should take only the end points into account everything else should be ignored.

Environment

• OSATE Version: 2.5.1
• Operating System: all

[AaronGreenhouse]

Example from Lutz:

package test
public
    
    process top
    end top;
    
    process implementation top.i
        subcomponents
            t0: thread th.i;
            t1: thread th.i;
            t2: thread th.i;
        connections
            c1: port t0.op -> t1.pip;
            c2: port t1.pop -> t2.ip;
        flows
            e2e: end to end flow t0.src -> c1 -> t1.pth -> c2 -> t2.snk;
    end top.i;
    
    thread th
        features
            ip: in data port;
            op: out data port;
            pip: in data port;
            pop: out data port;
        flows
            src: flow source op;
            pth: flow path pip -> pop;
            snk: flow sink ip;
    end th;
    
    thread implementation th.i
        subcomponents
            s1: subprogram s1;
        calls
            cs1: {
                call1: subprogram s1;
            };
        connections
            ct1: parameter pip -> call1.p1;
            ct2: parameter call1.p2 -> pop;
--        flows
--            pth: flow path pip -> ct1 -> s1.s1flow -> ct2 -> pop;    
    end th.i;
    
    subprogram s1
        features
            p1: in parameter;
            p2: out parameter;
        flows
            s1Flow: flow path p1 -> p2;
    end s1;
end test;

He says

if you remove the comments on the flow impl in th.i, the flow is no longer instantiated. Note that a flow impl in a thread that goes directly from an in port to an out port should not be ignored.

[AaronGreenhouse]

Currently, the end to end flow instance is created correctly if th.i has the trivial flow implementation

            pth: flow path pip -> pop;  

[AaronGreenhouse]

I'm confused what is the desired outcome here? Should the generated end to end flow

1. contain entries for the subprogram, etc., or
2. be identical to the trivial case, merely passing through the thread component?

[lwrage]

It's option 2. Trivial flow implementations through threads should be interpreted if present. (This is needed because the flow spec could be between two feature groups whereas the corresponding flow implementation could select a specific feature in that feature group.) All other flow implementations in threads should be ignored.

[AaronGreenhouse]

Okay, based on conversation with Lutz, what is desired is that if the flow implementation is simple, it should be used. This is account for connections between port groups. But any flow implementation that goes though a subcomponent (really, a subprogram call) of the thread should be outright ignored.

[AaronGreenhouse]

Okay, cooked up two test packages

package SimpleConnections
public
    subprogram sub
        features
            p1: in parameter;
            p2: out parameter;
        flows
            subPath: flow path p1 -> p2;
    end sub;
    
    thread th
    	features
    		ip: in data port;
    		op: out data port;
    	flows
    		fpath: flow path ip -> op;
    end th;
    
    thread implementation th.simple
	   	flows
    		fpath: flow path ip -> op;
    end th.simple;
    
    thread implementation th.withCall
    	subcomponents
    		sub1: subprogram sub;
    	calls
    		normal:{
    			call1: subprogram sub1;
    		};
    	connections
    		c1: parameter ip -> call1.p1;
    		c2: parameter call1.p2 -> op;
   		flows
    		fpath: flow path ip -> c1 -> sub1.subPath -> c2 -> op;
    end th.withCall;
    
    thread th2
    	features
    		ip2: in data port;
    		op2: out data port;
    	flows
    		fsrc: flow source op2;
    		fsnk: flow sink ip2;
    end th2;
    
    thread implementation th2.i
    	-- trivial
    end th2.i;
    
    process top
    end top;
    
    process implementation top.generic
    	subcomponents
    		t: thread th;
    		q: thread th2.i;
    	connections
            c1: port q.op2 -> t.ip;
            c2: port t.op -> q.ip2;
        flows
            e2e: end to end flow q.fsrc -> c1 -> t.fpath -> c2 -> q.fsnk;
    end top.generic;
    
    process implementation top.simple extends top.generic
        subcomponents
            t: refined to thread th.simple;
    end top.simple;
    
    process implementation top.withCall extends top.generic
        subcomponents
            t: refined to thread th.withCall;
    end top.withCall;
end SimpleConnections;

and

package FGConnections
public
    feature group FG
    	features
	    	x_in1: in data port;
	    	x_in2: in data port;
	    	x_out1: out data port;
	    	x_out2: out data port;
    end FG;

	feature group FG_inverse inverse of FG
	end FG_inverse;

    subprogram sub
        features
            p1: in parameter;
            p2: out parameter;
        flows
            subPath: flow path p1 -> p2;
    end sub;
    
    thread th
    	features
    		fg1: feature group FG;
    		fg2: feature group FG_inverse;
    	flows
    		fpath: flow path fg1 -> fg2;
    end th;
    
    thread implementation th.simple
    end th.simple;
    
    thread implementation th.specific
    	flows
    		fpath: flow path fg1.x_in1 -> fg2.x_in2;
    end th.specific;
    
    thread implementation th.withCall
    	subcomponents
    		sub1: subprogram sub;
    	calls
    		normal: {
    			call1: subprogram sub1;
    		};
    	connections
    		c1: parameter fg1.x_in1 -> call1.p1;
    		c2: parameter call1.p2 -> fg2.x_in2;
   		flows
    		fpath: flow path fg1.x_in1 -> c1 -> sub1.subPath -> c2 -> fg2.x_in2;
    end th.withCall;
    
    thread th2
    	features
    		fg1: feature group FG_inverse;
    		fg2: feature group FG;
    	flows
    		fsrc: flow source fg1;
    		fsnk: flow sink fg2;
    end th2;
    
    thread implementation th2.i
    	-- trivial
    end th2.i;
    
    process top
    end top;
    
    process implementation top.generic
        subcomponents
            t: thread th;
            q: thread th2.i;
        connections
            c1: feature group q.fg1 <-> t.fg1;
            c2: feature group t.fg2 <-> q.fg2;
        flows
            e2e: end to end flow q.fsrc -> c1 -> t.fpath -> c2 -> q.fsnk;
    end top.generic;
    
    process implementation top.simple extends top.generic
        subcomponents
            t: refined to thread th.simple;
    end top.simple;

    process implementation top.specific extends top.generic
        subcomponents
            t: refined to thread th.specific;
    end top.specific;

    process implementation top.withCall extends top.generic
        subcomponents
            t: refined to thread th.withCall;
    end top.withCall;
end FGConnections;

• Instantiating SimpleConnections::top.simple should generate the end to end flow instance.
• Instantiating SimpleConnections::top.withCall should not generate the end to end flow instance.
• Instantiating FGConnections::top.simple should generate four end to end flow instances.
• Instantiating FGConnections::top.specific should generate one end to end flow instance.
• Instantiating FGConnections::top.withCall should not generate the end to end flow instance.

[AaronGreenhouse]

Not sure there is anything to do for this issue, other than verify that things are doing what we want. According to the above tests, everything already does what we want.

[AaronGreenhouse]

Added JUnit test.