UML Diagrams References

UML Diagrams References
Contents
Classification of UML 2.5 Diagrams ..................................................................................................................... 2 UML 2.5 Structure Diagrams ............................................................................................................................... 3 UML 2.5 Behavior Diagrams ................................................................................................................................ 4 Class Diagrams Reference .................................................................................................................. 6 Use Case Diagrams Reference .......................................................................................................... 16 Sequence Diagrams Reference ......................................................................................................... 22 Activity Diagrams Reference ............................................................................................................ 30 Communication Diagrams Reference ............................................................................................... 40
http://www.uml-diagrams.org
Copied-Pasted by Dip Thanh Nguyn, 2014
Page 1 of 41
Classification of UML 2.5 Diagrams

UML specification defines two major kinds of UML diagram: structure diagrams and behavior diagrams. Structure diagrams show the static structure of the system and its parts on different abstraction and implementation levels and how they are related to each other. The elements in a structure diagram represent the meaningful concepts of a system, and may include abstract, real world and implementation concepts. Behavior diagrams show the dynamic behavior of the objects in a system, which can be described as a series of changes to the system over time. UML 2.5 diagrams could be categorized hierarchically as shown below. Note, items shown in blue are not part of official UML 2.5 taxonomy of diagrams.
UML 2.5 Diagrams Overview. Note, items in blue are not part of official taxonomy of UML 2.5 diagrams.
Page 2 of 41
UML 2.5 Structure Diagrams

Structure diagrams show static structure of the system and its parts on different abstraction and implementation levels and how those parts are related to each other. The elements in a structure diagram represent the meaningful concepts of a system, and may include abstract, real world and implementation concepts. Structure diagrams are not utilizing time related concepts, do not show the details of dynamic behavior. However, they may show relationships to the behaviors of the classifiers exhibited in the structure diagrams.
Diagram Class diagram Purpose Shows structure of the designed system, subsystem or component as related classes and interfaces, with their features, constraints and relationships - associations, generalizations, dependencies, etc.
Instance level class diagram which shows instance specifications of classes and interfaces (objects), slots with value specifications, and links (instances of association). Object diagram was defined in now obsolete UML 1.4.2 Specification as "a graph of instances, including objects and data values. A static object diagram is an instance of a class diagram; it shows a snapshot of the detailed state of a system at a point in time." It also stated that object diagram is "a class diagram with objects and no classes." UML 2.5 specification simply provides no definition of object diagram. Shows packages and relationships between the packages.
Elements class, interface, feature,co nstraint, association,gene ralization, dependency.

instance specification,object, slot, l ink.
Object diagram
Package diagram
package, packageable element, dependency,ele ment import, package import, package merge.
Model diagram
UML auxiliary structure diagram which shows some abstraction or model, package, packagea specific view of a system, to describe architectural, logical or behavioral ble element, dependency. aspects of the system. It could show, for example, architecture of a multi-layered (aka multi-tiered) application - see multi-layered application model. Diagram could be used to show: Internal structure of a classifier A behavior of a collaboration Shows internal structure of a classifier - a decomposition of the classifier into its properties, parts and relationships.
Composite structure diagram
Internal structure diagram Collaboration use diagram Component diagram
structured class, property,part, port, connector, usage.
Shows objects in a system cooperating with each other to produce some collaboration, property,co behavior of the system. nnector, part, dependency . Shows components and dependencies between them. This type of diagrams is used forComponent-Based Development (CBD), to describe systems with Service-Oriented Architecture (SOA). component, interface,pro vided interface, required interface, class, port,conn ector, artifact,component realization,usage. manifestation, component ,artifact.
Manifestation diagram
While component diagrams show components and relationships between components and classifiers, and deployment diagrams - deployments of artifacts to deployment targets, some missing intermediate diagram is manifestation diagram to be used to showmanifestation (implementation) of components by artifacts and internal structure of artifacts. Because manifestation diagrams are not defined by UML 2.5 specification, manifestation of components by artifacts could be shown using either component diagrams or deployment diagrams. Shows architecture of the system as deployment (distribution) of software artifacts todeployment targets. Note, that components were directly deployed to nodes in UML 1.x deployment diagrams. In UML 2.x artifacts are deployed to nodes, and artifacts could manifest (implement) components. Components are deployed to nodes indirectly through artifacts.
Deployment diagram
deployment, artifact,depl oyment target, node,device, execut ion environment,communicat ion path,deployment specification,
Page 3 of 41
Specification level deployment diagram (also called type level) shows some overview of deployment of artifacts to deployment targets, without referencing specific instances of artifacts or nodes. Instance level deployment diagram shows deployment of instances of artifacts to specific instances of deployment targets. It could be used for example to show differences in deployments to development, staging or production environments with the names/ids of specific build or deployment servers or devices. Network architecture diagram Profile diagram Deployment diagrams could be used to show logical or physical network architecture of the system. This kind of deployment diagrams - not formally defined in UML 2.5 - could be called network architecture diagrams. Auxiliary UML diagram which allows to define custom stereotypes, tagged values, and constraints as a lightweight extension mechanism to the UML standard. Profiles allow to adapt the UML metamodel for different platforms (such as J2EE or .NET), or domains (such as real-time or business process modeling). Profile diagrams were first introduced in UML 2.0. node, switch, router, load balancer, firewall,commu nication path,network segment, backbone. profile, metaclass,stereoty pe, extension,reference, p rofile application.
UML 2.5 Behavior Diagrams

Behavior diagrams show the dynamic behavior of the objects in a system, which can be described as a series of changes to the system over time. Diagram Purpose Elements
Use case diagram Describes a set of actions (use cases) that some system or systems (subject) should or can perform in collaboration with one or more external users of the system (actors) to provide some observable and valuable results to the actors or other stakeholders of the system(s). Note, that UML 2.4.1 specification (see "16.4 Diagrams") stated that Use Case Diagrams are a specialization of Class Diagrams such that the classifiers shown are restricted to being either Actors or Use Cases. Class diagrams are structure diagrams. Shows exchange of information between system entities at some high levels of abstraction. Information flows may be useful to describe circulation of information through a system by representing aspects of models not yet fully specified or with less details. Shows sequence and conditions for coordinating lower-level behaviors, rather than which classifiers own those behaviors. These are commonly called control flow and object flowmodels. Used for modeling discrete behavior through finite state transitions. In addition to expressing the behavior of a part of the system, state machines can also be used to express the usage protocol of part of a system. These two kinds of state machines are referred to asbehavioral state machines and protocol state machines. Shows discrete behavior of a part of designed system through finite state transitions. Shows usage protocol or a lifecycle of some classifier, e.g. which operations of the classifier may be called in each state of the classifier, under which specific conditions, and satisfying some optional postconditions after the classifier transitions to a target state. Interaction diagrams include several different types of diagrams: sequence diagrams, communication diagrams (known as collaboration diagrams in UML 1.x), timing diagrams, interaction overview diagrams. lifeline, execution specification, message,co behavioral state, behavioral transition, pseudostate. protocol state, protocol transition, pseudostate. use case, actor, subject,extend , include, association.
Information flow diagram
information flow,information item, actor,class. activity, partition, action,o bject, control, activity edge.
Activity diagram
State machine diagram
Behavioral state machine diagram Protocol state machine diagram
Interaction diagram
Sequence diagram Most common kind of interaction diagrams which focuses on the message interchange between lifelines (objects).
Page 4 of 41
mbined fragment,interaction use, state invariant, destruction occurrence. Communication diagram (a.k.a.Colla boration diagram in UML 1.x) Timing diagram Focuses on the interaction between lifelines where the architecture of the internal structure and how this corresponds with the message passing is central. The sequencing of messages is given through a sequence numbering scheme. Shows interactions when a primary purpose of the diagram is to reason about time. Timing diagrams focus on conditions changing within and among lifelines along a linear time axis. lifeline, message.
lifeline, state or condition timeline, destruction event,duration constraint, time constraint. initial node, flow final node,activity final node, decision node, merge node, fork node,join node, interaction,interacti on use, duration constraint, time constraint.
Interaction overview diagram
Defines interactions through a variant of activity diagrams in a way that promotes overview of the control flow. Interaction overview diagrams focus on the overview of the flow of control where the nodes are interactions or interaction uses. The lifelines and the messages do not appear at this overview level.
Page 5 of 41
Class Diagrams Reference

