Continutul cursului Conceptul de arhitectura software Ce este

Continutul cursului • Conceptul de arhitectura software – Ce este arhitectura software ? • Stiluri arhitecturale fundamentale – – Pipes and filters Layers Blackboard Event-driven • Arhitecturi tipice pe domenii/tipuri de aplicatii: – Adaptive • Reflection – Distribuite • Client-server, Broker – Enterprise • Data access – Interoperability

Tema 2 laborator • Subiectul: Reflection • http: //bigfoot. cs. upt. ro/~ioana/arhit/t 2. html • Fiecare poate alege una din cele 2 variante de tema: – varianta A: Utilizarea proprietatilor reflective ale unor limbaje (Java sau. NET): • Implementarea unei versiuni proprii de Serializare • Varianta ofera posibilitatea unui punct bonus – varianta B: Construirea meta-layer-ului unei arhitecturi reflective (Do-it-yourself reflection): • Implementarea unei arhitecturi adaptive • Varianta ofera si posibilitatea obtinerii unui punct bonus.

Sisteme adaptive • Sistem adaptiv: suporta modificarea sa ulterioara • Doua categorii de modificari: – Adaptarea la cerinte diferite (inglobarea unor noi functionalitati peste un nucleu minimal comun, stabil) – Schimbarea dinamica a structurii si comportamentului unui sistem in timpul executiei sale. • Tipare arhitecturale pentru sisteme adaptive: – Microkernel: suport pentru adaptarea la cerinte diferite; • separa un nucleu functional esential de restul functionalitatilor. • nucleul furnizeaza “sockets” in care se pot insera extensii de tip “Plug&Play” – Reflection: suport pentru schimbarea dinamica a structurii si comportamentului unui sistem. • sistemul pastreaza informatii despre el insusi, si utilizeaza aceste informatii pentru a se modifica in timpul executiei sale. • Exemple: – Limbaje de programare cu capacitati reflective – Arhitecturi dinamice.

Reflection • Bibliografie: – Tiparul arhitectural reflection, generalitati: • [POSA 1] – Metode/Tipare pentru proiectarea detaliata a metaobiectelor: • Dirk Riehle, Michel Tilman, Ralph Johnson: The Dynamic Object Model, PLOP 2000, http: //hillside. net/plop 2 k/proceedings/Riehle. pdf • Joseph Yoder, Ralph Johnson: The Adaptive Object-Model Architectural Style, WICSA 2002, http: //www. adaptiveobjectmodel. com/WICSA 3/Architecture. Of. AOMs. WICSA 3. pdf

Reflection Tiparul Reflection asigura un mecanism pentru schimbarea structurii si comportamentului unui sistem in mod dinamic, in timpul executiei. Aplicatia este compusa din 2 nivele: Base level care cuprinde logica aplicatiei, si Meta level care furnizeaza informatii despre anumite proprietati ale sistemului.

Reflection - Solutia • Sistemul software devine self-aware: 2 nivele: • Meta level • Base level • Protocol care guverneaza interactiunea cu Meta. Level: • Meta Object Protocol

Reflection - Structura [POSA]-Fig/P. 199

Reflection - Elementele [POSA]-Fig/P. 197

Tipuri de Reflection • In functie de: – Cat de multe permite reflection: • Introspection • Intercession/Manipulation/Adaptation – Ce reflecta: • Structural reflection • Behavioural reflection – Reflective towers: meta-meta-….

Tipuri de Reflection

