Interfaces (2)

shortcut notation for interface

Hashable String . .. isEqual(String):Boolean hash():Integer . .. * contents Comparable HashTable

association
uses

dependency relationship Realizes relationships

interface Comparable isEqual(String):Boolean hash():Integer

Dorothea Beringer, 1999

UML

Associations
Company Job employer employee Person

Job salary

association class (class-like properties like operations, attributes, associations)

worker

boss role 0..1 multiplicity

Adornments:

binary association

ordering: {ordered} changeability: {frozen}, {addOnly} Manages visibility: +, #, navigability: direction of arrow interface specifier: :nameOfInterface
Constraints: e.g. {or}, {subset}

Dorothea Beringer, 1999

UML

Aggregation and Composition (1)

Composition is a form of aggregation with strong ownership and coincident lifetime of the part with the whole.
unshared multiplicity of aggregate end is 0 or 1

1 Polygon 1

+points 3.. Contains {ordered} 1

Point

GraphicsBundle

-bundle color texture density

Other example: bicycles in shop (composition, physical aggregation) or in a catalog (catalog aggregation)
Dorothea Beringer, 1999 UML 3

Composition
Different yet equal representations:

Window scrollbar [2]: Slider title: Header body: Panel

Window
Dorothea Beringer, 1999

1 UML

Specialization- Generalization
Generalization is the taxonomic relationship between a more general and a more specific element (classes, use cases, interfaces, ) that:
is fully consistent with the first element and adds additional information.

Tree {disjoint, incomplete} species

Adornments:
{overlapping} or {disjoint} {incomplete} or {complete}
Elm Birch

Oak

discriminator (name of a partition of subtypes of a supertype)

Dorothea Beringer, 1999 UML 5

Dependencies
A dependency relationship between two elements (e.g. classes) indicates that a change to the target element (e.g. deletion) may require a change to the source element.

ClassA

friend

ClassB

see also example interfaces

instantiates

Some predefined keywords:

calls

ClassC

Element A does not function without element B: {uses} Historically different elements (new and old) on different abstraction levels but represent same concept: {trace} Element A calls functions of element B: {calls} Friend-relationship as used in C++: {friend}
Dorothea Beringer, 1999 UML 6

Dependency Graphs
Dependency graphs just show all dependencies between classes, often without keywords. Usage graphs only show all the use dependencies. How do you derive dependency graphs?
==> rather for quality analysis of existing models and software than for documentation Goals: minimize dependency on too many classes to improve maintenance maximize cohesion within and minimize coupling between classes (use dependencies) to decrease complexity
Dorothea Beringer, 1999 UML 7

CRC
CRC: Class - Responsibility - Collaboration
CRC-Cards are (together with some diagrams) cornerstone of RDD (responsibility driven design), an alternative to UML classes are found by looking for responsibilities classes are documented on cards by stating class name, responsibility and collaborators (attributes and operations are added later on in design) class diagrams are refactored (changing the structure of the diagram without changing its overall behavior) based on responsibilities and various quality criteria

==> add a compartment responsibility or put the responsibility into the class description and think in responsibilities ==> no good class diagram without at least one or two (major) refactoring (==> iterative process!)
Dorothea Beringer, 1999 UML 8

Whole Values and Quantities

Distinguish between atomic types, whole values, and quantities:
social security number (d: possible operations?) your height number of CDs you have phone number purchase price of a book (d: possible operations?) name of authors of a book number of authors of a book credit card number

==> whole values and quantities belong are classes, operations on them belong into these classes and not into some containing class ==> do not mix concepts together into one object! ==> make small objects and group them into packages!
Dorothea Beringer, 1999 UML 9

Goals of Modeling
Different goals:
Goals determine the content ==> you better know your goal Examples for goals? (b: make list)

Different abstraction levels

The same system/problem can be modeled on different abstraction levels, resulting in several models Example abstraction levels for specific goals? How do models on different abstraction levels relate to each other? (d) just adding more details, refinement, attributes become operations, no 1:1 mapping

Different views:
The same model can be represented by various diagrams Possible views for specific goals?(d)
Dorothea Beringer, 1999 UML 10

Static object diagrams

Snapshot of the system at a point of time showing a subset of its objects, their states, attribute values, links. Syntax: objectname : classnames [statenames]
attributename : type = value

awindow : Window horizontalBar:ScrollBar verticalBar:ScrollBar moves

triangle: Polygon
center = (0,0) vertices = ((0,0),(4,0),(4,3)) Dorothea Beringer, 1999

:Polygon

surface:Pane

moves

title:TitleBar
UML 11

Packages - Subsystems
Packages allow to group classes and other model elements
into subsystems (keyword <<subsystem>>) into a framework (keyword <<framework>>) <<system> contains all classes
<<subsystem>> Finances

<<subsystem>> Finances <<subsystem>> Finances Charge Account () Credit Account () Process Payments () Payment Status (): status
Dorothea Beringer, 1999 UML

<<subsystem>> <<subsystem>> Credits BankInterface

<<subsystem>> Accounts

12

