DATA MODEL STRUCTURAL

Introducere in Modelul Sistem pentru UML

Modelul sistem este o baza pentru un model semantic al
UML-ului. Modelul sistem formeaza centrul si fundamental
definitiei semanticilor pentru UML. Din acest motiv sistemul de
baza este dirijat spre UML.
1.1.Semanticile oricarui limbaj formal consta din urmatoarele
parti componente :
1. Sintaxa limbajului in discutie ( aici UML), data grafic sau
textual.
2. Domeniul semantic, un domeniu bine cunoscut si inteles,
bazat pe o teorie matematica bine cunoscuta si
3. Aplicatia semantica: o definitie functionala sau
relationala, care relationeaza atit elementele sinaxei, cat
si elementele domeniului semantic.
Principiul de baza al semanticii este aceasta tehnica de
privire a unui limbaj: fiecare constructie sintactica este aplicata
pe o constructie semantica.
In mod normal, multimea elementelor sintactice si domeniul
semantic poseda o anumita structura si aplicatia semantica
pastreaza oportunitatea
sau este compatibila cu
aceasta structura. Matematic, acest aspect este crucial si
predominant compositional.
Termenul de Model al Sistemului a fost folosit prima oara
pentru a descrie domeniul semantic; el defineste o familie de
sisteme, descriind caracteristicile lor structurale si
comportamentale. Fiecare instantiere sintactica concreta ( in
cazul nostru, o diagram UML individuala, sau o parte a sa ) este
interpretata de aplicatia semantica ca un predicat peste multimea
de sisteme definite de modelul sistem.
1

Aplicatia semantica are forma:

Sem: UML( Systemmodel)
si astfel relationeaza functional fiecare item din domeniul sintactic
cu o constructie din domeniul semantic. Semanticile unui model
m UML sunt Sem(m). Modelul Sistem descris in acest raport
identifica multimea tuturor sistemelor OO posibile, care pot fi
definite utilizind o submultime a UML, pe care am numit-o UMLul curatat.
1.2

Structurarea semanticii UML-ului.

In fig.! este descris scopul de baza al unei semantici date a

unui limbaj modelat grafic. Ideea de baza exprimata de aceasta
diagrama este: limbajul grafic plin este relationat cu un limbaj
simplificat prin citeva transformari care ne permit sa scapam de
citeva extensii notationale si concepte derivate, prin reducerea lor
la constructii ale limbajului simplificat.

Fig.1 Strategia generala de definire a semanticii pentru UML 2.0

De fapt, este posibil ca aplicarea semanticii sa nu se ocupe
cu intreg UML in final, ci doar cu o submultime simplificata a UML.
Concret,pentru a ne ocupa cu complexitatea definirii unei
semantici proprii, optam pentru descompunerea aplicatiei Sem:
UML( Systemmodel) in citeva moduri:

- UML-ul intreg este restrictionat la o submultime ( numita UML

curatat ), care poate fi tratata semantic fara constructii
sofisticate.
- UML-ul curatat este aplicat prin transformari in centrul UMLului simplificat.Pentru a face acest lucru, constructiile derivate
ale UML-ului sunt inlocuite prin definitiile lor in termini de
constructii ale centrului.
- In final UML-ul simplificat este aplicat pe modelul sistem
folosind o abordare predicativa.
Asa cum am mentionat mai devreme, modelul sistem descrie
universul
( multimea ) tuturor structurilor semantice posibile ( fiecare cu
comportarea sa)
Aplicarea semanticii interpreteaza un model UML ca un
predicat care restrictioneaza universul unei anumite multimi de
structuri, care reprezinta intelesul modelului UML. In alte cuvinte,
scopul nostru este sa definim semanticile unui centru cuprinzator
al conceptelor bine definite ale UML-ului, si nu a tuturor
extensiilor sale notationale. Acest mod de abordare este numit
abordarea concentrata(ceapa). Modelul sistem, adica partea
dreapta a aplicatiei semanticii Sem, nu adreseaza UML-ul si
constructiile sale, este orientat spre partea stinga a aplicatiei
Sem, anume UML2.0(simplificat), prin acoperirea unui numar de
concepte de baza exprimabile in UML.
Modelul sistem defineste un univers al masinilor de stare care
interactioneaza si care descriu comportarea obiectelor si
incorporeaza structura lor de date.Universul este introdus pe
nivele asa cum se arata in fig.2

Fig. 2 Teoriile ce constituie modelul sistem

Primul raport se concentreaza pe caracteristicile structurale
ale sistemului. Alte parti ale modelului sistem acopera tranzitia
starilor si partile de control; acestea vor fi introduce in alte
rapoarte.
Cand descriem conceptele, vom introduce dedesupt, precis,
anumite decizii ce trebuiesc luate si care pot fi deschise la stinga
sau nu apar niciodata cind ne aflam in stare informala. Identificam
clar aceste decizii sau direct, sau le marcam ca un punct de
variatie, sau ca un posibil punct de extensiesi il lasam
utilizatorului modelului sistem pentru a adopta o variatie sau o
extindere.
Dreptunghirile din Fig.2 contin concepte matematice, pe cind
sagetile arata o relatie dintre concepte, care poate fi parafrazata
prin este definita in termini de . De exemplu, numele
tipurilor( a nu se confunda cu entitatea sintactica de tipuri ale
4

unui limbaj de programare) si valorile sunt utilizate pentru a

defini, pe de o parte, clasele si obiectele si , pe de alta parte,
legaturile si gramezile.

1.3 Matematica in spatele Modelului

Sistem
O descriere precisa a modelului sistem necesita un instrument
precis. Pentru scopurile noastre, matematica este cea mai
potrivita , datorita puterii si flexibilitatii sale. Se stie ca uneori
matematica nu este atit de intuitiva si astfel cititorii trebuie sa se
acomodeze cu ea.Utilizarea UML-ului in sine pentru a descrie
semanticile UML-ului, se pare ca este o abordare pragmatica.
Aceasta abordare este oarecum meta-circulara si apeleaza in mod
necesar la un tip de legaturi tipic matematice, din nou.Mai mult,
intelegerea semanticilor UML-ului in termini ai UML-ului in sine,
necesita o foarte buna cunoastere a limbajului a carui semantici
trebuiesc date formal. UML-ul nu poate furniza convenabil un
mecanism potrivit cu ceea ce avem noi nevoie. Din aceste
motive , am decis sa utilizam numai matematica. De sigur, cand
este convenabil, utilizam diagrame pentru a ilustra anumite
concepte definite matematic, dar diagramele nu inlocuiesc
formulele matematice.
Cand definim modelul sistem s-a dovedit ca sunt folositoare
urmatoarele principii:
1.Matematica pura este folosita pentru a defini modelul
sistem. Subteoriile sale se bazeaza pe: numere, multimi,relatii si
functii.Teoriile aditionale sunt construite sub forma de nivele, ca in
fig.2. Aceasta inseamna ca in modelul sistem sunt introduse sau
folosite numai notatii si definitii matematice si nu sintaxe sau
limbaje noi. Diagramele sunt utilizate ocazional , pentru a clarifica
lucrurile, dar nu contribuie formal la modelul sistem.

