The Architecture of the Software Composition System COMPOST

1
The Architecture of the Software Composition
System COMPOST

• Dr. Uwe Aßmann
• Institut für Programmstrukturen
• Universität Karlsruhe
• Andreas Ludwig Rainer Neumann

2
(No Transcript)
3
Overview

• Different Roles in the Composition Process
• How Invasive Composition is Realized in COMPOST
• Component Model Boxes and Hook Hierarchies
• Composers Hierarchies, Basic and Composite,
  Sound Composition
• Composables
• General Design Considerations
• The Architecture of COMPOST (Incremental Change
  Management)
• Packages and Views
• Tool Support and Examples
• Generics Generic Statements and Cococo
• Intrusive Data Structures
• ContractCheck Intruder
• Weaving, Script-based Composition with Inject/J
• Reengineering

4
Yesterday Roles in Composition

• Component writer
• writes application-specific boxes and declares
  hooks
• Component assembler
• assembles some boxes and composes them
• Application developer
• assembles a complete system
• End user
• shouldnt know about boxes
• Re-engineer
• must fix hooks and boxes in legacy code

5
2. How Invasive Software Composition is Realized
in COMPOST
6
Software Composition
Component Model
Composition Technique
Composition Language
7
2.1 Component Model - Box Hierarchy

• Currently Available Boxes
• Box (abstract super class)
• PackageBox
• CompilationUnitBox
• ClassBox
• Future (0.7)
• MethodBox
• AspectBox
• ComposerBox

8
Boxes have Hooks
Hooks are arbitrary program elements of the
representation of a box which are subject to
change
9
Hook Facette Classification

• Mandatory?
• Implicit/Declared
• Program Element / Set / List
• Unary/Binary/N-ary
• Syntactic Context Point or InList
• Atomic or Composite
• Context-free (matchable) or context-sensitive
  (queryable)

10
2.1.1. Classes of Implicit Hooks

• Method Level
• Entry/Exit
• Statements
• Parameters
• Class Level
• Members
• Constructors
• Methods
• SuperClass
• CompilationUnit Level
• Imports
• Classes
• PublicClass
• ComposeMethods

• Package Level
• CompositionClasses

11
2.1.2 Classes of Declared Hooks

• Method Level
• Generic Statement
• Class Level
• Generic Type
• Generic Identifier
• Package Level (Future)
• Class
• CompositionClass

12
Box and Hook Hierarchy
Composable
Box
Hook
ClassesBox
ClassBox
PointHook
ListHook
PointInListHook
Statements
CUBox
PackageBox
Classes
Methods
13
Declaration of hooks

• NO Language Extensions (keywords..)
• Standardized Names
• Comment Tags

Class Set extends genericXSuperClass class
Set / _at_superClass / / _at_pre .../ / _at_post
/ / _at_restr /
14
Generics A Generic List
15
Composables

• Composables abstract boxes and hooks
• Many composers are applicable on boxes and hooks
• If composers are applied to boxes, they look for
  the hooks themselves (i.e. hooks are common sense)

hook.extend(Value) classBox.extend(Value)
16
2.3 Composition Technique
17
(No Transcript)
18
Calling Composers

• Upper Level Via the functional interface
• hook.bind(Value)
• Composer.connect(hook1, hook2)
• Lower level Creating command-objects
• Composer c1 createComposer(...)
• compositionSystem.execute()

19
Composition Interface
Implicit Hooks
AST direct
20
C
C
C2
C1
C3
21
Basic Unary Composers

• composer.execute/undo
• Hidden behind hook interfaces
• hook.Bind(Value)
• hook.Extend(Value)
• hook.append
• hook.prepend
• hook.wrap
• hook.unbind
• box.encapsulate (fut.)
• type-specific basic composers
• bindGenericType
• bindGenericIdentifier

22
Complex Composers (0.6..)

• Refactorings (AST)
• Connector (Composition Interface)
• Coordinator (imposes control flow, Composition
  Interface)
• Pattern
• Weaver
• Hookifier (transform implicit hooks to declared
  ones)
• Portifiers

