Feature groups and data ports
Carlos Ramos
Sam Procter
Carlos,
It’s a little challenging to give advice here because the situation you describe is rather abstract. That said, there are a couple precepts that I think are relevant:
1. Model for a specific analysis – Always try and keep in mind the purpose of the model you’re building. Does having pin-level detail help support that purpose? If not, it may not be helpful to add it and – as you’ve discovered – it can add unnecessary complexity. If you’re targeting an automated analysis, great: you probably have a subset of AADL that informs that analysis and you know what to use. If you’re just building a model to analyze it / reason about it manually, though, it’s still helpful to think in terms of what helps the analysis (ie, aids your understanding) and what is unnecessary.
2. Absolute fidelity to the “real system” may not be necessary – You mention that feature groups are an “abstract construct that one cannot really see in the real system.” But, as an organizational technique, they may still be very useful. Many constructs in higher-level behavioral languages don’t have absolute representations in the machine code that ends up getting executed, but they are invaluable for the humans who have to understand the code.
Finally, it may be that you’re trying to have one model that does too much. Consider building a simpler model and then extending it with additional details so that the high-level / abstract model can be understood quickly, and then the lower-level model can support more in-depth analysis.
Yours truly,
Sam
From:
os...@googlegroups.com <os...@googlegroups.com> on behalf of Carlos Ramos <cram...@gmail.com>
Date: Wednesday, June 19, 2024 at 4:33 PM
To: OSATE <os...@googlegroups.com>
Subject: [OSATE] Feature groups and data ports
|
Warning: External Sender - do not click links or open attachments unless you recognize the sender and know the content is safe. |
In some modeling approaches, even if they are not AADL, I have seen models where there is a single connection between two blocks. The ports are named according to the part that is connected on the other side. Other models will show multiple connections with ports shown detecting specific interfaces.
I have been thinking about the possibility of using things like feature groups for example or in the case of SysML using a single connection like the approach above but was wondering if doing so sacrifices fidelity in the model. recently I tried modeling things down to a pin level for example and I ended spending way too much time moving things around and moving connectors etc. Ports also require their own notes and annotations as well. On the other hand, creating some feature group to hold multiple data ports seems like creating an abstract construct that one cannot really see in the real system.
Any advice out there on how to simplify models yet make them useful and readable?
--
You received this message because you are subscribed to the Google Groups "OSATE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
osate+un...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/osate/4a2ebdf0-ed11-495c-9075-b873fadc82c0n%40googlegroups.com.
jjhudak
Hi Carlos:
“possibility of using things like feature groups for example or in the case of SysML using a single connection like the approach above but was wondering if doing so sacrifices fidelity in the model.”
I don’t see how using feature groups in AADL would sacrifice fidelity. There are some concepts that underlie your questions that need to be sorted out to help in determine the modeling approach and the intended desired detail. There are a lot of things to consider and the problem context needs to be more detailed that what your questions allude to.
The first consideration is to understand the precise semantic meaning of ‘connection’ and ‘feature group’. Different architecture description language (ADL’s) such as Wright, Rapide,Darwin, AADL, etc., have different semantic interpretations of a connection. In AADL, a connection depicts an interaction between two components. Ports define the externally visible features and specify the directional exchange of data and events. Feature groups allow for aggregate data communication via a connection.
The second consideration is the intent of the model and the degree of abstraction necessary. In AADL a feature group is a named construct to contain ports. An abstract model (initial model) could show a feature group between two systems. The intention is it acts as a placeholder for ports specifications to be added later. The amount of detail (the number of ports) to be added depends on the intended analysis and the end goal of the model. Generally speaking, one can add a specific port and connection that represents a set of ports with the same features. This concept can support latency analysis.
Another consideration is modeling logical or physical architectures. The intent of a logical model is to show interactions between/among components. The grouping of ports in a FG can be done in different ways. Features may be aggregated according to directionality, state/event or logically related. The type of grouping can make some model representations a bit more work. For example, for defining flow paths through a system may entail describing a few representative flow paths versus a larger number of flow paths.
In representing a physical architecture, it is often desirable to show the ports and connections exactly as they would appear in a physical system, e.g. a ribbon cable between two systems. The intention with this approach is to show relevance to an assembly as opposed to a logical relation among components.
It is hard to give specific answer to your question. Hopefully this provides some guidance when attempting to make comparisons and eventually develop a model.