2. Modelul sistem nu defineste constructiv elementele sale,

dar introduce elementele si caracterizeaza proprietatile
lor.Aceasta inseamna ca termenii abstracti sunt utilizati ori de cite
ori este posibil. De exemplu, in loc de utilizarea unei inregistrari
pentru a defini structura unui obiect, putem utiliza o multiume
abstracta si un numar de functii de selectare. Proprietatile
multimii sunt atunci definite prin astfel de selectori.Aceasta poate
pune problema constructivitatii, care vrea sa dezvolte
constructiv orice. Bazindu-ne pe mediul si cunostintele noastre,
afirmam ca putem transforma acest model sistem intr-o versiune
constructiva, dar care va fi mult mai incomod de citit si mai putin
intuitiv,
deoarece asta presupune o multime de masinarii, cum ar fi
punctele fixe,etc.
3.Orice este important este dat printr-un nume adecvat. De
exemplu, in scopul tratarii claselor, exista un univers al numelor
de clase, UCLASS si similar exista de asemenea un univers al
numelor de tipuri UTYPE, care este chiar o multime de nume ( si
nu de tipuri ).
4.Pentru cunoasterea cea mai buna orice presupunere
neclara este evitata, in acord cu sloganul: ceea ce nu este explicit
specificat nu trebuie sa aiba loc. De exemplu, daca nu afirmam
explicit ca doua multimi sunt disjuncte, atunci aceste doua
multimi pot avea elemente comune : noi nu fortam multimile de
nume de tipuri UTYPE si de nume de valori UVAL sa fie disjuncte
( dar, de asemenea, nu consideram avantajul unei posibile
suprapuneri). Uneori aceste pierderi de finaluri sunt folositoare
pentru specializarea modelului sistem si se afla in scopul
urmarit.Daca ai nevoie de o proprietate (a) verifica daca exista,
(b) daca este absenta, verifica daca poate fi dedusa ca o
proprietate de urgenta, (c) daca nu,chiar ai nevoie de ea? Si (d)
daca da ,poti sa o adaugi ca o restrictie suplimentara.
6

5. In general este utilizata incorporarea adinca ( sau

reprezentarea explicita). Aceasta inseamna ca semanticile
limbajului incorporat, adica UML,este complet formalizat in cadrul
limbajului suport, in cazul nostru, matematica. Ca o consecinta ,
modelul sistem nu are si nu necesita un sistem de tipuri in
sine.Totusi, caracterizeaza sistemul de tipuri al UML.
6.Multimile dinamice, privite ca multime de identificatori ai
obiectelor actual existente intr-o anumita instantiere a executiei
sistemului, sunt modelate in doua parti :un univers al
identificatorilor de obiecte descrie o multime maximala ( care
este infinita) si o multime finita a identificatorilor de obiect
existente este parte a starii sistemului.
7. Punctele specifice, unde modelul sistem poate fi intarit,
au fost marcate ca executii si puncte de variatie. Extensiile
se ocupa cu elementele aditionale, care pot fi definite pe modelul
sistem. Punctele de extensie ne permit sa aratam masinaria
aditionala, care nu este necesar sa fie prezenta in fiecare sistem
modelat. Exemple importante de astfel de extensii sunt existenta
unei clase predefinite de nivel inalt, numita obiect , sau un tip
de sistem schimbat, incluzind,de exemplu, contemplari.
8. Variatiile descriese schimba definitiile, ceea ce duce la un
model sistem putin diferit. Punctele de variatie ne permit sa
descriem variante specializate ale modelului sistem, care pot sa
nu fie in general valide, dar au loc pentru o mare parte a
sistemelor posibile. Exemple proeminente sunt ierarhiile
mostenite sau tipurile sigure referitoare la operatii in subclase,
care nu sunt date in general de UML.

1.4 Probleme statice si dinamice

Un sistem orientat pe obiect poate fi descris utilizind una din
diferitele paradigme existente. Noi am optat pentru paradigma
unei masini de stare globala, cu scopul sa ne acomodam cu un
7

spatiu de stari global (si poate distribuit ). Un model UML va fi

interpretrat ca o unica masina de stare cuprinzind, printre alte
lucruri,intelesul diagramelor de tranzitie a starilor dintr-un model.
Modelul sistem defineste un univers al masinilor de stare. O
masina de stare este data prin spatiul sau de stari, starile sale
initiale si functia de tranzitie a starilor. Notiunea noastra de
masina a starilor este mai bazica si nu se relationeaza direct cu
masinile de stare / diagramele de tranzitie a starilor furnizate de
UML.
Tipurile si clasele unui model UML sunt statice, adica ele nu
se schimba de-a lungul timpului de viata al sistemului. Aceste
informatii sunt numite informatiile statice ale masinii de stare.
Multimea obiectelor existente si valorile atributelor, ca si o parte
din relatii sunt dinamice,adica ele se pot schimba in pasii
tranzitiei.
Acestea din urma sunt numite informatii dinamice ale masinii de
stare si sunt codificate in starile masinii de stare. Multimea
metodelor invocate si neexecutate ( deplin) este administrata in
partea de control a masinii de stare.
In concluzie, o masina de stare a modelului sistem este
constituita din urmatoarele elemente:
- Partea statica: definitiile numelor claselor si a numelor
tipurilor.
- Partea dinamica: multimea starilor create si starea atributelor
sale.
- Partea de control: metodele invocate
- Functia de tranzitie a starilor: definita in termini de parte de
control.
- Abstractizarea interfetei: incapsularea starilor locale.
Schimbarile din partea statica , care au loc atunci cand, de
exemplu, modelul UML evolueaza sau este reconfigurat, nu sunt
considerate in acest raport.
8

In urmatoarea sectiune detaliem partea statica a unei masini

