Softw

areD

esign,M

odellin

ga

ndA

nalysis

inU

ML

Le

cture2

1:In

heritance

II

20

14-0

2-05

Prof.

Dr.

Andreas

Podelski,

Dr.

Bern

dW

estp

hal

Alb

ert-Ludw

igs-Universitat

Freib

urg,

Germ

any

– 21 – 2014-02-05 – main –

Co

ntents&

Go

als

Last

Lectu

re:

•B

ehavio

ural

Featu

res

•State

Mach

ines

Variatio

nPoin

ts

•In

heritan

cein

UM

L:co

ncrete

syntax

•Lisko

vSubstitu

tion

Prin

ciple

—desired

seman

tics

This

Lectu

re:

•Educatio

nalO

bje

ctiv

es:

Cap

abilities

forfollow

ing

tasks/question

s.

•W

hat’s

the

Lisko

vSubstitu

tion

Prin

ciple?

•W

hat

islate/

earlybin

din

g?

•W

hat

isth

esu

bset,

what

the

uplin

ksem

antics

ofin

heritan

ce?

•W

hat’s

the

effect

ofin

heritan

ceon

LSCs,

State

Mach

ines,

System

States?

•W

hat’s

the

idea

ofM

eta-Modellin

g?

•Conte

nt:

•T

wo

appro

aches

toobtain

desired

seman

tics

•T

he

UM

LM

etaM

odel

– 21 – 2014-02-05 – Sprelim –

2/74

“...sh

allbe

usable...”

forU

ML

– 21 – 2014-02-05 – main –

3/74

Easy:

StaticTypin

g

Giv

en:

C1

x:In

t

f(In

t):In

t

D1

C

itsC1

itsD

1

C2

x:In

t

f(In

t):In

t

D2

x:Bool

f(F

loat)

:In

t

〈〈signal〉〉

E

〈〈signal〉〉

F

Wante

d:

•x

>0

alsowell-ty

ped

forD

1

•assign

men

titsC

1:=

itsD1

bein

gwell-ty

ped

•itsC

1.x

=0,

itsC1.f

(0),itsC

1!F

bein

gwell-typ

ed(an

ddoin

gth

erigh

tth

ing).

Appro

ach:

•Sim

ply

defi

ne

itas

bein

gwell-typ

ed,

adju

stsystem

statedefi

nition

todo

the

right

thin

g.

– 21 – 2014-02-05 – Sstatic –

4/74

StaticTypin

gC

ont’d

C1

x:In

t

f(In

t):In

t

D1

C2

x:In

t

f(In

t):In

t

D2

x:Bool

f(F

loat)

:In

t

〈〈signal〉〉

E

〈〈signal〉〉

F

Notio

ns

(fromcategory

theory):

•in

varia

nce,

•covaria

nce,

•contra

varia

nce.

We

could

call,e.g.

am

ethod,su

b-ty

pe

pre

serv

ing,if

and

only

ifit

•accep

tsm

ore

genera

ltyp

esas

input

(contra

varia

nt),

•provid

esa

more

specia

lised

type

asou

tput

(covaria

nt).

This

isa

notio

nused

by

man

ypro

gram

min

glan

guag

es—

and

easilytyp

e-checked

.

– 21 – 2014-02-05 – Sstatic –

5/74

Excursus:

Late

Bin

ding

ofBeh

aviouralFeatures

– 21 – 2014-02-05 – main –

6/74

Late

Bin

ding

What

transform

erap

plies

inw

hat

situation

?(E

arly(co

mpile

time)

bin

din

g.)

fnot

overridden

inD

C

f()

:In

t

D

C0

someC

someD

foverrid

den

inD

C

f()

:In

t

D

f()

:In

t

value

ofsomeC

/som

eD

someC->f()

C::f

()C

::f()

u1

someD->f()

C::f

()D

::f()

u2

someC->f()

C::f

()D

::f()

u2

What

one

could

wan

tis

someth

ing

diff

erent:

(Late

bin

din

g.)

someC->f()

C::f

()C

::f()

u1

someD->f()

D::f

()D

::f()

u2

someC->f()

C::f

()C

::f()

u2

– 21 – 2014-02-05 – Slatebind –

7/74

Late

Bin

ding

inthe

Stan

dard

an

dP

rogramm

ing

La

ng.

•In

the

standard

,Section

11.3.10,“C

allOperation

Action

”:

“Sem

antic

Varia

tion

Poin

ts

The

mech

anism

fordeterm

inin

gth

em

ethod

tobe

invoked

asa

result

ofa

callop

erationis

unsp

ecified

.”[O

MG

,2007b

,247]

•In

C+

+,

•m

ethods

areby

defau

lt“(early)

com

pile

time

bin

din

g”,

•can

be

declared

tobe

“late

bin

din

g”

by

keyword

“virtual”,

•th

edeclaratio

nap

plies

toall

inheritin

gclasses.

•In

Java,

•m

ethods

are“late

bin

din

g”;

•th

ereare

pattern

sto

imitate

the

effect

of“early

bin

din

g”

Exerc

ise:

What

could

have

driven

the

design

ersof

C+

+to

taketh

atap

proach?

Note

:late

bin

din

gtyp

icallyap

plies

only

tom

eth

ods,

not

toattrib

ute

s.(B

ut:

getter/

setterm

ethods

have

been

inven

tedrecen

tly.)

– 21 – 2014-02-05 – Slatebind –

8/74

Back

tothe

Main

Track:“

...tellthedifference...”

forU

ML

– 21 – 2014-02-05 – main –

9/74

With

Only

Early

Bin

ding...

•...w

e’redone

(ifwe

realiseit

correctlyin

the

framew

ork).

•T

hen

•if

we’re

calling

meth

od

fofan

object

u,

•w

hich

isan

instan

ceofD

with

C�

D

•via

aC

-link,

•th

enwe

(by

defi

nitio

n)

only

seean

dch

ange

the

C-p

art.

•W

ecan

not

tellw

heth

eru

isa

Cor

anD

instan

ce.

So

we

imm

ediately

alsohave

beh

avioural/d

ynam

icsu

btyp

ing.

– 21 – 2014-02-05 – Ssubtyping –

10

/74

Difficult:

Dyn

amic

Su

btyping

C

f(In

t):In

t

D

f(In

t):In

t

•C

::fan

dD

::fare

type

com

patib

le,

but

Dis

not

necessa

rilya

sub-ty

pe

ofC

.

•Exam

ple

s:(C

++

)

int

C::f(int)

{return

0;

};

vs.int

D::f(int)

{return

1;

};

int

C::f(int)

{return

(rand()

%2);

};

vs.int

D::f(int

x)

{return

(x

%2);

};

– 21 – 2014-02-05 – Ssubtyping –

11

/74

Su

b-Typing

Principles

Co

nt’d

•In

the

standard

,Section

7.3.36,“O

pera

tion”:

“Sem

antic

Varia

tion

Poin

ts

[...]W

hen

operatio

ns

arered

efined

ina

specializatio

n,ru

lesreg

ardin

gin

varia

nce,covaria

nce,or

contra

varia

nce

oftyp

esan

dpreco

nditio

ns

determ

ine

wheth

erth

esp

ecializedclassifi

eris

substitu

table

forits

more

gen

eralparen

t.Such

rules

constitu

tesem

antic

variation

poin

tsw

ithresp

ectto

redefi

nitio

nofoperatio

ns.”

[OM

G,2007a,

106]

•So,

better:

calla

meth

od

sub-ty

pe

pre

serv

ing,if

and

only

ifit

(i)accep

tsm

ore

input

valu

es

(contra

varia

nt),

(ii)on

the

old

valu

es,

has

fewer

behavio

ur

(covaria

nt).

Note

:T

his

(ii)is

no

longer

am

atterof

simple

type-ch

ecking!

•A

nd

not

necessarily

the

end

ofth

estory:

•O

ne

could

,e.g.

wan

tto

consid

erexecu

tiontim

e.

•O

r,like

[Fisch

eran

dW

ehrh

eim,2000

],relax

to“few

erob

servable

beh

aviour”,

thus

adm

itting

the

sub-typ

eto

do

more

work

onin

puts.

Note

:“testin

g”diff

erences

dep

ends

onth

egra

nula

rityof

the

seman

tics.

•Rela

ted:

“has

aweaker

pre-condition

,”(c

ontra

varia

nt),

“has

astron

gerpost-con

dition

.”(c

ovaria

nt).

– 21 – 2014-02-05 – Ssubtyping –

12

/74

Ensurin

gS

ub-Typin

gfor

StateM

achinesCD

•In

the

CA

SE

tool

we

consid

er,m

ultip

leclasses

inan

inheritan

cehierarch

ycan

have

statem

achin

es.

•B

ut

the

statem

achin

eof

asu

b-class

cannot

be

draw

nfrom

scratch.

•In

stead,th

estate

mach

ine

ofa

sub-class

canon

lybe

obtain

edby

applyin

gaction

sfrom

are

stricte

dset

toa

copyof

the

original

one.

Rou

ghly

(cf.U

serG

uid

e,p.760,

fordetails),

•ad

dth

ings

into

(hierarch

ical)states,

•ad

dm

orestates,

•attach

atran

sition

toa

diff

erent

target

(limited

).

•T

hey

ensu

re,th

atth

esu

b-class

isa

behavio

ura

lsu

b-ty

pe

ofth

esu

per

class.(B

ut

meth

od

implem

entation

scan

stilldestroy

that

property.)

•Tech

nica

lly,th

eid

eais

that

(by

late

bin

din

g)

only

the

state

mach

ine

ofth

em

ost

specia

lisedcla

ssesare

runnin

g.

By

know

ledge

of

the

fram

ework

,th

e(co

de

for)

state

mach

ines

of

super-cla

ssesis

still

accessib

le—

but

usin

git

ishard

lya

good

idea

...

– 21 – 2014-02-05 – Ssubtyping –

13

/74

Towards

SystemStates

Wante

d:

aform

alrepresen

tationof

“ifC

�D

then

D‘is

a’C

”,th

atis,

(i)D

has

the

same

attributes

and

beh

avioural

features

asC

,an

d

(ii)D

objects

(iden

tities)can

replace

Cobjects.

We’ll

discu

sstw

oappro

aches

tosem

antics:

•D

om

ain

-inclu

sion

Sem

antics

(more

theore

tical)

•U

plin

kSem

antics

(more

technic

al)

– 21 – 2014-02-05 – Ssubtyping –

14

/74

Dom

ainInclusio

nSem

antics

– 21 – 2014-02-05 – main –

15

/74

Dom

ainInclusio

nStructure

LetS

=(T

,C

,V,a

tr,E

,F,m

th,⊳

)be

asign

ature.

Now

astru

ctu

reD

•[a

sbefo

re]m

aps

types,

classes,asso

ciations

todom

ains,

•[fo

rcom

ple

teness]

meth

ods

totran

sformers,

•[a

sbefo

re]in

den

titiesof

instan

cesof

classesnot

(transitively)

relatedby

generalisation

aredisjoin

t,

•[c

hanged]th

ein

den

titiesof

asu

per-class

comprise

allid

entities

ofsu

b-classes,

i.e.

∀C

∈C

:D

(C)

)⋃

C⊳

D D

(D).

Note

:th

eold

setting

coincid

esw

ithth

esp

ecialcase

⊳=

∅.

– 21 – 2014-02-05 – Sdomincl –

16

/74

Dom

ainInclusio

nSystem

States

Now

:a

syste

msta

teofS

wrt.D

isa

type-c

onsiste

nt

map

pin

g

σ:D

(C

)7→

(V7→

(D(T

)∪D

(C0,1 )

∪D(C

∗ )))

that

is,for

allu∈

dom

(σ)∩ D

(C),

•[a

sbefo

re]σ(u

)(v)∈D

(τ)

ifv

:τ,τ∈T

orτ∈{C

∗ ,C0,1 }.

•[c

hanged]dom

(σ(u

))=

⋃

C0�

Catr

(C0 ),

Exam

ple

:C

x:In

t

D

x:In

t

y:In

t

n 0,1

Note

:th

eold

setting

stillcoin

cides

with

the

special

case⊳

=∅.

– 21 – 2014-02-05 – Sdomincl –

17

/74

Prelim

inaries:

Expressio

nN

ormalisatio

n

Recall:

A

v:In

t

C

v:In

t

D

n 0,1

•we

wan

tto

allow,e.g.,

“context

Din

v:v

<0”.

•we

assum

efu

llyqualifi

ed

nam

es,

e.g.C

::v.

Intu

itively,v

shall

den

oteth

e“m

ost

specia

lm

ore

genera

l”C

::vaccord

ing

to⊳

.

To

keepth

isou

tof

typin

gru

les,we

assum

eth

atth

efollow

ing

norm

alisa

tion

has

been

applied

toall

OCL

expressions

and

allaction

s.

•G

ivenexpression

v(or

f)

inconte

xt

ofclass

D,as

determ

ined

by,e.g.

•by

the

(type

ofth

e)navig

ation

expressio

nprefi

x,or

•by

the

class,th

estate-m

achin

ew

here

the

action

occcu

rsbelo

ngs

to,

•sim

ilarfor

meth

od

bodies,

•norm

alise

vto

(=rep

laceby)

C::v

,

•w

here

Cis

the

gre

ate

stclass

wrt.

“�”

such

that

•C

�D

and

C::v

∈atr

(C).

Ifno

(uniq

ue)

such

classexists,

the

model

iscon

sidered

not

well-fo

rmed;th

eexpression

isam

bigu

ous.

Then

:exp

licitlyprovid

eth

equalifi

ed

nam

e.

– 21 – 2014-02-05 – Sdomincl –

18

/74

OC

LSyntax

an

dTypin

g

•Recall

(part

ofth

e)O

CL

syntax

and

typin

g:v,r

∈V

;C

,D∈C

expr

::=v(e

xpr1 )

:τC→

τ(v

),if

v:τ∈T

|r(e

xpr1 )

:τC→

τD

,if

r:D

0,1

|r(e

xpr1 )

:τC→

Set(τ

D),

ifr

:D

∗

The

defi

nition

ofth

esem

antics

remain

s(textu

ally)th

esa

me.

– 21 – 2014-02-05 – Sdomincl –

19

/74

More

Interesting:

Well-Typed-ness

C

v:In

t

D

•W

ewan

t

context

Din

v:v

<0

tobe

well-typ

ed.

Curren

tlyit

isn’t

becau

se

v(e

xpr1 )

:τC→

τ(v

)

but

A⊢

self

:τD

.

(Becau

seτD

and

τC

arestill

diff

ere

nt

types,

althou

ghdom

(τD

)⊂

dom

(τC

).)

•So,

add

a(fi

rst)new

typin

gru

le

A⊢

expr

:τD

A⊢

expr

:τC

,if

C�

D.

(Inh)

Which

iscorrect

inth

esen

seth

at,if

‘expr’is

oftyp

eτD

,th

enwe

canuse

iteveryw

here,

where

aτC

isallow

ed.

The

systemstate

isprep

aredfor

that.

– 21 – 2014-02-05 – Sdomincl –

20

/74

Well-Typed-nessw

ithVisibility

Co

nt’d

A,D

⊢expr

:τC

A,D

⊢C

::v(e

xpr):τ

,ξ

=+

(Pub)

A,D

⊢expr

:τC

A,D

⊢C

::v(e

xpr)

:τ

,ξ

=#

,C

�D

(Prot)

A,D

⊢expr

:τC

A,D

⊢C

::v(e

xpr):τ

,ξ

=−

,C

=D

(Priv)

〈C::v

:τ,ξ,v

0 ,P〉∈

atr

(C).

Exam

ple

:

context/in

v(n

.)v1

<0

(n.)v

2<

0(n

.)v3

<0

CDB

C

−v1

:In

t

#v2

:In

t

+v3

:In

t

DB

0,1

n

– 21 – 2014-02-05 – Sdomincl –

21

/74

Satisfyin

gO

CL

Co

nstraints(D

omain

Inclusion)

•Let

M=

(CD

,OD

,SM

,I

)be

aU

ML

model,

andD

astru

cture.

•W

e(c

ontin

ue

to)

sayM

|=expr

forcon

textC

inv

:expr0

︸︷︷

︸

=expr

∈In

v(M)

iff

∀π

=(σ

i ,εi )

i∈N∈JMK

∀i∈N

∀u∈

dom

(σi )∩D

(C)

:

IJexpr0 K(σ

i ,{se

lf7→

u})

=1.

•M

is(still)

consisten

tif

and

only

ifit

satisfies

allcon

straints

inIn

v(M).

•Exam

ple

:C

x:In

t

D

n 0,1

– 21 – 2014-02-05 – Sdomincl –

22

/74

Transform

ers(D

omain

Inclusion)

•Tran

sformers

alsorem

ainth

esa

