Software Development and UML

1
Software Development and UML

• Nick Hsueh
• 3/27/2003

2
Modeling Elements

• Structural elements
• class, interface, collaboration, use case, active
  class, component
• Behavioral elements
• interaction, state machine
• Grouping elements
• package, subsystem
• Other elements
• note

3
Introduction of UML

• The Importance of Modeling
• Object-Oriented Modeling
• An Overview of UML
• Software Development Life Cycle
• Hello, World!

4
The Importance of Modeling

• What is a model?
• a model is a simplification of reality
• Why do we model?
• we build models so that we can better understand
  the system we are developing
• we build models of complex systems because we
  cannot comprehend such a system in its entirety
• four aims to achieve
• help us to visualize a system
• permit us to specify the structure/behavior of a
  system
• give us a template that guides us in constructing
  systems
• document the decisions we have made

5
Object-Oriented Modeling

• Different models are organized for their foci
• algorithmic perspective
• focus on control and the decomposition of larger
  algorithms into smaller ones (functional
  decomposition)
• not easy to maintain
• object-oriented perspective
• the main building block is object or class
• user interface layer buttons, menus, dialog
  boxes
• middle layer higher-level views of problem
  entities, such as customers, products and orders
• database layer tables representing entities from
  the problem domain, including customers,
  products, and orders
• Visualizing, specifying, constructing, and
  documenting object-oriented systems is exactly
  the purpose of UML

6
create a meeting
attend a meeting
participant
initiator
cancel a meeting
functional decomposition
object decomposition
Case A
System
A
D
Case A
Case B
Case C
Case B
Case D
B
Case C
function
Case D
function
function
G
Z
C
F
function
function
E
7
An Overview of UML

• Unified Modeling Language
• a object-oriented modeling language, rather than
  a modeling method
• support different perspectives for constructing a
  base model
• a language for
• visualizing an explicit model facilitates
  communication
• specifying a precise, unambiguous, and complete
  model
• constructing mapping UML models to programming
  language
• documenting requirements, architecture,
  analysis, design,

8
Conti.

• History
• end of 1994, Rumbaugh and Booch
• 1995, Jacobson
• Oct, 1997, publication of UML1.1

Jacobson, OOSE
Rumbaugh, OMT
Booch, OOD
Requirement Elicitation
Object-oriented Analysis
Object-oriented Design
9
Conti.
Use Case View Logical View Physical
View Deployment V.
Focus
Expression of requirements
Expressing Behavior
Implementing Objects and Classes
Deployment of Executable Code
Representing Structure
class diagrams
use case diagrams
statechart diagrams
component diagrams
Involving Diagram
object diagrams
sequence diagrams
deployment diagrams
activity diagrams
collaboration diagrams
Actors Use cases Classes Collaborations
Objects Classes Collaborations Interactions Catego
ries
Modules Subroutines Tasks Subsystems
Nodes Modules Main Programs
Major Modeling Components
UML Uses Various Diagrams to Model the System
from Different Perspectives
10
Diagram

• A diagram is a view of a model
• Presented from the aspect of a particular
  stakeholder
• Provides a partial representation of the system
• semantically consistent with other views
• There are 9 standard diagrams
• Use case diagram
• Class (object) diagram
• Behavior diagram
• activity, collaboration, sequence, state
• Implementation diagrams
• Component, Deployment

11
Conti.

• Use case diagrams
• Describe the functional behavior of the system as
  seen by the user, that is I.e. how to use the
  system
• Illustrate actors, use cases, and their
  relationships
• Class diagrams
• Describe the static structure of the system
  Objects, Attributes, and Associations.
• Shows classes and their relationships with each
  other.
• Activity diagrams
• Model the workflow of the system.
• Shows activities, object states, states, state
  transitions, and events.
• Collaboration diagram
• Shows objects and their relationships, including
  their spatially structure message exchange

12
Conti.

• Sequence diagrams
• Describe the dynamic behavior between actors and
  the system and between objects of the system.
• Illustrate objects and their relationships,
  including their chronologically structured
  message exchange
• State diagrams
• Describe the dynamic behavior of an individual
  object as a finite state machine.
• Illustrate state, state transitions, and events
• Component diagram
• Illustrate components and their relationships
• Deployment diagram
• Illustrate components, nodes and their
  relationships

