The document discusses state diagrams, which depict the life of an object in terms of events that trigger state changes. A state diagram identifies external and internal events that alter an object's state. Sequence diagrams show single scenarios while state diagrams show object behavior across use cases. The document provides an example state diagram and discusses when to use state diagrams. It also discusses package diagrams, which group classes into subsystems, and component diagrams, which model software implementation and relationships.

1. 4/11/2011
State Diagram
Statechart Diagram
 The Statechart describes the life of an object in terms of
the events that trigger changes in the object’s state.
 It identifies both the external events and internal events
that can change the object’s state.
 Next, contrast the scope of the Statechart with that of the
Sequence diagram. The scope of the Statechart is the
entire life of an object. The scope of the Sequence
diagram is a single scenario. Consequently, it is possible
to derive a Statechart from the set of Sequence
diagrams that use the object.
1

2. 4/11/2011
State Diagrams
 Depicts object behavior across use cases
 State: collection of values of attributes
 State-behavior relationship
 state is updated by some behavior carried out
 Notation
 States: rounded rectangles
 Arrows: state transitions
 Labels on Arrows: event/action/use case
Example 1:
Book in a Library System
start
Reserved
release
New reserve
borrow Borrowed
activate return
Available
2

3. 4/11/2011
Defining Internal Events and Activities
When to Draw State Diagrams
 State diagrams are good at describing the
behavior of an object across several use
cases
 Use state diagrams only for those classes
that exhibit interesting behavior, often the
main classes of the system
3

4. 4/11/2011
State Diagrams Help Complete
System Design
 State diagrams often reveal use cases
overlooked in earlier analyses of the system
 State diagrams provide hints on which
attributes are necessary for a given class
Package Diagrams
 Systems are often large
 Can be divided into subsystems
 In object-oriented contexts, subsystems are
packages; packages are groups of classes
 Package diagrams depict
 grouping
 dependencies between packages
4

5. 4/11/2011
Package Diagram Notation
 Folder: Package
 Dotted arrow between folders: dependency
link
 Two variations
 Abbreviated: name in folder
 Detailed: name on folder tab, rectangles
representing classes in folder area
Every subsystem package must have at least one
public interface (that is, at least one class with a public interface).
5

6. 4/11/2011
Package dependency
The dependency relationship means that at least one class in a package has
to communicate with at least one class in the other package.
6

7. 4/11/2011
The Component Diagram
 The Component diagram models the physical
implementation of the software.(Deployment diagram
models the physical architecture of the hardware)
 The purpose of the Component diagram is to define
software modules and their relationships to one another
 Each component is a chunk of code that resides in
memory on a piece of hardware.
 Each component must define an interface, which allows
other components to communicate with that component.
 The interface and the internal implementation of the
component are encapsulated in the classes that make
up the component.
Defining the Notation for Components
and Component Dependencies
7

8. 4/11/2011
Component stereotypes
 <<executable>>: A component that runs on a processor
 <<library>>: A set of resources referenced by an executable
during runtime
 <<table>>: A database component accessed by an executable
 <<file>>: Typically represents data or source code
 <<document>>: A document such as a page inserted into a
Web page
Component interfaces
8