me,e.g.

[VL

12,p.18]

update

(expr1 ,v

,expr2 )

:(σ

,ε)7→

(σ′,ε)

with

σ′=

σ[u

7→σ(u

)[v7→

IJexpr2 K(σ

)]]

where

u=

IJexpr1 K(σ

).

– 21 – 2014-02-05 – Sdomincl –

23

/74

Sema

nticsofM

etho

dC

alls

•N

on

late

-bin

din

g:

clear,by

norm

alisation.

•Late

-bin

din

g:

Con

struct

am

eth

od

call

transform

er,w

hich

isap

plied

toall

meth

od

calls.

– 21 – 2014-02-05 – Sdomincl –

24

/74

Inherita

ncea

nd

StateM

achines:Triggers

•W

ante

d:

triggerssh

allalso

be

sensitive

forin

herited

events,

sub-class

shall

execute

super-class’

state-mach

ine

(unless

overridden

).

(σ,ε)

(cons,S

nd)

−−−−−−−→

u(σ

′,ε′)

if

•∃

u∈

dom

(σ)∩D

(C)∃

uE∈D

(E)

:u

E∈

ready(ε

,u)

•u

isstab

lean

din

statem

achin

estate

s,i.e.

σ(u

)(stable

)=

1an

dσ(u

)(st)=

s,

•a

transitio

nis

enab

led,i.e.

∃(s

,F

,expr,act,s

′)∈→

(SM

C)

:F

=E

∧I Je

xprK(σ

)=

1

where

σ=

σ[u

.para

ms

E7→

ue ].

and•

(σ′,ε

′)resu

ltsfro

map

plyin

gtact

to(σ

,ε)an

drem

ovin

gu

Efro

mth

eeth

er,i.e.

(σ′′,

ε′)

=tact (σ

,ε⊖

uE),

σ′=

(σ′′[u

.st7→

s′,

u.sta

ble

7→b,

u.p

ara

ms

E7→

∅])|D

(C)\

{u

E}

where

bdepends:

•If

ubeco

mes

stable

ins′,

then

b=

1.

Itdoes

beco

me

stable

ifan

donly

ifth

ereis

no

transitio

nw

ithout

trigger

enab

ledfor

uin

(σ′,

ε′).

•O

therw

iseb

=0.

•Consu

mptio

nofu

Ean

dth

esid

eeff

ectsofth

eactio

nare

observed

,i.e.

cons

={(u

,(E,σ(u

E)))}

,Snd

=O

bs

tact (σ

,ε⊖

uE

).

– 21 – 2014-02-05 – Sdomincl –

25

/74

Dom

ainInclusio

na

ndInteractio

ns

CD

EF

CC’

EF

•Sim

ilarto

satisfactionof

OCL

expressions

above:

•A

nin

stance

line

stands

forall

instan

cesof

C(exact

orin

heritin

g).

•Satisfaction

ofeven

tob

servationhas

totake

inheritan

cein

toaccou

nt,

too,

sowe

have

tofix,

e.g.

σ,co

ns,S

nd|=

βE

!x,y

ifan

don

lyif

β(x

)sen

ds

anF

-event

toβy

where

E�

F.

•N

ote

:C

-instan

celin

ealso

bin

ds

toC

′-objects.

– 21 – 2014-02-05 – Sdomincl –

26

/74

Uplink

Sema

ntics

– 21 – 2014-02-05 – main –

27

/74

Uplink

Sema

ntics

•Id

ea:

•Con

tinue

with

the

existing

defi

nition

ofstru

ctu

re,i.e.

disjoin

tdom

ains

forid

entities.

•H

avean

implic

itasso

cia

tion

fromth

ech

ildto

eachparen

tpart

(similar

toth

eim

plicit

attribute

forstab

ility).

C

x:In

t

D

•A

pply

(adiff

erent)

pre-processin

gto

make

appropriate

use

ofth

atasso

ciation,e.g.

rewrite

(C+

+)

x=

0;

inD

to

uplink

C->x

=0;

– 21 – 2014-02-05 – Suplink –

28

/74

Pre-P

rocessing

forthe

Uplink

Sema

ntics

•For

eachpair

C⊳

D,exten

dD

bya

(fresh)

association

uplin

kC

:C

with

µ=

[1,1],ξ

=+

(Exerc

ise:

public

necessary?)

•G

ivenexpression

v(or

f)

inth

econte

xt

ofclass

D,

•let

Cbe

the

smalle

stclass

wrt.

“�”

such

that

•C

�D

,an

d•

C::v

∈atr

(D)

•th

enth

ereexists

(bydefi

nition

)C⊳

C1⊳

...⊳

Cn⊳

D,

•norm

alise

vto

(=rep

laceby)

uplin

kC

n->···

->

uplin

kC

1 .C::v

•A

gain:

ifno

(uniq

ue)

smallest

classexists,

the

model

iscon

sidered

not

well-fo

rmed;th

eexpression

isam

bigu

ous.

– 21 – 2014-02-05 – Suplink –

29

/74

Uplink

Structure,SystemState,Typin

g

•D

efinition

ofstru

cture

remain

sunchanged.

•D

efinition

ofsystem

staterem

ainsunchanged.

•Typ

ing

and

transform

ersrem

ainunchanged

—th

eprepro

cessing

has

put

everythin

gin

shap

e.

– 21 – 2014-02-05 – Suplink –

30

/74

Satisfyin

gO

CL

Co

nstraints(U

plink)

•Let

M=

(CD,OD

,SM,I

)be

aU

ML

model,

andD

astru

cture.

•W

e(c

ontin

ue

to)

say

M|=

expr

for

context

Cin

v:expr0

︸︷︷

︸

=expr

∈In

v(M)

ifan

don

lyif

∀π

=(σ

i )i∈

N∈JMK

∀i∈N

∀u∈

dom

(σi )∩D

(C)

:

I Jexpr0 K(σ

i ,{se

lf7→

u})

=1.

•M

is(still)

consisten

tif

and

only

ifit

satisfies

allcon

straints

inIn

v(M).

– 21 – 2014-02-05 – Suplink –

31

/74

Transform

ers(U

plink)

•W

hat

has

tochange

isth

ecre

ate

transform

er:

crea

te(C

,expr,v

)

•A

ssum

e,C

’sin

heritan

cerelation

sare

asfollow

s.

C1,1⊳

...⊳

C1,n

1⊳

C,

...

Cm

,1⊳

...⊳

Cm

,nm⊳

C.

•T

hen

,we

have

to

•create

one

freshob

jectfor

eachpart,

e.g.

u1,1 ,...,u

1,n

1 ,...,um

,1 ,...,um

,nm

,

•set

up

the

uplin

ksrecu

rsively,e.g.

σ(u

1,2 )(u

plin

kC

1,1 )

=u

1,1 .

•A

nd,if

we

had

constru

ctors,be

carefulw

ithth

eirord

er.

– 21 – 2014-02-05 – Suplink –

32

/74

Late

Bin

ding

(Uplink)

•Em

ploy

someth

ing

similar

toth

e“mostspec”

trick(in

am

inute!).

But

the

result

istyp

icallyfar

fromcon

cise.

(Related

toO

CL’sisKindOf()

function

,an

dRT

TIin

C+

+.)

– 21 – 2014-02-05 – Suplink –

33

/74

Dom

ainInclusio

nvs.U

plinkSem

antics

– 21 – 2014-02-05 – main –

34

/74

Cast-Tra

nsformers

•Cc;

•Dd;

•Id

entity

upcast

(C+

+):

•C∗cp

=&d;

//assig

naddress

of‘d

’to

poin

ter‘cp

’

•Id

entity

dow

ncast

(C+

+):

•D∗dp

=(D∗)c

p;

//assig

naddress

of‘d

’to

poin

ter‘d

p’

•Valu

eupcast

(C+

+):

•∗c

=∗d;

//co

py

attrib

ute

valu

esof‘d

’in

to‘c’,

or,

//m

ore

precise,

the

valu

esofth

eC

-part

of‘d

’

– 21 – 2014-02-05 – Sdiff –

35

/74

Casts

inD

omain

Inclusion

an

dUplink

Sema

ntics

Dom

ain

Inclu

sion

Uplin

k

C∗cp

=&d;

easy:

imm

ediately

com

patib

le(in

underlyin

gsystem

state)be-

cause

&d

yields

anid

entity

from

D

(D)⊂D

(C).

easy:

By

pre-p

rocessin

g,

C∗cp

=d.uplink

C;

D∗dp

=(D∗)cp;

easy:

the

value

ofcp

isinD

(D)∩

D

(C)

becau

seth

epoin

ted-to

ob-

jectis

aD

.

Oth

erwise,

errorco

nditio

n.

diffi

cult:

we

need

the

iden

tityofth

eD

whose

C-slice

isde-

noted

by

cp.

(See

next

slide.)

c=

d;

bit

diffi

cult:

set(for

allC

�D

)(C

)(·,

·):τ

D×

Σ→

Σ|a

tr(C

)

(u,σ)7→

σ(u

)|atr

(C

)

Note:

σ′

=σ[u

C7→

σ(u

D)]

isnot

type-co

mpatib

le!

easy:

By

pre-p

rocessin

g,

c=

∗(d

.uplink

C);

– 21 – 2014-02-05 – Sdiff –

36

/74

IdentityD

owncastw

ithU

plinkSem

antics

•Recall

(C+

+):

Dd;

C∗cp

=&d;

D∗dp

=(D∗)c

p;

•Pro

ble

m:

we

need

the

iden

tityof

the

Dw

hose

C-slice

isden

otedby

cp.

•O

ne

technic

also

lutio

n:

•Give

up

disjo

intn

essofdom

ains

forone

additio

nalty

pe

com

prisin

gall

iden

tities,i.e.

have

all∈T

,D(all)

=⋃

C∈ C D

(C)

•In

each�

-min

imalcla

sshave

associatio

ns

“mostspec”

poin

ting

tom

ost

specia

lised

slices,plu

sin

formatio

nofw

hich

type

that

sliceis.

•T

hen

dow

ncast

mean

s,dep

endin

gon

themostspec

type

(only

finitely

man

ypossib

ilities),goin

gdow

nand

then

up

asnecessary,

e.g.

switch(mostspectype){

case

C:

dp

=cp->mostspec->uplink

Dn->

...->uplink

D1->uplink

D;

...}

– 21 – 2014-02-05 – Sdiff –

37

/74

Dom

ainInclusio

nvs.U

plinkSem

antics:

Differences

•N

ote

:T

he

uplin

ksem

antics

views

inheritan

ceas

anab

breviation:

•W

eonly

need

toto

uch

transform

ers(create)

—an

dif

we

had

constru

ctors,we

did

n’t

evenneed

edth

at(w

eco

uld

enco

de

the

recursive

constru

ction

ofth

eupper

slicesby

atran

sformatio

nofth

eexistin

gco

nstru

ctors.)

•So:

•In

heritan

cedoesn

’tadd

expressivepow

er.

•A

nd

italso

doesn

’tim

pro

ve

concisen

essso

odra

matic

ally.

As

long

aswe’re

“early

bin

din

g”,

that

is...

– 21 – 2014-02-05 – Sdiff –

38

/74

Dom

ainInclusio

nvs.U

plinkSem

antics:

Motives

•Exerc

ise:

What’s

the

poin

tof

•havin

gth

ete

dio

us

adju

stmen

tsof

the

theory

ifit

canbe

approach

edte

chnic

ally?

•havin

gth

ete

dio

us

technical

pre

-pro

cessin

g

ifit

canbe

approach

edcle

anly

inth

eth

eory?

– 21 – 2014-02-05 – Sdiff –

39

/74

Meta-M

odellin

g:Idea

an

dE

xample

– 21 – 2014-02-05 – main –

40

/74

Meta-M

odellin

g:W

hya

nd

Wh

at

•M

eta

-Modellin

gis

one

major

prerequisite

forunderstan

din

g

•th

estan

dard

docu

men

ts[O

MG

,2007a,

OM

G,2007b

],an

d

•th

eM

DA

ideas

ofth

eO

MG

.

•T

he

idea

issim

ple

:

•if

am

odellin

gla

nguage

isab

out

modellin

gth

ings,

•an

dif

UM

Lm

odels

arean

dcom

priseth

ings,

•th

enw

hy

not

modelth

osein

am

odellin

glan

guage?

•In

other

word

s:

Why

not

have

am

odel

MU

such

that

•th

eset

oflegal

instan

cesof

MU

is•th

eset

ofwell-form

ed(!)

UM

Lm

odels.

– 21 – 2014-02-05 – Smm –

41

/74

Meta-M

odellin

g:E

xample

•For

example,

let’scon

sider

aclass.

•A

cla

sshas

(ona

superfi

ciallevel)

•a

nam

e,

•an

ynum

ber

ofattrib

ute

s,

•an

ynum

ber

ofbehavio

ura

lfe

atu

res.

Each

ofth

elatter

two

has

•a

nam

ean

d

•a

visib

ility.

Beh

avioural

features

inad

dition

have

•a

boolean

attribute

isQuery,

•an

ynum

ber

ofparam

eters,

•a

return

type.

•Can

we

model

this

(inU

ML,for

astart)?

– 21 – 2014-02-05 – Smm –

42

/74

UM

LM

eta-Mo

del:E

xtract

Com

men

tElem

ent

Nam

edElem

ent

nam

e

visibility

Typ

eTyp

edElem

ent

Red

efElem

ent

Featu

reN

amesp

ace

Classifi

erStru

ctFeatu

reB

ehavF

eature

Class

Prop

erty

Operation

Param

eter

�

∗red

efdElem

∗

type

0..1

��0..1

∗

�0..1

∗

type

– 21 – 2014-02-05 – Sumlmm –

43

/74

Classes

[OM

G,2

007b,3

2]

Fig

ure 7.12 - C

lasses diag

ram o

f the K

ernel packag

e

�

StructuralF

eature

Property

isDerived : Boolean

isReadO

nly : BooleanisD

erivedUnion : Boolean

/default : Stringaggregation : AggregationKind/IsC

omposite : Boolean

Classifier

Relationship

Classifier

Association

isDerived : B

oolean

Type

<<

enumeration>

>A

ggregationKind

nonesharedcom

posite

ValueS

pecification

{redefines general}+

/superClass

+subsettedP

roperty

{subsets classifier,subsets nam

espace,subsets featuringC

lassifier}+

class

+ow

nedAttribute

Class

{subsets attribute,subsets ownedM

ember,

ordered}

{subsets redefinedElement}

+ redefinedProperty

+/opposite

0..1

0..1

Classifier

Operation

{subsets namespace,

subsets redefinitionContext}

+class

{subsets ownedM

ember, ordered}

+nestedClassifier

0..1*

{subsets redefinitionContext,

subsets namespace,

subsets featuringClassifier}

+class

{subsets feature, subsetsow

nedMem

ber, ordered}+ow

nedOperation

0..1*

0..1*

******

{subsets mem

ber, ordered}+m

emberE

nd+association

2..*0..1

{subsets mem

berEnd,

subsets feature, subsetsow

nedMem

ber, ordered}+ow

nedEnd

{subsets association,subsets nam

espace,subsets featuringC

lassifier}+ow

ningAssociation

0..1*{subsets ow

ner}+navigableO

wnedE

nd

*0..1

{subsets owner}

+owningP

roperty(subsets ow

nedElem

ent}+defaultValue

0..10..1

{readOnly, odered}+/endType *

1..*

– 21 – 2014-02-05 – Sumlmm –

44

/74

Operatio

ns[O

MG

,2007b,3

1]

Fig

ure 7.11 - O

peratio

ns d

iagram

of th

e Kern

el package

– 21 – 2014-02-05 – Sumlmm –

45

/74

Operatio

ns[O

MG

,2007b,3

0]

Fig

ure 7.10 - F

eatures d

iagram

of th

e Kern

el package

– 21 – 2014-02-05 – Sumlmm –

46

/74

Classifiers

[OM

G,2

007b,2

9]

Fig

ure 7.9 - C

lassifiers diag

ram o

f the K

ernel packag

e

– 21 – 2014-02-05 – Sumlmm –

47

/74

Nam

espaces

[OM

G,2

007b,2

6]

Fig

ure 7.4 - N

amespaces d

iagram

of th

e Kern

el package

PackageableE

lement

visibility : VisibilityK

ind

Nam

espace

{readOnly, subsets m

ember}

+im

portedMem

ber*

Elem

ent

Nam

edElem

ent

Nam

e : String

visibility : VisibilityK

ind [0..1][0..1][0..1]

/qualifiedNam

e : String

<<

enumeration>

>V

isibilityKind

publicprivateprotectedpackage

Nam

edElem

ent

DirectedR

elationship

Elem

entImport

visibility : VisibilityK

indalias : S

tring [0..1]

Package