13
Software Development Life Cycle
Inception
Elaboration
Construction
Transition
Process Workflow
Business modeling
Requirement capturing
Analysis and design
Implementation
Test
Deployment
Supporting Workflow
Configuration and change management
Project management
Environment
Preliminary iteration(s)
Iter 2
Iter n
Iter n1
Iter n2
Iter m1
Iter 1
Iter m
14
Phase 1 Inception

• Objective
• risk Management
• commercial risk can the competition capture the
  market before the product is ready
• financial risk does the corporation have
  sufficient financial capacity to take the project
  to completion?
• technical risk is the technology foundation
  solid and proven?
• development risk is the team sufficiently
  experienced?
• development team assembling
• progress measurement

15
Conti.
Main Recurring Risks, and Actions to Reduce them
16
Conti.
Financial advisor
Analyzer
End user
Technical consultant
Software development
Project manager
Quality checker
Project Leader
Documentalist
System administrator
Development Team Assembling
17
Conti.

• A rough progress is scheduled

18
Phase 2 Elaboration

• Objective
• requirement elicitation
• analyze the problem domain
• use case capturing and modeling requirements
• structural model modeling requirements and
  domain knowledge
• hardware architecture analysis
• establish a sound architectural foundation
• develop the project plan
• define the priority of requirements
• define the deadline of functions

19
Conti.

• Using Rational Rose to analyze your system
• use case model
• requirements capturing/modeling
• class diagram
• model conceptual objects and their relationships
• database analyzing
• sequence diagram
• interactions between objects
• deployment diagram
• hardware architecture

20
Phase 3 Construction

• Objective
• developing a software product ready for
  transition
• flesh out the design
• complete the implementation
• test the software
• document
• Iterative cycle
• each iteration results in the delivery of an
  execution prototype
• for each iteration
• identify the scenario in the iteration
• assign the precise task to development team to
  complete
• define the evaluation criteria

21
Conti.

• Objective
• deploy the software to the user community
• adjust the system
• correct some undetected problems
• finish some features that have been postponed
• The difficulty of the transition phase is
  inversely proportional to the quality of the
  product
• all products require training
• product installation phase should not be
  neglected
• for a replacement system, a lot of effort is
  necessary to put the new system into place in
  parallel with the existing system

22
Getting Started -- Hello, World!
Container
Panel
Applet
Import java.awt.Graphics class HelloWorld extends
java.applet.Applet public void paint
(Graphics g) g.drawString (Hello, World!,
10, 10)
HelloWorld
Paint()
Graphics
Java Code
Class Diagram
applet
awt
lang
Package Diagram
23
Hello, World!
Thread
Toolkit
ComponentPeer
ComponentPeer
run
run
callbackLoop
handleExpose
paint
Sequence Diagram
24
Hello, World!
HelloWorld.Class
hello.java
hello.html
hello.jpg
25
Use Case Diagram
26
Use Case Diagram

• A graph of actors, a set of use cases, possibly
  some interfaces, and the relationships between
  these elements.
• The relationships are associations between the
  actors and the use cases, generalizations between
  the actors, and generalizations, extends, and
  includes among the use cases.
• The use cases represent functionality of a system
  or a classifier, like a subsystem or a class.
• Developed by analysts and domain experts

27
Use Case Diagram

• Purposes of use case diagram
• Describe the interaction between a set of use
  case and the actors
• Capture system functionality as seen by users
• Used during requirements elicitation to represent
  external behavior of system
• Drive implementation and generate test cases

??????????
28
Use Case Diagram
Package
SimpleWatch
Actor
ReadTime
SetTime
WatchUser
WatchRepairPerson
Use case
ChangeBattery
29
Actors

• An external entity communicates with the system
  by sending and receiving messages, and exchanging
  data and events.
• user, external system, physical environment, a
  user of the system
• A description to represent roles that play the
  system functions
• A person can play a number of roles (actors)
• Examples
• Passenger A person in the train
• ATM the client is an actor who can withdraw
  money from an account, transfer money to an
  account, or check balance of an account

30
Actors

• Notation
• Textual stereotyping
• Visual stereotyping
• Textual and visual stereotyping
• Generalization/specialization

ltltactorgtgt Customer
ltltactorgtgt Customer
Home insurance clerk
Car insurance clerk
Field service clerk
31
Use Case

• A use case representing a coherent unit of
  functionality provided by a system, a subsystem,
  or a class.
