POTENCIAL INDUSTRIAL

In this section, we realize an adaptation of CA, called component configuration au-

tomata(CCA), that accommodates components. To define CCA, first, we include the information of which classes are the activator classes. Second, we extend the configuration to include information which SIOA represents an actor and which SIOA represents a component instance. Every time there is a transition that cre- ates an actor of an activator class C, the new SIOA (that is, an instance of AA of

C) is marked as a component, unless the creator is part of a component instance. In the latter case, the new SIOA is composed together (using the parallel compo- sition operator) with the creator’s SIOA. Otherwise, this transition creates a new SIOA and puts it into the configuration as done in ACA. Transitions that do not involve actor creations are modeled the same to what is done in ACA with the exception of allowing simultaneous exposure of a group of actors. We show that this adaptation does not impact the observable behavior of the represented actor system in comparison to ACA.

To unite the use of AA and CompA, CCA are defined such that components [C] can be designated as activator classes. Creating such a component means instantiating a parameterized component automaton that represents [C]. The

9.3. Model of Component Configuration Automata component automata are SIOA, allowing the AA, composed AA and component automata to be treated in a uniform manner.

First we define a notion of configurations called component configuration that al- lows the use of an SIOA A to represent a group of actors. To distinguish SIOA that represent only single actors from SIOA that represent a group of actors, we encode this information in a boolean mapping. The notion of a compatible component configuration is a generalization of the notion of compatible actor configurations.

Definition 9.3 (Component configurations):

A component configuration C is a tuple 〈A, S, E, U, B〉 where • A is a set of SIOA identifiers,

• S maps each SIOA identifier A ∈ A to a state s ∈ states(A),

• E is the set of actors (names) that have been exposed to the environment, • U is the set of futures that the environment have used in relation to calling

methods of actors represented in the configuration, and

• B maps each SIOA identifier A ∈ A to a boolean value, indicating, if true, that A represents a component instance. Otherwise, A is an AA represent- ing an actor.

We lift the names function to component configurations, such that names(C) = S

A∈A

names(A). A component configuration C = 〈A, S, E, U, B〉 is compatible

iff, for all A, B_{∈ A, A 6= B:} • names(A) ∩ names(B) = ;,

• out(A)(S(A)) ∩ {e | target(e) ∈ names(B) ∨ caller(e) ∈ names(B)}

⊆ in(B)(S(B)) ∩ {e | caller(e) ∈ names(A) ∨ caller(e) ∈ names(B)}, and • out(A)(S(A)) ∩ {e | isCreate(e) ∧ target(e) ∈ names(B)} = ;.

E ⊆ names(C) and U ⊆ {u | ancestors(gen(u)) ∩ names(A) = ;}. Additionally, for all A_{∈ A : |names(A)| > 1 =⇒ B(A) = true.}

The definition above is a natural extension to the actor configuration defini- tion (Definition8.1), where it provides also a map to indicate which SIOA in the configuration are representing groups of actors. The compatibility of component configurations only differs from that of actor configurations in the assumption that each SIOA represents an actor. Apart from that, the compatibility notion remains

the same. An output event generated by an actor represented within some actor- based SIOA A and sent to an actor represented within B can be accepted as an input event for the target actor, and no creation event that marks the creation of an actor that is already in the actor configuration is generated. The compatibility notion above assumes that there is no conflict within an SIOA, which is guaranteed by how the transitions are intrinsically derived. This notion also strengthens the usage of the mapping, such that when an SIOA represents a component instance, it is marked so in the mapping B, which we call component instance mapping. The function names for actor configurations retains the same meaning for component configurations. This function applied to a component automata instance returns the set of all actors that may be transitively created by the initial actor of the com- ponent instance. We qualify(A, s, b) as a member of a component configuration 〈A, S, E, U, B〉 if A ∈ A, S(A) = s and B(A) = b. The functions exposed(C) and

futs(C) retain their meaning for actor configurations.

The notion of intrinsic signatures of component configurations is formalized by Definition9.4. This notion is the same as that for actor configurations, because the additional element B does not affect the actual signatures of each SIOA within a configuration.

