Class%20Diagrams

1
Class Diagrams

• ASSOCIATION relationships between instances of a
  classes, e.g., customer places order, employee
  works for company
• Each association has two roles
• Each role has multiplicity

2
1
A
B
Only one B is associated with an A
1..
A
B
One or more instances of B are associated with an
A
0..1
A
B
0 or 1 instance of B is associated with an A

A
B
An A is associated with 0 or more instances of B
3
1..3
A
B
1, 2, or 3 instances of B are associated with an A
The arrow head on the association implies
navigability. In this example, we can determine
the customer from the order
4
Implementation Model for two-way navigability
class Order private Customer
_customer private Vector _orderlines .......
class Customer private Vector _orders
..........
5
Interfaces and Abstract Classes

• An interface contains abstract methods and its
  member variables are static and final. It is
  primarily a collection of method signatures
• An abstract class can have method implementations
  as well as variables that are not static and final

6
(No Transcript)
7
Qualified Association
Typically implemented using maps, hashtables, and
the like
8
SPECIFICATION PERSPECTIVE ........ class Order
public OrderLine lineItem(Product
aProduct) public void addLineItem(Number
amount, Product forProduct) IMPLEMENTATION
PERSPECTIVE class Order private Dictionary
_lineItems
9
Association Class

employer
PERSON
COMPANY
0..1
ASSOCIATION CLASS
Employment
period dateRange
10
T
Set
TEMPLATE CLASS
insert(T)
remove(T)
ltltbindgtgt
ltEmployeegt
EmployeeSet
11
IMPLEMENTATION..... class Set ltTgt void insert
(T newElement) void remove (T
anElement) ........ Declare..... SetltEmployeegt
employeeSet
12
Value Versus Reference Semantics

• Identity
• Sharing
• Cardinality
• Direction of navigation

13
Aggregation and Composition

• Aggregation represents a has-a relationship and
  may be used to model whole/part relationships

14
Aggregation Versus Composition

• In aggregation, there is no link between the
  lifetimes of the whole and its parts
• An aggregation is semantically stronger than an
  association
• A part in an aggregation can be shared by other
  wholes
• Meaning of navigation is the same as in an
  association

15
Composition

• Semantically stronger than an aggregation
• Characterized by coincident lifetimes of the
  whole and its parts
• Object can be a part of only one whole

16
Reflexive Association
17
Ternary Associations
18
Attribute Syntax

• The syntax of an attribute in the UML is
• visibility name multiplicity type
  initial value
• property string
• Visibility , - , or (public, private,
  protected)
• multiplicity refers to the number of the
  instances of the attribute in
  the class
• type data type

19
Property String

• changeable (default) value can be modified
• addOnly values can be added, but not removed or
  changed
• frozen value cannot be changed after object
  initialization

20
Syntax for Operations

• The UML has the following syntax for an
  operation
• visibility name (list of parameters)
  return type
• poperty string
• Syntax for each parameter is
• direction name type default value
• direction may be in, out, or inout

21
Property Strings for operations

• isQuery
• sequential
• concurrent
• guarded

22
Inheritance

• Generalization versus Specialization
• Visibility is determined by access directives
• Public fields are not good, protected is somewhat
  better, and private is perhaps the best

23
Type Promotion (upcasting)
class X public static void f(Vehicle v)
v.run() // Safe type promotion class X
public static void f(Vehicle v)
v.race() // will not work! why? what is the
solution?
Vehicle
vehicleID
run()
Automobile
race()
24
class Y public static void g(Vehicle v)
Automobile a (Automobile) v a.race()
What will this piece of code do if we pass an
instance of a Truck? class Y public static
void g(Vehicle v) if (v instanceOf
Automobile) Automobile a (Automobile)
v a.race()
25
Polymorphism and Dynamic Binding
26
Advantages of Polymorphism

• Client knows only about the superclass
• Changes to the subclasses do not affect the
  client as long as the interface is unaltered
• In some languages, recompilation may not be
  necessary if there are changes to the subclass
  that do not affect the interface presented to the
  client
• Pluggability

27
Class Specialization

• A subclass may specialize its superclass either
  through extension (Java, C) or by restriction
  (C)
• Extension happens when
• 1) You add a new behavior
• 2) You override an existing behavior
• 3) You add state information (value or reference)

28
Dependency

• Dependency may be used to model
• 1) A refinement of a design feature (remember
  ltlttracegtgt?)
• 2) Instantiation of a template
• 3) A refinement of an association
• A dependency is used to show a using
  relationship
• Examples include bind, derive, instantiate,
  friend, instanceOf, refine, access, import,
  become, etc.,

29
Notes

• Notes are often attached to elements on a diagram

30
Extension Mechanisms

• Extension mechanisms are provided to accommodate
  differences among OO languages
• Annotation mechanisms include specifications and
  adornments
• Extension mechanisms permit the designer
  tointroduce new properties, constraints,
  stereotypes, and the like

31
Extension mechanisms

• Specifications are often descriptions that appear
  in a document that is not part of the UML
  diagram, but may be hyperlinked to one
• A graphical representation of text is called an
  adornment, e.g., stands for public
• Properties are expressed as tag-value pairs,
  e.g., Date created 12/11/00
• The tag or value may be implied at times

32
Constraints

• Constraints are rules that cannot be violated

or
33
Stereotypes

• Stereotypes appear in guillements (e.g.,
  ltltactorgtgt)
• Stereotypes may be used with any UML construct -
  with specialization relationships, dependency
  relationships, refinements, plain associations,
  etc.,

34
Class Diagram for Order Processing
0..1
ltltactorgtgt Telephone Agent
Order
1
Product Catalog
1
Item Number
Order Registry
order

1..
Customer Catalog
Catalog Item
Line Item
1

1
name, phone
1
Customer

35
(No Transcript)
36

• Dynamic Diagramming Notation

37
Static and Dynamic Views
38

• A scenario is an instance of a use case, i.e., it
  is one pass through the use case
• Use cases are described using
• 1) A textual description
• 2) Activity diagrams

39
Textual Description

• Start with a general description
• Factor if necessary
• Provide details of steps - main flows,
  alternative flows including exceptions

40
Interaction Diagrams

• Interaction diagrams are used to object
  interaction in a scenario
• They are graphical

message()
41
Interaction Diagrams

• An instance of class A sends a message to an
  instance of class B
• message() would correspond to a method defined in
  class B

message()
42
Interaction Diagrams

• There are two types of interaction diagrams
• Collaboration Diagrams emphasize links between
  objects and help one to visualize the structural
  organization of objects
• Sequence Diagrams emphasize the time ordering of
  messages

43
Interaction Diagram features

44
(No Transcript)
45
(No Transcript)
46
Branching
condition true x()
condition false f()
47
(No Transcript)
48
Object Creation and Destruction
49
A
B
1 x()
2 new()
C
50
Timing Constraints
A
B
x
y
y - x lt 5 ms
51
State Machines

• May be used to model the dynamics of a system
• Used to model the behavior of a single object
  across all scenarios
• Useful for specifying the states that an object
  goes through in its lifetime, what triggers the
  transition, and how the object responds to those
  events that trigger the transition

52

• State machines are useful for objects that
  exhibit meaningful state-based behavior, i.e.,
  when an objects response to events depends on
  the state that it is in and when it is possible
  for the object to pass through a set of states
  (some of which may be meaningful), or when the
  order of execution of an objects methods is
  important

53
State Machines

• A state is a particular condition that an object
  (with specific values for its attributes and
  links) is in during which time it may perform
  some activity or wait for the occurrence of an
  event
• Transitions from one state to another are
  triggered by events
• An event may be a signal (e.g., a hardware
  interrupt) or a message (e.g., the invocation of
  a method)

54
State Machines

• Activities may be performed by an object when it
  is in a particular state
• Time for an activity is not negligible
• Transitions are assumed to be instantaneous
• Actions carried out during transitions,
  therefore, take very little time

55
Parts of a state (Booch et al., 1999)

• Unique name (a string) - it could also be
  anonymous
• Entry and exit actions
• Transition to self, i.e., it remains in the same
  state
• Substates - nested structures which may involve
  sequential or concurrent substates
• Deferred events - queued to be handled by the
  object when it is in a different state

56
States

• Initial state is represented by a filled black
  circle
• Final state is represented by a filled black
  circle surrounded by a circle
• Initial and final states are called psuedostates

57
Triggers for Transitions

• When an event/message is received
• Event/message and a guarding condition occur
• A condition becomes true
• A certain amount of time elapses
• A triggerless transition may occur when the
  source state completes its activity

58
Receipt of events

• Two possible states of a Book class

return
NotAvailable
Available
59
Message and a guard condition

• Two possible states of a Book class

return ! onHold
NotAvailable
Available
60
Condition becomes true
when (numberAvailable 0)
Available
NotAvailable
61
Transition after a certain time

• Possible states of a VCR

PowerOff
Stopped
after(60 seconds)
62
Actions during a transition
allocateFromInventory(quantity) quantity gt
currentInventory warehouse.backorderItem(item,
rorderQuantity)
when (currentInventory 0 )
warehouse.backorderItem(item, rorderQuantity)
BackOrdered
Available
itemAvailable(quantity) / currentInventory
quantity
63
Composite States
64
(No Transcript)
65
History States
H
continue
66
Shallow and Deep History

• The H is for shallow history, which is all right
  for one level of nesting
• Shallow history does not remember down to the
  innermost nested state
• Use deep history, represented by a H, to
  remember down to the innermost nested state

67
Parallel State Machines
0)
....
68
Parallel State Machines

• Each of the two state machines (one for the
  Inventory and the other for the Catalog) executes
  in parallel
• Parallel state machines normally imply a lack of
  cohesion for the class
• In this example, management of inventory could be
  moved to a separate class ( remember Inheritance
  Coupling? from chapter 4)

69
Parallel States
Fork - both states entered at the same time