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

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

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

encapsulationI 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 syntaxI 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 associationsAssociation class:

Equivalent construct from an implementation perspective:

B

A * C*

BA * C*


Integral link idiom 1a 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’)

:b:a

:b:alinkTo()

:b:a


Comments onintegral link idiom 1Key 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 functionsA C++ capability

Can help control access more finely Still violates encapsulation too much


Integral link idiom 2

a in charge; b initiates link1. a asks b to make the link2. 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


Integral link idiom 3

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’ keywordExample 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 removeEnforcement 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 useImagine 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 aboveFewer lines of codeCleaner, easier-to-program, codeIntegrity more easily assuredEncapsulation more enforcedCoupling clearly localized


Other ideasExtensions to handle reflexive twoway

associationsExtensions 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 languagesBut … 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 programmerYet 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


ConclusionIncorporating 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

Documents

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