• A sequences of messages exchanged among the
  system and the actors together with actions
  performed by the system.
• A scenario that describes a thread of usage for
  a system
• Describe a set of activities of a system from the
  point of view of its actor
• Be always initiated by an actor
• Extension points may be listed in a compartment
  of the use case with the heading extension
  points.
• The name of an abstract use case may be shown in
  italics.

32
Use Case Structure

• A use case can be described as the
  content-related structuring text
• Unique name of use case
• Participating actors
• Entry conditions, preconditions
• Exit conditions, post conditions
• Invariants conditions must always be satisfied
• Special requirements, non-functional requirements
• Flow of events, process description
• Exceptions, error situations
• Variations deviations and exceptions from the
  normal process and description of alternative
  process for these case.

33
The Relationships of Use Case

• Extend (A to B)
• B is extended (for specific conditions) by the
  behavior of A. The behavior of A is inserted at
  the extension point in B.
• The direction is to the extended use case
• Include (C to D)
• C contains the behavior of D.
• To extract identical section occurring in several
  use cases in order to prevent redundancy.
• The direction is to the using use case
• Generalization (E to F)
• E is a specialization of F.

34
Explorative prototypes

• To communication with users
• Concrete screen dialog
• Business forms
• Sample print-outs
• Visual material

35
Developing a Use Case

• What are the main tasks or functions that are
  performed by the actor?
• What system information will the the actor
  acquire, produce or change?
• Will the actor have to inform the system about
  changes in the external environment?
• What information does the actor desire from the
  system?
• Does the actor wish to be informed about
  unexpected happens?

36
Use Case Example(1)

• Name Purchase ticket
• Participating actor Passenger
• Entry condition
• Passenger standing in front of ticket
  distributor.
• Passenger has sufficient money to purchase
  ticket.
• Exit condition
• Passenger has ticket.

• Event flow
• 1. Passenger selects the number of zones to be
  traveled.
• 2. Distributor displays the amount due.
• 3. Passenger inserts money, of at least the
  amount due.
• 4. Distributor returns change.
• 5. Distributor issues ticket.

Anything missing?
37
(No Transcript)
38
(No Transcript)
39
Use Cases Example(2)

• ATM. The client (actor) can withdraw money from
  an account, transfer money to an account, or
  check the balance of an account. These
  operations, correspond to flows, which can be
  represented by use cases.

40
Use Case Example(3)
41
Process

• Modeling requirements in terms of use cases
• establish the context of the system (by
  identifying the actors that surround it)
• for each actor, consider the behavior that each
  expects or requires the system to provide
• construct these common behaviors as use cases
• factor common behavior into new use cases that
  are used by others (organizing)
• adorn these use cases with notes that assert
  nonfunctional requirements

42
Structural Diagram

• Class Diagram
• Object Diagram
• Package Diagram

43
Structural Diagram

• Diagrams let you visualize, specify, construct,
  and document the things that live in your system,
  including
• classes, objects, interfaces, components, nodes,
  and use cases and their instance, together with
  the way those things sit in relationship to on
  another

UML diagram
Deployment
Class
Object
Sequence
Use case
Activity
Collaboration
Statechart
44
Class

• A class diagram express the static structure of a
  system, in terms of classes and relationships
  between those classes

Instance of


Class
Links
Links


Association
Instance of
Class diagram
Object diagram
A meta-model of Class Diagram
45
Class

• Attribute
• Operation
• Organizing attribute and operations

attribute
public
stereotype
protected
private
operation
46
Class

• Visibility
• public
• any outside classifier with visibility to the
  given classifier can use the feature
• protected
• any descendant of the classifier can use the
  feature
• private
• only the classifier itself can use the feature

public
protected
private
47
Class

• Scope
• instance
• each instance of the classifier holds its own
  value for the feature
• class
• there is just one value of the feature for all
  instances of the classifier
• ltltutilitygtgt classes are class scoped

48
Mapping to Java Programming
Frame
Header FrameHeader uniqueID Long
49
Class

• Multiplicity
• sometimes, youll want to restrict the number of
  instances a class may have
• utility class has zero instances

Math ltltutilitygtgt
Singleton Class
Utility class
multiplicity
ControlRod 3
50
Mapping to Java Programming
51
Class