Exemple pe tipuri de reflection • Structural introspection: – Intr-un limbaj reflectiv cu capacitatea de a-si cunoaste structura tipurilor si relatiile dintre ele (de ex OO cu metaobiecte de tip Class, Field, Method): • pot afla structura oricarui tip • Structural manipulation: – Intr-un limbaj reflectiv ca cel anterior: • (ipotetic): pot modifica la runtime structura unui tip prin scoaterea/adaugarea de campuri si metode de la o clasa, cu efect si asupra instantelor – Base-level e in pericol de a deveni instabil ! • Behavioural introspection: – Un limbaj reflectiv cu capacitatea de a-si cunoaste/schimba semantica, de ex prin metaobiecte de tip Function. Call. Policy • Behavioural manipulation: – Intr-un limbaj reflectiv ca cel anterior: • Pot modifica la runtime metaobiectul de tip Function. Call. Policy, modificand la runtime semantica apelurilor de functii (cu transmiterea param prin referinta <-> cu transmiterea param princopiere)

Exemple pe tipuri de reflection • Structural introspection: – Intr-un limbaj reflectiv cu capacitatea de a-si cunoaste structura tipurilor si relatiile dintre ele (de ex OO cu metaobiecte de tip Class, Field, Method): • pot afla structura oricarui tip • Structural manipulation: – Intr-un limbaj reflectiv ca cel anterior: • (ipotetic): pot modifica la runtime structura unui tip prin scoaterea/adaugarea de campuri si metode de la o clasa, cu efect si asupra instantelor – Base-level e in pericol de a deveni instabil ! • Behavioural introspection: – Un limbaj reflectiv cu capacitatea de a-si cunoaste/schimba semantica, de ex prin metaobiecte de tip Function. Call. Policy • Behavioural manipulation: – Intr-un limbaj reflectiv ca cel anterior: • Pot modifica la runtime metaobiectul de tip Function. Call. Policy, modificand la runtime semantica apelurilor de functii (cu transmiterea param prin referinta <-> cu transmiterea param princopiere)

Meta level • Meta level: – furnizeaza o auto-reprezentare a sistemului software, ii permite acestuia sa-si cunoasca propria structura si propriul comportament – Consta din Meta-obiecte: un metaobiect face anumite categorii de informatii explicit accesibile si eventual modificabile

Base level • Base level: – Defineste logica aplicatiei – Implementarea sa utilizeaza metaobiecte din nivelul superior pentru a-si asigura independenta de aspecte care se pot schimba • Exemplu: componentele din base-level comunica doar prin metaobiectul care implementeaza mecanismul de apel de functii. Daca se schimba acest mecanism, schimbarea se produce doar la metalevel – Componentele din Base level pot utiliza direct componentele din Meta level, dar nu le pot modifica direct

Meta Object Protocol • Meta Object Protocol: – Interfata pentru manipularea metaobiectelor – Permite clientilor sa specifice anumite modificari – de exemplu modificarea metaobiectului mecanism de apel de functie – MOP verifica daca modificarile cerute sunt permise si le efectueaza propriu-zis

Reflection – Exemplu problema • Problema: Persistence Component in C++: Adaugarea facilitatii de serializare a obiectelor (stocare a unui obiect pe disc si citire a unui obiect) intr-un limbaj care initial nu suporta acest lucru (de ex C++)

Reflection – Exemplu problema Solutia necorespunzatoare • Solutie necorespunzatoare: se specifica cum se stocheaza si cum se citeste fiecare tip de date din aplicatie: – Dezavantaj major: de fiecare data cand se schimba structura claselor trebuie modificate aceste functii ! [POSA]-Fig/P. 193

Reflection – Exemplu problema Solutia buna • Solutia buna de serializare: adaugarea la limbajul de programare a unei componente care poate asigura persistenta independent de structura tipurilor aplicatiilor • Solutia in termenii tiparului Reflection: – Base level: user application (care contine obiecte de diferite tipuri ce trebuie serializate) – Meta level: metaobiecte care reflecta informatiile despre tipurile prezente in aplicatia din base level • Problema cea mai dificila la inceput: stabilirea tipurilor necesare de metaobiecte (ce metainformatii sunt necesare ? ) • Unde se implementeaza: – Componenta explicita de serializare + suport in cadrul compilatorului • Solutia presupune ca se poate accesa type-information la run-time: pentru aceasta, ar putea exista un pas special la compilare, care sa colecteze informatiile despre tipurile prezente in aplicatie, si sa genereze automat codul pentru instantierea metaobiectelor