23
Brother
Sister
composer
Composer
Arg 1
Arg 2
Brother
Sister
Composer
Child
Args
24
Sound Composition

• Compositions are sound if
• they are side-effect free
• they extend feature groups Stata/Guttag95
• mix orthogonal code (without dependencies)
  Aßmann98 LambdaN-Kalkül, Dami 97
• mix in code which is only flow dependent on the
  old code
• All these criteria can be checked (by program
  analysis) (1.0)

25
2.3 The Composition Language
26
The composition steps within a COMPOST
composition program

• Read components
• parse them into an AST/ASG in the meta model
• Hook Identification
• Apply composers
• transform hooks
• bind replace hook by code
• extend attach more code to the hook
• check syntax and possibly semantics
• adapt externally generate glue code
• (Language normalization)
• Pretty print modified components and glue code
• Compile system

27
Composition on Box Level
28
Compositions as Static Meta-programs
Client.coc (Javahooks)
Server.coc (Javahooks)
Composition Program in Java and COMPOST
Composition/ Configuration
Client.java
Server.java
Glue.java
Compiler
Compilation
29
Meta- Composition Level
Cococo, the COMPOST composition compiler
Generates
Composition Language
Composition Language Level
Composition Technique for Composition Recipes
Composition Language for Composition Recipes
Component Model of Composition Language
Composition System
Composition System Level
Composition Technique Composers Reified
Composition Recipe Java Programs
Component Model Boxes, Hooks Reified
30
Compose Classes and Methods

• Compose Classes
• Special classes which are evaluated at compile
  time
• Marked by ...Maker
• Found and executed by cococo
• Compose Methods
• Special methods which are evaluated at compile
  time
• Marked by ...compose
• Found, extracted, and executed by cococo

31
compost
list
composition
ListMaker
MyClass1
hook
MyClass2
compose
HookMaker
MyClass1
MyClass1
compose
32
(No Transcript)
33
X.coc (JavaHooks)
CompositionProgram.coc (JavaHooks)
Cococo-Extractor extracts compose methods
CompositionProgram.java
Java Compiler
Cococo Composition/ Configuration
CompositionProgram.class
Set.java
Run compose methods
Java Compiler
Compilation
34
Composition Programs Simplify Software Process
Management

• Global configuration of architecture in
  Composition Classes
• standard version management
• standard software process tooling
• make as driver program
• configuration tools
• Compose methods allows inlined architecture, such
  as generics or inheritance
• Local configuration of single composers
• If-control structures configure (replace ifdefs)

35
The Architecture of COMPOST
36
Source Code Hygiene

• Important for incremental software development
  with automated transformations
• Obtained by a smart Pretty-Printer
• reformat only the new parts
• formatting style can be customized

37
Java Program Model
38
Services and ServiceConfigurations

• Services encapsulate the functionality
• source file handling
• typing ....
• Not all services are required for all application
  areas
• configure only necessary services
• ServiceConfiguration (main system class)
• DefaultServiceConfiguration (parsing,
  pretty-printing)
• CrossReferenceServiceConfiguration (plus
  semantics and cross-referencing, def-use)
• CompositionSystem (parsing, printing, boxes,
  hooks, composer meta-model)

39
(No Transcript)
40
(No Transcript)
41
(No Transcript)
42
Service Configurations byViews (0.7)
43
ltltpackagegtgt
CompositionSystem
Model
ChangeHistory
ltltaspectgtgt
BoxAspect
NameService
TypeService
SourceFile Repository
CrossReferencer Service
ltltaspectgtgt
Persistence Aspect
ltltaspectgtgt
ltltpackagegtgt
Parallelism Aspect
XX Aspect
44
COMPOST SourceFile View
hasSourceFile
COMPOST Box View
COMPOST main package (IR, parser)
hasComponent
hasIR
hasType
COMPOST Type View
hasUse
45
COMPOST main package (IR, parser)
COMPOST Component View
members
COMPOST main package (IR, parser)
members
members
hash table
COMPOST Component View
members
COMPOST main package (IR, parser)
COMPOST Component View
hash table
46
Adding Foreign Parsers
47
Language-specific Model
Compatible
Mappable
Fitting
Non-Mappable
Common Model
48
CLanguageModel
Fitting
Compatible
Non-Mappable
Mappable
ModelElement
BaseTypes
Package C-(Project)
ValueTypes
Compilation Unit (File)
CProgramElement
Matrices
Statements
Type
Struct (Class)
Addressoperations
MemoryAllocation
Object (Pointer)
sizeof
Method (Procedure)
Relational Expressions
Arithmetic Expressions
49
COMPOST Core
C Parser
Common IR
Common IR
C-IR
Fitting
Mappable
Compatible
Non-Mappable
50
Applications
51
Tool Support

