Get documents about "Unanticipated Software Evolution
Shared by: HC120831154037
-
Stats
- views:
- 3
- posted:
- 8/31/2012
- language:
- simple
- pages:
- 51
Document Sample
Unanticipated Software
Evolution (USE)
Course of Software Engineering II
Stefania Ciarlo
Plan of the talk
Software Evolution
How software system can change
Strategies for change
Unanticipated changes
Ways to deal with change
The staged model of software lifecycle
Post deployment evolution
The Taylor Project
2
Software Evolution 1/2
Is the process of software change, most often
change in software requirements
Software changeability (evolvability) is one of
the essential properties of software
Evolvable software can handle unanticipated
changes
3
Software Evolution 2/2
Goals for research: make software changes
EASY, SAFE and INEXPENSIVE
Incorporate new and unexpected
requirements quickly and easy
Provide hooks for future evolution
4
How software systems can
change
Classification of software systems in terms of
how they may change and how likely they are
to change
S-systems
P-systems
E-systems
[M.M.Lehman 1980]
5
S-systems
Real world
Systems that are formally
defined and derivable Problem
from a specification
Reqts spec
Unlikely to change
System
Information
6
P-systems Real world
System that are based on an Problem
abstraction of a problem rather
than a completely defined
specification Abstraction
Ex: play chess: program may be Reqts spec
completely defined in terms of the
rules of chess
System
Subject to incremental change
Information
7
Real world
E-systems
Problem
Systems that are embedded
in the real world and change
as the world changes Abstraction
The system has become a Reqts spec
part of the world it models
Ex: air-traffic control, stock
control.. System
Subject to constant
change Information
8
Strategies for change 1/3
Anticipate changes
Build the software in such a way that the changes
will be localized inside components
Parametrization
Localize change within one class
When a change is localized within a
component, it is easier, safe and inexpensive
9
Strategies for change 2/3
Not all changes in the software can be
anticipated
70% of the requirements were predicted in
advance and the remaining requirements were
discovered during development
Changes during software maintenance are
even less accurately predicted
10
Strategies for change 3/3
Current software trend is the development of
ever increasing complexity and heterogeneity
and this will make accurate prediction of
change even harder
These application will be exposed to many
unanticipated changes during their lifetime
Better support for unanticipated changes
is an important research goal
11
Unanticipated Changes
New hardware
Technological New operating system
New software configurations
New standards
New domains
Sociological New business practices
New process and regulations
New users
Examples of unexpected changes: company mergers, Euro
12
Why are they unanticipated?
Impossibility to state how all these factor will co-
evolve over time
Impossibility to anticipate all uses to which a
piece of software will be put in the future and in
what contexts will be used
As people use software, and as their businesses,
domains and available technologies change, they
find different uses for the software and they
impose new requirements on it
13
Ways to deal with change
Software maintenance
The general process of changing a system once it has
been delivered
Architectural transformation
Modifying the system architecture to a distributed
configuration
Software re-engineering
Improving the system structure to reduce the cost of
future maintenance
14
Software Maintenance
IEEE definition
“The process of modifying a software system
or component after delivery to correct faults,
improve performance or other attributes, or
adapt to a changed environment”
Key techniques
Configuration management and change control
Requirement traceability and impact analysis
15
The staged model of the
software lifecycle 1/2
Conceived by
Keith H. Bennett : member of the Research
Institute for Software Evolution, University of
Durham, UK
Václav T.Rajlich : Professor at Department of
Computer Science, Wayne State University, Detroit
Related paper was published in July 2000 by
IEEE Computer
Unlike the conventional view of the software
lifecycle it looks the software lifecycle from
the perspective of software evolution
19
The staged model of software
lifecycle 2/2
Initial development
evolution changes
first running version
Evolution
servicing patches
loss of evolvability
Servicing
servicing discontinued
Phase-out
switch-off
Close-down 20
Post deployment evolution 1/4
The application has been developed
We have to adapt it to new requirements
Particular attention to dynamic adaptation
(modify components while they are active)
26
Post deployment evolution 2/4
Known approaches can be classified according to
The time when adaptation is performed
Compile-time(Static)
Load-time
Run-time (Dynamic)
Their ability to adapt whole component types or
individual component instances
Global
Selective
27
Post deployment evolution 3/4
The applied techniques
Code-modification-based
Its essence is the replacement of an existing
class by a new version of that class
Is applicable at compile-time or at load-time
but has only limited application at run-time
because in a running system the instances of the
class to be replaced already exist and are being
used
28
Post deployment evolution 4/4
Wrapper-based
When active components can neither be directly
modified nor unloaded from a running system, we
are faced with the problem to change their
behaviour solely by adding more components
This leads us to the use of wrappers. A wrapper is
interposed between a component and each of its
clients that should perceive some new behaviour
Enables unanticipated dynamic selected
adaptation
29
The TAILOR Project 1/4
Developed at University of Bonn, Germany
Goal: conceive and implements programming
languages and runtime systems that allow for
unanticipated software evolution
Enables unanticipated adaptation of Object-
Oriented Systems
30
The TAILOR Project 2/4
Gives special attention to
1. Applicability to black-box components
How can be software Delegation
changed when there is
no access to its source
code?
2. Applicability at run time
How can programs be Dynamic
changed without Object
stopping them? Replacement
31
The TAILOR Project 3/4
3. Independent extensibility
How can changes to software be
developed indipendently and use
No general answer
jointly, without having to to this question
anticipate the joint use of these
changes?
32
The TAILOR Project 4/4
Main subprojects that provide relevant input to it:
Darwin: Unanticipated Object-based Inheritance
Developed by Günter Kniesel, University of Bonn, since 1998
Gilgul: Transmigration of Object Identity
Developed by Pascal Costanza, University of Bonn, 2001
JMangler: Load Time Adaption of Java Class Files,
Developed by Günter Kniesel, Pascal Costanza, Michael
Austermann, 2001
33
The Darwin Project
Current result of the project are:
The Darwin Model is an object model that
extends traditional class-based object-
oriented systems by type-safe object based
inheritance( also known as delegation)
The Lava language extends Java with type-
safe static and dynamic delegation according
to the Darwin Model
34
Delegation 1/4
Originally introduced by Henry Lieberman in
1986
Is the definition of objects that delegates part
of their behaviour to other objects
Enables unanticipated, dynamic, wrapper-
based component adaptation
35
Delegation 2/4
Original
delegation
Client
Adapted
As shown in the figure, a particular client can
be adapted to new requirements by
interposing a delegating wrapper object
between the client and the component
36
Delegation 3/4
May be
Static The “parent” object is initialized
at run-time but never exchanged afterwards
Dynamic Allows also later exchange of
parent objects
37
Delegation 4/4
Is a very powerfull version of inheritance
Limitation: Atomic object replacement
problem
i.e. there is no way to determine all references to one
object and replace them all in one atomic operation
It needs to be supplemented with another
technique: Transmigration of Object Identity
38
Gilgul
Is a compatible extension of Java
It introduces a new view on the concept of
object-identity
It allows for dynamic object
replacement by simultaneously rerouting a
set of references as an atomic operation
40
Object Identity
Usually combines the notions of reference
and comparison
In this approach these two notion are strictly
separated into
References, which are never compared
Comparands, which are never used as references
We can manipulate them indipendently
41
Dynamic Object Replacement
1/2
Redirect a set of incoming references of the
old component to its new version
Problems
It’s hard to ensure consistency of these
redirections
This task can be carried on only if it is possible to
completely determine the set of references on
target
42
Dynamic Object Replacement
2/2
Solution: Introduce a programming language
feature that facilitates it
The Gilgul programming language with the
reference assignment operation #= provides
a direct solution to the problem ( see later..)
43
Gilgul’s model 1/2
Object references point to an entry in an
object table which holds referents that
represent the actual objects
To able to compare objects each one is
supplemented with an attribute that stores a
so-called comparand
44
Gilgul’s model 2/2
references referents
Objects with
object table comparands 45
Comparand Assignment
Comparison of Objects means the comparison of their
comparands
a
b
a.comparand = b.comparand
46
Reference Assignment 1/3
Is introduced to enable the replacement of
objects
It can be applied to class and interface
47
Reference Assignment 2/3
Old
Object The expression a#=b lets
the referent of a refer to
the object b without
a changing any references
This means that all other
variables wich holds the
b same reference as a refer
to the object b, too
New
Object
48
Reference Assignment 3/3
Old
Object Result of a #= b
a
b
New
Object
49
Gilgul’s results
Currently a compiler and runtime systems for
Gilgul is being developed at the University of
Bonn
50
JMangler 1/2
Is a Framework disegnated for transformation
of compiled Java classes during load-time
Enables adaptation resulting from
unanticipated changes of requirements to be
applied to third party libraries and black-box
components whose source code is unavailable
51
JMangler 2/2
Allows a wide range of code and interface
transformations
Supports multiple transformation on multiple
classes
100% pure Java
Freely available
52
Why class file transformation?
Third-party libraries are usually only deployed
in binary formats
Only class files transformations can capture
the entire application
53
Why load-time transformation?
JavaClass files are loaded dinamically when
they are needed
There is no way to determine, before
runtime, which class files are used by our
application
The only point where it is possible to
determine all classes that are actually used by
a program and adapt them as needed is the
dynamic class loading process
54
JMangler’s structure 1/2
Transformer Components
Java Class Files
Class Loader
Transformation Composition
System
Manager Algorithm
Execution Engine
Java Platform JMangler-Framework
55
References 1/3
Software Evolution
Anthony Finkelstein, Maintenance and Evolution
http://www.cs.ucl.ac.uk/staff/A.Finkelstein/advmsc/16.pdf
Václav T. Rajlich, Software Evolution: A Road Map,
International Conference on Software Maintenance
2001
http://www.computer.org/proceedings/icsm/1189/11890006
.pdf
William Harrison, Harold Ossher, Peri Tarr,
Software Engineering Tools and Environments: A
Road Map, 2000
http://www.cs.ucl.ac.uk/staff/A.Finkelstein/fose/fi
nalossher.pdf
60
References 2/3
Staged Model of software lifecycle
Keith H. Bennett, Václav T. Rajlich, The staged
model of the software lifecycle: A new perspective
on software evolution, IEEE Computer, July 2000
http://www.cs.wayne.edu/~vip/publications/Evo15.pdf
Keith H. Bennett, Václav T. Rajlich, Software
Maintenance and Evolution
http://www.cs.ucl.ac.uk/staff/A.Finkelstein/fose/present/ben
nettpres.pdf
61
References 3/3
Post Deployment Evolution
The Tailor project
http://www.javalab.cs.uni-bonn.de/research/tailor/
Günter Kniesel, Type-Safe Delegation for Run-Time
Component Adaptation, ECOOP 99 conference
paper
http://javalab.cs.uni-
bonn.de/data2/papers/darwin/dca.ecoop99-revised.pdf
Pascal Costanza, Transmigration of Object Identity:
The Programming Language GILGUL, 2001
http://www.informatik.uni-bonn.de/~costanza/
gilgul_OOPSLA_poster.pdf
62
Future event
First International Workshop on Unanticipated
Software Evolution
Held in conjuction with ECOOP 2002 ,
June 10-14th 2002 in Malaga, Spain
http://informatik.uni-bonn.de/˜gk/use2002
63
The End
Unanticipated Software Evolution 64