Pasi importanti de definire a unei arhitecturi reflective 1. 2. Identificarea comportamentului variabil Identificarea aspectelor care nu variaza/nu au voie sa se modifice Definirea metaobiectelor Definirea Meta. Object. Protocol (MOP) 3. 4. – – controleaza modul in care se modifica continutul meta-layer si cum se modifica relatiile intre componente ale base-layer si meta-layer Poate fi implementat in variantele: • • 5. Integrat in metaobiecte (fiecare metaobiect furnizeaza o parte a functiilor din MOP) Ca si componenta separata de control Definirea Base Level

Exemplu Persistence Component: Pasi 1 -2: 1. Identificarea comportamentului variabil – 2. Aparitia de noi tipuri, obiectele care sunt instante ale acestor tipuri trebuie sa poata fi tratate (serializate) fara modificarea Persistence Component Identificarea aspectelor care nu variaza/nu au voie sa se modifice – Tipurile existente nu se modifica

Exemplu Persistence Component: Pas 3: 3. Definirea metaobiectelor: – – – Persistence component – face parte din Base Level: scrie/citeste obiecte Metaobiecte: furnizeaza informatii despre tipurile prezente in momentul executiei (acces introspectiv; in cazul de fata nu e permisa modificarea acestor informatii). Cel mai dificil pas: stabilirea tipurilor necesare de metaobiecte! (cautam o “sursa de inspiratie” in suportul oferit de java reflection API pentru serializare … )

