DATA MODEL STRUCTURAL

Introducere in Modelul Sistem pentru UML

Modelul system este o baza pentru un model semantic al
UML-ului. Modelul Sistem formeaza inima 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 component:
1. Sintaxa limbajului in discutie ( aici UML), data graphic sau
textual.
2. Domeniul semantic, un domeniu bine cunoscut si inteles,
bazat pe o teorie matematica bine cunoscuta si
3. Aplicatia semantic: o definitie functional sau relationala,
care relationeaza atit elementele sinaxei, cat si
elementele domeniului semantic.
Principiul de baza al semanticii este aceasta tehnica de a
privi un limbaj: fiecare constructi sintactica este aplicata pe o
constructive semantic.
In mod normal, multimea elementelor sintactice si domeniul
semantic poseda o anumita structura si aplicatia semantic
pastreaza
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 structural si
comportamentale. Fiecare instantiere sintactica concreta ( in
cazul nostrum, o diagram UML individuala, sau o parte a sa ) este
interpretata de aplicatia semantic ca un predicat peste multimea
de sisteme definite de modelul sistem.
1

Aplicatia semantic are forma:

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

Structurarea semanticii UML-ului.

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

unui limbaj modelat grafic. Ideea de baza exprimata de aceasta
diagram este: limbajul graphic plin este relationat cu un limbaj
simplificat prin citeva transformari care ne permit sa scapam de
citeva extensii notationale si concept 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, cid oar cu o submultime simplificata a UML.
Concret,pentru a ne ocupa cu complexitatea definirii unei
semantici proprii, opotam 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 inima UML-ului
simplificat.Pentru a face acest lucru, constructiile derivate ale
UML-ului sunt inlocuite prin definitiile lor in termini de
constructii ale inimii.

- In final UML-ul simplificat este aplicat pe modelul system

folosind o abordare predicative.
Asa cum am mentionat mai devreme, modelul system descrie
universal ( multimea ) tuturor structurilor semantic 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 unei inimi cuprinzatoare
a 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. 2Teoriile ce constituie modelul sistem
Primul raport se concentreaza pe caracteristicile structurale
ale sistemului. Alte parti ale modelului system acopera tranzitia
starilor si partile de control; acestea vor fi introduce in alte
rapoarte.
Cind descriem conceptele, vom introduce dedesupt, prcis,
anumite decizii ce trebuiesc luate si care pot fi deschise la stinga
sau nu apar niciodatacind 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 system pentru a adopta o variatie sau o

