A Constrained Executable Model of Dynamic System Reconfiguration

A Constrained Executable Model of Dynamic System ReconfigurationD’Arcy Walsh

Carleton [email protected]

Francis BordeleauZeligsoft and Carleton University

[email protected]

Bran SelicCarleton University

[email protected]

Abstract Explicit metaclass programming techniques arepresented that enable domain-specific objects todynamically change their run-time properties. Thedomain-specific objects are instantiations of a domainmodel of dynamic system reconfiguration. The domainmodel is the product of a model-based domain analysisthat identified a set of concepts that reflect the types ofreconfigurations possible and the system integritycharacteristics that must be maintained during suchreconfigurations. It is expressed using the UnifiedModeling Language (UML) as a constrainedrepresentation of the domain-level specification and thenrealized as an executable model using a programmingenvironment that supports explicit metaclass programming.

1. Introduction

Deployed software systems can be characterized as beingever more complex, ever more prevalent, and ever morecritical in many ways to society as a whole. Examplesinclude the trend toward mobile and distributed systems,embedded systems and embedded controlling devices,personal digital devices, and others. Since these systemsserve increasingly useful roles in many domains, it isimportant they are engineered for future change as thedemands placed upon them vary over time. Adaptivecomputing through dynamic system reconfigurationtechniques can enable the systematic evolution of softwaresystems due to unanticipated changes in specification orrequirements. A model-based approach is adopted in this paper in orderto identify, at an abstract level, a set of change types andsystem integrity characteristics that together can effect thechange of a component-based software system in aconsistent manner. A reconfiguration of a particular systemconforms to one or more of these general types but withinthe context of the particular conditions that motivated thechange and the concrete representations of that system. To set the scene, a high-level review of a domain modelof comprehensive change is presented. The model is aconstrained one in the sense it addresses only a subset ofthe greater problem of dynamic system reconfiguration inthe context of component-based software systems. Areview of significant previous research relevant to theformulation of the model is presented in [1]. A case study

of dynamic reconfiguration is reviewed as a domain-specific illustration of the model. The core of the paper describes the use of explicitmetaclass programming techniques to encode certainaspects of the model. Using the case study, a description isgiven of representing and then dynamically changing adomain-specific global property. The purpose ofconstructing an executable model is: (i) to gain a moredirect understanding of the conceptual framework and (ii)to validate, through empirical proof and simulation, that theconstrained model is applicable within domain-specificcontexts. The rest of this paper first presents a high-level review ofthe domain model. Section 3 presents the case study.Section 4 describes the realization of a global propertyusing explicit metaclasses. Using the case study, Section 5illustrates dynamically changing a global property. Asummary and conclusion and a discussion of future work isgiven at the end.

2. The domain of dynamic reconfiguration

This section presents a reference model of the differentkinds of evolution that could be exhibited by a dynamicallyreconfigurable component-based software system. Thefollowing domain analysis was first presented in [2] and ismore fully reported on in [1].

2.1. Domain concepts of dynamic reconfiguration

The purpose of the domain model is to provide acomprehensive conceptual framework within which tosystemically address problems and solutions related todynamically reconfigurable systems. The analysis identifiesand categorizes the various types of change that may berequired, the relationship between those types, and thesystem integrity characteristics that need to be consideredwhen such changes take place. Figure 1 shows the changetypes and their relationships with other change types andsystem integrity management areas. The component-based systems paradigm is adopted as arealization platform because complex systems can bedecomposed as software components, that are units ofdeployment, that can in principle be dynamicallyreconfigured as distinct entities (through intra-componentdynamic reconfiguration) and/or as cooperative entities(through inter-component dynamic reconfiguration). Aparticular change type is shown effecting (i) inter-

Proceedings of the 40th Hawaii International Conference on System Sciences - 2007

