-
Notifications
You must be signed in to change notification settings - Fork 8
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
Difficult to Determine Direction of Access Feature Instances #758
Comments
Hi Philip, I discussed this issue with @lwrage this morning, and we were wondering if you could provide a little more context as to your planned usage of the direction of the access feature instance. That is, is your primary interest determining the shape of a symbol in a graphical view of the instance model? Or in some new analysis? or something else entirely? I don't think provides / requires can be cleanly mapped to in / out, because -- as I understand it -- a component that provides access could be providing access to read and / or write data. Similarly, a component requiring access could be requiring read or write access. |
The primary interest is for determining the shape of a symbol in the graphical view of the instance model. However, this issue could effect analysis. Currently there isn't an easy way to determine if a feature instance is a provides or a requires. I have to agree that depending on how you think about the in/out concept vs provides/requires that perhaps it isn't an appropriate mapping. I typically think of a requires as an input because access to the data/bus is being given(input) to the component. However, my main desire is a way of easily determining whether a feature instance is a provides/requires in the same way that we can determine if port feature instances are inputs or outputs. |
Change as follows:
Code currently calls |
The direction of all feature instances for Access features is In Out in the instance model. I believe it should be set to In or Out based on whether it is a provides or requires feature or another field should be provided. It is difficult to reliably determine the kind of the feature instance using the underlying feature because there are cases such as inverse feature groups which would cause the direction to be opposite of the underlying feature.
The text was updated successfully, but these errors were encountered: