Specification-Based Component Substitutability and Revision Identification PhD Thesis (beta version)...
-
Upload
austen-stewart -
Category
Documents
-
view
216 -
download
0
Transcript of 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
P.Brada > PhD Thesis > Introduction
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 } )*) }
P.Brada > PhD Thesis > Introduction
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
P.Brada > PhD Thesis > Component Revision Identification
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)
P.Brada > PhD Thesis > Introduction
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
P.Brada > PhD Thesis > The ENT Model
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 }
P.Brada > PhD Thesis > The ENT Model
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}
P.Brada > PhD Thesis > The ENT Model
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” | …
P.Brada > PhD Thesis > The ENT Model
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
P.Brada > PhD Thesis > The ENT Model
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 …”) }
P.Brada > PhD Thesis > The ENT Model
Applications of the Model
• Structuring interface for analyses– comparison substitutability,
versioning– search and retrieval– internal representation
• Synthesis– visual representation– code generation, crosscompiling
P.Brada > PhD Thesis > The ENT Model
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
P.Brada > PhD Thesis > Analysing Specification Differences
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; }
P.Brada > PhD Thesis > Analysing Specification Differences
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
P.Brada > PhD Thesis > Analysing Specification Differences
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)
P.Brada > PhD Thesis > Analysing Specification Differences
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
P.Brada > PhD Thesis > Component Revision Identification
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
P.Brada > PhD Thesis > Component Revision Identification
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
P.Brada > PhD Thesis > Component Revision Identification
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)
P.Brada > PhD Thesis > Component Revision Identification
Cascaded Derivation
P.Brada > PhD Thesis > Component Revision Identification
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
P.Brada > PhD Thesis > Component Revision Identification
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;}
P.Brada > PhD Thesis > Component Revision Identification
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
P.Brada > PhD Thesis > Substitutability and Compatibility
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
P.Brada > PhD Thesis > Substitutability and Compatibility
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 }
P.Brada > PhD Thesis > Substitutability and Compatibility
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’)
P.Brada > PhD Thesis > Substitutability and Compatibility
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
P.Brada > PhD Thesis > Substitutability and Compatibility
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
P.Brada > PhD Thesis > Substitutability and Compatibility
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
P.Brada > PhD Thesis > Component Meta-data
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
P.Brada > PhD Thesis > Component Meta-data
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
P.Brada > PhD Thesis > Component Meta-data
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>
P.Brada > PhD Thesis > Component Meta-data
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
P.Brada > PhD Thesis > Evaluation
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
P.Brada > PhD Thesis > Evaluation
Issues
• Relies on interface specification• Tight integration of revision scheme
and naming / IDL / infrastructure• Substitutability still based on
subtyping• Does not consider architectural
props
P.Brada > PhD Thesis > Evaluation
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.