de stare globala a modelului sistem.

1.5 Ce este un model sistem ?

Un model sistem furnizeaza un inteles pentru definirea
semanticilor unui model UML. In termini precisi, matematici,
starile unei masini de stare a unui model sistem sunt definite in
termini ai unui numar mare de elemente definite matematic, care
sunt introduse in continuare.
Definitie: Modelul sistem SYSMOD este universul masinilor de
stare, a caror
- Stari sunt tripletele ( DataStore,ControlStore,EventStore) ,
unde
DataStore, definita anterior, depinde de structura statica si
ControlStore si EventStore sunt definite in documente
separate.
- Functia de tranzitie a starilor este de asemenea definite intr-un
document separat.
Formal, cand vorbim despre o masina de stare a unui model
sistem, vorbim despre o instantiere sm SYSMOD. Mai precis, un
univers UTYPE de nume de tipuri, definit de sm SYSMOD, nu
este unic in mod necesar; sm.UTYPE este o prescurtare care
inseamna ca UTYPE este universal numelor de tipuri al masinii de
stare sm. Notam simplu UTYPE, daca sm este clar din context.

1.6 Ce va urma dupa modelul sistem ?

Documentul contine partea structurala a modelului sistem.
Urmatoarele doua parti, fiecare in document separat, se ocupa cu
controlul(procese, comunicatii,etc.) si cu definitia starii de baza /
interactiunii, pentru un model sistem.
Paralel, pentru a avea designul modelului sistem, intram
acum in procesul de utilizare a lui pentru a defini semanticile
pentru cele mai importante notatii ale UML. De-a lungul acestui
proces de definire a semanticilor UML, speram sa fim in stare sa
aprofundam modelul sistem definit in urmatoarele trei parti, sa
9

determinam o baza semantica solida si in general acceptabila

pentru UML.

Partea statica a Modelului Sistem

In aceasta sectiune, introducem partea statica fundamentala

a masinilor de stare in modelul sistem, care va servi la definirea
semanticilor modelelor UML.
Formal, partea statica a unei masini de stare in modelul
sistem este compusa din urmatoarele alte lucruri:
-

UTYPE, universul numelor de tipuri.

UVAL, universul valorilor
UCLASS, universul numelor de clase si
UOID, universul identificatorilor de obiecte.

2.1 Numele de tipuri si multimile purtatoare

asociate lor
Numele tipului identifica o multime purtatoare asociata, care
contine elemente de date simple sau complexe, numite membri
sau valori ale (sau asociate cu) numelui tipului. Membrii tuturor
numelor de tipuri sunt acumulati in unversul UVAL al valorilor.
Formal, avem:
Definitie
- UTYPE este unversul numelor de tipuri
- UVAL este universul valorilor
- CAR: UTYPE(UVAL) aplica numele tipurilor multimilor
purtatoare asociate
- Pentru T UTYPE si e CAR(T), perechea (T,e) reprezinta un
element tipic al numelui tipului T.

Punct de variatie: Intr-un context foarte general, nu fortam

multimile purtatoare sa fie disjuncte sau nu cerem valorilor sa stie
in care din multimile purtatoare se afla. Pentru anumite nume de

10

tipuri putem presupune ca multimile purtatoare asociate lor sunt

identice sau se afla intr-o relatie de submultime.
Observatie: Intr-un sistem corespunzator de tipuri familiile de
tipuri, impreuna cu functiile lor, formeaza algebra cu signaturile
specifice.

2.2 Nume de tipuri de baza si constructorii

numelor de tipuri
Presupunem ca s-au dat un numar de nume de tipuri de baza
pentru valorile de baza. Avem nevoie numai de nume de tipuri
pentru valori intregi sau Booleiene.
Definitie
- Bool, Int UTYPE
- CAR(Boolean) = {true,false} ,cu true,false UVAL si true
false
- CAR(Int) = UVAL este multimea valorilor intregi
- UTYPE X UTYPE este o relatie de echivalenta pe numele de
tipuri
Introducem notiunea de echivalenta a numelor de tipuri si
scriem T1T2, pentru a arata ca T1 si T2 reprezinta aceeasi multime
purtatoare, adica CAR(T1) = CAR(T2)
Mai mult, presupunem operatiile tipice pe valorile asociate cu
numele de tipuri de baza, cum ar fi, de exemplu, conectivitatea
logica sau operatorii aritmetici.
Un nume de tip special este Void,a carui multime purtatoare
este unitara
Definitie
- Void UTYPE
- CAR(Void) = { void}, cu void UVAL
Punct de variatie: In plus fata de numele de tipuri de bazareal,caracter sau sir- daca exista, nu sunt nici asumate, nici
detaliate.

11

Constructorii numelui de tip sunt functii simple care iau una

sau mai multe nume de tipuri ca argument si construiesc un nou
nume de tip.

2.3 Referinte si Variabile

O referinta este sau Nil sau un identificator pentru o valoare in
multimea purtatoare a unui nume de tip dat. Fie T un nume de tip
arbitrar. Atunci Ref T este numele de tip a carui multime
purtatoare consta dintr-o multime infinita de referinte, incluzind
referinta distinsa Nil.
Dat un nume de tip T , multimea purtatoare a numelui de tip
Ref T are o multime foarte limitata de operatii. Referintele de baza
permit compararea
( adica testul de egalitate ) si
deferentierea si furnizeaza referinta speciala Nil. Data o referinta
r CAR(Ref T) , dereferinta sa deref(r) CAR(T) este definita daca
si numai daca r Nil.
Definitia referintelor
- Ref : UTYPE UTYPE
- Nil CAR(Ref T) UVAL pentru orice T UTYPE
- Deref : CAR(Ref T) CAR(T) pentru orice T UTYPE
Cu dom(deref) = CAR(Ref T) \ { Nil }
- Deref : UTYPE UTYPE cu deref(Ref T) = T
Notatie *r = deref(r)
Observatie: Existenta functiei deref,definita matematic, de la
referinte la valori are un efect interesant. Cum functiile
matematice nu se schimba in timp,referentele din Ref T, pentru
orice nume de tip T, se refera mereu la aceeasi valoare. Din acest
motiv, am introdus mai devreme conceptul de locatii a caror
continut se poate schimba.
Punct de Variatie: Compararea referintelor poate fi extinsa
incluzind relatia mai mic decatsi pot fi adaugate chiar operatii
pe referinte, in scopul gasirii unui pointer aritmetic.Totusi,conform
scopurilor noastre, consideram ca aceste relatii si operatii pe
referinte nu sunt necesare.

