Use Case Diagram Syntax

The parts of the syntax are explained in the following paragraphs. At the end of the document, there is a complete example of a valid use case diagram that uses many of the mentioned features.

General elements

• A use case diagram always starts with @start-uscd, ends with @end-uscd, and requires to put a title in quotation marks right after the start tag, e.g. @start-uscd "My Use Cases". In the second place, the default package “RootElement” must be declared with rootPackage RootElement. So, the basic structure of a use case diagram looks like the following example:

   @start-uscd "My Use Cases"
   @end-uscd

• Unique identifiers are used to define core UML elements, for instance, classes, associations, packages, interfaces, etc.
• Indentation is not relevant – everything can be formatted left-aligned. Though, spaces are relevant to distinguish between elements. Strings are not restricted in length and must be put in quotation marks.
• The ordering of elements is restricted by their type: First, all actors are specified. Second, the systems are defined. Use cases are located in systems. Last, the relationshipts between elements are given.

Actors

• Actors are defined with the keyword act and need a unique identifier that is given directly after the keyword

act SomeActor

• You can assign a more extensive name by giving the name in quotes after the keyword as. Please note that you always have to refer to the actor by its name instead of its long name.

act SomeActor as "Some Actor"

• The type of the actor can be specified by assignin a role to it. Available roles are system and human. In order to assign the role, add the keyword role after the name (or alias is used) prepended by the role name in square brackets.

act CashDesk role[system]
act Customer role[human]

Systems

• Systems hold the use cases that describe its features. A system is defined with the keyword sys followed by curly brackets. The curly brackets contain the use cases.

sys Bookstore {
  uc Sell
}

Use Cases

• Use cases start with the keyword uc and need a name unique with respect to the system.

uc Sell

• Use cases can have more extensive names defined in quotes after the keyword as.

uc sell as "Sell some goods"

Associations

• Associations are defined between use cases and actors. They are located outside of the system. An association starts with the keyword iac (interacts). Afterwards, the actor has to be given first and the use case second in brackets separated by a comma.

act Person
sys Bookstore {
  uc Sell
}
iac (Person, Sell)

• Associations can have cardinalities. Cardinalities are specified by the keyword card followed by the multiplicities in square brackets separated by a colon.

iac (Person, Sell) card[2:1]

• Notes: The default cardinality is 0..1

Generalizations

• Generalizations are possible between actors and use cases. Generalizations start with the keyword isa followed by the participants given as comma separated list in brackets. The specific element is given first. The general element is given second. Generalizations between use cases are located inside the system. Generalizations between actors are located outside of the system.

act Person
act Salesman
sys Bookstore {
  uc Sell
  uc SellPremium
  isa (SellPremium, Sell)
}
isa (Salesman, Person)

Relationships between Use Cases

• All relationships between use cases are located inside the system.
• Include relationships are defined by the keyword inc followed by the participants given as comma separated list in brackets. The including use case is the first one, the included use case the second one.

sys Bookstore{
  uc Sell
  uc Pay
  inc (Sell, Pay)
}

• Extend relationships are defined by the keyword ext followed by the participants given as comma separated list in brackets. The first use case defines the extending use case. The second use case is the extended use case. Additionally, the extension point that is used to extend a use case has to be given with the keyword ep followed by the name of the extension point in square brackets. The condition for the extension is optional and can be given with the keyword cond followed by the quoted condition in square brackets. The extension point is defined in curly brackets after the use case definition by writing the keyword ep followed by the name of the extension point.

sys Bookstore {
  uc Sell {
    ep Wrapping
  }
  uc WrapAsPresent
  ext (WrapAsPresent, Sell) ep[Wrapping] cond["Receiver!=Buyer"]
}

Notes

• Notes can be given for actors, systems and use cases. They start with the keyword note followed by the quotes comment.
• Actors can have a note at the end of its definition

act Person note "Some comment"

• Systems can have a note after its name if there are no use cases contained or as first entry after the curly bracket if there are use cases contained.

sys Bookstore {
  note "Some comment"
  uc Sell
}
sys Accounting note "Some other comment"

Example

@start-ucd "example"

rootElement RootElement

act Person role[human]
act Customer
act Salesman note "Person that sells books"
act CashDesk role[machine]

sys Bookstore {
	note "Plain old book store"
	uc sell
	uc pay {
		ep paymentMethod
	}

	uc payByCard note "Supports credit and debit cards"
	uc payByCash
        inc (sell, pay)
        ext (payByCard, pay) ep[paymentMethod] cond["Customer wants to pay by card"]
        ext (payByCash, pay) ep[paymentMethod] cond["Customer wants to pay by cash"]
}

isa (Customer, Person)
isa (Salesman, Person)
iac (Customer, Bookstore.sell) card[0..1 :0..1]
iac (Salesman, Bookstore.sell) card[0..*]

@end-ucd