1. ISM 6124 – Advanced Information Systems Analysis and Design
Abstracted From: Object Modeling with
OMG UML Tutorial Series
Introduction to UML
ISM 6124 – Advanced Information Systems Analysis and Design
Fall Semester 2001
© OMG and Contributors: Crossmeta, EDS, IBM, Enea Data, Hewlett-Packard, InLine Software, IntelliCorp, Kabira Technologies, Klasse Objecten, ObjectTime Ltd., Rational Software, Unisys

2. Tutorial Goals What you will learn: What you will not learn:
what the UML is and what is it not
UML’s basic constructs, rules and diagram techniques
how the UML can model large, complex systems
how the UML can specify systems in an implementation-independent manner
What you will not learn:
Object Modeling 101
object methods or processes
Metamodeling 101

3. Why do we model? Provide structure for problem solving
Experiment to explore multiple solutions
Furnish abstractions to manage complexity
Reduce time-to-market for business problem solutions
Decrease development costs
Manage the risk of mistakes

4. Quick Tour The UML is a graphical language for
specifying
visualizing
constructing
documenting
the artifacts of software systems
Added to the list of OMG adopted technologies in November 1997 as UML 1.1
Most recent minor revision is UML 1.3, adopted in November 1999

5. UML Goals
Define an easy-to-learn but semantically rich visual modeling language
Unify the Booch, OMT, and Objectory modeling languages
Include ideas from other modeling languages
Incorporate industry best practices
Address contemporary software development issues
scale, distribution, concurrency, executability, etc.
Provide flexibility for applying different processes
Enable model interchange and define repository interfaces

6. OMG UML Evolution

7. OMG UML Contributors Aonix Colorado State University
Computer Associates
Concept Five
Data Access
EDS
Enea Data
Hewlett-Packard
IBM
I-Logix InLine Software
Intellicorp
Kabira Technologies Klasse Objecten
Lockheed Martin
Microsoft
ObjecTime Oracle Ptech
OAO Technology Solutions Rational Software Reich
SAP
Softeam
Sterling Software
Sun
Taskon
Telelogic Unisys …

8. OMG UML 1.3 Specification UML Summary UML Semantics UML Notation Guide
UML Standard Profiles
Software Development Processes
Business Modeling
UML CORBAfacility Interface Definition
UML XML Metadata Interchange DTD
Object Constraint Language

9. Tutorial Focus: the Language
language = syntax + semantics
syntax = rules by which language elements (e.g., words) are assembled into expressions (e.g., phrases, clauses)
semantics = rules by which syntactic expressions are assigned meanings
UML Notation Guide – defines UML’s graphic syntax
UML Semantics – defines UML’s semantics

10. Building Blocks The basic building blocks of UML are:
model elements (classes, interfaces, components, use cases, etc.)
relationships (associations, generalization, dependencies, etc.)
diagrams (class diagrams, use case diagrams, interaction diagrams, etc.)
Simple building blocks are used to create large, complex structures
cf. elements, bonds and molecules in chemistry
cf. components, connectors and circuit boards in hardware

11. Well-Formedness Rules
Well-formed: indicates that a model or model fragment adheres to all semantic and syntactic rules that apply to it.
UML specifies rules for:
naming
scoping
visibility
integrity
execution (limited)
However, during iterative, incremental development it is expected that models will be incomplete and inconsistent.

12. What is structural modeling?
Structural model: a view of an system that emphasizes the structure of the objects, including their classifiers, relationships, attributes and operations.

13. Structural Modeling: Core Elements

14. Structural Modeling: Core Elements (cont’d)
¹ An extension mechanism useful for specifying structural elements.

15. Structural Modeling: Core Relationships

16. Structural Modeling: Core Relationships (cont’d)

17. Structural Diagram Tour
Show the static structure of the model
the entities that exist (e.g., classes, interfaces, components, nodes)
internal structure
relationship to other entities
Do not show
temporal information
Kinds
static structural diagrams
class diagram
object diagram
implementation diagrams
component diagram
deployment diagram

18. Static Structural Diagrams
Shows a graph of classifier elements connected by static relationships.
kinds
class diagram: classifier view
object diagram: instance view

19. Classes
Fig. 3-17, UML Notation Guide

20. Classes: method body
Fig. 3-21, UML Notation Guide

21. Associations
Fig. 3-31, UML Notation Guide

22. Composition
Fig. 3-36, UML Notation Guide

23. Generalization
Fig. 3-39, UML Notation Guide

24. Constraints and Comments
Fig. 3-15, UML Notation Guide

25. Implementation Diagrams
Show aspects of model implementation, including source code structure and run-time implementation structure
Kinds
component diagram
deployment diagram

26. Component Diagram
Shows the organizations and dependencies among software components
Components include
source code components
binary code components
executable components

