Runtime Verification  2

Texto

(1)

(2) Agenda  1. Runtime Verification  2. Paradigma MOP.  3. Java MOP  4. SOA Monitoring  5. Concluzii.

(3) 1. Runtime Verification  Notiunea de verificare implica trei tehnici de baza:  demonstrarea teoremelor – permite demonstrarea corectitudinii. unui program prin utilizarea mecanismelor matematice  model checking – metoda automata de verificare, se aplica in. special sistemelor cu stari finite; se bazeaza pe logici temporale  testarea – denota procesul de gasire a bugg-urilor unui sistem.

(4) 1. Runtime Verification vs Model Checking  Idea logicilor temporale – o formula nu este adevarata sau falsa. intr-o maniera statica intr-un model (contraex. LP)  Modelele logicilor temporale contin cateva stari, iar o formula. poate fi adevarata in unele dintre aceastea si falsa in altele.  Modelul este un sistem tranzitional, iar proprietatile formule. temporale..

(5) 1. Runtime Verification vs Model Checking  Verificarea unui sistem implica urmatorii pasi:  folosim un limbaj descriptiv a model checker-ului.  codificam proprietatea(ile) vizate utilizand limbajul de specificatie. a model checker-ului  rulam model checker-ul, avand ca input: modelul si formulele.

(6) 1. Runtime Verification  Verificarea la runtime este privita ca o tehnica de verificare. usoara, complementara tehnicilor de tipul: model checking si testare.  Un esec software ("software failure") este o deviatie dintre un. comportament observat si comportamentul necesar al unui sistem software.  Un "fault" este identificat de catre deviatia starii curente in raport cu. starea asteptata a sistemului.  O eroare este o greseala ce apartine programatorului, greseala ce rezulta intr-un “fault” si posibil intr-un esec..

(7) 1. Runtime Verification - Monitoare  Verificarea la runtime vizeaza doar detectarea violarii sau. respectarii proprietatilor de corectitudine.  In literatura de specialitate executia unui sistem software ("run") este. privita ca o posibila secventa infinita de stari ale sistemului.  Starile pot fi alcatuite din asignari de variabile sau secvente de actiuni emise si efectuate de catre un sistem.  Formal, o executie este considerata ca un posibil cuvant infinit sau. trace.  Executia unui sistem este un prefix finit al acelui run, trace finit..

(8) 1. Runtime Verification - Monitoare  Verificarea executiei unui sistem in raport cu o proprietate de. corectitudine este responsabilitatea unui monitor.  Functionalitatea de baza a unui astfel de monitor este de a decide. daca executia curenta satisface o anumita proprietate.  Putem extrapola si afirma ca verificarea la runtime din punct de. vedere matematic si formal incearca dezvoltarea de tehnici capabile sa ofere un raspuns in ceea ce priveste incluziunii unui cuvant (trace) intr-un limbaj (set de stari ale unui sistem)..

(9) 1. Runtime Verification - Monitoare  Monitorizare online - implica folosirea unui monitor pentru a. verifica executia curenta a unui sistem.  Monitorizare offline - implica folosirea unui monitor pentru a. multime finita de executii inregistrate  In ceea ce priveste verificarea la runtime, monitoarele sunt. generate automat dintr-o specificatie de nivel inalt..

(10) 1. Runtime Verification - „Safety properties”  Prin conceptul de proprietate de siguranță se încearcă. surprinderea unui proprietăți comportamentale corelată cu trace-uri de execuției  Caracteristica de bază este dată de faptul că odată încălcată. (proprietatea), aceasta nu mai poate fi satisfăcută  Proprietatile de siguranta pot fi aplicate peste trace-uri finite. si/sau infinite.

(11) 1. Runtime Verification – Definire formala monitoare  sintaxa formală: Ḿ=(S, s0, M: S x ∑ → S)  un monitor este un automat specializat, fară stări terminale  proprietăți ale unui monitor:  Ĺ*( Ḿ ) = { w ϵ ∑* | M (s0,w) ↓}  Ĺ (Ḿ ) = { u ϵ ∑ | M (s0,w) ↓} for all w ϵ prefixes(u)}.  Ĺ*, (Ḿ ) = Ĺ*( Ḿ )  Ĺ ( Ḿ ).

