Objective
Systems complexity comes from dependencies between objects or activities, some structural, some functional, some discretionary, some mandatory. Since those connections are rooted in business concerns, they must be analyzed upfront at requirements level.
Structural vs Functional Connectors
Links between objects or activities are described by connectors and, as far as architectures are concerned, the priority is to distinguish between local connectors and those linking individual components identified at system level.
That’s true for actual objects and processes as well as for symbolic representations which, in any case, are themselves supported by actual system components and resources. Hence, links must be characterized depending upon how they are to be used (semantic context) and accessed (object identity):
- Structural links, aka structures, are used when parts are bound by use to the whole, ie they are not meaningful by themselves and therefore can only be accessed through the whole. As a consequence they can be managed locally.
- Non structural links, aka functional connectors, are used when targets can be used with different contexts, i.e they have meanings of their own and therefore can be accessed from different contexts. Therefore they must be managed at system level.
As a corollary, it must be noted that structural links cannot be used across different domains (when applied to objects) or locations (when applied to activities) lest the part be subject to an understanding different from the one governing its whole (objects), or the time spent to communicate not being accounted for (activities).
It must be reminded that, while that distinction is to be critical for architecture design, it can be established on purely organizational criteria, namely:
- Who’s is responsible for defining business objects and setting business rules.
- How is the execution of business processes to be controlled, centrally or through collaboration.
Collections, which provide standard access mechanisms, are to be introduced in order to reference sets of objects across domains or activities across locations.
If architectural concerns are to be dealt with, it’s necessary to get an unified understanding of connectors whatever the nature of connections. Along that reasoning four different types of connections have to be described:
- Links between symbolic objects.
- Data or control flows between symbolic activities.
- Connection between physical objects.
- Communication between actual processes.
Aggregates vs Composites
Whereas UML’s notation for aggregates and composites (respectively white and black diamonds) is widely used, there remains some debate regarding their semantics, especially for shared aggregates. Beyond the proper relevancy of definitions and references, it may be useful to remind two principles:
- Composition is to be used only for strong (or final) whole/part structures, i.e for parts without identities of their own.
- Aggregates are to be used for weak (or temporary) whole/part structures, i.e for exclusive ownership of elements with identities of their own.
In that context shared aggregates may be used for non exclusive ownership of elements with identities of their own; yet, a distinct notation must be introduced if confusion is to be avoided with standard (non shared) aggregates.
Finally, if built-in consistency checks are to be supported, aggregate and composite constructs must be applied uniformly to all four kinds of connectors: references, flows, channels, and transitions.
About Mixed Paradigms
As it happens, most of the arguments regarding the semantics of composite and aggregates can be regrouped in two categories:
- Definitions using identities, life-cycle, or encapsulation are rooted in the Object Oriented paradigm.
- Definitions using cardinality, exclusivity, or mutability are clearly inspired by the Entity/Relationship approach.
Given that mixing paradigms is usually counterproductive, the former option is clearly more consistent with UML founding principles.