Packages - Dependencies
Examples of an architecture diagram showing subsystems and their dependencies:

<<subsystem>> User Interface

<<subsystem>> Business Rules Benefits

<<subsystem>> Business Rules Salary

<<subsystem>> Database
Dorothea Beringer, 1999 UML 13

Subsystems - Design Criteria

Each subsystem should have:
a single functionality strong cohesion: strong relationships between classes within subsystem loose (external) coupling: minimize dependencies among subsystems minimal communication to other subsystems reusability (d: what are the criteria here?)

Also: consider architecture of systems you are integrating with and architecture preferences of COTS subsystems.

See also architectural patterns (lecture on architecture).

Dorothea Beringer, 1999 UML 14

Breaking down Use Cases (1)

Assign steps of a use case to the various subsystems (taking into account responsibility of subsystem). One (or part of or several) step(s) of the system-wide use case becomes one use case of a subsystem. ==> superordinate use case, its subordinate use cases
The other subsystems (only those with which interaction is necessary for carrying out the step) become actors of this subsystem. Who is the trigger of this new use case? A new, more detailed description of the subsystem use case is created, containing again several steps.

If use case is still to high-level and complex, iterate!

Dorothea Beringer, 1999 UML 15

Sequence Diagrams
A sequence diagram represents an Interaction, which is a set of messages exchanged among objects within a collaboration to effect a desired operation or result.
roles (object or group of objects)
op() ob1:C1 [x>0] foo(x) [x<0] bar(x) doit(w) ob3:C3 ob4:C4

Generic form
(shows all possible sequences of an interaction)

lifelines
conditionality, guards focus of control (control flow, duration of action)

ob2:C2 doit(z)

destruction of an object
diagram continues
Dorothea Beringer, 1999 UML 16

Sequence Diagram with Timing

Instance form
active/concurrent objects (thick border)
{b - a < 1 sec.} caller a b {c - b < 10 sec.} c The call is d routed through the network. d' {d' - d< 5 sec.} lift receiver dial tone exchange receiver

timing constraints timing marks

dial digit ... route ringing tone phone rings answer phone

description of actions
stop tone

Dorothea Beringer, 1999

At this point the parties can talk.

stop ringing
17

UML

Messages
A message conveys information and triggers action in another (or the same) object and is represented by a call arrow.
message name: signature of method called (parameters and return values may be omitted) or name of signal/event sent procedure call: return from procedure call (may be omitted in procedural flow of control): asynchronous message: or simply for all messages: branching: several call-arrows with guard-conditions iteration: all messages in loop are marked Additional symbols and modeling rules: see UML-books

Dorothea Beringer, 1999

UML

18

Collaboration Diagrams
A collaboration diagram shows an interaction organized around the objects in the interaction, and their links to each other.
shows relationships among objects roles time is no separate dimension

No time axis sequence numbers are used for showing ordering of messages.
procedural flow of control: nested numbering according to call nesting non-procedural flow: non-nested numbering with predecessors to indicate order of messages and synchronisation among threads, details see UML-books

Dorothea Beringer, 1999

UML

19

Collaboration Diagrams: Example (1)

redisplay() :Controller window :Windowlinks parameterwindow

call arrows

iteration with guard

wire

1: displayPositions(window) contents {new} localline 1.1.2: create(r0,r1) 1.1.3: display(window) :Line {new}

sequence numbers
self

wire: Wire i-1 i

1.1.1a: r0 := position()

1.1.1b: r1:=position()

left: Bead
1.1*[i:=1..n]: drawSegment(i)
Dorothea Beringer, 1999 UML

right: Bead

Adornments: {new} {destroyed} {transient} parameter local self

20

Collaboration Diagrams: Example (2)

An active object is one that owns a thread of control and may initiate control activity:
thick border {active}
sequence number of this message
B2: completed 1 / B1: start(job)
{local} job currentJob :TransferJob job :Factory Scheduler

:Factory Mana

1: start(job) A2,B2 / 2: completed(job)

:Factory JobMgr

A2: complete