• Each UML model element may have one or more
  stereotypes when the basic semantics of the
  elements are not sufficient

View A ltltinterfacegtgt
Employ ltltpersistencegtgt
place such order
Math ltltutilitygtgt
ltltextendgtgt
set priority
52
Class -- UML and Java

• Mappting to Java Code

class ToolBar protected Tool
currentSelection protected int toolCount
public void pickItem(int i)
public void addTool(Tool t)
53
Abstract Class

• A class can not be instantiated

RectangularIcon
Abstract class
Height Integer
54
Abstract Class UML and Java
abstract class RectangularIcon int Height
class Button extends RectangularIcon
void Display() class final
MyButton extends Button void Display()

RectangularIcon
Height Integer
MyButton ltltfinalgtgt
Display()
55
Interface class

• Interface class describe the externally visible
  behavior of model elements
• Interface class is an abstract classes which
  define abstract operations
• Contain only operations
• Interface class can extend several other
  interfaces
• A common class can implement several interface
• The different interfaces do not contain
  homonymous signatures
• make the interface concept more powerful, to
  specify constraints for each signature
• Precondition
• Postcondition
• Invariants
• Exported exceptions

56
Interface class

• Realization relationship

ltltimplementsgtgt
ltltinterfacegtgt Sortable isEqual(String)Boolean
String isEqual(String)Boolean Length()Integer
String isEqual(String)Boolean Length()Integer
Sortable
57
Interface class

• dependency relationship
• SortedStringList as the interface user is only
  dependent on the operation of the String class

String isEqual(String)Boolean Length()Integer
ltltusegtgt
SortedStringList
Sortable
58
MetaClass

• Classes of class objects (underline for operation
  and attribute)
• A class operation is new
• A class attribute is numberOfInstances

ltltinstance ofgtgt
59
Parameterized Class

• Template class (in C)
• With generic formal parameters

iElement
WaittingRoom
WaittingQueue
ltltbindgtgt(patient)
Add() Remove()
ltltbindgtgt(Car)
TrafficJam
60
Utility Class

• Collections of global variables and functions
• Math class in Java

ltltutilitygtgt Math Pi Sin() Cos()
61
Object

• An Object is a unit which actually exists and
  acts in the current system, a phenomenon.
• An alternative term is instance
• The name of an instance is underlined and can
  contain the class of the instance.
• The attributes are represented with their values.
• Multiple classification an object is an instance
  of more than one class
• Dynamic classification an object can became an
  instance of more than one class

aCircle Circle radius25 Center (10,10)
62
Relationship

• Very few of classes stand alone
• Kinds of relationships
• dependency, generalization, association

1 one and only one 0..1 zero or
one m..n from m to n from zero to any
positive integer 1.. from one to any
positive integer
multiplicity
child
role
qualifier
1

User
Password
association navigation
63
Relationship

• Association
• a structure relationship that specifies that
  objects of one thing are connected to objects of
  another
• four adornments name, role, multiplicity,
  aggregation

role
employer
employee
Company
Person
multiplicity
Company
Person
100..
1..2
aggregation
Department
64
Association

• Mapping to Java Code

work for
Company
Person
65
Association

• Navigation
• Qualification

1

Company
Person
owner
association navigation
B
B
parent
1
qualifier
B
B
first name
Person
with qualifier
without qualifier
0..1
mother/dad
child
A
66
Association

• Association class
• an association may have properties, operations

1

Company
Person
owner
Association class
67
Mapping to Java Programming
68
Association

• Constraint

1

Person
Company
Person
owner
Manager
Employer
Department
manage
exclusive-or
work
salary gt40000
69
Constraints

• OR

has ?
Domestic Address
Person
OR
Foreign Address
has ?

• Values

Rectangle a agt0 b bgt0

• Oredr

Person lastName firstName
1 contains ? 1..
ordered lastName
NameList
70
Dependency

• A using relationship that states that a change in
  specification of one thing may affect another
  thing that use it
• e.g., a class uses another class as a parameter
  to an operation

CourseSchedule
Add (c Course) remove (c Course)
Course
ltltinstanceOfgtgt
ltltfriendgtgt
Iterator
Data Stru.
71
Dependency

• Mapping to Java Code
• Objects as arguments
• Create your own objects
• Objects on-the-fly
• An object is created in a method

