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

Rename refactoring of port misses references in flow implementations #2434

Closed
lwrage opened this issue Sep 14, 2020 · 1 comment · Fixed by #2493
Closed

Rename refactoring of port misses references in flow implementations #2434

lwrage opened this issue Sep 14, 2020 · 1 comment · Fixed by #2493
Assignees
Milestone

Comments

@lwrage
Copy link
Contributor

lwrage commented Sep 14, 2020

Summary

Flow implementations name starting and/or ending feature. When renaming such a feature no renaming happens in flow implementations.

Expected and Current Behavior

Occurrences of features in flow implementations should be renamed during rename refactoring.

Note: Mark occurrence works for this case.

Steps to Reproduce

  1. Select port p in S
  2. Hit Alt+Shilt+R to start rename refactoring
  3. No box appears around the reference to p in fsnk in S.i
  4. Change the port name
  5. Occurrence of p in fsnk is not renamed
package Issue2434
public

	system S
		features
			p: in data port;
		flows
			fsnk: flow sink p; 
	end S;
	
	system implementation S.i
		subcomponents
			sub: system subsystem;
		connections
			c1: port p -> sub.q;
		flows
			fsnk: flow sink p -> c1 -> sub;
	end S.i;

	system subsystem
		features
			q: in data port;
	end subsystem;

end Issue2434;

Environment

  • OSATE Version: 2.8.0
  • Operating System: Ubuntu 20.04
@lwrage lwrage changed the title Rename reafctorng of part misses references in flow implementations Rename refactoring of port misses references in flow implementations Sep 14, 2020
@lwrage lwrage added this to the 2.9.1 milestone Oct 2, 2020
@lwrage lwrage self-assigned this Oct 3, 2020
@lwrage
Copy link
Contributor Author

lwrage commented Oct 31, 2020

This is a problem in Aadl2ScopeProvider.scope_FlowEnd_feature(FLowEnd...), where it is assumed the the flow end is contained in a FlowSpecification. In this case it is contained in a Flow_Implementation_. The ClassCastException is not propagated to the top level.

Also, scope_FlowEnd_feature(FlowEnd...) doesn't need to call the other scope_FlowEnd_feature method directly, this happens in the polymorphic dispatcher. The other method should just take a Flow parameter, which is a common superclass of FlowSpecification and FlowImplementation.

scope_FlowEnd_context(...) fails to handle flow implementations, too. Context parameter must have type ComponentClassifier.

Tests are in ConnectedElementsAndFlowEndsTest.xtend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant