How to model different software components?

[KuechA]

To implement #341, we will introduce a new type of Node to the CPG. This node should model a piece of software that belongs together, e.g., an application.

The basic functionality of this class is to hold all TranslationUnitDeclarations of the respective software artifact and specify potential entry points or outgoing calls. The TUDs are currently collected in the TranslationResult, so that I would suggest to move the respective functionality from the class TranslationResult to the new class and collect (potentially multiple) instances of the software components in TranslationResult.

Questions

• Q1 How should we call this new node? I'd suggest SoftwareComponent to be as general as possible, other options could be Program, Application, Module, or anything else you can think of.
• Q2 Which relations should this component have? My current idea is to have
  • A list of TranslationUnitDeclarations to hold all source code files of that piece of software
  • incomingInteractions: A list of nodes modelling entry points or other "starting points" (e.g. listening for events, ...)
  • outgoingInteractions: A list of nodes modelling a dependency of the software to another piece of software (e.g. sending an http request)
• Q3 Does the basic idea make sense of having this "intermediate layer" or are there any concerns? Should we keep the relation from the TR to the TUDs or eliminate them?

Is there anything else that could be useful in this context?

[oxisto]

Several things to consider:

• While I think its a good idea to have these components in the translation result, it would be good to introduce some (convenience) functions to directly return a list of translation results, if only one component is present. This will probably be the default for most cases and for almost all test cases, so we should try not to make it more complicated for the majority of uses
• SoftwareComponent or just Component is good for now, Application is probably not a good term or at least should inherit from Component. Maybe we can have the "interactions" as properties of these derived classes, e.g. a main property for an Application - or should just generalise it?