• Semantic Analysis (name and type service)
• Cross-referencing (def-use service)
• AST-Collectors, File-Collectors
• cococo, the COMPOST composition compiler
• hookshow, the hook lister
• liveness-Analyzer, PackageMover, AutoDoc-Tool
• ContractCheck-Intruder
• SRF-Generator for GOOSE Reengineering Tool Set
• Script-based compositions with Inject/J
• Experimenting with wizards Embedding of
  meta-programs into IDE as wizards
• Experimental Graph rewrite tool OPTIMIX
  generates weavers for COMPOST

52
SRF-Generator for Reengineering

• O. Ciupke GOOSE from the FAMOOS Project is a
  tool suite for reengeneering program queries
  (problem detection).
• GOOSE starts from a simple relational format
  (SRF) which is extracted from the program
• GOOSE queries detect design problems in OO code
• Generate visualizations of the graphs in VCG and
  other tools
• COMPOST has been used as generator for SRF,
  already for large class libraries
• Pictures off-line

53
Generics for Languages without Generics
54
A Generic List Module with Hooks
55
Generic Statements (cococo template)
56
Intrusive Data Structures

• Embedding of relation into classes and structs
• Allows faster navigation algorithms
• Avoid the object schizophrenia problem for graph
  data

57
Contract Check Intruder

• Problemrun-time errors in oo systems by
  polymorphic non-conformance
• Example
• An acyclic graph is a graph
• Add an edge to the graph
• The graph may become cyclic!
• Goal (R. Neumann)
• Avoid runtime errors!

58
Problem
void p(A a) a.m()
class A abstract void m()
Framework
class B extends A / _at_restricted /
void m()
my_code p(z)
Critical Call
RestrictedMethod
59
Problem Care

• Find critical calls automatically by analysis of
  tags and uses
• Analyse whether instrumentation necessary
• Instrument with assertions
• Semi-Automized by contract check intruder

60
Automized Aspect Weaving with Graph Rewriting
61
GRS - Basics
Rewrite Rule
Derivation
Host Graph
Redex
62
Component Aspect Graphs
63
Example

• Task prepend statements to method entries

class ClassDeclaration (nameName)
class ClassDeclaration (nameName)
aspectStatement Statement (placename)
aspectStatement Statement (placename)
methods
methods
method MethodDeclaration
method MethodDeclaration
entry
64
Example (2)
methods
entry
methods
methods
entry
methods
methods
65
Comparison
System
terminating
deterministic
aspect graph
Aspect Fragment Matching
Aspect-relating
yes
yes
yes
Aspect-additive
if exhaustive
yes
yes
Component-modifying
if exhaustive
usually not
yes
Aspects in Rules
depends
depends
no
Intra-Component
depends
depends
no
66
Aspect Weaving is similar toProgram Optimization

• Graph rewriting can express many program
  optimizations uniformly Aßm96.
• Optimizations transform programs.
• Weavers transform programs.
• Hope
• Graph rewriting can be used for reengineering
  and hookification

67
Generating Tools from Rewrite Specification
Program data weaving rules
Optimix
Component Code
generates
Weaver
Aspect Code
generates
Program
68
Script-based Composition with Inject/J

• T. Genssler, V. Kuttruf
• Idea Abstract composition programs in scripts
  which match implicit hooks with wildcards
• Provide navigation support for the AST
• Map to COMPOST
• Similar to Aspect/J, although more flexible in
  compositions
• Demo offline

69
THE END

• Its not perfect, but starts to work....
• Lets discuss about your needs.