(12) 1. Runtime Verification – Definirea mecanismului de functionare a monitoarelor  ideea generală de funcționare a unui monitor este:  automatul specializat, va fi declanșat de evenimentele generate de către. sistemul observant (în mod concret sistemul este reprezentat de literele din ∑)  fiecare eveniment nou primit trece monitorul din starea curentă în altă stare  trecerea este dictată de funcția de tranziție M  dacă monitorul se blochează (mai exact în cazul în care funcția de tranziție este nedefinită pe starea curentă și evenimentul curent), proprietatea monitorizată este declarată ca fiind încălcată în acel punct  procesul de monitorizare este descris de necesitatea verificării apartenței unui. cuvânt w ϵ ∑* la prefixes(w), unde prefixes(w): ∑* → Ƥ(∑*).

(13) 1. Runtime Verification – Amendament  Sisteme tranzitionale (modele software)  Forma generala: Ḿ= (S, →, L) – S –multimea starilor; → relatie binara (relatie de tranzitie); L – functie de etichetare L: S -> Ƥ(Atoms). Pentru fiecare stare s, avem și o multime de propoziții atomice L(s), propoziții ce dețin valoarea de adevăr pentru starea s.. Tranzițiile sunt: so → s1, so → s2, s1 → s0, s1 → s2, s2 → s2. Etichetele sunt: L(so)={a,b}, L(s1)={b,c}, L(s2)={c}.

(14) 2. Monitoring-Oriented Programming  Modelul MOP.

(15) 2. Monitoring-Oriented Programming  Din perspectiva paradigmei MOP, cerintele unui sistem apar sub. forma unor specificații formale, aceste specificații prezentânduse ca adnotări.  Flexibilitatea acestei abordări constă în faptul că respectivele. adnotări pot fi inserate în diferite locatii ale programului (în sensul unui sistem software); locurile de insertie sunt definite de catre programator..

(16) 2. Monitoring-Oriented Programming  Pe baza specificatiilor formale se va genera un asa-numit „cod de. monitorizare”, acest cod este acelasi cu limbajul de implementare al sistemului peste care vrem să adaugam monitoarele.  Evenimentele (element de sintaxă din cadrul unei specificații. MOP –„event”) sunt cele care facilitează verificarea proprietăților la diferite locuri în cod.  Un monitor trebuie privit sub forma unui automat specializat,. fară stări terminale..

(17) 2. Monitoring-Oriented Programming  Sintaxa generala a unei specificatii MOP.

(18) 2. Monitoring-Oriented Programming  Prima componentă (header-ul) va contine informatii despre. procesul de monitorizare, generare si integrare. Pot fi adăugate si informatii privitoare la scopul si logica folosită la definirea unor proprietati in vederea monitorizarii.  În cea de a doua componenta (corpul) proprietatile monitorizate. sunt declarate, acele formule vor fi asociate cu anumite plug-inuri logice, în concordanta cu semnatica formala utilizata.  Ultima componentă (handler-ul) este reprezentată de codul. declarat de programator pentru cazul in care proprietatea este respectata sau incalcata..

(19) 3. JavaMOP  Tool ce faciliteaza declararea de specificatii MOP, in urma. procesului de generare vom avea un cod de monitorizare cu sintaxa specifica limbajului de programare Java.  La nivel de arhitectura JavaMOP prezinta o structura de tip. client-server:  partea de client contine un modul pentru interfata si procesorul de. specificatii, special dezvoltat pentru JavaMOP  partea de server conține un dispecer de mesaje si plug-in-uri logice. pentru Java, acestea suporta formalisme ca: ptLTL, ftLTL, ERE si CGF.

(20) 3. JavaMOP  Principalul rol al acestei tehnologii este de a translata output-ul. furnizata de egine-urile logice in aspecte (sintaxa este una proprietara AspectJ). Etapa finala de integrare apartine compilatorului AspectJ care are rolul de a unifica programul original cu aspectele generate..

(21) 3. JavaMOP.

(22) 3. JavaMOP.

(23) 3. JavaMOP  Exemplu nr.1 (din care reiese necesitatea folosirii JavaMOP) Vector v=new Vector(); v.add(new Integer(10)); Iterator i =v.iterator(); v.add(new Integer(20)); System.out.println(i.next()); JVM: ConcurentModificationException Proprietatea unui iterator: fail-fast.

