Tata AIG General Insurance Company - Insurer Innovation Award 2024
Â
UML notations used by CommonKADS
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
Â
Â
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
Â
Â