Actors interact with the system by using use cases (actors initiate execution of use case) and by being used by use cases (actors provide functionality for the execution of the use case). Actors represent roles that users / systems adopt.
Specific users can adopt and set aside multiple roles simultaneously.
Actors are not part of the system / they are outside of system boundaries.
graph { label="role of the users of the system" A [shape=star label="" xlabel="A"]}
Use cases describe the functionality expected from the system under development, it provides tangible benefit for one or more actors that communicate with this use case. It is derived from the customer’s wishesw
graph { label="unit of functionality of the system" A}
Associations connect Actors and use cases via solid lines. Every actor must communicate with at least one use case. An association is always binary and multiplicities may be specified.
graph { nodesep=0.8 subgraph cluster0 { label = "Laboratory Assignment" c [label="Conduct oral exam"] } c--a c--s [label="1..3"] a [shape=star label="" xlabel="Assistant"] s [shape=star label="" xlabel="Student"]}
Generalisation shows inheritance relationships between actors or use cases.
Multiple inheritance is permitted, abstract actors are possible.
Sub-actors can access all of their use cases plus those of the super-actor.
The include relationship, ⟨⟨include⟩⟩, is where the behaviour of one use case (included use case) is integrated in the behaviour of another use case (base use case).
The extend relationship, ⟨⟨extend⟩⟩, is where the behaviour of one use case (extending use case) may be integrated in the behaviour of another use case (base use case) but does not have to. Both use cases may be executed independently of each other.
A decides if B is executed.
Extension points define at which point the behaviour is integrated.
Conditions define under which circumstances the behaviour is integrated.
Multiple extension points may be specified.
Extension points are written directly on the use case.
A class diagram shows the static class structure, they are used when developing an object-oriented system model to show the classes in a system and the associations between these classes.
It consists of:
Class (UML Class)
An object class (or just class) which can be thought of as a general definition of one kind of system object.
An aggregation is a special form of association used to express that a class is part of another class, properties of the aggregation association include:
transitive: if B is part of A and C is part of B, C is also part of A
asymmetric: it is not possible for A to be part of B and B to be part of A at the same time
There are two types:
Shared Aggregation (UML Class)
A sharedaggregation expresses “a weak belonging of the parts to a whole” where parts also exist independently of the whole. Multiplicity at the aggregating end may be ≥1 hence one element can be part of multiple other element at the same time. Syntax is a hollow diamond at the aggregating end.
A composition is an existence dependency between the composite object and its parts. One part can only be contained in at most one composite object at one specific point in time. Multiplicity at aggregating end is at maximum 1, the composite objects form a tree.
If the composite object is deleted, its parts are also deleted.
Syntax: solid diamond at the aggregating end.
For example, a Beamer is part of LectureHall which is part of Building.
The head of the lifeline is a rectangle that contains the expression roleName:Class, roles are a more general concept than objects and objects can take on different roles over their lifetime.
The body of the lifeline is a vertical (usually dashed) line which represents the life time of the object associated with it.
Time-consuming message: a message with a set duration. Usually we assume messages are transmitted with no loss of time, we express time elapses between the send and receipt of a message.
Object creation is represented by a dashed arrow with an arrowhead pointing to the head of the lifeline of the object to be created. We use the keyword new.
We can use combined fragments to model various control structures.
There are three categories of types of fragments:
Branches and loops: alt, opt, loop, break
Concurrency and order: seq, strict, par, critical
Filters and assertions: ignore, consider, assert, neg
The types of fragments are:
Alt Fragment (UML Sequence)
alt: to model alternative sequences, similar to a switch case.
Guards are used to select the one path to be executed.
They are modelled in square brackets. We may use [else] to signify any other case if other guards fail.
Guards must be disjoint to avoid in deterministic behaviour.
loop: to express that a sequence is to be executed repeatedly.
Exactly one operand.
Keyword is followed by minimal / maximal number of iterations.
(min..max) or (min, max)
Examples of equivalent notation:
loop(3,8) = loop(3..8)
loop(8,8) = loop(8)
loop = loop(*) = loop(0, *)
Guard is evaluated as soon as the minimum number of iterations has taken place, then checked also for each iteration within the limits.
If the guard evaluates to false, the execution of the loop is terminated.
Order of event occurrences on different lifelines between different operands is significant.
Messages in an operand that is higher up on the vertical axis are always exchanged before the messages in an operand that is lower down on the vertical axis.
If there is more than 1 outgoing edge, guards must be mutually exclusive and cover all possible cases to ensure that exactly one target state is reached.
If initial state becomes active, the object immediately switches to the next state.
In addition, a direction may be specified:
