UML Notations in CommonKADS

Activity diagrams State diagrams Class diagrams

Use-case diagrams

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

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

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)

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

UML notations 6

Basic notation for activity diagram

data  entry

proces s ing generateoutput

UML notations 7

Decision

■  Sate transition is deterministic ■  If transition depends on outcome of the work, then

introduce a decision

data  entry

dump  in  was te  bas ket

furtherproces s ing

[data  correct]

[data  incorrect]

UML notations 8

Introducing concurrency

buy  foodand  drinks

cook  dinner open  winebottle

have  dinner

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)

UML notations 10

Notation for swim lanes

write  tender

get  cus tomerinformation

S ALE SDE P ARTME NT

calculatecos t

DE S IGNDE P ARTME NT

des ignelevator

   

UML notations 11

Object flow

s tandarddes ign

write  tender

get  cus tomerinformation

S ALE SDE P ARTME NT

dec ide    about  des ign  type

cus tomdes ign

cos tcalculation

elevatordesign

DE S IGNDE P ARTME NT

non-­‐s tandard s tandard

CUS TOME R

tender

customerinformation

   

UML notations 12

Signals

receivereques t

archive(reques t)

archive(reques t)

proces sreques t

archive

UML notations 13

Business process “Housing” primaryproces s

s econdaryproces s

data  entryof  applications

magaz ineproduction

applicationas s es sment

res idenceas s ignment

s tatis ticalanalys is

policyinformation

:residenceassignments

   

UML notations 14

Activity diagram of method control

cover

predic t

obtain compare

[no  more  s olutionsof  cover]

[new  s olutionof  cover]

[res ult  =  equal]

[res ult  =  not  equal]

s olution  found

no  s olution  found

s tartdiagnos isthrough

generate-­‐and-­‐tes t

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

UML notations 16

State

watching    footba ll  match

duration

entry/switch  on  TVdo/watchexit/turn  off  TV

state  name

state  variables

state  actions&  activities

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  fortake  off

check:  boolean

entry/final  check

a irborne

do/fly

permis s ion-­‐from-­‐control-­‐tower[check  -­‐=  OK ]  /  take-­‐off  control-­‐tower.confirm-­‐takeoff(flightID)

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

UML notations 19

State diagram of ticket machine

    idle     inserting  money

timerbalance

ins ert(coin)/add  to  balance

processing  se lec tion

do/compute  change

dispensingchange

do/dis pens e  change

dispensingticket

do/dis pens e  ticket

cance lling

do/return  balances elect(ticket)

cancel  buttonpres s ed

time  out[balance  <  ticket  price]

ins ert(coin)/new  balance

[balance  =  ticket  price]

[balance  >  ticket  price]

UML notations 20

State concurrency

enteringtrans action

dataproces s ing

take  outcas h

take  outcard

idle

cas h  cardentered

cas h  taken card  taken

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

whiteto  move

blackto  move

playing  chess

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

UML notations 23

State diagram “Housing”

applicationas s es sment

waiting  for  cas e  data

application  received/order  as s es sment

data  needed/as k

data  received  /  reply

as s es sment  finis hed/report  dec is ion

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

UML notations 25

Objects and classes

F okker  100:a irplane

a irplane

#s eats :   integer

F okker  70:a irplane

#s eats  =  80

:a irplane

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.

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

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.

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

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.

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

UML notations 32

Class notation

c las s  name

a ttribute-­‐1:  va lue-­‐s eta ttribute-­‐2:  va lue-­‐s et  

opera tion-­‐1(P a r1:T ype ,  P a r2:T ype):  R eturnT ype

library  book

ca ta log# :  s tringtitle :  s tringauthor:  s tringca tegory:  C a tegorycover-­‐type:  {ha rd-­‐cover,  paperback}

ava ilable ():  B oolean

librarybook

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.

UML notations 34

Association notation

man woman0-­‐1 0-­‐1

w ifehusband

man womanhusband w ife

ma rried-­‐to

General  notation  for  association

Notation  for  a  binary  association

married-­‐to 0-­‐10-­‐1

UML notations 35

Multiplicity examples

student course

person

major

address<<  has  addres s

married-­‐to

major  s ubject  >>

enrolled  in  >>

0+

0-­‐1

1+

   

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.

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.

UML notations 38

Notation association class

man woman0-­‐1 0-­‐1

w ifehus band

marriage

date:  Date

c ityregis tered  in  >>

   

UML notations 39

Use of an association class

company

name

person

namesoc ial  s ecurity  #addres ss alaryjob  title

person

namesoc ial  s ecurity  #addres s

company

name

<<  works  for  

employer employee

1+1

employer employee

1+ 1+

works  for

s alary:job  title

if  you  want  to  model  thata  pers on  can  work  for

 more  than  one  company,then  change  to

   

     

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").

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).

UML notations 42

Notation for generalization

agent

human computerprog ram

man woman

taskexecutor-­‐of  >>

1+ 0+

   

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, ...

UML notations 44

Notation for aggregation

audiosystem

tape  deck

CD  player

tuner

amplifier

speakerheadphones

recordplayer

0-­‐1

0-­‐1

0-­‐1

0-­‐1 0-­‐1 2,4

     

UML notations 45

Composition

■  Sub-type of aggregation ■  Existence of part depends on aggregate

document

nametype

openprint

parag raph

s tyle0+

     

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)

UML notations 47

Combined aggregation and generalization

audiosystem

tape  deck

CD  player

tuner

amplifier

speakerheadphones

recordplayer

0-­‐1 2,4inputsystem

1+

       

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

UML notations 49

Use cases for a library

libra ry  system

lend  book

make  bookres ervation

s earch  librarycatalog

add  bookto  catalog

remove  bookfrom  cataloglender librarian

   

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

UML notations 51

Use cases

s tudent

tutor

updates tudent  data

ins pectcours e  info

updatecours e  info

enrollin  cours e

enterexam  res ults

browseenrollments

browseexam  res ults

browseindividual  res ults

browsecours eres ults

adminis tratives taff

   

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

UML notations 53

Activity diagram for course enrollment procedure

s ubmitenrollmentreques t

checks tudent  limit

checkpreconditions

inform  aboutprerequis ites

inform  abouts tudent  limit

regis terenrollment

inform  aboutenrollment

[preconditionsOK ]

[preconditionsnot  OK ] [above  limit]

[limit  notyet  reached]

UML notations 54

State diagram: “update student data”

waiting  fornotifica tion

timer

received(new  s tudent  data)    s end  mes s age  to  

central  univers ity  databas e

loca lprocessing

do/update  local  databas edo/dis play  res ults

OK  mes s age  received  from  central    databas e

[timer  =  time-­‐out  or  not  OK ]/notify  failure