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

Wrong feature group type validation #1671

Closed
AaronGreenhouse opened this issue Jan 9, 2019 · 2 comments

Comments

Projects
None yet
3 participants
@AaronGreenhouse
Copy link
Contributor

commented Jan 9, 2019

Suppose I have the feature groups FG1, IG1, and FG2:

	feature group FG1
		features
			f1: out event port;
	end FG1;
	
	feature group IG1
		features
			g1: in event port;
		inverse of FG1
	end IG1;
	
	feature group FG2 extends FG1
		features
			f1: refined to out event port;
			f2: out event port;
	end FG2;

Now I want to declare an inverse feature group of FG2

	feature group IG2 extends IG1
		features
			g2: in event port;
		inverse of FG2
	end IG2;

OSATE marks IG2 with an error "Feature group features list count differs from that of its inverse". In order to make OSATE happy, IG2 needs to have 2 features, such as:

	feature group IG2 extends IG1
		features
			h: in event port;
			g2: in event port;
		inverse of FG2
	end IG2;

But this is complete nonsense because because now IG2 really has three features. The problem is caused by the refined feature in FG2. It's being counted as a new feature by the verifier.

@lwrage lwrage changed the title OSATE forces illegal feature group type to be declared Wrong feature group type validation Feb 21, 2019

@lwrage lwrage added next and removed backlog labels Mar 21, 2019

@lwrage lwrage added this to the 2.5.0 milestone Mar 27, 2019

@joeseibel

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2019

This isn't simply an issue of counting refined features. The validator currently looks at the owned features and the inverse's owned features. It assumes that diamond inheritance is happening, but fails when there is no diamond.

In the following case, IG2 doesn't extend anything. The validator should accept this model, but doesn't.

package inverse_only
public
  feature group FG1
    features
      f1: out event port;
  end FG1;

  feature group FG2 extends FG1
    features
      f2: out event port;
  end FG2;

  feature group IG2
    features
      g1: in event port;
      g2: in event port;
    inverse of FG2
  end IG2;
end inverse_only;

In another example, IG2 extends a feature group which is not an inverse of FG1. The validator should also accept this model.

package not_diamond
public
  feature group FG1
    features
      f0: out event port;
      f1: out event port;
  end FG1;

  feature group FG2 extends FG1
    features
      f2: out event port;
  end FG2;

  feature group FG3
    features
      f3: out event port;
  end FG3;

  feature group IG3
    features
      g3: in event port;
    inverse of FG3
  end IG3;

  feature group IG2 extends IG3
    features
      g1: in event port;
      g2: in event port;
    inverse of FG2
  end IG2;
end not_diamond;
@joeseibel

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2019

Here are graphs showing each example's feature group type relationships. Solid lines represent extends and dashed lines represent inverse of.

Aaron's example in original post:
first_example

inverse_only:
inverse_only

not_diamond:
not_diamond

@ghost ghost added in progress and removed next labels Apr 11, 2019

@ghost ghost added review and removed in progress labels Apr 12, 2019

@lwrage lwrage closed this in #1776 Apr 18, 2019

@ghost ghost removed the review label Apr 18, 2019

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