PackageIm

port

DirectedR

elationship

PackageableE

lement

visibility : VisibilityK

ind

{readOnly, union,

subsets owner}

+/nam

espace

*

{readOnly, union}

+/m

ember

+/ow

nedMem

ber

{readOnly, union, subsets

mem

ber, subsets ownedE

lement }

0..1

**

{subsets source, subsets owner}

+ im

portingNam

espace{subsets target}

+ im

portedElem

ent*

11

1+

elementIm

port

{subsetsow

nedElem

ent}

{subsets source,subsets ow

ner}+

importingN

amespace

{subsets target}+

importedP

ackage

+packageIm

port{subsets ow

nedElem

ent} *

*1

1

– 21 – 2014-02-05 – Sumlmm –

48

/74

Ro

otDiagram

[OM

G,2

007b,2

5]

Fig

ure 7.3 - R

oo

t diag

ram o

f the K

ernel packag

e

– 21 – 2014-02-05 – Sumlmm –

49

/74

Interesting:

De

claration/D

efinition

[OM

G,2

007b,4

24]

Fig

ure 13.6 - C

om

mo

n B

ehavio

r

– 21 – 2014-02-05 – Sumlmm –

50

/74

UM

LA

rchitecture

[OM

G,2

003,8]

•M

eta-modellin

ghas

already

been

used

forU

ML

1.x.

•For

UM

L2.0

,th

ereq

uest

forpro

posals

(RFP)

askedfor

asep

aration

ofco

ncern

s:

Infra

structu

rean

dSuperstru

ctu

re.

•O

ne

reaso

n:

sharin

gw

ithM

OF

(seelater)

and,e.g

.,CW

M.

Co

re

UM

L

MO

F

CW

M

Pro

files

Figure 0-1

Ove

rview o

f archite

cture

Class, O

bject Action, Film

strip Package, Snapshot

Class, State,

Transition, Flow

, …

Superstructure (concrete syntax)

ClassBox, StateBox,

TransitionLine, …

Superstructure (abstract syntax)

Infrastructure (w

ith semantics)

Diagram

Interchange

Node, Edge…

– 21 – 2014-02-05 – Swhole –

51

/74

UM

LS

uperstructure

Packages[O

MG

,2007a,1

5]

Fig

ure 7.5 - T

he to

p-level packag

e structu

re of th

e UM

L 2.1.1 S

up

erstructu

re

Com

monB

ehaviors

UseC

ases

Classes

StateM

achinesInteractions

Com

positeStructures

Com

ponents

Deploym

ents

AuxiliaryC

onstructsA

ctivities

Actions

– 21 – 2014-02-05 – Swhole –

52

/74

Meta-M

odellin

g:P

rinciple

– 21 – 2014-02-05 – main –

53

/74

Mo

delling

vs.Meta-M

odellin

g

Class

nam

e:

Str

Prop

erty

nam

e:

Str

Typ

e

nam

e:

Str

C

v:Z

:Class

nam

e=

C

:Prop

erty

nam

e=

v

:Typ

e

nam

e=

Z

S

=({Z},

{C},{v

},{C

7→v}),

D

Σ DS

:C

v=

0 insta

nce-o

f

σ=

{u7→

{v7→

0}}

∈

Meta-

Model

(M2)

Model

(M1)

Instan

ce(M

0)

– 21 – 2014-02-05 – Sprinciple –

54

/74

Mo

delling

vs.Meta-M

odellin

g

Class

nam

e:

Str

Prop

erty

nam

e:

Str

Typ

e

nam

e:

Str

C

v:Z

:Class

nam

e=

C

:Prop

erty

nam

e=

v

:Typ

e

nam

e=

Z

S

=({Z},

{C},{v

},{C

7→v}),

D

Σ DS:C

v=

0 insta

nce-o

f

σ=

{u7→

{v7→

0}}

∈

Meta-

Model

(M2)

Model

(M1)

Instan

ce(M

0)

•So,

ifwe

have

am

eta

modelM

Uof

UM

L,th

enth

eset

ofU

ML

models

isth

eset

ofin

stances

ofM

U.

•A

UM

Lm

odelM

canbe

represented

asan

object

diagram

(orsystem

state)w

rt.th

em

eta

-modelM

U.

•O

ther

vie

w:

An

object

diagram

wrt.

meta

-modelM

U

can(altern

atively)be

rendered

asth

eU

ML

modelM

.

– 21 – 2014-02-05 – Sprinciple –

54

/74

Well-Form

ednessas

Co

nstraintsin

theM

eta-Mo

del

•T

he

setof

well-fo

rmed

UM

Lm

odels

canbe

defi

ned

asth

eset

ofob

jectdiagram

ssatisfyin

gall

constrain

tsof

the

meta

-model.

For

example,

“[2]G

eneralization

hierarch

iesm

ust

be

directed

and

acyclical.A

classifier

cannot

be

both

atran

sitivelygen

eralan

dtran

sitivelysp

ecific

classifier

ofth

esam

eclassifi

er.

not

self.allP

arents()

->

inclu

des(self)”

[OM

G,2007b

,53]

•T

he

other

way

round:

Given

aU

ML

modelM

,unfold

itin

toan

object

diagram

O1

wrt.

MU

.If

O1

isa

valid

object

diagram

ofM

U(i.e.

satisfies

allin

variants

fromIn

v(MU

)),th

enM

isa

well-form

edU

ML

model.

That

is,if

we

have

anob

jectdiagram

valid

itychecker

forof

the

meta-m

odellin

glan

guage,

then

we

have

awell-fo

rmedness

checker

forU

ML

models.

– 21 – 2014-02-05 – Sprinciple –

55

/74

Rea

ding

theSta

nd

ard

UM

L Superstructure S

pecification, v2.1.2 i

Tab

le of C

on

tents

1.S

cop

e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.C

on

form

ance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.1 Language U

nits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

2.2 C

ompliance Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

2.3 M

eaning and Types of C

ompliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

2.4 C

ompliance Level C

ontents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

3.N

orm

ative Referen

ces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.T

erms an

d D

efinitio

ns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.S

ymb

ols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6.A

dd

ition

al Info

rmatio

n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6.1 C

hanges to Adopted O

MG

Specifications . . . . . . . . . . . . . . . . . . . . . . . . .10

6.2 A

rchitectural Alignm

ent and MD

A S

upport . . . . . . . . . . . . . . . . . . . . . . . . .10

6.3 O

n the Run-T

ime S

emantics of U

ML . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

6.3.1 The B

asic Prem

ises ................................................................................................116.3.2 T

he Sem

antics Architecture ....................................................................................11

6.3.3 The B

asic Causality M

odel .....................................................................................126.3.4 S

emantics D

escriptions in the Specification ...........................................................13

6.4 T

he UM

L Metam

odel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136.4.1 M

odels and What T

hey Model ................................................................................13

6.4.2 Sem

antic Levels and Nam

ing .................................................................................14

6.5 H

ow to R

ead this Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

6.5.1 Specification form

at ................................................................................................156.5.2 D

iagram form

at .......................................................................................................18

6.6 A

cknowledgem

ents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

Part I - S

tructu

re . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7.C

lasses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

– 21 – 2014-02-05 – Sreading –

56

/74

Rea

ding

theSta

nd

ard

UM

L Superstructure S

pecification, v2.1.2 i

Tab

le of C

on

tents

1.S

cop

e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.C

on

form

ance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.1 Language U

nits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

2.2 C

ompliance Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

2.3 M

eaning and Types of C

ompliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

2.4 C

ompliance Level C

ontents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

3.N

orm

ative Referen

ces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.T

erms an

d D

efinitio

ns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.S

ymb

ols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6.A

dd

ition

al Info

rmatio

n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6.1 C

hanges to Adopted O

MG

Specifications . . . . . . . . . . . . . . . . . . . . . . . . .10

6.2 A

rchitectural Alignm

ent and MD

A S

upport . . . . . . . . . . . . . . . . . . . . . . . . .10

6.3 O

n the Run-T

ime S

emantics of U

ML . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

6.3.1 The B

asic Prem

ises ................................................................................................116.3.2 T

he Sem

antics Architecture ....................................................................................11

6.3.3 The B

asic Causality M

odel .....................................................................................126.3.4 S

emantics D

escriptions in the Specification ...........................................................13

6.4 T

he UM

L Metam

odel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136.4.1 M

odels and What T

hey Model ................................................................................13

6.4.2 Sem

antic Levels and Nam

ing .................................................................................14

6.5 H

ow to R

ead this Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

6.5.1 Specification form

at ................................................................................................156.5.2 D

iagram form

at .......................................................................................................18

6.6 A

cknowledgem

ents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

Part I - S

tructu

re . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7.C

lasses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23ii

UM

L Superstructure S

pecification, v2.1.2

7.1 O

verview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

7.2 A

bstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

7.3 C

lass Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

7.3.1 Abstraction (from

Dependencies) ...........................................................................38

7.3.2 AggregationK

ind (from K

ernel) ...............................................................................387.3.3 A

ssociation (from K

ernel) .......................................................................................397.3.4 A

ssociationClass (from

AssociationC

lasses) ..........................................................477.3.5 B

ehavioralFeature (from

Kernel) ............................................................................48

7.3.6 BehavioredC

lassifier (from Interfaces) ...................................................................49

7.3.7 Class (from

Kernel) .................................................................................................49

7.3.8 Classifier (from

Kernel, D

ependencies, Pow

erTypes) ............................................52

7.3.9 Com

ment (from

Kernel) ..........................................................................................57

7.3.10 Constraint (from

Kernel) .......................................................................................58

7.3.11 DataT

ype (from K

ernel) ........................................................................................607.3.12 D

ependency (from D

ependencies) .......................................................................627.3.13 D

irectedRelationship (from

Kernel) .......................................................................63

7.3.14 Elem

ent (from K

ernel) ...........................................................................................647.3.15 E

lementIm

port (from K

ernel) ................................................................................657.3.16 E

numeration (from

Kernel) ...................................................................................67

7.3.17 Enum

erationLiteral (from K

ernel) ..........................................................................687.3.18 E

xpression (from K

ernel) ......................................................................................697.3.19 F

eature (from K

ernel) ...........................................................................................707.3.20 G

eneralization (from K

ernel, Pow

erTypes) ...........................................................71

7.3.21 GeneralizationS

et (from P

owerT

ypes) ..................................................................757.3.22 InstanceS

pecification (from K

ernel) ......................................................................827.3.23 InstanceV

alue (from K

ernel) .................................................................................857.3.24 Interface (from

Interfaces) ....................................................................................867.3.25 InterfaceR

ealization (from Interfaces) ...................................................................89

7.3.26 LiteralBoolean (from

Kernel) .................................................................................89

7.3.27 LiteralInteger (from K

ernel) ...................................................................................907.3.28 LiteralN

ull (from K

ernel) ........................................................................................917.3.29 LiteralS

pecification (from K

ernel) ..........................................................................927.3.30 LiteralS

tring (from K

ernel) .....................................................................................927.3.31 LiteralU

nlimitedN

atural (from K

ernel) ...................................................................937.3.32 M

ultiplicityElem

ent (from K

ernel) ..........................................................................947.3.33 N

amedE

lement (from

Kernel, D

ependencies) ......................................................977.3.34 N

amespace (from

Kernel) .....................................................................................99

7.3.35 OpaqueE

xpression (from K

ernel) .......................................................................1017.3.36 O

peration (from K

ernel, Interfaces) ....................................................................1037.3.37 P

ackage (from K

ernel) ........................................................................................1077.3.38 P

ackageableElem

ent (from K

ernel) ....................................................................1097.3.39 P

ackageImport (from

Kernel) ..............................................................................110

7.3.40 PackageM

erge (from K

ernel) ..............................................................................1117.3.41 P

arameter (from

Kernel, A

ssociationClasses) ....................................................120

7.3.42 Param

eterDirectionK

ind (from K

ernel) ................................................................1227.3.43 P

rimitiveT

ype (from K

ernel) ................................................................................1227.3.44 P

roperty (from K

ernel, AssociationC

lasses) .......................................................1237.3.45 R

ealization (from D

ependencies) .......................................................................1297.3.46 R

edefinableElem

ent (from K

ernel) .....................................................................130

– 21 – 2014-02-05 – Sreading –

56

/74

Rea

ding

theSta

nd

ard

UM

L Superstructure S

pecification, v2.1.2 i

Tab

le of C

on

tents

1.S

cop

e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.C

on

form

ance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.1 Language U

nits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

2.2 C

ompliance Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

2.3 M

eaning and Types of C

ompliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

2.4 C

ompliance Level C

ontents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

3.N

orm

ative Referen

ces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.T

erms an

d D

efinitio

ns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.S

ymb

ols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6.A

dd

ition

al Info

rmatio

n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6.1 C

hanges to Adopted O

MG

Specifications . . . . . . . . . . . . . . . . . . . . . . . . .10

6.2 A

rchitectural Alignm

ent and MD

A S

upport . . . . . . . . . . . . . . . . . . . . . . . . .10

6.3 O

n the Run-T

ime S

emantics of U

ML . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

6.3.1 The B

asic Prem

ises ................................................................................................116.3.2 T

he Sem

antics Architecture ....................................................................................11

6.3.3 The B

asic Causality M

odel .....................................................................................126.3.4 S

emantics D

escriptions in the Specification ...........................................................13

6.4 T

he UM

L Metam

odel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136.4.1 M

odels and What T

hey Model ................................................................................13

6.4.2 Sem

antic Levels and Nam

ing .................................................................................14

6.5 H

ow to R

ead this Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

6.5.1 Specification form

at ................................................................................................156.5.2 D

iagram form

at .......................................................................................................18

6.6 A

cknowledgem

ents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

Part I - S

tructu

re . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7.C

lasses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23ii

UM

L Superstructure S

pecification, v2.1.2

7.1 O

verview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

7.2 A

bstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

7.3 C

lass Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

7.3.1 Abstraction (from

Dependencies) ...........................................................................38

7.3.2 AggregationK

ind (from K

ernel) ...............................................................................387.3.3 A

ssociation (from K

ernel) .......................................................................................397.3.4 A

ssociationClass (from

AssociationC

lasses) ..........................................................477.3.5 B

ehavioralFeature (from

Kernel) ............................................................................48

7.3.6 BehavioredC

lassifier (from Interfaces) ...................................................................49

7.3.7 Class (from

Kernel) .................................................................................................49

7.3.8 Classifier (from

Kernel, D

ependencies, Pow

erTypes) ............................................52

7.3.9 Com

ment (from

Kernel) ..........................................................................................57

7.3.10 Constraint (from

Kernel) .......................................................................................58

7.3.11 DataT

ype (from K

ernel) ........................................................................................607.3.12 D

ependency (from D

ependencies) .......................................................................627.3.13 D

irectedRelationship (from

Kernel) .......................................................................63

7.3.14 Elem

ent (from K

ernel) ...........................................................................................647.3.15 E

lementIm

port (from K

ernel) ................................................................................657.3.16 E

numeration (from

Kernel) ...................................................................................67

7.3.17 Enum

erationLiteral (from K

ernel) ..........................................................................687.3.18 E

xpression (from K

ernel) ......................................................................................697.3.19 F

eature (from K

ernel) ...........................................................................................707.3.20 G

eneralization (from K

ernel, Pow

erTypes) ...........................................................71

7.3.21 GeneralizationS

et (from P

owerT

ypes) ..................................................................757.3.22 InstanceS

pecification (from K

ernel) ......................................................................827.3.23 InstanceV

alue (from K

ernel) .................................................................................857.3.24 Interface (from

Interfaces) ....................................................................................867.3.25 InterfaceR

ealization (from Interfaces) ...................................................................89

7.3.26 LiteralBoolean (from

Kernel) .................................................................................89

7.3.27 LiteralInteger (from K

ernel) ...................................................................................907.3.28 LiteralN

ull (from K

ernel) ........................................................................................917.3.29 LiteralS

pecification (from K

ernel) ..........................................................................927.3.30 LiteralS

tring (from K

ernel) .....................................................................................927.3.31 LiteralU

nlimitedN

atural (from K

ernel) ...................................................................937.3.32 M

ultiplicityElem

ent (from K

ernel) ..........................................................................947.3.33 N

amedE

lement (from

Kernel, D

ependencies) ......................................................977.3.34 N

amespace (from

Kernel) .....................................................................................99

7.3.35 OpaqueE

xpression (from K

ernel) .......................................................................1017.3.36 O

peration (from K

ernel, Interfaces) ....................................................................1037.3.37 P

ackage (from K

ernel) ........................................................................................1077.3.38 P

ackageableElem

ent (from K

ernel) ....................................................................1097.3.39 P

ackageImport (from

Kernel) ..............................................................................110

7.3.40 PackageM

erge (from K

ernel) ..............................................................................1117.3.41 P

