The Unified Modeling Language UML

1
The Unified Modeling Language(UML)

• CSc 335
• Object-Oriented Programming and Design
• Spring 2007

2
Things to add

• Attributes and Associations are both "Properties"
• Collections not usually shown, the indicates
  this
• Don't return bare collections, use add / remove
• Others can modify elements in the collection
• Bidirectional if you can get from one to
  another, you should be able to get back to
  originator
• If I can see the borrowed lendable, the lendable
  should know who is borrowing it
• Name associations with meaningful things
• Don't need to write "has"
• A derived attribute is one whose values are not
  part of the state of the object instance, but
  whose values can be determined or computed
  Operations Don't need to mentions those
  manipulating properties (but tools do)
• In software engineering and system engineering, a
  use case is a technique for capturing functional
  requirements of systems and systems-of-systems.
  According to Bittner and Spence, "Use cases,
  stated simply, allow description of sequences of
  events that, taken together, lead to a system
  doing something useful" 1. Each use case
  provides one or more scenarios that convey how
  the system should interact with the users called
  actors to achieve a specific business goal or
  function. Use case actors may be end users or
  other systems. Use cases typically avoid
  technical jargon, preferring instead the language
  of the end user or domain expert. Use cases are
  often co-authored by business analysts and end
  users. Use cases are separate and distinct from
  use case diagrams, which allow one to abstractly
  work with groups of use cases.

3
Acknowledgments

• Some material drawn from a lecture by Rick Mercer
  with help from The Unified Modeling Language User
  Guide, by Grady Booch, James Rumbaugh, and Ivar
  Jacobsen, Addison Wesley, 1999, ISBN
  0-201-57168-4.
• Many changes and video phone example are by
  Richard Snodgrass, with help from UML Distilled,
  by Martin Fowler, with Kendall Scott, Addison
  Wesley, 1997, ISBN 0-201-32563-2 and
  Object-Oriented Software Development Using Java,
  by Xiaoping Jia, Addison Wesley, Second Edition,
  2003, ISBN 0-201-73733-7.

4
Outline

• Purpose of UML
• Class Diagrams
• Properties
• Fields and Methods
• Relationships between classes
• Advanced Notions
• Sequence Diagrams

5
The Unified Modeling Language

• Unified Modeling Language (UML) comes from
  Rumbaugh, Booch, and Jacobson (the three amigos)
  who combined efforts to standardize on one
  modeling language.
• This is primarily a graphical communication
  mechanism for developers and customers.
• We will learn some, but not all, of the UML.
• It is very complex, few understand all of it.

6
Purpose

• The main purpose of UML is to
• support communication about the analysis and
  design of the system being developed, and
• support the movement from the problem domain in
  the "world" to the solution domain in the machine
• Two views of the same system
• One view has diagrams
• Source code is another view
• UML is a modeling language, not a method, as it
  does not comprise a process

7
UML is a Modeling Language

• Has a graphical notation to describe software
  design
• Has rules on how to draw models of
• classes
• associations between classes
• message sends between objects
• Has become the de facto industry standard.
• Not official, but everyone uses it
• Like a blueprint to show what is going on during
  analysis, design and implementation
• Some projects require UML documentation

8
UML Defined by the Authors

• The Unified Modeling Language User Guide, Booch,
  Rumbaugh, Jacobson states
• The UML is a language for
• visualizing
• specifying
• constructing
• documenting
• the artifacts of a software intensive
  system.

9
Several Types of UML Diagrams

• Class Diagram
• Demonstrates the relationships between classes in
  object-oriented software.
• Good for visualizing how classes interact.
• Sequence Diagram
• Demonstrates the flow of control through the
  system, usually along the major branch of
  execution.
• Good for visualizing when objects interact.
• Use Case Diagram
• Demonstrates the actors upon the system
• Good for visualizing who causes objects to
  interact

10
Objects and Classes
11
Objects

• Each object has a unique identity.
• The state of an object is composed of a set of
  fields, or attributes. Each field has a name, a
  type, and a value.
• The behavior of an object is defined by a set of
  methods that may operate on the object, accessing
  or changing the value of the fields.
• Accessors methods that do not modify the state
• Mutators methods that could modify the state
• Immutable object an object that has no mutators.
• Mutable object

12
Classes

• A class is a template for creating or
  instantiating its instances, the objects.
• The class defines the names and types of all
  fields and the names, types, and implementations
  of all methods.

13
Example Cell Phone

• Assume that the cell phone includes a Java
  virtual machine.
• We wish to design all capabilities for the phone
  for implementation in Java.

14
Outline

• Purpose of UML
• Class Diagrams
• Properties
• Fields and Methods
• Relationships between classes
• Advanced Notions
• Sequence Diagrams

15
First up Class Diagrams

• A class diagram
• expresses class definitions to be implemented,
• lists name, attributes, and methods for each
  class, and
• shows how instances will connect to one others.
• UML allows different levels of detail on both the
  attributes and the methods of one class.
• A class could be just the the class name in a
  rectangle
• or like the general form shown on the next slide.

16
Class in a Class Diagram
Class Name
field
field type
field type initial value
/derivedField
...
method1()
method2(parameter Type) returnType
publicMethod()
abstractMethod()
-privateMethod()
protectedMethod()
...
17
Classes in UML

• Three components
• Class name
• Fields
• Methods
• Each component is separated with a line.
• The fields and methods can each be elided for
  less cluttered class diagrams

18
Fields

• public (public in Java) The field is
  accessible to any class.
• - private (private in Java) The field is only
  accessible within the class itself.
• protected (protected in Java) The field is
  accessible to the class itself, all the classes
  in the same package, and all its subclasses.
• package (leave blank in Java) The field is
  accessible to the class itself and all classes in
  the same package.

19
Fields, cont.

• A UML field has up to five components, as
  follows
• Visibility The scope of the field
• Type a base type or other class
• Name an identifier for the field
• Multiplicity If absent, then the field has
  exactly one value. Otherwise, lower .. upper,
  where lower and upper are integers or named
  constants.
• Initial value If present, preceded by .

20
Anatomy of a field

• Here are the five field components put together

-greetings1..3 Greeting Greeting.DEFAULT
Visibility (private)
Name (greetings)
Type (Greeting class)
Multiplicity (may have 1 through 3 greetings)
Initial Value (A static default)
21
Differences between UML and Java

• In UML, when something is left out, it is
  intentionally ambiguous, and that is considered
  acceptable. In Java, there is either an implicit
  default or an error. For example

22
Methods

• Methods have up to four components, two of which
  are required.
• Visibility optional
• Name required
• Parameters optional, though parentheses are
  required. Each parameter, if present, has a name
  followed by a colon followed by its type.
• Return type optional, though if present,
  preceded by a colon.
• Examples
• addCall()
• -getPerson(name String) Person

23
A Class PhoneState
24
Different Levels of Detail

• Express as much or as little detail as needed.
• Often, a rectangle with a name is enough.
• perhaps a method or an attribute clarifies.
• Simple is good.
• Sketches on paper or white board are effective.
• No defaults
• Missing information should not be assumed.

25
Outline

• Purpose of UML
• Class Diagrams
• Objects and Classes
• Fields and Methods
• Relationships Between Classes
• Advanced Notions
• Sequence Diagrams

26
Relationships

• There are three kinds of relationships in UML.
• 1) Dependency
• 2) Association
• 3) Generalization
• Understanding the semantics (meaning) of these
  relationships is more important than simply
  remembering the kinds of lines that UML uses.

27
1) Dependency A Uses Relationship

• Dependency
• Occurs when one object depends on another
• If you change one object's interface, you need to
  change the dependent object.
• Arrow points from dependent to needed classes.

Display
PhoneState
Calls
28
2) Association Structural Relationship

• An association models a relationship between
  classes that indicates some meaningful and
  interesting connection.
• Associations can be labeled with a
  hyphen-connected verb phrase which reads well
  between concepts.

association
Has-Home-Number
PhoneNumber
Person
29
Associations

• Associations imply that our knowledge that a
  relationship must be preserved for some time (1
  ms to forever).
• Fundamental question to ask Between what objects
  do we need to remember a relationship?
• UML associations
• Are modeled with a line between two classes,
• Can be named,
• Can be bi-directional, or have a direction
  indicated with an arrow,
