Transcript College 2

UML Notations in CommonKADS
Activity diagrams
State diagrams
Class diagrams
Use-case diagrams
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
UML notations
2
UML notations used

Class diagram


Activity diagram


combined function/control view
Use-case diagram


static information structure (“data”)
high level view of system services (functional)
State diagram

UML notations
highly interactive control
3
Activity diagram


Model control and information flow of a procedure or
process
Useful if control is mainly synchronous


Use in CommonKADS: modeling the organizational
process


otherwise: use state diagram
worksheet OM-2 of the organization model
Can also be used to model control flow within a task
method (knowledge model)
UML notations
4
Action state

State in which some work is being done


State terminates when the work is finished


difference with state diagrams
After termination the action state can lead to another
action state


activity, task
“state transition”
Special symbols for being and end of a procedure or
process
UML notations
5
Basic notation for activity
diagram
data entry
processing
UML notations
generate
output
6
Decision


Sate transition is deterministic
If transition depends on outcome of the work, then
introduce a decision
[data correct]
data entry
[data incorrect]
UML notations
further
processing
dump in
waste basket
7
Introducing concurrency
buy food
and drinks
cook dinner
open wine
bottle
have dinner
UML notations
8
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)
UML notations
9
Notation for swim lanes
SALES
DEPARTMENT
DESIGN
DEPARTMENT
get customer
information
design
elevator
calculate
cost
write
tender
UML notations
10
Object flow
CUSTOMER
SALES
DEPARTMENT
DESIGN
DEPARTMENT
customer
information
get customer
information
decide about
design type
non-standard
tender
write
tender
cost
calculation
UML notations
standard
standard
design
custom
design
elevator
design
11
Signals
receive
request
archive
(request)
archive
UML notations
archive
(request)
process
request
12
Business process “Housing”
primary
process
secondary
process
data entry
of applications
magazine
production
application
assessment
:residence
assignments
residence
assignment
UML notations
statistical
analysis
policy
information
13
Activity diagram of method
control
cover
[result = not equal]
start
diagnosis
through
generate-and-test
[no more solutions
of cover]
no solution found
[new solution
of cover]
[result = equal]
solution found
predict
obtain
UML notations
compare
14
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


UML notations
internal control
object flow
15
State
state name
state variables
state actions
& activities
UML notations
watching
football match
duration
entry/switch on TV
do/watch
exit/turn off TV
16
State transition
ready for
take off
check: boolean
permission-from-control-tower
[check -= OK]
/ take-off
^control-tower.confirm-takeoff(flightID)
airborne
do/fly
entry/final check



Event: comes from outside the object modeled
Message: generates event for another object
Guard: outcome of internal object computation
UML notations
17
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
UML notations
18
State diagram of
ticket machine
idle
insert(coin)/new balance
cancel button
pressed
inserting money
timer
balance
insert(coin)/add to balance
cancelling
[balance <
ticket price]
time out
select(ticket)
do/return balance
processing selection
[balance = ticket price]
dispensing
ticket
dispensing
change
do/dispense ticket
do/dispense change
UML notations
do/compute change
[balance > ticket price]
19
State concurrency
entering
transaction
data
cash card
entered
processing
take out
cash
cash taken
take out
card
card taken
idle
UML notations
20
State generalization
playing chess
white
to move
black
to move


If Object A is in super-state S, then the object us in precisely one
of the sub-states
Cf. concurrency: “and”-states
UML notations
21
State diagrams in
CommonKADS


Communication modeling (Ch. 8)
Asynchronous reasoning control



real-time applications
Control specification for the business process
Overlap with activity diagrams

UML notations
state with no outgoing events = action state
22
State diagram “Housing”
assessment finished/
report decision
application received/
order assessment
application
assessment
data needed/ask
data received / reply
UML notations
waiting for
case data
23
Class diagram

Captures static information structure



Generalization, inheritance & reuse are important
issues
Imported into CommonKADS domain- schema
notation


In O-O: also functions
no use made of operation box
Can also be used in Task Model to sketch task
information structure
UML notations
24
Objects and classes
airplane
#seats: integer
Fokker 70
:airplane
Fokker 100
:airplane
:airplane
#seats = 80
UML notations
25
Object class

Describes a group of objects with similar properties


Rationale for introducing classes:


Abbreviation: "class"
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.
UML notations
26
Attributes


