Embedding UML features in programming languages: Some thoughts about how and why

1. Embedding UML features in programming languages:Some thoughts about how and why Timothy C. Lethbridge University of Ottawa Presentation at IFIP WG2.4 Delft, Netherlands, May 2000

2. Overview • 2-way UML associations are tedious and error prone to program and maintain • They involve programming idioms that are repeated very frequently • They open the potential for violation of encapsulation • I propose three simple keywords that: • Reduce programming time • Improve data integrity Timothy C. Lethbridge

3. Hypotheses: • It is an advantage to compactly represent certain UML abstractions at the programming language level • Doing so is better than providing code generation for these abstractions Timothy C. Lethbridge

4. Java syntax • I will use the Java syntax since it is well understood • But: • The concept I propose can be implemented in any OO language • I will take some liberties • I.e. assume the presence of a genericity (parameterizing / template) capability Timothy C. Lethbridge

5. UML associations... • One-One: • One-Many: • Many-Many: Timothy C. Lethbridge

6. UML associations • Association class: • Equivalent construct from an implementation perspective: Timothy C. Lethbridge

7. Integral link idiom 1 a in charge; a initiates link 1. a makes the initial one-way link to b 2. a calls b.linkTo(a) to make link back to a. • b makes the requested one-way link back to a • (If steps 1 & 2 are reversed, we have idiom 1’) Timothy C. Lethbridge

8. Comments onintegral link idiom 1 • Key weaknesses • A and B have to relax their encapsulation to link to each other • Some other method can call b.linkTo() to cause it to make a spurious one-way link • Possible defensive programming: • b.linkTo() can ensure that its argument already points to it before linking Timothy C. Lethbridge

9. Friend classes and functions • A C++ capability • Can help control access more finely • Still violates encapsulation too much Timothy C. Lethbridge

10. Integral link idiom 2 a in charge; b initiates link 1. a asks b to make the link 2. b follows integral link idiom 1 • Advantage for class A • It can be programmed defensively as described • Disadvantage for class A • It is more at the mercy of class B Timothy C. Lethbridge

11. Integral link idiom 3 a in charge; acreatesb as an instance of an association class, which links to c 1. a requests the creation of b passing itself and c to the constructor of class B b makes a one-way link back to a as in idiom 1 b uses idiom 1, 1’ or 2 to link to c 2. a makes the final one-way link to b as in idiom 1’ Timothy C. Lethbridge

12. Proposal to help implement2-way associations • Add the keyword ‘twoway’ • Each participating class would • declare its own end (instance variable) of the association to be ‘twoway’ • Use the same name for its own end to allow consistency checking • Add keywords ‘link’ and ‘unlink’ • These manage links, ensuring integrity of inverse links • Coding is simplified Timothy C. Lethbridge

13. The ‘twoway’ keyword • Example declarations: • Link to many class A { twoway LinkVector<B> AcontainsB; } • Link to one class B { twoway A AcontainsB; } • Imagine we have • A a; B b; Timothy C. Lethbridge

14. The ‘link’/’unlink’ keywords... • (many or one)-many association case • When a wants to make a link: link AcontainsB(b); • When a wants to delete a link; unlink AcontainsB(b); • Inverse links are handled automatically Timothy C. Lethbridge

15. The ‘link’/’unlink’ keywords • (many or one)-one association case • When :a wants to delete a link; unlink AcontainsB; • No argument needed • Inverse link is again handled automatically Timothy C. Lethbridge

16. Rules... 1. A twoway variable must have as its type either: • A class with an identically named twoway instance variable referring to the current class. • A collection class, whose members have an identically named twoway variable referring to the current class. • The collection must support a LinkCollection interface • Provides straightforward methods for add and remove • Enforcement of this requires a genericity mechanism Timothy C. Lethbridge

17. Rules... 2. A twoway variable should be treated as if it were a constant in all accesses except by link and unlink. 3. ‘static’ and ‘twoway’ are mutually exclusive keywords. Timothy C. Lethbridge

18. Rules 4. ‘private’, ‘public’ and ‘protected’ would behave as normal, but note: • ‘link’ and ‘unlink’ would only be usable on a twoway variable in its class or a subclass • A public twoway variable can be read in other classes • If a twoway variable is ‘private’, then ‘link’ and ‘unlink’ cannot be used on that variable in a subclass • A private twoway variable can still be linked to from its associated class Timothy C. Lethbridge

19. Example of use • Imagine the following UML class diagram Timothy C. Lethbridge

20. Partial implementation (current) class Passenger { Vector bookings // <Booking> addBooking(SpecificFlight aFlight) { Booking theBooking; theBooking = Booking new(this, aFlight); bookings add(theBooking); } } class Booking { Passenger thePassenger; SpecificFlight theSpecificFlight; Booking(Passenger aPassenger, SpecificFlight aSpecificFlight) { thePassenger = aPassenger; theSpecificFlight = aSpecificFlight; aSpecificFlight.addBooking(this); } } Timothy C. Lethbridge

21. Partial implementation (with twoway/link) class Passenger { Vector bookings // <Booking> addBooking(SpecificFlight aFlight) { twoway booking BookingOfPassenger; theBooking = Booking new(this, aFlight); } } class Booking { twoway Passenger BookingOfPassenger; twoway SpecificFlight BookingOnSpecificFlight; Booking(Passenger aPassenger, SpecificFlight aSpecificFlight) { link BookingOfPassenger(aPassenger); link BookingOnSpecificFlight(aSpecificFlight); // code for addBooking in SpecificFlight is eliminated } } Timothy C. Lethbridge

22. Concrete benefits of the above • Fewer lines of code • Cleaner, easier-to-program, code • Integrity more easily assured • Encapsulation more enforced • Coupling clearly localized Timothy C. Lethbridge

23. Other ideas • Extensions to handle reflexive twoway associations • Extensions to handle state machines or other UML features Timothy C. Lethbridge

24. Should we keep extending programming languages? • Each improvement should help reduce cost • Reduce error-prone activities • Make programming faster and simpler • E.g. • Structured programming and type declarations • Abstract data types Timothy C. Lethbridge

25. Extensions in programming languages • But … some improvements can increase cost • Radical syntax changes make it harder to find and train people • ‘Powerful’ facilities can add substantial complexity • E.g. C++ templates • Substantially increased cognitive load • Questionable net benefit, as implemented Timothy C. Lethbridge

26. Alternative: Code generation • Problems • Generated code alien to programmer • Yet it often must be modified • Restricted programming freedom • Limits innovation • Can complicate reuse-by-encapsulation • Generators tend to be environment-specific • Benefits: • Reuse of carefully thought out design Timothy C. Lethbridge

27. Conclusion • Incorporating simple support for certain UML programming idioms into programming languages can be beneficial with few drawbacks • There is nothing to stop one also allowing code generation in some circumstances Timothy C. Lethbridge