Representing Hierarchical Mobility in Software Architectures

Fernando J. BarrosUniversity of CoimbraPortugal

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)

C1visible:

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

6

FactorialFactorial

Connecton 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)

structuresuper structure.self link: #Ensemble gate: #factorial:

to: #Executive gate: #factorial:.self link: #Executive gate: #factorial:

to: #Executive gate: #factorial:

factorial: nn == 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

A B

A

A B

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

send:

BA

Nin:

C

receive:

out: M

send:

B

Nin:

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

Delayrun:

out:time:

out:time:in:time:

time: time:

time:

in:time:

in:time:

stats

stats

19

FIFO Server

C1

FIFOin:time:end:time: ren:time:

end:time:

ren:time:

time:

time:

end:time: ren:time:

work:factor: Cn

time:

end:time: ren:time:

… work:factor:

work:factor:

20

FIFO: Client Arrivalin: 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 Serviceend: 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: timestatus == #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