presentation 2003 03 24

Specification-BasedComponent Substitutability and Revision Identification: 

Specification-Based Component Substitutability and Revision Identification PhD Thesis (beta version) Přemek Brada KSI/MFF/UK + KIV/FAV/ZČU

Talk overview: 

Talk overview Scene, Issues and Goals Technical topics Related work Achievements and Conclusions

The Scene: 

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?

CDL of SOFA Component: 

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: 

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: 

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 … : 

Coming next … Meta-model Component Specification Comparison Revision Identification Substitutability Definition Component Meta-data

Part 1: The ENT Model: 

Part 1: The ENT Model An open meta-model of component and module interface specification

Motivation: 

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: 

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: 

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: 

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: 

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 : 

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: 

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: 

ENT Visual Representation

Part 2: Analysing Specification Differences: 

Part 2: Analysing Specification Differences Representation of subtype relation with smaller-than-type granularity

Motivation: 

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: 

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: 

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: 

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: 

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: 

Part 3: Component Revision Identification Straightforward revision numbering scheme amendable to automated generation and use

Motivation: 

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: 

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: 

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: 

Cascaded Derivation

Penetration into Type System: 

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: 

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: 

Notes Complete versioning variants branches Tight integration component identification revision data difference classification

Part 4: Substitutability and Compatibility: 

Part 4: Substitutability and Compatibility Notion of substitutability suitable for black-box components deployed in a context

Motivation: 

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: 

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: 

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: 

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: 

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: 

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: 

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: 

Part 5: Component Meta-Data Storing revision data and comparison results in a pre-computed meta-data supports querying and saves time

Motivation: 

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: 

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: 

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: 

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: 

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: 

Evaluation Contributions, benefits, open issues

Related Work: 

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: 

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: 

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: 

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: 

The END Comments? Hints? Criticism? Better late than never … Thank you.