DArcy Walsh

1
Constrained Executable Model of Dynamic System
Reconfiguration

• DArcy Walsh
• Carleton University jdwalsh_at_acm.org

Francis Bordeleau Zeligsoft Carleton
Universityfrancis_at_zeligsoft.com
Bran SelicCarleton Universitybselic_at_ca.ibm.com
2
Outline

• Main Concepts
• Key Results
• Implications
• Future Work

3
Main concepts

• Case-study driven
• domains financial analysis, bioinformatics,
  cognitive radio
• Feature-oriented domain analysis
• concept dynamically reconfigurable
  component-based system
• application of model-driven development
  techniques
• Change represented as constraints
• global and local properties drive system
  signature
• Executable representation using explicit
  metaclasses
• metaobjects encapsulate system signature
  fragments
• run-time composition of metaobjects

4
Key results

• Financial system case study
• Integration of two financial prediction systems
• Domain analysis of dynamic system reconfiguration
• system model composed with context of change
• Metaclasses used to represent a global property
• system signature of original control style of
  system
• Global property changed by reconfiguring its
  metaclass properties
• system signature now includes augmented control
  style

5
New control style of system A
Energy Sector
Conditions
a1
a5
a4
a6
a2
a3
a7
Energy Sector
Scenario
Knowledge
Valuation Assessment
Cash Flow Projections
Analysis
a8
a9
a1. Generate on-line financial conditions
a2. Provide cash flow projections
a3. Provide valuation assessment
a4. Update on-line financial conditions update
knowledge information about market sector
Scenario Analysis-A
Scenario
Analysis-B
Energy
a5
a6
Sector
a10
a7
Knowledge-A
a11
a12
a9
a8
6
Domain analysis of dynamic system reconfiguration
7
Domain-specific example
8
Changing a global property

• System A - GP1 Control Style Constraint (gp1)
  metaobject is GP1AMetaClass
• System A - GP1 Change Property (newgp1)
  metaobject is NewGP1AMetaClass
• GP1AMetaClass mixins ClassWithInstanceMutableMet
  aObjects. SystemAOnLineControlStyleMetaObject
• NewGP1AMetaClass mixins ClassWithInstanceMutable
  MetaObjects. SystemBInteroperationMetaObject
• gp1 metaObject class addAllMixins (newgp1
  metaObject class mixins).
• GP1AMetaClass mixins ClassWithInstanceMutableMet
  aObjects. SystemAOnLineControlStyleMetaObject.
  SystemBInteroperationMetaObject

9
Implications

• Interpretation of continuous system evolution as
  discrete change events
• through simulation, statistics, heuristics or
  other means
• Representing a change event as global and/or
  local constraints
• includes functional and non-functional properties
• Reconciling change properties with system
  properties
• including reformulation of change constraints in
  a manner that ensures there is a resolution and
  the use of a SAT (satisfiability) solver
• Assessing the impact of change to ensure system
  consistency
• system may change significantly during assessment

10
Future work

• Investigating the application of change types and
  associated system integrity characteristics
• including the preferred ordering for feasibility,
  efficiency, or other reasons
• investigating dataflow dependency analysis (and
  like) techniques
• Investigating different levels of control
• in the context of decentralized software
  evolution
• in support of load-balancing, roll-back,
  fault-tolerance, and the systems life cycle
• Refining the domain model and the simulator
  within an industrial context
• including their automatic transformation
• dynamically adjusting the set of mixins
• the use of traits

11
Extra Slides
12
Case study Integration of two financial
prediction systems

• System As clients need shorter-term preferred
  stock values predictions
• infer shorter-term values based on on-line cash
  flow projections and valuation assessment
• System Bs clients need longer-term preferred
  stock values
• infer longer-term values based on off-line cash
  flow projections and valuation assessment on
  demand

13
Original control styles
14
Dynamic system reconfiguration

• Reconfiguring a running system in response to new
  requirements or circumstances
• Complex problem encompassing a broad diversity of
  needs, situations, and mechanisms
• A general reference model of dynamic change has
  been defined
• Enables a comprehensive and systematic treatment
  of the problem

15
System signature

• Behavioral signature
• service to service protocol dependencies
• operation to required service dependencies
• operation to provided service dependencies
• operation to operation dependencies
• operation to state element dependencies
• operation to composite component service
  dependencies
• Structural signature
• component to component dependencies
• required service to provided service dependencies

16
Change types and their relationships
17
UML class model of domain
18
Use of explicit metaclasses
19
Representing a global property

• 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 ClassWithInstanceMutableMetaOb
  jects.
• metaclass addMixin SystemAOnLineControlStyleMetaO
  bject.
• metaclassInstance metaclass new.
• gp1 metaObject metaclassInstance.

20
StandardClass

• Root class of all MetaclassTalk explicit
  metaclasses
• By subclassing it, can define new kinds of
  classes
• Can change the evaluation process by redefining
  certain methods
• Class subclass StandardClass instanceVariableNam
  es ' classVariableNames ' poolDictionaries
  ' category 'MetaclassTalk-Kernel metaclass
  StandardClass

21
Mixins

• A Mixin is a subclass builder.
• Allows building different subclasses that extend
  different superclasses in the same way
• StandardClass subclass Mixin instanceVariableNam
  es 'createdClasses classVariableNames '
  poolDictionaries ' category 'MetaclassTalk-Mixi
  n Based Composition metaclass MixinClass

22
Using mixins

• SystemAOnLineControlStyleMetaObject is a mixin
  with instance variable systemSignatureForSystemAO
  nLineControl.
• Implements a standardized protocol that is used
  to set up systemSignatureForSystemAOnLineControl
  .
• systemSignatureForSystemAOnLineControl is an
  instance of System Signature
• represents relevant behavioral and structural
  dependencies.
• Mixin named SystemAOnLineControlStyleMetaObject
  instanceVariables 'systemSignatureForSystemAOnLin
  eControl category 'Dynamic Reconfiguration-Mixi
  ns

23
MixinClass

• Implements mixin creation method.
• StandardClass subclass MixinClass
  instanceVariableNames ' classVariableNames '
  poolDictionaries ' category 'MetaclassTalk-Mixi
  n Based Composition metaclass StandardClass

24
Composite class

• CompositeClass inherits from an implicit subclass
  of its 'official superclass' through a set of
  mixins.
• 'official superclass' is the orginal superclass
  before adding mixins (as such it is a class that
  is not generated by mixins)
• StandardClass subclass CompositeClass
  instanceVariableNames ' classVariableNames '
  poolDictionaries ' category 'MetaclassTalk-Mixi
  n Based Composition metaclass StandardClass

25
MetaObject

• MetaObject is an object that controls the
  behavior of another object
• MetaclassTalk meta-objects controls how to
  read/write instance variables and how to handle
  message sends and reception and how to evaluate
  methods
• Object subclass MetaObject instanceVariableNames
  ' classVariableNames ' poolDictionaries '
  category 'MetaclassTalk-MetaObjects Kernel
  metaclass MetaObjectClass

26
MetaObjectClass

• Speeds up behavior of default metaobject by
  turning off IV access, IV assignment, message
  send, and method wrapping controls.
• Implements sole instance pattern via mixin.
• StandardClass subclass MetaObjectClass
  instanceVariableNames ' classVariableNames '
  poolDictionaries ' category 'MetaclassTalk-Meta
  Objects Kernel metaclass CompositeClass.
• MetaObjectClass mixins SoleInstanceClass

27
Compatibility issue

• When both inheritance and instantiation are
  explicitly and simultaneously involved,
  communication between classes and their instances
  raises the metaclass compatibility issue.
• Compatibility model makes it possible to assign
  specific properties to classes while ensuring
  metaclass compatibility
• It is composed of upwards and downwards
  capability concerns

28
Upwards and downwards compatibility
29
Compatibility model

• Two layers of metaclasses compatibility
  metaclasses and property metaclasses.
• Each class is the unique instance of a property
  metaclass. This metaclass holds class specific
  properties, i.e., properties that are not
  propagated to subclasses.
• Class methods that are involved in
  class-metaclass couplings are defined in
  compatibility metaclasses
• Compatibility metaclasses are organized in an
  inheritance hierarchy parallel to the class
  hierarchy.

30
Compatibility model