12

In scopul modelarii inregistrarilor,obiectelor,parametrilor si a

variabilelor locale ale metodei invocate si a executiei, introducem
notiunea de nume de variabile, utilizate pentru a modela numele
atributelor in obiecte si numele variabilelor locale si ale
parametrilor in metode.
Definitie
- UVAR este universul numelor de variabile ( numite si atribute )
- Fiecare pereche (T,u), cu TUTYPE si uUVAR reprezentind o
variabila tipica a tipului T
- Notam variabilele tipice de asemenea cu u : T

2.4 Nume de tipuri de inregistrare si Produse

carteziene
Numele de tipuri pot fi compuse in nume de tipuri inregistrate.
In plus, pentru a construi noi valori din unele date, valorile
inregistrate ( adica valorile din multimea purtatoare a unui nume
de tip inregistrat )furnizeaza de asemenea functii de selectie
pentru fiecare parte a valorii inregistrate. In inregistrarile cu
numele etichetat, aceste nume etichetate furnizeaza nume proprii
pentru functiile de selectie.

Definitia inregistrarilor
Rec: f(UVAR X UTYPE) UTYPE,unde numele variabilelor sunt
toate diferite
Notatie
Rec({(a1,T1), (a2,T2),, (an,Tn)}) se noteaza cu Rec{ a1:T1, a2:T2,
, an:Tn}
Definitie
Car(Rec{ a1:T1, a2:T2,, an:Tn}) = {r:UVARUVAL|r(ai)CAR(Ti),
1in}
attr: UTYPEUVAR
attr(Rec{ a1:T1, a2:T2,, an:Tn}) = {a1,,an}
attr(Ref T) = attr(T) pentru tipul de referinta Ref T
attr(T) = { } pentru orice alt tip
13

- proj: UVAR UVAL UVAL cu

- proj(ak)(r) = r(ak), daca r CAR(Rec{ a1:T1, a2:T2,, an:Tn}) si
1in
- proj(ak)(r) = proj(ak)(*r) , daca r CAR(Ref T) si akattr(T)
- Notatie
- proj(ak)(r) este notat cu r,ak , daca r CAR(T) si akattr(T)
- proj(ak)(r) este notat cu rak , daca r CAR(Ref T) si
akattr(T)
Orice nume de tip poare fi compus in nume de tip inregistrat.
Variabilele ai se numesc atribute ale numelui de tip
iregistrat.Observam ca, desi Rec este definit pe multimile (finite)
de perechi, definitia sa nu se relationeaza cu ordinea atributelor
sale, astfel Rec{a:T,b:S} si Rec{b:S,a:T} reprezinta acelasi nume
de tip. Daca S si T sunt nume de tip distincte, atunci asa sunt si
Rec{a:S} si Rec{a:T}.Daca, totusi S si T au multimi purtatoare
suprapuse, atunci Rec{a:S} si Rec{a:T} au valori inregistrate
comune in multimile lor purtatoare.
Observam ca, desi nu am interzis explicit ca un nume de tip
sa fie de ambele forme Ref T si Ref S, acest lucru poate fi implicit
dedus. De exemplu, daca ab, atunci din attr(Rec{a:Int}) = {a}
si attr(Rec{b:Int}) = {b}, implica ca ambele nume de tipuri
inregistrate nu sunt egale. Mai mult, inregistrarile[a = 3] si [b = 3]
sunt valori distincte, de asemenea.
Produsele carteziene (numite si produse incrucisate) peste
valori si multimile purtatoare ale numelor de tip inregistrate,
introduse anterior, fac parte dintr-o structura comuna. Uneori, ele
difera semnificativ destul pentru ca noi sa nu le identificam.
Inregistrarile au indexat valorile intrate, pe cand produsele
carteziene au o lista ordonata de valori. Desi in programare,
produsele carteziene pot fi imitate chiar bine de inregistrari, in
modelul sistem avem nevoie de un produs cartezian pentru a
modela, de exemplu, parametrii mesajelor si ai metodelor.
In continuare, utilizam List(.), Stack(.), Queue(.), care sunt
constructori matematici si nu extinderi de tip pentru UML.Ne
permitem sa construim liste finite peste elemente matematice
14

arbitrare, utilizind [1,,n] pentru liste, len(.) pentru lungimea

listei, list( index) pentru selectia punctelor si alti operatori comuni.
Definitia produsului cartezian
- Prod: List(UTYPE) UTYPE
- CAR(Prod{T1,,Tn}) = X(1kn)CAR(Tk)
- Lista vida duce la un tip unitar special Prod{ }, a carei
multime purtatoare are o singura valoare ( )
- Notatie
- Folosim Prod{ T1,,Tn} ca un sinonim pentru tip si scriem:
- (p1,,pn) CAR(Prod{ T1,,Tn}) pentru un n-uplu de valori
piCAR(Ti), 1in
- Exista doua aplicatii intre n-uple si inregistrarile
corespunzatoare
- rec[a1,,an]( v1,,vn) = [ a1=v1, ,an=vn]
- prod[a1,,an]( [ a1=v1, ,an=vn]) = ( v1,,vn)
Aplicatiile dintre n-uple si inregistrari sunt
inversabile.Observam ca atit n-uplele cat si inregistrarile au
nevoie de liste de nume de atribute: rec are nevoie de lista
ordonata [a1,,an] pentru a aplica valorile atributelor
corespunzatoare, iar prod are nevoie de lista pentru a reintroduce
ordinea data intre n-uple ( care nu se afla intr-o inregistrare ).

2.5 Locatii
Partile statice si dinamice trebuiesc tinute strict separate.
Introducem astfel un concept explicit de locatii pentru variabilele
mutabile. Valoarea stocata in locatie depinde de starea masinii de
stare. O locatie este o reprezentare abstracta a unei parti a starii
sistemului.
Definitia locatiilor
- ULOC UVAL este universal locatiilor
- Loc: UTYPE UTYPE
- Loc T reprezinta tipul locatiei care stocheaza data de tip T
- CAR(Loc T ) ULOC
Pentru orice nume de tip T,notam cu Loc T numele de tip a
carui valori asociate sunt locatii pentru valorile asociate cu
numele de tip T. Ne permitem combinatii arbitrare de tipuri, cum
ar fi Loc Ref T sau Ref Loc T.
15

Din ULOCUVAL permitem locatiilor sa fie inconjurate si

