1. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Intentional annotations for evolving object-oriented software Kim Mens Programming Technology Lab Vrije Universiteit Brussel Thesis advisor:Theo D’Hondt 00 kimmens@vub.ac.be

2. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens 00 Towards an Explicit Intentional Semantics for Evolving Software Kim Mens Programming Technology Lab Vrije Universiteit Brussel Thesis advisor:Theo D’Hondt kimmens@vub.ac.be

3. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Ï Conflict detection l with reuse contracts l with intentions Ð Towards an intentional semantics Ñ Approach Ò Contribution Overview Ê Thesis Ë Motivating example Ì Thesis (rephrased) Í Software classifications Î Intentions (in terms of classifications) 01

4. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens (Tentative) thesis “Automated reasoning about explicit information on the intentions of software engineers allows to build more powerful tools for software evolution.” we will focus on (tools for) detecting evolution conflicts = can draw stronger conclusions (= can detect extra or more precise conflicts) 02

5. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Motivating example: 3-tiered architecture User interface Domain Database Updating Changing 03

6. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Motivating example: 3-tiered architecture User Interface Domain Database Updating Changing u To express this example we need: l software classifications l relationships between these classifications l formal reasoning about classifications and relations u Some examples: l Model.change isClassified ‘Changing’ l uses(‘User Interface’,‘Domain’) l architecturalBreach()if uses(without(‘Domain’,‘Changing’),‘User Interface’)) 03

7. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Motivation Software evolution is not easy because of the many hidden assumptions in the software u difficult to understand the purpose of software (and its evolution) u difficult to assess impact of making changes to software u difficult to detect evolution conflicts that arise by breaking undocumented assumptions 04

8. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Motivation u Software... l only reveals how and what is done l but not why it is done u Software evolution lacks... l information on how the software is modified l information on why things are modified 05 traceability research software comprehension research reuse contracts our contribution

9. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Research Idea u More information needed on software engineers’ intentions when modifying software artifacts u Rephrased thesis: “Automated reasoning about intentional software annotations (formally describing the intentions of software engineers) allows to build powerful tools for detecting evolution conflicts.” 06

10. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Some Definitions Intention [Webster’s]= l that upon which the mind is set or which it wishes to express or achieve l purpose conceived Software intention = l that which the software engineer wishes to express l purpose conceived by a software engineer when constructing or modifying a software artifact l reason why something was constructed or modified 07

11. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Some Definitions Annotation [Webster’s] = l a critical or explanatory note Intentional software annotation = l an annotation of a software artifact describing a software intention l describes why some software artifact was constructed or modified For now, we will focus on intentional annotations that can be expressed using software classifications... 08

12. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens User Interface Domain Database Updating Changing Software Classifications u A software classification is a collection of software artifacts that belong together because they share some common characteristics. u A classification expresses the intention that all artifacts it contains have something in common. u Classifications may be overlapping. u Some examples: ‘User interface’‘Domain’ ‘Database’ ‘Changing’‘Updating’ 09

13. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens User Interface Domain Database Updating Changing Definition of Software Classifications Intentions can be expressed in terms of l simple classifications For example: ‘Domain’, ‘Changing’,... l combinations of classifications  both(C 1,C 2 ) “both C 1 and C 2 ”  C 1  C 2  either(C 1,C 2 ) “either C 1 or C 2 ”  C 1  C 2  without(C 1,C 2 ) “C 1 without C 2 ”  C 1 \ C 2 u … (these are the building blocks) 10

14. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens User Interface Domain Database Updating Changing Definition of Intentional Annotations l Intentional annotations are defined in terms of dependencies between software classifications... u isClassified(A,C) =artifact A belongs to classification C u uses(C 1,C 2 ) =some artifact in C 1 uses one in C 2 u requires(C 1,C 2 ) =each artifact in C 1 uses one in C 2 u isa(C 1,C 2 ) = C 1 is a special case of C 2 l … and combinations of such intentions using logical operators u and(I 1,I 2 )both I 1 and I 2 hold u or(I 1,I 2 )either I 1 or I 2 holds, or both u xor(I 1,I 2 )either I 1 or I 2 holds, but not both 11

15. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Example: Intentions in terms of Software Classifications add addall {add} isClassified ‘Element addition’ isClassified ‘Set union’ Set Intention: requires(‘Set union’,‘Element addition’) Intentional rule: requires(C 1,C 2 )if  m 1 where isClassified(m 1,C 1 ) :  m 2 where isClassified(m 2,C 2 ) such that invokes(m 1,m 2 ) 12

16. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Conflict detection u “Reuse contracts” l formally describe how software artifacts can be, and are actually modified, during software evolution l allow automated conflict detection by reasoning about this information u Our approach l extends the information provided by reuse contracts with more intentional information l allows more precise detection of evolution conflicts 13

17. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Reuse Contracts (RC) add addall {add} add addall {} count add {count} addall {add} Evolution A coarsening addall { - add} refinement add { + count} + count SetSet’ Set” formal software annotations expressing how the software is modified. Evol. B 14

18. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Conflict detection with RC’s add addall {add} Evolution A coarsening addall { - add} refinement add { + count} + count SetSet’ Set” Evol. B refinement add { + count} + count Set” Evol. B addall {add,count} Inconsistent method conflict addall {} 15

19. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Conflict detection with intentions add addall {add} coarsening addall { - add} Set Set’ Evol. A isClassified‘Element addition’ isClassified‘Set union’ Intention is invalidated... requires( ‘Set union’,‘Element addition’) Solution: assert hidden assumptions explicitly. speed optimization isClassified ‘Element addition’ 16

20. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Conflict detection with intentions add addall {add} refinement add { + count} + count Set Set” Evol. B isClassified ‘Element addition’ isClassified ‘Set union’ isClassified ‘Element counting’ Derived intentions: requires(‘Set union’,‘Element addition’) requires(‘Element addition’, ‘Element counting’) requires(‘Set union’,‘Element counting’) 17

21. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Conflict detection with intentions add addall {add} Evolution A coarsening addall { - add} refinement add { + count} + count SetSet’ Set” Evol. B refinement add { + count} + count Set” Evol. B Intention invalidated... requires(‘Element addition’, ‘Element counting’) 18

22. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Towards an intentional semantics (semantics of classifications) Semantic domain: [ ] Classification : Classification  2 Artifacts [ C ] Classification = { A  Artifacts | isClassified(A,C) } [ both(C 1,C 2 ) ] Classification = [ C 1 ] Classification  [ C 2 ] Classification [ either(C 1,C 2 ) ] Classification = [ C 1 ] Classification  [ C 2 ] Classification [ without(C 1,C 2 ) ] Classification = [ C 1 ] Classification \ [ C 2 ] Classification 19

23. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Towards an intentional semantics (semantics of intentions) Semantic domain: [ ] Intention : Intention  {true,false} [ requires(C 1,C 2 ) ] Intention =  m 1  [ C 1 ] Classification :  m 2  [ C 2 ] Classification : invokes(m 1,m 2 ) [ uses(C 1,C 2 ) ] Intention =  m 1  [ C 1 ] Classification :  m 2  [ C 2 ] Classification : invokes(m 1,m 2 ) [ isa(C 1,C 2 ) ] Intention = [ C 1 ] Classification  [ C 2 ] Classification [ and(I 1,I 2 ) ] Intention = [ I 1 ] Intention  [ I 2 ] Intention 20

24. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Approach u Find out what interesting software intentions are u Bottom-up approach - limit scope at first l object-oriented software l evolution conflict detection tools l evolution at implementation level l intentions in terms of software classifications and the dependencies between them u Develop formal model for conflict detection by reasoning about intentional annotations 21

25. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Approach u Build prototype conflict detection tool u Merge model and tool with reuse contract approach u Validate tool on industrial case (and show that tool indeed provides extra power) u Broaden scope again: l study other kinds of evolutionary intentions l other kinds of software evolution tool support l artifacts at other phases in software life cycle 22

26. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Our Contribution u Develop formalism to describe intentions by means of formal software annotations. u Particular focus on use of software classifications to express software intentions. u (Semi-) automatic detection of evolution conflicts by reasoning about these intentional annotations. 23

27. October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens “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 the end... 24