Notation Class
A class is a classifier which describes a set of objects that share the same features constraints semantics (meaning) . A class is shown as a solid-outline rectangle containing the class name, and optionally with compartments separated by horizontal lines containing features or other members of the classifier. When class is shown with three compartments, the middle compartment holds a list of attributes and the bottom compartment holds a list of operations . Attributes and operations should be left justified in plainface, with the first letter of the names in lower case.
Description
o o o
Class Customer - details suppressed.
Class SearchService - analysis level details Middle compartment holds attributes and the bottom one holds operations.
Class SearchService - implementation level details. The createEngine is static operation. Attributes or operations may be grouped by visibility. A visibility keyword or symbol in this case can be given once for multiple features with the same visibility.
Class SearchService - attributes and operations grouped by visibility. Utility is class that has only class scoped static attributes and operations . As such, utility class usually has no instances.
Math is utility class - having static attributes and operations (underlined)
Page 6 of 41
Abstract Class
Abstract class was defined in UML 1.4.2 as class that can't be directly instantiated. No object may be a direct instance of an abstract class. UML 2.4 mentions abstract class but provides no definition. We may assume that in UML 2.x abstract class does not have complete declaration and "typically" can not be instantiated. The name of an abstract class is shown in italics.
Class SearchRequest is abstract class .
Nested Classifiers
A class or interface could be used as a namespace for various classifiers including other classes, interfaces, use cases, etc. This nesting of classifier limits the visibility of the classifier defined in the class to the scope of the namespace of the containing class or interface. In obsolete UML 1.4.2 a declaring class and a class in its namespace may be shown connected by a line, with an "anchor" icon on the end connected to a declaring class (namespace). An anchor icon is a cross inside a circle. UML 2.x specifications provide no explicit notation for the nesting by classes. Note, that UML's 1.4 "anchor" notation is still used in one example in UML 2.4.x for packages as an "alternative membership notation". Class LinkedList is nesting the Element interface. The Element is in scope of the LinkedList namespace.
Class Template
UML classes could be templated or bound. The example to the left shows bound class Customers with substitution of the unconstrained parameter class T with class Customer and boundary parameter n with the integer value 24.
Template class Array and bound class Customers. The Customers class is an Array of 24 objects of Customer class.
Interface
An interface is a classifier that declares of a set of coherent public features and obligations. An interface specifies a contract. In UML 1.4 interface was formally equivalent to an abstract class with no attributes and no methods and only abstract operations . An interface may be shown using a rectangle symbol with the keyword interface preceding the name. The obligations that may be associated with an interface are in the form of various kinds of constraints (such as pre- and postconditions) or protocol specifications, which may impose ordering restrictions on interactions through the interface.
Interface SiteSearch.
Interface Pageable Interface participating in the interface realization dependency is shown as a circle or ball, labeled with the name of the interface and attached by a solid line to the classifier that realizes this interface. Interface SiteSearch is realized (implemented) by SearchService.
Page 7 of 41
The usage dependency from a classifier to an interface is shown by representing the interface by a half-circle or socket, labeled with the name of the interface, attached by a solid line to the classifier that requires this interface. Interface SiteSearch is used (required) by SearchController.
Object
Object is an instance of a class or an interface . Object is not a UML element by itself. Objects are rendered as instance specifications, usually on object diagrams. Class instance (object) could have no name, be anonymous. Anonymous instance of the Customer class. In some cases, class of the instance is unknown or not specified. When instance name is also not provided, the notation for such an anonymous instance of an unnamed classifier is simply underlined colon - :. Instance newPatient of the unnamed or unknown class. Interface instance (object) could have both name and associated classifier.
Instance checkAcct of the Account interface. Class instance (object) could have instance name, class and namespace (package) specified.
Instance front-facing-cam of the Camera class from android.hardware package. If an instance has some value, the value specification is shown either after an equal sign ('=') following the instance name, or without the equal sign below the name.
Instance orderPaid of the Date class has value July 31, 2011 3:00 pm. Slots are shown as structural features with the feature name followed by an equal sign ('=') and a value specification. Type (classifier) of the feature could be also shown.
Instance newPatient of the Patient class has slots with values specified.
Data Type
A data type is a classifier - similar to a class - whose instances are identified only by their value. A data type is shown using rectangle symbol with keyword dataType. DateTime data type A data type may contain attributes and operations to support the modeling of structured data types.
Structured data type Address
Page 8 of 41
When data type is referenced by, e.g., as the type of a class attribute, it is shown simply as the name of the data type.
Attributes of the Patient class are of data types Name, Gender, DateTime, Address and Visit.
Primitive Type
A primitive type is a data type which represents atomic data values, i.e. values having no parts or structure. A primitive data type may have precise semantics and operations defined outside of UML, for example, mathematically. Standard UML primitive types include: Boolean, Integer, UnlimitedNatural , String. A primitive type has the keyword primitive above or before the name of the primitive type.
Primitive data type Weight.
Enumeration
An enumeration is a data type whose values are enumerated in the model as user-defined enumeration literals. An enumeration may be shown using the classifier notation (a rectangle) with the keyword enumeration. The name of the enumeration is placed in the upper compartment. A list of enumeration literals may be placed, one to a line, in the bottom compartment. The attributes and operations compartments may be suppressed, and typically are suppressed if they would be empty. Enumeration AccountType.
Feature
Feature overview diagram
Association Qualifier
A qualifier is a property which defines a partition of the set of associated instances with respect to an instance at the qualified end. Qualifiers are used to model hash maps in Java, dictionaries in C#, index tables, etc. where fast access to linked object(s) is provided using qualifier as a hash key, search argument or index. A qualifier is shown as a small rectangle attached to the end of an association between the final path segment and the symbol of the classifier that it connects to. The qualifier rectangle is part of the association , not part of the classifier. A qualifier may not be suppressed.
Given a company and a social security number (SSN) at most one employee could be found.
Page 9 of 41
In the case in which the target multiplicity is 0..1, the qualifier value is unique with respect to the qualified object, and designates at most one associated object. In the case of target multiplicity 0..*, the set of associated instances is partitioned into possibly empty subsets, each selected by a given qualifier instance. Given a library and author name none to many books could be found. UML 2.4 specification is gibberish explaining multiplicity of qualifier: The multiplicity of a qualifier is given assuming that the qualifier value is supplied. The raw multiplicity without the qualifier is assumed to be 0..*. This is not fully general but it is almost always adequate, as a situation in which the raw multiplicity is 1 would best be modeled without a qualifier.
Given chessboard and specific rank and file we'll locate exactly 1 square. UML specification provides no lucid explanation of what multiplicity 1 means for qualifier.
Operation
Operation is a behavioral feature of a classifier that specifies the name, type, parameters, and constraints for invoking an associated behavior. When operation is shown in a diagram, the text should conform to the syntax defined in UML specification. Note, that UML 2.2 to 2.4 specifications seem to have wrong nesting for operation's properties, making presence of the properties dependent on the presence of return type. The syntax provided here is non-normative and different from the one in the UML 2.4 specification: operation ::= [ visibility ] signature [ oper-properties ] Visibility of the operation is optional, and if present, it should be one of: visibility ::= '+' | '-' | '#' | '~'
Operation executeQuery is public, isPoolable - protected, getQueryTimeout - with package visibility, and clearWarnings is private.
Signature of the operation has optional parameter list and return specification. signature ::= name '(' [ parameter-list ] ')' [ ':' return-spec ] Name is the name of the operation. Parameter-list is a list of parameters of the operation in the following format: parameter-list ::= parameter [ ',' parameter ]* parameter ::= [ direction ] parm-name ':' typeexpression [ '[' multiplicity ']' ] [ '=' default ] [ parm-properties ] Parm-name is the name of the parameter. Type-expression is an File has two static operations - create and slashify. Create has two expression that specifies the type of the parameter. Multiplicity is the multiplicity of the parameter. Default is an expression that defines the parameters and returns File. Slashify is private operation. Operation listFiles returns array of files. Operations getName and value specification for the default value of the parameter. Parameter list listFiles either have no parameters or parameters were suppressed. can be suppressed. Direction of parameter is described as one of: direction ::= 'in' | 'out' | 'inout' | 'return' and defaults to 'in' if omitted. Optional parm-properties describe additional property values that apply to the parameter. parm-properties ::= '{' parm-property [ ',' parm-property ]* '}' Optional return specification is defined as: return-spec ::= [ return-type ] [ '[' multiplicity ']' ] Return type is the type of the result, if it was defined for the operation. Return specification also has optional multiplicity of the return type.
Operation setDaemon has one input parameter, while single parameter of changeName is both input and output parameter. Static enumerate returns integer result while also having output parameter - array of threads. Operation isDaemon is shown with return type parameter. It is presentation option equivalent to returning operation result as: +isDaemon(): Boolean.
Properties of the operation are optional, and if present should follow the rule: oper-properties ::= '{' oper-property [ ',' oper-property ]* '}' oper-property ::= 'redefines' opername | 'query' | 'ordered' | 'unique' | oper-constraint Properties of operation describe operation in general or return parameter, and are defined as: redefines oper-name - operation redefines an inherited operation identified by oper-name; Operation check redefines inherited operation status from the query - operation does not change the state of the system; superclass. Operation getPublicKey does not change the state of the system. Operation getCerts returns ordered array of Certificates ordered - the values of the return parameter are ordered; without duplicates. unique - the values returned by the parameter have no duplicates;
Page 10 of 41