(24) 3. JavaMOP – exemplu nr.1  package mop;. import java.io.*; import java.util.*; HasNext(Iterator i) { event hasnext after(Iterator i) : call(* Iterator.hasNext()) && target(i) {} event next before(Iterator i) : call(* Iterator.next()) && target(i) {}. ptltl : next implies (*) hasnext @violation { System.out.println("next called without hasNext!"); } }. Specificatia monitorului.

(25) 3. JavaMOP – exemplu nr.2  monitorizarea unei proprietăți ptLTL de forma : (b→ • a), unde în cazul de față b. reprezintă returnarea unei liste de produse, iar a reprezintă autentificarea  rolul proprietății de mai sus este de a verifica accesul la o resursă în contextul unui SW package mop; import searchFarm.ServiciuWebSearchFarm IsAuthentificated(ServiciuWebSearchFarm swsf ) { event authenticate before(ServiciuWebSearchFarm swsf ) : call(* ServiciuWebSearchFarm.authenticate()) && target(swsf ) {} event getFarmProdList after(ServiciuWebSearchFarm swsf ) : call(* ServiciuWebSearchFarm.getFarmProdList()) && target(swsf ) {} ptltl : getFarmProdList implies (*) authenticate @violation { System.out.println("Operatia nu poate fi realizata fara a fi autentificat!"); } }.

(26) 4. SOA Monitoring  Consta in folosirea paradigmei MOP pentru tehnologiile. specifice “Service Oriented Arcitecture“:  Servicii Web  Procese de afaceri  Componente software.

(27) 4. SOA – Definire concepte  Conceptul. fundamental al SOA este acela de serviciu, proprietățile sale putând fi enumerate (de menționat că un serviciu este privit sub forma unei componente software):  este definit de o interfata ce poate fi independenta de platforma  este accesibil folosind o retea.  operatiile definite in interfata vor realiza operatiile esentiale. („business functions”), realizarea lor vizand obiectele de tip business  interfata unui serviciu si implementarea acestuia pot fi „decorate” cu extensii ce isi vor face simtita prezenta la „runtime”..

(28) 4. SOA – Proprietati generale ale unui serviciu  Interfata independenta de platforma: functionalitatea unui. serviciu trebuie definita de catre o interfata externa. Principalul rol al unui serviciu este acela de a adresa si de a rezolva aspecte legate de integrare.  Accesibil prin intermediul unei retele: este un principiu. fundamental si consta in capacitatea de a accesa functionalitătile unui serviciu intr-o manieră remote..

(29) 4. SOA – Proprietati generale ale unui serviciu  Operatii realizate asupra „business object”-urilor: aceasta. proprietate se refera la indeplinirea/executia unor functionalitati specifice unui domeniu al aplicatiei supuse viziunii SOA.  Decorabilitate: acest concept face referire la posibilitatea de a. decora, adnota operatiile serviciului, astfel incat sa fie surprinse atat aspectele functionale, cat si cele nefunctionale (WSRealiableMessaging, WS-SecureConversation)..

(30) 4. SOA - Clasificare  Distingem urmatoarea clasificare a serviciilor:  servicii entitate - un serviciu de tip entitate reprezinta una sau mai multe entitati de tip „business”.  servicii functionale - deseori acest tip de serviciu nu are o reprezentare in cadrul unui model de afaceri; poate fi reprezentat totusi in cadrul unei diagrame de tip secventa. Trebuie mentionat ca un serviciu functional este serviciul orientat spre tehnologie si nu spre business (operatii de logging și notificare) .  servicii de tip proces - un serviciu de tip proces este alcatuit dintr-o serie de task-uri (activitati) relationate. Aceste activitati pot fi indeplinite in cadrul granitelor unui singur domeniu de business, peste mai multe domenii de business sau intre organizatii..

(31) 4. SOA – Principii modelare  Tehnicile arhitecturale ce se impun în procesul de modelare:  Generalizarea. presupune analiza serviciului pentru a determina definirea la nivel de concept a serviciului respectiv. Putem face o analogie cu programarea orientata-obiect; o astfel de analiza in contextul OO poarta numele de relatie de tip „IS-A”. O generalizare exagerata poate evita surprinderea aspectelor relevante pentru respectivul serviciu, diminuand posibilitatea refolosirii; prin acest fapt se încalca unul dintre principiile de baza ale SOA..