stocate ca valori ordinare. Dereferenta locatiei la valoarea
continuta este data in contextul starii reprezentata printr-un stoc,
asa cum s-a definit anterior.
Prin introducerea explicita a locatiilor, diferenta fata de
referinte devine foarte clara.O referinta puncteaza la o valoare si
aceasta relatie este statica, adica independenta de starea
sistemului. O locatie contine o valoare ( sau continutul sau ) si
este dependenta de stare.
Functia rvalue care recupereaza informatia stocata intr-o
locatie, fiind opusa functiei deref, este dependenta de stare si
astfel definitia sa este aminata pina cand va fi introdusa partea
dinamica a masinii de stare a modelului sistem.

2.6 Numele claselor si obiecte

Dat un numar de mai multe conditii esentiale matematice,
traditionale,construim acum notiunile de obiect si clase de virf,
fundamentale pentru extinderea operatiilor folositoare anumitor
nume de tipuri si prin restringerea accesului, elementele asociate
unui anumit nume de tip sunt structurate si pot fi folosite.
Un nume de clasa defineste atributele si metodele si poate sa
fie relationata cu alte nume de clase. Fie C un nume de clasa. In
mod curent, noi nu consideram metodele definite in numele de
clase, adica le consideram acumulate in suita de metode si ne
ocupam de ele mai tirziu.

Exemplu: Structura unui obiect

16

Fig.3
Structura tipica a unui obiect
Avem doua scene dereferentiind de la identificatorul obiectului
la valorile mutabile, actuale ale atributelor. Identificatorul de
obiect, mai intii face referinta la structura statica, care contine un
numar de locatii pentru valorile atributelor in stocul de date.
Numele de clase au asociata o structura speciala. Fiecare clasa
reprezinta o multime de idetificatori de obiecte, caracterizindu-se
prin numele tipului, care este de forma:
C = Ref Rec {self: C, a1:Loc T1,,an:Loc Tn},
si valorile asociate lor, care sunt numite obiecte si sunt asociate
unui nume de tip de forma:
*C = Rec {self: C, a1:Loc T1,,an:Loc Tn}
Astfel un nume de clasa este un nume de tip la fel de bine.
CAR(C) reprezinta multimea de identificatori de obiecte pentru
clasa C. O singura dereferentiere a acestor identificatori duce la
structura obiectului:
17

CAR(C) UOID
CAR(*C) = {*oid | oidCAR(C) } INSTANCE.
( UOID si INSTANCE sunt definite formal anterior ) Identificatorii de
obiect puncteaza unic structura obiectului (inregistrarile formale )
si cum noi nu avem referinte instabile, exista o bijectie intre
identificatorii de obiecte si structurile obiectelor, adica
dereferentierea (* ) este bijectiva ( atunci cand nu tinem seama
de Nil )
In final,nu permitem existenta obiectelor cu locatiile
impartite. Astfel, pentru orice doi identificatori de obiect
o1CAR(C1) , o2CAR(C2)si nume de atribute
aattr(*C1),battr(*C2), avem *o1.a *o2.b, pentru orice a si b de
tip Loc.
Observam ca UOID contine referintele tuturor obiectelor
posibile si , in mod analog, INSTANCE contine toate obiectele
posibile intr-un stoc de date.
Prin functia de dereferentiere identificatorii obiectelor cunosc
obiectele pe care le dereferentiaza.Obiectele au de asemenea
anumite cunostinte si despre ele insele. Aceasta inseamna ca
obiectele cunosc identificatorul lor si clasa lor. Ca o consecinta a
acestei definitii,fiacre obiect apartine exact unei clase.
Definitia claselor si a instantierilor:
- Ref Rec {self: C,c1:T1,,ck:Tk, ak+1:Loc Tk+1,,an:Loc Tn},este un
nume de clasa
- UCLASS UTYPE este universul numelor de clase
- UOID = C UCLASS CAR (C) este universal identificatorilor de
obiect
- INSTANCE = C UCLASS CAR ( C) este multimea obiectelor,
unde pentru fiecare CUCLASS exista si sunt unici ai,Ti asa
incat
18

C = Ref Rec {self: C, a1:Loc T1,,an:Loc Tn}, si pentru toti

oidUOID identificatorul de obiect potriveste *oid.self = oid
- classOf: INSTANCE UCLASS, cu obiectCAR(classOf(obiect))
- classOf: UOID UCLASS cu classOf(oid) = classOf(*oid)

Fig.4 O imagine asupra universului semantic

2.7 Subclasarea

Subclasarea( numita si mostenirea) este o caracteristica de

baza in programarea orientata pe obiect. Pentru a indica faptul ca
o clasa C mosteneste din clasa C, introducem relatia binara de
subclasare subpe universul tipurilor,care implica un numar de
conditii asupra claselor relationate.
Definitia subclasarii
- subUCLASS X UCLASS este relatia subclasare,care este
tranzitiva si reflexiva
- Oid:UCLASSUTYPE este un constructor de tip pentru tipul
identificatorului de obiect, pentru clasa C , incluzind subclasele
sale definite prin
19

- CAR(Oid(C)) =

CAR(C 1)
C 1C

UOID.

Definitia anterioara este suficienta pentru a captura

subclasarea pe partea structurala.Totusi, ea lasa cateva lucruri
deschise.De exemplu, relatia binara sub nu este obligata sa fie
antisimetrica (desi nici o complementare de limbaj nu suporta
acest lucru astazi).
Din definitie putem vedea ca in UML o subclasa poate avea o
structura de inregistrari diferita, arbitrara.Mai mult,subclasarea nu
se bazeaza pe o definitie structurala: doua clase C1 si C2 pot sa
aiba aceleasi atribute,dar sa nu fie in nici o relatie cu celelalte.
Principiul substitutiei obliga identificatorul de obiect al
subclasei C1 sa fie cazuri speciale ale clasei C. Aceasta poate fi
usor modelata prin introducerea unei incluziuni de multimi pe
identificatorii de obiect , deoarece nu putem inconjura obiectele
,dar pentru identificare nu necesita incluziunea intre obiecte, ci
intre identificatori.
Cu aceasta tehnica de definire a relatiei de submultime pe
identificatorii de obiecte si nu pe obiecte,putem realiza o mare
simplificare in imitarea sistemului de tipuri. Ea ne permite sa
redefinim structura atributelor in subclase fara o pierdere a
principiului substitutiei.
Observatie: Mostenirea multipla permite unei clase sa
mosteneasca trasaturi de la mai multe clase.In timp ce o definitie
constructiva a clasei mosteneste de la cateva clase, un punct de
vedere relational rezolva chiar ca astfel de relatii binare de
mostenire sa existe .
Pentru a evita conflictele de nume care apar atunci cand
atributele din superclase diferite ( sau ale unei superclase si ale
unei extensii) sunt omonime, cerem ca toate definitiile de atribute
sa introduca nume diferite. Semantic, aceasta conventie nu
reprezinta nici o restrictie, deoarece accesul atributelor este
intotdeauna realizat static in timpul rularii si nu exista nici o
comportare dinamica a atributelor.
20

