Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Misleading warning on feature reference in parameter connection #1988

Closed
AaronGreenhouse opened this issue Sep 12, 2019 · 3 comments · Fixed by #2066
Closed

Misleading warning on feature reference in parameter connection #1988

AaronGreenhouse opened this issue Sep 12, 2019 · 3 comments · Fixed by #2066
Assignees
Milestone

Comments

@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Sep 12, 2019

Summary

When one of the end points of a parameter connection has a data classifier and the other end does not, OSATE (rightly) generates a warning. But the warning is poorly worded and unhelpful. Currently the warning is of the form

feature is missing a classifier

This confused me for a while when generating an example for something else because I kept reading the warning as "feature is missing in classifier," which didn't make any sense to me.

Expected and Current Behavior

I suggest making the warning more descriptive, something more like:

Expected feature to have data classifier classifier

Classifier classifier can be determined by the other connection endpoint.

Steps to Reproduce

Consider the example

package Example1
public
	data D
	end D;
	
    subprogram sub
        features
            p1: in parameter D;
            p2: out parameter;
    end sub;
 
    thread th2
    	features
    		ip2: in data port;
    		op2: out data port;
    end th2;

	thread implementation th2.bad
		subcomponents
			myData: data D;
    		sub1: subprogram sub;
    	calls
    		normal:{
    			call1: subprogram sub1;
    		};
		connections
			c1: parameter ip2 -> call1.p1;
			c2: parameter call1.p2 -> myData;
    end th2.bad;
end Example1;

Here we have warnings on ip2 in the declaration of c1 and call1.p2 in the declaration of c2.

The following example switches things around and we have the errors on the destination features of c1 and c2:

package Example2
public
	data D
	end D;
	
    subprogram sub
        features
            p1: in parameter;
            p2: out parameter D;
    end sub;
 
    thread th2
    	features
    		ip2: in data port D;
    		op2: out data port;
    end th2;

	thread implementation th2.bad
		subcomponents
			myData: data;
    		sub1: subprogram sub;
    	calls
    		normal:{
    			call1: subprogram sub1;
    		};
		connections
			c1: parameter ip2 -> call1.p1;
			c2: parameter call1.p2 -> myData;
    end th2.bad;
end Example2;
@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

@AaronGreenhouse AaronGreenhouse commented Nov 15, 2019

The same general code for this is used for port, parameter, and access connections. Should change the message for all three cases.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

@AaronGreenhouse AaronGreenhouse commented Nov 15, 2019

Need to update

  • Aadl2JavaValidator.checkPortConnectionClassifiers()
  • Aadl2JavaValidator.checkParameterConnectionClassifiers()
  • Aadl2JavaValidator.checkAccessConnectionClassifiers()
@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

@AaronGreenhouse AaronGreenhouse commented Nov 15, 2019

Oops, for access and parameter connections sometimes it's not a feature but a subcomponent. Need get the message correct for that case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.