Error message on connection when starting a flow source implementation with a data subcomponent

[AaronGreenhouse]

Summary

AADL allows a flow source implementation to begin with a data subcomponent. However, the current OSATE implementation gives an error on the subsequent connection in the flow implementation when you try to do this.

Expected and Current Behavior

The expected behavior is that there should not be an error reported on the declarative model. In actuality there is an error of the form

The source of connection connection_id does not match the preceding subcomponent subcomponent_id

Interestingly, there is no analogous error when ending a flow sink implementation at a data subcomponent.

Steps to Reproduce

Consider the example

package DataTest
public
	data D
		
	end D;
	
	thread T
		features
			output: out data port D;
		flows
			fsrc: flow source output;
	end T;
	
	thread implementation T.i
		subcomponents
			myData: data D;
		connections
			c: port myData -> output;
		flows
			fsrc: flow source myData -> c -> output;
	end T.i;
	
	thread TT
		features
			input: in data port D;
		flows 
			fsnk: flow sink input;
	end TT;
	
	thread implementation TT.i
		subcomponents
			myData: data D;
		connections
			c: port input -> myData;
		flows
			fsnk: flow sink input -> c -> myData;
	end TT.i;
end DataTest;

OSATE will show an error marker on the connection identifier c in the flow source implementation fsrc of T.i. The error is

The source of connection 'c' does not match the preceding subcomponent 'myData'

Interestingly there is no similar error in the flow sink implementation fsnk of TT.i.

The error comes from Aadl2JavaValidator.checkFlowConnectionEnds(). In this case, the source of the connection is the data subcomponent but the connection source context is null. It seems like the method is not considering this case, but instead expects the connection source to be a feature of a subprogram?

[AaronGreenhouse]

I get source and destination errors in an end to flow destination in the following example:

package EndToEndFlowData
public
	data D
		-- empty		
	end D;
	
	data E
		-- empty
	end E;
	
	thread T
		features
			input: in data port D;
			output: out data port E;
		flows
			fpath: flow path input -> output;
	end T;
	
	process P
		-- empty
	end P;
	
	process implementation P.top
		subcomponents
			dataD: data D;
			dataE: data E;
			threadT: thread T;
		connections
			c1: port dataD -> threadT.input;
			c2: port threadT.output -> dataE;
		flows
			e2e: end to end flow dataD -> c1 -> threadT.fpath -> c2 -> dataE;
	end P.top;
end EndToEndFlowData;

Here I get errors on c1 and c2 in the end to end flow e2e:

The destination of connection 'c2' does not match the succeeding subcomponent or in flow spec feature 'dataE'

The source of connection 'c1' does not match the preceding subcomponent or out flow spec feature 'dataD'

[AaronGreenhouse]

After some time in the debugger, I have found that the flow sink case in DataTest::TT.i (the first example above) does indeed report an error. Or at least it tries to. But because it tries to dereference the cxt of the connection, which is null, it causes an exception instead. Not sure where this exception gets logged or swallowed. But if I remove the use of cxt in the error message, it gets reported on the model.

Of course the problem here is that we shouldn't be reporting an error in this case and we should be checking that cxt is null as part of the filter.

I feel better knowing it's trying to report an error because it didn't make sense that the flow source and flow sink cases would be handled differently.

[AaronGreenhouse]

The case is missing appropriate error checking too, I think. I think I need to add checks in this case that the named data component in the connection is the same as the one in the flow.

[AaronGreenhouse]

The code for checking connections vs. subcomponents in flows is in method checkFlowConnectionEnds() in Aadl2JavaValidator around line 1511 (for the case of subcomponent -> connection):

						if (prevFlowElement != cxt && !(cxt instanceof SubprogramCall
								&& ((SubprogramCall) cxt).getCalledSubprogram() == prevFlowElement)) {
							error(flow.getOwnedFlowSegments().get(i),
									"The source of connection '" + connection.getName()
											+ "' does not match the preceding subcomponent '"
											+ ((Subcomponent) prevFlowElement).getName() + '\'');
						}

(The source code for checking connection -> subcomponent) is similar around line 1567.)

But this doesn't work. The first part checks if prevFlowElement and cxt are equal. I think this is supposed to be handling the case of data subcomponents. But this doesn't work because cxt is null in the case.

The other part is trying to deal the case of the connection being a parameter connection, but it has other problems. If I try to make an example that creates a flow from a subprogram, it doesn't work (which I think we already have an issue for):

	data D
	end D;
	
	subprogram SP
		features
			p1: in out parameter D; 
	end SP;
	
	thread T
		features
			output: out data port D;
		flows
			fsrc: flow source output;
	end T;
	
	thread implementation T.i
		subcomponents
			myData: data D;
		calls
			q: {
				call1: subprogram SP;
			};
		connections
			c: parameter call1.p1 -> output;
		flows
			fsrc: flow source call1 -> c -> output;
	end T.i;

Looking at flow source fsrc in T.i, I get an error on call1

Couldn't resolve reference to FlowElement 'call1'.

If I change it to sp (which seems to be what the above code is trying to require), that also doesn't resolve.

[AaronGreenhouse]

Fixed checkFlowConnectionEnds(FlowImplementation).

Still need to fix checkFlowConnectionEnds(EndToEndFlow)

[AaronGreenhouse]

Fixed checkFlowConnectionEnds(EndToEndFlow) by updating getConnectionSubcomponent() to not check if the connection is an Access connection, and just check if the connection context is null.

Still need unit tests

[AaronGreenhouse]

Added Unit tests