As with the intrinsic signatures, the intrinsic transitions for component config- urations do not differ much from the intrinsic transitions for actor configurations. There are two main differences: the consideration of groups of actors as compo- nent instances, instead of just single actors, and the inclusion of activator classes to distinguish which groups of actors should be represented by an SIOA. Unlike for actor configurations where an actor creation event simply means adding a new SIOA to the set of existing SIOA, in the component case we have to distinguish whether the new SIOA is going to be composed with the SIOA that generates the event or it is going to be a separate member of the configuration. The latter case requires a further check on whether the class of created actor is an activator class. If so, the component instance mapping for the corresponding SIOA marks this SIOA as a component. Furthermore, if the activator class is represented in its boxed variant, the component automaton instance is used in the configuration instead of the actor automaton one. Because an SIOA may represent a group of actors, more than one actor of that group can be exposed within one single event. A component intrinsic transition (Definition 9.5) relies on the event being in the intrinsic signature of the component configuration. If e is a creation event such that the creator is part of a component instance, then the SIOA representing the component instance is composed with the new SIOA in the configuration. If

e is a creation event where the creator is not part of a component instance, the new SIOA is a new member of the configuration. Furthermore, if the class of

9.3. Model of Component Configuration Automata

Definition 9.4 (Intrinsic signatures of a component configuration):

Let C = 〈A, S, E, U, B〉 be a compatible component configuration. Let

commonEvbe the set of common events between actors represented within the configuration: commonEv=    e      

target(fut(e)) ∈ names(C) ∧

(isMethod(e) =⇒ caller(e) ∈ names(C)) ∧ (isCreate(e) =⇒ caller(e) ∈ names(C))

 

 .

Let envEv be the set of bogus events generated by the environment:

envEv=      e         isMethod(e) ∧

(acq(e) ∩ (envActors(names(C)) ∪ E) 6= ; ∨ fut(e) ∈ U) ∧ (isCall(e) =⇒ caller(e) /∈ names(C) ∧

(isRet(e) =⇒ target(e) /∈ names(C))

     .

Then, the signature sig(C) = 〈in(C), out(C), int(C)〉 is the intrinsic signature of C, where

• in(C) = (S A∈A

in(A)(S(A))) − commonEv − envEv

• out(C) = (S A∈A

out(A)(S(A))) − commonEv

• int(C) = (S A∈A int(A)(S(A))) ∪ ( S A∈A in(A)(S(A)) ∩ S A∈A out(A)(S(A)))

The external signature C is defined as ext(C) = 〈in(C), out(C)〉.

the created actor is an activator class, the new SIOA is marked as a component instance. The exposure of actors is done in bulks, as an SIOA may represent a group of actors. If an event is sent to the environment, all acquaintance of that event is exposed to the environment. The collection of futures used by the environment also remains the same. The transition causes the state of an SIOA in the configuration to change if an actor represented by the SIOA takes part in the event. No transition causes the mapping of component instances to change on existing SIOA.

The definition of CCA differs from ACA only on the use of component configu- rations and component intrinsic transitions. As explained previously, the activator class info must be included in the structure of CCA. To avoid confusion, an acti-

Definition 9.5 (Component intrinsic transitions):

Let C = 〈A, S, E, U, B〉, C0 = 〈A0, S0, E0, U0, B0〉 be two arbitrary compatible component configurations and e an event. Let CL ⊆ CL ∪ [CL] be a set of classes and components. If e is a creation event and class(e) ∈ CL, we let A00= A0(target(e)) be an actor automata of class class(e). If e is a creation event and [class(e)] ∈ CL is a boxed class [C], we let A00 = A0(target(e)) be a component automata of initial class C. There is a component intrinsic

transitionfrom C to C0, written as C=⇒e CLC0, iff 1. e∈ csig(C);

2. Let A00be a set of SIOA identifiers such that,

• if e is a creation event (i.e., isCreate(e)), A ∈ A is an SIOA such that

caller(e) ∈ names(A) and A is derived from a group of actor automata

(i.e., B(A) = true),

A00= (A − {A}) ∪ {A k A00} ;

in addition, S0(A k A00) = 〈s0, s00〉 where S(A)−→e As0and s00∈ start(A00) such that param(e) = s00(params);

• if e is a creation event (i.e., isCreate(e)), A ∈ A is an SIOA such that

caller(e) ∈ names(A) and A is an AA (i.e., B(A) = false),

A00= A ∪ {A00} ;

in addition, S0(A00) ∈ start(A00) such that param(e) = param(S0(A00)), B0(A00) = class(e) ∈ CL;

• otherwise A00= A;

3. for all A_{∈ A : B}0(A) = B(A) and if e ∈sigc(A)(S(A)) ∧ S(A) e

−→As, then S0(A) = s, otherwise S0(A) = S(A),

4. E0= E ∪    a      

(isCall(e) ∧ target(e) /∈ names(C)) ∨ (isRet(e) ∧ caller(e) /∈ names(C)) ∧

a_{∈ acq(e) − envActors(names(C))}

 

 , and

9.4. Properties of Component Configuration Automata