arameter (from

Kernel, A

ssociationClasses) ....................................................120

7.3.42 Param

eterDirectionK

ind (from K

ernel) ................................................................1227.3.43 P

rimitiveT

ype (from K

ernel) ................................................................................1227.3.44 P

roperty (from K

ernel, AssociationC

lasses) .......................................................1237.3.45 R

ealization (from D

ependencies) .......................................................................1297.3.46 R

edefinableElem

ent (from K

ernel) .....................................................................130U

ML S

uperstructure Specification, v2.1.2

iii

7.3.47 Relationship (from

Kernel) ..................................................................................132

7.3.48 Slot (from

Kernel) ................................................................................................132

7.3.49 StructuralF

eature (from K

ernel) ..........................................................................1337.3.50 S

ubstitution (from D

ependencies) ......................................................................1347.3.51 T

ype (from K

ernel) ..............................................................................................1357.3.52 T

ypedElem

ent (from K

ernel) ...............................................................................1367.3.53 U

sage (from D

ependencies) ...............................................................................1377.3.54 V

alueSpecification (from

Kernel) ........................................................................137

7.3.55 VisibilityK

ind (from K

ernel) ..................................................................................139

7.4 D

iagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140

8.C

om

po

nen

ts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

8.1 O

verview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143

8.2 A

bstract syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144

8.3 C

lass Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146

8.3.1 Com

ponent (from B

asicCom

ponents, PackagingC

omponents) ...........................146

8.3.2 Connector (from

BasicC

omponents) ....................................................................154

8.3.3 ConnectorK

ind (from B

asicCom

ponents) .............................................................1578.3.4 C

omponentR

ealization (from B

asicCom

ponents) .................................................157

8.4 D

iagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159

9.C

om

po

site Stru

ctures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

9.1 O

verview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161

9.2 A

bstract syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161

9.3 C

lass Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166

9.3.1 Class (from

StructuredC

lasses) ............................................................................1669.3.2 C

lassifier (from C

ollaborations) ............................................................................1679.3.3 C

ollaboration (from C

ollaborations) ......................................................................1689.3.4 C

ollaborationUse (from

Collaborations) ................................................................171

9.3.5 ConnectableE

lement (from

InternalStructures) ....................................................174

9.3.6 Connector (from

InternalStructures) .....................................................................174

9.3.7 ConnectorE

nd (from InternalS

tructures, Ports) ....................................................176

9.3.8 EncapsulatedC

lassifier (from P

orts) .....................................................................1789.3.9 InvocationA

ction (from InvocationA

ctions) ............................................................1789.3.10 P

arameter (from

Collaborations) ........................................................................179

9.3.11 Port (from

Ports) .................................................................................................179

9.3.12 Property (from

InternalStructures) ......................................................................183

9.3.13 StructuredC

lassifier (from InternalS

tructures) ....................................................1869.3.14 T

rigger (from InvocationA

ctions) .........................................................................1909.3.15 V

ariable (from S

tructuredActivities) ....................................................................191

9.4 D

iagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191

10.D

eplo

ymen

ts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

– 21 – 2014-02-05 – Sreading –

56

/74

Rea

ding

theSta

nd

ardC

ont’d

52 U

ML S

uperstructure Specification, v2.1.2

Fig

ure 7.29 - C

lass no

tation

: attribu

tes and

op

eration

s gro

up

ed acco

rdin

g to

visibility

7.3.8 C

lassifier (from

Kern

el, Dep

end

encies, P

ow

erTyp

es)

A cla

ssifier is a

classificatio

n o

f insta

nces, it d

escrib

es a

set of insta

nce

s tha

t ha

ve fe

atu

res in

com

mo

n.

Gen

eralization

s

• “N

amespace (from

Kerne

l)” on page 99

• “R

edefinableElem

ent (from Kernel)” on page 1

30

• “T

ype (from K

ernel)” on page 135

Descrip

tion

A classifie

r is a na

mespa

ce w

ho

se m

embe

rs can in

clud

e featu

res. Cla

ssifier is an abstract metaclass.

A cla

ssifier is a

type

an

d ca

n o

wn

ge

ne

raliza

tion

s, the

reb

y ma

king it po

ssible

to de

fine

ge

ne

raliza

tion

rela

tion

ship

s to

oth

er classifiers. A

classifier can

specify a

gen

era

lizatio

n h

iera

rchy b

y refe

ren

cing

its ge

ne

ral cla

ssifiers.

A cla

ssifier is a

rede

fina

ble e

lem

ent, me

aning

tha

t it is po

ssible to

red

efine n

este

d cla

ssifiers.

Attrib

utes

•isA

bstra

ct: Bo

ole

an

�

If true, the C

lassifier does not provid

e a

com

ple

te d

ecla

ratio

n a

nd

can

typically not be instantiated. A

n abstract�

classifier is intended to be used by oth

er classifie

rs (e.g

., as the

targe

t of general m

etarelationships or generalization�

relationships). Default value is false.

Asso

ciation

s

•/attribute: P

roperty [*]�

Refers to all of the P

roperties that are direct (i.e., n

ot inherited or imported) attributes of the classifier. S

ubsets�

Classifie

r::fea

ture and is a derived union.

•/ feature : F

eature [*]�

Sp

ecifie

s each

featu

re d

efin

ed

in th

e classifie

r. Subsets Na

me

spa

ce::m

em

be

r. T

his is a

de

rived

union

.

•/ general : C

lassifier[*]�

Sp

ecifie

s the

ge

ne

ral C

las

sifiers for this Classifier. T

his is derived.

Win

do

w

public size: A

rea = (100, 100) defaultS

ize: Rectangle

protected visibility: B

oolean = true

private xW

in: XW

indowpublic display() hide()private attachX

(xWin: X

Window

)

– 21 – 2014-02-05 – Sreading –

57

/74

Rea

ding

theSta

nd

ardC

ont’d

52 U

ML S

uperstructure Specification, v2.1.2

Fig

ure 7.29 - C

lass no

tation

: attribu

tes and

op

eration

s gro

up

ed acco

rdin

g to

visibility

7.3.8 C

lassifier (from

Kern

el, Dep

end

encies, P

ow

erTyp

es)

A cla

ssifier is a

classificatio

n o

f insta

nces, it d

escrib

es a

set of insta

nce

s tha

t ha

ve fe

atu

res in

com

mo

n.

Gen

eralization

s

• “N

amespace (fro

m K

ern

el)” on page 99

• “R

edefinableElem

ent (from Kernel)” on page 1

30

• “T

ype (from K

ernel)” on page 135

Descrip

tion

A classifie

r is a na

mespa

ce w

ho

se m

embe

rs can in

clud

e featu

res. Cla

ssifier is an abstract metaclass.

A cla

ssifier is a

type

an

d ca

n o

wn

ge

ne

raliza

tion

s, the

reb

y ma

king it po

ssible

to de

fine

ge

ne

raliza

tion

rela

tion

ship

s to

oth

er classifiers. A

classifier can

specify a

gen

era

lizatio

n h

iera

rchy b

y refe

ren

cing

its ge

ne

ral cla

ssifiers.

A cla

ssifier is a

rede

fina

ble e

lem

ent, me

aning

tha

t it is po

ssible to

red

efine n

este

d cla

ssifiers.

Attrib

utes

•isA

bstra

ct: Bo

ole

an

�

If true, the C

lassifier does not provid

e a

com

ple

te d

ecla

ratio

n a

nd

can

typically not be instantiated. A

n abstract�

classifier is intended to be used by oth

er classifie

rs (e.g

., as the

targe

t of general m

etarelationships or generalization�

relationships). Default value is false.

Asso

ciation

s

•/attribute: P

roperty [*]�

Refers to all of the P

roperties that are direct (i.e., n

ot inherited or imported) attributes of the classifier. S

ubsets�

Classifie

r::fea

ture and is a derived union.

•/ feature : F

eature [*]�

Sp

ecifie

s each

featu

re d

efin

ed

in th

e classifie

r. Subsets Na

me

spa

ce::m

em

be

r. T

his is a

de

rived

union

.

•/ general : C

lassifier[*]�

Sp

ecifie

s the

ge

ne

ral C

las

sifiers for this Classifier. T

his is derived.

Win

do

w

public size: A

rea = (100, 100) defaultS

ize: Rectangle

protected visibility: B

oolean = true

private xW

in: XW

indowpublic display() hide()private attachX

(xWin: X

Window

)

UM

L Superstructure S

pecification, v2.1.2 53

•generalization: G

eneralization[*]�

Specifies the G

eneralization relationships for this Classifier. T

hese Generalizat

ions navigate to more general�

classifiers in the generalization hierarchy. Su

bse

ts Ele

me

nt::o

wned

Ele

me

nt

•/ inheritedM

ember: N

amedE

lement[*]

�

Specifies all elem

ents inherited by this classifier from the general classifiers.

Su

bse

ts Na

me

spa

ce::m

em

be

r. T

his is�derived.

•redefinedC

lassifier: Classifier

[*]�

References the C

lassifiers that are redefin

ed by this Classifier. S

ubsets Re

definab

leE

lemen

t::rede

fine

dE

lem

ent

Package D

ependencies

•su

bstitution : Substitution

�

References the substitu

tions that are owned by this C

lassifier. Subsets E

lem

en

t::ow

ne

dE

lem

en

t and�

Na

me

dElem

en

t::clien

tDep

en

den

cy.)

Package P

owerTypes

•pow

ertypeExtent : G

eneralizationSet

�

Designates the G

eneralizationSet of w

hich the associated C

lassifier is a power type.

Co

nstrain

ts

[1] T

he

general classifiers are the classifiers referenced by the generalization relationships.

general = self.parents()

[2]G

eneralization hierarchies must be directe

d a

nd

acyclical. A

classifie

r cannot be both a transitively general and

transitively specific classifier of th

e sa

me cla

ssifier.

no

t self.allParents()->

includes(self)

[3]A

classifier may only specialize

classifie

rs of a va

lid typ

e.

self.parents()->forA

ll(c | self.mayS

pecializeType(c))

[4]T

he inheritedMem

ber association is derived by inheriting the inheritable mem

bers of the parents.

self.inheritedMem

ber->includesA

ll(self.inherit(self.parents()->collect(p | p.inheritableM

embers(self)))

Package P

owerTypes

[5]

Th

e C

lassifie

r tha

t map

s to a

Ge

neralizationS

et may neither be a specific nor a general C

lassifier in any of the G

eneralization relationships defined for that GeneralizationS

et. In other words, a power type m

ay not be an instance of itself n

or may its instances also be its subcl

asses.

Ad

ditio

nal O

peratio

ns

[1] T

he

qu

ery allF

ea

ture

s() give

s all o

f the features in the namespace of the classifi

er. In

ge

ne

ral, th

rou

gh

me

cha

nism

s su

ch as

inheritance, this will be a larger set than feature.

Classifier::allF

eatures(): Set(F

eature);allF

eatures = m

ember->

select(oclIsKindO

f(Feature))

[2]T

he

que

ry parents() give

s all o

f the im

med

iate

an

cesto

rs o

f a g

eneralized Classifier.

Classifier::parents(): S

et(Classifier);

parents = generalization.general�

��

– 21 – 2014-02-05 – Sreading –

57

/74

Rea

ding

theSta

nd

ardC

ont’d

52 U

ML S

uperstructure Specification, v2.1.2

Fig

ure 7.29 - C

lass no

tation

: attribu

tes and

op

eration

s gro

up

ed acco

rdin

g to

visibility

7.3.8 C

lassifier (from

Kern

el, Dep

end

encies, P

ow

erTyp

es)

A cla

ssifier is a

classificatio

n o

f insta

nces, it d

escrib

es a

set of insta

nce

s tha

t ha

ve fe

atu

res in

com

mo

n.

Gen

eralization

s

• “N

amespace (fro

m K

ern

el)” on page 99

• “R

edefinableElem

ent (from Kernel)” on page 1

30

• “T

ype (from K

ernel)” on page 135

Descrip

tion

A classifie

r is a na

mespa

ce w

ho

se m

embe

rs can in

clud

e featu

res. Cla

ssifier is an abstract metaclass.

A cla

ssifier is a

type

an

d ca

n o

wn

ge

ne

raliza

tion

s, the

reb

y ma

king it po

ssible

to de

fine

ge

ne

raliza

tion

rela

tion

ship

s to

oth

er classifiers. A

classifier can

specify a

gen

era

lizatio

n h

iera

rchy b

y refe

ren

cing

its ge

ne

ral cla

ssifiers.

A cla

ssifier is a

rede

fina

ble e

lem

ent, me

aning

tha

t it is po

ssible to

red

efine n

este

d cla

ssifiers.

Attrib

utes

•isA

bstra

ct: Bo

ole

an

�

If true, the C

lassifier does not provid

e a

com

ple

te d

ecla

ratio

n a

nd

can

typically not be instantiated. A

n abstract�

classifier is intended to be used by oth

er classifie

rs (e.g

., as the

targe

t of general m

etarelationships or generalization�

relationships). Default value is false.

Asso

ciation

s

•/attribute: P

roperty [*]�

Refers to all of the P

roperties that are direct (i.e., n

ot inherited or imported) attributes of the classifier. S

ubsets�

Classifie

r::fea

ture and is a derived union.

•/ feature : F

eature [*]�

Sp

ecifie

s each

featu

re d

efin

ed

in th

e classifie

r. Subsets Na

me

spa

ce::m

em

be

r. T

his is a

de

rived

union

.

•/ general : C

lassifier[*]�

Sp

ecifie

s the

ge

ne

ral C

las

sifiers for this Classifier. T

his is derived.

Win

do

w

public size: A

rea = (100, 100) defaultS

ize: Rectangle

protected visibility: B

oolean = true

private xW

in: XW

indowpublic display() hide()private attachX

(xWin: X

Window

)

UM

L Superstructure S

pecification, v2.1.2 53

•generalization: G

eneralization[*]�

Specifies the G

eneralization relationships for this Classifier. T

hese Generalizat

ions navigate to more general�

classifiers in the generalization hierarchy. Su

bse

ts Ele

me

nt::o

wned

Ele

me

nt

•/ inheritedM

ember: N

amedE

lement[*]

�

Specifies all elem

ents inherited by this classifier from the general classifiers.

Su

bsets N

am

esp

ace

::me

mb

er

. This is�

derived.

•redefinedC

lassifier: Classifier

[*]�

References the C

lassifiers that are redefin

ed by this Classifier. S

ubsets Re

definab

leE

lemen

t::rede

fine

dE

lem

ent

Package D

ependencies

•su

bstitution : Substitution

�

References the substitu

tions that are owned by this C

lassifier. Subsets E

lem

en

t::ow

ne

dE

lem

en

t and�

Na

me

dElem

en

t::clien

tDep

en

den

cy.)

Package P

owerTypes

•pow

ertypeExtent : G

eneralizationSet

�

Designates the G

eneralizationSet of w

hich the associated C

lassifier is a power type.

Co

nstrain

ts

[1] Th

e g

eneral classifiers are the classifiers referenced by the generalization relationships.

general = self.parents()

[2]G

eneralization hierarchies must be directe

d a

nd

acyclical. A

classifie

r cannot be both a transitively general and

transitively specific classifier of th

e sa

me cla

ssifier.

no

t self.allParents()->

includes(self)

[3]A

classifier may only specialize

classifie

rs of a va

lid typ

e.

self.parents()->forA

ll(c | self.mayS

pecializeType(c))

[4]T

he inheritedMem

ber association is derived by inheriting the inheritable mem

bers of the parents.

self.inheritedMem

ber->includesA

