UML2 – Applied Features and Extensions
1. STATIC STRUCTURE OF COMPONENTS AND ASSEMBLIES
from port multiplicities. Though, we restrict our connectors to singleton types whose mul- tiplicity1is not explicitly shown in the diagrams. Moreover, we do not consider group
communication and hence allow only for binary connectors.
As an example consider the compressing proxy component introduced in Chap. 2 whose static structure specification is for convenience repeated here in Fig. 7.2. The com- posite component type CompressingProxyconsists of an assembly of three simple com-
ponents with typesAdaptor,GZip, andGifToJpgintroduced by the respective component
declarations adapt:Adaptor,gzip:GZip, andgifToJpg:GifToJpg. The simple components as
well as the composite component show port declarations such ast:TxtComprorl:UpStream.
adapt : Adaptor [1] u : UpStream [1] d : DownStream [1] t : TxtCompr [1] g : GifCompr [1] gif : GifToJpg [1] j : ToJpg [1] gzip : GZip [1] z : Zip [1] «component» CompressingProxy l : UpStream [1] r : DownStream [1] «async» tz:TZ «sync» gj:GJ
FIGURE7.2. Using UML2 for the specification of composite components In the given example we use only singleton types for both, components and ports. The components are connected with assembly connectors named tzandgj. The anonymous
delegate connectors link the open port declarationsu:UpStreamandd:DownStreamof the
assembly with the port declarationsl:UpStreamandr:DownStreamof the composite com-
ponent typeCompressingProxy.
We introduce three stereotypes for specific kinds of connectors. Stereotypes «sync»
and «async» specify the communication timing and the stereotype «seq-adapter» an adap-
tion pattern for connections between ports with different multiplicities. Figure. 7.3 shows an example for the specification of an asynchronous and an adapter connector. The commu- nication timing relates to the message exchange between components. With a synchronous connector a rendezvous (handshake) mechanism is used and with an asynchronous connec- tor FIFO buffers are used, one for each communication direction. The precise meaning of «sync» and «async» is formally given by the definition of buffering connector behaviours
in Chap. 2, Def. 2.21. and their integration with component behaviours in Def. 2.22. The stereotype «seq-adapter» is used to bridge communication links between ports
that are specified with different multiplicities. Consider, for instance the specification of the CoCoME componentCashDeskLinein Fig. 8.2a below. There might be several instances
of typeCashDeskaccording to the multiplicity1..*of the component’s declaration. With
a sequential adapter connector we think of an additional component that provides as many ports as there are instances ofCashDeskand exactly one port to face the communication
with the bank. Figure. 7.3 illustrates the corresponding expansion of the static structure for the connector between the bank port of possibly severalcashDesksand the bank port of
the composite componentCashDeskLine. The behaviour of a «seq-adapter» connector is
supposed to realise the communication betweenncashdesks and one bank bysequential (synchronised) arrangement of multiple requests of different cash desk components.
116 7. UML2 – APPLIED FEATURES AND EXTENSIONS static structure expanded
CashDeskLine[ ] coordinator : Coordinator [1] cds : C-CD [*] cashDesks : CashDesk [1..*] b : CDA-Bank [1] co : CDA-C [1] i : CDA-I [0..1] : CDS−B−Adapter [1] cds : CD [*] bank : B [1] «component» CashDeskLine i : CDA-I [0..1] «seq−adapter» «async» co−cds
FIGURE7.3. Sequential adapter in componentCashDeskLine
Finally, we allow for the static modelling of attributes and operations for components and ports. The former provides a convenient way to specify data-dependent component be- haviour and the latter is used to declare internal methods that help to illustrate the intended meaning of internal actions. Since we do not consider data states on the formal behavioural level of our component model, the data-related specifications need to be abstracted or in- stantiated for the translation to I/O-transition systems. For this reason we did not include these concepts in our metamodel in Chap. 2 (Fig. 2.1). The precise relation to the UML is analogous to the relation between the Java/A component model and UML as defined in [KJH+08a, Fig. 1]. Note that component, port and connector declarations are represented by metaclasses with the suffixPropertyinstead ofDeclarationin [KJH+08a].
Multiplicities of Ports and Components. The formal part of our component model is not set up to cope with issues of dynamic reconfiguration. Static structure specifications with multiplicities 6= 1are considered to be architectural templates for a number of dif- ferent instantiation possibilities. Before an analysis along our formal model of port-based components is feasible, we need to resolve multiplicity specifications6= 1, and select an appropriate instance with multiplicities1only. Of course this is a limitation of our current formal model, but it also highlights potential ways to cope with multiplicity specifications. Instead of an extension of the formal model, multiplicities may also be resolved on the syntactical level, leaving the formal model untouched and thus easier to comprehend.
Under the assumption of fixed upper bounds for port and component multiplicities (instead of unbounded upper limits specified using the UML value*) a static structure with
a maximal number of instances is constructed by adding port declarations to components and component declarations to composite components. The resulting specification shows multiplicity1only. The names of additional port and component declaration use, for in-
stance, the original name extended by a suffix derived from a counter variable according to the given upper bound. After all declarations have been added, binary assembly connec- tors are used to link all of the created port declarations. The communication timing «sync»
or «async» is inherited from the original connector specification. The approach integrates
with sequential adapter connectors, specified by a connector with stereotype «seq-adapter»
(Sect. 1), and orthogonal component behaviours, specified by state machines with stereo- type «orthogonal» (Sect. 4), by taking into account the new port declaration names within