The Fortress Language Specification - CiteSeerX

Upgrade A predicate upg? takes two components and indicates whether the first can be upgraded with the second;
that is, upg?(c t ,c r ) returns true if and only if c t can be upgraded with c r . This predicate captures both the constraints
imposed by a component’s isValidUpgrade function and the conditions that guarantee the well-formedness of the
result. That is,
upg?(c t ,c r ) =⇒ c t .isValidUpgrade(c r )
∧ imp(c r ) ⊆ exp(c t ) ∪ imp(c t )
∧ exp(c r ) ⊂ exp(c t )
∧ ∀c ∈ cns(c t ).(exp(c) ⊆ exp(c r ) ∨ exp(c) ∩ exp(c r ) = ∅ ∨ upg?(c,c r ))
Visible and Provided We introduce two new functions on components: vis, which returns the APIs of a component
that have not been hidden; and prov, which returns those visible APIs that are exported by some top-level constituent
of the component (or all the exported APIs of a simple component); we say these APIs are provided by the component.
We need to distinguish provided APIs because they can be imported by the top-level constituents of a component, and
thus by a replacement component in an upgrade, while other visible APIs cannot be. Thus, for a compound component
c, prov(c) = vis(c) ∩ ⋃ c ′ ∈cns(c) exp(c′ ). For a simple component c, prov(c) = vis(c) = exp(c).
Constrain If c is a compound component and A ⊂ exp(c) is a set of APIs such that a ∈ exp(c) ∧ a ′ ∈ uses(a) ∩
A =⇒ a ∈ A, we define c ′ = constrain(c,A) such that exp(c ′ ) = exp(c) − A and for any component c ′′ ,
upg?(c ′ ,c ′′ ) ⇐⇒ upg?(c,c ′′ ) ∧ exp(c ′ ) ⊈ exp(c ′′ ). The imp, vis, prov and cns functions all have the same values
for c and c ′ . The extra condition on the upgrade compatibility simply captures the restriction we mentioned above,
that a replacement component should not export every API exported by the target.
Hide If c is a compound component and A ⊂ vis(c) is a set of APIs such that exp(c) ⊈ A and a ∈ vis(c) ∧ a ′ ∈
uses(a) ∩ A =⇒ a ∈ A, we define c ′ = hide(c,A) such that vis(c ′ ) = vis(c) − A, prov(c ′ ) = prov(c) − A,
exp(c ′ ) = exp(c) − A, and for any component c ′′ , upg?(c ′ ,c ′′ ) ⇐⇒ upg?(c,c ′′ ) ∧ exp(c ′ ) ⊈ exp(c ′′ ) ∧ vis(c ′′ ) ⊆
vis(c ′ ). The additional clause in upg?(c ′ ,c ′′ ) (compared with that of constrain) reflects the hiding of the APIs: we
can no longer upgrade APIs that are hidden.
Upgrade The interplay between imported, exported, visible and provided APIs introduces subtleties. In particular,
the last of the three conditions imposed for well-formedness of upgrades is modified to state that for any constituent
that is not subsumed by a replacement component, either it can be upgraded with the replacement, or its visible
APIs are disjoint from the APIs exported by the replacement (i.e., it is unaffected by the upgrade). To maintain the
invariant that no two constituents export the same API, we need another condition, which was implied by the previous
condition when no APIs were constrained or hidden: if the replacement subsumes any constituents of the target, then
its exported APIs must exactly match the exported APIs of some subset of the constituents of the target. That is, if
upg?(c t ,c r ) ∧ ∃c ∈ cns(c t ). exp(c) ⊆ exp(c r ) then exp(c r ) = ⋃ c∈C exp(c) for some C ⊂ cns(c t). In practice,
this restriction is rarely a problem; in most cases, a user wishes to upgrade a target with a new version of a single
constituent component, where the APIs exported by the old and new versions are either an exact match, or there are
new APIs introduced by the new component that have no implementation in the target.
341