Using the UML - A live example
Our example application focuses on a commodity trading environment. We assume that the application supports
trading and related activities at a single location. For purposes of analysis, we are concerned with two functions:
the act of monitoring and gathering market information, and the act of completing a commodity trade.
The main users of the systems are the traders, who perform individual trades from their desks, mostly over the
phone. Traders are supported by personal workstations, connected to larger corporate servers (or administrators in
our parlance). Traders rely on many sources of market information, some informal and some formal; the workstation
is used to convey some of this market information, which is provided by the system of interest in two forms: pricing
information and market news, from both wire services and financial information providers. Pricing information
includes current prices of specific commodities (e.g. oil) for different time periods. Market news includes press
releases, demand and supply forecasts, wire stories, etc. The system must collect, filter, and disseminate these news
to traders.
A trader executes a trade after completing a negotiation with another trader (called a counterparty in commodities
parlance). To complete the trade, a formal contract must be generated specifying the terms of the deal (e.g. volume,
price, quantity, delivery date, mode of transportation, or combination thereof). In addition, the trader's position in
the commodity being traded must be updated appropriately. The position is captured in a schedule often known in
the industry as a slate, which gives a summary of all agreed to receipts and deliveries for a given <commodity,
location, month> combination, as defined by all contracts pertaining to that combination. Receipts and deliveries of
a trade are called its legs.
Use Case Diagram:
Figure1
The use case diagram is typically of interest to users, as well as object modelers and analysts who need to perform
the application domain design. Figure 1 provides an overall picture of the usage scenarios executed by the trading
system, using the classic notation introduced by Jacobson. Individual use cases (ovals) are specified in more detail
using either text, a sequence diagram, or a collaboration diagram (see below).
The diagram captures the following:
Modeling Concept
actor
Representation
“stick man” figure
use case
oval with label
system boundary
rectangle enclosing a set of use
cases
name of stereotype enclosed by
guillemets adjacent to a model
element
solid line connecting actor and
use case
<<extends>> stereotype added to
inheritance notation (triangle on
the base use case end of a
relationship)
<<uses>> stereotype on a dashed
(dependency) arrow. Source use
case includes behavior of target
use case
stereotype
Relationship: participates
Relationship: extends
Relationship: uses
Example(s) in diagram1[1]
trader, marketDataProvider,
traderContact
generate contract, trade
commodities
large rectangle enclosing all use
cases in figure
<<extends>>
trader participates in the “trade
commodities” use case
“distribute trade news” use case
extends the “distribute news” use
case.
“trade commodities” use case
uses the “generate contract” use
case
Sequence and Collaboration Diagrams (Specifying Use Cases)
1[1] Example(s) shown in this column are not necessarily exhaustive, only representative.
Figure 2a
USE CASE: trade commodities
ACTORS:
Company trader (trader)
Counterparty trader (traderContact)
PROCESS FLOW:
When a counterparty trader wishes to trade a commodity she contacts a company trader and the request to trade the commodity is announced.
The company trader analyzes the offer to trade. For a detailed discussion of this phase see the “analyze potential trade” use case.
The terms and conditions of the deal are then discussed and negotiated with the counterparty trader. This constitutes acceptance of the trade.
Upon acceptance, a new trade is created
The details of the trade are registered with the Trade Administrator
The Trade Administrator makes a permanent, persistent record of the trade details and notifies the Position Administrator of the trade.
If the trade falls within an existing slate, that slate is simply updated with the details of the new trade.
If no previous trades for the same commodity, movement location and movement period have been made, the Position Administrator creates a
new slate.
In either case a permanent, persistent record of the slate state is made.
The Trade Administrator provides the trade information to the Market Data Service for internal news distribution
The Trade Administrator requests the Contract Administrator to produce a formal printed contract
PRECONDITIONS:
Credit agreement(s) in place between Company and Counterparty
Contract template(s) in place between the Company and Counterparty
…
POSTCONDITIONS:
A printed contract is distributed to the Counterparty
Details of the trade recorded for use by various departments (e.g., credit, scheduling)
Figure above provides a graphical description of the “trade commodities” use case supported by the trading system.
This diagram is a time ordered representation of the object interactions that occur when completing a commodity
trade. The sequence diagram is typically of interest to object modelers and analysts who need to perform the
application domain design, as well as domain users. For clarity and ease of reading, supporting text is shown next to
the sequence diagram; it provides a list of actors, a process flow, preconditions, and postconditions.
The diagram captures the following:
Modeling Concept
object
message
activation (focus of control)
time sequence of messages
Message synchronization: balking
Message synchronization:
synchronous
Message synchronization:
asynchronous
Message synchronization:
timeout
Representation
rectangle with labels of the form
(name: class) across top of
diagram, attached to a vertical
dotted line
labeled arrow between objects,
arrowhead on the target object
double vertical line on object
physical placement and
sequential numbering of
messages
message arrow returning on itself
(indicates that sender abandons
the operation if receiver is not
immediately ready)
“X” near arrowhead of message
One-sided arrowhead on message
small circle attached to message
constraint (conditional execution
of messages)
text within braces adjacent to
messages
uses relationship
labeling message with name of
use case
free form expression enclosed by
braces
rectangle with bent corner
(attached to messages or objects
with dotted lines), or free form
text in margins
timing marks
note
Example(s) in diagram
tradeAdministrator :
TradeAdministrator object
“request commodity” message
(#1)
steps 1,3,4 on object
traderContract
Message “request commodity”
(#1) occurs before “analyze
potential trade” (#2).
message #1, “request
commodity”
message #2, “analyze potential
trade”
message #6, “register (trade)”
message #8, “notifyTrade”.
(indicates that tradeAdministrator
will abandon the message (and
raise an error) if
positionAdministrator cannot
handle the message within a
specified amount of time).
messages #9-10, “update {…}” &
#11-12 “new {…}”
(indicates that an existing slate
will be updated OR a new slate
will be created and stored,
depending on whether the slate
already exists)
message #13, “distribute trade
news (Use Case)”
{8 + 9 + 10 < 1 sec.} (see lefthand margin)
Notes on event stream
implementation; states of use case
and description in left hand
margin
Figure 2b
A collaboration diagram is typically of interest to object modelers and analysts who need to perform the application
domain design. Figure 2b provides a graphical description of the “generate contract” use case supported by the
trading system. This diagram is presented to follow through with the <<uses>> relationship between the “trade
commodities” and the “generate contract” use cases. Also, it is presented to demonstrate the use of a collaboration
diagram to describe a use case.
The collaboration diagram captures the following (note that there is significant overlap with the modelling concepts
represented in the preceding sequence diagram):
Modeling Concept
object
message
time sequence of messages
multiobject
Message synchronization:
synchronous
Message synchronization:
asynchronous
data/object flows and passing of
parameters
note
Representation
rectangle with labels of the form
(name: class)
labeled arrow between objects;
arrowhead on the target object
sequential numbering of
messages
multiple offset rectangles (label
has the same form)
“X” near arrowhead of message
Example(s) in diagram
contract : Contract object
One-sided arrowhead on message
message #1, “generateContract”
arrow with circle at the tail, or
method name and parameter(s)
message #1, “generateContract”
(trade object is passed to
contractAdministrator)
Alternative would be
generateContract(Trade)).
Notes on event stream
implementation
rectangle with bent corner
(attached to messages or objects
with dotted lines), or free form
text in margins
Class Diagram (Defining Application Domain)
“generateContract” message (#1)
“generateContract” (#1) occurs
before “constructContract” (#2).
contractAdministrator:
ContractAdministrator
message #2, “constructContract”
Figure 3
A class diagram is typically of interest to the object modelers and analysts. Figure 3 shows a static view of a portion
of the domain model for the trading system. Information on slates and counterparties is omitted here for space
reasons.
This diagram captures the following:
Modeling Concept
class
Representation
box with three compartments,
Example(s) in diagram
PositionDetail
visibility of attributes and
operations
abstract class
association
separated by horizontal lines,
showing class name (in bold),
class attributes, and class
operations (last two are optional)
“-“ for private, “+” for public, “#”
for protected
<<abstract>> stereotype (using
guillemets) in the name
compartment of the class; name
of class is italicized
solid line between classes
association role
text string on the relevant end of
the line
multiplicity
numeric range(s) adjacent to the
relevant class
Relationship: aggregation
Hollow diamond on “whole”, or
aggregate, end of the association.
(Weaker association than
Composition)
Solid diamond on “whole”, or
aggregate (Stronger association
than Aggregation)
Relationship: composition
Relationship: generalization
Relationship: dependency
note
State Transition Diagram
large hollow triangle at the end of
the association attached to the
more general element
broken line associations with an
arrowhead attached to the
independent element.
rectangle with bent corner
(attached to classes with dotted
lines), or free form text in
margins
attributes and operations of
PositionDetail (protected
visibility does not apply to
PositionDetail)
Administrator
TradeLeg is associated with a
Trade (Trade has TradeLeg(s))
Receipt, Delivery roles of
Tradeleg on association between
Trade and TradeLeg
Trade may have zero or more
Receipt TradeLeg(s) and may
have zero or more Delivery
TradeLeg(s).
A TradeLeg is part of a Trade.
(Conversely a Trade has
TradeLeg(s))
Position is composed of
PositionDetail(s). (A
PositionDetail is not meaningful
or accessible outside the context
of a Position, but reverse is not
true)
A TradeAdministrator is a
subclass of Administrator
TradeLeg is dependent on Price
(for computation of its value).
Price is dependent on
MarketDataService (for
instantiation).
note attached to the Administrator
class indicating a requirement for
fault-tolerance and loadbalancing strategies
Figure 4
A state transition diagram is typically of interest to analysts and developers who need to implement the detailed
behavior of a class. Figure 4a illustrates the state transitions of the Trade class from the domain class model. Trade
state transitions are dependent upon TradeLeg state transitions (not shown).
This diagram captures the following:
Modeling Concept
state
Representation
rounded rectangle
substate
physical enclosure of states
within another state
concurrent substates
substates separated by broken
lines within the “superstate”
sequential substates
physical enclosure of substates,
positioned sequentially with
events between them
small solid filled circle
circle surrounding small solid
filled circle (“bull’s eye”)
arrow between states, with
conditions specified in text
pseudo-state (initial)
pseudo-state (final)
events (triggered by simple
conditions)
events (triggered by receipt of
messages)
event-name(parameter list)
action clauses on events
event ‘/’ action-clause
transition string
event-signature [ guardcondition ] / action-clause ^ sendclause
simple transition
event causing a transition from
one state or substate to another
Example(s) in diagram
States of Trade: Estimated,
Actualized, Canceled
Delivery Estimated/Actualized
and Receipt Estimated/Actualized
substates within Estimated state
the substates mentioned above
(both deliveries and receipts must
be actualized before entire trade
is actualized)
(N/A)
see top of diagram
see bottom of diagram
“deliveryEstimates=0”
(moving from Delivery Estimated
to Delivery Actualized because
there are no more estimated
tradelegs)
tradeLegActualized(tradeLeg)
and tradeLegEstimate(tradeLeg)
events on the Estimated state
(trade object is notified that a
specific trade leg has been
estimated or actualized; could
result in changes to substates
within Estimated state)
estimateDelivery(…),
actualizeDelivery(…),
estimateReceipt(…),
actualizeReceipt(…) events on
the Estimated state
(on these events, the action is to
increment or decrement the
number of delivery or receipt
estimates using the appropriate
private method)
cancel[All Receipts and
Deliveries are estimates]
^tradeLeg.cancel
(indicates that trade canot be
cancelled unless all receipts and
deliveries are estimates; when
this holds, the action is to cancel
the individual trade legs as well)
transition between the
DeliveryActualized and
DeliveryEstimated states labeled
with the transition string
“estimateDelivery(tradeLeg)
internal transition
Event not causing a transition
from one state or substate to
another (event arrow
[ isDeliveryLeg(tradeLeg) ] /
deliveryEstimates + 1”
tradeLegEstimate(tradeLeg)…
(attached to a single state of
Estimated)
Collaboration Diagram (Defining Application Services)
Figure 5 above presents a collaboration diagram with a set of top-level “administrator” objects, whose classes can
be traced back to a domain class diagram (e.g. MarketDataService). In this particular diagram, each connection
between objects represents an “application service” to be provided. A collaboration diagram such as this is typically
of interest to the both the application designers and software architects, to the extent that it describes activities at the
boundary of application domain design and system architecture. Events are not numbered in the diagram, since the
messages are generally executed independently.
This diagram captures the following:
Modeling Concept
multiobject
Representation
multiple offset rectangles
link
line between objects
(specific) message
labeled arrow along links
note
rectangle with bent corner
(attached to objects or links with
dotted lines), or free form text in
margins
guillemets above text of note
note stereotype
Example(s) in diagram
aTradeAdministrator:
TradeAdministrator
linkbetween aMarketDataService
and Trader
“hearsay” and “news” messages
along association from Trader to
aMarketDataService
Notes on requirements for fault
tolerance and reliable
communication channels
<<requirement>> and
<<constraint>> stereotypes
Class diagrams (defining implementation of a service and collaborations)
Figure 6a above presents a class diagram for a portion of the implementation of the “Market Information” service,
in which the MarketDataService distributes news and price information to the employee. Notice that Employee and
MarketDataService are the same classes as in the domain model, but all others are purely architectural mechanisms
to implement the properties attached to this service in Figure 5.
This diagram captures the following (some redundant features from the previous class diagram are not shown):
Modeling Concept
type
parameterized class or template
parameter for template class
refinement
binding, bound class
implementation-specific
stereotypes
note
Representation
rectangle with type name and
<<type>> stereotype
Small dashed rectangle
representing parameters
superimposed on upper righthand corner of the class rectangle
text in small dashed rectangle, of
form “name: type” Type is
optional
<<refines>> stereotype on
dependency arrow
<<bind>> stereotype on
dependency arrow and/or
duplicated class name with
parameter
user-defined extensions to UML
rectangle with bent corner
(attached to classes with dotted
lines), or free form text in
margins
Example(s) in diagram
Employee, MarketDataService
(variants of domain classes)
GTIE_Employee (implem)
“implem” parameter (omits type)
“represents” dependency from
GTIE_Employee<Employee_i+ >
to Employee
(the first is a refinement of the
second for implementation
purposes. “-i" is a CORBA
naming convention)
dependency from
GTIE_Employee<Employee_i+>
to GTIE_Employee; the first class
is bound to the second.
<<IDL-generated>> and
<<delegate>> stereotypes
Notes on requirements attached to
Employee and
MarketDataService
Figure 6b
Class diagrams can also be used to capture the notion of a collaboration (Figure 6b above). A collaboration
specifies a set of objects collaborating to achieve a common goal. It can show both structural and behavioral
elements; this particular diagram focuses on the structural elements in a CORBA implementation of a collaboration
needed to implement the Market Information Service.
This diagram captures the following (some redundant features from the previous class diagrams are not shown):
Modeling Concept
collaboration
context
enumeration
parameterized or template
(collaboration)
Component Diagrams
Representation
class with <<collaboration>>
stereotype (user-defined)
nesting of entities within
dominant class
<<enumeration>> stereotype on
class
Small dashed rectangle
representing parameters
superimposed on upper righthand corner of the class rectangle
Example(s) in diagram
EventStream (large rectangle)
All other classes, etc. lying within
EventStream
Events class
EventStream class (parameters
Sender, Receiver, Events)
Figure 7a
Component diagrams are typically used primarily by software developers and system administrators who are
interested in how the source and executable files of the application are structured. This is useful both during
development and during deployment. Figure 7a shows the top-level physical packaging of the commodity trading
application into packages and active objects. In a complete application, all software artifacts needed to implement
the system design reside within one of the packages in the diagram2[1].
This diagram captures the following:
Modeling Concept
package
active object
physical composition/ nesting of
packages and modules
dependency
layers (of software)
note
Representation
File folder
rectangle with darkened border
with name of object underlined
Graphical enclosure
dashed arrow from “client” to
“supplier” package or module
Dependencies coupled with
physical placement of packages
(higher packages at higher up on
drawing are at a higher level of
abstraction than lower packages)
rectangle with bent corner
(attached to packages or modules
with dotted lines), or free form
text in margins
Example(s) in diagram
Desktop Tier package
OrbixD
The TraderUI and
CorporateServer packages nested
within the Desktop Tier package;
The OrbixD active object nested
within the Orbix + ISIS Support
package, which in turn is nested
within the Utitlities and External
Interfaces package.
Desktop Tier depends on
Application Tier
Desktop Tier is at higher level of
abstraction than Application Tier
Notes on contents of Application
Tier
2[1] Note that the TraderUI, Database Interface, and NewsFeed Interface packages are included in the component
diagram for completeness only, and in these cases, specific classes that would reside in these packages were not
presented in the class diagrams above due to space limitations.
Where more detail within a package or between packages enclosed within different package boundaries needs to be
specified, a lower-level diagram can be constructed, as in Figure 7b above . In Figure 7a, the Application Tier was
introduced, but its components were not shown. In Figure 7b, the specific packages within the Application Tier
package (TradeAdmininstrator-, MarketData-, Position-, and Contract- Server packages), are provided, and
dependencies (both internal and external to the Application Tier) are displayed.
Deployment Diagrams
Deployment diagrams are typically used by software architects to indicate deployment strategies and primary
communication paths in the system, and by network architects as an input to network design and architecture.
Figure 8a above shows the node classes, distribution units, and connections required to deploy and run the trading
system. Notice that the structure of the nodes and connections resembles that of the objects and message paths on
the collaboration diagram in Figure 5. In addition, another node (PersistenceServerNode) and many of the
distribution units found in the component diagram are included.
This diagram captures the following:
Modeling Concept
node
connection (aka communication
association)
process (aka distribution unit)
running on a node
node stereotype
connection stereotype
note
Representation
3-dimensional cube
line between nodes
Graphical enclosure of process
(shown here as text representing a
package or active object;
alternative is enclose the package
or active object itself)
guillemets enclosed within node
cube
guillemets adjacent to connection
rectangle with bent corner
(optionally attached to nodes with
dotted lines), or free form text in
margins
Example(s) in diagram
UserNode
connection between UserNode
and TradeAdministrator node
MarketDataServerNode runs the
MarketDataServer and OrbixD
distribution units (package and
module, respectively)
<<client>>and <<server>>
stereotypes
<<Broadcast>> connection
between UserNode and
MarketDataServerNode
(indicates that a single
MarketData Server node can
broadcast the same news and
prices to many UserNodes at the
same time);
<<Point-to-Point> connection
between UserNode and
PersistenceServer (e.g. a
UserNode sends messages
directly to a Persistence Server
node).
Notes on server replication
Figure 8a above indicates that there are user nodes (e.g. workstations) and that all server nodes are replicated, but
does not specify exactly how many of each are used at any given time. To convey this information, it is useful to
create a diagram with groups of node instances rather than node classes (Figure 8b below).
Figure 8b above captures the following additional information:
Modeling Concept
multiplicity of nodes
Representation
number within 3-dimensional
cube
Example(s) in diagram
6 UserNodes, 3 MarketData and
TradeAdministrator Server nodes,
2 Contract and Position Server
nodes
multiobject nodes
multiobject stereotype
See TradeAdministrator node
For further elaboration of characteristics of and connections between specific node instances (e.g. primary vs.
backup servers), another level of detail could be shown in a separate diagram.