27. Components
Fig. 3-84, UML Notation Guide

28. Component Diagram
Fig. 3-81, UML Notation Guide

29. Deployment Diagram
Shows the configuration of run-time processing elements and the software components, processes and objects that live on them
Deployment diagrams may be used to show which components may run on which nodes

30. Deployment Diagram
Fig. 3-82, UML Notation Guide

31. When to model structure
Adopt an opportunistic top-down+bottom-up approach to modeling structure
Specify the top-level structure using “architecturally significant” classifiers and model management constructs (packages, models, subsystems; see Tutorial 3)
Specify lower-level structure as you discover detail re classifiers and relationships
If you understand your domain well you can frequently start with structural modeling; otherwise
If you start with use case modeling (as with a use-case driven method) make sure that your structural model is consistent with your use cases
If you start with role modeling (as with a collaboration-driven method) make sure that your structural model is consistent with your collaborations

32. Structural Modeling Tips
Define a “skeleton” (or “backbone”) that can be extended and refined as you learn more about your domain.
Focus on using basic constructs well; add advanced constructs and/or notation only as required.
Defer implementation concerns until late in the modeling process.
Structural diagrams should
emphasize a particular aspect of the structural model
contain classifiers at the same level of abstraction
Large numbers of classifiers should be organized into packages

33. What is use case modeling?
Use case model: a view of a system that emphasizes the behavior as it appears to outside users. A use case model partitions system functionality into transactions (‘use cases’) that are meaningful to users (‘actors’).

34. Use Case Modeling: Core Elements

35. Use Case Modeling: Core Relationships
<<extend>>

36. Use Case Modeling: Core Relationships (cont’d)
<<include>>

37. Use Case Diagram
Fig. 3-44, UML Notation Guide

38. Use Case Relationships
Fig. 3-45, UML Notation Guide

39. Use Case Description: Change Flight
Actors: traveler, client account db, airline reservation system
Preconditions:
Traveler has logged on to the system and selected ‘change flight itinerary’ option
Basic course
System retrieves traveler’s account and flight itinerary from client account database
System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment.
System asks traveler for new departure and destination information; traveler provides information.
If flights are available then …
System displays transaction summary.
Alternative courses
If no flights are available then …

40. When to model use cases Model user requirements with use cases.
Model test scenarios with use cases.
If you are using a use-case driven method
start with use cases and derive your structural and behavioral models from it.
If you are not using a use-case driven method
make sure that your use cases are consistent with your structural and behavioral models.

41. Use Case Modeling Tips
Make sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and programmers
When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams (see Lecture 2)
Factor out common usages that are required by multiple use cases
If the usage is required use <<include>>
If the base use case is complete and the usage may be optional, consider use <<extend>>
A use case diagram should
contain only use cases at the same level of abstraction
include only actors who are required
Large numbers of use cases should be organized into packages (see Lecture 3)

42. Ideas to Take Away
UML is effective for modeling large, complex software systems
It is simple to learn for most developers, but provides advanced features for expert analysts, designers and architects
It can specify systems in an implementation-independent manner
10-20% of the constructs are used 80-90% of the time
Structural modeling specifies a skeleton that can be refined and extended with additional structure and behavior
Use case modeling specifies the functional requirements of system in an object-oriented manner

43. Behavioral Modeling Part 1: Interactions and Collaborations
Part 2: Statecharts
Part 3: Activity Diagrams

44. What are interactions?
Interaction: a collection of communications between instances, including all ways to affect instances, like operation invocation, as well as creation and destruction of instances
The communications are partially ordered (in time)

45. Interactions: Core Elements
Construct
Description
Syntax
Instance (object, data value, component instance etc.)
An entity with a unique identity and to which a set of operations can be applied (signals be sent) and which has a state that stores the effects of the operations (the signals).
name
attr values
Action
A specification of an executable statement.
A few different kinds of actions are predefined, e.g. CreateAction, CallAction, DestroyAction, and UninterpretedAction.
textual

46. Interaction: Core Elements (cont’d)
Construct
Description
Syntax
Stimulus
A communication between two instances.
Operation
A declaration of a service that can be requested from an instance to effect behavior.
textual
Signal
A specification of an asynchronous stimulus communicated between instances.
«Signal» Name
parameters

47. Interaction: Core Relationships
Construct
Description
Syntax
Link
A connection between instances.
Attribute Link
A named slot in an instance, which holds the value of an attribute.
textual

48. Example: Instance triangle : Polygon triangle : Polygon triangle
underlined name
triangle : Polygon
triangle
center : Point = (2,2) vertices : Point* = ((0,0), (4, 0), (2,4))
borderColor : Color = black
fillColor : Color = white
attribute links
: Polygon

49. Example: Instances and Links
: Family
husband
wife
Joe : Person
Jill : Person

