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

Design Patterns in Java Appendix D UML at a Glance

  • Upload
    marci

  • View
    46

  • Download
    0

Embed Size (px)

DESCRIPTION

Design Patterns in Java Appendix D UML at a Glance. Summary prepared by Kirk Scott. UML Notation for Classes. First, a UML diagram is given Following that, the features it illustrates will be noted point by point. Draw a class by centering its name in a rectangle - PowerPoint PPT Presentation

Citation preview

Page 1: Design Patterns in Java Appendix D UML at a Glance

1

Design Patterns in JavaAppendix D

UML at a Glance

Summary prepared by Kirk Scott

Page 2: Design Patterns in Java Appendix D UML at a Glance

2

UML Notation for Classes

• First, a UML diagram is given• Following that, the features it illustrates will

be noted point by point

Page 3: Design Patterns in Java Appendix D UML at a Glance

3

Page 4: Design Patterns in Java Appendix D UML at a Glance

4

• Draw a class by centering its name in a rectangle

• Note that UML doesn’t require that everything be shown in a diagram

• Not all methods of a class need be listed, etc.• The diagram can be selective, showing only

what’s necessary to explain the topic at hand

Page 5: Design Patterns in Java Appendix D UML at a Glance

5

• 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

• 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

Page 6: Design Patterns in Java Appendix D UML at a Glance

6

• Class diagrams can show instance variables in a second rectangle, below the one with the name

• Give the name of the variable, followed by a colon, followed by a type

Page 7: Design Patterns in Java Appendix D UML at a Glance

7

• Class diagrams can show (constructors and) methods in a third rectangle, below the one with the instance variables

• A listing of a method would include its name and a pair of parentheses

• 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

Page 8: Design Patterns in Java Appendix D UML at a Glance

8

• 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 “#”

Page 9: Design Patterns in Java Appendix D UML at a Glance

9

• Static methods are indicated by underlining• In addition, static methods can noted using

dot notation, giving the name of the class, followed by a colon, followed by the method signature

Page 10: Design Patterns in Java Appendix D UML at a Glance

10

• 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

Page 11: Design Patterns in Java Appendix D UML at a Glance

11

Class Relationships

• First, a UML diagram is given• Following that, the features it illustrates will

be noted point by point

Page 12: Design Patterns in Java Appendix D UML at a Glance

12

Page 13: Design Patterns in Java Appendix D UML at a Glance

13

• Italicize the names of things that are declared abstract, like methods and the classes that contain them

• Underline the names of static methods• In general, the relationships between classes are

indicated by lines• Whether the lines are dashed, and what kind of

symbol they have on the end, indicate what the relationship is

Page 14: Design Patterns in Java Appendix D UML at a Glance

14

• Use an undashed line and a closed, hollow arrowhead to point from a subclass to its superclass

• Use an undashed line with a diamond to indicate that one or more instances of one class contain one or more instances of another

• The lines 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

• Under composition, the parts can’t exist without the whole

Page 15: Design Patterns in Java Appendix D UML at a Glance

15

• A line, in general, indicates some relationship between classes

• 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 an undashed 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

Page 16: Design Patterns in Java Appendix D UML at a Glance

16

• 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

• A dashed line with an open arrowhead can also be used to indicate the throwing of an exception, with the arrow point from the throwing class to the exception class

Page 17: Design Patterns in Java Appendix D UML at a Glance

17

Interfaces

• First, a UML diagram is given• Following that, the features it illustrates will

be noted point by point

Page 18: Design Patterns in Java Appendix D UML at a Glance

18

Page 19: Design Patterns in Java Appendix D UML at a Glance

19

• 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

Page 20: Design Patterns in Java Appendix D UML at a Glance

20

• In order to prevent a nightmare of criss-crossing lines in a diagram, the fact that a class implements an interface can be indicated by a short line from it to a small circle (a lollipop) labeled with the interface name

• The book states, “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.”

• Note that logically you could rewrite the book’s statement by observing that if interfaces and methods are always effectively abstract, then there is no need to indicate that with italics or other notation. It is understood.

Page 21: Design Patterns in Java Appendix D UML at a Glance

21

Objects

• First, a UML diagram is given• Following that, the features it illustrates will

be noted point by point

Page 22: Design Patterns in Java Appendix D UML at a Glance

22

Page 23: Design Patterns in Java Appendix D UML at a Glance

23

• 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

Page 24: Design Patterns in Java Appendix D UML at a Glance

24

• 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

Page 25: Design Patterns in Java Appendix D UML at a Glance

25

• Static structure diagrams typically show the relationships between classes

• Sequence diagrams show the relationships between objects, namely the calls between them, at run time

• Note that sequence diagrams can go all the way down to the method level (as pointed out in CS 202), but this book doesn’t cover that

Page 26: Design Patterns in Java Appendix D UML at a Glance

26

• 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

• In UML terminology, the calls are known as one object “sending a message” to another

• The lines are labeled with the name of the method called

Page 27: Design Patterns in Java Appendix D UML at a Glance

27

• 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

Page 28: Design Patterns in Java Appendix D UML at a Glance

28

• 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

Page 29: Design Patterns in Java Appendix D UML at a Glance

29

States

• First, a UML diagram is given• Following that, the features it illustrates will

be noted point by point

Page 30: Design Patterns in Java Appendix D UML at a Glance

30

Page 31: Design Patterns in Java Appendix D UML at a Glance

31

• A state is given as a rectangle with rounded corners containing the name of the state

• Transitions between states are given as open arrows 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

Page 32: Design Patterns in Java Appendix D UML at a Glance

32

The End