72
Generalization
specialization
generalization
abstract operation (in C, virtual operation)
abstract class
generalization
RectangularIcon
ArbitraryIcon
concrete operation
Height Integer
Edge LineCollection
isInside()
Concrete class
73
Composition

• Containment
• Strong aggregation
• physical composition
• The same life cycle
• Aggregation
• Weak aggregation
• Logical composition
• a-part-of (APO)
• A-kind-of vs. a-part-of

74
Curriculum
Course
aggregation
Car
containment
Engine
75
Composition

• Contained objects are usually hidden from other
  objects

Car
Engine
Object
Text
AlignText
Label
76
Package

• Software Architecture
• dog house/house/high rise
• packages are chucks for organizing a model

77
Architecture Modeling (Package Diagram)
ltltFrameworkgtgt Widgets
ltltCategorygtgt User Interface
ltltinterfacegtgt
ltltproxygt
ltltFrameworkgtgt Control Command
ltlt Category gtgt Machine tools
ltlt Category gtgt Instructions
ltltcontrolgtgt
ltlt Category gtgt Comms
ltlt Category gtgt Persistence
ltltpersistencegtgt
ltlt Category gtgt Operating System
78
Mapping to Java Programming
79
Behavior Diagrams

• Statechart Diagram
• Activity Diagram
• Collaboration
• Sequence Diagram

80
Behavior Modeling

• Object dont just sit idle, they interact through
  messages passing
• An interaction is a behavior that comprises a set
  of messages exchanged among a set of objects
  within a context to accomplish a purpose

UML diagram
Deployment
Class
Object
Sequence
Use case
Activity
Collaboration
Statechart
81
Statechart Diagram

• Modeling objects behavior by a statechart diagram
• States
• each object is in a particular state at a given
  point time
• a state is the image of an combination of the
  values in the objects attributes, and the
  presence or the absence of links from the given
  object to another object
• Events
• a event is a trigger to go from one state to
  another
• Transitions
• The passing from one state to another is
  performed when a transition is triggered

82
Statechart Diagram
entry/op2 do/op3 AnEvent/op4 exit/op5
entry/op6 do/op7 AnEvent/op8 exit/op9
op6
op1
event/action
event/action
event/action
final state
initial state
Transition
83
Generalization of states
A
B

C
push R
Transition
Reverse
Neutral
push N
push F
push R
Forward
upshift
upshift
First
Second
Third
stop
downshift
downshift
84
Statechart Diagram

• Aggregation of states

X
Y
A
Z
B
Accelerator
Brake
OFF
OFF
Transition
depress accelerator
release accelerator
release brake
depress brake
ON
ON
85
Mapping to Java Programming

• Find a class in Java API, describe its behavior
  by using statechart

86
Interaction Diagram

• Representation
• focus on time ordering
• sequence diagram
• focus on structural organization of the objects
• collaboration diagram
• SD and CD are largely isomorphic, and some
  visually different
• Tips
• A well-structured interaction
• simple
• interact in a clear context
• understandable (no obscure semantics)
• When you are drawing an interaction
• choose an emphasis (time ordering / context)
• show only properties important to the interaction

87
Collaboration Diagram

• Captures dynamic behavior (message-oriented)
• Purpose
• Model flow of control
• Illustrate coordination of object structure and
  control

88
Sequence Diagram

• Used during requirements analysis
• To refine use case descriptions
• to find additional objects (participating
  objects)
• Used during system design
• to refine subsystem interfaces
• Classes are represented by columns
• Messages are represented by arrows
• Activations are represented by narrow rectangles
  to sent the message, and is as long as all nested
  activations
• Lifelines are represented by dashed lines
• Purpose
• Captures dynamic behavior (time-oriented) in
  terms of interactions.
• Model flow of control
• Illustrate typical scenarios
• Complement the class diagrams which represent
  structure.

89
Sequence Diagram
Object
Message
Activation
90
Sequence Diagrams Nested Messages
TicketMachine
Passenger
selectZone()
ZoneButton
TarifSchedule
Display
selectZone()
lookupPrice(selection)
insertCoins()
displayPrice(price)
pickupChange()
Dataflow
pickUpTicket()
91
Sequence Diagram
92
Sequence Diagram
93
Interaction Diagram

• Message
• call / return / send / create / destroy

