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

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

Timothy C. LethbridgeUniversity of OttawaPresentation at IFIP WG2.4Delft, Netherlands, May 2000

UML in Prog. Lang. Timothy C. Lethbridge 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


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


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


UML associations...

One-One:

One-Many:

Many-Many:

BA

BA*

BA**


UML associations

Association class:

Equivalent construct from an implementation perspective:

B

A*

C*

BA*

C*


Integral link idiom 1

a in charge; a initiates link1. 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’)

:b:a

:b:alinkTo()

:b:a


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

:b:alinkTo()

linkTo() ?


Friend classes and functions

A C++ capability Can help control access more finely Still violates encapsulation too much



a in charge; b initiates link1. 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



a in charge; a creates b as an instance of an association class, which links to c1. a requests the creation of b passing itself and c to

the constructor of class Bb 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’


Proposal to help implement2-way associationsAdd the keyword ‘twoway’

Each participating class woulddeclare 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 linksCoding is simplified


The ‘twoway’ keyword

Example declarations: Link to manyclass A {

twoway LinkVector<B> AcontainsB;

}

Link to oneclass B {

twoway A AcontainsB;

}

Imagine we haveA a; B b;


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


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


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


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.


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 subclassA 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


Example of use

Imagine the following UML class diagram

Passenger

*

Booking SpecificFlight*


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);

}

}

Passenger

*



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

}

}

Passenger

*



Concrete benefits of the above

Fewer lines of codeCleaner, easier-to-program, codeIntegrity more easily assuredEncapsulation more enforcedCoupling clearly localized


Other ideas

Extensions to handle reflexive twoway associations

Extensions to handle state machines or other UML features


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


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

complexityE.g. C++ templatesSubstantially increased cognitive loadQuestionable net benefit, as implemented


Alternative: Code generation

Problems Generated code alien to programmer

Yet it often must be modified

Restricted programming freedomLimits innovation

Can complicate reuse-by-encapsulationGenerators tend to be environment-specific

Benefits: Reuse of carefully thought out design


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

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

Documents

Transcript of Embedding UML features in programming languages: Some thoughts about how and why Timothy C....