Package Merge in UML 2: Practice vs. Theory?
- Alanna ZitoAffiliated withSchool of Computing, Queen’s University
- , Zinovy DiskinAffiliated withSchool of Computing, Queen’s University
- , Juergen DingelAffiliated withSchool of Computing, Queen’s University
The notion of compliance is meant to facilitate tool interoperability. UML 2 offers 4 compliance levels. Level L i + 1 is obtained from Level L i through an operation called package merge. Package merge is intended to allow modeling concepts defined at one level to be extended with new features. To ensure interoperability, package merge has to ensure compatibility: the XMI representation of the result of the merge has to be compatible with that of the original package. UML 2 lacks a precise and comprehensive definition of package merge. This paper reports on our work to understand and formalize package merge. Its main result is that package merge as defined in UML 2.1 does not ensure compatibility. To expose the problem and possible remedies more clearly, we present this result in terms of a very general classification of model extension mechanisms.
- Package Merge in UML 2: Practice vs. Theory?
- Book Title
- Model Driven Engineering Languages and Systems
- Book Subtitle
- 9th International Conference, MoDELS 2006, Genova, Italy, October 1-6, 2006. Proceedings
- pp 185-199
- Print ISBN
- Online ISBN
- Series Title
- Lecture Notes in Computer Science
- Series Volume
- Series ISSN
- Springer Berlin Heidelberg
- Copyright Holder
- Springer-Verlag Berlin Heidelberg
- Additional Links
- Industry Sectors
- eBook Packages
- Editor Affiliations
- 16. Software Composition Group, University of Bern
- 17. Computing Department - InfoLab21, Lancaster University
- 18. Department of Computer Science and Applied Mathematics, The Weizmann Institute of Science
- 19. DISI, Università di Genova
- Author Affiliations
- 20. School of Computing, Queen’s University, Kingston, Ontario, Canada
To view the rest of this content please follow the download PDF link above.