1 / 25

Towards an Explicit Intentional Semantics for Evolving Software

This thesis explores the use of intentional software annotations to facilitate software evolution by detecting and resolving conflicts. It proposes automated reasoning about software engineers' intentions to build more powerful tools for software evolution.

patrickrodriguez
Télécharger la présentation

Towards an Explicit Intentional Semantics for Evolving Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. kimmens@vub.ac.be 00 Towards an Explicit Intentional Semantics for Evolving Software Kim Mens Programming Technology Lab Vrije Universiteit Brussel Thesis advisor: Theo D’Hondt

  2. Thesis Motivating example Thesis (rephrased) Software classifications Intentions (in terms of classifications) 01 Overview • Conflict detection • with reuse contracts • with intentions • Towards an intentional semantics • Approach • Contribution

  3. 02 (Tentative) thesis “Automated reasoning about explicit information on the intentions of software engineers allows to build more powerfultools for software evolution.” = can draw stronger conclusions (= can detect extra or more precise conflicts) we will focus on (tools for) detecting evolution conflicts

  4. User interface Updating Domain Changing Database 03 Motivating example:3-tiered architecture

  5. User interface Updating Domain Changing Database 03 Motivating example:3-tiered architecture To express this example we need: software classifications relationships between these classifications formal reasoning about classifications and relations Some examples: Model.change addresses ‘Changing’ uses(‘User interface’,‘Domain’) architecturalBreach() if uses(without(‘Domain’,‘Changing’),‘User interface’))

  6. 04 Motivation Software evolution is not easy because of the many hidden assumptions in the software • difficult to understand the purpose of software (and its evolution) • difficult to assess impact of making changes to software • difficult to detect evolution conflicts that arise by breaking undocumented assumptions

  7. 05 Research idea • Describing the software engineers’ intentions more explicitly might facilitate software evolution. • Rephrased thesis: “Automated reasoning about intentional software annotations (formally describing the intentions of software engineers) allows to build powerful tools for detecting evolution conflicts.”

  8. 06 Some definitions Intention [Webster’s]= • that upon which the mind is set or which it wishes to express or achieve • purpose conceived Software intention = • that which the software engineer wishes to express • purpose conceived by a software engineer when constructing or modifying a software artifact • reason why something was constructed or modified

  9. 07 Some definitions Annotation [Webster’s] = • a critical or explanatory note Intentional software annotation = • an annotation of a software artifact describing a software intention • describes why some software artifact was constructed or modified We first look at intentional annotations that can be expressed using software classifications...

  10. User interface Updating Domain Changing Database 08 Software classifications • A software classification is a collection of software artifacts that belong together because they share some common characteristics. • A classification expresses the intention that all artifacts it contains have something in common. • Classifications may be overlapping. • Some examples (LAN simulation): ‘User interface’ ‘Domain’ ‘Database’ ‘Changing’ ‘Updating’

  11. User interface Updating Domain Changing Database 09 Definition ofsoftware classifications Intentions can be expressed in terms of • single classifications For example: ‘Domain’, ‘Changing’, ... • combinations of more primitive classifications • both(C1,C2) “both C1 and C2”  C1 C2 • either(C1,C2) “either C1 or C2”  C1 C2 • without(C1,C2) “C1 without C2”  C1 \ C2 For example: without(‘Domain’, ‘Changing’) (these are the building blocks)

  12. User interface Updating Domain Changing Database 10 Definition ofintentional annotations Intentional annotations are defined in terms of dependencies between software classifications... • isClassified(A,C) = artifact A belongs to classification C • uses(C1,C2) = some artifact in C1 uses one in C2 • requires(C1,C2) = each artifact in C1 uses one in C2 • isa(C1,C2) = C1 is a special case of C2 … and combinations of more primitive intentions using logical operators • and(I1,I2) both I1 and I2 hold • or(I1,I2) either I1 or I2 holds, or both • xor(I1,I2) either I1 or I2 holds, but not both

  13. add addall {add} 11 Example: intentions in terms ofsoftware classifications Set isClassified ‘Element addition’ isClassified ‘Set union’ Intention: requires(‘Set union’,‘Element addition’) Intentional rule: requires(C1,C2) if  m1 where isClassified(m1,C1) :  m2 where isClassified(m2,C2) such that invokes(m1,m2)

  14. 12 Conflict detection • “Reuse contracts” • formally describe how software artifacts can be, and are actually modified, during software evolution • allow automated conflict detection by reasoning about this information • Our approach • extends the information provided by reuse contracts with more intentional information • allows more precise detection of evolution conflicts

  15. add addall {add} add addall {} 13 Reuse contracts (RC) Set Set’ Evolution A coarsening addall {-add} Evol. B refinement add {+count} +count formal software annotations expressing how the software is modified. Set” count add {count} addall {add}

  16. add addall {add} 14 Conflict detection with RC’s Set Set’ Evolution A coarsening addall {-add} refinement add {+count} +count refinement add {+count} +count Evol. B Evol. B Set” Set” Inconsistent method conflict addall {add,count} addall {}

  17. add addall {add} 15 Conflict detection with intentions Set isClassified ‘Element addition’ isClassified ‘Set union’ coarsening addall {-add} Evol. A (speed optimization) isClassified ‘Element addition’ Set’ Intention invalidated ... requires( ‘Set union’,‘Element addition’) Solution: explicitly assert hidden assumptions

  18. add addall {add} 16 Conflict detection with intentions Set isClassified ‘Element addition’ isClassified ‘Set union’ refinement add {+count} +count Evol. B isClassified ‘Element counting’ Set” Derived intentions: requires(‘Set union’,‘Element addition’) requires(‘Element addition’, ‘Element counting’) requires(‘Set union’,‘Element counting’)

  19. add addall {add} 17 Conflict detection with intentions Set Set’ Evolution A coarsening addall {-add} refinement add {+count} +count refinement add {+count} +count Evol. B Evol. B Set” Set” Intention invalidated ... requires(‘Element addition’, ‘Element counting’)

  20. 18 Towards an intentional semantics(semantics of classifications) Semantic domain: [ ]Classification : Classification  2Artifacts Semantics: [C]Classification = { A  Artifacts | isClassified(A,C) } [both(C1,C2)]Classification = [C1]Classification [C2]Classification [either(C1,C2)]Classification = [C1]Classification [C2]Classification [without(C1,C2)]Classification = [C1]Classification \ [C2]Classification

  21. 19 Towards an intentional semantics(semantics of intentions) Semantic domain: [ ]Intention : Intention  {true,false} Semantics: [requires(C1,C2)]Intention = m1 [C1]Classification : m2 [C2]Classification: invokes(m1,m2) [uses(C1,C2)]Intention = m1 [C1]Classification : m2 [C2]Classification: invokes(m1,m2) [isa(C1,C2)]Intention = [C1]Classification [C2]Classification [and(I1,I2)]Intention = [I1]Intention[I2]Intention

  22. 20 Approach • Bottom-up approach —limit scope at first • object-oriented software • evolution conflict detection tools • evolution at implementation level • intentions in terms of software classifications and the dependencies between them • Find out what interesting software intentions are • Develop formal model for conflict detection by reasoning about intentional annotations

  23. 21 Approach • Build prototype conflict detection tool • Merge model and tool with reuse contract approach • Validate tool on industrial case (and show that tool indeed provides extra power) • Broaden scope again: • study other kinds of evolutionary intentions • artifacts at other phases in software life cycle • other kinds of software evolution tool support

  24. 23 Our contribution • Overview of which software intentions are important to be documented. • Develop formalism to describe intentions by means of formal software annotations. • Particular focus on use of software classifications to express software intentions. • (Semi-) automatic detection of evolution conflicts by reasoning about these intentional annotations.

  25. 24 the end... “By relieving the mind of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race.” Alfred North Whitehead

More Related