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:
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.
provides access feature instances will have direction out
requires access feature instances will have direction in
Code currently calls getDirection() to determine allowed data flow, which is always in out for access features => Create new method getFlowDirection() that returns in out for access features and calls getDirection() for all other features.
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: