‘Active’ Models: A possible approach to the integration of objective and subjective process models Brian Warboys School of Computer Science University of Manchester UK http://www.cs.man.ac.uk/ipg/
[email protected]
May 2005
SPW2005 Beijing
Slide 1
Presentation Outline
• • • •
The problem of Integration The need for active systems Complex and Dynamic Active Systems A technology example – The ArchWare Approach - European Union project between IPG and the Universities of St Andrews (Ron Morrison) and Savoie at Annecy (Flavio Oquendo) – Some example meta-behaviours
May 2005
SPW2005 Beijing
Slide 2
The problem of integration • Objective and Subjective Process Models • Macro and micro processes .. or team rules and personal rules – The process that should be followed – The process that is actually followed • Explicit and tacit knowledge • Emergent behaviour • A paradigm of building systems by starting with outline, abstract specifications and then adding detail by evolving this specification - a process that never stops!
May 2005
SPW2005 Beijing
Slide 3
The Real Problem: Co-evolution • The relationship between business/society and software can be viewed as co-evolution:
– Business/social changes create pressures on the software to evolve, and at the same time software changes create pressures on the business/society to evolve
Environment Stimulated Change
Evolving Software System
Evolving Business
Environment Stimulated Change
Shared Phenomena May 2005
SPW2005 Beijing
Slide 4
On emergent behaviour • Modern Complex and Dynamic Systems are generally subject to ‘emergent’ behaviour. • Classical S/W Engineering has mostly adopted a component engineering style so ‘emergent’ behaviour has either been: – ignored -> legacy software – partially addressed - parameterisation, inheritance … – treated as a connectivity problem - plugs/sockets to soften the effects of misfitting componentry • Impression is that the problem of ‘emergent’ behaviour is a trait to be suppressed. • Our view is that it is not only inevitable but is a property that should be recognised and exploited.
May 2005
SPW2005 Beijing
Slide 5
An analysis - Traditional S/W Engineering • Software Engineering has suffered from its inception from the curse of modern scientific reductionism. • It adopts a reductionist approach: – Partly because this was its legacy from numerical computation – in order to develop ‘products’ which have predictable characteristics. • Reuse approaches generally and modern quality models, whilst enabling better and reusable development approaches, essentially strengthen this reductionist approach.
May 2005
SPW2005 Beijing
Slide 6
A way forward? • For many reasons we are seeking to develop ‘products’ which cannot be understood in such reductionist ways. • Thus we must seek to create a new ‘engineering’ approach which accepts the non-reductionist scenario, whilst retaining the constructive and responsible characteristics of ‘engineering’. • The challenge is to create the means of doing this in the context of all the properties associated with a ‘new’ order of complexity. – Unknowable, emergent, dynamic, higher order etc etc • This has some resonance with Autonomic Computing Initiatives and also has roots in classical Cybernetics
May 2005
SPW2005 Beijing
Slide 7
An appropriate development paradigm? • Not one grounded in reductionist systems – optimised in a fixed and well understood environment • but one based on complex adaptive systems – made to ‘work’ in an environment that is subject to emergent behaviour. • Thus it is essential to understand: – the meta-behaviours, that is behaviours about behaviours »Learning to learn … guidelines for tailoring – the operational behaviours – and, most importantly, their constant interaction, as a process of evolution and change. May 2005
SPW2005 Beijing
Slide 8
An appropriate development paradigm? Thus: • Systems must have ways of dynamically changing themselves. • In general such systems necessarily will include people – both the ‘engineers’ and the ‘users’. • The paradigm is therefore one of inclusion.
May 2005
SPW2005 Beijing
Slide 9
Our efforts to date • Our efforts to date have been to develop ways of describing such complex systems in formal ways - formal in the sense of being expressible as a computer system related to the other system elements (eg human, social, business .. etc). • Fundamental to a new approach is the notion of the development of systems that reflect a fusion of ‘eternal’ design and architectures for handling dynamic evolution. • The goal is to embrace and indeed exploit the emergent properties that arise when a system is placed within its social context.
May 2005
SPW2005 Beijing
Slide 10
The implications • We begin by describing our computer systems as enacting models of behaviours in complex systems (rather like simulations). • However the inclusive nature of development and the context for development extends this to a view that such models are part of the complex system itself. – The models ARE the system. • We can use this insight to develop the notion of reuse ‘metabehaviours’. • Such ‘meta-behaviours’ allow us to handle emergence and learning as multilevel ideas in systems.
May 2005
SPW2005 Beijing
Slide 11
The result • In particular we note the importance of meta-behaviours as a part of the system as a whole. • This viewpoint means that one general rule about ‘emergent engineering’ is that it is adaptive. • The ‘engineer’ is part of the emergent behaviour rather than , as in traditional systems, external to it - indeed the end-user is a valid ‘engineer’ in such a system.
May 2005
SPW2005 Beijing
Slide 12
A technology example • The ArchWare project – An EU funded project – Technology produced by the Universities of Manchester, St Andrews and Savoie – Exploited by Thesame (Agile process systems for SMEs) in France and Engineering (Federated Knowledge Management System) in Italy – A 3.5 year project which finishes in the middle of 2005
May 2005
SPW2005 Beijing
Slide 13
Addressing Co-evolution • Our objective is to – make enough of the software evolve at the correct rate to support the business – reduce the costs of achieving such flexibility – make such evolution as safe as possible • Also recall that the evolving software, especially when stimulated from outside of the system, also stimulates business change – implies management of co-evolution
May 2005
SPW2005 Beijing
Slide 14
Active Architectures for Co-evolution • Software architectures describe systems in terms of their components and interactions between components • However in order to respond to environmentally stimulated change we need more - thus we characterise an active architecture in the following way:
– An active architecture is composed of interacting active components – Each active component is itself an active architecture – Each active component is an enacting process model of some behaviour of the overall system » this idea derives from the notions of shared phenomena and change – To support this idea an active architecture needs to possess a number of properties:
May 2005
SPW2005 Beijing
Slide 15
Properties of an Active Architecture • we define an active software architecture to be one with at least the following properties: – Dynamic: the topology of the components and interactions are determined dynamically » New components and interactions may be created during execution – Updatable: the components may be replaced dynamically » Whereas dynamic evolution is additive, update evolution may be regarded as subtractive and then additive (atomically) – Decomposable: the running system may be (partially) stopped and split into its constituent components and interactions – Reflective: the specification of the components and interactions may be evolved during execution
May 2005
SPW2005 Beijing
Slide 16
A Single Computational Model • In active architectures, in order to ensure continuing compliance, the specification of the architectural model changes in lock-step with the model execution – Thus changes during execution will change the specification and changes to the specification will affect the execution – At any time in the execution of the model the specification is dynamically up-to-date • Fundamentally the specification is the computational model – However, without some special efforts, all changes are still of an a priori nature – For co-evolution we require a single computational model that can also accept change stimulus from outside and thus deal with emergent change
May 2005
SPW2005 Beijing
Slide 17
An interesting observation • In setting out to design our new process language we observed: • That our old PML, an OO language, contained two built in classes termed Roles and Interactions • These were coarse grained notions which imposed a rigid style on our models and indeed our modelling methods • We wanted a finer grain of behaviour and settled on a type language with two special types termed behaviours and connections – π-calculus notions of process and channel. • However in using this language it was clear not only that we could describe process models but process model architectures - it is thus termed ADL rather than PML
May 2005
SPW2005 Beijing
Slide 18
Support for emergent behaviour • Decomposition – takes part of an executing system and breaks it into its constituent components - ADL Decompose operator • Reification – allows introspection of a component - current state etc • Reflection – allows the changed component to be brought back into the execution domain by dynamic compilation - ADL callable compiler function • Recomposition – Takes the evolved component(s) and composes them together to form a new system - ADL Compose operator
May 2005
SPW2005 Beijing
Slide 19
The ArchWare Approach
• The ArchWare approach, as currently manifest in the EU ArchWare project, is to provide mechanisms for evolution at different layers of the system. These are: – a π-calculus based process and architecture description language (ADL) – abstractions for capturing architectural and process styles - such as the Role/Interaction models of the old PML – a methodology for constructing active systems
May 2005
SPW2005 Beijing
Slide 20
Consequences of an active architecture • The preceeding properties allow us to develop very flexible systems. • However …. • A highly undesirable characteristic of such systems is that they also allow the easy development of nonsense systems! • In order to bring order we need to rely on constraints imposed by the ‘meta-behaviours’. • However it is clearly vital that such meta-behaviours should themselves be subject to emergent behaviour, else this management (control) system does not have the same degree of complexity as the controlled system - simple cybernetic principles.
May 2005
SPW2005 Beijing
Slide 21
A meta-behaviour for Evolution • We start from the position that we wish to structure system components for co-evolution – Essentially transforming existing components as they are required to evolve • For this we regard all component as process models with members from two sets of process types: – The Produce set (P) and the Evolve set (E) – The set P is responsible for the operational behaviour of the system – The set E is responsible for the ‘fitness for purpose’ of that operational behaviour
May 2005
SPW2005 Beijing
Slide 22
P/E pair for Co-evolution An active component
c00 Environment 00
Binding mechanism Binding Rules
Evolve00
® 00 Raw00
May 2005
Produce00
SPW2005 Beijing
Widgets 00
Slide 23
Component Composition • The P/E behaviour allows components to be structured both co-operatively and hierarchically – The next slide shows two components, C00 and C01, co-operatively bound at level 0, together with a co-evolution component, evolve10, to form the hierarchical level 1 component, C10 – The binding mechanism Ù must accommodate both composition and decomposition of the components, and along with the rules ® is itself evolvable
May 2005
SPW2005 Beijing
Slide 24
Composition of P/E pairs c10 Environment 10
Evolve 10
® 10 Produce 10
c00 Environment00
c01 Environment01
Evolve00
Evolve01
Raw10
Widgets 10
® 00 Raw00
May 2005
Produce00
® 01 Widgets00
SPW2005 Beijing
Raw01
Produce01
Widgets01
Slide 25
The Bootstrap null
Enact the evolve process to produce the production process
c00 ® Pevolve
Produce the Evolve Process
May 2005
Evolve00
Initially Empty
® 00 Raw00
Produce00
SPW2005 Beijing
Widgets 00
Slide 26
Grounding the model - COTS
c00 Environment
manual
Raw
Widgets
COTS
May 2005
SPW2005 Beijing
Slide 27
Granularity of Co-evolution • Within the parts of the system written in the ADL, the granularity of components can be expressed as any data type in the Universe of Discourse – This can be very small or as large as the designer wishes – The size of the component can also be changed by reflection • With regard to COTS, the granularity of change depends on the a priori structuring of the COTS – Where the COTS can be specified in parts then the evolution can operate on these parts
May 2005
SPW2005 Beijing
Slide 28
A meta-behaviour for system development • Derived from an analysis of Software Engineering methods • Supports two default refinement ‘active component’ Produce processes for system development – The Refine process - creates a child of the original component. The child is a more concrete ‘vertical’ refinement of its parent. – The Partition process - creates a child of the original component. The child is a part explosion of its parent by ‘horizontal’ refinement.
May 2005
SPW2005 Beijing
Slide 29
The Tower meta-behaviour Refine
Evolve00 Evolve00
® 00
Evolve00
® 00
® 00
Produce00 Produce00
Evolve00
® 00 Produce00
Produce00
Partition May 2005
SPW2005 Beijing
Slide 30
Organising things • The Tower behaviour is an example of one structuring of active components - to achieve, in that case, a software development environment. • In order to organise any arbitrary structuring of active components to achieve a viable active system we need to introduce a new pattern to control the connectivity of the active components. • It is the access rights to connections, and to the metaprocesses which control these rights, which determine the organisational approach to system change. • We introduce another meta-behaviour, termed Spheres (after Spheres of Influence) to allow an active approach to access permissions.
May 2005
SPW2005 Beijing
Slide 31
Spheres: A behaviour for the control of bindings A Sphere containing its own Meta-process - autonomous control Access to the Sphere implies the user can evolve the Produce process
Evolve
® Produce
May 2005
SPW2005 Beijing
Slide 32
Spheres continued A new Sphere whose Meta-process is held within the context of the original process - autocratic control To recursively repeat this pattern leads to hierarchical control structures
Evolve Evolve
® Produce
May 2005
SPW2005 Beijing
® Produce
Slide 33
Spheres continued A new Sphere which contains all the Meta-processes of all the Spheres - constitutional locking - change is by consent of all of the Meta-processes
E E
®
E
® P
Produce
May 2005
®
Produce
SPW2005 Beijing
Slide 34
Conclusions • Current software systems don’t work • We are in denial – Social systems are emergent in nature – Software systems are not • The technology exists … well nearly
Questions?
May 2005
SPW2005 Beijing
Slide 35