50. Operation and Method Triangle foreach v in vertices do
v.x := v.x + dist.x;
v.y := v.y + dist.y
+ move (in dist : Point)
+ scale (in factor : Real)
foreach v in vertices do
v.x := factor * v.x;
v.y := factor * v.y

51. Interaction Diagram Tour
Show interactions between instances in the model
graph of instances (possibly including links) and stimuli
existing instances
creation and deletion of instances
Kinds
sequence diagram (temporal focus)
collaboration diagram (structural focus)

52. Sequence Diagram object symbol lifeline stimulus activation delete
name : Class
other
object symbol
lifeline
stimulus
name (…)
activation
: Class
create
new (…)
delete
return

53. Different Kinds of Arrows
Procedure call or other kind of nested flow of control
Flat flow of control
Explicit asynchronous flow of control
Return

54. Example: Different Arrows
teller
: Order
: Article
Nested Flow
getValue
price
getName
caller
exchange
callee
Flat Flow
lift receiver
dial tone
dial digit
ringing tone
ringing signal
appl
err handl
alarm
Asynchronous Flow
unknown

55. Collaboration Diagram
object symbol
link symbol
standard stereotype
: Controller
: Window
wire :Wire
{new} : Line
left : Bead
right : Bead
redisplay ()
stimulus
1: displayPositions (window)
wire
«local» line
contents {new}
window
«self»
window «parameter»
standard constraint
add (self)
1.1 *[i := 1..n]: drawSegment (i)
1.1.2: create (r0, r1) 1.1.3: display (window)
1.1.1a: r0 := position ()
1.1.1b: r1 := position ()

56. When to Model Interactions
To specify how the instances are to interact with each other.
To identify the interfaces of the classifiers.
To distribute the requirements.

57. Interaction Modeling Tips
Set the context for the interaction.
Include only those features of the instances that are relevant.
Express the flow from left to right and from top to bottom.
Put active instances to the left/top and passive ones to the right/bottom.
Use sequence diagrams
to show the explicit ordering between the stimuli
when modeling real-time
Use collaboration diagrams
when structure is important
to concentrate on the effects on the instances

58. Wrap Up: Interactions & Collaborations
Instances, Links and Stimuli are used for expressing the dynamics in a model.
Collaboration is a tool for
identification of classifiers
specification of the usage of instances
expressing a mapping between different levels of abstraction
Different kinds of diagrams focus on time or on structure

59. State Machine (Automaton) Diagram
Graphical rendering of automata behavior
Lamp On
off on
off
Lamp Off

60. Outputs and Actions
As the automaton changes state it can generate outputs: on
off
Lamp On
Lamp Off
on/print(”on”)
Mealy automaton on
off
Lamp On
print(”on”)
Lamp Off
Moore automaton

61. Extended State Machines
off on
Lamp On
Lamp Off
on/ctr := ctr + 1
Addition of variables (“extended state”)
ctr : Integer

62. A Bit of Theory An extended (Mealy) state machine is defined by:
a set of input signals (input alphabet)
a set of output signals (output alphabet)
a set of states
a set of transitions
triggering signal
action
a set of extended state variables
an initial state designation
a set of final states (if terminating automaton)

63. Basic UML Statechart Diagram
“top” state
State
Initial
pseudostate
top
Trigger
Ready
Transition
stop
/ctr := 0
Done
Final
state
Action
stop

64. What Kind of Behavior?
In general, state machines are suitable for describing event-driven, discrete behavior
inappropriate for modeling continuous behavior
time
threshold

65. Event-Driven Behavior
Event = a type of observable occurrence
interactions:
synchronous object operation invocation (call event)
asynchronous signal reception (signal event)
occurrence of time instants (time event)
interval expiry
calendar/clock time
change in value of some entity (change event)
Event Instance = an instance of an event (type)
occurs at a particular time instant and has no duration

66. Wrap Up: Statecharts
UML uses an object-oriented variant of Harel’s statecharts
adjusted to software modeling needs
Used to model event-driven (reactive) behavior
well-suited to the server model inherent in the object paradigm
Primary use for modeling the behavior of active event-driven objects
systems modeled as networks of collaborating state machines
run-to-completion paradigm significantly simplifies concurrency management

67. Wrap Up: Statecharts (cont’d)
Includes a number of sophisticated features that realize common state-machine usage patterns:
entry/exit actions
state activities
dynamic and static conditional branching
Also, provides hierarchical modeling for dealing with very complex systems
hierarchical states
hierarchical transitions
orthogonality

68. Activity Diagram Applications
Intended for applications that need control flow or object/data flow models …
... rather than event-driven models like state machines.
For example: business process modeling and workflow.
The difference in the three models is how step in a process is initiated, especially with respect to how the step gets its inputs.

