specification-based component substitutability and revision identification phd thesis (beta version)...

Specification-BasedComponent Substitutability and Revision Identification

PhD Thesis (beta version)Přemek Brada

KSI/MFF/UK + KIV/FAV/ZČU

P.Brada > PhD Thesis > Introduction

Talk overview

• Scene, Issues and Goals• Technical topics• Related work• Achievements and Conclusions


The Scene

• Components (… and modules)– black-box binary, contractually specified

interfaces (P+R), trading and assembly– Szyperski 1998

– UniCon, SOFA; EJB, CCM; Ada, Delphi

• Automation key for success– upgrade: What version? Is compatible?

P.Brada > PhD Thesis > Component Revision Identification

CDL of SOFA Component frame FAddressBook { provides: IAddressBook book; IAddressSearch search; property short maxSize; requires: /system/FileAccess files; protocol: // incopmlete, illustration purposes ?book.addPerson { !files.create? ; !files.write } ; (( ?book.clear { !files.write } | ?book.getPerson { !files.read } | ?book.addPerson { !files.write } )* | ( ?search.getPerson { !files.read } | ?search.findByName { !files.read } )*) }


The Issues & The Goals

• Component Versioning– not present; support automation

• Substitutability – manual or subtyping; spec-based in

architecture

• Link between these two areas– intuitive; formalize


The Approach

• Find aggregate structures in interface– major parts, characteristic traits,

elements

• Compare structures– diff subtyping substitutability

• Indicate differences between versions– revision identification (interface only)


Coming next …

1. Meta-model2. Component Specification

Comparison3. Revision Identification4. Substitutability Definition5. Component Meta-data

Part 1: The ENT Model

An open meta-model of component and module

interface specification

P.Brada > PhD Thesis > The ENT Model

Motivation

• Common characteristics of component (and module) interfaces– modular PLs, ADLs, MILs, CBSE– unifying vocabulary, analysis, code gen.

• Examples– Ada: type, procedure; use– UniCon: player (routine, stream); def/call– SOFA: interface, property; provided, reqd


The ENT Classification System

• Human view of interface element• Predefined facets (dimensions)

– contents = { feature, quality }– kind = { operational, data }– role = { provided, required, neutral }– arity = { single, multiple }– occurrence = { const, inst, typedef, typeref }– lifecycle = { development, assembly,

deployment, runtime }


SOFA Element Classification

frame FAddressBook { provides: IAddressBook book; IAddressSearch search; property short maxSize; requires: /system/FileAccess files; protocol: // incopmlete, illustration purposes ?book.addPerson { !files.create? ; !files.write } ; (( ?book.clear { !files.write } | ?book.getPerson { !files.read } | ?book.addPerson { !files.write } )* | ( ?search.getPerson { !files.read } | ?search.findByName { !files.read } )*) }

{feature}, {op}, {prov}, {multi}, {inst}, {dev,assem,run}

{fe}, {da}, {multi}, {inst}, {any}

{quality}, {op}, {na}, {typedef}, {dev,assem,run}


Structure of the Meta-model

• Element = atomic interface unit– (name, type, tags, inherited, metatype, classifier)

• Trait = elements with same classifier– (name, metatype, CT, E)– SOFA: “provisions”, “requirements”, “protocol”

• Category = traits fitting given classifier– (name, fK, T)– “Exports”, “Needs”, “Ties” | “Func”, “Data” | …


Traits in SOFA, CCM

• SOFA– provides/requires: feature, operational,

provided/required, multiple, instance– properties: feature, data, prov, multi, inst– protocol: quality, op, prov+req, typedef

• CCM (distinguishing dimensions)– supports, facets, receptacles: Role, Occur– attributes: (alles klar)– sinks, emitters, publishers: Arity


SOFA Element, Traits frame FAddressBook { provides: IAddressBook book; IAddressSearch search; property short maxSize; requires: /system/FileAccess files; protocol: // incopmlete, illustration purposes ?book.addPerson { !files.create? ; !files.write } ... }

name = maxSize,type = short,tags = { (access,rw) },inherited = false,metatype = property,classifier = [see above]

provides = { (book,…), (search,…) }requires = { (files,…) }properties = { (maxSize,…) }protocol = { (nil, “?book.addPerson …”) }


Applications of the Model

• Structuring interface for analyses– comparison substitutability,

versioning– search and retrieval– internal representation

• Synthesis– visual representation– code generation, crosscompiling


ENT Visual Representation

Part 2: Analysing Specification Differences

Representation of subtype relation with smaller-than-

type granularity

P.Brada > PhD Thesis > Analysing Specification Differences

Motivation

• Comparison at meta-model level will lead to wider applicability – component model features– frameworks– specification languages

• Support automation in subsequent uses

• Approach: subtyping on ENT structures– subtype can be substituted for supertype


Element Comparison

• ei subsumes ej (ei >ej) iff– names equal– ei tags subtypes of ej tags– ei type subtype of ej type

• Plus equality, incomparability ()(maxSize, short,…) > (maxSize, long, …)(cnt,int,{(access,rw)},…) > (cnt,int,{(access,ro)},…)struct { string name; int age; } > struct { string name; }struct { string name; int age; } struct {string name; Date age; }


Comparison of Traits, Categories, and

Components• Subtyping on ENT aggregates• Traits: ti subsumes tj iff

– names equal– for all elements in tj : ei,x subsumes ej,x

• Categories: Ki subsumes Kj iff– for all traits in Kj : ti,x subsumes tj,x

• Component: Ci subsumes Cj iff– Ei > Ej Ni < Nj Ti /Names(Cj ) > Tj


Difference Classification

• Simple representation of subtyping in terms of differences: diff(i,j) = – equality “none”– subsumes “specialization”– inverse of subsumes “generalization”– incomparability “mutation”

• Combinations (spec + gen =

mutation)


A few notes

• Needs to define tag subtyping– readwrite < readonly etc.

• Subtyping brings pros and cons– propagates changes in referenced types– simple common changes lead to mutation– uses the Role dimension for contravariance

• Problems with type comparison– IDL/CDL rules vs. carrier language rules– binary compatibility for Java

Part 3: ComponentRevision Identification

Straightforward revision numbering scheme

amendable to automated generation and use


Motivation

• Bad state of practice– component versioning rudimentary– in longer term it will be badly needed– we want to provide automated

versioning

• Relate to substitutability– downstream revision is usually upgrade– parts of interface play different role– we want to formalize this intuition


Foundations

• Configuration management– terms: branch, revision, variant, configuration

• Detecting version differences – component comparison using ENT model

• Specification-based Revision Data– (r1, …, rN) of components Cc, Cr

– each ri related to interface spec part

– ri,r = ri,c+1 iff diff(i,c,i,r) none


Revision Data Levels

• Detailed: granularity = traits– N = |Traits(C)|

• Component: granularity = E,N,T– N = 3 (fits well into

placeholders)

• Primitive: granularity = whole type– N = 1 (for data-types)


Cascaded Derivation


Penetration into Type System

• Every user-defined type versioned– inevitable: change propagation in

subtypes– inobtrusive: using primitive revision data – repository support needed and feasible

• Don’t panic: technical alleviations– default revision number– computed automatically– infrastructure already in CORBA IR


SOFA Implementation

• Revision data in CDL– meta-data constructs a la .NET properties– enables versioned dependencies

• Complete version information in meta-data– see below

frame FAddressBook [ branch=trunk, @rev=4.2.1 ] { provides: IAddressBook book; requires: /system/Files#rev=2.0.0 files;}


Notes

• Complete versioning– variants– branches

• Tight integration– component identification– revision data– difference classification

Part 4: Substitutability and CompatibilityNotion of substitutability

suitable for black-box components deployed in a

context

P.Brada > PhD Thesis > Substitutability and Compatibility

Motivation

• Automated substitution desirable– application composers– end-user upgrades– remote apps and embedded devices

• Configuration consistency required– high availability applications

• Could run regression test suite, but– subtyping-based is faster, safer, …– … and requires less effort


Terms and Conditions

• Components– current (Cc), replacement (Cr)– test for substitutability before the act

• Architectures– components do not live in a vacuum– deployment environment can change

assumptions for subtyping relation


Strict Substitutability

• Standard contra-variant subtyping– components stand-alone

• Using ENT comparison:– can substitute iff Cr > Cc

– diff(Ec,Er ) { none, spec }diff(Nc,Nr ) { none, gen }diff(Tc /Names(Cr),Tr ) { none, spec }


Deployment Context

• Describes the environment of Cc

– which provided features are used– what can be used to satisfy requirements– represented as Cx = (E’, N’, T’)


Contextual Substitutability

• Compares Cr to the context• In ENT terms:

– Cr > Cx– diff(E’,Er ) { none, spec }

diff(N’ ,Nr ) { none, gen }diff(T’/Names(Cr),Tr ) { none, spec }

• Substitutability: Strict Contextual


Compatibility, Partial Substitutability

• Backward compatibility– special case of substitutability– same name, rev numbers in order

• Partial substitutability/compatibility– parts of interface not important– feature s/c: only feature elements– data s/c: only feature,data elements


SOFA Implementation

• Place in the framework– component manager asks for

substitutability before building Cr

– comparison of protocol specification may have exponential complexity

• Determining context– from architecture declaration (CDL)– from run-time information

Part 5: Component Meta-Data

Storing revision data and comparison results in a

pre-computed meta-data supports querying and saves

time

P.Brada > PhD Thesis > Component Meta-data

Motivation

• Formalize the intuitive – relation between versioning and

compatibility

• Enhance current technology– meta-data commonly used but under-

used– will benefit from formal underpinning– can help in substitutability checking


The Compatibility-Version Link

• Intuitive rule:– rev(b) > rev(a) b can substitute a– explicit only in DCE interface versioning

• Formal underpinning– target: black-box components– link between revision numbers (parts, order)

and interface compatibility (constituents, subtype)

– the ENT-based diff as common source of data provides the means


Contents of meta-data

• Concentrate on– identification– version data + revision history– base data for substitutability assessment

• Version data: – component revision data + E,N,T diff– detailed revision data + trait diff– branch ID, variant description

• Revision history:– branch ID + parent component rev ID + E,N,T

diff


Format <provider>cz.zcu.kiv</provider> <namespace /> <name>FAddressBook</name> <version> <branch>trunk</branch> <revision> <parent>3.1.1</parent> <data level="component"> <trait><name>E</name> <revnum>4</revnum> <change>spec</change></trait> <trait><name>N</name> <revnum>2</revnum> <change>spec</change></trait> <trait><name>T</name> <revnum>1</revnum> <change>none</change></trait> </data> ... </version>


Use of Meta-Data

• Revision data– check revision order, place of change

• Differences– evaluate substitutability in linear time

• Component naming information– place and find component in repository

• Corollary: globally unique id w/o UUID

Evaluation

Contributions, benefits, open issues

P.Brada > PhD Thesis > Evaluation

Related Work

• Component frameworks– Szyperski; SOFA, CCM, UniCon

• Meta-modelling– Medvidovic, Rastofer; OMG MOF, Seyler

• Substitutability– DCE, Java; Zaremski, Vallecillo,

Nierstrasz• Versioning and Meta-data

– Conradi, Larsson, Plaice; Hoek, .NET


Achievements

• Real meta-model for components– base for analyses incl. subtyping

• Substitutability in context• Revision identification

– well-defined relation to substitutability

• Cross-platform applicability• Ability to pre-compute, automate


Issues

• Relies on interface specification• Tight integration of revision scheme

and naming / IDL / infrastructure• Substitutability still based on

subtyping• Does not consider architectural

props


Conclusions

• It turns out that designing versioning scheme for components is not that easy– Is this the reason why the world is content with

simplistic approaches or solution by avoidance?

• More work needs to be done in fact– Variant information is crucial but interferes with

quality attributes, language mappings and IDLs need evolution to be developed to full potential, …

• We believe it’s worth the effort

The END

Comments? Hints? Criticism?Better late than never …

Thank you.

specification-based component substitutability and revision identification phd thesis (beta version)...

Documents