Punct de variatie: In limbajele procedurale, redefinirea

atributelor in subclase nu este posibila fara o pierdere a sigurantei
tipului. Ca o variatiune semantica, putem forta siguranta tipului,
cerind subclaselor sa pastreze atributele lor si acestor atribute sa
pastreze numele lor si astfel si tipul. Deci numai o subclasa
extinde structura de inregistrari a superclasei sale: pentru orice
clase C1 siC2 avem attr(C2) attr(C1).
Punct de extensiereclasificarea dinamica: Observam
ca un obiect poate fi privit ca o instantiere a mai multor clase de-a
lungul ierarhiei subtipizarii. Astfel un obiect poate sa fie reclasificat
dinamic prin contextul sau, in acord cu ierarhia de subclase data.
Totusi,aceasta schimba numai punctul de vedere exterior al
obiectului, dar nu structura sa interna ( atributele existente)si nici
comportarea sa.
In UML2.0 reclasificarea dinamica pentru clase este introdusa
intr-un mod foarte general. Modelul sistem nu reflecta aceasta
capacitate de reclasificare, deoarece noi presupunem ca acest
concept poate sa fie aplicat modelului sistem prin introducerea
unei infrastructuri aditionale. Implementarile posibile ale
reclasificarii dinamice se desfasoara de-a lungul construirii unei
superclase aditionale care contine toate atributele si un reper a
carui comportare este activa in mod current. Chiar se castiga mai
multa flexibilitate, cand sansa comportarii dinamice este realizata
prin delegarea comportarii altor obiecte.

2.8 Punct deVariatie si de Extensie: Sistem de

tip
Sunt posibile constructii suplimentare pentru constructia
numelor de tip. De exemplu, sunt disponibile un nume de tip array
sau o structura de subtip dincolo de conceptul de subclasare
implementat in OO. De asemenea ,nu ne ocupam cu polimorfismul
parametric, de exemplu, cel care a fost introdus in Java1.5 sub
forma de constructii instabile in modelul sistem.Un sistem de tip
este un concept sintactic schimbat si poate sa fie utilizat impreuna
cu sintaxa concreta a modelelor.
21

Modelul stoc pe care l-am introdus nu furizeaza si,deoarece

este o constructive pur semantic, nu are nevoie de nici o
vizibilitate explicita sau meca nisme ascunse. In particular , el nu
descrie care activitati pot schimba care attribute. Desi este
recomandat din practica inginereasca sa prevenim obiectele
straine prin schimbarea unui atribut ( sa utilizam numai attribute
private), pot sa fie modelate referintele de trecere.Aceasta
permite parametric de intrare/iesire, dar da posibilitatea si chiar
incurajeaza pierderile incapsulate.
Orice atribut attr cu tipul LocLoc T contine o locatie pentru o
locatie. Locatiile sunt valori ordinare si pot fi stocate, inconjurate si
folosite pentru citire si scriere.Mai mult, plasamentul locationat al
valorii T in stoc, poate sa fie schimbat.

2.9 Structura stocului de date

In modelul sistem, am abstractizat un numar de detalii, cum ar
fi nivelele de stocare si distributia fizica. Utilizam un stoc global
abstract pentru a reprezenta starea unui sistem obiect. Chiar daca
nu exista nici un astfel de concept in sistemul real (distribuit) toate
instantierile sunt organizate intr-un unic stoc global.
Intuitiv,stocurile de date modeleaza starea sistemului la un
anumit moment. In fiecare moment stocul contine obiecte reale
pentru o submultime finita a universului UOID al identificatorilor de
obiecte. Progresul timpului este modelat prin tranzitiile masinii de
stare.
Chiar daca am definit conceptul un stoc de date global,nu am
impus existenta unei astfel de stari definite global in
implementare. Am permis, de asemenea, intrepatrunderea, ca si
activitatile concurente.Acestea vor fi detaliate mai tirziu, cand vom
defini partile dinamice,starea de control,gramezile si procesele.
Un stoc de date este o poza de date ale sistemului in rulare.
Stocurile contin repartitiile locatiilor si descriu multimea de obiecte
curent instantiate .
Definitia stocului de date:
In modelul sistem avem
22

- DataStore = (UOID) X (ULOC UVAL) multimea valorilor

pozei
- oids: DataStore (UOID) multimea obiectelor existente,
unde oids((s,m))=s
- locations: DataStore ULOC multimea locatiilor utilizate, unde
locatins((s,m)) = dom(m)
Exista un numar de restrictii in DataStore:
Elementele din DataStore contin aplicatii partiale ,deoarece
numai un numar finit de locatii pot sa fie folosite in orice poza a
calculului. Mai mult, locatiile utilizate in obiectele existente,
corespund locatiilor utilizate in stoc la acel moment. Astfel,
ambele multimi: oids( store), care contine identificatorii
obiectelor existente in stocul DataStore si locations(store), care
contine locatiile existente in stoc, sunt finite.
Este necesar sa avem un numar de functii de recuperare si
actualizare pentru stocul de date

Definitia functiilor DataStore

Functiile de recuperare pentru stocul de date sunt:
val: DataStore X ULOCUVAL recupereaza valoarea pentru o
locatie data
val((s,m),loc) = m(loc)
val: DataStore X UOID X UVAR UVAL recupereaza valoarea
pentru un obiect si atribut dat
val((s,m),oid,at) = m(*oid.at)
vals: DataStore X UOID (UVAR UVAL) recupereaza aplicarea
numelui atributului la o valoare, pentru un obiect dat
vals((s,m),oid) = {f|dom(f)=attr(classOf(oid))
atdom(f):f(at)=m(*oid.at)}
Pentru a define schimbarile putem folosi urmatoarele
apgradari
addobj: DataStore X OID (ULPC UVAL) DataStore,care
adauga un nou obiect
addobj((s,m),oid,f) = (s{oid},mf)
setval: DataStore X ULOCUVAL DataStore, care seteaza
valoarea pentru o locatie
setval((s,m),loc,v) = (s,m[loc=v])
23

