Module SEO01 Software Evolution

1
Module SE-O-01 Software Evolution
Topic 8 Formal Transformations
2
Contents

• What is a formal method?
• Classification of formal methods
• WSL program transformation theory
• FermaT tool
• An Integrated Evolution Framework
• Process for Evolution

3
What is a formal method in software engineering?

• Essential components
• The semantic model is a sound mathematical or
  logical structure within which all terms,
  formulae, and rules used have a precise meaning.
• The specification language is a set of notations
  that are used to describe the intended behavior
  of the system. This language must have proper
  semantics within the semantic model.
• Verification system and refinement calculi are
  sound rules that allow for the verification of
  properties and the refinement of specifications.
• Development guidelines are steps showing the use
  of the method.
• Supporting tools include tools such as a proof
  assistant, a syntax and type checker, an
  animator, and a prototyper.

4
How can formal methods be applied?

• The ways to apply formal methods
• To produce specifications that are then the basis
  for a conventional system development through
  correctness preserving refinement rules (forward
  engineering).
• To produce formal specifications, as above, to
  use as a basis against which the correctness of
  the system is verified.
• To transform a program to another semantically
  equivalent program (reengineering)

5
Contents

• What is a formal method?
• Classification of formal methods
• WSL program transformation theory
• FermaT tool
• An Integrated Evolution Framework
• Process for Evolution

6
Classification of formal methods

• model-based
• logic-based
• Algebraic
• process algebra and
• net-based (graphical).

7
Model-based approach

• A system is modeled by explicitly defining the
  states and operations that transform the system
  from one state to another. In this approach,
  there is no explicit representation of
  concurrency. Nonfunctional requirements (such as
  the temporal requirement) can be expressed in
  some cases.
• Examples Z, VDM, B-method

8
Logic-based approach

• In this approach logic is used to describe the
  system's desired properties, including the
  low-level specification, temporal, and
  probabilistic behaviors. The validity of these
  properties is achieved using the associated axiom
  system of the logic. In some cases, a subset of
  the logic can be executed (e.g., the Tempura
  system). The executable specification can then be
  used for simulation and rapid prototyping
  purposes.
• Examples include Hoare Logic, Dijkstra Weakest
  Preconditions Calculus, Temporal logic etc.

9
Logic-based approach (cont)

• The logic can be augmented with some concrete
  programming constructs to obtain what is known as
  wide-spectrum formalism. The development of
  systems in this case is achieved by a set of
  correctness-preserving refinement steps.
• Examples include TAM, the refinement calculus,
  and FermaT.

10
Algebraic approach

• In this approach, an implicit definition of
  operations is given by relating the behavior of
  different operations without defining the
  meanings of the actual states. Similar to the
  model-based approach, there is no explicit
  representation of concurrency
• Examples OBJ, Larch

11
Process Algebra Approach

• In this approach, an explicit representation of
  concurrent processes is allowed. System behavior
  is represented by constraints on all allowable
  observable communications between processes.
• Examples Communicating Sequential Processes
  (CSP), Lotos, Timed CSP.

12
Net based Approach

• Graphical notations are popular notations for
  specifying systems as they are easier to
  comprehend and, hence, more accessible to
  non-specialists. This approach uses graphical
  languages with formal semantics, which brings
  particular advantages in system development and
  reengineering.
• Examples Petri Nets, State Charts.

13
Contents

• What is a formal method?
• Classification of formal methods
• WSL program transformation theory
• FermaT tool
• An Integrated Evolution Framework
• Process for Evolution

14
WSL program transformation theory

• WSL specification is a description of the
  relationship between input and output states of
  the program however, it does not necessarily
  describe how this relationship is to be achieved.
• A spec S1 is said to be refined by another spec
  S2 (written S1 S2) if the set of possible final
  states for S2 is a subset of the final states for
  S1.
• If S1 S2 and S2 S1 then we say S1 and S2 are
  equivalent and write S1 S2.
• WSL program transformation is an operation that
  can be applied to a program spec to generate
  another equivalent program spec (provided any
  given applicability conditions are satisfied)

15
WSL Kernel Language

• Primitive statements
• Assertion P is an assertion statement that
  acts as a partial skip statement. If the formula
  P is true then the statement terminates
  immediately without changing any variables,
  otherwise it aborts.