69. Control Flow Each step is taken when the previous one finishes …
…regardless of whether inputs are available, accurate, or complete (“pull”).
Emphasis is on order in which steps are taken.
Weather Info
Start
Decision is taken with whatever information you have at the time. Does not wait for complete input or even any input to be provided.
Analyze Weather Info
Not UML
Notation!
Chart Course
Cancel Trip

70. Object/Data Flow
Each step is taken when all the required input objects/data are available …
… and only when all the inputs are available (“push”).
Emphasis is on objects flowing between steps.
Design Product
Acquire Capital
Procure
Materials
Build
Subassembly 1
Build
Subassembly 2
Final
Assembly
Not UML
Notation

71. Action (State)
Action
An action is used for anything that does not directly start another activity graph, like invoking an operation on an object, or running a user-specified action.
However, an action can invoke an operation that has another activity graph as a method (possible polymorphism).

72. Subactivity (State)
Subactivity
A subactivity (state) starts another activity graph without using an operation.
Used for functional decomposition, non-polymorphic applications, like many workflow systems.
The invoked activity graph can be used by many subactivity states.

73. Example POEmployee.sortMail Deliver Mail Deliver Mail POEmployee
Check Out
Truck
Put Mail
In Boxes
Deliver Mail
No standard notation yet for the name of an action, to indicate what kind of object and operation are being invoked.
No standard notation for connecting an action state to the object it invokes an operation on. Likewise for the decomposition of a subactivity state into another state machine.
The action state is polymorphic, the subactivity state is not.

74. Object Flow (State)
Class
[State]
A special sort of step (state) that represents the availability of a particular kind of object, perhaps in a particular state.
No action or subactivity is invoked and control passes immediately to the next step (state).
Places constraints on input and output parameters of steps before and after it.

75. Object Flow (State)
Order
[Taken]
Take Order
Fill Order
Take Order must have an output parameter giving an order, or one of its subtypes.
Fill Order must have an input parameter taking an order, or one of its supertypes.
Dashed lines used with object flow have the same semantics as any other state transition.
More about semantics of dashed line in pitfalls section.
A step parameter refers to the parameters of the operations invoked by action states. Take Order and Fill Order can be subactivity states, whereupon the parameters are in the first/last action state in the subactivity graph, recursively.

76. Coordinating Steps Inherited from state machines Initial state
Final state
Fork and join

77. Coordinating Steps
Decision point and merge ( ) are inherited from state machines.
For modeling conventional flow chart decisions.
Calculate
Cost
Charge
Account
Get
Authorization
[cost < $50]
[cost >= $50]
Use merge instead of dummy state before join.

78. Convenience Features Partitions are a grouping mechanism.
Swimlanes are the notation for partitions.
They do not provide domain-specific semantics.
Register
Bug
Evaluate
Impact
Fix
Revise
Plan
Release
Test
[ priority = 1]
Management
Support
Engineering

79. Case Study Communications of the ACM Kobryn, “UML 2001” Adapted from
partition
Submission Team
Task Force
Revision Task Force
Issue RFP
Evaluate initial
submissions
Submit
specification
draft
Collaborate with
competitive
submitters
Develop
technology
action state
RFP
[issued]
[optional]
control flow
Finalize
Specification
[initial
proposal]
input value
Begin
object flow
initial state
join of control
conditional
fork
fork of control
[final
Case Study
Communications of the ACM
Kobryn, “UML 2001”
Adapted from
October 1999

80. Case Study Communications of the ACM Kobryn, “UML 2001” Adapted from
Evaluate initial
submissions
Evaluate final
Vote to
recommend
Enhance
specification
Implement
Revise
Finalize
Specification
[final
proposal]
[adopted]
Recommend
revision
[revised]
[NO]
[YES]
[else]
[Enhanced]
decision
final state
guard
Collaborate with
competitive
submitters
Case Study
Communications of the ACM
Kobryn, “UML 2001”
Adapted from
October 1999

81. When to Use Activity Diagrams
Use activity diagrams when the behavior you are modeling ...
does not depend much on external events.
mostly has steps that run to completion, rather than being interrupted by events.
requires object/data flow between steps.
is being constructed at a stage when you are more concerned with which activities happen, rather than which objects are responsible for them (except partitions possibly).

82. Activity Diagram Modeling Tips
Control flow and object flow are not separate. Both are modeled with state transitions.
Dashed object flow lines are also control flow.
You can mix state machine and control/object flow constructs on the same diagram (though you probably do not want to).

83. Wrap Up: Activity Diagrams
Use Activity Diagrams for applications that are primarily control and data-driven, like business modeling …
… rather than event-driven applications like embedded systems.
Activity diagrams are a kind of state machine until UML 2.0 …
… so control and object/data flow do not have separate semantics.
UML 1.3 has new features for business modeling that increase power and convenience. Check it out and give feedback!