DATA MODEL STRUCTURALIntroducere in Modelul Sistem pentru UMLModelul 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 si3. 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.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.0De 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.2Fig. 2Teoriile ce constituie modelul sistemPrimul 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 SistemO 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 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 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 dinamiceUn 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. 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 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.2 Partea statica a Modelului SistemIn 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 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 tipuriPresupunem 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 tipuriIntroducem 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 unitaraDefinitie Void UTYPE CAR(Void) = { void}, cu void UVALPunct de variatie: In plus fata de numele de tipuri de baza- real,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 VariabileO 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 UTYPECu dom(deref) = CAR(Ref T) \ { Nil } Deref : UTYPR UTYPE cu deref(Ref T) = TNotatie *r = deref(r)Observatie10