Prototypical instance
named instance
c Client
P PlanningAssistant
ltltcreategtgt
TicketAgent
(create)
setltinerary(i)
(call)
caculateRoute()
(call, local invocation)
route
ltltdestroygtgt
(destroy)
notify()
(send)
94

• Control structure
• centralized control
• decentralized control

A
B
C
D
A
B
C
D
Centralized Control
Decentralized Control
95
Activity Diagrams

• A special case of a state chart diagram in which
  states are activities (functions)
• Purpose
• Model business workflows, flow control within a
  system, and operations
• Captures dynamic behavior (activity-oriented)
• Three types of states
• Action state
• Cannot be decomposed any further
• Happens instantaneously with respect to the
  level of abstraction used in the model
• Activity state
• Can be decomposed further
• The activity is modeled by another activity
  diagram
• object state

96
Activity Diagram Modeling Decisions
lowPriority
Open
Allocate
Incident
Resources
fire highPriority
not fire highPriority
Notify
Fire Chief
Object State
Notify
Police Chief
97
Activity Diagrams Modeling Concurrency

• Synchronization of multiple activities
• Splitting the flow of control into multiple
  threads

98
Activity Diagrams Swim lanes

• Actions may be grouped into swim lanes to denote
  the object or subsystem that implements the
  actions.

Dispatcher
FieldOfficer
99
Event

• Event is a significant occurrence that has a
  location in time and space
• external event
• passing between the system and its actors
• e.g., pushing buttons
• internal event
• passing among the objects that live inside the
  system
• e.g., an overflow exception

100
Event

• Kinds of Events
• signal event
• dispatched asynchronously by one object and then
  received by another
• exception
• call event
• dispatch of an operation
• time event
• passing of time
• e.g., after 2 seconds
• change event
• a change in state or the satisfaction of some
  condition
• e.g., when altitude lt 1000

101
Event

• Signal

102

• Mapping to Java Code
• Study the classes in java.object.event, use UML
  to model them
• Describe why is modeled like that?

103
Implementation Diagrams
104
Component Diagram

• Captures the physical structure of the
  implementation
• Built as part of architectural specification
• Purpose
• Organize source code
• Construct an executable release
• Specify a physical database
• Developed by architects and programmers

UML diagram
Deployment
Class
Object
Sequence
Use case
Activity
Collaboration
Statechart
105
Component

• Logical things live in the conceptual world /
  physical things live in the world of bits
• A component is a physical and replaceable part
  of a system that conforms to and provides the
  realization of a set of interfaces
• physical packaging of logical element, such as
  classes, interfaces, and collaboration
• e.g., executables, libraries, tables, files, and
  documents
• Good components define crisp abstracts with
  well-defined interfaces

106
agent.java
fraudagent.dll
component
class
FraudAgent
FraudPolicy
PatternSearch
image.java
component.java
dependency
interface
realization
ltltinterfacegtgt ImageObserver
realization
image.java
component.java
realization
abort int error int
imageUpdate()
107
Component Diagram
108
Deployment Diagram

• Captures the topology of a systems hardware
• Illustrate the structure of the runtime system,
  including the configuration of runtime processing
  elements and the software components, processes,
  and objects that live on them.
• Built as part of architectural specification
• Purpose
• Specify the distribution of components
• Identify performance bottlenecks
• Developed by architects, networking engineers,
  and system engineers
• Example A browser-based three-tier account
  management system

109
sales
node
pos.exe
contacts.exe
ltlt10-T Ethernetgtgt
ltltRS-232gtgt
110
Deployment Diagram
node
component
dependency
111
Deployment Diagram
112
Representing System Architecture
Logical View
Implementation View
Programmers Software management
Use Case View
Process View
Deployment View
System engineering
System topology Delivery, installation Communicat
ion
Conceptual
Physical
113
Generic Approach to OO Development
Requirements
Analysis
Design
Implementation and Testing
Business Process Reengineering or Context Diagram
Deployment Diagram
State Diagrams
Screen or Web Pages
Activity Diagram
Component Diagram
Use Case Diagram with Descriptions
Sequence Diagram
Scenarios
Package Diagram
RDB or OODB
Ideal Object Model (MVC Model)
Class Diagram (Architectural Patterns)
Updated Sequence Diagram
Object Diagram
CRC Cards
(Design Patterns)
Collaboration Diagram
Java Bytecode
Elaborated Class Diagram
Basic process
Legend
Optional
Additional process, if any