ll(self.inherit(self.parents()->collect(p | p.inheritableM

embers(self)))

Package P

owerTypes

[5]

Th

e C

lassifie

r tha

t map

s to a

Ge

neralizationS

et may neither be a specific nor a general C

lassifier in any of the G

eneralization relationships defined for that GeneralizationS

et. In other words, a power type m

ay not be an instance of itself n

or may its instances also be its subcl

asses.

Ad

ditio

nal O

peratio

ns

[1] T

he

qu

ery allF

ea

ture

s() give

s all o

f the features in the namespace of the classifi

er. In

ge

ne

ral, th

rou

gh

me

cha

nism

s su

ch as

inheritance, this will be a larger set than feature.

Classifier::allF

eatures(): Set(F

eature);allF

eatures = m

ember->

select(oclIsKindO

f(Feature))

[2]T

he

que

ry parents() give

s all o

f the im

med

iate

an

cesto

rs o

f a g

eneralized Classifier.

Classifier::parents(): S

et(Classifier);

parents = generalization.general�

��

54 U

ML S

uperstructure Specification, v2.1.2

[3]

Th

e q

ue

ry allP

are

nts() g

ives a

ll of the direct and indirect ancestors of a generalized Classifier.

Classifier::allP

arents(): Set(C

lassifier);

allParents =

self.parents()->union(self.parents()->

collect(p | p.allParents())

[4]

The query inheritableM

embers() gives all o

f the

me

mb

ers of a

classifie

r tha

t ma

y be inherited in one of its descendants, subject to w

hatever visibility restrictions apply.

Classifier::inheritableM

embers(c: C

lassifier): Set(N

amedE

lement);

pre: c.allP

arents()->includes(self)

inheritableMem

bers = m

ember->

select(m | c.hasV

isibilityOf(m

))

[5]

The query hasVisibilityO

f() determines w

heth

er a n

am

ed e

lem

en

t is visible

in the

classifier. By default all are visible. It is

only called when the argum

ent is something ow

ned by a parent.

Classifier::hasVisibilityO

f(n: Nam

edElem

ent) : Boolean;

pre: self.allP

arents()->collect(c | c.m

ember)->

includes(n)

if (self.inheritedMem

ber->includes(n)) th

en�

hasV

isibilityO

f = (n.visib

ility <> #private)

�

else

hasVisibilityO

f = tru

e

[6]T

he que

ry confo

rmsTo() gives true for a

classifier that defines a type that conform

s to another. This is used, for exam

ple, in the specification of signature conform

ance for operations.

Classifier::conform

sTo(other: Classifier): B

oolean;

conformsTo =

(self=other) or (self.allP

arents()->includes(other))

[7]

The query inherit() defin

es how

to inherit a set of elements. H

ere the operation is defined to inherit them all. It is intended

to be redefined in circumstances

where inheritance is affected by redefinition.

Classifier::inherit(inhs: S

et(Nam

edElem

ent)): Set(N

amedE

lement);

inherit = inhs

[8]

The query mayS

pecializeType() determines w

hether this classifier may have a generalization relationship to classifiers of

the specified type. By default a classifier

may specialize classifiers of the sam

e or a more general type. It is intended to be

redefin

ed b

y classifie

rs that have

diffe

ren

t spe

cializa

tion

con

strain

ts.

Classifier::m

aySpecializeType(c : C

lassifier) : Boolean;

mayS

pecializeType = self.oclIsK

indOf(c.oclType)

Sem

antics

A cla

ssifier is a

classificatio

n o

f insta

nces acco

rdin

g to

the

ir fea

tures.

A C

lassifie

r ma

y pa

rticipa

te in

ge

ne

raliza

tio

n re

latio

nsh

ips w

ith o

the

r Cla

ssifiers. A

n in

stan

ce o

f a sp

ecific C

lassifie

r is also

an (ind

irect) in

stan

ce of e

ach o

f the

gene

ral Cla

ssifiers. Th

erefo

re, fe

atu

res specifie

d fo

r instance

s of th

e g

ene

ral cla

ssifier a

re imp

licitly spe

cified

for in

stan

ces o

f the

spe

cific cla

ssifier. A

ny con

strain

t ap

plyin

g to

insta

nce

s of

the

g

en

era

l classifie

r also

ap

plie

s to in

stan

ces o

f the

spe

cific classifie

r.

Th

e sp

ecific se

mantics o

f ho

w g

en

era

lization

affe

cts ea

ch co

ncre

te su

btyp

e o

f C

lassifier va

ries. All in

stan

ces of a

classifie

r ha

ve va

lues co

rresp

on

din

g to

the

classifie

r’s a

ttribu

tes.

A C

lassifie

r de

fines a typ

e. Typ

e co

nfo

rman

ce b

etw

ee

n g

en

era

lizab

le

Cla

ssifiers is defin

ed

so tha

t a Cla

ssifier con

form

s to

itself a

nd

to a

ll of its a

nce

stors in

the

gene

raliza

tion

hiera

rchy.

– 21 – 2014-02-05 – Sreading –

57

/74

Rea

ding

theSta

nd

ardC

ont’d

52 U

ML S

uperstructure Specification, v2.1.2

Fig

ure 7.29 - C

lass no

tation

: attribu

tes and

op

eration

s gro

up

ed acco

rdin

g to

visibility

7.3.8 C

lassifier (from

Kern

el, Dep

end

encies, P

ow

erTyp

es)

A cla

ssifier is a

classificatio

n o

f insta

nces, it d

escrib

es a

set of insta

nce

s tha

t ha

ve fe

atu

res in

com

mo

n.

Gen

eralization

s

• “N

amespace (from

Kerne

l)” on page 99

• “R

edefinableElem

ent (from Kernel)” on page 1

30

• “T

ype (from K

ernel)” on page 135

Descrip

tion

A classifie

r is a na

mespa

ce w

ho

se m

embe

rs can in

clud

e featu

res. Cla

ssifier is an abstract metaclass.

A cla

ssifier is a

type

an

d ca

n o

wn

ge

ne

raliza

tion

s, the

reb

y ma

king it po

ssible

to de

fine

ge

ne

raliza

tion

rela

tion

ship

s to

oth

er classifiers. A

classifier can

specify a

gen

era

lizatio

n h

iera

rchy b

y refe

ren

cing

its ge

ne

ral cla

ssifiers.

A cla

ssifier is a

rede

fina

ble e

lem

ent, me

aning

tha

t it is po

ssible to

red

efine n

este

d cla

ssifiers.

Attrib

utes

•isA

bstra

ct: Bo

ole

an

�

If true, the C

lassifier does not provid

e a

com

ple

te d

ecla

ratio

n a

nd

can

typically not be instantiated. A

n abstract�

classifier is intended to be used by oth

er classifie

rs (e.g

., as the

targe

t of general m

etarelationships or generalization�

relationships). Default value is false.

Asso

ciation

s

•/attribute: P

roperty [*]�

Refers to all of the P

roperties that are direct (i.e., n

ot inherited or imported) attributes of the classifier. S

ubsets�

Classifie

r::fea

ture and is a derived union.

•/ feature : F

eature [*]�

Sp

ecifie

s each

featu

re d

efin

ed

in th

e classifie

r. Subsets Na

me

spa

ce::m

em

be

r. T

his is a

de

rived

union

.

•/ general : C

lassifier[*]�

Sp

ecifie

s the

ge

ne

ral C

las

sifiers for this Classifier. T

his is derived.

Win

do

w

public size: A

rea = (100, 100) defaultS

ize: Rectangle

protected visibility: B

oolean = true

private xW

in: XW

indowpublic display() hide()private attachX

(xWin: X

Window

)

UM

L Superstructure S

pecification, v2.1.2 53

•generalization: G

eneralization[*]�

Specifies the G

eneralization relationships for this Classifier. T

hese Generalizat

ions navigate to more general�

classifiers in the generalization hierarchy. Su

bsets Ele

me

nt::o

wned

Ele

me

nt

•/ inheritedM

ember: N

amedE

lement[*]

�

Specifies all elem

ents inherited by this classifier from the general classifiers.

Su

bsets N

am

esp

ace

::me

mb

er

. This is�

derived.

•redefinedC

lassifier: Classifier

[*]�

References the C

lassifiers that are redefin

ed by this Classifier. S

ubsets Re

definab

leE

lemen

t::rede

fine

dE

lem

ent

Package D

ependencies

•su

bstitution : Substitution

�

References the substitu

tions that are owned by this C

lassifier. Subsets E

lem

en

t::ow

ne

dE

lem

en

t and�

Na

me

dElem

en

t::clien

tDep

en

den

cy.)

Package P

owerTypes

•pow

ertypeExtent : G

eneralizationSet

�

Designates the G

eneralizationSet of w

hich the associated C

lassifier is a power type.

Co

nstrain

ts

[1] The g

eneral classifiers are the classifiers referenced by the generalization relationships.

general = self.parents()

[2]G

eneralization hierarchies must be directe

d a

nd

acyclical. A

classifie

r cannot be both a transitively general and

transitively specific classifier of th

e sa

me cla

ssifier.

no

t self.allParents()->

includes(self)

[3]A

classifier may only specialize

classifie

rs of a va

lid typ

e.

self.parents()->forA

ll(c | self.mayS

pecializeType(c))

[4]T

he inheritedMem

ber association is derived by inheriting the inheritable mem

bers of the parents.

self.inheritedMem

ber->includesA

ll(self.inherit(self.parents()->collect(p | p.inheritableM

embers(self)))

Package P

owerTypes

[5]

Th

e C

lassifie

r tha

t map

s to a

Ge

neralizationS

et may neither be a specific nor a general C

lassifier in any of the G

eneralization relationships defined for that GeneralizationS

et. In other words, a power type m

ay not be an instance of itself n

or may its instances also be its subcl

asses.

Ad

ditio

nal O

peratio

ns

[1] T

he

qu

ery allF

ea

ture

s() give

s all o

f the features in the namespace of the classifi

er. In

ge

ne

ral, th

rou

gh

me

cha

nism

s su

ch as

inheritance, this will be a larger set than feature.

Classifier::allF

eatures(): Set(F

eature);allF

eatures = m

ember->

select(oclIsKindO

f(Feature))

[2]T

he

que

ry parents() give

s all o

f the im

med

iate

an

cesto

rs o

f a g

eneralized Classifier.

Classifier::parents(): S

et(Classifier);

parents = generalization.general�

��

54 U

ML S

uperstructure Specification, v2.1.2

[3]

Th

e q

ue

ry allP

are

nts() g

ives a

ll of the direct and indirect ancestors of a generalized Classifier.

Classifier::allP

arents(): Set(C

lassifier);

allParents =

self.parents()->union(self.parents()->

collect(p | p.allParents())

[4]

The query inheritableM

embers() gives all o

f the

me

mb

ers of a

classifie

r tha

t ma

y be inherited in one of its descendants, subject to w

hatever visibility restrictions apply.

Classifier::inheritableM

embers(c: C

lassifier): Set(N

amedE

lement);

pre: c.allP

arents()->includes(self)

inheritableMem

bers = m

ember->

select(m | c.hasV

isibilityOf(m

))

[5]

The query hasVisibilityO

f() determines w

heth

er a n

am

ed e

lem

en

t is visible

in the

classifier. By default all are visible. It is

only called when the argum

ent is something ow

ned by a parent.

Classifier::hasVisibilityO

f(n: Nam

edElem

ent) : Boolean;

pre: self.allP

arents()->collect(c | c.m

ember)->

includes(n)

if (self.inheritedMem

ber->includes(n)) th

en�

hasV

isibilityO

f = (n.visib

ility <> #private)

�

else

hasVisibilityO

f = tru

e

[6]T

he que

ry confo

rmsTo() gives true for a

classifier that defines a type that conform

s to another. This is used, for exam

ple, in the specification of signature conform

ance for operations.

Classifier::conform

sTo(other: Classifier): B

oolean;

conformsTo =

(self=other) or (self.allP

arents()->includes(other))

[7]

The query inherit() defin

es how

to inherit a set of elements. H

ere the operation is defined to inherit them all. It is intended

to be redefined in circumstances

where inheritance is affected by redefinition.

Classifier::inherit(inhs: S

et(Nam

edElem

ent)): Set(N

amedE

lement);

inherit = inhs

[8]

The query mayS

pecializeType() determines w

hether this classifier may have a generalization relationship to classifiers of

the specified type. By default a classifier

may specialize classifiers of the sam

e or a more general type. It is intended to be

redefin

ed b

y classifie

rs that have

diffe

ren

t spe

cializa

tion

con

strain

ts.

Classifier::m

aySpecializeType(c : C

lassifier) : Boolean;

mayS

pecializeType = self.oclIsK

indOf(c.oclType)

Sem

antics

A cla

ssifier is a

classificatio

n o

f insta

nces acco

rdin

g to

the

ir fea

tures.

A C

lassifie

r ma

y pa

rticipa

te in

ge

ne

raliza

tio

n re

latio

nsh

ips w

ith o

the

r Cla

ssifiers. A

n in

stan

ce o

f a sp

ecific C

lassifie

r is also

an (ind

irect) in

stan

ce of e

ach o

f the

gene

ral Cla

ssifiers. Th

erefo

re, fe

atu

res specifie

d fo

r instance

s of th

e g

ene

ral cla

ssifier a

re imp

licitly spe

cified

for in

stan

ces o

f the

spe

cific cla

ssifier. A

ny con

strain

t ap

plyin

g to

insta

nce

s of

the

g

en

era

l classifie

r also

ap

plie

s to in

stan

ces o

f the

spe

cific classifie

r.

Th

e sp

ecific se

mantics o

f ho

w g

en

era

lization

affe

cts ea

ch co

ncre

te su

btyp

e o

f C

lassifier va

ries. All in

stan

ces of a

classifie

r ha

ve va

lues co

rresp

on

din

g to

the

classifie

r’s a

ttribu

tes.

A C

lassifie

r de

fines a typ

e. Typ

e co

nfo

rman

ce b

etw

ee

n g

en

era

lizab

le

Cla

ssifiers is defin

ed

so tha

t a Cla

ssifier con

form

s to

itself a

nd

to a

ll of its a

nce

stors in

the

gene

raliza

tion

hiera

rchy.

UM

L Superstructure S

pecification, v2.1.2 55

Package P

owerTypes

Th

e n

otion

of p

ow

er typ

e w

as in

spire

d

by th

e n

otio

n o

f po

we

r set. A p

owe

r set is defin

ed

as a set w

hose

instance

s are

su

bse

ts. In e

ssence

, the

n, a p

owe

r type

is a class w

ho

se instances a

re subclasse

s. Th

e po

we

rtype

Exte

nt a

ssocia

tion

rela

tes

a C

lassifie

r with

a se

t of g

en

era

lizatio

ns tha

t a) h

ave

a co

mmon sp

ecific C

lassifie

r, and

b) rep

rese

nt a

colle

ction

of su

bse

ts fo

r tha

t class.

Sem

antic V

ariation

Po

ints

Th

e p

recise

lifecycle

sem

an

tics of

ag

gre

ga

tion

is a se

mantic va

riatio

n p

oin

t.

No

tation

Cla

ssifier is a

n a

bstra

ct mo

de

l e

lem

en

t, and

so p

rop

erly sp

ea

kin

g h

as n

o n

ota

tion

. It is ne

verthe

less co

nve

nie

nt

to d

efin

e

in o

ne

pla

ce a

de

fau

lt no

ta

tion

ava

ilab

le for a

ny co

ncre

te su

bclass o

f Cla

ssifier for w

hich

this n

ota

tion

is suita

ble

. Th

e

de

fau

lt no

tatio

n fo

r a cla

ssifier is a

solid

-ou

tline

recta

ng

le

con

tain

ing

the

classifie

r’s n

am

e, a

nd

op

tionally w

ith

com

pa

rtme

nts se

pa

rate

d b

y ho

rizon

tal lin

es co

nta

inin

g fe

atu

res o

r o

ther m

emb

ers of th

e classifier. T

he

specific typ

e of

classifie

r can

be

sho

wn

in g

uille

me

ts a

bo

ve th

e n

am

e. S

ome sp

ecia

lizatio

ns o

f Cla

ssifie

r ha

ve the

ir ow

n d

istinct n

ota

tions.

Th

e n

am

e o

f an

ab

stract C

lassifie

r is sho

wn

in ita

lics.

An a

ttribu

te ca

n b

e sh

ow

n a

s a te

xt string

. Th

e fo

rma

t of th

is strin

g is spe

cified

in th

e N

ota

tion

sub

clau

se o

f “Pro

pe

rty (fro

m K

ern

el, A

ssocia

tion

Cla

sses)” o

n p

ag

e

12

3.

Presen

tation

Op

tion

s

An

y com

pa

rtme

nt m

ay b

e su

ppresse

d. A

sep

ara

tor lin

e is n

ot d

raw

n fo

r a su

pp

resse

d co

mp

artm

en

t. If a co

mpa

rtme

nt is

sup

pre

ssed

, no in

fere

nce

can

be

d

raw

n a

bo

ut th

e p

rese

nce

o

r ab

sen

ce o

f ele

ments in

it. Co

mp

artm

en

t na

mes can

be

use

d

to rem

ove

am

big

uity, if n

ece

ssary.

An a

bstra

ct Cla

ssifier ca

n b

e sh

ow

n

usin

g th

e ke

ywo

rd {a

bstra

ct} afte

r or b

elo

w th

e n

am

e o

f the

Cla

ssifier

.

Th

e typ

e, visibility

, de

fau

lt, mu

ltiplicity, p

rop

erty strin

g m

ay b

e

suppresse

d fro

m b

eing d

ispla

yed

, eve

n if th

ere

are

va

lue

s in

the

mo

de

l.

Th

e ind

ividu

al p

rop

ertie

s of a

n a

ttribu

te ca

n b

e sh

ow

n in co

lum

ns ra

the

r tha

n as a co

ntin

uous strin

g.

Style G

uid

elines

• A

ttribute names typically begin w

ith a low

ercase letter. Multi-w

ord names are often formed by concatenating the words

an

d u

sing

lowercase for all letters except

for upcasin

g th

e first le

tter o

f ea

ch w

ord

bu

t the first.

• C

enter the name of the classifier in boldface.

• C

enter keyword (including stereotype nam

es) in plain face within guillem

ets above the classifier name.

• F

or those languages that distinguish between uppercase and lo

we

rcase

cha

racte

rs, ca

pitalize names (i.e, begin them

w

ith an uppercase character).

• Left justify attributes and operations in plain face.

• B

eg

in a

ttribu

te an

d operation nam

es with a

lowercase letter.

• S

how full attributes and operations when needed and sup

press them

in othe

r contexts o

r reference

s.

– 21 – 2014-02-05 – Sreading –

57

/74

Rea

ding

theSta

nd

ardC

ont’d

52 U

ML S

uperstructure Specification, v2.1.2

Fig

ure 7.29 - C

lass no

tation

: attribu

tes and

op

eration

s gro

up

ed acco

rdin

g to

visibility

7.3.8 C

lassifier (from

Kern

el, Dep

end

encies, P

ow

erTyp

es)

A cla

ssifier is a

classificatio

n o

f insta

nces, it d

escrib

es a

set of insta

nce

s tha

t ha

ve fe

atu

res in

com

mo

n.

Gen

eralization

s

• “N

amespace (fro

m K

ern

el)” on page 99

• “R

edefinableElem

ent (from Kernel)” on page 1

30

• “T

ype (from K

ernel)” on page 135

Descrip

tion

A classifie

r is a na

mespa

ce w

ho

se m

embe

rs can in

clud

e featu

res. Cla

ssifier is an abstract metaclass.

A cla

ssifier is a

type

an

d ca

n o

wn

ge

ne

raliza

tion

s, the

reb

y ma

king it po

ssible

to de

fine

ge

ne

raliza

tion

rela

tion

ship

s to

oth

er classifiers. A

classifier can

specify a

gen

era

lizatio

n h

iera

rchy b

y refe

ren

cing

its ge

ne

ral cla

ssifiers.

A cla

ssifier is a

rede

fina

ble e

lem

ent, me

aning

tha

t it is po

ssible to

red

efine n

este

d cla

ssifiers.

Attrib

utes

•isA

bstra

ct: Bo

ole

an

�

If true, the C

lassifier does not provid

e a

com

ple

te d

ecla

ratio

n a

nd

can

typically not be instantiated. A

n abstract�

classifier is intended to be used by oth

er classifie

rs (e.g

., as the

targe

t of general m

etarelationships or generalization�

relationships). Default value is false.

Asso

ciation

s

•/attribute: P

roperty [*]�

Refers to all of the P

roperties that are direct (i.e., n

ot inherited or imported) attributes of the classifier. S

ubsets�

Classifie

r::fea

ture and is a derived union.

•/ feature : F

eature [*]�

Sp

ecifie

s each

featu

re d

efin

ed

in th

e classifie

r. Subsets Na

me

spa

ce::m

em

be

r. T

his is a

de

rived

union

.

•/ general : C

lassifier[*]�

Sp

ecifie

s the

ge

ne

ral C

las

sifiers for this Classifier. T

his is derived.

Win

do

w

public size: A

rea = (100, 100) defaultS

ize: Rectangle

protected visibility: B

oolean = true

private xW

in: XW

indowpublic display() hide()private attachX

(xWin: X

Window

)

UM

L Superstructure S

pecification, v2.1.2 53

•generalization: G

eneralization[*]�

Specifies the G

eneralization relationships for this Classifier. T

hese Generalizat

ions navigate to more general�

classifiers in the generalization hierarchy. Su

bse

ts Ele

me

nt::o

wned

Ele

me

nt

•/ inheritedM

ember: N

amedE

lement[*]

�

Specifies all elem

ents inherited by this classifier from the general classifiers.

Su

bse

ts Na

me

spa

ce::m

em

be

r. T

his is�derived.

•redefinedC

lassifier: Classifier

[*]�

References the C

lassifiers that are redefin

ed by this Classifier. S

ubsets Re

definab

leE

lemen

t::rede

fine

dE

lem

ent

Package D

ependencies

•su

bstitution : Substitution

�

References the substitu

tions that are owned by this C

lassifier. Subsets E

lem

en

t::ow

ne

dE

lem

en

t and�

Na

me

dElem

en

t::clien

tDep

en

den

cy.)

Package P

owerTypes

•pow

ertypeExtent : G

eneralizationSet

�

Designates the G

eneralizationSet of w

hich the associated C

lassifier is a power type.

Co

nstrain

ts

[1] T

he

general classifiers are the classifiers referenced by the generalization relationships.

general = self.parents()

[2]G

eneralization hierarchies must be directe

d a

nd

acyclical. A

classifie

r cannot be both a transitively general and

transitively specific classifier of th

e sa

me cla

ssifier.

no

t self.allParents()->

includes(self)

[3]A

classifier may only specialize

classifie

rs of a va

lid typ

e.

self.parents()->forA

ll(c | self.mayS

pecializeType(c))

[4]T

he inheritedMem

ber association is derived by inheriting the inheritable mem

bers of the parents.

self.inheritedMem

ber->includesA

ll(self.inherit(self.parents()->collect(p | p.inheritableM

embers(self)))

Package P

owerTypes

[5]

Th

e C

lassifie

r tha

t map

s to a

Ge

neralizationS

et may neither be a specific nor a general C

lassifier in any of the G

eneralization relationships defined for that GeneralizationS

et. In other words, a power type m

ay not be an instance of itself n

or may its instances also be its subcl

asses.

Ad

ditio

nal O

peratio

ns

[1] T

he

qu

ery allF

ea

ture

s() give

s all o

f the features in the namespace of the classifi

er. In

ge

ne

ral, th

rou

gh

me

cha

nism

s su

ch as

inheritance, this will be a larger set than feature.

Classifier::allF

eatures(): Set(F

eature);allF

eatures = m

ember->

select(oclIsKindO

f(Feature))

[2]T

he

que

ry parents() give

s all o

f the im

med

iate

an

cesto

rs o

f a g

eneralized Classifier.

Classifier::parents(): S

et(Classifier);

parents = generalization.general�

��

54 U

ML S

uperstructure Specification, v2.1.2

[3]

Th

e q

ue

ry allP

are

nts() g

ives a

ll of the direct and indirect ancestors of a generalized Classifier.

Classifier::allP

arents(): Set(C

lassifier);

allParents =

self.parents()->union(self.parents()->

collect(p | p.allParents())

[4]

The query inheritableM

embers() gives all o

f the

me

mb

ers of a

classifie

r tha

t ma

y be inherited in one of its descendants, subject to w

hatever visibility restrictions apply.

Classifier::inheritableM

embers(c: C

lassifier): Set(N

amedE

lement);

pre: c.allP

arents()->includes(self)

inheritableMem

bers = m

ember->

select(m | c.hasV

isibilityOf(m

))

[5]

The query hasVisibilityO

f() determines w

heth

er a n

am

ed e

lem

en

t is visible

in the

classifier. By default all are visible. It is

only called when the argum

ent is something ow

ned by a parent.

Classifier::hasVisibilityO

f(n: Nam

edElem

ent) : Boolean;

pre: self.allP

arents()->collect(c | c.m

ember)->

includes(n)

if (self.inheritedMem

ber->includes(n)) th

en�

hasV

isibilityO

f = (n.visib

ility <> #private)

�

else

hasVisibilityO

f = tru

e

[6]T

he que

ry confo

rmsTo() gives true for a

classifier that defines a type that conform

s to another. This is used, for exam

ple, in the specification of signature conform

ance for operations.

Classifier::conform

sTo(other: Classifier): B

oolean;

conformsTo =

(self=other) or (self.allP

arents()->includes(other))

[7]

The query inherit() defin

es how

to inherit a set of elements. H

ere the operation is defined to inherit them all. It is intended

to be redefined in circumstances

where inheritance is affected by redefinition.

Classifier::inherit(inhs: S

et(Nam

edElem

ent)): Set(N

amedE

lement);

inherit = inhs

[8]

The query mayS

pecializeType() determines w

hether this classifier may have a generalization relationship to classifiers of

the specified type. By default a classifier

may specialize classifiers of the sam

e or a more general type. It is intended to be

redefin

ed b

y classifie

rs that have

diffe

ren

t spe

cializa

tion

con

strain

ts.

Classifier::m

aySpecializeType(c : C

lassifier) : Boolean;

mayS

pecializeType = self.oclIsK

indOf(c.oclType)

Sem

antics

A cla

ssifier is a

classificatio

n o

f insta

nces acco

rdin

g to

the

ir fea

tures.

A C

lassifie

r ma

y pa

rticipa

te in

ge

ne

raliza

tio

n re

latio

nsh

ips w

ith o

the

r Cla

ssifiers. A

n in

stan

ce o

f a sp

ecific C

lassifie

r is also

an (ind

irect) in

stan

ce of e

ach o

f the

gene

ral Cla

ssifiers. Th

erefo

re, fe

atu

res specifie

d fo

r instance

s of th

e g

ene

ral cla

ssifier a

re imp

licitly spe

cified

for in

stan

ces o

f the

spe

cific cla

ssifier. A

ny con

strain

t ap

plyin

g to

insta

nce

s of

the

g

en

era

l classifie

r also

ap

plie

s to in

stan

ces o

f the

spe

cific classifie

r.

Th

e sp

ecific se

mantics o

f ho

w g

en

era

lization

affe

cts ea

ch co

ncre

te su

btyp

e o

f C

lassifier va

ries. All in

stan

ces of a

classifie

r ha

ve va

lues co

rresp

on

din

g to

the

classifie

r’s a

ttribu

tes.

A C

lassifie

r de

fines a typ

e. Typ

e co

nfo

rman

ce b

etw

ee

n g

en

era

lizab

le

Cla

ssifiers is defin

ed

so tha

t a Cla

ssifier con

form

s to

itself a

nd

to a

ll of its a

nce

stors in

the

gene

raliza

tion

hiera

rchy.

UM

L Superstructure S

pecification, v2.1.2 55

Package P

owerTypes

Th

e n

otion

of p

ow

er typ

e w

as in

spire

d

by th

e n

otio

n o

f po

we

r set. A p

owe

r set is defin

ed

as a set w

hose

instance

s are

su

bse

ts. In e

ssence

, the

n, a p

owe

r type

is a class w

ho

se instances a

re subclasse

s. Th

e po

we

rtype

Exte

nt a

ssocia

tion

rela

tes

a C

lassifie

r with

a se

t of g

en

era

lizatio

ns tha

t a) h

ave

a co

mmon sp

ecific C

lassifie

r, and

b) rep

rese

nt a

colle

ction

of su

bse

ts fo

r tha

t class.

Sem

antic V

ariation

Po

ints

Th

e p

recise

lifecycle

sem

an

tics of

ag

gre

ga

tion

is a se

mantic va

riatio

n p

oin

t.

No

tation

Cla

ssifier is a

n a

bstra

ct mo

de

l e

lem

en

t, and

so p

rop

erly sp

ea

kin

g h

as n

o n

ota

tion

. It is ne

verthe

less co

nve

nie

nt

to d

efin

e

in o

ne

pla

ce a

de

fau

lt no

ta

tion

ava

ilab

le for a

ny co

ncre

te su

bclass o

f Cla

ssifier for w

hich

this n

ota

tion

is suita

ble

. Th

e

de

fau

lt no

tatio

n fo

r a cla

ssifier is a

solid

-ou

tline

recta

ng

le

con

tain

ing

the

classifie

r’s n

am

e, a

nd

op

tionally w

ith

com

pa

rtme

nts se

pa

rate

d b

y ho

rizon

tal lin

es co

nta

inin

g fe

atu

res o

r o

ther m

emb

ers of th

e classifier. T

he

specific typ

e of

classifie

r can

be

sho

wn

in g

uille

me

ts a

bo

ve th

e n

am

e. S

ome sp

ecia

lizatio

ns o

f Cla

ssifie

r ha

ve the

ir ow

n d

istinct n

ota

tions.

Th

e n

am

e o

f an

ab

stract C

lassifie

r is sho

wn

in ita

lics.

An a

ttribu

te ca

n b

e sh

ow

n a

s a te

xt string

. Th

e fo

rma

t of th

is strin

g is spe

cified

in th

e N

ota

tion

sub

clau

se o

f “Pro

pe

rty (fro

m K

ern

el, A

ssocia

tion

Cla

sses)” o

n p

ag

e

12

3.

Presen

tation

Op

tion

s

An

y com

pa

rtme

nt m

ay b

e su

ppresse

d. A

sep

ara

tor lin

e is n

ot d

raw

n fo

r a su

pp

resse

d co

mp

artm

en

t. If a co

mpa

rtme

nt is

sup

pre

ssed

, no in

fere

nce

can

be

d

raw

n a

bo

ut th

e p

rese

nce

o

r ab

sen

ce o

f ele

ments in

it. Co

mp

artm

en

t na

mes can

be

use

d

to rem

ove

am

big

uity, if n

ece

ssary.

An a

bstra

ct Cla

ssifier ca

n b

e sh

ow

n

usin

g th

e ke

ywo

rd {a

bstra

ct} afte

r or b

elo

w th

e n

am

e o

f the

Cla

ssifier

.

Th

e typ

e, visibility

, de

fau

lt, mu

ltiplicity, p

rop

erty strin

g m

ay b

e

suppresse

d fro

m b

eing d

ispla

yed

, eve

n if th

ere

are

va

lue

s in

the

mo

de

l.

Th

e ind

ividu

al p

rop

ertie

s of a

n a

ttribu

te ca

n b

e sh

ow

n in co

lum

ns ra

the

r tha

n as a co

ntin

uous strin

g.

Style G

uid

elines

• A

ttribute names typically begin w

ith a low

ercase letter. Multi-w

ord names are often formed by concatenating the words

an

d u

sing

lowercase for all letters except

for up

casin

g th

e first le

tter o

f ea

ch w

ord

bu

t the first.

• C

enter the name of the classifier in boldface.

• C

enter keyword (including stereotype nam

es) in plain face within guillem

ets above the classifier name.

• F

or those languages that distinguish between uppercase and lo

we

rcase

cha

racte

rs, ca

pitalize names (i.e, begin them

w

ith an uppercase character).

• Left justify attributes and operations in plain face.

• B

eg

in a

ttribu

te an

d o

pe

ratio

n na

me

s with

a low

ercase letter.

• S

how full attributes and operations when needed and sup

press them

in othe

r contexts o

r reference

s.

56 U

ML S

uperstructure Specification, v2.1.2

Exam

ples

Fig

ure 7.30 - E

xamp

les of attrib

utes

Th

e a

ttribu

tes in

Fig

ure

7.3

0 a

re e

xpla

ine

d b

elo

w.

• C

lassA::nam

e is an attribute with type String.

• C

lassA::shape is an attribute w

ith type Rectangle.

• C

lassA::size is a public attribute of type Integer w

ith multiplicity 0..1.

• C

lassA::area is a derived attribute w

ith type Integer. It is marked as read-only.

• C

lassA::height is an attribute of type Integer w

ith a default initial value of 5.

• C

lassA::w

idth is an attribute of type Integer.

• C

lassB::id is an attribute that redefin

es ClassA

::name.

• C

lassB::shape is an attribute that redefines C

lassA::shape. It has type S

quare, a specialization of Rectangle.

• C

lassB::height is an attribute that redefines ClassA

::height. It has a default of 7 for ClassB in

stan

ces th

at o

verrid

es th

e

ClassA

default of 5.

• C

lassB::w

idth is a derived attribute that redefines ClassA

::w

idth, w

hich is not derived.

An

attrib

ute

ma

y also

be

sho

wn

usin

g a

ssocia

tion n

otatio

n, w

ith n

o a

do

rnm

en

ts at th

e ta

il o

f the

arro

w a

s sho

wn

in F

igu

re

7.3

1.

Fig

ure 7.31 - A

ssociatio

n-like n

otatio

n fo

r attribu

te

ClassB

id {redefines name}

shape: Square

height = 7

/ width

ClassA

name: S

tringshape: R

ectangle+ size: Integer [0..1]/ area: Integer {readO

nly}height: Integer=

5w

idth: Integer

Window

Area

size

1W

indowA

reasize

1

– 21 – 2014-02-05 – Sreading –

57

/74

Rea

ding

theSta

nd

ardC

ont’d

52 U

ML S

uperstructure Specification, v2.1.2

Fig

ure 7.29 - C

lass no

tation

: attribu

tes and

op

eration

s gro

up

ed acco

rdin

g to

visibility

7.3.8 C

lassifier (from

Kern

el, Dep

end

encies, P

ow

erTyp

es)

A cla

ssifier is a

classificatio

n o

f insta

nces, it d

escrib

es a

set of insta

nce

s tha

t ha

ve fe

atu

res in

com

mo

n.

Gen

eralization

s

• “N

amespace (fro

m K

ern

el)” on page 99

• “R

edefinableElem

ent (from Kernel)” on page 1

30

• “T

ype (from K

ernel)” on page 135

Descrip

tion

A classifie

r is a na

mespa

ce w

ho

se m

embe

rs can in

clud

e featu

res. Cla

ssifier is an abstract metaclass.

A cla

ssifier is a

type

an

d ca

n o

wn

ge

ne

raliza

tion

s, the

reb

y ma

king it po

ssible

to de

fine

ge

ne

raliza

tion

rela

tion

ship

s to

oth

er classifiers. A

classifier can

specify a

gen

era

lizatio

n h

iera

rchy b

y refe

ren

cing

its ge

ne

ral cla

ssifiers.

A cla

ssifier is a

rede

fina

ble e

lem

ent, me

aning

tha

t it is po

ssible to

red

efine n

este

d cla

ssifiers.

Attrib

utes

•isA

bstra

ct: Bo

ole

an

�

If true, the C

lassifier does not provid

e a

com

ple

te d

ecla

ratio

n a

nd

can

typically not be instantiated. A

n abstract�

classifier is intended to be used by oth

er classifie

rs (e.g

., as the

targe

t of general m

etarelationships or generalization�

relationships). Default value is false.

Asso

ciation

s

•/attribute: P

roperty [*]�

Refers to all of the P

roperties that are direct (i.e., n

ot inherited or imported) attributes of the classifier. S

ubsets�

Classifie

r::fea

ture and is a derived union.

•/ feature : F

eature [*]�

Sp

ecifie

s each

featu

re d

efin

ed

in th

e classifie

r. Subsets Na

me

spa

ce::m

em

be

r. T

his is a

de

rived

union

.

•/ general : C

lassifier[*]�

Sp

ecifie

s the

ge

ne

ral C

las

sifiers for this Classifier. T

his is derived.

Win

do

w

public size: A

rea = (100, 100) defaultS

ize: Rectangle

protected visibility: B

oolean = true

private xW

in: XW

indowpublic display() hide()private attachX

(xWin: X

Window

)

UM

L Superstructure S

pecification, v2.1.2 53

•generalization: G

eneralization[*]�

Specifies the G

eneralization relationships for this Classifier. T

hese Generalizat

ions navigate to more general�

classifiers in the generalization hierarchy. Su

bse

ts Ele

me

nt::o

wned

Ele

me

nt

•/ inheritedM

ember: N

amedE

lement[*]

�

Specifies all elem

ents inherited by this classifier from the general classifiers.

Su

bsets N

am

esp

ace

::me

mb

er

. This is�

derived.

•redefinedC

lassifier: Classifier

[*]�

References the C

lassifiers that are redefin

ed by this Classifier. S

ubsets Re

definab

leE

lemen

t::rede

fine

dE

lem

ent

Package D

ependencies

•su

bstitution : Substitution

�

References the substitu

tions that are owned by this C

lassifier. Subsets E

lem

en

t::ow

ne

dE

lem

en

t and�

Na

me

dElem

en

t::clien

tDep

en

den

cy.)

Package P

owerTypes

•pow

ertypeExtent : G

eneralizationSet

�

Designates the G

eneralizationSet of w

hich the associated C

lassifier is a power type.

Co

nstrain

ts

[1] Th

e g

eneral classifiers are the classifiers referenced by the generalization relationships.

general = self.parents()

[2]G

eneralization hierarchies must be directe

d a

nd

acyclical. A

classifie

r cannot be both a transitively general and

transitively specific classifier of th

e sa

me cla

ssifier.

no

t self.allParents()->

includes(self)

[3]A

classifier may only specialize

classifie

rs of a va

lid typ

e.

self.parents()->forA

ll(c | self.mayS

pecializeType(c))

[4]T

he inheritedMem

ber association is derived by inheriting the inheritable mem

bers of the parents.

self.inheritedMem

ber->includesA

ll(self.inherit(self.parents()->collect(p | p.inheritableM

embers(self)))

Package P

owerTypes

[5]

Th

e C

lassifie

r tha

t map

s to a

Ge

neralizationS

et may neither be a specific nor a general C

lassifier in any of the G

eneralization relationships defined for that GeneralizationS

et. In other words, a power type m

ay not be an instance of itself n

or may its instances also be its subcl

asses.

Ad

ditio

nal O

peratio

ns

[1] T

he

qu

ery allF

ea

ture

s() give

s all o

f the features in the namespace of the classifi

er. In

ge

ne

ral, th

rou

gh

me

cha

nism

s su

ch as

inheritance, this will be a larger set than feature.

Classifier::allF

eatures(): Set(F

eature);allF

eatures = m

ember->

select(oclIsKindO

f(Feature))

[2]T

he

que

ry parents() give

s all o

f the im

med

iate

an

cesto

rs o

f a g

eneralized Classifier.

Classifier::parents(): S

et(Classifier);

parents = generalization.general�

��

54 U

ML S

uperstructure Specification, v2.1.2

[3]

Th

e q

ue

ry allP

are

nts() g

ives a

ll of the direct and indirect ancestors of a generalized Classifier.

Classifier::allP

arents(): Set(C

lassifier);

allParents =

self.parents()->union(self.parents()->

collect(p | p.allParents())

[4]

The query inheritableM

embers() gives all o

f the

me

mb

ers of a

classifie

r tha

t ma

y be inherited in one of its descendants, subject to w

hatever visibility restrictions apply.

Classifier::inheritableM

embers(c: C

lassifier): Set(N

amedE

lement);

pre: c.allP

arents()->includes(self)

inheritableMem

bers = m

ember->

select(m | c.hasV

isibilityOf(m

))

[5]

The query hasVisibilityO

f() determines w

heth

er a n

am

ed e

lem

en

t is visible

in the

classifier. By default all are visible. It is

only called when the argum

ent is something ow

ned by a parent.

Classifier::hasVisibilityO

f(n: Nam

edElem

ent) : Boolean;

pre: self.allP

arents()->collect(c | c.m

ember)->

includes(n)

if (self.inheritedMem

ber->includes(n)) th

en�

hasV

isibilityO

f = (n.visib

ility <> #private)

�

else

hasVisibilityO

f = tru

e

[6]T

he que

ry confo

rmsTo() gives true for a

classifier that defines a type that conform

s to another. This is used, for exam

ple, in the specification of signature conform

ance for operations.

Classifier::conform

sTo(other: Classifier): B

oolean;

conformsTo =

(self=other) or (self.allP

arents()->includes(other))

[7]

The query inherit() defin

es how

to inherit a set of elements. H

ere the operation is defined to inherit them all. It is intended

to be redefined in circumstances

where inheritance is affected by redefinition.

Classifier::inherit(inhs: S

et(Nam

edElem

ent)): Set(N

amedE

lement);

inherit = inhs

[8]

The query mayS

pecializeType() determines w

hether this classifier may have a generalization relationship to classifiers of

the specified type. By default a classifier

may specialize classifiers of the sam

e or a more general type. It is intended to be

redefin

ed b

y classifie

rs that have

diffe

ren

t spe

cializa

tion

con

strain

ts.

Classifier::m

aySpecializeType(c : C

lassifier) : Boolean;

mayS

pecializeType = self.oclIsK

indOf(c.oclType)

Sem

antics

A cla

ssifier is a

classificatio

n o

f insta

nces acco

rdin

g to

the

ir fea

tures.

A C

lassifie

r ma

y pa

rticipa

te in

ge

ne

raliza

tio

n re

latio

nsh

ips w

ith o

the

r Cla

ssifiers. A

n in

stan

ce o

f a sp

ecific C

lassifie

r is also

an (ind

irect) in

stan

ce of e

ach o

f the

gene

ral Cla

ssifiers. Th

erefo

re, fe

atu

res specifie

d fo

r instance

s of th

e g

ene

ral cla

ssifier a

re imp

licitly spe

cified

for in

stan

ces o

f the

spe

cific cla

ssifier. A

ny con

strain

t ap

plyin

g to

insta

nce

s of

the

g

en

era

l classifie

r also

ap

plie

s to in

stan

ces o

f the

spe

cific classifie

r.

Th

e sp

ecific se

mantics o

f ho

w g

en

era

lization

affe

cts ea

ch co

ncre

te su

btyp

e o

f C

lassifier va

ries. All in

stan

ces of a

classifie

r ha

ve va

lues co

rresp

on

din

g to

the

classifie

r’s a

ttribu

tes.

A C

lassifie

r de

fines a typ

e. Typ

e co

nfo

rman

ce b

etw

ee

n g

en

era

lizab

le

Cla

ssifiers is defin

ed

so tha

t a Cla

ssifier con

form

s to

itself a

nd

to a

ll of its a

nce

stors in

the

gene

raliza

tion

hiera

rchy.

UM

L Superstructure S

pecification, v2.1.2 55

Package P

owerTypes

Th

e n

otion

of p

ow

er typ

e w

as in

spire

d

by th

e n

otio

n o

f po

we

r set. A p

owe

r set is defin

ed

as a set w

hose

instance

s are

su

bse

ts. In e

ssence

, the

n, a p

owe

r type

is a class w

ho

se instances a

re subclasse

s. Th

e po

we

rtype

Exte

nt a

ssocia

tion

rela

tes

a C

lassifie

r with

a se

t of g

en

era

lizatio

ns tha

t a) h

ave

a co

mmon sp

ecific C

lassifie

r, and

b) rep

rese

nt a

colle

ction

of su

bse

ts fo

r tha

t class.

Sem

antic V

ariation

Po

ints

Th

e p

recise

lifecycle

sem

an

tics of

ag

gre

ga

tion

is a se

mantic va

riatio

n p

oin

t.

No

tation

Cla

ssifier is a

n a

bstra

ct mo

de

l e

lem

en

t, and

so p

rop

erly sp

ea

kin

g h

as n

o n

ota

tion

. It is ne

verthe

less co

nve

nie

nt

to d

efin

e

in o

ne

pla

ce a

de

fau

lt no

ta

tion

ava

ilab

le for a

ny co

ncre

te su

bclass o

f Cla

ssifier for w

hich

this n

ota

tion

is suita

ble

. Th

e

de

fau

lt no

tatio

n fo

r a cla

ssifier is a

solid

-ou

tline

recta

ng

le

con

tain

ing

the

classifie

r’s n

am

e, a

nd

op

tionally w

ith

com

pa

rtme

nts se

pa

rate

d b

y ho

rizon

tal lin

es co

nta

inin

g fe

atu

res o

r o

ther m

emb

ers of th

e classifier. T

he

specific typ

e of

classifie

r can

be

sho

wn

in g

uille

me

ts a

bo

ve th

e n

am

e. S

ome sp

ecia

lizatio

ns o

f Cla

ssifie

r ha

ve the

ir ow

n d

istinct n

ota

tions.

Th

e n

am

e o

f an

ab

stract C

lassifie

r is sho

wn

in ita

lics.

An a

ttribu

te ca

n b

e sh

ow

n a

s a te

xt string

. Th

e fo

rma

t of th

is strin

g is spe

cified

in th

e N

ota

tion

sub

clau

se o

f “Pro

pe

rty (fro

m K

ern

el, A

ssocia

tion

Cla

sses)” o

n p

ag

e

12

3.

Presen

tation

Op

tion

s

An

y com

pa

rtme

nt m

ay b

e su

ppresse

d. A

sep

ara

tor lin

e is n

ot d

raw

n fo

r a su

pp

resse

d co

mp

artm

en

t. If a co

mpa

rtme

nt is

sup

pre

ssed

, no in

fere

nce

can

be

d

raw

n a

bo

ut th

e p

rese

nce

o

r ab

sen

ce o

f ele

ments in

it. Co

mp

artm

en

t na

mes can

be

use

d

to rem

ove

am

big

uity, if n

ece

ssary.

An a

bstra

ct Cla

ssifier ca

n b

e sh

ow

n

usin

g th

e ke

ywo

rd {a

bstra

ct} afte

r or b

elo

w th

e n

am

e o

f the

Cla

ssifier

.

Th

e typ

e, visibility

, de

fau

lt, mu

ltiplicity, p

rop

erty strin

g m

ay b

e

suppresse

d fro

m b

eing d

ispla

yed

, eve

n if th

ere

are

va

lue

s in

the

mo

de

l.

Th

e ind

ividu

al p

rop

ertie

s of a

n a

ttribu

te ca

n b

e sh

ow

n in co

lum

ns ra

the

r tha

n as a co

ntin

uous strin

g.

Style G

uid

elines

• A

ttribute names typically begin w

ith a low

ercase letter. Multi-w

ord names are often formed by concatenating the words

an

d u

sing

lowercase for all letters except

for up

casin

g th

e first le

tter o

f ea

ch w

ord

bu

t the first.

• C

enter the name of the classifier in boldface.

• C

enter keyword (including stereotype nam

es) in plain face within guillem

ets above the classifier name.

• F

or those languages that distinguish between uppercase and lo

we

rcase

cha

racte

rs, ca

pitalize names (i.e, begin them

w

ith an uppercase character).

• Left justify attributes and operations in plain face.

• B

eg

in a

ttribu

te an

d operation nam

es with a low

ercase letter.

• S

how full attributes and operations when needed and sup

press them

in othe

r contexts o

r reference

s.

56 U

ML S

uperstructure Specification, v2.1.2

Exam

ples

Fig

ure 7.30 - E

xamp

les of attrib

utes

Th

e a

ttribu

tes in

Fig

ure

7.3

0 a

re e

xpla

ine

d b

elo

w.

• C

lassA::nam

e is an attribute with type String.

• C

lassA::shape is an attribute w

ith type Rectangle.

• C

lassA::size is a public attribute of type Integer w

ith multiplicity 0..1.

• C

lassA::area is a derived attribute w

ith type Integer. It is marked as read-only.

• C

lassA::height is an attribute of type Integer w

ith a default initial value of 5.

• C

lassA::w

idth is an attribute of type Integer.

• C

lassB::id is an attribute that redefin

es ClassA

::name.

• C

lassB::shape is an attribute that redefines C

lassA::shape. It has type S

quare, a specialization of Rectangle.

• C

lassB::height is an attribute that redefines ClassA

::height. It has a default of 7 for ClassB in

stan

ces th

at o

verrid

es th

e

ClassA

default of 5.

• C

lassB::w

idth is a derived attribute that redefines ClassA

::w

idth, w

hich is not derived.

An

attrib

ute

ma

y also

be

sho

wn

usin

g a

ssocia

tion n

otatio

n, w

ith n

o a

do

rnm

en

ts at th

e ta

il o

f the

arro

w a

s sho

wn

in F

igu

re

7.3

1.

Fig

ure 7.31 - A

ssociatio

n-like n

otatio

n fo

r attribu

te

ClassB

id {redefines name}

shape: Square

height = 7

/ width

ClassA

name: S

tringshape: R

ectangle+ size: Integer [0..1]/ area: Integer {readO

nly}height: Integer=

5w

idth: Integer

Window

Area

size

1W

indowA

reasize

1

UM

L Superstructure S

pecification, v2.1.2 57

Package P

owerTypes

Fo

r exa

mp

le, a

Ba

nk A

ccou

nt Typ

e cla

ssifier co

uld

ha

ve a

po

wertype

asso

ciation

with

a G

en

era

lizatio

nS

et. T

his

Ge

ne

raliza

tion

Se

t cou

ld th

en

asso

ciate

with

tw

o G

en

eraliza

tions w

here

the

class (i.e

., ge

ne

ral Cla

ssifier) Ban

k Acco

un

t h

as tw

o sp

ecific su

bclasse

s (i.e., Classifie

rs): Ch

ecking

Acco

un

t an

d S

avin

gs A

ccou

nt. C

he

cking

Acco

un

t an

d S

avin

gs

Acco

un

t, the

n, a

re in

stan

ces o

f the

po

we

r type

: Ba

nk A

cco

un

t Type

. In o

the

r wo

rds, C

he

cking

Accou

nt a

nd

Sa

ving

s A

ccou

nt a

re bo

th: in

stan

ces of B

an

k Acco

un

t Type

, as w

ell a

s sub

classes o

f Ba

nk A

ccou

nt. (F

or m

ore

ex

pla

na

tion a

nd

exa

mp

les, see

Exa

mp

les in

the

Gen

era

lizatio

nS

et sub

clause, belo

w.)

7.3.9 C

om

men

t (from

Kern

el)

A co

mm

en

t is a te

xtua

l an

no

tatio

n th

at can

be

atta

che

d to

a se

t of e

lem

en

ts.

Gen

eralization

s

• “E

lement (from

Kernel)” on page 64.

Descrip

tion

A co

mm

en

t give

s the

ab

ility to

atta

ch va

riou

s rem

arks to

ele

me

nts. A

com

me

nt ca

rries no se

mantic fo

rce, bu

t ma

y conta

in

inform

atio

n tha

t is use

ful to a

mo

de

ler.

A co

mm

en

t can

be

ow

ne

d b

y an

y ele

me

nt.

Attrib

utes

•m

ultiplicitybody: String [0..1]�

Specifies a string that is the com

ment.

Asso

ciation

s

•annotatedE

lement: Elem

ent[*]�

References the E

lement(s)

being comm

ented.

Co

nstrain

ts

No a

dd

ition

al co

nstra

ints

Sem

antics

A C

om

me

nt a

dd

s no

sem

an

tics to th

e a

nn

ota

ted

ele

me

nts, b

ut m

ay re

pre

sen

t info

rmatio

n u

sefu

l to th

e re

ad

er o

f the

m

od

el.

No

tation

A C

om

me

nt is sh

ow

n a

s a re

ctan

gl

e w

ith th

e u

pp

er rig

ht corn

er b

ent (th

is is also kn

ow

n a

s a “no

te sym

bo

l”). Th

e re

ctan

gle co

nta

ins the b

od

y of th

e Co

mm

en

t. Th

e co

nn

ectio

n to ea

ch a

nnota

ted

ele

me

nt is sh

ow

n b

y a se

pa

rate

da

she

d

line

.

Presen

tation

Op

tion

s

Th

e d

ashe

d lin

e co

nn

ectin

g th

e n

ote

to the

an

nota

ted

ele

me

nt(s) m

ay be

sup

pre

ssed

if it is clea

r from th

e co

nte

xt, or n

ot

imp

orta

nt in

this d

iag

ram

.

– 21 – 2014-02-05 – Sreading –

57

/74

Meta

Obje

ctFacility(M

OF

)

– 21 – 2014-02-05 – main –

58

/74

Open

Questio

ns...

•N

owyou

’vebeen

“tric

ked”

again.

Tw

ice.

•W

edid

n’t

tellw

hat

the

modellin

gla

nguage

form

eta-modellin

gis.

•W

edid

n’t

tellw

hat

the

is-insta

nce-o

frelation

ofth

islan

guage

is.

•Id

ea:

have

am

inim

alobje

ct-o

riente

dcore

comprisin

gth

enotion

sof

cla

ss,asso

cia

tion,in

herita

nce,etc

.w

ith“self-exp

lainin

g”sem

antics.

•T

his

isM

eta

Obje

ct

Facility

(MO

F),

which

(more

orless)

coincid

esw

ithU

ML

Infrastru

cture

[OM

G,2007a].

•So:

thin

gson

meta

level

•M

0are

object

diagram

s/systemstates

•M

1are

word

softh

ela

nguage

UM

L

•M

2are

word

softh

ela

nguage

MO

F

•M

3are

word

softh

ela

nguage

...

– 21 – 2014-02-05 – Smof –

59

/74

MO

FSem

antics

•O

ne

approach

:

•Treat

itw

ithour

signatu

re-b

ase

dth

eory

•T

his

is(in

effect)

the

right

direction

,but

may

require

new

(orexten

ded

)sign

atures

foreach

level.(F

orin

stance,

MO

Fdoesn

’thave

anotio

nofSig

nal,

our

signatu

rehas.)

•O

ther

approach

:

•D

efine

ageneric,

gra

ph

base

d“is-in

stance-of”

relation.

•O

bject

diagram

s(th

atare

graphs)

then

are

the

systemstates

—not

only

gra

phic

alre

pre

senta

tions

ofsystem

states.

•If

this

works

out,

good:

We

caneasily

experim

ent

with

diff

erent

langu

agedesign

s,e.g.

diff

erent

flavou

rsof

UM

Lth

atim

med

iatelyhave

asem

antics.

•M

ostin

teresting:

alsodo

generic

defi

nition

ofbeh

aviour

with

ina

closedm

odellin

gsettin

g,but

this

isclearly

stillresearch

,e.g.

[Busch

ermoh

lean

dO

elerink,

2008]

– 21 – 2014-02-05 – Smof –

60

/74

Meta-M

odellin

g:(A

nticipated)

Benefits

– 21 – 2014-02-05 – main –

61

/74

Benefits:

Overview

•W

e’ll(su

perfi

cially)lo

okat

three

aspects:

•B

enefi

tsfor

Modellin

gTools.

•B

enefi

tsfor

Language

Desig

n.

•B

enefi

tsfor

Code

Genera

tion

and

MD

A.

– 21 – 2014-02-05 – Sbenefits –

62

/74

Benefits

forM

odellin

gTo

ols

•T

he

meta-m

odel

MU

ofU

ML

imm

edia

tely

provides

adata

-structu

re

representation

forth

eab

stractsyn

tax(∼

forou

rsign

atures).

Ifwe

have

code

generation

forU

ML

models,

e.g.in

toJava,

then

we

canim

med

iatelyrepresen

tU

ML

models

inm

em

ory

forJava.

(Becau

seeach

MO

Fm

odel

isin

particu

lara

UM

Lm

odel.)

•T

here

existto

olsan

dlibraries

calledM

OF-re

posito

ries,

which

cangen

ericallyrepresen

tin

stances

ofM

OF

instan

ces(in

particu

larU

ML

models).

And

which

canoften

generate

specifi

cco

de

tom

anip

ulate

instan

cesof

MO

Fin

stances

interm

sof

the

MO

Fin

stance.

– 21 – 2014-02-05 – Sbenefits –

63

/74

Benefits

forM

odellin

gTo

olsC

ont’d

•A

nd

not

only

inm

em

ory,

ifwe

canrepresen

tM

OF

instan

cesin

files,

we

obtain

acan

onical

representation

ofU

ML

models

infile

s,e.g.

inX

ML.

→X

ML

Metad

ataIn

terchan

ge(X

MI)

•N

ote

:A

priori,th

ereis

no

graphical

inform

ationin

XM

I(it

ison

lyab

stractsyn

taxlike

our

signatu

res)→

OM

GD

iagramIn

terchan

ge.

•N

ote

:T

here

aresligh

tam

bigu

itiesin

the

XM

Istan

dard

.

And

diff

erent

tools

by

diff

erent

vendors

often

seemto

lieat

opposite

ends

on

the

scaleofin

terpretatio

n.

Which

issu

relya

coin

ciden

ce.

Inso

me

cases,it’s

possib

leto

fix

thin

gs

with

,e.g

.,X

SLT

scripts,

but

full

vendor

indep

enden

ceis

today

not

given

.

Plu

sX

MIco

mpatib

ilitydoesn

’tnecessarily

referto

Diag

ramIn

terchan

ge.

•To

re-ite

rate

:th

isis

generic

for

all

MO

F-b

asedm

odellin

glan

guages

such

asU

ML,CW

M,etc.

And

alsofor

Dom

ain

Specifi

cLanguages

which

don

’teven

exityet.

– 21 – 2014-02-05 – Sbenefits –

64

/74

Benefits:

Overview

•W

e’ll(su

perfi

cially)lo

okat

three

aspects:

•B

enefi

tsfor

Modellin

gTools.

✔

•B

enefi

tsfor

Language

Desig

n.

•B

enefi

tsfor

Code

Genera

tion

and

MD

A.

– 21 – 2014-02-05 – Sbenefits –

65

/74

Benefits

forL

an

gu

ageD

esign

•Recall:

we

saidth

atco

de-gen

eratorsare

possib

le“read

ers”of

stereotypes.

•For

example,

(heavily

simplifyin

g)we

could

•in

troduce

the

stereotypes

Butto

n,Toolb

ar,

...

•for

conven

ience,

instru

ctth

em

odellin

gto

olto

use

special

pictu

resfor

stereotypes

—in

the

meta-d

ata(th

eab

stractsyn

tax),th

estereotyp

esare

clearlypresen

t.

•in

struct

the

code-gen

eratorto

autom

aticallyad

din

heritan

cefrom

Gtk::B

utton

,G

tk::Toolb

ar,etc.

corre

spondin

gto

the

stereotype.

Et

voila

:we

canm

odel

Gtk-G

UIs

and

generate

code

forth

em.

•A

noth

erview

:

•U

ML

with

these

stereotyp

esis

anew

modellin

gla

nguage:

Gtk

-UM

L.

•W

hich

liveson

the

same

meta-level

asU

ML

(M2).

•It’s

aD

om

ain

Specifi

cM

odellin

gLanguage

(DSL).

One

mech

anism

todefi

ne

DSLs(b

asedon

UM

L,an

d“w

ithin

”U

ML):

Pro

file

s.

– 21 – 2014-02-05 – Sbenefits –

66

/74

Benefits

forL

an

gu

ageD

esign

Co

nt’d

•For

eachD

SL

defi

ned

bya

Profi

le,we

imm

ediately

have

•in

mem

oryrepresen

tations,

•m

odellin

gto

ols,

•file

representation

s.

•N

ote

:here,

the

sem

antic

sof

the

stereotypes

(and

thus

the

langu

ageof

Gtk-U

ML)lie

sin

the

code-g

enera

tor.

That’s

the

first

“reader”

that

understan

ds

these

special

stereotypes.

(And

that’s

what’s

mean

tin

the

standard

when

they’re

talking

abou

tgivin

gstereotyp

essem

antics).

•O

ne

canalso

impose

addition

alwell-form

edness

rules,

forin

stance

that

certaincom

pon

ents

shall

allim

plem

ent

acertain

interface

(and

thus

have

certainm

ethods

available).

(Cf.

[Stah

lan

dV

olter,2005].)

– 21 – 2014-02-05 – Sbenefits –

67

/74

Benefits

forL

an

gu

ageD

esign

Co

nt’d

•O

ne

stepfu

rther:

•N

obody

hin

ders

us

toob

taina

model

ofU

ML

(written

inM

OF),

•th

rowou

tparts

unnecessary

forou

rpurp

oses,

•ad

d(=

integrate

into

the

existing

hierarch

y)m

oread

equat

new

constru

cts,for

instan

ce,contra

cts

orsom

ethin

gm

oreclose

tohard

ware

asin

terru

pt

orse

nso

ror

driv

er,

•an

dm

aybe

alsostereotyp

es.

→a

new

langu

agestan

din

gnext

toU

ML,CW

M,etc.

•D

rawback:

the

resultin

glan

guage

isnot

necessarily

UM

Lan

ym

ore,so

we

can’t

use

provenU

ML

modellin

gto

ols.

•B

ut

we

canuse

allto

olsfor

MO

F(or

MO

F-like

thin

gs).

For

instan

ce,Eclip

seEM

F/G

MF/G

EF.

– 21 – 2014-02-05 – Sbenefits –

68

/74

Benefits:

Overview

•W

e’ll(su

perfi

cially)lo

okat

three

aspects:

•B

enefi

tsfor

Modellin

gTools.

✔

•B

enefi

tsfor

Language

Desig

n.

✔

•B

enefi

tsfor

Code

Genera

tion

and

MD

A.

– 21 – 2014-02-05 – Sbenefits –

69

/74

Benefits

forM

odel(to

Mo

del)Tra

nsformatio

n

•T

here

arem

anifold

application

sfor

model-to-m

odel

transform

ations:

•For

instan

ce,to

olsu

pport

forre

-facto

rings,

likem

oving

comm

onattrib

utes

upw

ards

the

inheritan

cehierarch

y.

This

cannow

be

defi

ned

asgra

ph-re

writin

gru

leson

the

levelof

MO

F.

The

graph

tobe

rewritten

isth

eU

ML

model

•Sim

ilarly,on

ecou

ldtran

sforma

Gtk

-UM

Lm

odel

into

aU

ML

model,

where

the

inheritan

cefrom

classeslike

Gtk::B

utton

ism

ade

explicit:

The

transform

ationwou

ldad

dth

isclass

Gtk::B

utton

and

the

inheritan

cerelation

and

remove

the

stereotype.

•Sim

ilarly,on

ecou

ldhave

aGU

I-UM

Lm

odel

transform

edin

toa

Gtk

-UM

Lm

odel,

ora

Qt-U

ML

model.

The

former

aPIM

(Platform

Indep

enden

tM

odel),

the

lattera

PSM

(Platform

Specifi

cM

odel)

—cf.

MD

A.

– 21 – 2014-02-05 – Sbenefits –

70

/74

Spe

cialCase:

Co

deG

eneration

•Recall

that

we

saidth

at,e.g.

Javaco

de,

canalso

be

seenas

am

odel.

So

code-gen

erationis

asp

ecia

lcase

ofm

odel-to-m

odel

transform

ation;

only

the

destin

ationlo

oksquite

diff

erent.

•N

ote

:Code

generation

need

n’t

be

asexp

ensive

asbuyin

ga

modellin

gto

olw

ithfu

llfled

gedco

de

generation

.

•If

we

have

the

UM

Lm

odel

(orth

eD

SL

model)

givenas

anX

ML

file,

code

generation

canbe

as

simple

as

anX

SLT

script.

“Can

be”

inth

esen

seof

“T

here

may

be

situatio

nw

here

agra

phica

land

abstra

ct

represen

tatio

nofso

meth

ing

isdesired

which

has

aclear

and

direct

mappin

gto

som

etex

tualrep

resenta

tion.”

Ingen

eral,co

de

generation

can(in

colloquial

terms)

becom

earb

itrarily

diffi

cult .

– 21 – 2014-02-05 – Sbenefits –

71

/74

Exam

ple:M

odela

nd

XM

I

〈〈pt1

00〉〉

Sen

sorA〈〈6

5C

02〉〉

Con

trollerA〈〈N

ET

2270〉〉

Usb

Agath

er

1

update

1

<?xml

version

=’1.0’

encoding

=’UTF-8’

?>

<XMI

xmi.version

=’1.2’

xmlns:UML

=’org.omg.xmi.namespace.UML’

timestamp

=’Mon

Feb

02

18:23:12

CET

2009’>

<XMI.content>

<UML:Model

xmi.id

=’...’>

<UML:Namespace.ownedElement>

<UML:Class

xmi.id

=’...’

name

=’SensorA’>

<UML:ModelElement.stereotype>

<UML:Stereotype

name

=’pt100’/>

</UML:ModelElement.stereotype>

</UML:Class>

<UML:Class

xmi.id

=’...’

name

=’ControllerA’>

<UML:ModelElement.stereotype>

<UML:Stereotype

name

=’65C02’/>

</UML:ModelElement.stereotype>

</UML:Class>

<UML:Class

xmi.id

=’...’

name

=’UsbA’>

<UML:ModelElement.stereotype>

<UML:Stereotype

name

=’NET2270’/>

</UML:ModelElement.stereotype>

</UML:Class>

<UML:Association

xmi.id

=’...’

name

=’in’

>...</UML:Association>

<UML:Association

xmi.id

=’...’

name

=’out’

>...</UML:Association>

</UML:Namespace.ownedElement>

</UML:Model>

</XMI.content>

</XMI>

– 21 – 2014-02-05 – Sbenefits –

72

/74

References

– 21 – 2014-02-05 – main –

73

/74

Refe

rences

[Busch

ermohle

and

Oelerin

k,2008]

Busch

ermohle,

R.and

Oelerin

k,J.(2

008).

Rich

meta

object

facility.

InPro

c.1st

IEEE

Int’l

work

shop

UM

Land

Form

alM

ethods.

[Fisch

erand

Weh

rheim

,2000]

Fisch

er,C.and

Weh

rheim

,H

.(2

000).

Beh

avio

ura

lsu

btyp

ing

relatio

ns

for

object-o

riented

form

alism

s.In

Rus,

T.,

edito

r,A

MA

ST

,num

ber

1816

inLectu

reN

otes

inCom

puter

Scien

ce.Sprin

ger-V

erlag.

[OM

G,2003]

OM

G(2

003).

Um

l2.0

pro

posa

lofth

e2U

gro

up,versio

n0.2

,http://www.2uworks.org/uml2submission.

[OM

G,2007a]

OM

G(2

007a).

Unifi

edm

odelin

gla

nguage:

Infra

structu

re,versio

n2.1

.2.

Tech

nica

lRep

ort

form

al/

07-1

1-0

4.

[OM

G,2007b]

OM

G(2

007b).

Unifi

edm

odelin

gla

nguage:

Superstru

cture,

version

2.1

.2.

Tech

nica

lRep

ort

form

al/

07-1

1-0

2.

[Sta

hland

Volter,

2005]

Sta

hl,

T.and

Volter,

M.(2

005).

Modellg

etrieben

eSoftw

areentw

icklu

ng.

dpunkt.verla

g,H

eidelb

erg.

– 21 – 2014-02-05 – main –

74

/74