Continutul cursului Conceptul de arhitectura software

Prezentarea pe tema: "Continutul cursului Conceptul de arhitectura software"— Transcriere de prezentare:

1 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

2 Tema 2 laborator Subiectul: Reflection
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.

3 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.

4 Reflection Bibliografie:
Tiparul arhitectural reflection, generalitati: [POSA1] Metode/Tipare pentru proiectarea detaliata a metaobiectelor: Dirk Riehle, Michel Tilman, Ralph Johnson: The Dynamic Object Model, PLOP 2000, Joseph Yoder, Ralph Johnson: The Adaptive Object-Model Architectural Style, WICSA 2002,

5 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.

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

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

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

9 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-meta-….

10 Tipuri de Reflection

11 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 FunctionCallPolicy Behavioural manipulation: Pot modifica la runtime metaobiectul de tip FunctionCallPolicy, modificand la runtime semantica apelurilor de functii (cu transmiterea param prin referinta <-> cu transmiterea param princopiere)

12 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 FunctionCallPolicy Behavioural manipulation: Pot modifica la runtime metaobiectul de tip FunctionCallPolicy, modificand la runtime semantica apelurilor de functii (cu transmiterea param prin referinta <-> cu transmiterea param princopiere)

13 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

14 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

15 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

16 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++)

17 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

18 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

19 Pasi importanti de definire a unei arhitecturi reflective
Identificarea comportamentului variabil Identificarea aspectelor care nu variaza/nu au voie sa se modifice Definirea metaobiectelor Definirea MetaObjectProtocol (MOP) 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: Integrat in metaobiecte (fiecare metaobiect furnizeaza o parte a functiilor din MOP) Ca si componenta separata de control Definirea Base Level

20 Exemplu Persistence Component: Pasi 1-2:
Identificarea comportamentului variabil 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

21 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 … )

22 Sursa de inspiratie: schita de implementare a serializarii in Java
public void scrie(Object obj) throws Exception { Class c = obj.getClass(); System.out.println("numele clasei "+c.getName()); Field fields [] = c.getDeclaredFields(); int i; for (i = 0; i < fields.length; i++) { System.out.print("numele campului: " + fields[i].getName()+" "); c = fields[i].getType(); fields[i].setAccessible(true); if (c.isPrimitive()) { // determina exact tipul primitiv si ia valoarea // … } else if (c.isArray()) { System.out.println(“camp de tip array cu elemente de tipul "+c.getComponentType()); // … in functie de tipul elementelor tabloului – daca e primitiv sau nu …. // .. else { System.out.println("tipul campului: neprimitiv "+c.getName()); Object fo=fields[i].get(obj); this.scrie(fo);

23 Determinarea metaobiectelor (1)
Principalele operatii pentru a scrie un obiect: 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

24 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 ObjectCreator (oarecum similar cu ce face Class.newInstance) 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: ObjectCreator, Type-Info, Data-Info

25 Determinarea metaobiectelor (3)
Principalele metaobiecte: Type-Info Data-Info ObjectCreator Base-Info: ofera functii pentru accesarea informatiilor despre clasele de baza ale clasei curente

26 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

27 Exemplu Persistence Component: Pas 4:
4. Definirea MetaObjectProtocol (MOP): Functii care modifica meta-layer: Crearea unui nou metaobiect de tip Type-Info pornind de la un nume (identificator) newTypeId(typeName) Modificarea unui metaobiect de tip Type-Info pentru adaugarea unor informatii despre tip newTypeInfo(typeName, isBuiltIn, isPointer) Crearea unui metaobiect de tip Base-Info si modificarea unui metaobiect de tip Type-Info pentru reprezentarea relatiilor de mostenire addBase(typeName, baseName) Crearea unor metaobiecte corespunzatoare membrilor unui tip, mofificarea metaobiectului Type-Info corespunzator: addData (typeName, memberTypeName, memberName) Modificarea metaobiectului ObjectCreator: addCreationCode(typeName) Functii care returneaza info din meta-layer ObjectCreator.createObject(typeName) -> BaseLevelObject, TypeInfo TypeInfo.isBuiltIn TypeInfo.getData -> TypeInfo

28 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

29 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

30 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)

31 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: OpenORB, TAO Reflective Component frameworks: OpenCOM, Fractal

32 Exemplu de arhitectura reflectiva: OpenCOM 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)

33 Exemplu – sistem alcatuit prin compunerea de componente

34 The architecture of OpenCOM

35 OpenCOM Runtime OpenCOM deploys a standard runtime substrate
Functions of the OpenCOM 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 OpenCOM follow 3 metamodels: the Interface meta-model (IMetaInterface), the Architecture meta-model (IMetaArchitecture) and the Behaviour meta-model (IMetaInterception).

36 More on OpenCOM … OpenCOM page: [OpenCOMv1] Clarke, M., Blair, G. S., Coulson, G., and Parlavantzas, N An Efficient Component Model for the Construction of Adaptive Middleware. In Proceedings of the IFIP/ACM international Conference on Distributed Systems Platforms Heidelberg (November , 2001). R. Guerraoui, Ed. Lecture Notes In Computer Science, vol Springer-Verlag, London, [OpenCOMv2] Coulson, G., Blair, G., Grace, P., Taiani, F., Joolia, A., Lee, K., Ueyama, J., and Sivaharan, T A generic component model for building systems software. ACM Trans. Comput. Syst. 26, 1 (Feb. 2008), DOI=

37 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, Joseph Yoder, Ralph Johnson: The Adaptive Object-Model Architectural Style, WICSA 2002,

38 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, PLOP2000

39 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)

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

