Component systems and BIP

Why separating glue matters

Component-based systems fail when coordination logic leaks into component internals. When that happens, assumptions become implicit: the component only works under a particular schedule, ordering, or resource policy, but those assumptions are not visible at the boundary.

A disciplined separation keeps coordination explicit. Instead of hiding glue inside callback conventions and shared mutable state, you treat interaction as a first-class object. That makes it possible to reason about composition and to attach checks to the glue itself.

BIP as a perspective

BIP is often explained as three layers:

• BehaviourWhat each component can do locally (states and transitions).
• InteractionHow components synchronise or exchange actions (the glue).
• PriorityConstraints that resolve choices when multiple interactions are possible.

Even when you do not use a framework that enforces this structure, you can use it as a design checklist. If you cannot clearly state the interaction and priority rules, they are probably hidden in code paths that are hard to test.

Diagram: behaviour + glue + priority

How this connects to verification

The more explicit the glue is, the easier it is to check system-level properties. Many safety properties are fundamentally coordination properties: “two things are never active together”, “requests eventually receive responses”, “resources are not oversubscribed”.

In a workflow, you can often model the interaction and priority rules more compactly than the full component internals. That makes model checking or other analysis more feasible. This is one reason component models appear frequently in workshop discussions such as ICE.

Key definitions

• ComponentA unit with local behaviour and an interface for interaction.
• GlueCoordination logic that specifies how components interact (synchronisation, scheduling, restrictions).
• InteractionA defined coordination step involving multiple components.
• Priority ruleA policy that selects among enabled interactions.
• CompositionalityReasoning about the whole system from parts and their composition operator.

Common pitfalls

• Glue hidden in callbacksImplicit sequencing assumptions are hard to test and hard to discuss.
• Priority rules encoded as ad hoc “if” chainsThe policy drifts over time unless it is explicit.
• Assuming local correctness implies global correctnessComposition changes the environment; assumptions can break.
• Over-modellingIf the model is too detailed, analysis becomes infeasible; prefer focused models.

Internal links

• ICE 2011 workshop hubPresentation pages and programme structure.
• Research: component modelsThemes and methodology.
• BRiCoSBuilding-block perspective on composition.