Ports, Provided and Required Interfaces in a 400-Class Avionics Model
Skyline Systems is merging three legacy flight-management models into a single 400-class component model with about 1,200 ports, exchanged between two vendors' tools as XMI 2.5.1. The original authors declared every protocol with an «interfaceRealization» from the component class to the interface, typed the ports with plain classes, and drew the ball-and-socket symbols by hand on diagrams only. Validation now reports 214 "required interface not provided" warnings, and the code generator emits two adapter classes per connection because nothing in the model states which port offers which interface. One subcontractor component both calls and implements IFlightPlan; to show this the team created a second, hand-reversed copy of the interface, which broke existing operation bindings in the subscriber's tool. No profiles are allowed, the model must remain pure UML 2.5.1, and port compatibility has to be checkable automatically - the team cannot review 1,200 ports on diagrams.
1. Explain why a component-level «interfaceRealization» does not make an interface provided by a given port, and state which standard UML constructs actually determine a port's provided and required sets.
Read the worked answer
InterfaceRealization is a Realization whose client is a BehavioredClassifier and whose supplier is an Interface. Declaring it on the component class says the component as a whole fulfils the contract; it does not attach the interface to any Port, so a tool that computes compatibility from ports sees an empty provided set for all 1,200 of them.
In UML 2.5.1 the sets are derived from the port's type:
Port::provided(derived union) = the Interfaces realized by the type of the port.Port::required(derived union) = the Interfaces used by the type of the port, i.e. targets of «use» Dependencies (Usage) from that type.
Consequences for Skyline:
- Typing a port with a plain class C that realizes no interface puts nothing in
provided. Change the port's type to the interface itself, or to a class/interface that carries the InterfaceRealizations. - Required interfaces need an explicit «use» Dependency from the port's type to the Interface - a socket drawn on a diagram is notation, not model content.
- A component-level InterfaceRealization may stay if the component also exposes the contract at classifier level, but it must not be the only statement of what a port offers.
Once provided and required are derived from types, the ball-and-socket rendering and the generator's adapter count both follow from the model, and the 214 warnings resolve to the ports whose types genuinely realize nothing.
2. IFlightPlan is both called and implemented by one component. How should this be modelled so the semantics are correct and the XMI round-trips, given that the team's hand-reversed interface copy broke operation bindings?
Read the worked answer
Conjugation is a property of a Port (Port::isConjugated), not of an Interface, and it inverts the whole provided and required sets of that one port. Therefore:
- A reversed copy of IFlightPlan is a defect: it creates a second, unrelated type, operation bindings no longer match, and no tool can tell the copies are related.
- A single port with
isConjugated = trueflips everything on it, so it cannot be used when the same port must also offer an unrelated interface - that interface would be flipped too.
Recommended encodings for a component that both consumes and provides IFlightPlan:
Option A (preferred, unambiguous): two ports. Port planner typed by IFlightPlan, not conjugated - provided = {IFlightPlan}. Port client typed by IFlightPlan with isConjugated = true - required = {IFlightPlan}. Assembly connectors then wire socket to ball without special cases.
Option B: one port whose type both realizes IFlightPlan and has a «use» Dependency to IFlightPlan, so provided = required = {IFlightPlan}. Legal, and honest that the port is bidirectional, but it gives the generator no direction information and no way to say that other contracts on the same port are one-way.
Choose A when direction must be machine-checkable, B when the port is genuinely symmetric (a peer-to-peer link) and both directions share a single connector. Never conjugate the Interface itself; the metaclass has no such feature.
3. What model-level checks and tooling pattern would enforce port compatibility across 1,200 ports without reviewing diagrams, using only UML 2.5.1 and OCL?
Read the worked answer
Encode the rule as model content plus OCL, so XMI consumers can enforce it:
- Invariant on Port: every port has a type, and provided/required are non-empty unless the port is explicitly marked as a behaviour-only port.
- Invariant on Connector (assembly kind): for each end, the required interfaces of the requiring port must be a subset (allowing interface specialization) of the provided interfaces of the other end in one direction or the other; otherwise the connector is invalid.
- Invariant on InterfaceRealization: if the client is a component, at least one of its ports is typed by an element carrying the same realization, or the realization is explicitly marked as a classifier-level contract (a Constraint or comment owned by the classifier); otherwise it is dead model content, exactly the current failure.
- Invariant on «use» Dependency: the supplier must be an Interface and the client must be a port type; a «use» on the component itself will never populate a port.
Then a build step computes the derived unions per port and emits a report instead of a diagram review. The pattern generalizes: derive from types, constrain connectors, and fail the build when a port is wired to an interface it does not require or cannot be provided. Add a golden-file test that round-trips the model through both vendors' tools and diffs the computed provided/required sets - the sets, not the XMI text, are the stable contract.