Representing Hierarchical Mobility in Software Architectures

1. 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. Motivation (I) e C1 visible: C2 hidden:

4. Motivation (II) e C1 New C2

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 • Current implementation in Smalltalk (Desmos)

6. Connecton Factorial Factorial factorial: 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 e e A B e e A B A

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) send: send: out: out: Me Me A B A B in: in: Ne Ne receive: receive: A C C

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 time: run: Delay run: DT::Simulatore in:time: time: out:time: time: time: ren:time: Stats Generator FIFO out:time: in:time: in:time: out:time: stats stats

19. FIFO Server end:time: FIFOe in:time: ren:time: end:time: ren:time: work:factor: end:time: end:time: ren:time: ren:time: work:factor: Cn C1 … work:factor: time: time: time:

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