- setval: DataStore X UOID X UVAR X UVAL DataStore, care

seteaza valoarea pentru un obiect si atribut dat
- setval((s,m),oid,at,v) = (s,m[*oid.at = v])
Prescurtari utilizate
ds(loc)
pentru val(ds,loc)
ds[loc=v]
pentru setval(ds,loc,v)
ds(oid,at)
pentruval(ds,oid,at)
ds[oid.at=val] pentru setval(oid,at,val)
Se aplica din nou variate restrictii in utilizarea functiilor de
recuperare si actualizare.Aceasta implica utilizarea valorilor
tipurilor convenabile, atribute care exista actual intr-o clasa,etc.
Mai mult, un numar de proprietati pot sa fie derivate, cum ar fi
din valorile selectate din informatia tipica.
In fiecare moment, adica in fiecare stare a masinii de stare,
cand exista instantieri, presupunem ca atributele sale sunt
prezente si valorile in aceste locatii au valori definite( incluzind
Nil), dar nu este necesar in cazul cand cunoastem aceste valori.
Ele pot sa fie nespecificate. In particular este posibil ca , dupa
crearea unei instantieri, sa fie necesar sa initializam atributele
sale. Utilizam o tehnica eleganta de modelare in verificarea
sistemelor de a avea in mod explicit pseudovalori nedefinite.
Este in conformitate cu realitatea atunci cand exista o variabila
neinitializata de tip int. Cand accesam valoarea,stim ca ea
contine un intreg, dar nu avem nici o ide care este aceasta.
In ipoteza ca putem folosi o stare globala consistenta, pentru
toate instantierile la fiecare moment, chiar daca ele sunt activitati
calculatorii, putem modela starea de date globala a unui sistem
obiect prin aceste stocuri de date.

2.10 variabilele si constantele de clasa

In timp ce atibutele sunt elementele pe departe cele mai
comun utilizate pentru stocarea valorilor, exista trei tipuri de
elemente prezente in universul orientarii pe obiect.
Constantele, pe de o parte, sunt valori cu nume, astfel incat
numele poate sa fie folosit in locul valorii. Nu dorim sa
reprezentam constantele explicit in modelul sistem: valorile
24

asociate lor sunt prezente in universul valorilor si aplicarea

numelor la valori ca si vizibilitatea lor nu este parte a modelului
sistem, dar este parte a aplicarii din UML a modelului sistem.
Al doilea concept pe care nu il reprezentam explicit in
continuare, este conceptul de atribute statice. Acestea sunt
atribute care pot sa fie private ca impartite intre toate obiectele
claselor. Intradevar ele exista independent de orice obiect, dar pot
sa fie accesate numai dintr-un scop limitat. In timp ce modelul
sistem nu se ocupa cu vizibilitatea atributelor statice, este
pregatit sa incorporeze atributul static prin stabilirea unei locatii
in interiorul sau, care nu este parte a nici unui obiect.In acest
mod, modelul sistem este capabil sa se ocupe cu atributele
statice.
O cale diferita , dar convenabila de a include un atribut static
in toate obiectele ale unei clase, este sa include locatia sa in toate
obiectele uniform, permitind astfel obiectelor sa acceseze locatia.

2.11 Asocierile. Relatiile dintre diferite obiecte

Conceptul de asociere este un element central al UML.
Asocierile sunt relatii dintre identificatorii obiectelor. Desi cele mai
multe asociatii sunt binare,ele pot sa fie de orice aritate, pot sa fie
clasificate in multe moduri si pot sa aiba atribute aditionale
proprii. Mai mult, asociatiile pot fi detinute de unul sau mai
multe obiecte/clase participante sau se pot aseza in interiorul lor,
fara sa fie detinute de oricare din obiectele relationate. In
implementari, un mecanism de baza pentru administrarea acestor
relatii este utilizarea directa a link-urilor clasei Collection, dar
exista si alte posibilitati. Pentru a permite diferite variante ale
realizarii asocierilor, folosim o abordare extensibila: utilizam
identificatorii relatiilor pentru a extrage link-urile din stoc si a tine
seama de varietatea de relatii ale acestor functii. Aceasta
abordare este foarte flexibila,deoarece, pe de o parte
abstractizeaza de departe catre proprietarul asociatiilor ca si
forma in care asociatiile sunt stocate, iar pe de alta parte nu
25

restrictioneaza orice forma posibila de asociere. Un dezavantaj al

acestei abordari este ca nu putem captura toate formele de
asociere intr-o caracterizare uniforma, dar putem furniza un
numar de tipare standard care acopera cele mai importante
cazuri.Daca nici un caz standard nu se aplica, adica pentru un nou
stereotip de asociere, atunci developatorul stereotipului descrie
interpretarea sa a stereotipului direct, in termini ai modelului
sistem dat anterior. Pentru simplitate, argumentam aceasta
abordare definind variante ale asocierii binare.
In general, orice asociere are un nume R, o semnatura data de
o lista de clase (C1,,Cn), posibilele atribute aditionale ale acestei
asocieri si o functie de recuperare a relatiei relOf: DataStore
f(CAR(OidC1) X X CAR(OidCn)X UVALk).
Observam ca utilizarea lui CAR(Oid C1) include relatii intre
obiectele subclaselor lui Ci, care sunt usual prezentate prin
asocieri, dar neacoperitoare daca vom folosi multimile purtatoare
CAR(Ci) ale obiectelor apartinind direct lui Ci.
Observam ca cu aceasta abordare este posibil sa modelam
asocierile clasificate, interpretind unul (sau mai multe) dintre
atributele aditionale ca un clasificator, precum si sa modelam
asocierile neunice prin introducerea unei valori ca un reper
distinctive. Sunt date in continuare unele exemple pentru
aplicatiile asocierilor, pornind cu asocierea binara.
In al treilea rind, putem de asemenea observa ca asocierile
definesc de regula anumite restrictii in transformarile lor. Aceasta
nu poate fi stabilite prin partea statica a modelului sistem, dar
numai atunci cand sunt utilizate sirurile din DataStore pentru
compararea comportarii de-a lungul timpului.
Functia de recuperare relOf este dependenta de realizarea
concreta a asocierii. Chiar dupa un numar suficient de ani de
studiu al formalizarii OO, este atat de departe o abordare
satisfacatoare care sa descrie toate variantele de implementare a
asocierilor. Am furnizat aceaste functie abstracta si am impus
anumite proprietati functiei, fara sa discutam structura stocarii
interne. Singura decizie pe care am luato in continuare este ca
26

