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 | Representation | |
actor | “stick man” figure | trader, marketDataProvider, traderContact |
use case | oval with label | generate contract, trade commodities |
system boundary | rectangle enclosing a set of use cases | large rectangle enclosing all use cases in figure |
stereotype | name of stereotype enclosed by guillemets adjacent to a model element | <<extends>> |
Relationship: participates | solid line connecting actor and use case | trader participates in the “trade commodities” use case |
Relationship: extends | <<extends>> stereotype added to inheritance notation (triangle on the base use case end of a relationship) | “distribute trade news” use case extends the “distribute news” use case. |
Relationship: uses | <<uses>> stereotype on a dashed (dependency) arrow. Source use case includes behavior of target use case | “trade commodities” use case uses the “generate contract” use case |
Sequence and Collaboration Diagrams (Specifying Use Cases)
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 | Representation | Example(s) in diagram |
object | rectangle with labels of the form (name: class) across top of diagram, attached to a vertical dotted line | tradeAdministrator : TradeAdministrator object |
message | labeled arrow between objects, arrowhead on the target object | “request commodity” message (#1) |
activation (focus of control) | double vertical line on object | steps 1,3,4 on object traderContract |
time sequence of messages | physical placement and sequential numbering of messages | Message “request commodity” (#1) occurs before “analyze potential trade” (#2). |
Message synchronization: balking | message arrow returning on itself (indicates that sender abandons the operation if receiver is not immediately ready) | message #1, “request commodity” |
Message synchronization: synchronous | “X” near arrowhead of message | message #2, “analyze potential trade” |
Message synchronization: asynchronous | 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 handle the message within a specified amount of time). |
constraint (conditional execution of messages) | text within braces adjacent to messages | messages #9-10, “update {…}” & #11-12 “new {…}” |
uses relationship | labeling message with name of use case | message #13, “distribute trade news (Use Case)” |
timing marks | free form expression enclosed by braces | {8 + 9 + 10 < 1 sec.} (see left-hand margin) |
note | rectangle with bent corner (attached to messages or objects with dotted lines), or free form text in margins | 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 | Representation | Example(s) in diagram |
object | rectangle with labels of the form (name: class) | contract : Contract object |
message | labeled arrow between objects; arrowhead on the target object | “generateContract” message (#1) |
time sequence of messages | sequential numbering of messages | “generateContract” (#1) occurs before “constructContract” (#2). |
multiobject | multiple offset rectangles (label has the same form) | contractAdministrator: ContractAdministrator |
Message synchronization: synchronous | “X” near arrowhead of message | message #2, “constructContract” |
Message synchronization: asynchronous | One-sided arrowhead on message | message #1, “generateContract” |
data/object flows and passing of parameters | 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)). |
note | rectangle with bent corner (attached to messages or objects with dotted lines), or free form text in margins | 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 | Representation | Example(s) in diagram |
class | box with three compartments, separated by horizontal lines, showing class name (in bold), class attributes, and class operations (last two are optional) | PositionDetail |
visibility of attributes and operations | “-“ for private, “+” for public, “#” for protected | attributes and operations of PositionDetail (protected visibility does not apply to PositionDetail) |
abstract class | <<abstract>> stereotype (using guillemets) in the name compartment of the class; name of class is italicized | Administrator |
association | solid line between classes | TradeLeg is associated with a Trade (Trade has TradeLeg(s)) |
association role | text string on the relevant end of the line | Receipt, Delivery roles of Tradeleg on association between Trade and TradeLeg |
multiplicity | numeric range(s) adjacent to the relevant class | Trade may have zero or more Receipt TradeLeg(s) and may have zero or more Delivery TradeLeg(s). |
Relationship: aggregation | Hollow diamond on “whole”, or aggregate, end of the association. (Weaker association than Composition) | A TradeLeg is part of a Trade. (Conversely a Trade has TradeLeg(s)) |
Relationship: composition | Solid diamond on “whole”, or aggregate (Stronger association than Aggregation) | Position is composed of PositionDetail(s). (A PositionDetail is not meaningful or accessible outside the context of a Position, but reverse is not true) |
Relationship: generalization | large hollow triangle at the end of the association attached to the more general element | A TradeAdministrator is a subclass of Administrator |
Relationship: dependency | broken line associations with an arrowhead attached to the independent element. | TradeLeg is dependent on Price (for computation of its value). Price is dependent on MarketDataService (for instantiation). |
note | rectangle with bent corner (attached to classes with dotted lines), or free form text in margins | note attached to the Administrator class indicating a requirement for fault-tolerance and load-balancing 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 | Representation | Example(s) in diagram |
state | rounded rectangle | States of Trade: Estimated, Actualized, Canceled |
substate | physical enclosure of states within another state | Delivery Estimated/Actualized and Receipt Estimated/Actualized substates within Estimated state |
concurrent substates | substates separated by broken lines within the “superstate” | the substates mentioned above (both deliveries and receipts must be actualized before entire trade is actualized) |
sequential substates | physical enclosure of substates, positioned sequentially with events between them | (N/A) |
pseudo-state (initial) | small solid filled circle | see top of diagram |
pseudo-state (final) | circle surrounding small solid filled circle (“bull’s eye”) | see bottom of diagram |
events (triggered by simple conditions) | arrow between states, with conditions specified in text | “deliveryEstimates=0” |
events (triggered by receipt of messages) | event-name(parameter list) | 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) |
action clauses on events | event ‘/’ action-clause | estimateDelivery(…), actualizeDelivery(…), estimateReceipt(…), actualizeReceipt(…) events on the Estimated state |
transition string | event-signature [ guard-condition ] / action-clause ^ send-clause | cancel[All Receipts and Deliveries are estimates] ^tradeLeg.cancel |
simple transition | event causing a transition from one state or substate to another | transition between the DeliveryActualized and DeliveryEstimated states labeled with the transition string “estimateDelivery(tradeLeg) [ isDeliveryLeg(tradeLeg) ] / deliveryEstimates + 1” |
internal transition | Event not causing a transition from one state or substate to another (event arrow | 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 | Representation | Example(s) in diagram |
multiobject | multiple offset rectangles | aTradeAdministrator: TradeAdministrator |
link | line between objects | linkbetween aMarketDataService and Trader |
(specific) message | labeled arrow along links | “hearsay” and “news” messages along association from Trader to aMarketDataService |
note | rectangle with bent corner (attached to objects or links with dotted lines), or free form text in margins | Notes on requirements for fault tolerance and reliable communication channels |
note stereotype | guillemets above text of note | <<requirement>> and <<constraint>> stereotypes |
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 | Representation | Example(s) in diagram |
type | rectangle with type name and <<type>> stereotype | Employee, MarketDataService (variants of domain classes) |
parameterized class or template | Small dashed rectangle representing parameters superimposed on upper right-hand corner of the class rectangle | GTIE_Employee (implem) |
parameter for template class | text in small dashed rectangle, of form “name: type” Type is optional | “implem” parameter (omits type) |
refinement | <<refines>> stereotype on dependency arrow | “represents” dependency from GTIE_Employee<Employee_i+ > to Employee |
binding, bound class | <<bind>> stereotype on dependency arrow and/or duplicated class name with parameter | dependency from GTIE_Employee<Employee_i+> to GTIE_Employee; the first class is bound to the second. |
implementation-specific stereotypes | user-defined extensions to UML | <<IDL-generated>> and <<delegate>> stereotypes |
note | rectangle with bent corner (attached to classes with dotted lines), or free form text in margins | 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 | Representation | Example(s) in diagram |
collaboration | class with <<collaboration>> stereotype (user-defined) | EventStream (large rectangle) |
context | nesting of entities within dominant class | All other classes, etc. lying within EventStream |
enumeration | <<enumeration>> stereotype on class | Events class |
parameterized or template (collaboration) | Small dashed rectangle representing parameters superimposed on upper right-hand corner of the class rectangle | 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 diagram [1].
This diagram captures the following:
Modeling Concept | Representation | Example(s) in diagram |
package | File folder | Desktop Tier package |
active object | rectangle with darkened border with name of object underlined | OrbixD |
physical composition/ nesting of packages and modules | Graphical enclosure | 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. |
dependency | dashed arrow from “client” to “supplier” package or module | Desktop Tier depends on Application Tier |
layers (of software) | Dependencies coupled with physical placement of packages (higher packages at higher up on drawing are at a higher level of abstraction than lower packages) | Desktop Tier is at higher level of abstraction than Application Tier |
note | rectangle with bent corner (attached to packages or modules with dotted lines), or free form text in margins | Notes on contents of Application Tier |
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 | Representation | Example(s) in diagram |
node | 3-dimensional cube | UserNode |
connection (aka communication association) | line between nodes | connection between UserNode and TradeAdministrator node |
process (aka distribution unit) running on a node | Graphical enclosure of process (shown here as text representing a package or active object; alternative is enclose the package or active object itself) | MarketDataServerNode runs the MarketDataServer and OrbixD distribution units (package and module, respectively) |
node stereotype | guillemets enclosed within node cube | <<client>>and <<server>> stereotypes |
connection stereotype | 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); |
note | 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 | Representation | Example(s) in diagram |
multiplicity of nodes | number within 3-dimensional cube | 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.
[1] Example(s) shown in this column are not necessarily exhaustive, only representative. |
[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. |
No comments:
Post a Comment