Ch. 14 of the CommonKADS textbook

1. UML Notations in CommonKADS
Activity diagrams
State diagrams
Class diagrams
Use-case diagrams

2. UML notations 2
Background UML
■ Nineties: number of popular object-oriented methods
■ Unified Modeling Language: proposal for set of
standard notations
■ wide attention
➤ see www.rational.com
■ mainly meant for analysis phase

3. UML notations 3
UML notations used
■ Class diagram
➤ static information structure (“data”)
■ Activity diagram
➤ combined function/control view
■ Use-case diagram
➤ high level view of system services (functional)
■ State diagram
➤ highly interactive control

4. UML notations 4
Activity diagram
■ Model control and information flow of a procedure or
process
■ Useful if control is mainly synchronous
➤ otherwise: use state diagram
■ Use in CommonKADS: modeling the organizational
process
➤ worksheet OM-2 of the organization model
■ Can also be used to model control flow within a task
method (knowledge model)

5. UML notations 5
Action state
■ State in which some work is being done
➤ activity, task
■ State terminates when the work is finished
➤ difference with state diagrams
■ After termination the action state can lead to another
action state
➤ “state transition”
■ Special symbols for being and end of a procedure or
process

6. UML notations 6
Basic notation for activity
diagram
data
entry
processing
generate
output

7. UML notations 7
Decision
■ Sate transition is deterministic
■ If transition depends on outcome of the work, then
introduce a decision
data
entry
dump
in
waste
basket
further
processing
[data
correct]
[data
incorrect]

8. UML notations 8
Introducing concurrency
buy
food
and
drinks
cook
dinner
open
wine
bottle
have
dinner

9. UML notations 9
Swim lanes
■ Process can sometimes be distributed over several
agents or organizational units
■ Notation: use compartments
■ In particular useful when modeling a business
process (e.g. in organization model)

10. UML notations 10
Notation for swim lanes
write
tender
get
customer
information
S ALE S
DE P ARTME NT
calculate
cost
DE S IGN
DE P ARTME NT
design
elevator

11. UML notations 11
Object flow
standard
design
write
tender
get
customer
information
S ALE S
DE P ARTME NT
decide
about
design
type
custom
design
cost
calculation
elevator
design
DE S IGN
DE P ARTME NT
non-­‐standard standard
CUS TOME R
tender
customer
information

12. UML notations 12
Signals
receive
request
archive
(request)
archive
(request)
process
request
archive

13. UML notations 13
Business process “Housing”
primary
proces s
s econdary
proces s
data
entry
of
applications
magazine
production
application
assessment
residence
assignment
statistical
analysis
policy
information
:residence
assignments

14. UML notations 14
Activity diagram of method
control
cover
predict
obtain compare
[no
more
solutions
of
cover]
[new
solution
of
cover]
[result
=
equal]
[result
=
not
equal]
solution
found
no
solution
found
start
diagnosis
through
generate-­‐and-­‐test

15. UML notations 15
State diagrams
■ Synonyms: “state chart”, “state-transition diagram”
■ Purpose: model of dynamic behavior
■ Use if control is heavily influenced by “external”
events
■ Draw a state diagram for object classes with
interesting behavior
■ Activity diagram is alternative
➤ internal control
➤ object flow

16. UML notations 16
State
watching
football
match
duration
entry/switch
on
TV
do/watch
exit/turn
off
TV
state
name
state
variables
state
actions
&
activities

17. UML notations 17
State transition
■ Event: comes from outside the object modeled
■ Message: generates event for another object
■ Guard: outcome of internal object computation
ready
for
take
off
check:
boolean
entry/final
check
airborne
do/fly
permission-­‐from-­‐control-­‐tower
[check
-­‐=
OK ]
/
take-­‐off
^control-­‐tower.confirm-­‐takeoff(flightID)

18. UML notations 18
Actions and activities
■ Action: instantaneous, not interruptible
➤ on transition
➤ on state entry = action on all incoming transitions
➤ on state exit = action on all outgoing transitions
➤ on event
■ Activity: takes time, interruptible

19. UML notations 19
State diagram of
ticket machine
idle
inserting
money
timer
balance
insert(coin)/add
to
balance
processing
selection
do/compute
change
dispensing
change
do/dispense
change
dispensing
ticket
do/dispense
ticket
cancelling
do/return
balance
select(ticket)
cancel
button
pressed
time
out
[balance
<
ticket
price]
insert(coin)/new
balance
[balance
=
ticket
price]
[balance
>
ticket
price]