• Can have a multiplicity, and
• Can have role names for one or both participating
  classes.

30
Association Names

• Read this as Type-VerbPhrase-Type.
• Note that we are not yet worrying about messages,
  instance variables, data flow, or objects.
• So a phone book contains a person who has a home
  phone number, which was called on a particular
  call.

PhoneBook
Contains
Called-On-In
Has-Home
PhoneNumber
Person
Call
31
Directionality

• Associations are assumed to be bi-directional, in
  that they can be read from either direction. For
  example, a phonebook contains a person and a
  person is contained in a phonebook.
• A direction is notated with a solid arrowhead
  with no tail. A phone number is called on in a
  call, but a call cant be called on in a person.

PhoneBook
Contains
Has-Home
Called-On-In?
PhoneNumber
Person
Call
32
Navigation

• Navigation is separate from directionality.
• An association may be navigable in one or both
  directions the default is both directions.
• A person can be reached from a phonebook, but the
  phonebook cannot be reached starting from a
  person.

PhoneBook
Contains
Has-Home
Called-On-In?
PhoneNumber
Person
Call
33
Multiplicity

• Multiplicity defines how many instances of type A
  can be associated with one instance of type B at
  any point in time.

Has-Home
Person
PhoneNumber
1
0..1
PhoneBook
Person
1

Called-On
PhoneNumber
ConferenceCall
1..5

A phone number can be associated with 0 to many
conference calls. A conference call must be to at
least one phone number, but could include up to
5 phone numbers.
34
Multiplicity

• The multiplicity specification is a
  comma-separated sequence of integer intervals,
  with meaning the entire range. They appear at
  each end of the association.

zero or more

T
"many"

1..
one or more
T
1..52
one to fifty two
T
5
exactly five
T
3, 5, 8
exactly three,
Rarely used, so no longer in UML 2
T
five or eight
35
Roles in Associations

• A role names the side of an association.
• Either or both sides can have a role.
• In this case, since the association is
  directional, it is not necessary to name one of
  the roles.

Person-Called?
Person
Call
WhichCalls
36
Aggregation A Special Association

• Aggregation is a whole/part relationship.
• An association models has-a relationships.
• The objects can exist independently of each
  other.
• No one object is more important than the other.
• Place an open diamond on the whole.
• This means that the PhoneState is composed of a
  PhoneBook (as well as other components, not
  shown).

PhoneState
PhoneBook
1
1
37
Composition A Special Association

• Composition is a stronger relationship than
  aggregation.
• The part object belongs to only one whole.
• The part objects live and die with the whole a
  part object cannot exist without its whole
  object.
• Denoted with a solid diamond.
• Model aggregation or composition? When in doubt,
  use association (just a simple line),

PhoneState
1
1
Person
PhoneBook
1

38
Association Classes

• Association classes allow you to add attributes,
  operations, and other features to associations.
• Here we track the number of cell-phone calls.

Has-Cell
Person
PhoneNumber
39
Outline

• Purpose of UML
• Class Diagrams
• Objects and Classes
• Fields and Methods
• Relationships between classes
• Dependency
• Association
• Aggregation
• Composition
• Association Classes
• Generalization
• Advanced Notions
• Sequence Diagrams

40
3) Generalization

• Generalization refers to defining a superclass
  that abstracts aspects from one or more
  subclasses.
• The subclasses inherit those aspects from the
  superclass.
• In this case, the subclasses inherit the number
  field.

PhoneNumber
number int
call()
LongDistance
Local
areaCode int
41
Generalization, cont.

• Here RegularCall and ConferenceCall share the
  When field and, indirectly, the association with
  PhoneNumber.

Call
whenDateTime
RegularCall
ConferenceCall


PhoneNumber
1
1..5
42
Outline

• Purpose of UML
• Class Diagrams
• Objects and Classes
• Fields and Methods
• Relationships between classes
• Advanced Notions
• Derived fields and associations
• Constraint Rules
• Interfaces and Abstract classes
• Packages
• Stereotypes
• Sequence Diagrams

43
Derived Fields and Associations

• numCalls is a derived field. It is computed via
  the Has-Cell association. (Note the /.)
