Appendix D UML at a Glance Summary prepared by Kirk Scott 1

Design Patterns in Java Appendix D UML at a Glance Summary prepared by Kirk Scott 2

UML Notation for Classes, Etc. The first example UML diagram is shown on the following overhead Following this is a list of the features it includes Then the diagram is repeated Then a more detailed, point-by-point explanation of the features is given 3

4

Features Packages – Tabbed boxes – Dot notation in names Classes – Rectangles – Name, instance variables, constructors, methods 5

Methods – Access modifiers, -, +, # – Return type – Parameters Static methods – Underlined – Or dot notation with class name 6

Notes – Dog-eared boxes General rule – A UML diagram can be as complete and detailed or as sparse as desired – The goal is to convey what is necessary without needing to convey what is not important 7

8

Packages Indicate a package by putting its name in a “tab” at the upper left of a rectangle which contains the elements (classes, etc.) of the package 9

Classes Draw a class by centering its name in (at the top of) a rectangle Note that UML doesn’t require that everything be shown in a diagram The diagram can be selective, showing only what’s necessary to explain the topic at hand The diagram may simply give the name of the class, or it may include other information 10

If a class belongs to a package, but the package itself is not diagrammed as a tabbed rectangle, the class’s name can include the package name using dot notation: packagename.classname 11

Class diagrams can show instance variables in a second subdivision of the rectangle, below the one with the name Not all instance variables of a class need be listed The names of variable are given followed by a colon, followed by a type 12

Class diagrams can show (constructors and) methods in a third rectangle, below the one with the instance variables Not all methods of a class need be listed A listing of a method would include its name and a pair of parentheses 13

If the method takes a parameter, within the parentheses the name of the parameter would be given, followed by a colon, followed by its type If the method returns a value, the parentheses are followed by a colon, which is followed by the type of the return value 14

Both instance variables and methods can be marked to indicate what access modifier they have Private things are preceded with a “-” Public things are preceded with a “+” Protected things are preceded with a “#” 15

Static methods are indicated by underlining In addition, static methods can be noted using dot notation, giving the name of the class, followed by a colon, followed by the method signature 16

Notes Notes can be added by drawing a dashed line from the item in question to a dog-eared rectangle Notes can be code, constraints, or comments Notes can be used wherever needed or desired in a UML diagram 17

Additional Class Notation and Class Relationships The second example UML diagram is shown on the following overhead Following this is a list of the features it includes Then the diagram is repeated Then a more detailed, point-by-point explanation of the features is given 18

19

Features Abstract classes and methods – Italicize Relationships – Any line indicates some relationship Inheritance – Solid line with closed, hollow arrowhead from subclass to superclass 20

Aggregation or composition – Solid line with diamond from “having” to “had” class Reference/Navigability – Solid line with open (feathered) arrowhead from the one with the reference to the one referred to Dependencies without references – Dashed line with open arrowhead 21

22

Additional Class Notation Italicize the names of things that are declared abstract, like methods and the classes that contain them Underline the names of static methods 23

Class Relationships A line, in general, indicates some relationship between classes Conventions such as dashed or solid lines, and what kind of symbol they have on the end, indicate what the relationship is 24

Inheritance, or Superclass-Subclass Relationships Use a solid line and a closed, hollow arrowhead to point from a subclass to its superclass 25

Aggregation and Composition Use a solid line with a diamond to indicate that one or more instances of one class contain one or more instances of another The line can be labeled with numbers indicating the cardinality of each end of the relationship A white or black diamond determines whether this is aggregation of composition, respectively Under composition, the parts can’t exist without the whole 26

References and Navigability If two classes are connected by a simple line, this would indicate that one of the classes has an instance of the other as an instance variable In order to make this clear, a reference from one class to an instance of another is indicated with a solid line with an open arrowhead The official term for this is navigability, the object referred to is reachable through the code of the object which refers to it 27