20. UML notations 20
State concurrency
entering
transaction
data
processing
take
out
cash
take
out
card
idle
cash
card
entered
cash
taken card
taken

21. UML notations 21
State generalization
■ If Object A is in super-state S, then the object us in precisely one
of the sub-states
■ Cf. concurrency: “and”-states
white
to
move
black
to
move
playing
chess

22. UML notations 22
State diagrams in
CommonKADS
■ Communication modeling (Ch. 8)
■ Asynchronous reasoning control
➤ real-time applications
■ Control specification for the business process
■ Overlap with activity diagrams
➤ state with no outgoing events = action state

23. UML notations 23
State diagram “Housing”
application
assessment
waiting
for
case
data
application
received/
order
assessment
data
needed/ask
data
received
/
reply
assessment
finished/
report
decision

24. UML notations 24
Class diagram
■ Captures static information structure
➤ In O-O: also functions
■ Generalization, inheritance & reuse are important
issues
■ Imported into CommonKADS domain- schema
notation
➤ no use made of operation box
■ Can also be used in Task Model to sketch task
information structure

25. UML notations 25
Objects and classes
Fokker
100
:airplane
airplane
#seats:
integer
Fokker
70
:airplane
#seats
=
80
:airplane

26. UML notations 26
Object class
■ Describes a group of objects with similar properties
➤ Abbreviation: "class"
■ Rationale for introducing classes:
➤ it provides a means for abstraction
■ Terminology: “object” is often used in an ambiguous
way, pointing to both objects (in the strict sense) and
object classes.

27. UML notations 27
Attributes
■ An attribute describes a value held by objects
belonging to the class.
■ Attribute specification consists of:
➤ Class it is defined on (student)
➤ Attribute name (name)
➤ Admissible values (string)
➤ Optional: default value

28. UML notations 28
Object and Value
■ Most O-O approaches distinguish between objects
and values.
■ Difference: a value does not have an identity
➤ it "lives” only in connection to a certain object.
■ RULE 1: an object is not allowed as a possible value
of an attribute!
■ RULE 2: attribute names need only to be unique
within a class.

29. UML notations 29
Values and Value Sets
■ Values are the primitive things with no internal
structure from the viewpoint of the application
■ Admissible values are defined through a value set
■ Typical predefined value-sets:
➤ string, number, integer, real, range, boolean, ….
■ User-defined:
➤ set or list of strings

30. UML notations 30
Object Identifiers
■ In O-O modeling you assume that every object has
an identity.
■ Consequence: introduce only attributes that act as
identifiers, iff the identifier is something that exists in
the real world.
■ Examples: student card number, social security
number.

31. UML notations 31
Operations
■ Definition:
➤ operation is "a function or a transformation that can be
applied to objects of a class".
■ Objects in a class share the same operations.
■ Method: implementation of an operation
■ = functional view

32. UML notations 32
Class notation
class
name
attribute-­‐1:
value-­‐set
attribute-­‐2:
value-­‐set
operation-­‐1(P ar1:T ype,
P ar2:T ype):
R eturnT ype
library
book
catalog#:
string
title:
string
author:
string
category:
C ategory
cover-­‐type:
{hard-­‐cover,
paperback}
available():
Boolean
library
book