An attribute describes a value held by objects
belonging to the class.
Attribute specification consists of:




UML notations
Class it is defined on (student)
Attribute name (name)
Admissible values (string)
Optional: default value
27
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.
UML notations
28
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:

UML notations
set or list of strings
29
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.
UML notations
30
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
UML notations
31
Class notation
class name
attribute-1: value-set
attribute-2: value-set
operation-1(Par1:Type, Par2:Type): ReturnType
library book
library
book
catalog#: string
title: string
author: string
category: Category
cover-type: {hard-cover, paperback}
available(): Boolean
UML notations
32
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.
UML notations
33
Association notation
General notation for association
w ife
husband
man
woman
0-1
married-to
0-1
Notation for a binary association
husband
w ife
man
woman
0-1
0-1
married-to
UML notations
34
Multiplicity examples
person
0-1
married-to
0+
1+
student
address
<< has address
enrolled in >>
course
major subject
>>
major
UML notations
35
Multiplicity



Also called: "cardinality".
Always connected to one of the classes involved.
Typical types of multiplicity:




UML notations
0-1
1
0+
1+
Zero or one (optional).
Precisely one.
Zero or more,
One or more.
36
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.
UML notations
37
Notation association class
husband
w ife
woman
man
0-1
0-1
marriage
date: Date
city
registered in >>
UML notations
38
Use of an association class
person
company
name
employee
employer
1
<< works for
1+
name
social security #
address
salary
job title
if you want to model that
a person can work for
more than one company,
then change to
company
employee
employer
name
1+
1+
person
name
social security #
address
works for
salary:
job title
UML notations
39
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:


UML notations
generalization ("is a").
aggregation ("part of").
40
Generalization




Purpose: sharing similarities while preserving
differences
Is an association between a class that acts as superclass and one or more classes called the subclasses.
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).
UML notations
41
Notation for generalization
executor-of >>
agent
task
1+
computer
program
human
man
UML notations
0+
woman
42
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

UML notations
precisely one; optional (0-1); many, ...
43
Notation for aggregation
0-1
audio
system
CD player
record
player
0-1
0-1
tuner
0-1
tape deck
UML notations
0-1
head
phones
2,4
amplifier
speaker
44
Composition


Sub-type of aggregation
Existence of part depends on aggregate
document
paragraph
name
type
0+
style
open
print
UML notations
45
Aggregation and generalization

Similarities:



Tree-like structure
Transitive properties
Differences:


UML notations
AND-tree (aggregation) vs. OR-tree (generalization)
instance tree (aggregation) vs. class tree (generalization)
46
Combined aggregation and
generalization
audio
system
1+
0-1
input
system
UML notations
amplifier
speaker
record
player
CD player
tuner
head
phones
2,4
tape deck
47
Use-case diagram



shows services that can be expected from a system
provides outsider view (customer)
terminology
use case
actor


service provided by system
agent using a system service
used in early phases of system analysis
use in CommonKADS: way to present possible
solutions to customer
UML notations
48
Use cases for a library
library system
lend book
add book
to catalog
make book
reservation
lender
remove book
from catalog
librarian
search library
catalog
UML notations
49
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
UML notations
50
Use cases
browse
individual
results
browse
course
results
browse
exam results
enter
exam results
enroll
in course
browse
enrollments
inspect
course info
update
course info
tutor
student
update
student data
UML notations
administrative
staff
51
Class diagram
exam
date: date
result: [0..10]
requires
0+
course-exam
1
enrollment
student
0+
date: date
student-card#: string
name: string
0+
address: string
date-of-birth: data
major: Major
.........
course
0+
course-code: string
year: integer
trimester: 1-3
study-points: integer
learning-goals: string
description: text
literature: text
maximum-#students: integer
0+
university
staff member
title: string
position: string 1+
department: string
telephone: string
room: string
e-mail: string
UML notations
tutor
52
Activity diagram for course
enrollment procedure
submit
enrollment
request
check
preconditions
inform about
prerequisites
check
student limit
[preconditions
not OK]
[above limit]
[preconditions
OK]
[limit not
yet reached]
register
enrollment
UML notations
inform about
student limit
inform about
enrollment
53
State diagram:
“update student data”
received(new student data)
^ send message to
central university database
waiting for
notification
[timer = time-out or not OK]
/notify failure
timer
OK message received from central database
local
processing
do/update local database
do/display results
UML notations
54