• Person-Called is a derived association. It is
  computed via the Has-Cell and Called-On-In
  associations.

Has-Cell
PhoneNumber
Person /numCallsint
Called-On-In
/Person-Called?
numCalls count of Call
44
Constraint Rules

• Constraint rules are arbitrary predicates.
• (Note that multiplicity is just a special kind of
  constraint rule.)
• Constraint rules are specified in italics in
  brackets.
• There are also some predefined constraints.
• Immutability
• Ordering

numCalls ? 0
45
Immutability

• Immutability is a constraint that is usually
  applied to a field, a role, or a class.
• For a field or a role, immutability indicates
  that the value of that field or role may not
  change during the lifetime of the source object.
• For a class, immutability indicates that all
  roles and attributes associated with that class
  are immutable.
• Immutability is specified as with other
  constraint rules.

immutable
46
Ordered

• A multi-valued role is one whose multiplicitys
  upper bound is greater than 1.
• The default for such roles is that they are
  considered to be sets there is no ordering, and
  no duplicate target objects.
• Ordered is a constraint applied to a
  multi-valued role of an association that says
  there is an ordering (but no duplicates).
• Bag is a constraint that says there is no
  order, but there can be duplicates.

47
Outline

• Purpose of UML
• Class Diagrams
• Objects and Classes
• Fields and Methods
• Relationships between classes
• Advanced Notions
• Derived fields and associations
• Constraint Rules
• Immutability
• Ordering
• Interfaces and Abstract classes
• Packages
• Stereotypes
• Sequence Diagrams

48
Interfaces and Abstract Classes

• An interface is a class with no fields and no
  method implementation. It just provides method
  declarations.
• An abstract class has at least one method that is
  not implemented.
• Both are shown in UML through italics.

ltltinterfacegtgt VoiceTag
say()
Person
49
Packages

• Packages occur in class diagrams, or separately
  in package diagrams.
• A package is denoted with a small rectangle in
  the top-left corner.
• Here classes in Package 1 depend on class(es) in
  Package 2.

Package 2
Package 1
Class 1
Class 2
Class 3
50
Stereotypes

• A stereotype is a UML element that allows
  designers to extend the UML vocabulary.
• Stereotypes are shown in text between angle
  braces, e.g., ltltabstractgtgt.
• They are often used to distinguish an abstract
  class name from an interface.

ltltinterfacegtgt Iterator hasNext( )
boolean next( ) Object remove( ) void
51
Dynamic versus Static Generalization

• Dynamic generalization allows objects to change
  type within the subtyping structure.
• Static generalization does not. Static is
  assumed.
• Dynamic generalization is specified with the
  ltltdynamicgtgt stereotype.

PhoneNumber
number int
call()
ltltdynamicgtgt
Local
LongDistance
areaCode int
52
Java Phone Class Diagram
PhoneState
/MostRecentCall
0..1
Regular Call
/NumCalls int 0

numCalls ?0
1
0..1
1
Call
PhoneBook
Called-On_In?
when DateTime
/numPeople int 0
immutable
When called

getNumCalls () int
addPerson (Name String, Address String)
personIterator() Iterator
0..1
/PersonCalled?
Contains
Ordered
1..5
1..5
PhoneNumber
Person
Conference Call
Has-Home
Called-On_C

name readonly address String
number int
1
0..1
1
call( )
Has-Cell
getHome( ) PhoneNumber getCell( ) PhoneNumber
1
0..1
ltltdynamicgtgt
LongDistance
Local
areaCode int
Accumulator
numCalls int
53
Outline

• Purpose of UML
• Class Diagrams
• Objects and Classes
• Fields and Methods
• Relationships between classes
• Advanced Notions
• Sequence Diagrams

54
Sequence Diagrams

• Class diagrams show how classes are related
  statically. There is little dynamic activity
  shown (dependency is a very limited form of
  dynamic activity).
• Sequence diagrams, on the other hand, show
  dynamic activity.
• Sequence diagrams contain objects (instances of
  classes) rather than the classes themselves. The
  objects are lined up at the top of the diagram,
  with their activation lifetimes shown as dotted
  lines flowing down the page.