(32) 4. SOA – Principii modelare  Descompunerea. presupune determinarea elementelor candidat pentru realizarea unei compuneri. O astfel de abordare de cele mai multe ori duce la descoperirea serviciilor de tip entitate sau a serviciilor functionale, servicii ce trebuiesc separate. Ca principiu general, cu cat serviciul este mai bine izolat, in sensul lipsei unei interdependente excesive, cu atat mai mult respectivul serviciu va putea fi folosit/refolosit si eventual integrat intr-un scenariu de “compunere “..

(33) 4. SOA – Principii modelare  Agregarea. presupune analiza serviciului in vederea determinarii contextului din care face parte, in sensul relatiilor de interdependenta. Elementele ce tin de agregare pot fi clasificate ca fiind procese existente, servicii sau chiar servicii-candidat. De asemenea, putem face o paralelă cu programarea orientata-obiect; procesul poarta numele de cautare a relatiilor de tip „HAS-A”..

(34) 4. SOA – Principii modelare  Aplicarea principiilor de mai sus este necesara in vederea. descoperirii serviciilor ce pot fi compuse.  Vom prezenta si principiile aditionale:  Reutilizabilitatea  Securitate  Interoperabilitate  SLA  Granularitate  Contract  Proces.

(35) 4. SOA – Principii modelare  Reutilizabilitatea: scopul final al acestei tehnici este de a. furniza un contract; pe baza analizelor sistemului se urmareste in primul rand gradul de refolosire pe care il poate avea respectivul serviciu.  Securitatea: de obicei, acest aspect este luat in considerare la. nivelul aplicatiei. In cazul modelarii serviciilor componentele ce vor asigura securitatea vor fi încadrate intr-un model general de securitate asociat respectivei solutii SOA, model care va contine SAML (Security Assertion Markup Language), un „policy enforcement”, specificatii privind securitatea transportului, semnaturi digitale, Kerberos etc..

(36) 4. SOA – Principii modelare  Interoperabilitate: in contextul programarii orientate-. obiect, obiectele comunica doar cu alte obiecte; in cazul serviciilor, acest principiu nu este aplicat, ideea de baza fiind aceea de comunicarea intre componente software implementate pe platforme software eterogene.  SLA-uri: serviciile, asemenea sistemelor pe care le expun,. trebuie sa aiba definite contracte, „agreement-uri” la nivel de servicii. Aceste tipuri de specificatii sunt extrem de importante deoarece un anume serviciu intr-un context SOA va fi reutilizat de mai multe ori, in contexte diferite, implicit, procese diferite..

(37) 4. SOA – Principii modelare  Granularitate: un serviciu de cele mai multe ori va fi integrat. intr-un mediu in care serviciile evolueaza in ceea ce priveste interactiunea, implicit interoperabilitatea dintre diferite sisteme. Definirea unei cat mai bune granularitati (functionalitati specifice unui anume business, nu exista un grad mare de interdependenta) reprezinta garantia reutilizarii respectivei componente software..

(38) 4. SOA – Principii modelare  Contract: in cadrul unui model (in sensul unei aplicatii SOA),. definirea unui contract consta in identificarea elementelor necesare la nivel global. Unele dintre elemente vor fi atribute serviciilor, iar altele vor servi ca metadate expuse in cadrul contextului WS-MetaDataExchange. Trebuie mentionat faptul ca deseori vor fi luate in calcul si elementele nefunctionale, de obicei declararea acestora fiind facilitata de tehnologiile ce ofera suport pentru dezvoltarea de aplicatii orientate SOA..

(39) 4. SOA – Principii modelare  Proces: analiza de proces difera de abordarile traditionale (in. sensul construirii de sisteme capabile sa realizeze un set clar de functionalitati) axate pe paradigma orientata-obiect; importanta lor in contextul IT este data de posibilitatea de a translata, a reprezenta un proces de afaceri sub forma unui serviciu web (ultimul standard elaborat de OASIS – WS-BPEL 2.0). Numeroase proiecte (tehnologii ce permit dezvoltarea software) ofera ca solutie pentru realizarea mecanismului de orchestrare (opusul conceptului de coreografie specific mai mult serviciilor web clasice – „WS-Choreography”) suport pentru lucrul cu procese de afaceri si expunerea lor ca servicii..

(40) 5. Concluzii  JavaMOP si MOP sunt centrate pe flexibilitate si optimizarea. monitorizarii  Provocarea consta in elaborarea unui set de tehnici si solutii capabile sa monitorizeze la runtime aplicatiile software ce apartin viziunii SOA..

(41) Sfarsit  Intrebari?.

(42)