Data Model Structural 1

42
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. 1

description

uyrdcn

Transcript of Data Model Structural 1

DATA MODEL STRUCTURALIntroducere in Modelul Sistem pentru UMLModelul 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 si3. 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.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 UML-ul 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.0De 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 UML-ului 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 sistemPrimul 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 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 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. 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 dinamiceUn 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 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. 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 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 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 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 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 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 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 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 UTYPECu dom(deref) = CAR(Ref T) \ { Nil } Deref : UTYPE UTYPE cu deref(Ref T) = TNotatie *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.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 cartezieneNumele 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 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 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 LocatiiPartile 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.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 obiecteDat 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

Fig.3 Structura tipica a unui obiectAvem 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:CAR(C) UOIDCAR(*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 = este universal identificatorilor de obiect INSTANCE = este multimea obiectelor, unde pentru fiecare CUCLASS exista si sunt unici ai,Ti asa incat 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 semantic2.7 SubclasareaSubclasarea( 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 CAR(Oid(C)) = 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.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 tipSunt 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.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 dateIn 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 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 DataStoreFunctiile 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]) 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 utilizateds(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 clasaIn 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 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 obiecteConceptul 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 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 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 folosibinaryRelOf: 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 recuperareorderedBinaryRelOf: UASSOC DataStore CAR(Oid A ) CAR(List(Oid B)).Similar,pentru o relatie de clasificare definimqualified 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. 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 SimpRCel 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 prinbinaryRelOf(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:

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 functievals: DataStore X CAR(Collection(A)) f(CAR(OidA)) Functia de recuperare este simplu definita prinbinaryRelOf(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:

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.

27