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 use case system boundary stereotype
Relationship: participates
Relationship: extends
Relationship: uses
Representation
“stick man” figure oval with label 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
Example(s) in diagram 1 [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
Representation rectangle with labels of the form
(name: class) across top of diagram, attached to a vertical dotted line
Example(s) in diagram tradeAdministrator :
TradeAdministrator object message activation (focus of control) time sequence of messages labeled arrow between objects, arrowhead on the target object double vertical line on object physical placement and sequential numbering of messages
“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 synchronization: balking message arrow returning on itself
(indicates that sender abandons the operation if receiver is not
Message synchronization: synchronous
Message synchronization: asynchronous immediately ready)
“X” near arrowhead of message message #2, “analyze potential trade”
One-sided arrowhead on message message #6, “register (trade)”
Message synchronization: timeout small circle attached to message message #8, “notifyTrade”.
(indicates that tradeAdministrator will abandon the message (and raise an error) if positionAdministrator cannot constraint (conditional execution of messages) text within braces adjacent to messages 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 uses relationship timing marks note 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 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
“generateContract” message (#1)
“generateContract” (#1) occurs before “constructContract” (#2). contractAdministrator:
ContractAdministrator message #2, “constructContract”
One-sided arrowhead on message message #1, “generateContract” arrow with circle at the tail, or method name and parameter(s) rectangle with bent corner
(attached to messages or objects with dotted lines), or free form text in margins message #1, “generateContract”
(trade object is passed to contractAdministrator)
Alternative would be generateContract(Trade)).
Notes on event stream implementation
Class Diagram (Defining Application Domain)

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 association role multiplicity
Relationship: aggregation
Relationship: composition
Relationship: generalization
Relationship: dependency note separated by horizontal lines, showing class name (in bold), class attributes, and class operations (last two are optional)
“-“ for private, “+” for public, “#” for protected attributes and operations of
PositionDetail (protected visibility does not apply to
PositionDetail)
Administrator <<abstract>> stereotype (using guillemets) in the name compartment of the class; name of class is italicized solid line between classes text string on the relevant end of the line numeric range(s) adjacent to the relevant class
Hollow diamond on “whole”, or aggregate, end of the association.
(Weaker association than
Composition)
Solid diamond on “whole”, or aggregate (Stronger association than Aggregation)
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 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
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
State Transition Diagram

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 substate concurrent substates sequential substates pseudo-state (initial) pseudo-state (final) events (triggered by simple conditions) events (triggered by receipt of messages) action clauses on events transition string simple transition
Representation rounded rectangle physical enclosure of states within another state substates separated by broken lines within the “superstate”
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) 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 see top of diagram see bottom of diagram event-name(parameter list) event ‘/’ action-clause event-signature [ guardcondition ] / action-clause ^ sendclause event causing a transition from one state or substate to another
“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
Collaboration Diagram (Defining Application Services)
[ isDeliveryLeg(tradeLeg) ] / deliveryEstimates + 1” tradeLegEstimate(tradeLeg)…
(attached to a single state of
Estimated)
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 link
(specific) message note note stereotype
Representation multiple offset rectangles line between objects labeled arrow along links rectangle with bent corner
(attached to objects or links with dotted lines), or free form text in margins guillemets above text of note
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
Example(s) in diagram
Employee, MarketDataService
(variants of domain classes)
GTIE_Employee (implem)
“implem” parameter (omits type)
<<bind>> stereotype on dependency arrow and/or duplicated class name with parameter
“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. user-defined extensions to UML <<IDL-generated>> and
<<delegate>> stereotypes rectangle with bent corner Notes on requirements attached to
(attached to classes with dotted lines), or free form text in margins
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)
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)
Component Diagrams

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 diagram 2 [1] .
This diagram captures the following:
Modeling Concept package active object physical composition/ nesting of packages and modules
Representation
File folder rectangle with darkened border with name of object underlined
Graphical enclosure
Example(s) in diagram
Desktop Tier package
OrbixD dependency layers (of software) note 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
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
Example(s) in diagram
UserNode connection between UserNode and TradeAdministrator node
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
MarketDataServerNode runs the
MarketDataServer and OrbixD distribution units (package and module, respectively)
<<client>>and <<server>> stereotypes guillemets adjacent to connection <<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). rectangle with bent corner
(optionally attached to nodes with dotted lines), or free form text in margins
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.