70
Decomposition and SawMill Linux

• How to use COMPOSTs features for SawMill Linux?
• Views/Extensibility. Mixin new features at
  implicit or declared hooks
• What are the boxes and aspects?
• Architecture Where are the connectors?
• Hookification How to support?
• Memorizing code positions of declared hooks, in
  order to introduce them again when versions
  evolve (graph analysis?)
• Look at COMPOST itself and its tools

71
Advantages

• Composers are standard programs
• Standard tooling available
• Standard software process management
• Open systems
• Scalable systems by simple configuration
• Composers are boxes
• can be composed themselves
• uniformity
• connector reuse from libraries
• Composition programs
• are component-oriented
• can be composed themselves

72
Subject-orientierted Programming
EJB
Aspect-oriented Programming
Invasive Composition
Architectural languages
Corba DCOM Beans
SOP
lN-calculus
Template MP
Standard Composition
73
3) Reengineering

• Connector Meta-Programs Deweave
• match weaved code and replace it
• transform old code into new versions
• Identify and Introduce Ports
• match weaved code and replace it by ports
• General reengineering operations
• refactoring

74
Port Identification

• All method calls can be reduced to ports
• pack all parameters into a convenience class
• Declared methods are provided ports
• Additional join points exist, such as
• method body entries and exits
• feature and parameter declaration lists
• relevant internal states
• Ports can be identified from other patterns
• Calls to Port classes
• Calls to special methods
• Access to shared data

75
Reengineering Portifier

• Initialization phase
• Identification phase
• deweaving select a call to be replaced by the
  Observer pattern, i.e. the event-signalling code
• Transformation phase
• deweave remove weaved parts, i.e. calls
• insert port
• (weave)
• Emitting phase

76
Port Identification
77
De-/Weaving Process
Portified system modified communications
Final weaved system
78
Observifier Deweaves Callsto Ports
Hanoi
Hanoi
Hanoi
compute
compute
compute
PrintObserver
event
display
event
event
call
display
display
display
Deweaving
Weaving
79
Connectors
80
Example Observifier

• In 2 classes (subject, observer), list of ports
  in subject to replace
• Out 3 classes (subject, observer, event), where
• subject knows an observer
• ports are replaced by event notifications
• event class encapsulates the method parameters
• Typical engineering (weaving) problem
• How do we introduce the connector Observer into a
  program? How do we generate glue code?

81
Weaving Towers of Hanoi
Hanoi
compute
import java.io. public class Hanoi public
Hanoi() .. protected void compute( int n,
String s,
String t, String h ) if(n gt 1)
compute( n - 1, s, h, t ) move(s,t)
DISPLAY_PORT() if(n gt 1)
compute( n - 1, h, t, s )
Hanoi
PrintObserver
compute
display
event
82
Observified Towers
import java.io. public class Hanoi extends
java.util.Observable implements
java.util.Observer public Hanoi()
addObserver( new PrintObserver() ) protected
void compute( int n, String s, String t, String h
) if(n gt 1) compute( n - 1, s, h, t
) move(s,t) setChanged()
notifyObservers( new displayPack( s, t ) )
if(n gt 1) compute( n - 1, h, t, s )

import java.io. public class Hanoi public
Hanoi() .. protected void compute( int n,
String s, String t, String h ) if(n gt 1)
compute( n - 1, s, h, t )
move(s,t) DISPLAYPORT() if(n gt 1)
compute( n - 1, h, t, s )
83
(No Transcript)
84
Phases Observifier Connector

• Initialization phase
• make classes accessible to COMPOST MOP, i.e. read
  in classes
• Identification phase
• identifiy port declarations
• pattern match places in code where to weave
• Transformation phase
• deweave remove weaved parts
• weave allocate gluecode for events, adapt
  interfaces as Observable
• Emitting phase
• Pretty print modified classes and glue code

85
Phases Towers of Hanoi
ObservifierDriver.java
Glue code
Hanoi.java
COMPOST Observifier
Java
MOP
Observified code
Hanoi.java-1
Parameter packer
PrintObserver
Java compiler
86
(No Transcript)