extindere.
Dreptunghirile din Fig.2 contin concept matematice, pe cind
sagetile arata o relatie dintre concept, care poate fi parafrazata
prin este definite in termini de . De exemplu, numele
tipurilor( a nu se confunda cu entitatea sintactica de tipuri ale
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 system 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 pragmatic.
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
concept definite mathematic, dar diagramele nu inlocuiesc
formulele matematice.
Cand definim modelul system s-a dovedit ca sunt folositoare
urmatoarele principii:
1.Matematica pura este folosita pentru a define modelul
system. Subteoriile sale se bazeaza pe: numere, multimi,relatii si
4

functii.Teoriile aditionale sunt construite sub forma de nivele, ca in

fig.2. Aceasta inseamna ca in modelul system sunt introduce 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 system.
2. Modelul system 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 utilize 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 system intr-o versiune
constructive, dar care va fi mult mai incomod de citit si mai
putinintuitiv,
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 tipuriUTYPE, care este chiar o multime de nume ( si
nu de tipuri ).
4.Pentru cunoasterea cea mai buna orice presupunere
subliniata este evitata, in accord 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 commune : 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
5

folositoare pentru specializarea modelului system 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 urgent, (c) daca nu,chiar ai nevoie de ea? Si (d)
daca da ,poti sa o adaugi ca o restrictive suplimentara.
5. In general este utilizata incorporarea adinca ( sau
reprezentarea explicita). Aceasta inseamna ca semanticile
limbajului incorporate, adica UML,este complet formalizat in
cadrul limbajului support, in cazul nostrum, matematica. Ca o
consecinta , modelul system nu are si nu necesita un system 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 maximal ( care este
infinita) si o multime finite a identificatorilor de obiect existente
este parte a starii sistemului.
7. Punctele specifice, unde modelul system poate fi mai
puternic, au fost marcate ca executii si puncte de variatie.
Extensiile se ocupa cu elementele aditionale, care pot fi definite
pe modelul system. Punctele de extensie ne permit sa aratam
masinaria aditionala, care nu este necesar sa fie prezenta in
fiecare system modelat. Exemple importante de astfel de extensii
sunt existenta unei clase predefinite de nivel inalt, numita
obiect , sau un tip de system schimbat, incluzind,de exemplu,
contemplari.
8. Variatiile descries schimba definitiile, ceea ce duce la un
model system putin diferit. Punctele de variatie ne permit sa
descriem variante specializate ale modelului system, 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 system orientat pe obiect poate fi descries utilizind una
din diferitele paradigme existente. Noi am optat pentru paradigm
unei masini de stare globala, cu scopul sa ne acomodam cu un
spatiu de stari global ( si poate distribuit ). Un model UML va fi
interpretrat ca o unica masina de stare cuprinzind, printer alte
lucruri,intelesul diagramelor de tranzitie a starilor dintr-un model.
Modelul system defineste un univers al masinilor de stare. O
masina de stare este data prin spatial 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 administrate in
partea de control a masinii de stare.
In concluzie, o masina de stare a modelului system este
constituita din urmatoarele elemente:
- Partea statica: definitiile numelor claselor si a numelor
tipurilor.
- Partea dinamica: multimea starilor create si starea atributelor
sale.
7

- Partea de control: metodele invocate

- Functia de tranzitie a starilor: definite 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.
In urmatoarea sectiune detaliem partea static a unei masini
de stare globala a modelului system.

1.5 Ce este un model system ?

Un model system furnizeaza un inteles pentru definirea
semanticilor unui model UML. In termini precisi, matematici,
starile unei masini de stare a unui model system sunt definite in
termini ai unui numar mare de elemente definite mathematic,
care sunt introduce in continuare.
Definitie: Modelul system SYSMOD este universul masinilor
de stare, a caror
- Stari sunt tripletele ( DataStore,ControlStore,EventStore) ,
unde
DataStore, definita anterior, depinde de structura static si
ControlStore si EventStore sunt definite in documente
separate.
- Functia de tranzitie a starilor este de asemenea definite intr-un
document separate.
Formal, cand vorbim despre o masina de stare a unui model
system, vorbim despre o instantiere sm SYSMOD. Mai prcis, 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 structural a modelului sistem.

Urmatoarele doua parti, fiecare in document separat, se ocupa cu
8

controlul(procese, comunicatii,etc.) si cu definitia starii de baza /

interactiunii, pentru un model system.
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
process de definire a semanticilor UML, speram sa fim in stare sa
aprofundam modelul system definit in urmatoarele trei parti, sa
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 system, care va servi la definirea
semanticilor modelelor UML.
Formal, partea statica a unei masini de stare in modelul
system este compusa din urmatoarele alte lucruri:
-

UTYPE, universul numelor de tipuri.

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

2.1 Numele de tipuri si multimile purtatoare

asociate lor
Numele tipului identifica o multime 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 universal valorilor
- CAR: UTYPEP(UVAL) aplica numele tipurilor multimilor
purtatoare asociate
9

- 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
tipuri putem presupune ca multimile purtatoare associate 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 associate
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
10

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.
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 definite daca si numai daca
r Nil.
Definitia referintelor
- Ref : UTYPE UTYPE
- Nil CAR(Ref T) UVAL pentru orice T UTYPE
- Defer : CAR(Ref T) CAR(T) pentru orice T UTYPE
Cu dom(deref) = CAR(Ref T) \ { Nil }
- Deref : UTYPR UTYPE cu deref(Ref T) = T
Notatie *r = deref(r)
Observatie

11