1. 4 June 1998, Mulhouse, France > ‘98 International Workshop Tom Mens Carine Lucas & Patrick Steyaert {tommens|clucas|prsteyae}@vub.ac.be Programming Technology Lab Department of Computer Science Vrije Universiteit Brussel Pleinlaan 2 - 1050 Brussel - BELGIUM http://progwww.vub.ac.be/prog/pools/rcs/ Supporting Disciplined Evolution of UML Models

2. 4 June 1998, Mulhouse, France > ‘98 International Workshop Software Evolution and Aging “Continuously evolving systems will become the norm for most organisations.” “Programs, like people, get old. We can’t prevent aging, but we can understand its causes, take steps to limit its effects, temporarily reverse some of the damage it has caused, …” Grady Booch, 1998 D. L. Parnas, 1994

3. 4 June 1998, Mulhouse, France > ‘98 International Workshop 4new or changed requirements 4adoption of new technology 4software maintenance 4use of software beyond its original goals 4new insights in the domain 4new design insights 4... Reasons for Software to Evolve

4. 4 June 1998, Mulhouse, France > ‘98 International Workshop 4lack of movement 4maintenance 4ignorant surgery and architectural erosion 4inflexibility from the start 4inadequate documentation 4deadline pressure 4“Not Invented Here” syndrome Reasons for Aging

5. 4 June 1998, Mulhouse, France > ‘98 International Workshop 4Version proliferation 4Improper reuse and composition 4Architectural erosion 4Overfeaturing 4Ripple effect (butterfly effect) 4Traceability Evolution Problems

6. 4 June 1998, Mulhouse, France > ‘98 International Workshop Goals A formalism for disciplined reuse and evolution is needed We need to stop or reverse the effects of aging ! We need to avoid or reduce evolution problems ! ! !

7. 4 June 1998, Mulhouse, France > ‘98 International Workshop Evolution and composition conflicts WebNavigationPDFNavigationHistoryNavigation evolution of original component customisation of original component Evolution conflict !

8. 4 June 1998, Mulhouse, France > ‘98 International Workshop Reuse Contracts 4Need for disciplined reuse and evolution 4 what is a reusable component? 4 how can a component be reused? 4 how can evolution conflicts be detected? 4Document incremental changes 4 document how a component evolves/is reused 4Focus on essential behaviour of software only 4 interaction between collaborating classes 4Balance between formality and ease of use

9. 4 June 1998, Mulhouse, France > ‘98 International Workshop Wat is a reusable component? (in UML) interaction diagrams class interfaces collaboration context «provider clause» WebNavigation «static structure» «interface» Browser handleClick getURL «interface» Document mouseClick resolveLink «collaboration» : Browser doc browser : Document «interaction» mouseClicking doc 1:mouseClick self 1.1: resolveLink : Document : Browser handleClick «interaction» linkResolving browser 1:getURL : Document : Browser resolveLink

10. 4 June 1998, Mulhouse, France > ‘98 International Workshop Using Reusable Components “pattern” notation Application start exit Document ActiveDoc print contents BrowsableDoc mouseClick resolveLink html-docpdf-doc InternetBrowser handleClick getURL ExplorerNavigator WebNavigation Browser Document

11. 4 June 1998, Mulhouse, France > ‘98 International Workshop How can a component be reused? (in UML) 4UML provides limited support for reuse and evolution of model components. 4 generalisation can only add more information (because of substitutability requirements) 4 dependency needs to be customised (stereotyped) for reuse purposes

12. 4 June 1998, Mulhouse, France > ‘98 International Workshop Reuse Contracts Terminology provider clausereuser clausecontract types

13. 4 June 1998, Mulhouse, France > ‘98 International Workshop Contract Types 4Document the intentions of reusers/evolvers 4 specify the kind of reuse/evolution that takes place (participant extension, interaction refinement, …) 4 the details are specified in the reuser clause 4Impose obligations and restrictions on the reuser 4 extenders may add new elements, but may not remove existing elements, etcetera. 4 evolution conflicts correspond to breaches of obligations

14. 4 June 1998, Mulhouse, France > ‘98 International Workshop Reuse of collaborations BrowsableDoc mouseClick resolveLink html-docpdf-doc InternetBrowser handleClick getURL ExplorerNavigator WebNavigation Browser Document Browser PDFNavigation Document

15. 4 June 1998, Mulhouse, France > ‘98 International Workshop Stereotyped Packages ContractClause /ownedElt ProviderClauseReuserClause StaticStructure Collaboration Interaction 1 1 * /ownedElt

16. 4 June 1998, Mulhouse, France > ‘98 International Workshop Stereotyped Dependencies * /subDeps ContractType ComposedTypeBasicType {ordered} CollTypeIntTypeStStType

17. 4 June 1998, Mulhouse, France > ‘98 International Workshop How can evolution conflicts be detected? 4By comparing the contract types and reuser clauses, evolution conflicts can be detected. 4By specifying formal rules, the detection process can be automated 4This facilitates impact analysis, reduces the effort to make certain changes, and allows us to deal with change propagation and version proliferation more easily.

18. 4 June 1998, Mulhouse, France > ‘98 International Workshop Detecting Reuse Conflicts WebNavigation evolution of original component customisation of original component {type=participant extension} {type=interaction refinement} {type=interaction coarsening} {type=participant extension} {type=interaction refinement} Inconsistent operations conflict ! PDFNavigation HistoryNavigation «reuse»

19. 4 June 1998, Mulhouse, France > ‘98 International Workshop Automatic Conflict Detection participant extension interaction refinement interaction coarsening participant extension interaction refinement interaction coarsening no conflicts inconsistent operations interface conflicts operation capture, unanticipated recursion operation capture, inconsistent operations no conflicts operation capture, inconsistent operations of getURL invocation by resolveLink of getURL with addURL invocation HistoryNavigationPDFNavigation

20. 4 June 1998, Mulhouse, France > ‘98 International Workshop Conclusion 4UML must provide support for evolution and reuse 4Reuse contracts provide formalism for disciplined reuse and evolution 4Incorporating reuse contracts gives an added value to UML 4 Documenting the evolution of models 4 Support for disciplined reuse 4 Detecting evolution conflicts automatically 4 Dealing with ripple effects and version proliferation