Modeling Computational Activities with SCEL Sample Clauses

Modeling Computational Activities with SCEL. ‌ To complement the high-level, architectural design, we have proposed specific linguistic and program- ming abstractions aiming at dealing with the challenges posed to language designers by massively distributed and highly dynamic systems. Our starting points have been the notions of autonomic components (ACs) and autonomic-component ensembles (ACEs) that are used to structure systems into independent and distributed building blocks that interact and adapt in different ways. Based on the notions of ACs and ACEs, we have introduced a number of specific abstractions and linguistic constructs that permit building up ACs, defining ACEs and programming their behaviors and interac- tions. The proposed abstractions are the basis of SCEL (Software Component Ensemble Language) [DLPT13, DFLP11b]. ACs are entities with dedicated knowledge units and resources that can cooperate while play- ing different roles. Each AC is equipped with an interface, consisting of a set of attributes, such as provided functionalities, spatial coordinates, group memberships, trust level, response time, etc. Attributes are used by the ACs to dynamically organize themselves into ACEs. Indeed, one of the main novelties of SCEL is the way sets of partners are selected for interaction and thus how ensembles are formed. Individual ACs not only can single out communication partners by using their identities, but they can also select partners by exploiting the attributes in the interfaces of the individual ACs. Predicates over such attributes are used to specify the targets of communication actions, thus providing a sort of attribute-based communication. In this way, the formation rule of ACEs is endogenous to ACs: members of an ensemble are connected by the interdependency relations defined through predicates. Starting from the IRM model presented in Figure 7, we can identify two kinds of SCEL compo- nents, namely PLCSs and Vehicles: Iplcs1[Kplcs1, Πplcs1, Pplcs1] ǁ Iplcs2[Kplcs2, Πplcs2, Pplcs2] ǁ . . . ǁ Ivehicle1[Kvehicle1, Πvehicle1, Pvehicle1] ǁ Ivehicle2[Kvehicle2, Πvehicle2, Pvehicle2] ǁ . . . A PLCS identifies a parking lot/charging station and is characterized by a position, its availability and, possibly, a chargingStation. These are the attributes that are exposed in the component interface and that respectively identify the location of the PLCS, the number of available slots in the area and the presence of a charging station. Iplcs j ¾ {(id, plcsj), (type, “PLCS ”), (position, (xj,...