41 Type Object Abordarea clasica OO: cate o subclasa pentru fiecare tip nou. Introducerea unui tip nou necesita scrierea de cod Metaclasa ComponentType: 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 CheckingAccount in VIPAccount) Aici se adauga problema mai complexa a convertirii atributelor, dar prin TypeObject controlul ii apartine utilizatorului

42 Type Object - Exemplu SavingsAccountType=new AccountType(“SavingsAccount”) SavingsAccount1 = new Account(SavingsAccountType); SavingsAccount2 = new Account(SavingsAccountType); CurrentAccountType=new AccountType(“CurrentAccount”); CurrentAccount1 = new Account(CurrentAccountType);

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

44 Property List - Exemplu
Account1=new Account(); Account1.addProperty(“OverdrawLimit”, Float.class, new Float(1000.0)); Account2 = new Account(); Account2.addProperty(“DepositTerm”, Integer.class, new Integer(12));

45 Solutie exemplu conturi bancare
Type Object: AccountType: se pot crea in mod dinamic diferite tipuri de conturi PropertiesList: fiecare cont are propriul set personalizat de atribute Type Object: PropertyType: controleaza ce tipuri de atribute sunt permise pentru un anumit tip de cont

46 Solutie exemplu conturi bancare
PropertyType OverdrawLimit = new PropertyType("overdrawLimit", Integer.class); PropertyType DepositTerm = new PropertyType("depositTerm", Integer.class); PropertyType OwnerName = new PropertyType("ownerName", String.class); AccountType SavingsAccount = new AccountType("SavingsAccount"); SavingsAccount.addPropertyType(DepositTerm); SavingsAccount.addPropertyType(OwnerName); AccountType AnonymousSavingsAccount = new AccountType("AnonymousSavingsAccount"); AnonymousSavingsAccount.addPropertyType(DepositTerm); AccountType CurrentAccount = new AccountType("CurrentAccount"); CurrentAccount.addPropertyType(OverdrawLimit); Account aSavingsAccount1 = new Account(SavingsAccount); Account aSavingsAccount2 = new Account(SavingsAccount); Account aCurrentAccount = new Account(CurrentAccount); aSavingsAccount1.setProperty("depositTerm", new Integer(12)); aSavingsAccount1.setProperty(“overdrawLimit”, new Integer(1000)); // proprietate nepermisa aSavingsAccount1.setProperty(“ownerName”, new Integer(100)); // valoare incompatibila

47 Solutie exemplu conturi bancare
PropertyType OverdrawLimit = new PropertyType("overdrawLimit", Integer.class); PropertyType DepositTerm = new PropertyType("depositTerm", Integer.class); PropertyType OwnerName = new PropertyType("ownerName", String.class); AccountType SavingsAccount = new AccountType("SavingsAccount"); SavingsAccount.addPropertyType(DepositTerm); SavingsAccount.addPropertyType(OwnerName); AccountType AnonymousSavingsAccount = new AccountType("AnonymousSavingsAccount"); AnonymousSavingsAccount.addPropertyType(DepositTerm); AccountType CurrentAccount = new AccountType("CurrentAccount"); CurrentAccount.addPropertyType(OverdrawLimit); Account aSavingsAccount1 = new Account(SavingsAccount); Account aSavingsAccount2 = new Account(SavingsAccount); Account aCurrentAccount = new Account(CurrentAccount); aSavingsAccount1.setProperty("depositTerm", new Integer(12)); aSavingsAccount1.setProperty(“overdrawLimit”, new Integer(1000)); // proprietate nepermisa aSavingsAccount1.setProperty(“ownerName”, new Integer(100)); // valoare incompatibila Implementarea lui setProperty (si a altor operatii) poate si trebuie sa faca astfel de verificari !

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

49 Pasi de definire a unei arhitecturi reflective cf [POSA]
Exemplu: Pentru problema Dynamic Object Model 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) Identificarea aspectelor care nu variaza/nu au voie sa se modifice Definirea metaobiectelor ComponentType (AccountType), PropertyType Definirea MetaObjectProtocol (MOP) Functii care modifica meta-layer: New AccountType New PropertyType AccountType.addPropertyType Functii care returneaza info din meta-layer Account.getType Account.getPropertyTypes

50 Pasi de definire a unei arhitecturi reflective cf [POSA]
Exemplu: Pentru problema Dynamic Object Model 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) Identificarea aspectelor care nu variaza/nu au voie sa se modifice Definirea metaobiectelor ComponentType (AccountType), PropertyType Definirea MetaObjectProtocol (MOP) Functii care modifica meta-layer: New AccountType New PropertyType AccountType.addPropertyType Functii care returneaza info din meta-layer Account.getType Account.getPropertyTypes

51 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

52 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,

53 Representing Business Rules
Business Rules pot fi reprezentate sub forma unor Strategy/RuleObject/Composite de RuleObject atasate la EntityType (ComponentType) Descrierea Business Rules face parte din Domain Model

54 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)

55 Bibliografie Reflection
Tiparul arhitectural reflection, generalitati: [POSA1] Metode/Tipare pentru proiectarea detaliata a metaobiectelor: Dirk Riehle, Michel Tilman, Ralph Johnson: The Dynamic Object Model, PLOP 2000, Joseph Yoder, Ralph Johnson: The Adaptive Object-Model Architectural Style, WICSA 2002,