Another Introduction to UML

1
Another Introduction to UML

• These slides describe UML 1.3. Some features
  have changed in UML 2.0. Slides derived from the
  following sources
• ISM 6124 Advanced Information Systems Analysis
  and Design
• Fall Semester 2001,
• and
• Object Modeling with OMG UML Tutorial Series

2
Goals

• What you will learn
• what the UML is and what is it not
• UMLs 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 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

8
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 UMLs graphic syntax
• UML Semantics defines UMLs semantics

9
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

10
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.

11
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.

12
Structural Modeling Core Elements
13
Structural Modeling Core Elements
¹ An extension mechanism useful for specifying
structural elements.
14
Structural Modeling Core Relationships
15
Structural Modeling Core Relationships (contd)
16
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

17
Static Structural Diagrams

• Shows a graph of classifier elements connected by
  static relationships.
• kinds
• class diagram classifier view
• object diagram instance view

18
Classes
Fig. 3-17, UML Notation Guide
19
Classes method body
Fig. 3-21, UML Notation Guide
20
Associations
Fig. 3-31, UML Notation Guide
21
Composition
Fig. 3-36, UML Notation Guide
22
Generalization
23
Constraints and Comments
Fig. 3-15, UML Notation Guide
24
Implementation Diagrams

• Show aspects of model implementation, including
  source code structure and run-time implementation
  structure
• Kinds
• component diagram
• deployment diagram

25
Component Diagram

• Shows the organizations and dependencies among
  software components
• Components include
• source code components
• binary code components
• executable components

26
Components
27
Component Diagram
Fig. 3-81, UML Notation Guide
28
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

29
Deployment Diagram
Fig. 3-82, UML Notation Guide
30
When to model structure

• Adopt an opportunistic top-downbottom-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

31
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

32
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).

33
Use Case Modeling Core Elements
34
Use Case Modeling Core Relationships
ltltextendgtgt
35
Use Case Modeling Core Relationships (contd)
ltltincludegtgt
36
Use Case Diagram
Fig. 3-44, UML Notation Guide
37
Use Case Relationships
Fig. 3-45, UML Notation Guide
38
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 travelers 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

39
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.

40
Use Case Modeling Tips

• Each use case describes a complete task 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 ltltincludegtgt
• If the base use case is complete and the usage
  may be optional, consider use ltltextendgtgt
• 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)

41
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-indepe
  ndent 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

42
Behavioral Modeling

• Part 1 Interactions and Collaborations
• Part 2 Statecharts
• Part 3 Activity Diagrams

43
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)

44
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
45
Interaction Core Elements (contd)
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
A specification of an asynchronous stimulus
communicated between instances.
Signal
SignalName
parameters
46
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
47
Example Instance
triangle Polygon
center Point (2,2)vertices Point
((0,0), (4, 0), (2,4)) borderColor Color
black fillColor Color white
48
Example Instances and Links
Family
husband
wife
Joe Person
Jill Person
49
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
50
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)

51
Sequence Diagram
52
Different Kinds of Arrows
53
Example Different Arrows
54
Collaboration Diagram
redisplay ()
55
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.

56
Interaction Modeling Tips

• Set the context for the interaction.
• Include only features of the instances that are
  relevant.
• Express the flow from left to right and 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

57
Summary 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

58
State Machine (Automaton) Diagram

• Graphical rendering of automata behavior

Lamp On
Lamp Off
59
Outputs and Actions

• As the automaton changes state it can generate
  outputs

60
Extended State Machines

• Addition of variables (extended state)

ctr Integer
61
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)

62
Basic UML Statechart Diagram
top state
State
Initial pseudostate
Trigger
Ready
Transition
/ctr 0
stop
Done
Final state
Action
63
What Kind of Behavior?

• In general, state machines are suitable for
  describing event-driven, discrete behavior
• inappropriate for modeling continuous behavior

64
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

65
Summary Statecharts

• UML uses an object-oriented variant of Harels
  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

66
Summary Statecharts (contd)

• 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

67
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.

68
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
Analyze Weather Info
Not UML Notation!
Chart Course
Cancel Trip
69
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 2
Build Subassembly 1
Final Assembly
Not UML Notation
70
Action (State)

• 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).

Action
71
Subactivity (State)

• 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.

72
Example
73
Object Flow (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.

Class State
74
Object Flow (State)

• 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.

75
Coordinating Steps

• Inherited from state machines

76
Coordinating Steps

• Decision point and merge ( ) are inherited from
  state machines.
• For modeling conventional flow chart decisions.

77
Convenience Features

• Partitions are a grouping mechanism.
• Swimlanes are the notation for partitions.
• They do not provide domain-specific semantics.

78
Case Study
Adapted from Kobryn, UML 2001 Communications of
the ACM October 1999
79
Case Study
Adapted from Kobryn, UML 2001 Communications of
the ACM October 1999
80
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).

81
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).

82
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!