55
Sequence Diagram Symbols
Obj C
An Object
Flow of control
ltltcreategtgt
Creating an Object
Method (parameter)
Calling a method
Return from a method
56
Java Phone Sequence Diagram
aPhoneNumber
aPersonPerson
aPhoneState
getPerson( )
new( )
aCall
addCall( )
addCall( )
isCellPhone
57
Details of Sequence Diagrams

• Only pre-existing objects are shown at the top.
• A constructor results in the creation of a new
  object.
• Right-pointed arrows generally denote messages
  (method invocation).
• Self-delegation is when a class calls one of its
  own methods.
• Dashed arrows denote message return, and have an
  open arrow, unless it is self-delegation.
• Return arrows are not required. Use them only
  when they improve clarity.
• A condition is given in brackets .

58
State Diagrams

• A state is a condition or situation in the life
  of an object during which It satisfies some
  condition, performs some actions, or waits for
  some events.
• A transition is a relationship between two states
  indication that an object in the first state will
  perform certain actions and enter the second
  state

59
Java Phone State Diagram
On
Standby
power-on
incoming call
keypad-unlock
keypad-lock
end
off
Active
ignore
0-9
Dialing
Ringing
connection-fail
power-off
talk
Connecting
keypad-unlock
Entry LCDOn() Exit LCDOff()
Talking
connection-succeed
60
Coupling

• Coupling A measure of how strongly one class is
  connected to, has knowledge of, or relies upon,
  other classes.
• Low coupling class is not dependent on too many
  other classes, which is good
• High coupling class is dependent on too many
  others--bad
• A change to one class forces changes in others.
• More difficult to understand a type in isolation
• Assign responsibilities so that coupling remains
  low.

61
High Coupling

• Here the Person class needs to know the interface
  of two classes, RegularCall and ConferenceCall.

PersonCalledReg?
Regular Call
Person
name readonly address String
PersonCalledCC?
Conference Call
62
Alternative Design

• Here we use a superclass, so that Person now only
  knows about one class, Call.
• The coupling is thus reduced.

Regular Call
Person
Call
PersonCalled?
name readonly address String
when DateTime
immutable
Conference Call
63
Try to Keep Coupling Low

• Common forms of coupling
• Class A has an instance of Class B
• Class A send a message to an instance of Class B
• Class A is a subclass of Class B (inheritance)
• Class A implements interface B
• So coupling does occur, in any object-oriented
  program.
• Reasons for keeping coupling low reusability and
  modularity of code.

64
High Cohesion

• Cohesion A measure of how strongly related and
  focused the responsibilities of a class are.
• High functional cohesion is good.
• Low cohesion can be bad.
• Hard to understand
• Hard to reuse
• Hard to maintain
• Fragile constantly affected by change
• Assign responsibilities so that cohesion remains
  high.

65
High vs. Low Cohesion

• High functional cohesion exists when the elements
  of a class all work together to provide some
  well-bounded behavior
• -Grady Booch
• Examples of low cohesion
• One class is responsible for many things in
  different functional areas.
• Example Model arranges views, builds menus,...
• One class has sole responsibility of one complex
  task in one functional area.
• Example PhoneBook keeps track of persons,
  previously called numbers, games downloaded, ...

66
High Cohesion

• A class has moderate responsibilities in one
  functional area and collaborates with other
  objects to fulfill tasks
• Example PhoneBook just contains Person objects,
  each of which in turn has one or more
  PhoneNumbers.

67
Benefits of High Cohesion

• Design is clearer and more easily understood.
• Maintenance (bug fixes, enhancements, changing
  business rules) is easier.
• The fewer classes you touch the better -Adele
  Goldberg
• High cohesion can help you lower the coupling.

68
Summary

• We study two kinds of diagrams class and
  sequence
• Class diagrams contain classes sequence diagrams
  contain objects.
• Class diagrams have no orientation (left-right,
  top-down). In sequence diagrams, time goes down,
  messages usually go right, and returns go left.
• There is usually one class diagram but many
  sequence diagrams (generally one per use case).
• There are lots of other kinds of diagrams in UML,
  e.g., activity, collaboration, concurrent state,
  collaboration, deployment, state, use case.