Mapping UML Associations into Java Code

1
Mapping UML Associations into Java Code

• Marco Bär
• baerm_at_student.ethz.ch

2
Overview

• Motivation
• Problems
• Multiplicity
• Navigability
• Visibility
• Interface
• Conclusion

3
Motivation

• Associations are key concepts of OO
• No language support
• Implementing Associations is repetive and error
  prone
• Constraints and Invariants left to programmer
• Code is difficult to maintain

4
Problems

• Multiplicity
• Navigability
• Visibility

5
Multiplicity
1..
0..1
Person
Company
works for

• Specifies the number of target instances that
  may be linked to a single object of the source
  class
• denotes many
• Any subset of nonnegative integers allowed
• Paper deals only with intervals (min..max)
• Multiplicity Constraints are Invariants

6
Minimum Multiplicity

• Most common minimum multiplicities
• 0 optional
• 1 mandatory

• Remember the previous example
• Person ? Company is optional
• Company ? Person is mandatory
• What happens if a Company is created?
• It needs to be linked immediately to a Person!

7
Possibilities of creating a Company instance

• By an instance of Person

Person p new Person(personData) Company c
p.createCompany(companyData)

• With an instance of Person as parameter

Person p new Person(personData) Company c new
Company(companyData, p)

• Creation of a Company instance issues the
  creation of a Person instance

Company c new Company(companyData, personData)
8
Changing Links Example
(a)
(b)
(c)
9
Consequence

• Mandatory associations pose unsolvable problems
• Solution
• Dont check the minimum constraints when
  modifying links (e.g. mutator methods, or
  setters)
• Check the minimum constraints when accessing
  links (e.g. accessor methods, or getters)

10
Maximum Multiplicity

• Most common maximum multiplicities
• 1 single
• Single associations can be stored in a simple
  variable
• multiple
• A Collection has to be used to store the
  association references
• Choices for Adder Methods
• Reject additions that violate constraints
• Perform additions that violate constraints (like
  remove)
• Single associations have to reject additions that
  violate the multiplicity constraints

11
Example
0..
2..4
Game
Player
g1 Game
(a)
(b)
(c)
12
Summary of Multiplicity

• Adders
• Check maximum constraints
• Reject operations that violate maximum
  constraints
• Ignore objects already linked to the source
  instance
• Removers
• Dont check minimum constraints
• Ignore objects not linked to the source instance
• Getters
• Check both maximum and minimum constraints
• Raise exeptions if constraints are violated
• Users Responsibilities
• Use Remove and Add Methods in the right order
• Restore valid system state before accessing
  associations

13
Problems

• Multiplicity
• Navigability
• Visibility

14
Navigability
Navigability specifies the ability of an
instance of the source class to access the
instances of the target class through the links
that connect them.
15
Unidirectional Associations

• Single
• A simple attribute is used to store the reference

• Multiple
• A Collection is used to store the references

16
Bidirectional Associations

• Cannot be implemented with a single attribute
• Three possible combinations of multiplicities
• Single Single
• Single Multiple
• Multiple - Multiple

17
Single - Single
18
Synchronization Example
19
Multiple - Multiple
20
Problems

• Multiplicity
• Navigability
• Visibility

21
Visibility

• UML Standart says
• specifies the visibility of the association end
  from the viewpoint of the classifier on the other
  end.
• Possible visibilities
• public, protected, package, private
• package has different semantics in UML

22
What about Bidirectional Associations?

• No reciprocal update from Subject side!
• Private-private relations cannot be managed!
• Indirect access through public methods
• Similiar considerations for package and protected

23
Interface

• Accesor methods (get())
• min. or max. constraint violated ? exception
• Mutator methods
• add(Collection links), remove(Collection links)
• add(Type link), remove(Type link)
• none or all semantics
• maximum constr. violated ? cancel op return
  false
• type(link) type(target) ? cancel op exception

24
Conclusion

• Ups
• Reduces amount of coding
• Introduces automatic Invariant checks
• Additions/Modifications of associations possible
• Downs
• Add/Remove have to be invoked in the right order
• Valid system state has to be re-established after
  modifiers were called

25
Thank you for your attention!

• Questions?