1 / A1: start(

sequence numbers of predecessors

:Robot
Dorothea Beringer, 1999 UML

:Oven
21

Collaboration, Interaction, Role

Collaboration: A collaboration is a set of participants and relationships that are meaningful for a given set of purposes. Participants in a collaboration are objects-roles, i.e. objects having a collaboration-specific role. The same objects can play different roles in different collaborations. Interaction: A specific pattern of message exchanges to accomplish a specific purpose is called an interaction. The interaction may be specified either by a single description containing conditionals (e.g. generic sequence diagram), or multiple descriptions each describing a particular path through the possible execution paths.

Context: Most often we model the interaction of the objects of a collaboration; the collaboration then shows the context in which the interaction occurs.
Dorothea Beringer, 1999 UML 22

Using Interaction Diagrams

Interaction diagrams are used for many things, e.g.
documenting the internal message flow for a use case documenting which classes collaborate for a specific use case (with or without details concerning message flows) Alternative: just list all classes involved in a use case documenting architecture decisions documenting reoccurring design patterns finding classes and operations explaining and demonstrating certain operations showing all collaborators for a specific class showing different roles of an object

Interaction diagrams can be on different levels of granularity, yet UML does not provide any modeling concepts to link the various diagrams.
Dorothea Beringer, 1999 UML 23

Completeness
Maintained documentation: Description or pseudo-code at the left-hand side? Operations with parameters and return-value? Also types in parameter list? For which scenarios of a use case? For which use cases?
Verification of analysis/design models: What is needed for verifying the models? Validation of models with customers and end-users: Which models or views would you like for validation that you are developing the right system?
Dorothea Beringer, 1999 UML 24

Statechart Diagrams
A statechart diagram represents a state machine which is a graph of states and transitions that describes the response of an object of a given class to the receipt of outside stimuli.
statecharts of David Harel with various extensions, e.g. from Petri Nets, OMT powerful and well accepted notation

Elements of statecharts:
composite states, concurrent states actions and activities, entry-actions, exit-actions, transition-actions, sending messages events, ChangeEvent, SignalEvent, CallEvent, TimeEvent simple transitions, complex transitions

Dorothea Beringer, 1999

UML

25

Nested States (1)

state Dialing is decomposed using or-relationship into mutually exclusive disjoint substates

start state - end state within Dialing activities given by entry and exit action events can be methods of certain classes what does state diagram describe? a method, a class, ?
UML 26

(b: automatic transmission, effective gears, set gear, motor status, speed)
Dorothea Beringer, 1999

Nested States (2)

state Incomplete is decomposed using and-relationship into concurrent substates

Dorothea Beringer, 1999

UML

27

Nested States (3)

complex transition: all events before bar must have happened before transition to all states after bar happens

history indicator: A2 is chosen the first time, later on resume goes to the state active before interrupt happened

Dorothea Beringer, 1999

UML

28

Nested States (4)

activities denoted by do composite state guards on events

(b: add outermost start and end states: object is created and deleted, complete state diagram reflects whole life of object)
Dorothea Beringer, 1999 UML 29

Events (1)
An event is a noteworthy occurrence. For practical purposes in state diagrams, it is an occurrence that may trigger a state transition, e.g.:
receipt of a call for an operation by an object (CallEvent) object-name.operation-name (parameter-list) explicit signal from one object or subsystem to another (SignalEvent) ==> arbitrary high level signal-name (parameter-list), looks like CallEvent passage of a designated period of time after a specific other event (e.g. entry into current state) (TimeEvent) after (time) condition comes true (ChangeEvent) when (condition) (d: difference to guards, loosing events)

Signals:
can be represented like classes with keyword <<signal>> and a compartment for parameters build inheritance hierarchies
Dorothea Beringer, 1999 UML 30

Events (2)
Actions:
event-name (argument-list ) [ guard-condition ] / action-expressions ^ send-clauses any event names allowed, apart from keywords entry, exit, do guard-condition: boolean expression using parameters of the triggering event and attributes,links or states of object owning state diagram or of reachable (via links) object action-expression: atomic uninterruptible operation, operations are executed sequentially send-clause: destination-expression . operation-or-signal-name ( argument-list ) Example: right-mouse-down(location) [location in window] / object := pick-object(location) ^ object.highlight()
(d: how much to write down about a transition?)
Dorothea Beringer, 1999 UML 31

Interactions on State Charts

dashed arrow corresponds to send-clause rectangles denote object/subsystem this state chart belongs to

Dorothea Beringer, 1999

UML

32

Events (3)
Invocation of a nested state machine:
do / name_of_nested_state_diagram (argument-list) calls the state machine diagrammed somewhere else ==> one way to split up a diagram consider other activities as a nested state machines without diagram

Internal transition:
when event help occurs, action display help is carried out
help / display help

difference between these two diagrams?

Dorothea Beringer, 1999 UML 33

Activity Diagrams
An activity diagram describes the flow of control (and data) through the various stages (action states) of a procedure (operation, use case, ).
Is like a state diagram where the states are all action states and the transitions are automatic has characteristics of state-transition, data-flow, SDL and interaction diagrams has symbols for action states, branching, decisions, receiving and sending events, object flow, swimlines...

Used for:
describing algorithmic aspects of an operation of an object describing flow of data through the system describing actions of a use use either the whole activity diagram is owned by own object, or each object or group of object has a swimline
UML 34

Dorothea Beringer, 1999

Activity Diagram with Swimlanes

Signal receipt and signal sending:

Dorothea Beringer, 1999

UML

35

Activity Diagram with Dataflow

Dorothea Beringer, 1999

UML

36

Further Concepts in UML

Model and class organization: packages Other classifiers and predefined stereotypes like datatype, type (defines role), implementation class (realizes type) Templates, bind-dependency-relationship Utilities, metaclasses Qualifiers, qualified associations, n-ary associations Signals, data-tokens, concurrent iteration Collaboration symbol, collaboration roles Statechart diagrams and activity diagrams Extensions of UML by stereotypes (e.g. control, boundary, entity, utility, exception), additional predefined properties, constraint language, etc.
Dorothea Beringer, 1999 UML 37