33. UML notations 33
Associations
■ Associations are used to link objects to other objects
■ Majority of associations:
➤ binary (between two objects)
➤ directional (should be read in a particular direction
■ Ternary associations come up occasionally.
■ Associations between more than three objects are
rare.

34. UML notations 34
Association notation
man woman
0-­‐1 0-­‐1
w ife
husband
man woman
husband w ife
married-­‐to
General
notation
for
association
Notation
for
a
binary
association
married-­‐to 0-­‐10-­‐1

35. UML notations 35
Multiplicity examples
student course
person
major
address
<<
has
address
married-­‐to
major
subject
>>
enrolled
in
>>
0+
0-­‐1
1+

36. UML notations 36
Multiplicity
■ Also called: "cardinality".
■ Always connected to one of the classes involved.
■ Typical types of multiplicity:
➤ 0-1 Zero or one (optional).
➤ 1 Precisely one.
➤ 0+ Zero or more,
➤ 1+ One or more.

37. UML notations 37
Association class
■ Modeling an association as a class if the association
has an internal information structure
■ Advantage: associations become first-class objects.
■ Attributes and methods can be defined for the
association class.

38. UML notations 38
Notation association class
man woman
0-­‐1 0-­‐1
w ifehusband
marriage
date:
Date
city
registered
in
>>

39. UML notations 39
Use of an association class
company
name
person
name
social
security
#
address
salary
job
title
person
name
social
security
#
address
company
name
<<
works
for
employer employee
1+
1
employer employee
1+ 1+
works
for
salary:
job
title
if
you
want
to
model
that
a
person
can
work
for
more
than
one
company,
then
change
to

40. UML notations 40
Associations with specific
semantics
■ Associations provide a general, "neutral", way of
connecting object classes.
■ Semantics of the association are defined through
argument typing, multiplicity and (implicitly) the name
of the association.
■ Class diagrams provide specific types of
associations, with predefined semantics:
➤ generalization ("is a").
➤ aggregation ("part of").

41. UML notations 41
Generalization
■ Purpose: sharing similarities while preserving
differences
■ Is an association between a class that acts as super-
class and one or more classes called the sub-
classes.
■ Super-classes show the features that the sub-classes
have in common.
■ Each sub-class inherits the attributes and operations
defined on its super-class(es).

42. UML notations 42
Notation for generalization
agent
human
computer
program
man woman
task
executor-­‐of
>>
1+ 0+

43. UML notations 43
Aggregation
■ Aggregation denotes a binary association in which
one side is an "assembly" and the other side a "part".
■ "Assembly" and "part" act as predefined roles
involved in the aggregation association.
■ Cardinality of a part can be defined
➤ precisely one; optional (0-1); many, ...

44. UML notations 44
Notation for aggregation
audio
system
tape
deck
CD
player
tuner
amplifier
speakerhead
phones
record
player
0-­‐1
0-­‐1
0-­‐1
0-­‐1 0-­‐1 2,4

45. UML notations 45
Composition
■ Sub-type of aggregation
■ Existence of part depends on aggregate
document
name
type
open
print
paragraph
style
0+

46. UML notations 46
Aggregation and generalization
■ Similarities:
➤ Tree-like structure
➤ Transitive properties
■ Differences:
➤ AND-tree (aggregation) vs. OR-tree (generalization)
➤ instance tree (aggregation) vs. class tree (generalization)

47. UML notations 47
Combined aggregation and
generalization
audio
system
tape
deck
C D
player
tuner
amplifier
speakerhead
phones
record
player
0-­‐1 2,4
input
system
1+

48. UML notations 48
Use-case diagram
■ shows services that can be expected from a system
■ provides outsider view (customer)
■ terminology
use case service provided by system
actor agent using a system service
■ used in early phases of system analysis
■ use in CommonKADS: way to present possible
solutions to customer

49. UML notations 49
Use cases for a library
library
system
lend
book
make
book
reservation
search
library
catalog
add
book
to
catalog
remove
book
from
catalog
lender librarian

50. UML notations 50
A small case study
■ Course administration system (CAS)
■ Context: university department
■ Required services:
STUDENT: update personal data, inspect exam results, inspect
course info, enroll in course
TUTOR: inspect exam results, update course info, inspect
enrollments
ADMIN STAFF: enter exam results, inspect exam results,
update personal data students, inspect enrollments

51. UML notations 51
Use cases
student
tutor
update
student
data
inspect
course
info
update
course
info
enroll
in
course
enter
exam
results
browse
enrollments
browse
exam
results
browse
individual
results
browse
course
results
administrative
staff

52. UML notations 52
Class diagram
student
student-card#: string
name: string
address: string
date-of-birth: data
major: Major
.........
course
course-code: string
year: integer
trimester: 1-3
study-points: integer
learning-goals: string
description: text
literature: text
maximum-#students: integer
exam
date: date
result: [0..10]
enrollment
date: date
university
staff member
title: string
position: string
department: string
telephone: string
room: string
e-mail: string
0+ 0+
course-exam
1
0+
tutor
0+
1+
0+
requires

53. UML notations 53
Activity diagram for course
enrollment procedure
submit
enrollment
request
check
student
limit
check
preconditions
inform
about
prerequisites
inform
about
student
limit
register
enrollment
inform
about
enrollment
[preconditions
OK ]
[preconditions
not
OK ] [above
limit]
[limit
not
yet
reached]

54. UML notations 54
State diagram:
“update student data”
waiting
for
notification
timer
received(new
student
data)
^
send
message
to
central
university
database
local
processing
do/update
local
database
do/display
results
OK
message
received
from
central
database
[timer
=
time-­‐out
or
not
OK ]
/notify
failure