CS 426 Senior Projects Chapter 9: Relationships Chapter 10: Inheritance and Polymorphism [Arlow and Neustadt, 2005] February 21, 2012

Outline Relationships: Inheritance and Polymorphism: Links Associations Dependencies Inheritance and Polymorphism: Generalization Class inheritance Polymorphism Advanced generalization

Relationships: Links & Associations Relationships = semantic connections between modeling elements Links = connections between objects Associations = connections between classes Links are instances of associations

Links.. A link is a connection between objects that communicate via messages Links can be: Unidirectional, if only one object (the source) contains a reference to the other (the target). Navigability is shown by an arrowhead at the target end of the link. Bidirectional, if both objects have a reference to the other. Bidirectional links are shown using unadorned lines with no arrowheads. Object diagrams show objects and their relationships at some point in time. Thus, links are dynamic connections between objects

.Links. Example of object diagram, Fig. 9.2 [Arlow & Neustadt 2002]. It shows objects, links, and roles. It also illustrates the “oblique” style of drawing paths in UML diagrams.

..Links Example of unidirectional link, Fig. 9.3 [Arlow & Neustadt 2005] The “orthogonal” style of drawing paths in UML diagrams, Fig. 9.4 [Arlow & Neustadt 2002]

Associations: Semantics Associations are relationships between classes Links depend on associations, and instantiate them Fig. 9.5 [Arlow & Neustadt 2002]

Associations: Syntax The syntax for an association includes: Association name Role names Multiplicity Navigability Example of association, Fig. 9.6 [Arlow & Neustadt 2005]

Associations: Multiplicity.. Multiplicity constrains the number of objects of a class that can be involved in a given relationship at any point in time Fig. 9.8 [Arlow & Neustadt 2005]

Associations: .Multiplicity. There is no default value for multiplicity in UML. If not specified, multiplicity is undecided Examples of multiplicity syntax, Table 9.1 [Arlow & Neustadt 2005]

Associations: ..Multiplicity Multiplicity constraints encode business rules of the model It is important to “read the model as written” Figure 9.9 [Arlow & Neustadt 2005]

Associations: Hierarchies & Networks Example of association hierarchy, Fig. 9.11 [Arlow and Neustadt 2005] network, Fig. 9.12

Associations: Navigability Navigability can be read “messages can only be sent in the direction of the arrow” Relationships without arrows are bidirectional Unidirectional associations reduce coupling between classes Fig. 9.13 [Arlow & Neustadt 2005]

Associations: Modeled using Attributes One-to-one and one-to-many associations can be modeled using attributes Fig. 9.16 [Arlow & Neustadt 2005]

Associations: Association Classes. Many-to-many associations can lead to association classes Example of many-to-many association, Fig. 9.18 [Arlow & Neustadt 2005] Corresponding association class, Fig. 9.19 [Arlow & Neustadt 2005]

Associations: .Association Classes However, many-to-many associations can also be modeled using regular classes, e.g., Fig. 9.20 [Arlow & Neustadt 2005]

Dependencies: Definition and Types. “A dependency is a relationship between two elements where a change to one element (the supplier) may affect or supply information needed by the other element (the client)” [Rumbaugh et al., The UML Reference Manual] Three types of dependency Table 9.2 [Arlow & Neustadt 2005]

Dependencies: .Definition and Types Examples of different types of dependencies Fig. 9.23 [Arlow and Neustadt 2005]

Dependencies: Usage dependencies The <<use>> dependencies are the most common type of dependency. They state that the client makes use of the supplier in some way. Example, Fig. 9.24 [Arlow & Neustadt 2005] Java code for the above example

Dependencies: Abstraction dependencies Abstraction dependencies are dependencies between model elements that are at different level of abstraction: <<trace>>, <<substitute>>, <<refine>> and <<derive>> Examples for <<derive>> Table 9.3 [Arlow & Neustadt 2005]

Dependencies: Permission dependencies Permission dependencies indicate the capability of one model element to access another model element. Examples of permission dependencies: <<access>> <<import>> <<permit>> (formerly <<friend>>)

Generalization Generalization applies to all classifiers and to some other elements such as associations, states, and events Example of generalization, Fig. 10.2 [Arlow & Neustadt 2005]

Inheritance: Overriding. Example of class hierarchy, Fig. 10.3 [Arlow & Neustadt 2005]

Inheritance: .Overriding Example of overriding, Fig. 10.4 [Arlow & Neustadt 2005]

Inheritance: Abstract Classes & Operations Example of abstract classes and operations, Fig. 10.5 [Arlow & Neustadt 2005]

Inheritance: Level of Abstraction In generalization hierarchies it is important to maintain a uniform level of abstraction at each level Incorrect example, Fig. 10.6 [Arlow & Neustadt 2005]

Polymorphism… Polymorphism means “many forms”. A polymorphic operation has several different implementations Example of polymorphism, Fig. 10.7 [Arlow & Neustadt, 2002]

.Polymorphism.. Example of polymorphism “in action,” Fig. 10.8 [Arlow & Neustadt 2005]

..Polymorphism. Object diagram with polymorphism, Fig. 10.9 [Arlow & Neustadt 2005]

…Polymorphism Another example of polymorphism, Fig. 10.10 [Arlow & Neustadt 2005]

Advanced generalization: generalization sets. An example of generalization set, Figs. 10.11 & 10.12 [Arlow & Neustadt 2005]

Advanced generalization: .generalization sets Constraints on generalization sets Table 10.1 and Fig. 10.14 [Arlow & Neustadt 2005]