Representing Hierarchical Mobility in Software Architectures Fernando J. Barros University of Coimbra Portugal

2 Introduction The ability to move components from one hierarchical model to another becomes necessary to support arbitrary changes in software topologies Mobility allows the access to the hidden interface of a hierarchical component without breaking encapsulation, keeping the architecture modular Mobility permits the introduction of new functionally in the application without requiring changes in the architecture

3 C2 Motivation (I) C1 visible: hidden:  

4 C2 Motivation (II) C1   New

5 Connecton Software Architecture Supports modular software components Supports hierarchical composition (Connecton ensembles) Ensembles can have a dynamic topology Connectons can migrate between ensembles Connectons combines general systems theory and object- oriented styles Scalable solution based on the distributed definition of topology Supports ad-hoc structural changes Desmos Current implementation in Smalltalk (Desmos)

6 Factorial Connecton Factorial factorial :

7 Factorial (I) “Ensemble” ensembleInGates ^(super ensembleInGates) add: #factorial: “Executive” inGates ^(super inGates) add: #factorial: outGates ^(super outGates) add: #factorial:

8 Factorial (II) structure super structure. self link: #Ensemble gate: #factorial: to: #Executive gate: #factorial:. self link: #Executive gate: #factorial: to: #Executive gate: #factorial: factorial: n n == 0 ifTrue: [^1]. ^n * (out factorial: n - 1) (Factorial new: #F) factorial: 7

9 Structural Changes Topology adaptation has been subject to research in different areas like software engineering and general systems theory (simulation) The ability to change dynamically a running entity has been regarded as a powerful construct to build self-adaptive systems Methodologies supporting topology adaptation enable a representation with structural similarity easier to develop and to maintain components

10 Kind of Structural Changes     AB   A   AB

11 Mobility (I) The use of hierarchical components in system representation brings a new problem not present in non-hierarchical systems Hierarchical components hide their inner constitution from the outside how to expose inner components without violating encapsulation? Solutions proposed in systems theory and distributed systems, involve the use of mobile components components that can be transferred between two hierarchical components Inside an ensemble, a mobile component has access to the inner interface of a hierarchical component no violation of encapsulation After visiting an ensemble, a mobile component can return with the gathered information

12 Mobility (II) Mobility permits to extend indirectly the current interface of hierarchical component A mobile component can be used to modify the behavior of a hierarchical component A mobile component can be employed in a local reconfiguration bringing new behavior to an ensemble The mobile component may become permanently part of the visited ensemble

13 Mobility (III) Mobility requires the capability to remove a component from an ensemble and the ability to transmit it to another hierarchical component The visited ensemble needs to add the mobile component and to establish new links between the existing Connectons and the visiting one

14 Mobility (IV) MM send: BA NN in: C receive: out: MM send: B NN in: C receive: out: A A

15 Desmos Primitives addConnecton: aConnecton adds an existing connecton; remove: aConnecton removes a connecton link: aName gate: aGate to: bName gate: bGate links a Connecton named aName gate aGate to gate bGate of Connecton named bName unLink: aName gate: aGate from: bName gate: bGate unlinks a Connecton named aName gate aGate from gate bGate of Connecton bName

16 Server System Simulation The system is composed by a client generator, a FIFO server, a Delay server, and a statistic Connecton that computes clients’ cycle- time Clients have their own strategy to get the service in the FIFO server If they wait too long in the queue they quit and look for service in a competitor Each client is responsible for evaluating if the waiting time exceeds the maximum limit and to quit without getting service

17 Mobile vs. Conventional In a conventional approach servers treats clients as passive decisions are made by the server The conventional solution does not scale the addition of a new type of client requires changing all servers Mobility permits the addition of new behavior by introducing new type of clients servers remain unchanged Mobility provides scalability

18 Server System run: DT::Simulator  time: out:time: ren:time: Generator FIFO Stats Delay run: out:time: in:time: time: in:time: stats

19 FIFO Server C1C1 FIFO  in:time: end:time:ren:time: end:time: ren:time: time: end:time: ren:time: work:factor: CnCn time: end:time: ren:time: … work:factor:

20 FIFO: Client Arrival in: aClient time: time |name| self addConnecton: aClient. name := aClient _name. self link: #Ensemble gate: #time: to: name gate: #time:. self link: name gate: #reneging:time: to: #Executive gate: #reneging:time:. self link: name gate: #end:time: to: #Executive gate: #end:time:. status = #busy ifTrue: [^queue add: name]. status := #busy. self link: #Executive gate: #work:factor: to: name gate: #work:factor:. out work: time factor: 1. self unlink: #Executive gate: #work:factor: from: name gate: #work:factor:.

21 FIFO: End Service end: aClientName time: time |client clientName| client := self remove: aClientName. out end: client time: time. queue size == 0 ifTrue: [^status := #idle]. clientName := queue removeFirst. self link: #Executive gate: #work:factor: to: clientName gate: #work:factor:. out work: time factor: 1. self unlink: #Executive gate: #work:factor: from: clientName gate: #work:factor:.

22 Client: Time Advance time: time status == #waiting ifTrue: [ (time - timeIn) >= wTime ifTrue: [ out reneging: self _name time: time ]. ^nil ]. (time - startWorking) >= (pTime * factor) ifTrue: [ cycleTime := time - timeIn. out end: self _name time: time ].

23 Delay: Client Arrival in: aClient time: time |name| name := aClient _name. self addConnecton: aClient. self link: #Network gate: #time: to: name gate: #time:. self link: name gate: #end:time: to: #Executive gate: #end:time:. self link: #Executive gate: #work: to: name gate: #work:. out work: time factor: 2. self unlink: #Executive gate: #work: from: name gate: #work:

24 Conclusions Mobility plays an important role in the adaptation of hierarchical software architectures While adaptation in flat structures requires only changes in components interactions, hierarchical architectures require mobility Mobility enables the introduction of new behavior in the system without the need to change the existing elements Mobility permits to access the inner components of a hierarchical ensemble while keeping encapsulation

25 Future Work Mobile Connectons can be used to implement agent-based simulation kernels, providing a construct to represent mobile agents Extensions to the work currently support discrete event simulation Future work will address the representation of hybrid systems

26 Client: Start Service work: time factor: f status := #working. startWorking := time. factor := f.

27 Delay: End Service end: aClientName time: time |client| client:= self remove: aClientName. out end: client time: time

28 FIFO: Reneging Service ren: aClientName time: time |client| client := self remove: aClientName. queue remove: aClientName. out ren: client time: time.

29 Mobility (III) A A   B B C C  