Aggregation relation and class attribute

4

Does aggregation only occur when a A, class that aggregates a B class has an attribute of type B ?

Can aggregation exist without necessarily having one attribute having the type of the other?

For example, if I instantiate an object of another class in a method of my class, but this instantiated object is not an attribute of my class, is the relation still composition?     

asked by anonymous 16.12.2015 / 21:57

1 answer

3

TL; DR

It depends on the point of view, but in general aggregation in a class model occurs only when there is an attribute.

Class structure

In general, when we talk about class diagrams, we are referring to the structure of them. Therefore, aggregation would only occur if A has an attribute of type B .

We're not worried about implementation details while we're modeling or doing a high-level system design.

Static code analysis

On the other hand, if we do a static code analysis of a class ready to determine dependencies, we can find them:

  • Explicit or direct : in variable types and parameters, for example. Usually there will be import for each reference.
  • Implicit or indirect : when using an interface without knowing the implementation or when there is chaining of calls, such as objetoB.getObjetoC().getAtributo() , because in this case we depend on C without there being a direct connection with the class in A .

Running dynamic analysis

Going deeper, we can even do a run-time analysis to determine the actual dependencies that a class needs to run.

It is considered here that some of the implementations of interfaces can be provided:

  • At runtime, for example through plugins or libraries that are not present during compilation
  • By using reflection, instantiating or accessing classes by their name
  • According to user input or program configuration, where instance types may vary
  • By libraries that dynamically generate classes

Considerations

The structural modeling of the classes is good for thinking about the system domain, but it does not guarantee and should not try to guarantee the way the system executes or its dependencies at runtime.

Static code analysis helps determine the coupling and cohesion of a class, so you should always try to decrease the number of dependencies.

Finally, run-time analysis is the only one that gives full assurance of what is actually being executed, but is also the most costly and complex. Still, it is dependent on the moment, which means that the behavior of the system varies over time of use and sometimes it is very difficult to reproduce the desired scenario.

    
17.12.2015 / 01:54