Abstract Operation
oper-constraint - is a constraint that applies to the operation.
Abstract operation in UML 1.4.2 was defined as operation without implementation - "class does not implement the operation". Implementation had to be supplied by a descendant of the class. Abstract operation in UML 1.4.2 was shown with its signature in italics or marked as {abstract} . There is neither definition nor notion for abstract operation in UML 2.4.
Constraint
Constraint could have an optional name, though usually it is anonymous. A constraint is shown as a text string in curly braces according to the syntax: constraint ::= '{' [ name ':' ] boolean-expression '}' For an element whose notation is a text string (such as a class attribute, etc.), the constraint string may follow the element text string in curly braces. Bank account attribute constraints - non empty owner and positive balance. For a Constraint that applies to two elements (such as two classes or two associations), the constraint may be shown as a dashed line between the elements labeled by the constraint string in curly braces.
Account owner is either Person or Corporation, {xor} is predefined UML constraint. The constraint string may be placed in a note symbol and attached to each of the symbols for the constrained elements by a dashed line.
Bank account constraints - non empty owner and positive balance
Multiplicity
Multiplicity is a definition of an inclusive interval of non-negative integers to specify the allowable number of instances of described element. Multiplicity could be described with the following non-normative syntax rules: multiplicity ::= multiplicity-range [ '{' multiplicityoptions '}' ] Some typical examples of multiplicity bounds:
0 1 5 * 0..1
Multiplicity of Players for Soccer Team class.
Collection must be empty Exactly one instance Exactly 5 instances Zero or more instances No instances or one instance Exactly one instance Zero or more instances At least one instance Page 11 of 41
1..1 0..* 1..*
m..n
At least m but no more than n instances
Customer has none to many purchases. Purchases are in specific order and each one is unique (by default).
Multiplicity options could also specify of whether the values in an instantiation of the element should beunique and/or ordered: multiplicity-options ::= order-designator [ ',' uniqueness-designator ] | uniqueness-designator [ ',' order-designator ] order-designator ::= 'ordered' | 'unordered' uniqueness-designator ::= 'unique' | 'nonunique' If multiplicity element is multivalued and specified as ordered, then the collection of values in an instantiation of this element is sequentially ordered. By default, collections are not ordered. If multiplicity element is multivalued and specified as unique, then each value in the collection of values in an instantiation of this element must be unique. By default, each value in collection is unique.
Data Source could have a Logger and has ordered pool of min to max Connections. Each Connection is unique (by default).
Visibility
Visibility allows to constrain the usage of a named element , either in namespaces or in access to the element. It is used with classes, packages , generalizations , element import, package import . UML has the following types of visibility: public (+) package (~) protected (#) private (-) If a named element is not owned by any namespace , then it does not have a visibility.
Operation executeQuery is public, isPoolable - protected, getQueryTimeout - with package visibility, and clearWarnings is private.
Association
Association is a relationship between classifiers which is used to show that instances of classifiers could be either linked to each other or combined logically or physically into some aggregation. It is normally drawn as a solid line connecting associated classifiers. Binary association relates two typed instances. It is normally rendered as a solid line connecting two classifiers, or a solid line connecting a single classifier to itself (the two ends are distinct). The line may consist of one or more connected segments. Job is associated with Year . A small solid triangle could be placed next to or in place of the name of binary association (drawn as a solid line) to show the order of the ends of the association. The arrow points along the line in the direction of the last end in the order of the association ends. This notation also indicates that the association is to be read from the first end to the last end. Any association may be drawn as a diamond (larger than a terminator on a line) with a solid line for each association end connecting the diamond to the classifier that is the ends type. N-ary association with more than two ends can only be drawn this way.
Order of the ends and reading: Car - was designed in - Year
Ternary association Design relating three classifiers.
Aggregation
Aggregation (aka shared aggregation) is shown as binary association decorated with a hollow diamond as a terminal adornment at the aggregate end of the association line. Search Service has a Query Builder using sharedaggregation
Page 12 of 41
Composite Aggregation (Composition)

Composite aggregation (aka composition) is a "strong" form of aggregation. Composition is depicted as binary association decorated with a filled black diamond at the aggregate (composite) end. Folder could contain many files, while each File has exactly one Folder parent. If Folder is deleted, all contained Files are deleted as well. When composition is used in domain models, both whole/part relationship as well as event of composite "deletion" should be interpreted figuratively, not necessarily as physical containment and/or termination.
Hospital has 1 or more Departments, and each Department belongs to exactly one Hospital. If Hospital is closed, so are all of its Departments.
Multiplicity of the composite (whole) could be specified as 0..1 ("at most one") which means that part is allowed to be a "stand alone", not owned by any specific composite. Each Department has some Staff, and each Staff could be a member of one Department (or none). If Department is closed, its Staff is relieved (but excluding the "stand alone" Staff).
Ownership of Association End

Ownership of association ends by an associated classifier may be indicated graphically by a small filled circle (aka dot ). The dot is drawn at the point where line meets the classifier. It could be interpreted as showing that the model includes a property of the type represented by the classifier touched by the dot. This property is owned by the classifier at the other end. Attribute notation can be used for an association end owned by a class, because an association end owned by a class is also an attribute. This notation may be used in conjunction with the line arrow notation to make it perfectly clear that the attribute is also an association end .
Association end query is owned by classifier QueryBuilderand association end qbuilder is owned by association Builds itself.
Association end qb is an attribute of SearchService class and is owned by the class.
Association Navigability
No adornment on the end of an association means unspecified navigability.
Both ends of association have unspecified navigability. Navigable end is indicated by an open arrowhead on the end of an association.
A2 has unspecified navigability while B2 is navigablefrom A2. Not navigable end is indicated with a small x on the end of an association.
A3 is not navigable from B3 while B3 has unspecified navigability.
A4 is not navigable from B4 while B4 is navigable from A4.
A5 is navigable from B5 and B5 is navigable from A5.
Page 13 of 41
A6 is not navigable from B6 and B6 is not navigable from A6.
Generalization
A Generalization is shown as a line with a hollow triangle as an arrowhead between the symbols representing the involved classifiers. The arrowhead points to the symbol representing the general classifier. This notation is referred to as the "separate target style."
Checking, Savings, and Credit Accounts are generalized by Account. Multiple Generalization relationships that reference the same general classifier can also be connected together in the "shared target style."
Checking, Savings, and Credit Accounts are generalized by Account.
Dependency
Dependency relationship is used on class diagrams to show usage dependency or abstraction . A dependency is generally shown as a dashed arrow between two model elements. The model element at the tail of the arrow (the client) depends on the model element at the arrowhead (the supplier). The arrow may be labeled with an optional stereotype and an optional name.
Data Access depends on Connection Pool
Usage
Usage is a dependency relationship in which one element (client) requires another element (or set of elements) (supplier) for its full implementation or operation. For example, it could mean that some method(s) within a ( client ) class uses objects (e.g. parameters) of the another (supplier) class. A usage dependency is shown as a dependency with a use keyword attached to it.
Search Controller uses Search Engine.
Create
Create is a usage dependency denoting that the client classifier creates instances of the supplier classifier. It is denoted with the standard stereotype create. Data Source creates Connection Create may relate an instance value to a constructor for a class, describing the single value returned by the constructor operation. The operation is the client, the created instance the supplier. The instance value may reference parameters declared by the operation. Account constructor creates new instance of Account
Required Interface
Required interface specifies services that a classifier needs in order to perform its function and fulfill its own obligations to its clients. It is specified by a usage dependency between the classifier and the correspondinginterface . The usage dependency from a classifier to an interface is shown by representing the interface by a half-circle or socket, labeled with the name of the interface, attached by a solid line to the classifier that requires this interface.
Interface SiteSearch is used (required) by SearchController.
Page 14 of 41
If interface is represented using the rectangle notation, interface usage dependency is denoted with dependency arrow. The classifier at the tail of the arrow uses (requires) the interface at the head of the arrow. Interface SiteSearch is used (required) by Search Controller.
Interface Realization
The interface realization dependency from a classifier to an interface is shown by representing the interface by a circle or ball, labeled with the name of the interface and attached by a solid line to the classifier that realizes this interface. Interface SiteSearch is realized (implemented) by SearchService. In cases where interfaces are represented using the rectangle notation, interface realization dependency is denoted with interface realization arrow. The classifier at the tail of the arrow implements the interface at the head of the arrow. Interface SiteSearch is realized (implemented) by SearchService.
Page 15 of 41
Use Case Diagrams Reference

Notation Subject
The subject (of use cases) is the system under design or consideration to which a set of use cases apply. The subject could be a physical system, software program, or smaller element that may have behavior, e.g.subsystem , component, or even class. Subject is presented by a rectangle with subject name in upper corner with applicable use cases inside the rectangle and actors - outside of the system boundaries.
Description
Books Online (subject) with applicable use cases and Web Customer actor.
Standard UML stereotypes and keywords for the subject are: subsystem process service component
Weather Service subject stereotyped as service.
Applicability of Use Cases

Use cases visually located inside the system boundaries are the use cases applicable to the subject (but not necessarily owned by the subject).
Use cases Browse Items and Buy Items are applicable to Retail Website subject.
Ownership of Use Cases

The nesting (ownership) of a use case by a classifier is represented using the standard notation for nested classifiers.
Retail Website subject owns use cases.
Page 16 of 41
Actor
Standard UML icon for actor is "stick man" icon with the name of the actor above or below the icon. Actor names should follow the capitalization and punctuation guidelines for classes. The names of abstract actors should be shown in italics. All actors must have names.
Student actor. Custom icons that convey the kind of actor may also be used to denote an actor, such as using a separate icon(s) for non-human actors.
Custom icon for Web Client actor.
Custom icon for Bank actor . A business actor (introduced in Rational Unified Process to support Business Modeling) represents a role played by some person or system external to the modeled business . Business actor is not part of UML standard. Business actor is shown as "stick man " icon with a line crossing its head. Business actor Passenger. An actor may also be shown as a class rectangle with the keyword actor, having usual notation for class compartments, if needed.
Customer actor as Class.
Generalization between actors

Generalization between actors is rendered as a solid directed line with a large arrowhead (the same as for generalization between classes).
Web Client actor is abstract superclass for Administrator, Editor and Customer.
Page 17 of 41
Use Case
Every use case must have a name. Use case is shown as an ellipse containing the name of the use case.
User Registration Use Case. A use case could be shown as an ellipse with the name of the use case placed below the ellipse.
Transfer Funds Use Case. Business use case was introduced in Rational Unified Process to support Business Modeling - to represent business function, process, or activity performed in the modeled business. Business use case is represented in RUP with use case oval icon and a line crossing it down right. Business use case Individual Check-In. An optional stereotype keyword may be placed above the name and a list of properties - operations and attributes - included below the name in a compartment.
Use Case User Sign-In stereotyped as authentication Use case with extension points may be listed in a compartment of the use case with the heading extension points .
Registration Use Case with extension points Registration Help and User Agreement. A use case can also be shown using the standard rectangle notation for classifiers with an ellipse icon in the upper righthand corner of the rectangle and with optional separate list compartments for its features.
Registration Use Case shown using the standard rectangle notation for classifiers .
Page 18 of 41
Use case could be rendered in the frame labeled as use case or in abbreviated form as uc. The content area of the frame could contain different kinds of UML diagrams. For example, use case could be described with activity diagram or state machine.
Use case Search Items rendered as frame with associated Search Items activity diagram
Generalization between use cases

Generalization between use cases is similar to generalization between classes child use case inherits properties and behavior of the parent use case and may override the behavior of the parent. It is rendered as a solid directed line with a large arrowhead, the same as for generalization between classifiers.
Web User Authentication use case is abstract use casespecialized by Login, Remember Me and Single Sign-On use cases.
Extend
Extend is a directed relationship that specifies how and when the behavior defined in usually supplementary (optional) extending use case can be inserted into the behavior defined in the extended use case . Extended use case is meaningful on its own, it is independent of the extending use case. Extending use case typically defines optional behavior that is not necessarily meaningful by itself. Registration use case is complete and meaningful on its own. It Extend relationship between use cases is shown by a dashed arrow could be extended with optional Get Help On Registrationuse case. with an open arrowhead from the extending use case to the extended (base) use case . The arrow is labeled with the keyword extend. The condition of the extend relationship as well as the references to the extension points are optionally shown in a comment note attached to the corresponding extend relationship.
Registration use case is conditionally extended by Get Help On Registration use case in extension point Registration Help.
Page 19 of 41
Extension Point
An extension point is a feature of a use case which identifies (references) a point in the behavior of the use case where that behavior can be extended by some other (extending) use case, as specified by extendrelationship. Extension points may be shown in a compartment of the use case oval symbol under the heading extension points . Each extension point must have a name, unique within a use case. Extension points are shown as a text string according to the syntax: extension point ::= name [: explanation ] Registration Use Case with extension points Registration Help and User Agreement. Extension points may be shown in a compartment of the use case rectangle with ellipse icon under the heading extension points.
Extension points of the Registration use case shown using the rectangle notation.
Include
An include relationship is a directed relationship between two use cases when required, not optional behavior of the included use case is inserted into the behavior of the including (base) use case. The include relationship is analogous to a subroutine call or macro and could be used: when there are common parts of the behavior of two or more use cases, to simplify large use case by splitting it into several use cases. An include relationship between use cases is shown by a dashed arrow with an open arrowhead from the base use case to the included use case. The arrow is labeled with the keyword include. Large and complex use case could be simplified by splitting it into several use cases each describing some logical unit of behavior. Note, that including use case becomes incomplete by itself and requires included use cases to be complete.
Deposit Funds and Withdraw Cash use cases includeCustomer Authentication use case.
Checkout use case includes several use cases - Scan Item, Calculate Total and Tax, and Payment
Association
An association between an actor and a use case indicates that the actor and the use case communicate with each other. An actor could be associated to one or several use cases.
Actor Customer associated with two use cases.
Page 20 of 41
Use case may have one or several associated actors. It may not be obvious from use case diagram which actor initiates the use case, i.e. is "primary actor ". (In nonstandard UML, primary actors are those using system services, and supporting actors are actors providing services to the system.) Use case Manage Account associated with Customer and Bank actors. When an actor has an association to a use case with a multiplicity that is greater than one at the use caseend, it means that a given actor can be involved in multiple use cases of that type. The specific nature of this multiple involvement is not defined in the UML 2.2 . Use case multiplicity could mean that an actor initiates multiple use cases: in parallel (concurrently), or at different points in time, or mutually exclusive in time. When a use case has an association to an actor with a multiplicity that is greater than one at the actor end, it means that more than one actor instance is involved in initiating the use case. The manner in whichmultiple actors participate in the use case is not defined in the UML 2.2 . For instance, actor's multiplicity could mean that: a particular use case might require simultaneous (concurrent) action by two separate actors (e.g., in launching a nuclear missile), or it might require complementary and successive actions by the actors (e.g., one actor starting something and the other one stopping it).
Actor Bank is involved in multiple Use cases Transfer Funds.
Two or more Player Actors are required to initiate Play GameUse case.
Page 21 of 41
Sequence Diagrams Reference

Notation Lifeline
A Lifeline is shown using a symbol that consists of a rectangle forming its head followed by a vertical line (which may be dashed) that represents the lifetime of the participant.
Description
Lifeline with name "data" of class Stock. Anonymous lifeline has no name - arbitrary representative of class.
Anonymous lifeline of class User. Selector could be used to specify some lifeline from collection.
Lifeline "x" of class X is selected with selector [k].
Execution
Execution (full name - execution specification , informally called activation ) is interaction fragmentwhich represents a period in the participant's lifetime when it is executing a unit of behavior or action within the lifeline , sending a signal to another participant, waiting for a reply message from another participant. The duration of an execution is represented by two execution occurrences - the start occurrence and thefinish occurrence. Execution is represented as a thin grey or white rectangle on the lifeline.
Execution specification shown as grey rectangle on the Service lifeline. Execution can be represented by a wider labeled rectangle, where the label usually identifies the action that was executed.
Execution represented as wider rectangle labeled as action.
Page 22 of 41
Overlapping executions on the same lifeline are represented by overlapping rectangles.
Overlapping execution specifications on the same lifeline - message to self.
Overlapping execution specifications on the same lifeline - callback message.
Message
Message is a named element that defines one specific kind of communication between lifelines of an interaction. The message specifies not only the kind of communication, but also the sender and the receiver. Sender and receiver are normally two occurrence specifications (points at the ends of messages). A message is shown as a line from the sender message end to the receiver message end. The line must be such that every line fragment is either horizontal or downwards when traversed from send event to receive event. The send and receive events may both be on the same lifeline. The form of the line or arrowhead reflects properties of the message.
Messages by Action Type

Depending on the type of action that was used to generate the message, message could be one of: synchronous call asynchronous call asynchronous signal create delete reply

Synchronous Call
Synchronous call typically represents operation call - send message and suspend execution while waiting for response. Synchronous Messages are shown with filled arrow head.
Web Client searches Online Bookshop and waits for results.
Page 23 of 41
Asynchronous Call
Asynchronous call - send message and proceed immediately without waiting for return value. Asynchronous Messages have an open arrow head.
Service starts Task and proceeds in parallel without waiting.
Asynchronous Signal
Asynchronous signal message corresponds to asynchronous send signal action.
Create Message
Create message is sent to lifeline to create itself. Note, that it is weird but common practice in OOAD to send create message to a nonexisting object to create itself. In real life, create message is sent to some runtime environment. Create message is shown as a dashed line with open arrowhead (same as reply), and pointing to created lifeline's head.
Online Bookshop creates Account.
Delete Message
Delete message (called stop in previous versions of UML) is sent to terminate another lifeline . The lifeline usually ends with a cross in the form of an X at the bottom denoting destruction occurrence. UML 2.3 specification provides neither specific notation for delete message nor a stereotype. Until they provide some notation, we can use custom destroy stereotype.
Online Bookshop terminates Account.
Reply Message
Reply message to an operation call is shown as a dashed line with open arrow head.
Web Client searches Online Bookshop and waits for results to be returned.
Messages by Presence of Events

Depending on whether message send event and receive events are present, message could be one of: complete message lost message found message unknown message (default)
Page 24 of 41
Lost Message
Lost Message is a message where the sending event is known, but there is no receiving event. It is interpreted as if the message never reached its destination. Lost messages are denoted with as a small black circle at the arrow end of the message.
Web Client sent search message which was lost.
Found Message
Found Message is a message where the receiving event is known, but there is no (known) sending event. It is interpreted as if the origin of the message is outside the scope of the description. This may for example be noise or other activity that we do not want to describe in detail. Found messages are denoted with a small black circle at the starting end of the message.
Online Bookshop gets search message of unknown origin.
Destruction Occurrence
Destruction occurrence is a message occurrence which represents the destruction of the instance described by the lifeline. It may result in the subsequent destruction of other objects that this object owns bycomposition. No other occurrence may appear below the destruction on a given lifeline. Complete UML name of the occurrence is destruction occurrence specification. Until UML 2.4 it was calleddestruction event , and earlier - stop. The destruction of instance is depicted by a cross in the form of an X at the bottom of a lifeline. Account lifeline is terminated
State Invariant
A state invariant is an interaction fragment which represents a runtime constraint on the participants of the interaction. It may be used to specify different kinds of constraints, such as values of attributes or variables, internal or external states, etc. State invariant is usually shown as a constraint in curly braces on the lifeline.
Attribute t of Task should be equal to complete. It could also be shown as a state symbol representing the equivalent of a constraint that checks the state of the object represented by the lifeline. This could be either the internal state of the classifier behavior of the corresponding classifier or some external state based on a "black-box" view of the lifeline.
Task should be in Finished state.
Combined Fragment
Interaction operator could be one of: alt - alternatives opt - option
Page 25 of 41

Alternatives
loop - iteration break - break par - parallel strict - strict sequencing seq - weak sequencing critical - critical region ignore - ignore consider - consider assert - assertion neg - negative
The interaction operator alt means that the combined fragment represents a choice or alternatives of behavior. At most one of the operands will be chosen. The chosen operand must have an explicit or implicit guard expression that evaluates to true at this point in the interaction.
Call accept() if balance > 0, call reject() otherwise.
Option
The interaction operator opt means that the combined fragment represents a choice of behavior where either the (sole) operand happens or nothing happens. An option is semantically equivalent to an alternative combined fragment where there is one operand with non-empty content and the second operand is empty.
Post comments if there were no errors.
Loop
If loop has no bounds specified, it means potentially infinite loop with zero as lower bound and infinite upper bound.
Potentially infinite loop. If only min-int is specified, it means that upper bound is equal to the lower bound, and loop will be executed exactly the specified number of times.
Loop to execute exactly 10 times.
Page 26 of 41
If both bounds are specified, loop will iterate minimum the minint number of times and at most the max-intnumber of times. Besides iteration bounds loop could also have an interaction constraint - a Boolean expression in square brackets. To add to the other confusions, UML 2.3 also calls both of them guards. UML tries to shuffle the simplest form of for loop and while loop which causes weird UML 2.3 loop semantics on p.488: "after the minimum number of iterations have executed and the Boolean expression is false the loop will terminate". This is clarified - with opposite meaning - on the next page as "the loop will only continue if that specification evaluates to true during execution regardless of the minimum number of iterations specified in the loop." We may guess that as per UML 2.3, the loop is expected to execute minimum 5 times and no more than 10 times. If guard condition [size<0] becomes false loop terminates regardless of the minimum number of iterations specified. (Then why do we need that min number specified?!)
Break
The interaction operator break represents a breaking or exceptional scenario that is performed instead of the remainder of the enclosing interaction fragment. Note, UML allows only one level - directly enclosing interaction fragment - to be abandoned. This could become really annoying if double loop or loop with other combined fragments should be broken.
Break enclosing loop if y>0.
Parallel
The interaction operator par defines potentially parallel execution of behaviors of the operands of the combined fragment. Different operands can be interleaved in any way as long as the ordering imposed by each operand is preserved.
Search Google, Bing and Ask in any order, possibly parallel. Parallel combined fragment has a notational shorthand for the common situations where the order of events on one lifeline is insignificant. In a coregion area of a lifeline restricted by horizontal square brackets all directly contained fragments are considered as separate operands of a parallel combined fragment.
Coregion - search Google, Bing and Ask in any order, possibly parallel.
Page 27 of 41
Strict Sequencing
The interaction operator strict requires a strict sequencing (order) of the operands on the first level within the combined fragment.
Search Google, Bing and Yahoo in the strict sequential order.
Weak Sequencing
Weak sequencing seq is defined by the set of traces with these properties: The ordering of occurrence specifications within each of the operands are maintained in the result. Occurrence specifications on different lifelines from different operands may come in any order. Occurrence specifications on the same lifeline from different operands are ordered such that an occurrence specification of the first operand comes before that of the second operand. Thus weak sequencing seq reduces to a parallel merge when the operands are on disjunct sets of participants. Weak sequencing reduces to strict sequencing when the operands work on only one participant.
Search Google possibly parallel with Bing and Yahoo, but search Bing before Yahoo.
Critical Region
The interaction operator critical defines that the combined fragment represents a critical region . A critical region is a region with traces that cannot be interleaved by other occurrence specifications (on the lifelines covered by the region). This means that the region is treated atomically by the enclosing fragment and can't be interleaved, e.g. by parallel operator.
Add() or remove() could be called in parallel, but each one should run as a critical region.
Ignore
Interaction operator ignore means that there are some messages that are not shown within this combined fragment. These message types can be considered insignificant and are implicitly ignored if they appear in a corresponding execution. The list of ignored messages follows the operand enclosed in a pair of curly braces "{" and "}". Ignore operation is typically combined with other operations such as "assert ignore {m, s}."
Ignore get and set messages, if any.
Page 28 of 41
Consider
The interaction operator consider defines which messages should be considered within this combined fragment, meaning that any other message will be ignored. The list of considered messages follows the operand enclosed in a pair of curly braces "{" and "}". Consider operation is typically combined with other operations such as "assert consider {m, s}."
Consider only add() or remove() messages, ignore any other.
Assert
The interaction operator assert means that the combined fragment represents the assertion that the sequences of the assert operand are the only valid continuations (must be satisfied by a correct design of the system). All other continuations result in an invalid trace.
Commit() message should occur at this point, following with evaluation of state invariant.
Negative
The interaction operator neg describes combined fragment of traces that are defined to be negative (invalid). Negative traces are the traces which occur when the system has failed. All interaction fragments that are different from the negative are considered positive , meaning that they describe traces that are valid and should be possible.
Should we receive back timeout message, it means the system has failed.
Interaction Use
Interaction use is interaction fragment which allows to use (or call) another interaction. Large and complex sequence diagrams could be simplified with interaction uses. It is also common reusing some interaction between several other interactions. The interaction use is shown as a combined fragment with operator ref.
Web customer and Bookshop use (reference) interaction Checkout. The syntax of the interaction use of the ref operator is: interaction-use ::= [ attribute-name '=' ] [ collaboration-use '.' ] interaction-name [ io-arguments ] [ ':' return-value ] io-arguments ::= '(' io-argument [ ',' io-argument ]* ')' io-argument ::= in-argument | 'out' out-argument
Use Login interaction to authenticate user and assign result back to the user attribute of Site Controller.
Page 29 of 41
Activity Diagrams Reference

Notation Activity
Activity is parameterized behavior represented as coordinated flow of actions . Activity could be rendered as round-cornered rectangle with activity name in the upper left corner and nodes and edges of the activity inside.
Description
Online Shopping activity. Activity parameters are displayed on the border and listed below the activity name as: parameter-name: parameter-type .
Authenticate User activity with two parameters - Login Id and Password. The round-cornered activity border may be replaced with the diagram frame. The kind of the frame in this case is activity or act in short form. Activity parameters if any are displayed on the frame.
Authenticate User activity frame with two parameters - Login Id and Password.
Partition
An activity partition is activity group for actions that have some common characteristic. Activity partition may be shown using a swimlane notation - with two, usually parallel lines, either horizontal or vertical, and a name labeling the partition in a box at one end.
Activity partitions Customer and Order Dept as horizontal swimlanes.
Page 30 of 41
Activity partitions Customer and Order Dept as vertical swimlanes. Hierarchical partitioning is represented using swimlanes for subpartitions.
Hierarchical partitioning with subpartitions. When activities are considered to occur outside the domain of a particular model, the partition can be labeled with the keyword external.
Buy action occurs in external partition Customer. In the situations when we can't use swimlanes to show partitions, alternate text notation with qualified action name could be used instead. In this case partition name is placed in parenthesis above the action name. A comma-delimited list of partition names means that the node is contained in more than one partition. A double colon within a partition name indicates that the partition is nested, with the larger partitions coming earlier in the name.
Buy action occurs in external partition Customer.
Action
Actions are notated as round-cornered rectangles. The name of the action or other description of it may appear in the symbol.
The Process Order action Action could be expressed in some application-dependent action language.
Example of action expressed in some application-dependentaction language.
Page 31 of 41
Local pre-conditions and local post-conditions are shown as notes attached to the invocation with the keywords localPrecondition and localPostcondition, respectively.
Local pre- and post-conditions shown as notes attached to Process Order action. In the situations when we can't use swimlanes to show partitions, alternate text notation with qualified action name could be used instead. In this case partition name is placed in parenthesis above the action name. A comma-delimited list of partition names means that the node is contained in more than one partition. A double colon within a partition name indicates that the partition is nested, with the larger partitions coming earlier in the name.
Buy action occurs in external partition Customer.
Object Action
Object actions include different actions on objects. Object action is not present explicitly in UML standard, it is added here for clarity. In the UML standard all object actions are direct subclasses of action. Object actions: create object action destroy object action test identity action read self action value specification action start classifier behavior action read is classified object action reclassify object action read extend action

Variable Action
Variable actions overview diagram
Page 32 of 41
Invocation Action
Invocation actions overview diagram
Call Behavior Action

Call behavior action is a call action that invokes a behavior directly rather than invoking an operation that invokes the behavior. It is shown as action with the name of the behavior that is performed by the action or description of the behavior placed inside the action's round-cornered rectangle. If the node name is different than the behavior name, then it appears in the symbol instead. Note, that because it looks exactly the same way as the common action, there is no way just looking at the diagram to say whether the name is common action name, call behavior action name or some behavior name. Call activity action is indicated by a rake-style symbol within the action symbol. Note, that though UML 2.4 specification provides this notation, there is no official call activity action in the UML specification. Call activity action for User Authentication activity
Call behavior action for Checkout behavior
Send Signal Action

Send signal action is an invocation action that creates a signal from its inputs, and transmits it to the specified target object, where it may cause the firing of a state machine transition or the execution of an activity. When all the prerequisites of the action execution are satisfied, a signal is generated from the arguments and is transmitted to the identified target object. The sender of the signal (aka "requestor") continues execution immediately, without waiting for any response. Send signal action is notated as convex pentagon. Note, that the name of the action corresponds to the name of signal class it sends. Target object is not specified with this notation.
Notify Customer send signal action creates and sendsNotify Customer signal
Page 33 of 41
Structural Feature Action
Structural feature actions overview diagram
Link Action
Link actions overview diagram.
Page 34 of 41
Event Action
Event actions overview diagram.
Accept Event Action

Accept event action is notated with a concave pentagon. If an accept event action has no incoming edges , then the action starts when the containing activity or structured node does, whichever most immediately contains the action. In addition, an accept event action with no incoming edges remains enabled after it accepts an event. It does not terminate after accepting an event and outputting a value, but continues to wait for other events. An action whose trigger is a signal event is informally called accept signal action. It corresponds to send signal action.
Acceptance of the Accept Order signal causes an invocation of a Process Order action. The accept event action Accept Order is enabled on entry to the activity containing it, therefore no input arrow is shown.
Accept Event Action with incoming edges

Accept event action could have incoming edges. In this case the action starts after the previous action completes.
Payment Requested signal is sent. The activity then waits to receive Payment Confirmed signal. Acceptance of the Payment Confirmed is enabled only after the request for payment is sent; no confirmation is accepted until then.
Wait Time Action

If the event is a time event occurrence , the result value contains the time at which the occurrence happened. Such an action is informally called a wait time action. Accept time event action (aka informal: wait time action) is notated with an hour glass.
The Every Hour accept time event action generates an output every hour. There are no incoming edges to this time event action, so it is enabled as long as its containing activity or structured node is.
Page 35 of 41
Control Nodes
Activity control nodes overview.
Initial Node
Initial node is a control node at which flow starts when the activity is invoked. Activity may have more than one initial node. Initial nodes are shown as a small solid circle.
Activity initial node.
Flow Final Node

Flow final node is a control final node that terminates a flow. The notation for flow final node is small circle with X inside. Flow final node.
Activity Final Node

Activity final node is a control final node that stops all flows in an activity . Activity final is new in UML 2.0. Activity final nodes are shown as a solid circle with a hollow circle inside. It can be thought of as a goal notated as "bulls eye," or target.
Activity final node.
Decision
Decision node is a control node that accepts tokens on one or two incoming edges and selects one outgoing edge from one or more outgoing flows. The notation for a decision node is a diamond-shaped symbol.
Decision node with two outgoing edges with guards. For decision points , a predefined guard "else" may be defined for at most one outgoing edge.
Decision node with three outgoing edges and [else] guard.
Page 36 of 41
Decision can have decision input behavior . Decision input behaviors were introduced in UML to avoid redundant recalculations in guards. In this case each data token is passed to the behavior before guards are evaluated on the outgoing edges. The output of the behavior is available to each guard. Decision input behavior is specified by the keyword decisionInput and some decision behavior or condition placed in a note symbol , and attached to the appropriate decision node.
Decision node with decision input behavior. Decision may also have decision input flow . In this case the tokens offered on the decision input flow that are made available to the guard on each outgoing edge determine whether the offer on the regular incoming edge is passed along that outgoing edge. A decision input flow is specified by the keyword decisionInputFlow annotating that flow.
Decision node with decision input flow .
Merge
Merge node is a control node that brings together multiple incoming alternate flows to accept single outgoing flow. There is no joining of tokens. Merge should not be used to synchronize concurrent flows . The notation for a merge node is a diamond-shaped symbol with two or more edges entering it and a single activity edge leaving it.
Merge node with three incoming edges and a single outgoing edge.
Merge and decision combined

The functionality of merge node and decision node can be combined by using the same node symbol.
Merge node and decision node combined.
Fork
Fork node is a control node that has one incoming edge and multiple outgoing edges and is used to split incoming flow into multiple concurrent flows. The notation for a fork node is a line segment with a single activity edge entering it, and two or more edges leaving it.
Fork node with a single activity edge entering it, and three edges leaving it.
Join Node
Join node is a control node that has multiple incoming edges and one outgoing edge and is used to synchronize incoming concurrent flows. The notation for a join node is a line segment with several activity edges entering it, and only one edge leaving it.
Join node with three activity edges entering it, and a single edge leaving it.
Join specifications are shown in curly braces near the join node as joinSpec=....
Join node with join specification shown in curly braces.
Page 37 of 41
Join and fork combined

The functionality of join node and fork node can be combined by using the same node symbol.
Combined join node and fork node.
Activity Edge
Activity edge could be control edge or data flow edge (aka object flow edge). Both are notated by an open arrowhead line connecting activity nodes. Activity edge connects Fill Order and Review Order. Activity edge can be named, however, edges are not required to have unique names within an activity. If the edge has a name, it is notated near the arrow. Activity edge "updated" connects Update Order and Review Order. The guard of the activity edge is shown in square brackets that contain the guard. The guard must evaluate to true for every token that is offered to pass along the edge. Fill Order when priority is 1 An activity edge can be notated using a connector, which is a small circle with a name (also called label ) in it. Connectors are generally used to avoid drawing a long edge. This is purely notational. Every connector with a given label must be paired with exactly one other with the same label on the same activity diagram. The circles and lines involved map to a single activity edge in the model.
Connector A connects two edges between Fill Order and Review Order.
Object Flow Edge

Object flow edges are activity edges used to show data flow between action nodes. Object flow edges have no specific notation.
Data flow of Orders between Fill Order and Review Order actions The weight of the edge may be shown in curly braces that contain the weight. The weight is a value specification, which may be a constant, that evaluates to a non-zero unlimited natural value. An unlimited weight is notated as "*". Send Notification when number of Warnings reaches 6
Interrupting Edge
Interrupting edge is activity edge expressing interruption for regions having interruptions. It is rendered as a lightning-bolt.
Cancel Request signal causes interruption resulting in Cancel Order.
Page 38 of 41
An option for notating an Interrupting edge is a zig zag adornment on a straight line.
Cancel Request signal causes interruption resulting in Cancel Order.
Object Nodes
Activity object nodes include parameter, pin, central buffer, expansion nodes.
Pin
A pin is an object node for inputs and outputs to actions. Pin is usually shown as a small rectangle attached to the action rectangle. The name of the pin can be displayed near the pin. Item is input pin to the Add to Shopping Cart action.
Invoice is output pin from the Create Invoice action.
Data Store
A data store is a central buffer node for non-transient information. The data store is notated as an object node with the keyword datastore. Incoming Patient token is stored by the Patients data store.
Page 39 of 41
Communication Diagrams Reference

Notation Frame
Communication diagrams could be shown within a rectangular frame with the name in a compartment in the upper left corner. There is no specific long form name for communication diagrams heading types. The long form name interaction (used for interaction diagrams in general) could be used.
Description
Interaction frame for communication diagram BuyItem. There is also no specific short form name for Communication Diagrams . Short form name sd (which is used for interaction diagrams in general) could be used. This sd is bit confusing as it looks like abbreviation ofsequence diagram.
Sd Frame for Communication Diagram BuyItem.
Lifeline
A lifeline is shown as a rectangle (corresponding to head in sequence diagrams). Lifeline in sequence diagrams does have "tail" representing the line of life whereas "lifeline" in communication diagram has no line, just "head". Lifeline with name "data" of class Stock.
Anonymous Lifeline
Anonymous lifeline has no name - arbitrary representative of class.
Anonymous lifeline of class User.
Lifeline with Selector

Selector could be used to specify some lifeline from collection.
Lifeline "x" of class X is selected with selector [k].
Sequential Messages
The sequence expression is a dot separated list of sequence terms followed by a colon (":"). Message name follows the sequence expression. sequence-expression ::= sequence-term '.' . . . ':' messagename sequence-term ::= [ integer [ name ] ] [ recurrence ] The integer represents the sequential order of the message within the next higher level of procedural calling (activation).
Instance of A sends draw() message to instance of B, and after that B sends paint() to instance of C.
Page 40 of 41
Concurrent Messages
The name in sequence expression represents a concurrent thread of control. Messages that differ in the final name are concurrent at that level of nesting.
Instance of A sends draw() messages concurrently to instance of B and to instance of C.
Conditional Messages
A guard specifies condition for the message to be sent (executed) at the given nesting depth. UML does not specify guard syntax, so it could be expressed in pseudocode, some programming language, or something else. sequence-term ::= [ integer [ name ] ] '[' guard ']' Instance of class A will send message draw() to the instance of C, if x > y.
Sequential Loop
An iteration specifies a sequence of messages at the given nesting depth. UML does not specify iteration-clause syntax, so it could be expressed in pseudocode, some programming language, or something else. Iteration clause may be omitted, in which case the iteration conditions are unspecified. sequence-term ::= [ integer [ name ] ] '*' [ '[' iteration-clause ']' ]
Instance of class A will send search() message to instance of B n times, one by one.
Concurrent Loop
An iteration specifies a sequence of messages at the given nesting depth. UML does not specify iteration-clause syntax, so it could be expressed in pseudocode, some programming language, or something else. Iteration clause may be omitted, in which case the iteration conditions are unspecified. The *|| (star followed by a double vertical line) iteration notation specifies concurrent (parallel) execution of messages. sequence-term ::= [ integer [ name ] ] '*||' [ '[' iteration-clause ']' ]
Instance of class A will send n concurrent search() messages to instance of B.
Page 41 of 41

UML Diagrams References

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UML Diagrams References

Uploaded by

Copyright:

Available Formats

UML Diagrams References

Copied-Pasted by Dip Thanh Nguyn, 2014

Classification of UML 2.5 Diagrams

Copied-Pasted by Dip Thanh Nguyn, 2014

UML 2.5 Structure Diagrams

Elements class, interface, feature,co nstraint, association,gene ralization, dependency.

Composite structure diagram

Internal structure diagram Collaboration use diagram Component diagram

structured class, property,part, port, connector, usage.

Copied-Pasted by Dip Thanh Nguyn, 2014

UML 2.5 Behavior Diagrams

Information flow diagram

State machine diagram

Behavioral state machine diagram Protocol state machine diagram

Copied-Pasted by Dip Thanh Nguyn, 2014

Interaction overview diagram

Copied-Pasted by Dip Thanh Nguyn, 2014

Class Diagrams Reference

Math is utility class - having static attributes and operations (underlined)

Copied-Pasted by Dip Thanh Nguyn, 2014

Class SearchRequest is abstract class .

Copied-Pasted by Dip Thanh Nguyn, 2014

Structured data type Address

Copied-Pasted by Dip Thanh Nguyn, 2014

Primitive data type Weight.

Feature overview diagram

Copied-Pasted by Dip Thanh Nguyn, 2014

Copied-Pasted by Dip Thanh Nguyn, 2014

oper-constraint - is a constraint that applies to the operation.

Bank account constraints - non empty owner and positive balance

1..1 0..* 1..*

Copied-Pasted by Dip Thanh Nguyn, 2014

At least m but no more than n instances

Order of the ends and reading: Car - was designed in - Year

Ternary association Design relating three classifiers.

Copied-Pasted by Dip Thanh Nguyn, 2014

Composite Aggregation (Composition)

Ownership of Association End

Association end qb is an attribute of SearchService class and is owned by the class.

A3 is not navigable from B3 while B3 has unspecified navigability.

A4 is not navigable from B4 while B4 is navigable from A4.

A5 is navigable from B5 and B5 is navigable from A5.

Copied-Pasted by Dip Thanh Nguyn, 2014

A6 is not navigable from B6 and B6 is not navigable from A6.

Checking, Savings, and Credit Accounts are generalized by Account.

Data Access depends on Connection Pool

Search Controller uses Search Engine.

Interface SiteSearch is used (required) by SearchController.

Copied-Pasted by Dip Thanh Nguyn, 2014

Copied-Pasted by Dip Thanh Nguyn, 2014

Use Case Diagrams Reference

Weather Service subject stereotyped as service.

Applicability of Use Cases

Ownership of Use Cases

Retail Website subject owns use cases.

Copied-Pasted by Dip Thanh Nguyn, 2014

Custom icon for Web Client actor.

Customer actor as Class.

Generalization between actors

Copied-Pasted by Dip Thanh Nguyn, 2014

Copied-Pasted by Dip Thanh Nguyn, 2014

Generalization between use cases

Copied-Pasted by Dip Thanh Nguyn, 2014

Actor Customer associated with two use cases.