• Guard Q is a guard statement. It always
  terminates, and enforces Q to be true at this
  point in the program without changing the values
  of any variables.
• Add variables add(x) adds the variables in x to
  the state space (if they are not already present)
  and assigns arbitrary values to them.
• Remove variables remove(y) removes the variables
  in y from the state space (if they are present).

16
WSL Kernel language

• Compound statements
• Sequence (S1 S2) executes S1 followed by S2
• Nondeterministic choice (S1 ? S2) chooses one of
  S1 or S2 for execution, the choice being made
  nondeterministically
• Recursion (µX.S1) where X is a statement
  variable (taken from a suitable set of symbols).
  The statement S1 may contain occurrences of X as
  one or more of its component statements. These
  represent recursive calls to the procedure whose
  body is S1.

17
WSL kernel language

• Example
• x x1 could be expressed in WSL as
• add(ltx'gt) x' x 1 add(ltxgt) x x'
  remove(x')
• Another example
• If B then S1 else S2 endif could be expressed as
• (B S1) ? (B S2)

18
WSL transformations

• Assertions
• Assignments
• Invariants
• Loops
• Unbounded loops
• Absorption
• False loop
• Loop doubling
• Loop inversion
• Loop unrolling
• Recursion removal

19
Example applying WSL transf.
Original program
WSL specification

• main() / DataFlex transcription /
• int morenum, filestat
• char page6, theline51, item31,
  lastitem31
• FILE fopen(), fp_in, fp_out
• fp_in fopen("DIDB","r")
• fp_out fopen("DID2INX.TXT","w")
• theline0 '\0'
• morenum 0
• filestat fscanf(fp_in," ss",page,item)
• goto inhere
• for()
• filestat fscanf(fp_in," ss",page,item)
• if (filestat EOF) goto alldone
• morenum 1
• if (strcmp(item,lastitem))
• fprintf(fp_out," s\n",theline)
• theline0 '\0' morenum 0
• inhere
• strcpy(theline,item)

20
Example applying WSL transf.

• Applying transformations
• Collapse action system
• Loop inversion
• Take outside loop
• etc.

21
Example applying WSL transf.
Transformed program
WSL specification
22
Contents

• What is a formal method?
• Classification of formal methods
• WSL program transformation theory
• FermaT tool
• An Integrated Evolution Framework
• Process for Evolution

23
FermaT Workbench

• an industrial-strength assembler reengineering
  workbench consisting of a number of integrated
  tools for program comprehension, migration, and
  reengineering.
• FermaT integrated tools
• Function catalog
• Function call graph
• Text editor
• Program flowchart
• Data catalog
• Control flow analyzer
• Data flow analyzer
• Program slicer
• Migration tools.

24
Contents

• What is a formal method?
• Classification of formal methods
• WSL program transformation theory
• FermaT tool
• An Integrated Evolution Framework
• Process for Evolution

25
Characteristics of Legacy Systems

• Typical problems- Large systems, with hundreds
  of thousands lines of code- They are written in
  legacy languages (COBOL)- They are built around
  a legacy environment - They are autonomous. If
  interfaces are present, they are often badly
  designed and haphazard at best according to
  modern criteria.
• Structure and data dependency- Under most
  circumstances composed of nested procedures and
  functions (components) which have different scope
  levels.- Global and local data dependency.

26
The Expanded Evolution Approach

• A unified approach for software evolution, based
  on characteristics of legacy systems. It is based
  on the extension of the WSL. An integrated
  framework for evolution has been constructed to
  support this approach.
• There are two reasons to support this approach-
  specifications are more compact then source code
  they are expressed in a more problem oriented
  notation and are easier for the software engineer
  to understand.- from the new specification,
  executable code can potentially be generated
  automatically or semiautomatically.

27
EWSL
28
ITL

• Most abstract and logical layer.
• Used to give a specification oriented semantics
  for TGCL and ObTAM.
• Expressions in ITL include constants, static
  variables, state variables, functions applied to
  expressions and the notation iaf, where a
  is static variable and f is predicate. This
  returns a value for a such that f(a) holds. If
  there is no such value, then returns any value
  from as range.
• Formulae in ITL include predicates p(e1,en) and
  the following compositions of formulae v-f is
  true if f(v) holds for all values of v skip
  is true over any unit interval (any s with s
  1) f1f2 holds if the interval can be
  decomposed into a prefix and suffix interval,
  such that f1 holds over the prefix and f2 over
  the suffix, or if the interval is infinite and f1
  holds for that interval f holds if the
  interval is decomposable into a finite number of
  intervals such that for each of them f holds, or
  the interval is infinite and can be decomposed
  into an infinite number of finite intervals for
  which f holds.

29
TGCL

• Based on the basic structures of Dijkstras
  guarded command languages, TGCL introduces time,
  concurrency and communications.
• Adopts the concept of shunt in TAM. Shunts are
  shared variables via which communication between
  agents is performed.
• Semantics of TGCL is given at the right side

30
ObTAM

• TAM aims to be a realistic software development
  method for real time systems. ObTAM extends TAM
  with objectoriented features.
• Semantics of ObTAM

31
CSL

• CSL is developed to enrich the statements in TGCL
  and make EWSL compatible to WSL in FermaT.
• CSL is the most concrete procedural layer of EWSL.

32
COOL

• The syntax of COOL is the same as the syntax of
  CSL without the procedural part, but with the
  following additional object-oriented portion

33
Contents

• What is a formal method?
• Classification of formal methods
• WSL program transformation theory
• FermaT tool
• An Integrated Evolution Framework
• Process for Evolution

34
A Process for Evolution

• Stages in process of evolution1. Translate
  source code into EWSL2. Restructure3.
  Abstract4. Understand with the support of a
  cognitive tool5. Reuse components6. Retarget7.
  Measure evolution

35
Implementing the Process

• Reengineering assistant (RA) semiautomatic tool
  that aims at helping reengineers through the
  whole process of reengineering legacy systems.
• Rule-based intelligent system.
• Structure of the reverse engineering part of RA

36
Translating into EWSL

• A language-specific translator takes code in the
  source language and translate it into equivalent
  EWSL. The translator does not need to be
  concerned to preserve the structure of the
  original source code or to generate efficient or
  readable EWSL.
• The primary concern is to capture the precise
  semantics of the source program.

37
Restructuring

• Once the source code has been captured in EWSL
  there are a large number of restructuring and
  simplifying transformations that can be applied
  automatically to clean up the code, unscramble
  the structure, and delete redundant code
• A class of transformations have been dedicated
  to program clustering, which groups relevant
  control statements and data definitions to form
  clusters for further restructuring.
• Software visualization is often the first step
  for understanding and deciding which program
  segments should be selected for further
  restructuring. Visualization technique have been
  employed in both the FermaT workbench and RA tool.

38
Abstracting

• To achieve correct and practical abstraction, two
  fundamental problems need to be solved1. It is
  necessary to identify what abstraction is. 2.
  How to perform the abstraction?
• Stages1. Identify all components in systems.2.
  Associate the visibility levels for each
  component.3. All data items are associated with
  the visibility level of the component in which
  they were first declared.4. Identify the central
  data structures and items of the system.5. For
  each ith-level component with igt0 do a.
  Identify all data items local to the
  component. b. Record the effect of the data item
  identified in 5.a, on any data items in levels
  Q with QltI, in a specification statement of
  EWSL, and introduce a procedure definition if
  necessary. c. Abstract away unnecessary
  implementation details and trivial functionality
  within the generated specification.

39
Classification of Abstraction

• Weakening abstraction WA
• Hiding abstraction HA
• Temporal abstraction TA
• Structural abstraction SA
• Data abstraction DA

40
Understanding With the Support of the Domain
Knowledge-Based Analysis (DKBA) Tool

• Process of acquiring knowledge from a computer
  program.
• Classification of current methods that support
  automatic program understanding- Basic
  analysis- Formal analysis- Informal reasoning
  Structurally oriented heuristic analysis -
  DKBA
• Requirements for DKBA tool- Uncertainty-
  Nonmonotonic reasoning- Quality of conclusions-
  Response time

41
Reusing Components

• Reusing components in a reengineering process
  involves using a reverse engineering method to
  expose components from the existing system and a
  library to store and manage the components.
• Process of component-based evolution

42
Steps in component-based software reengineering
process

• Mine components from the legacy systems.
• Wrap up components with well-defined interfaces.
• Store the components in a component library.
• Build new reusable components if needed.
• Develop new systems by integrating components.