asocierile sunt oarecum continute in stoc, adica ele sunt oarecum

parte a obiectelor si locatiilor si relatiile de asociere nu extend
stocul. Aceasta este in spiritul modelului sistem, unde conceptele
de nivel inalt sunt explicate folosind conceptele de nivel scazut.
Definitia asocierilor. In modelul sistem consideram
- UASSOC este universul numelor de asocieri
- relOf(R): UASSOC DataStore f(CAR(OidC1) X X CAR(OidCn)X
UVALk) functia de recuperare pentru derivarea link-urilor actuale a
unei asocieri n-are, bazata pe starea curenta.
Observam ca nu putem constinge relatia dintre UASSOC si
UTYPE. In particular, putem privi fiecare asociere manifestindu-se
ca un tip (UASSOCUTYPE), sau numai o parte din asocieri ca
fiind realizate ca tipuri. Aceasta ne permite sa modelam relatiile
simple ca atribute numai, fara sa le atasam un tip in modelul
sistem, asa cum se arata in continuare.
Punct de extensie: Multe asocieri sunt binare fara orice alte
atribute aditionale. Pentru acestea putem folosi
binaryRelOf: UASSOC DataStore f(CAR(Oid A ) X CAR(Oid
B)) ca o functie de recuperare pentru derivarea link-urilor actuale.
Punct de extensie: Recuperarea anterioara nu are o
recuperare ordonata, necesara pentru minuirea ascierilor cu
stereotipuri ordonate, nici asociatiile clasificate,nici in minuirea
posibilitatii ca o pereche de obiecte sa fie unita ceva timp
( asocierile multiple). O extensie potrivita pentru ordonare este
data de functia de recuperare
orderedBinaryRelOf: UASSOC DataStore CAR(Oid A )
CAR(List(Oid B)).
Similar,pentru o relatie de clasificare definim
qualified BinaryReiOf: UASSOC DataStore f(CAR(Oid A ) X
CAR(Oid B)X CAR(Q)), unde numele de tip Q este clasificatorul care
identifica unicul B-obiect ce incepe intr-un A-obiect.
Punct de variatie si extensie: Functiile de recuperare nu
sunt inca specificate, deoarece ele trebuie sa aiba un numar de
realizari diferite. Pentru clarificare, le vom defini putin mai incolo,
acoperind cazurile standard si furnizindu-le ca punct de variatie.
27

Totusi, sunt posibile multe variatii, asa ca ne permitem sa

introducem variantele noastre proprii.Exista de asemenea un
punct de extensie.
Definim o relatie binara simpla SimpR
Cel mai simplu tip de asociere SimpR de la A la B este
realizat unidirectional in clasa A printr-un atribut simpRpentru a
se lega de cealalta parte:
- Structura lui*A este de forma Rec(, simpR:Loc B,) si
- Functia de recuperare este definita prin:
binaryRelOf(SimpR)(ds) = {(x,y) (CAR(Oid A ) X CAR(List(Oid
B))|y=ds(x.simpR)}
Pentru a ilustra aceasta, ne putem gindi la o transformare de
tipul urmator, pentru a realiza SimpR:

Urmatoarea definitie pentru *-to-* asocierea binara lucreaza

similar ca si pentru asocierile n-are, cu n arbitrar:
Defenitia relatiei binare *-to-* Med:
Asocierea *-to-* Med utilizeaza o clasa intermediara numita
de asemenea Med pentru stocarea legaturilor sale. Ea nu
include starea asocierii in oricare dintre obiectele lui A sau B:
- *Med se prezinta sub forma Rec(,a:Loc A,b:Loc B,) si
- Functia de recuperare este definita prin
binaryRelOf(Med)(ds) = {(x,y) (CAR(Oid A ) X CAR(Oid B))|
mCAR(Med): x=ds(m.a)y=ds(m.b)}
Pentru a ilustra aceasta, ne gindim la o transformare de tipul
urmator, pentru a realiza Med:
28

Cele doua definitii anterioare demonstreaza ca chestiunea

posedarii unei legaturi, poate sa fie acoperita, chiar in caz
general, prin utilizarea functiilor de abstractizare. In prima
definitie, obiectele poseda legaturi, in a doua, legaturile sunt
separate prin obiecte. De sigur sunt posibile combinatii, asa cum
se arata in a treia definitie.
Defenerea relatiei binare redundanta Med:
Asocierea *-to-* Med are legaturi redundante. Obiectele
participante din A, puncteaza direct la obiectele din B. Din B
asocierea este realizata utilizind o colectie externa:
- Presupunem ca clasa Collection(A) furnizeaza o functie
vals: DataStore X CAR(Collection(A)) f(CAR(OidA))
- Functia de recuperare este simplu definita prin
binaryRelOf(Med)(ds) = {(x,y) (CAR(Oid A ) X CAR(Oid B))|
y=ds(x.med)}
- Sau ca o alternativa echivalenta prin:
binaryRelOf(Med)(ds) = {(x,y) (CAR(Oid A ) X CAR(Oid B))|
xvals(ds,y.med)}
O astfel de realizare este o structura de date redundanta,
deci impunem constringerea de consistenta ca ambele multimi
sa fie egale. Pentru a ilustra aceasta situatie, ne putem gindi la o
transformare de tipul urmator, pentru a realiza Med:

29

Punct de variatie si extensie: Daca colectiile sunt utilizate

intr-o implementare, functiile de recuperare corespunzatoare
sunt o abstractizare a ceea ce colectiile stocheaza actual.
Observam ca aceste functii sunt constructori matematici care fac
explicite intentiile de colectare a claselor, dar nu este necesar sa
fie implementate actual.
Este important de observant ca efectul unei actiuni pe o
legatura a unei asociatii poate sa fie descris utilizind functiile de
recuperare, fara sa avem legatura cu actuala infatisare a actualei
reprezentari in modelul sistem. Nu este necesar sa furnizam o
astfel de reprezentare, dar este suficient sa stim ca exista una.
Acest principiu vine din tipurile abstracte ale algebrei, unde
schimbarile in structurile datelor sunt definite de asemenea ca
efecte ale accesului functiilor.

30