Sursa de inspiratie: schita de implementare a serializarii in Java public void scrie(Object obj) throws Exception { Class c = obj. get. Class(); System. out. println("numele clasei "+c. get. Name()); Field fields [] = c. get. Declared. Fields(); int i; for (i = 0; i < fields. length; i++) { System. out. print("numele campului: " + fields[i]. get. Name()+" "); c = fields[i]. get. Type(); fields[i]. set. Accessible(true); if (c. is. Primitive()) { // determina exact tipul primitiv si ia valoarea // … } else if (c. is. Array()) { System. out. println(“camp de tip array cu elemente de tipul "+c. get. Component. Type()); // … in functie de tipul elementelor tabloului – daca e primitiv sau nu …. //. . } else { System. out. println("tipul campului: neprimitiv "+c. get. Name()); Object fo=fields[i]. get(obj); this. scrie(fo); } }

Determinarea metaobiectelor (1) Principalele operatii pentru a scrie un obiect: 1. 2. 3. 4. E nevoie sa se poata afla clasa caruia ii apartine => Este nevoie de un metaobiect de tip Type-Info (similarul lui Class); acesta trebuie sa poata fi obtinut pornind de la un obiect E nevoie sa se poata afla structura interna a unui obiect (ce campuri de date are). => Este necesar ca prin interogarea metaobiectului Type-Info sa se obtina metaobiecte de tip Data-Info (similarul lui Field) Pentru fiecare camp de date, daca nu este de un tip primitiv al limbajului, se vor aplica recursiv pasii 1 -2 Daca un camp de date este de un tip primitiv al limbajului, se ia valoarea campului Tipuri de metaobiecte implicate: Type-Info, Data-Info

Determinarea metaobiectelor (2) Principalele operatii pentru a citi un obiect: • • E nevoie sa se poata instantia un obiect de un tip cu numele dat => este nevoie de un metaobiect de tip Object. Creator (oarecum similar cu ce face Class. new. Instance) Din Type-Info-ul obiectului creat se afla apoi structura interna a obiectului (campurile de date – metaobiectele Data-Info) Pentru fiecare camp de date, daca nu e un tip primitiv al limbajului, se aplica recursiv pasul 1 Daca un camp de date este tip primitiv, se seteaza valoarea acestuia pe valoarea citita Tipuri de metaobiecte implicate: Object. Creator, Type-Info, Data-Info

Determinarea metaobiectelor (3) • Principalele metaobiecte: – Type-Info – Data-Info – Object. Creator – Base-Info: ofera functii pentru accesarea informatiilor despre clasele de baza ale clasei curente

Exemplu: Scenariu pentru citirea unui obiect de pe disc Se creaza un obiect – instanta a unui tip cunoscut prin numele sau Pentru un membru de date care nu e de tip primitiv, se creaza un obiect de tipul corespunzator [POSA]-Fig/P. 201

Exemplu Persistence Component: Pas 4: 4. Definirea Meta. Object. Protocol (MOP): • Functii care modifica meta-layer: – Crearea unui nou metaobiect de tip Type-Info pornind de la un nume (identificator) new. Type. Id(type. Name) – Modificarea unui metaobiect de tip Type-Info pentru adaugarea unor informatii despre tip new. Type. Info(type. Name, is. Built. In, is. Pointer) – Crearea unui metaobiect de tip Base-Info si modificarea unui metaobiect de tip Type-Info pentru reprezentarea relatiilor de mostenire add. Base(type. Name, base. Name) – Crearea unor metaobiecte corespunzatoare membrilor unui tip, mofificarea metaobiectului Type-Info corespunzator: add. Data (type. Name, member. Type. Name, member. Name) – Modificarea metaobiectului Object. Creator: add. Creation. Code(type. Name) • Functii care returneaza info din meta-layer – Object. Creator. create. Object(type. Name) -> Base. Level. Object, Type. Info – Type. Info. is. Built. In – Type. Info. get. Data -> Type. Info

Exemplu: Scenariu pentru actualizarea metaobiectelor Un nou tip este definit Se creaza metaobiectul corespunzator noului tip Seteaza informatiile de baza despre noul tip Seteaza informatiile despre relatiile de mostenire Seteaza informatiile despre membri de date, creaza cate un metaobiect ptr fiecare [POSA]-Fig/P. 203

Exemplu Persistence Component: Pas 5: 5. Definirea Base Level: – – – Persistence component – face parte din Base Level: scrie/citeste obiecte Implementarea operatiilor de scriere/cirire se construieste in principiu dupa schitele prezentate anterior Detalii importante care mai trebuie luate in plus in considerare: • • Accesarea membrilor de date mosteniti Tratarea referintelor diferite la acelasi obiect

Tiparul Reflection - Concluzii • Avantaje – Modificarea unui sistem este posibila fara modificarea codului – Suporta o gama larga de tipuri de schimbari (structurale, comportamentale) • Dezavantaje – Pericolul de a destabiliza sistemul daca MOP nu este suficient de robust / nu impiedica utilizatorul sa ceara modificari ce pot aduce sistemul intr-o stare care nu e safe – Numar mare de componente: numarul metaobiectelor mai mare decat numarul obiectelor – Performanta (timp executie)

Alte exemple de utilizare a tiparului Reflection • Tiparul Reflection este cunoscut in special din domeniul proiectarii limbajelor de programare – Cel mai reprezentativ limbaj de programare reflectiv: CLOS (Common Lisp Object System) • Tiparul Reflection este aplicat si in ALTE domenii diferite! – Arhitecturi dinamice/adaptive realizate in stil reflectiv in diverse domenii: • Sisteme de operare reflective: ex: Apertos • Middleware reflectiv: Open. ORB, TAO • Reflective Component frameworks: Open. COM, Fractal

Exemplu de arhitectura reflectiva: Open. COM Component framework Domeniul Software components (CBSE): “A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third-parties. ” (Szyperski)

Exemplu – sistem alcatuit prin compunerea de componente

The architecture of Open. COM

Open. COM Runtime • Open. COM deploys a standard runtime substrate • Functions of the Open. COM runtime substrate (kernel): – manages the creation and deletion of components – acts upon requests to connect/disconnect components – maintains a system graph of the components currently in use • The explicit maintenance of dynamic dependencies between components provides the support for introspection and reconfiguration of component configurations. • The reflective interfaces of Open. COM follow 3 metamodels: the Interface meta-model (IMeta. Interface), the Architecture meta-model (IMeta. Architecture) and the Behaviour meta-model (IMeta. Interception).

More on Open. COM … • • Open. COM page: http: //www. comp. lancs. ac. uk/computing/research/mpg/reflection/opencom. php [Open. COMv 1] Clarke, M. , Blair, G. S. , Coulson, G. , and Parlavantzas, N. 2001. An Efficient Component Model for the Construction of Adaptive Middleware. In Proceedings of the IFIP/ACM international Conference on Distributed Systems Platforms Heidelberg (November 12 - 16, 2001). R. Guerraoui, Ed. Lecture Notes In Computer Science, vol. 2218. Springer-Verlag, London, 160 -178. [Open. COMv 2] Coulson, G. , Blair, G. , Grace, P. , Taiani, F. , Joolia, A. , Lee, K. , Ueyama, J. , and Sivaharan, T. 2008. A generic component model for building systems software. ACM Trans. Comput. Syst. 26, 1 (Feb. 2008), 1 -42. DOI=http: //doi. acm. org/10. 1145/1328671. 1328672

Reflection – Tipare de proiectare detaliata • Tiparul arhitectural reflection nu impune / nu precizeaza anumite metode de proiectare/implementare • Tipare/metode/idei pentru proiectarea detaliata: – Dirk Riehle, Michel Tilman, Ralph Johnson: The Dynamic Object Model, PLOP 2000, http: //hillside. net/plop 2 k/proceedings/Riehle. pdf – Joseph Yoder, Ralph Johnson: The Adaptive Object-Model Architectural Style, WICSA 2002, http: //www. adaptiveobjectmodel. com/WICSA 3/Architecture. Of. AOMs. WICSA 3. pdf

Dynamic Object Model • Obiectiv: posibilitatea de a efectua urmatoarele modificari, la runtime, asupra tipurilor obiectelor unei aplicatii: – Adaugarea unui nou tip – Modificarea unui tip existent (adaugare de noi atribute) – Modificarea relatiilor intre tipuri • Solutia: Dynamic Object Model (Adaptive Object Model, Runtime Domain Model) – Compus din pattern-urile Type Object si Property List – Bibliografie: • D. Riehle, M. Tilman, R. Johnson: Dynamic Object Model, PLOP 2000 http: //hillside. net/plop 2 k/proceedings/Riehle. pdf

Exemplu • • Problema: Gestionarea conturilor bancare Modelarea tipurilor de conturi sub forma unei ierarhii de clase este neconvenabila, pentru ca: – Exista un numar mare de tipuri de conturi (500) – Nu toate tipurile de conturi sunt cunoscute de la inceput, sau pot suferi modificari – Daca se doreste crearea unui nou tip de cont, trebuie facute operatii la nivelul codului sursa (crearea unui nou subtip)

Solutia Dynamic Object Model Pattern = Type Object Pattern + Property List Pattern

Type Object • Abordarea clasica OO: cate o subclasa pentru fiecare tip nou. – Introducerea unui tip nou necesita scrierea de cod • Metaclasa Component. Type: instante ale acestei clase inlocuiesc subclasele – Introducerea unui tip nou se poate face la runtime – Se poate face modificarea tipului unui obiect la runtime (de exemplu un cont este transformat din Checking. Account in VIPAccount) • Aici se adauga problema mai complexa a convertirii atributelor, dar prin Type. Object controlul ii apartine utilizatorului

Type Object - Exemplu Savings. Account. Type=new Account. Type(“Savings. Account”) Savings. Account 1 = new Account(Savings. Account. Type); Savings. Account 2 = new Account(Savings. Account. Type); Current. Account. Type=new Account. Type(“Current. Account”); Current. Account 1 = new Account(Current. Account. Type);

Property List • Instante ale acelaiasi clase au tipuri diferite de atribute • Este posibila adaugarea sau stergerea de atribute la runtime

Property List - Exemplu Account 1=new Account(); Account 1. add. Property(“Overdraw. Limit”, Float. class, new Float(1000. 0)); Account 2 = new Account(); Account 2. add. Property(“Deposit. Term”, Integer. class, new Integer(12));

Solutie exemplu conturi bancare Type Object: Account. Type: se pot crea in mod dinamic diferite tipuri de conturi Properties. List: fiecare cont are propriul set personalizat de atribute Type Object: Property. Type: controleaza ce tipuri de atribute sunt permise pentru un anumit tip de cont

Solutie exemplu conturi bancare Property. Type Overdraw. Limit = new Property. Type("overdraw. Limit", Integer. class); Property. Type Deposit. Term = new Property. Type("deposit. Term", Integer. class); Property. Type Owner. Name = new Property. Type("owner. Name", String. class); Account. Type Savings. Account = new Account. Type("Savings. Account"); Savings. Account. add. Property. Type(Deposit. Term); Savings. Account. add. Property. Type(Owner. Name); Account. Type Anonymous. Savings. Account = new Account. Type("Anonymous. Savings. Account"); Anonymous. Savings. Account. add. Property. Type(Deposit. Term); Account. Type Current. Account = new Account. Type("Current. Account"); Current. Account. add. Property. Type(Overdraw. Limit); Account a. Savings. Account 1 = new Account(Savings. Account); Account a. Savings. Account 2 = new Account(Savings. Account); Account a. Current. Account = new Account(Current. Account); a. Savings. Account 1. set. Property("deposit. Term", new Integer(12)); a. Savings. Account 1. set. Property(“overdraw. Limit”, new Integer(1000)); // proprietate nepermisa a. Savings. Account 1. set. Property(“owner. Name”, new Integer(100)); // valoare incompatibila

Solutie exemplu conturi bancare Property. Type Overdraw. Limit = new Property. Type("overdraw. Limit", Integer. class); Property. Type Deposit. Term = new Property. Type("deposit. Term", Integer. class); Property. Type Owner. Name = new Property. Type("owner. Name", String. class); Account. Type Savings. Account = new Account. Type("Savings. Account"); Savings. Account. add. Property. Type(Deposit. Term); Savings. Account. add. Property. Type(Owner. Name); Account. Type Anonymous. Savings. Account = new Account. Type("Anonymous. Savings. Account"); Anonymous. Savings. Account. add. Property. Type(Deposit. Term); Implementarea lui set. Property (si a altor operatii) poate si Account. Type Current. Account = new Account. Type("Current. Account"); trebuie sa faca astfel de Current. Account. add. Property. Type(Overdraw. Limit); verificari ! Account a. Savings. Account 1 = new Account(Savings. Account); Account a. Savings. Account 2 = new Account(Savings. Account); Account a. Current. Account = new Account(Current. Account); a. Savings. Account 1. set. Property("deposit. Term", new Integer(12)); a. Savings. Account 1. set. Property(“overdraw. Limit”, new Integer(1000)); // proprietate nepermisa a. Savings. Account 1. set. Property(“owner. Name”, new Integer(100)); // valoare incompatibila

Dynamic Object Model (Type Square) Meta Level, Knowledge Level Base Level, Operational Level

Pasi de definire a unei arhitecturi reflective cf [POSA] • Exemplu: Pentru problema Dynamic Object Model 1. Identificarea comportamentului variabil • posibilitatea de a efectua urmatoarele modificari, la runtime, asupra tipurilor obiectelor unei aplicatii: – Adaugarea unui nou tip – Modificarea unui tip existent (adaugare de noi atribute) 2. Identificarea aspectelor care nu variaza/nu au voie sa se modifice 3. Definirea metaobiectelor • Component. Type (Account. Type), Property. Type 4. Definirea Meta. Object. Protocol (MOP) • Functii care modifica meta-layer: – New Account. Type – New Property. Type – Account. Type. add. Property. Type • Functii care returneaza info din meta-layer – Account. get. Type – Account. get. Property. Types

Pasi de definire a unei arhitecturi reflective cf [POSA] • Exemplu: Pentru problema Dynamic Object Model 1. Identificarea comportamentului variabil • posibilitatea de a efectua urmatoarele modificari, la runtime, asupra tipurilor obiectelor unei aplicatii: – Adaugarea unui nou tip – Modificarea unui tip existent (adaugare de noi atribute) 2. Identificarea aspectelor care nu variaza/nu au voie sa se modifice 3. Definirea metaobiectelor • Component. Type (Account. Type), Property. Type 4. Definirea Meta. Object. Protocol (MOP) • Functii care modifica meta-layer: – New Account. Type – New Property. Type – Account. Type. add. Property. Type • Functii care returneaza info din meta-layer – Account. get. Type – Account. get. Property. Types

Dynamic Object Model - Concluzii • Avantaje: – Permite modificari: • • • Runtime typing Runtime object type creation Domain-speciffic typing Controlled dynamic type changing Runtime component type modification – Reduce numarul de clase • Dezavantaje – Creste numarul de obiecte – Increased design complexity – Increased runtime complexity • Limitari: – se ocupa exclusiv de partea structurala ! -> vezi completarile ulterioare

The Adaptive Object-Model Architectural Style • Aduce completari peste Dynamic Object Model: – Business Rules – Interpreters • Modelarea completa a unui Domain Model: metadatele reprezinta tipurile cu atributele, relatiile si comportamentul lor • Descrierea unui Domain Model este facuta de un non-programator, intr-un limbaj de descriere – Descriera poate fi stocata, modificata, etc – Descrierea este interpretata de un Interpreter la runtime – Interpretorul (interpretoarele) sunt necesare in 2 locuri: • Initializarea/modificarea metaobiectelor care descriu domeniul • Crearea de obiecte ale nivelului de baza si aplicarea business rules • Bibliografie: – Joseph Yoder, Ralph Johnson: The Adaptive Object-Model Architectural Style, WICSA 2002, http: //www. adaptiveobjectmodel. com/WICSA 3/Architecture. Of. AOMs. WICSA 3. pdf

Representing Business Rules • Business Rules pot fi reprezentate sub forma unor Strategy/Rule. Object/Composite de Rule. Object atasate la Entity. Type (Component. Type) • Descrierea Business Rules face parte din Domain Model

Adaptive Object Model - Concluzii • Avantaje: – Potrivit daca sistemul e in continua schimbare – Utilizatorii (non-programmers) pot modifica la runtime business model-ul • Dezavantaje: – Complex, mai ales datorita tool-urilor de suport (Interpretoare, GUI, Domain Specific Languages) necesare pentru a-l face util – Performanta (timp executie)

Bibliografie Reflection • Bibliografie: – Tiparul arhitectural reflection, generalitati: • [POSA 1] – Metode/Tipare pentru proiectarea detaliata a metaobiectelor: • Dirk Riehle, Michel Tilman, Ralph Johnson: The Dynamic Object Model, PLOP 2000, http: //hillside. net/plop 2 k/proceedings/Riehle. pdf • Joseph Yoder, Ralph Johnson: The Adaptive Object-Model Architectural Style, WICSA 2002, http: //www. adaptiveobjectmodel. com/WICSA 3/Architecture. Of. AOMs. WICSA 3. pdf