1©1530-1605/07 $20.00 2007 IEEEProceedings of the 40th Annual Hawaii International Conference on System Sciences (HICSS'07)0-7695-2755-8/07 $20.00 © 2007

component or intra-component change and (ii) structuralchange, when the configuration of components is changed,or behavioral change, when the functionality of existingcomponents is changed.

Figure 1. Change types and their relationships The types of system change are the following: Architectural Change changes global and/or local systemproperties. It is an inter-component change that may bestructural, behavioral, or both. Ultimately, it may requiretopology and/or protocol changes. Topology Change changes the topology of a systemthrough component addition and/or removal. This is astructural inter-component change.Ultimately, it may drive substitution orprotocol changes. Substitution replaces a particularcomponent by another within a given systemtopology. This is a structural intra-componentchange. It does not require any other types ofchange. Protocol Change changes the control flowand/or data flow of components. This is abehavioral inter-component change.Ultimately, it may require a topology changeor an interface change. Interface Change changes the externallyobservable behavior of a component. It is abehavioral intra-component change.Ultimately, it may require internal change of one or morecomponents to realize the new behavior. Internal Change changes the internal implementation of acomponent. This is an intra-component type of change thatcan be either behavioral, structural, or both. It does notrequire any other types of change.

The system integrity characteristics are: Global Consistency ensures the preservation of anyglobal architectural invariants of a system, as implied by itsspecification.

Local Consistency ensures thepreservation of any local architecturalinvariants of a system, as implied byits specification. Active Component References ensurethat any active client that is bound to achanging component has a validbinding after the change is completed(the binding may have to bedynamically updated). Dependent Operations ensure thatany change to a given operation wasvalid with respect to any clientoperations that had a directdependency on the operation about tochange. Composite Components ensure thatany change to a given component wasvalid with respect to any composedcomponents that had a directdependency on the changing

component. Constrained Operations ensure that any operation with adependency on a component’s state element would not beenacted until the given state element’s life cycle wasrestored as necessary after its component’s change. Component State indicates that any needed transfers ofstate from the changing component to its replacementcomponent(s) occurred through appropriate mechanisms.

Figure 2. Primary feature interactions

The process of dynamic reconfiguration progresses asfollows (see Figure 2):

• Determine whether User-Driven Changes and/orDomain Imposed Changes are required;

to effectstructuralchange

to effectbehavioral

change

Cascades

governed by:global consistency andlocal consistencymanagement

governed by:active component

reference,global consistency, and

local consistencymanagement

governed by:component state,active component

reference,global consistency, and

local consistencymanagement

governed by:global consistency andlocal consistency management

to effectinter-

componentchange

to effectintra-

componentchange

governed by:global consistency andlocal consistencymanagement

governed by:composite component, dependent operation,constrained operation, component state,global consistency andlocal consistency management

Architectural Change

Topology Change

Substitution

Protocol Change

Interface Change

Internal Change

System Model

Context of Change

Origin ofChange

ChangeProperties

Type ofChange

SystemIntegrity

SystemProperties

SystemSignature

ExternalInteractions

InternalBehavior

reconciledwith

representedby

determines determines

global orlocal

properties

structuralsignature

behavioralsignature

determinessystem

constructsrealigned

constrainssystem

constructsrealigned

further dynamic reconfiguration


2Proceedings of the 40th Annual Hawaii International Conference on System Sciences (HICSS'07)0-7695-2755-8/07 $20.00 © 2007

• Interpret the particular Origin of Change andrepresent it as appropriate Global Propertiesand/or Local Properties with an associatedReconciliation Policy (this would includereconciliation with existing System Properties);

• Determine what feasible subsets of Type ofChange (if any) would satisfy the ConditionChange Criteria; and

• If necessary, realign Dependencies and, possibly,External Interactions andInternal Behavior; and,finally, ensure SystemIntegrity Characteristics aremaintained when enactingchange.

2.2. Domain concepts as UMLclasses

Figure 3 shows a UML model of thedomain concepts as classes. Withrespect to change propertiesreconciliation, the classes SystemProperties and Change Propertiesrepresent the current system propertiesand (new) change properties,respectively, as global and localconstraints. Each grouping ofproperties is internally reconciledaccording to reconciliation policies. Inaddition, these groupings arereconciled with respect to each other.The overall reconciliation is modeledas a binary association linking SystemProperties and Change Properties.The reconciled change properties inturn determine which subsets ofchange types are required to performthe necessary system reconfiguration. With respect to change enactment,the classes Change Type, SystemIntegrity Characteristics, and SystemModel specify how the requiredchange types, as constrained by systemintegrity characteristics, realign thesystem model. Depending upon thetypes of change required, the structuraland/or behavioral signature of thesystem may have to be re-aligned, which, in turn, mayimpact its internal behavior or external interactions. With respect to further dynamic reconfiguration, giventhe internal behavior or external interactions of a systemhave changed, the system may reach a failure state orrequire further change based upon emergent properties.

This is represented by the group of classes ExternalInteractions, Internal Behavior, Fault Tolerance Mode, andOrigin Of Change. External Interactions and InternalBehavior are related to Fault Tolerance Mode upon failure(or emergent properties). Fault Tolerance Mode then drivesOrigin Of Change (which ultimately may be user driven ordomain imposed) which in turn indicates needed changeproperties. This completes the cycle of system dynamicreconfiguration described by the domain model.

Figure 3. Class model of comprehensive change

ContextOfChange

activeComponentReferencecomponentStateconstrainedOperationsdependentOperationscompositeComponentsglobalConsistencylocalConsistency

SystemIntegrityCharacteristicsConditionChangeCriteria

globalPropertieslocalPropertiesreconciliationPolicy

ChangeProperties

internalChangeinterfaceChangeprotocolChangetopologyChangearchitecturalChangesubstitution

ChangeType

DynamicReconfiguration

userDrivendomainImposed

OriginOfChange

globalPropertieslocalPropertiesreconciliationPolicy

SystemPropertiesstructuralSignaturebehavioralSignature

SystemSignature

Dependencies

SystemModel

emergentPropertiesFaultToleranceMode

ExternalInteractionsoperationsstateElementsthreads

InternalBehavior

serviceProtocolconnections

CommunicationPathprovidedServicesrequiredServices

Component

1

1

1

* *

1*

1

1 1

*

*

1

1

* 1

1

1

* 1 *

* 1 11

*

1

*

1 1

1 * *

1

*

* *1

1

1

1

*



3. Financial analysis system case study

The following is a review of a financial analysis systemcase study first presented in [3] and more fully reported onin [1]. The case study is a domain-specific example ofchanging global and local properties leading tocomprehensive change. The example describes thecomponents and the dynamic interoperation of two initiallydecoupled financial systems that specialize in maintainingknowledge and providing predictions about a particularsector of the economy. System A’s clients are concernedwith shorter-term predictions. System B’s clients areconcerned with longer-term predictions.

Figure 4. Original control style of system A

Figure 5. Original control style of system B

The following are examples of global system properties:• (GP1) The control style of each system (as depicted by

use case maps );• (GP2) The operations of different components provide

needed behavior within limited time constraints(scenario analysis must not be invalidated by currentfinancial conditions); and

• (GP3) The state elements of different components areupdated in a synchronized fashion (present valueanalysis, cash flow projection, and scenario analysisreference data is synchronized).

The following are examples of local system properties:• (LP1) A component has an upper bound on the number

of threads that may be spawned in response to remoteservice requests;

• (LP2) A provided service has at most one requiredservice bound to it and vice versa; and

ScenarioAnalysis

Energy SectorKnowledge

Energy SectorConditions

Valuation AssessmentCash Flow Projections

a1

a2 a3 a4 a5a6a7

a8a9

a1. generate on-line financial conditions.

a4. update on-line financial conditions;update knowledge information aboutmarket sector.

a8. provide knowledgeinformationabout market sector.a9. update knowledgeinformationabout market sector.

a2. provide cash flow projections.a3. provide valuation assessment.

a5. determine currentmarket knowledge.a6. current financial conditionsand market knowledge.a7. update preferred stock andcommon stock value predictions.

ScenarioAnalysis

Energy SectorKnowledge

Energy SectorConditions

ValuationAssessment

Cash FlowProjections

b1 b2

b3b4

b5

b6 b7 b8

b9

b10b11

b1. generate on-line financial conditions.

b2. update on-line financial conditions;update knowledge information aboutmarket sector.

b3. determine current knowledgeabout market.b4. provide current financialconditions and knowledge aboutmarket.

b5. determine cash flow projections.

b6. provide cash flow projections.

b8. provide valuation assessment.

b9. update preferred stock and bondvalue predictions.

b10. provide knowledgeinformation about marketsector.b11. update knowledgeinformation about marketsector.

b7. determine valuation assessment.



• (LP3) The values of certain state elements may notchange (Scenario Analysis reference data, oncesynchronized, remains immutable).

Figure 4 shows the original control style of System A.Use Case Maps (UCMs) [4] are used to illustrate the causalflow that is required of System A’ s components to provideshorter-term predictions. For example, for timelinessreasons, cash flow projections and valuation assessment aredone on-line. Figure 5 shows the original control style of System B.UCMs are used to illustrate the causal flow that is requiredof System B’ s components to provide longer-termpredictions. For example, for reasons of accuracy, cashflow projections and valuation assessment is done off-lineon demand. The systems are dynamically reconfigured so that SystemA can leverage System B’s preferred stock predictions. Todo this, each system’s architectural constraints arereconciled and changes are constrained to be backwardcompatible. System A is then able to provide improvedanalytic results for its respective clients based upon thenew information that is available from System B.

Figure 6. New control style of system A Figure 6 shows the new control style of System A. A newUCM represents the causal flow linking the ScenarioAnalysis component of System A to the Scenario Analysiscomponent of System B. This enables System A to useSystem B’s longer-term predictions to validate its shorter-term predictions. System evolution happens as follows:

• Evolution is localized to the scenario analysiscomponent of System A

• A communication path is established between thetwo systems

• System A’s external interactions evolve to supportnew required service

• Internal behavior of System A’s scenario analysiscomponent evolves in place so that it can processthe new information that is exchanged.

4. Using explicit metaclasses as an executablerepresentation

When a system’s run-time properties are realized asinstantiations of programmable metaclasses, theseproperties can be dynamically changed when theirmetaclasses change. This section explains the use ofexplicit metaclass programming techniques to realize theconstrained model in order to gain a direct understandingof the conceptual framework and to validate itsapplicability within a domain-specific context. First thesuitability of MetaclassTalk’s particular explicit metaclassprogramming facility is discussed and then a description isgiven of using this facility to represent a global property.

4.1 MetaclassTalk as a reflective substrate

Bouraqadi-Saadani, N. and T. Ledoux [5] describes areflective system development approach that utilizes safeand explicit metaclass programming techniques and animplementation environment that enables this that is knownas MetaclassTalk. This paradigm is based upon meta-links,which causally connect base-level and meta-level objects,and meta-object cooperation, which is explicitlyprogrammed. Examples of the kinds of relationships thatmay be implemented between base-level objects and meta-level objects include: (i) a single meta-object sharedbetween instances of the same class; (ii) a single specificmeta-object private to each base object; and (iii) many

S cenario Ana lysis-A

E nergyS ectorK now ledge-A

a5a6

a12

a5. determ ine current knowledge about m arket.

a6. provide current financia l conditions and knowledgeabout m arket.a7. update preferred s tock and com m on stock valuepredic tions. a8. provide knowledge in form ation about

m arket sector.a9. update knowledge in form ation aboutm arket sector.

S cenarioA na lysis-B

a7 a10

a8

a11

a9

a10. determ ine long-term predic tedvalues.

a11. provide long-term predic tedvalues.a12. va lidate short-term predic tionsusing long-tem predic ted values.



meta-objects shared among many base objects [5]. This isshown in Figure 7 below:

M eta-objects

Base-objects

o1 o2 o3 o4

m o1 m o2 m o3

m o5m o4

Meta-link Meta-cooperation

Figure 7. Base versus meta-objects Figure 8 shows how MetaclassTalk can be used as areflective substrate of the domain model presented inSection 2.1. The System Model and Context of Changefeatures, shown in Figure 2, are encoded as meta-objectsthat cooperate to enable the dynamic reconfiguration ofbase-level domain-specific component interactions. Themeta-link linking the base-level to Context of Changerepresents emergent run-time characteristics that areultimately manifested as change properties. Context ofChange and the System Model cooperate at the meta-levelto reconcile change properties with existing systemproperties and to realign the behavioral and/or structuralprofile of the system as required. The meta-link linking thebase-level to the System Model represents the causalconnection required to affect the realignment of therunning system. This may in turn lead to new emergentrun-time characteristics, leading to further dynamicreconfiguration, and so on.

M eta-objects

Base-objects

System M odelMeta-objects

Context ofChange

Meta-objects

InteractingCom ponents

Em ergentProperties

Figure 8. Using the reflective substrate

4.2 Using explicit metaclass programming

This subsection illustrates how the UML class model ofcomprehensive change, presented in Section 2.2, isencoded within the reflective substrate using explicitmetaclass programming techniques. What follows is anexplanation of how Global Properties are encoded.

Bouraqadi-Saadani [6] explains the use of compatibilityand property metaclasses to ensure the overallcompatibility of composed metaclasses that are explicitlyprogrammed. This technique is employed when encodingthe constrained model and therefore compatibility andproperty metaclasses are part of the encoding. Bouraqadi-Saadani [6] also implements meta-level support for mixinsas a mechanism to augment property metaclasses. Thistechnique is also used when encoding the model. As analternative mechanism to mixins, the use of “traits” isunder review [7]. Because [6] explicitly uses the termproperty, property named elements of the constrainedmodel, described in Section 2.2, are referenced asconstraints below. Figure 9 shows how global and local constraints (shownas global and local properties in Figure 3) are encoded. Aglobal constraint is a system characteristic that requiresglobal knowledge for conformance. A local constraint is asystem characteristic that requires local (i.e. component-level) knowledge for conformance. Examples of constraintcharacteristics that may apply, globally or locally, includestate element immutability, cardinality (i.e. limits on thenumber of threads or service bindings, and so on),performance, synchronization, distribution, persistence,security, control style, and so on. These characteristics arerepresented as Constraint Characteristics Meta Objects inFigure 9. They are ‘mixedin’ when a global or localconstraint is instantiated based upon a mixin linearizationlist that determines the order of composition. The following is a short description of the metaobjectsshown in Figure 9 that are required to encode a globalproperty:• Global Constraint is defined as a concrete subclass of

Constraint. It is an instance of Global ConstraintProperty Meta Object. When instantiated as a base-level object, a global constraint represents a particularglobal property of a component-based softwaresystem. Domain-specific examples of globalconstraints were given in Section 3.

• Constraint is defined as an instance of ConstraintProperty Meta Object. It is the abstract superclass ofGlobal Constraint and Local Constraint. It implementsconstraintSpec, which represents the specification of aparticular global or local constraint that is instantiatedby Global Constraint or Local Constraint. It alsoimplements the creation method, new: with MixinLinearization List, of Global Constraint and LocalConstraint. The mixin linearization list determines themixin properties that are composed when a global orlocal constraint is created.

• Constraint Property Meta Object is defined as aninstance of Composite Class (not shown). Compositeclass is part of the MetaclassTalk library. It is a classwhose instances inherit from their superclass through aset of mixins. The inheritance relationship is via



implicit subclass(es) of the ‘official superclass’ that arebuilt by means of the mixin mechanism. ConstraintProperty Meta Object is defined as a subclass ofConstraint Compatibility Meta Object with Abstract asa mixin. Abstract is part of the MetaclassTalk libraryof mixins. When it is added as a mixin to ConstraintProperty Meta Class mixins, Constraint becomes anabstract class.

Figure 9. Encoding global and local constraints

• Constraint Compatibility Meta Class is defined as asubclass and as an instance of Standard Class (notshown). Standard Class is part of the MetaclassTalklibrary. This is the root class of all MetaclassTalkexplicit metaclasses. When subclassed, it enables theexplicit definition of new kinds of (meta) classes.Constraint Compatibility Meta Class enables thecompatibility model described in [6] among the

inheritance hierarchies that underpin Constraint,Global Constraint, and Local Constraint.

• Global Constraint Property Meta Object is defined asan instance of Composite Class to enable mixinproperty composition (not shown). It is defined as asubclass of Global Constraint Compatibility MetaObject to ensure it complies with the meta classcompatibility model. Class With Instance MutableMeta Objects is part of the MetaclassTalk library of

mixins (not shown). When added as a mixin, theinstances of Global Constraint Property Meta Object(i.e. Global Constraint) have their own metaObjectwhich can be changed over time.

• Global Constraint Compatibility Meta Class is definedas an instance of Standard Class (not shown). As anexplicit metaclass, it is defined as a subclass ofConstraint Compatibility Meta Object to enable thecompatibility model.

M eta-m eta-objects

M eta-objects

Constraint

ConstraintPropertyM etaObject

GlobalConstraint

LocalConstraint

Abstract<<m ixin>>

ConstraintCom patibilityM etaObject

LocalConstraintPropertyM etaObject GlobalConstraintPropertyM etaObject

LocalConstraintCom patibilityM etaObject GlobalConstraintCom patibilityM etaObject

inherits from

instance of

ConstraintCharacteristicsM etaObjects{immutability,cardinality,performance,synchronization,

distribution,persistence,security,control style, ...}<<m ixin>>

new: withMixinLinearizationList

System A-GP1-Control Style Constraint System A-GP1-Change Property

M eta-objects

Base-objects



5. Executing a domain-specific example

This section illustrates how the reflective substrate isused to execute a domain-specific example. The followingis presented: (i) a description of how a global property isinstantiated using the encoded model; and (ii) anexplanation of how the substrate affects base-level domain-specific dynamic reconfiguration, when the global propertychanges.

5.1 Representing a global property

This subsection illustrates how the reflective substrate, isused to create instances of GP1, which determines thecontrol style of System A. Figure 9 shows the base-leveland meta-level interactions required. System A - GP-1-Control Style Constraint and System A - GP-1-ChangeProperty are shown as instances of Global Constraint.When System A - GP-1-Control Style Constraint andSystem A - GP-1-Change Property are created, their globalconstraint properties are augmented with an appropriatecontrol style provided by Control Style CharacteristicsMetaObjects. System A – GP1 – Control Style Constraintconforms to the control style shown in Figure 4. System A –GP1 – Change Property conforms to the control styleshown in Figure 6. For example, when System A - GP-1-Control StyleConstraint is created, the mixin linerization list drives thecomposition of specific control style metaobjects thatconstrain the configuration of System A’s components toensure cash flow projections and valuation assessment aredone on-line. MetaclassTalk code fragments are shown below toillustrate how this is done. In the example, gp1 is created torepresent the global property System A - GP-1-ControlStyle Constraint. The specification of this property forSystem A is ‘On-Line Control’. When gp1 is created, themetalink policy Class With Instance Mutable Meta Objectsis applied that enables it to have a unique metaclass (this isreported as “a single specific meta-object private to eachbase object” in Section 4.1). In the case of gp1 its particularproperties are augmented with System A On Line ControlStyle MetaObject in support of its ‘On-Line Control’specification:

gp1 := GlobalConstraint new.gp1 constraintSpec: ‘Control Style of System '.metaclass := MetaObject

subclass: #GP1AMetaClass instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Dynamic Reconfiguration-Interacting

Components-Instance Specific Property MetaObjects'

metaclass: CompositeClass.metaclass addMixin:ClassWithInstanceMutableMetaObjects.metaclass addMixin:SystemAOnLineControlStyleMetaObject.metaclassInstance := metaclass new.gp1 metaObject: metaclassInstance.

When GP1AMetaClass is created, it is a metaObjectspecific to gp1. Its mixins include System A On LineControl Style Meta Object:

MetaObject subclass: #GP1AMetaClassinstanceVariableNames: ''classVariableNames: ''poolDictionaries: ''category: 'Dynamic Reconfiguration-Interacting

Components-Instance Specific Property MetaObjects'metaclass: CompositeClass.

GP1AMetaClass mixins:{ClassWithInstanceMutableMetaObjects.SystemAOnLineControlStyleMetaObject}

System A On Line Control Style Meta Object is a mixinwith instance variable ‘system Signature For System A OnLine Control’:

Mixin named: #SystemAOnLineControlStyleMetaObjectinstanceVariables:

'systemSignatureForSystemAOnLineControl 'category: 'Dynamic Reconfiguration-Mixins'

System A On Line Control Style Meta Object implementsa standardized protocol that is used to set up ‘systemSignature For System A On Line Control’. It is an instanceof System Signature (see Figures 2 and 3) which in thiscase represents the behavioral and structural dependenciesreflected by Figure 4. Below is an example of part of theprotocol implemented by System A On Line Control StyleMeta Object:

setUpConnectedComponentDependencies

systemSignatureForSystemAOnLineControlconnectComponent: selfenergySectorConditionsComponent toComponent: selfcashFlowProjectionsComponent.

systemSignatureForSystemAOnLineControlconnectComponent: self cashFlowProjectionsComponenttoComponent: self valuationAssessmentComponent.

systemSignatureForSystemAOnLineControlconnectComponent: self valuationAssessmentComponenttoComponent: self energySectorKnowledgeComponent.



systemSignatureForSystemAOnLineControlconnectComponent: selfenergySectorKnowledgeComponent toComponent: selfscenarioAnalysisComponent.

The instance specific metaObject of System A - GP-1-Change Property also implements the standardizedprotocol. In its case, its System Signature represents thebehavioral and structural dependencies reflected by Figure6.

5.2 Dynamically reconfiguring a global property

The requirement for System A to dynamically inter-operate with System B is an example of emergentproperties as shown in Figure 8. This subsection describeshow the reflective substrate affects base-level domain-specific dynamic reconfiguration, when a global propertychanges. In this example, the outcome is reflected byFigure 6 with a new UCM causally linking System A toSystem B. Ultimately, a change to the global and localproperties of System A leads to its behavioral andstructural realignment (see Figure 2) to make this happen.The scope of this example is restricted to illustrate changeproperties affecting existing system properties, whichsubsequently drives the system signature of System A tochange. In Figure 9 emergent system properties are manifested asSystem A – GP1 – Change Property. System A - GP-1-Control Style Constraint represents an existing reconciledglobal constraint of System A before any change. System A– GP1 – Change Property is a global constraint thatimplies a change to the control style of System A asreflected by Figure 6. Its particular properties areaugmented with System B Interoperation MetaObjectwhich represents its augmentation of the ‘On-Line Control’specification:

newgp1a := GlobalConstraint new.newgp1a constraintSpec: ‘Control Style of System '.metaclass := MetaObject

subclass: #NewGP1AMetaClass instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Dynamic Reconfiguration-Interacting

Components-Instance Specific Property MetaObjects' metaclass: CompositeClass.

metaclass addMixin:ClassWithInstanceMutableMetaObjects.metaclass addMixin: SystemBInteroperationMetaObject.metaclassInstance := metaclass new.newgp1a metaObject: metaclassInstance.

When NewGP1AMetaClass is created, it is a metaObjectspecific to newgp1. Its mixins include System BInteroperation Meta Object:

MetaObject subclass: #NewGP1AMetaClassinstanceVariableNames: ''classVariableNames: ''poolDictionaries: ''category: 'Dynamic Reconfiguration-Interacting


NewGP1AMetaClass mixins:{ClassWithInstanceMutableMetaObjects.SystemBInteroperationMetaObject}

To drive system change, the original metaclass propertiesof System A - GP-1-Control Style Constraint aredynamically augmented to reflect the new control style ofSystem A by adding the metaclass properties of System A –GP1 – Change Property as additional mixin properties ofSystem A - GP-1-Control Style Constraint:

gp1 metaObject class addAllMixins: (newgp1 metaObjectclass mixins).

This is the result after adding the mixins of newgp1’smetaclass to the mixins of gp1’s metaclass. The mixins ofGP1AMetaClass now includes System B Interoperation MetaObject:

MetaObject subclass: #GP1AMetaClassinstanceVariableNames: ''classVariableNames: ''poolDictionaries: ''category: 'Dynamic Reconfiguration-Interacting


GP1AMetaClass mixins:{ClassWithInstanceMutableMetaObjects.SystemAOnLineControlStyleMetaObject.SystemBInteroperationMetaObject}

System A On Line Control Style Meta Object and SystemB Interoperation Meta Object each encapsulate a SystemSignature as described in Section 5.1. When the overallSystem Signature of System A is regenerated, these SystemSignature ‘fragments’ are composed. This drives thebehavioral and structural realignment of the system (seeFigure 2).

6. Summary, conclusion and future work

This paper described a constrained model of dynamicsystem reconfiguration by presenting a high-level UMLclass model of the domain concepts of comprehensive



change. An explanation was given of how the model couldbe encoded within a reflective substrate using explicitmetaclass programming techniques. The encoding wasillustrated by describing how global and local properties ofthe model are represented using base-level and meta-levelobjects whose interactions are enabled through meta-linksand meta-cooperation. Finally, a description was given ofhow the substrate could be used to execute base-leveldynamic reconfiguration using an example of changing adomain-specific global property. The control style metaObjects could express the requiredcontrol style formally as constraints [8, 9] in conjunctionwith an appropriate Architecture Description Language(ADL) [10]. The reconciliation of existing systemproperties and new change properties could then beresolved through a constraint solver. Depending upon thecontext, there may not be a solution. In this case, thechange may be rejected or the change constraints re-expressed in a manner that enables a resolution. This issueis not addressed in this paper but is the subject of futurework. It was learned that the explicit metaclass programmingfacility of MetaclassTalk can effectively be used to encodethe constrained model, as a static representation, at themetalevel. Base level objects could then be instantiated,based upon these static representations, as domain-specificinteractions. With respect to dynamic reconfiguration, itwas learned that a base-level object could be an instance ofa property metaclass that is unique to that base-level object.Through MetaclassTalk’s mixin mechanism, emergent run-time properties could be dynamically composed thatapplied just to that object. The set of available mixinsshould also be adjusted dynamically. This was notaddressed in this paper but will also be the subject of futurework. A key aspect enabling adaptive computing is the level ofdynamism supported by the computing environment inwhich a system is running. Open-ended facilities thatenable a system to extend itself, based upon self-representation, are viewed as a mandatory characteristic ofany environment that supports dynamic reconfiguration. Tobe fully dynamic, a reflective substrate must supportmetaobject representations that evolve in phase with an

adaptive system’s changing computing environment.Ultimately, this means emergent system properties mustinfluence not just what is computed but how the systemcomputes what is computed (through, for example, explicitmetaclass programming techniques that change the self-representation of the system).

7. References1. Walsh, D., F. Bordeleau, and B. Selic, Domain analysis

of dynamic system reconfiguration. Accepted forPublication in Software and System Modeling,Springer-Verlag, 2006.

2. Walsh, D., F. Bordeleau, and B. Selic. A Domain Modelfor Dynamic System Reconfiguration. in ACM/IEEE 8thInternational Conference on Model Driven EngineeringLanguages and Systems. 2005. Montego Bay, Jamaica:Springer.

3. Walsh, D., F. Bordeleau, and B. Selic. Change Types ofDynamic System Reconfiguration. in 13th Annual IEEEInternational Conference and Workshop on theEngineering of Computer Based Systems (ECBS). 2006.Potsdam, Germany: IEEE.

4. Buhr, R.J.A. and R.S. Casselman, Use Case Maps forObject-Oriented Systems. 1996, New York, NY:Prentice Hall.

5. Bouraqadi-Saadani, N. and T. Ledoux, Supporting AOPUsing Reflection, in Aspect-Oriented SoftwareDevelopment. 2005, Addison-Wesley: New York, NewYork. p. 261-279.

6. Bouraqadi-Saadani, N. Metaclass Composition UsingMix-in-Based Inheritance. in 11th Smalltalk ESUGConference. 2003. Bled, Slovenia.

7. Scharli, N., et al. Traits: Composable units of behavior.in ECOOP 2003. 2003: LNCS 2743, Springer Verlag.

8. Jackson, D., Micromodels of Software: LightweightModelling and Analysis with Alloy. 2002, MIT Lab forComputer Science: Cambridge, Mass. p. 1-58.

9. Marriott, K. and P.J. Stuckey, Programming withConstraints An Introduction. 1998, Cambridge, Mass.:MIT Press.

10. Medvidovic, N. and R.N. Taylor, A Classification andComparison Framework for Software ArchitectureDescription Languages. IEEE Transactions on SoftwareEngineering, 2000. 26(1): p. 70-93.



A Constrained Executable Model of Dynamic System Reconfiguration

Documents