Unanticipated Software Evolution USE

1
Unanticipated Software Evolution (USE)

• Course of Software Engineering II

Stefania Ciarlo
2
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

3
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

4
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

5
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
6
S-systems
Real world

• Systems that are formally defined and derivable
  from a specification
• Unlikely to change

Problem
Reqts spec
System
Information
7
P-systems
Real world

• System that are based on an abstraction of a
  problem rather than a completely defined
  specification
• Ex play chess program may be completely
  defined in terms of the rules of chess
• Subject to incremental change

Problem
Abstraction
Reqts spec
System
Information
8
E-systems
Real world
Problem

• Systems that are embedded in the real world and
  change as the world changes
• The system has become a part of the world it
  models
• Ex air-traffic control, stock control..
• Subject to constant change

Abstraction
Reqts spec
System
Information
9
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

10
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

11
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

12
Unanticipated Changes

• New hardware
• New operating system
• New software configurations
• New standards

• Technological
• Sociological

• New domains
• New business practices
• New process and regulations
• New users

Examples of unexpected changes company mergers,
Euro
13
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

14
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

15
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

16
Configuration Management

• Identify, organize and control software changes
  in order to maximize productivity and minimize
  errors

17
Requirement traceability

• When changes are needed is important to determine
  what other requirements may be affected by a
  particular change
• Is the ability to describe and follow the life of
  a requirement, in both a forward and backward
  direction
• If used, offer considerable benefits for a
  development project
• .

18
Requirement traceability

• Allows
• Easily identify the impact of changes
• Team members to see the scope of a change
• Verifying the adding of features for which
  requirements do not exist

19
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

20
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
21
Initial development

• The first version of software is developed to
  satisfy initial requirements
• Software architecture is established
• Likely to persist throught the rest of the life
  of program
• Programming team acquires the knowledge of
• Application domain, user requirements, role of
  the application in business process, operating
  environment

22
Evolution

• Iterative addition, modification, deletion of
  software functionality
• Substantial changes are made on the software
• Due to
• Learning process of the software team
• Customer require additional functionality
• Market preassure need to match features of the
  competitors product
• Legislative change
• Changes in business practices or operating
  environment

23
Servicing

• Architectural integrity or the expertise of the
  architects are missing
• The software is no longer easily evolved
• The software is treated as a black box and the
  changes are implemented as wrappers

24
Phase-out

• The system
• May be in production
• Is becoming increasily outdated
• Its users must work around deficiences more and
  more often
• Its owners seek to generate benefit for its use
  for as long as possible
• It is difficult to return from here to the stage
  of servicing

25
Close-down

• The software use is disconnected
• Current life of successful software 15 years
• The users are directed towards a replacement

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

27
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

28
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

29
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

30
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

31
The TAILOR Project 2/4

• Gives special attention to

• Applicability to black-box components

How can be software changed when there is no
access to its source code?

• Applicability at run time

How can programs be changed without stopping them?
32
The TAILOR Project 3/4

• Independent extensibility

How can changes to software be developed
indipendently and use jointly, without having
to anticipate the joint use of these changes?
33
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

34
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

35
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

36
Delegation 2/4
Original
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

37
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

38
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

39
Darwin

• Sir Charles Darwin founded the theory about the
  evolution of species by mutation and natural
  selection
• The hope of this project is to contribute the
  evolution of two species of object-oriented
  languages(class-based and protoype-based) to one
  that will be better adapted to the struggle for
  survival in the computer industry

40
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

41
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

42
Dynamic Object Replacement
1/2

• Redirect a set of incoming references of the old
  component to its new version
• Problems
• Its 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

43
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..)

44
Gilguls 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

45
Gilguls model 2/2
46
Comparand Assignment
Comparison of Objects means the comparison of
their comparands
a.comparand b.comparand
47
Reference Assignment 1/3

• Is introduced to enable the replacement of
  objects
• It can be applied to class and interface

48
Reference Assignment 2/3
Old Object

• The expression ab lets the referent of a refer
  to the object b without changing any references
• This means that all other variables wich holds
  the same reference as a refer to the object b, too

a
b
49
Reference Assignment 3/3
Old Object
Result of a b
a
b
New Object
50
Gilguls results

• Currently a compiler and runtime systems for
  Gilgul is being developed at the University of
  Bonn

51
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

52
JMangler 2/2

• Allows a wide range of code and interface
  transformations
• Supports multiple transformation on multiple
  classes
• 100 pure Java
• Freely available

53
Why class file transformation?

• Third-party libraries are usually only deployed
  in binary formats
• Only class files transformations can capture the
  entire application

54
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

55
JManglers structure 1/2
Transformer Components
Java Class Files
Transformation Manager
Class Loader System
Composition Algorithm
Execution Engine
JMangler-Framework
Java Platform
56
JManglers structure 2/2

• Java source code is compiled to binary files in
  Class File format
• Without JMangler the JVM loads and executes
  class files directly
• If JMangler is used, transformations may be
  performed on class files before they are passed
  to the core of the Java Runtime System

57
Transformation Manager

• Is the interface between the Java Class Loader
  system and the composition algorithm

58
Composition Algorithm

• Activates and coordinates the actions of one or
  more transformer components
• Checks for conflicts between the specifies
  transformations, if there are not or they can be
  resolved automatically, it performs the
  transformations

59
Transformer Components

• Are Java classes that analyze loaded classes and
  determine which transformations are to be
  performed

60
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/proceedi
  ngs/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/f
  inalossher.pdf

61
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/publicat
  ions/Evo15.pdf
• Keith H. Bennett, Václav T. Rajlich, Software
  Maintenance and Evolution http//www.cs.ucl.ac.uk/
  staff/A.Finkelstein/fose/present/bennettpres.pdf

62
References 3/3

• Post Deployment Evolution
• The Tailor project
• http//www.javalab.cs.uni-bonn.de/research/tai
  lor/
• Günter Kniesel, Type-Safe Delegation for Run-Time
  Component Adaptation, ECOOP 99 conference paper
• http//javalab.cs.uni-bonn.de/data2/papers/darw
  in/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

63
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

64
The End