Class Dependencies without References Classes may also have dependencies that are not determined by an object reference Such dependencies are shown with a dashed line and an open arrowhead The book illustrates such a dependency with a class that calls a static method of another class The book also uses this notation to indicate the throwing of an exception, with the arrow pointing from the throwing class to the exception class 28

Interfaces The third example UML diagram is shown on the following overhead Following this is a list of the features it includes Then the diagram is repeated Then a more detailed, point-by-point explanation of the features is given 29

30

Features Interfaces – Rectangle with label “interface” in European quotation marks – Dashed line with closed, hollow arrowhead from class that implements to interface – Lollipops to avoid multiple lines in diagram 31

32

Interfaces with Arrows You can show an interface by drawing a rectangle and labeling it with the name of the interface in European quotation marks A dashed line with a closed, white arrowhead from a class to an interface shows that the class implements the interface 33

Interfaces with Lollipops The fact that a class implements an interface can also be indicated by a short line from it to a small circle (a lollipop) labeled with the interface name. This notation helps prevent a nightmare of criss-crossing lines in a diagram 34

Interfaces and Abstract Classes The book makes this statement: “Interfaces and their methods are always abstract in Java. Oddly enough, interfaces and their methods do not appear in italics, unlike abstract classes and abstract methods in classes.” 35

Two observations can be made about the book’s statement: 1. If interfaces and methods are always effectively abstract, then there is no need to indicate that with italics or other notation. It is understood. 2. Purists might argue that interfaces and abstract classes are two different things anyway. 36

Objects The fourth example UML diagram is shown on the following overhead Following this is a list of the features it includes Then the diagram is repeated Then a more detailed, point-by-point explanation of the features is given 37

38

Features Objects – Rectangle labeled with name, underlined – Solid line with open arrowhead between objects indicates a reference 39

Sequence diagrams – Rectangles for objects (at the top) – Dashed life-line from top to bottom – Narrow rectangles indicate method activations – Horizontal arrows represent calls – Object creation can also be shown 40

41

Object Naming An object is represented by rectangle containing the name of the object More completely, it could be given as object name, colon, class name In the case of an unnamed object, it can be labeled with a colon followed by the class name Whatever naming convention is used, the name should be underlined 42

Object References A line between two objects shows that one has a reference to the other Just like with this notation in classes, it should be a solid line with an open arrowhead going from the one having the reference to the one referred to 43

Sequence Diagrams Static structure diagrams typically show the relationships between classes Sequence diagrams show the relationships between objects, namely the calls between them, at run time Sequence diagrams, like static structure diagrams, can vary in level of detail They can show specific information about methods—or not 44

When doing sequence diagrams, each object has a dashed life-line, a dashed vertical line where time runs from top to bottom The calls from one object to another are indicated by solid lines with solid black arrowheads from the life-line of one object to the life-line of another The lines are labeled with the name of the method called In UML terminology, the calls are known as one object “sending a message” to another 45

Object Creation One object creating another is shown using similar notation A solid line with a solid black arrowhead runs from the life-line of the creating object to the rectangle representing the created one This arrow is labeled with what is known as a stereotype, the word “create” in European quotation marks 46

Objects and Threads The last point on this topic is rather obscure In other words, we will never have a use for it in this course If the box representing an object is bold-faced, this means that the object is active in a thread, process, or computer other than the one in which the other objects in the diagram are active In other words, this is a way of indicating remote calls, for example 47

States The fifth example UML diagram is shown on the following overhead Following this is a list of the features it includes Then the diagram is repeated Then a more detailed, point-by-point explanation of the features is given 48

49

Features State – Rectangle with rounded corners, labeled Transition – Solid line with open arrowhead, labeled 50

51

A state is given as a rectangle with rounded corners containing the name of the state Transitions between states are given as solid lines with open arrowheads labeled with the name of the transition State charts do not necessarily map directly to a class or object diagram in particular application code, although this is possible This will come up in chapter 22 on the State design pattern 52

The End 53