Sisteme adaptabile

1. Sisteme adaptabile • Sistem adaptabil: 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 adaptabile: • 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.

2. Microkernel Microkernel: suport pentru adaptarea la cerinte diferite; separa un nucleu functional esential minimal de restul functionalitatilor. Nucleul are locuri in care se pot insera extensii. Exemplu tipic: dezvoltarea unui sistem de operare (Hydra), cu urmatoarele cerinte: • Portabilitate pe diferite sisteme hardware • Posibilitatea de a rula aplicatii scrise pentru diferite sisteme de operare => emularea acestor sisteme de operare • Emularea unui sistem de operare: servere care implementeaza vederi diferite ale aceluiasi nucleu functional

3. Exemplu microkernel – SO Hydra

4. Kernel Monolitic vs Microkernel

5. Microkernel – problema generala • Context: dezvoltarea unor aplicatii diferite, care utilizeaza API-uri similare ca si tipuri de functionalitati, construite peste acelasi nucleu de functionalitati de baza • Problema tipica careia i se potriveste tiparul Microkernel: problema de tip “application platform” • Dintr-un domeniu de aplicatie unde exista mai multe “standarde” si tehnologii oarecum similare. • Cu o durata de viata mare, timp in care trebuie sa integreze noi tehnologii si sa permita evolutia celor existente; • Trebuie sa aiba o portabilitate ridicata pe diferite platforme • Este de dorit sa poata rula aplicatii dezvoltate pentru standarde diferite: sa poata asigura vederi diferite (conforme cu fiecare standard in parte) ale functionalitatilor esentiale implementate • Domenii de aplicatii: sisteme de operare; aplicatii financiare; baze de date; aplicatii grafice

6. Microkernel – Elementele solutiei [POSA]-Fig/P.174

7. Microkernel - Structura [POSA]-Fig/P.178

8. Exemplu: Elementele SO Hydra • Microkernel: • Elementul central al tiparului • Implementeaza serviciile centrale: gestionarea resurselor (procese, fisiere), controlul si coordonarea accesului la resurse, facilitati de comunicare • Ascunde detaliile platformei hardware • Terminologie: • “mechanisms”: serviciile atomice implementate de Microkernel • “policies”: functionalitati mai complexe, contruite pe baza mecanismelor • De exemplu, Hydra poate emula 2 alte sisteme de operare, care au politici diferite (policies) de creare a proceselor: • Un proces fiu este creat ca o clona a intregului spatiu de adrese a parintelui • Un proces fiu nu primeste o copie a spatiului de adrese al parintelui • Se implementeaza in nucleu doar mecanismele: servicii atomice pentru • Creare de procese • Clonare a unui spatiu de adrese • Acestea sunt combinate ulterior pentru a obtine policies care trebuie emulate

9. Exemplu: Elementele SO Hydra • Internal servers (subsystems): • Implementeaza functionalitati din categoria celor de baza dar care sunt separate in componente diferite pentru a nu creste complexitatea nucleului • De exemplu: drivere • Implementeaza functionalitati mai complexe, care se doreste sa fie activate de Microkernel numai atunci cand sunt necesare • Elementele de tip internal server sunt accesibile doar pentru nucleu • External servers (personalities): • Elemente care utilizeaza nucleul pentru a implementa propriile vederi asupra domeniului. • Implementeaza policy-uri diferite • Au interfete (API-uri) proprii, prin care primesc de la clienti cereri de servicii. Executa aceste cereri, utilizand mecanismele furnizate de nucleu, si returneaza rezultatele clientilor lor. • Exemple de external servers pentru Hydra: • UNIX external server : utilizeaza mecanismele furnizate de nucleul Hydra pentru a exporta un set complet de apeluri sistem de tip UNIX • Windows external server : utilizeaza mecanismele furnizate de nucleul Hydra pentru a exporta un set complet de apeluri sistem de tip Windows

10. Exemplu: Elementele SO Hydra • Client: o aplicatie asociata cu un anumit server extern. Acceseaza API-ul furnizat de acesta. • Adapters (Emulators): intre Client si External server: • Cand un client solicita un serviciu de la un external server, este task-ul adapter-ului sa redirecteze apelul catre serverul in cauza • Datorita adapter-ului, un client nu va sti daca ruleaza pe un sistem nativ Unix sau pe Hydra care furnizeaza un External server de Unix

11. Scenariu – Client apeleaza External Server [POSA]-Fig/P.179

12. Scenariu – External S. utilizeaza Internal S. [POSA]-Fig/P.180

13. Proprietati ale arhitecturii Microkernel • Avantaje: • High Portability: daca se porteaza nucleul pe o noua platforma nu mai trebuie facute modificari la external servers si aplicatiile client • Flexibility and Extensibility: adaugarea unei noi vederi => adaugarea unui nou external server • Separation of policy and mechanism: • Atentionari: • Performance: mai slaba decat in cazul unui sistem monolitic care trateaza in exclusivitate un singur view • Complexity of design and implementation: este dificil de prevazut setul complet de mecanisme care trebuie incluse in nucleu

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

15. Reflection - Solutia • Sistemul software devine self-aware: 2 nivele: • Meta level: • furnizeaza o auto-reprezentare a sistemului software, ii permite acestuia sa-si cunoasca propria structura si propriul comportament (sa devina “self-aware”) • Consta din Meta-obiecte: un metaobiect face anumite categorii de informatii explicit accesibile si eventual modificabile • Exemple: in Java: Class, Method, Field • Informatii care ar mai putea fi retinute in meta-level-ul unui limbaj reflectiv: de ex, mecanisme de apel de functii • 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: • 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 - Elementele [POSA]-Fig/P.197

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

18. Problema: Adaugarea facilitatii de serializare a obiectelor (stocare a unui obiect pe disc si citire a unui obiect) intr-un limbaj care nu suporta acest lucru (C++) Solutia slaba: se specifica cum se stocheaza si citeste fiecare tip de date din aplicatie: de fiecare data cand se schimba structura claselor trebuie modificate aceste functii Reflection – Exemplu problema [POSA]-Fig/P.193

19. Reflection – Exemplu problema • Solutie dorita de serializare: adaugarea la limbaj a unei componente care asigura persistenta, independenta de structura tipurilor; • 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. • Problema: stabilirea tipurilor necesare de metaobiecte (ce metainformatii sunt necesare ?)

20. Solutia problemei exemplu • 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). • De ex: pentru a scrie un obiect: • E nevoie sa se poata afla clasa caruia ii apartine => Este nevoie de un metaobiect de tip 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 Class sa se obtina metaobiecte de tip Field • Pentru fiecare camp de date, daca nu este de un tip primitiv al limbajului, se va aplica recursiv pasii 1-2 • Daca un camp de date este de un tip primitiv al limbajului, se ia valoarea campului • De ex: 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 “Creator de obiecte”: Class.newInstance • Se afla structura interna a obiectului (campurile de date) • 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

21. 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); } }

22. Exemplu: Scenariu pentru regasirea 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

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

24. Proprietati ale tiparului Reflection • Avantaje: • Permite modificarea sistemului fara modificarea codului sursa • Atentionari: • Modificarile facute la MetaLevel pot cauza erori • Numar crescut de componente. Posibil mai multe componente in meta-level decat in base-level

25. 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 • J. Yoder, R. Johnson: The Adaptive Object-Model Architectural Style, WICSA 2003

26. 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)

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

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

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

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

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

32. 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 = newAccountType("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

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