Venezia--Novembre 20071 Software per il mondo aperto opportunit à e sfide Carlo Ghezzi Dipartimento di Elettronica e Informazione Politecnico di Milano,

Presentazione sul tema: "Venezia--Novembre 20071 Software per il mondo aperto opportunit à e sfide Carlo Ghezzi Dipartimento di Elettronica e Informazione Politecnico di Milano,"— Transcript della presentazione:

1 Venezia--Novembre 20071 Software per il mondo aperto opportunit à e sfide Carlo Ghezzi Dipartimento di Elettronica e Informazione Politecnico di Milano, Italy carlo.ghezzi@polimi.it

2 Venezia--Novembre 20072 Che cos' è il "mondo aperto? Le metodologie e tecnologie del software sono passate da una situazione di – mondo chiuso – a evoluzione controllata – a mondo aperto Il progresso nel settore può essere analizzato secondo questa visione prospettica Il mondo esterno col quale il sistema interagisce è ben noto e fisso La struttura della soluzione è fissa monolitica, fissa e centralizzata I cambiamenti nel mondo esterno ricdhiedono riprogettazione I cambiamenti nell'implementazione sono localizzati a parti ristretta I cambiamenti si manifestano quando il sistema è in esecuzione L'architettura evolve mentre il sistema è in funzione

3 Venezia--Novembre 20073 Traccia del seminario Breve rassegna dell'evoluzione del software dal punto di vista dei concetti di mondo aperto/chiuso Analisi delle sfide e opportunit à Zoom su due linee di ricerca Un'agenda per la ricerca

4 Venezia--Novembre 20074 Postulati Il mondo aperto richiede di comporre il software dinamicamente…. …. in quanto la struttura del software deve poter cambiare dinamicamente, anche in modo imprevisto Ciò comporta un cambiamento radicale in come si progetta e convalida il software –in particolare, da una convalida off-lie a una convalida "perpetua"

5 Venezia--Novembre 20075 Il punto di vista Mi focalizzo su composizione/struttura –come viene costruito un sistema da sue parti? come/quando si stabiliscono i "binding" tra parti? –quale struttura/architettura? anche a livello di processo –come è strutturata vita di un'applicazione? –quale organizzazione in fasi/attivit à /ruoli/attori? con un occhio al mondo del "business"

6 Venezia--Novembre 20076 Archeologia Nascita nel 1968 dell'ingegneria del software, come risposta a –crescente importanza del software nella societ à –bassa qualit à e costi elevati –assenza di metodi standard iterazione continua codifica/rimozione di errori

7 Venezia--Novembre 20077 Fatti e ipotesi implicite Organizzazioni monolitiche –soluzioni centralizzate L'ipotesi di mondo chiuso –i confini tra il mondo reale e la "macchina" sono chiari e fissi –i requisisti esistono e sono stabili, basta scovarli elicit them right! –le modifiche sono pericolose vanno evitate, sono la causa dei problemi di costo e "schedule"!

8 Venezia--Novembre 20078 Le soluzioni proposte A livello di processo –il modello sequenziale a fasi (waterfall) raffinamenti dai requisiti al codice sviluppi top-down via deduzioni formali A livello di prodotto –linguaggi e metodi per architetture software statiche, centralizzate, verificabili composizioni statiche, congelate a "design time"

9 Venezia--Novembre 20079 Lezioni apprese Impossibile stabilire all'inizio i requisiti I requisiti non possono essere congelati I requisiti sono intrinsecamente decentrati, illusori il loro controllo completo e la pre-pianificazione Quando cambiano, impattano spesso su ogni parte del prodotto/processo L'evoluzione è intrinseca al software –non è un fatto accidentale che capita inatteso dopo il rilascio

10 Venezia--Novembre 200710 Evoluzione controllata Si deve poter prevedere e controllare l'evoluzione –con ciò ci si allontana progressivamente dall'ipotesi di mondo chiuso A livello di processo –modelli evolutivi incrementali, prototipali, a spirale A livello di prodotto –Metodi design for change (Parnas) –information hiding –specification/interface vs. implementation/body –Tecnologia e linguaggi da strutture monolitiche, a modulari e distribuite (client/server)

11 Venezia--Novembre 200711 Evoluzione controllata: linguaggi e metodi OO Consentono alcuni tipi di cambiamenti dinamici Nuove (sotto)classi e oggetti possono essere creati mentre il sistema è in esecuzione –le operazioni chiamate vengono scelte durante l'esecuzione Mondo parzialmente aperto + "type safety" –se si possono prevedere i cambiamenti e li si possono gestire mediante il meccanismo di ereditariet à, l'evoluzione dinamica può coesistere con la verifica statica ("type safety")

12 Venezia--Novembre 200712 body interface Polimorfismo Fax f Binding dinamico f.sendFax(); OO design Fax -body -interface Fax with phone

13 Venezia--Novembre 200713 Binding che attraversa i confini di rete client server RMI code base

14 Venezia--Novembre 200714 Componenti: il processo nel mondo aperto Sistemi sviluppati a partire da componenti Mondo aperto per il processo –sviluppi decentrati –multipli "stakeholder" controllo limitato sul processo –integrazione "bottom up" via middleware

15 Venezia--Novembre 200715 Facciamo il punto La necessit à di adattamento ai cambiamenti esterni –nel mondo del "business" –nel mondo fisico impone cambiamenti al software Siamo stati ragionevolmente capaci di rispondere a questa sfida senza compromettere l'affidabilit à delle soluzioni

16 Venezia--Novembre 200716 Che cosa succede oggi? Mondo aperto –livelli mai prima sperimentati di evoluzione –"perpetual beta"

17 Venezia--Novembre 200717 Dove sono i motivi del cambiamento? (1) Nel mondo del business –organizzazioni agili in rete federazioni dinamiche, opportunistiche, goal-oriented reazioni rapide ai rapidi cambiamenti della domanda reazioni rapide interne all'organizzazione e nella rete dei rapporti

18 Venezia--Novembre 200718 Organizzazioni in rete Le applicazioni appartengono a diversi domini applicativi Interazioni via web con proptocolli standard BOO BOO LOO LOO MOO MOO FOO FOO Funzionalit`a offerte da diversi fornitori che variano nel tempo Esportazione di applicazioni interne

19 Venezia--Novembre 200719 Dove sono i motivi del cambiamento? (2) Mobilit à fisica e ubiquitous/ pervasive computing –richiedono binding dinamici e context-aware invocazione di un servizio di stampa che si lega alla stampante pi ù vicina richiesta di illuminazione che si lega a un attuatore che apre le imposte o all'interruttore della luce elettrica a seconda dellle condizioni di luce esterna

20 Venezia--Novembre 200720 Mondo aperto I requisiti cambiano in continuazione e in modo imprevedibile I confini tra il sistema e il mondo esterno non possono essere congelati –possono cambiare mentre il sistema è in esecuzione non possiamo "spegnere il sistema" e riprogettare/ reinstallare/rieseguire occorre fornire un servizio senza interruzione Le composizioni evolvono perch è possono cambiare sia i components che la loro struttura Non esiste una singola "autorit à " che ha l'intero sistema a carico

21 Venezia--Novembre 200721 Mondo chiuso Nel mondo chiuso esiste una separazione netta tra pre - runtime e runtime I cambiamenti si gestiscono ritornando alla fase di sviluppo, nella quale si effettuano le attivit à di verifica progetto verifica deployment execuzione

22 Venezia--Novembre 200722 Da componenti a servizi Entrambi sono sviluppati da "altri" I componenti sono eseguiti nel dominio dell'applicazione, e ne diventano parte I servizi sono eseguiti nei rispettivi domini Di norma, i componenti vengono scelti e collegati al tempo di progettazione Servizi scelti e collegati a run-time I servizi supportano contratti espliciti per consentire l'uso da parte di terzi –richiedono un SLA che riguarda non solo gli aspetti funzionali I servizi possono essere composti per formare nuovi servizi

23 Venezia--Novembre 200723 Ownership Tradizionalmente le applicazioni sono possedute dalle organizzazioni che lo "eseguono" Componenti e software di supporto non sono posseduti, ma sono amministrati da chi li esegue –che dipende dal proprietario per le evoluzioni I servizi non sono posseduti n è amministrati, ma solo "attivati"

24 Venezia--Novembre 200724 Meccanismi di binding per il mondo aperto Esplicito in due fasi –discovery-based fase 1: pubblicazione delle propriet à funzionali e non fase 2: ricerca, scoperta, selezione, con eventuale ottimizzazione/negoziazione Implicito –via uno spazio logico glocale di coordinamento eventi: publish/subscribe dati persistenti: tuple space by contract?

25 Venezia--Novembre 200725 Discovery Agency Service Provider Service Requestor Requirements Service Specification Publish Discovery-based binding Service Specification Service Interact Query Requirements RequestResponse

26 Venezia--Novembre 200726 C3C4C5C6 C1C2 Event Dispatcher sottoscrizioni notifiche Implicit binding (P/S) 2 sottoscrizioni a "rosso" (C1, C5) 1 sottoscrizione a blu (C6)

27 Venezia--Novembre 200727 Architetture Publish-Subscribe Comunicazione asincrona mediata da un dispatcher –anonima –multipoint –implicit addressing subject vs. contents-based I componenti applicativi –si sottoscrivono a pattern di messaggi a cui sono interessati – pubblicano messaggi Il dispatcher esegue un match tra messaggi pubblicati e sottoscrizioni ed esegue il multicast Supporto all'aggiunta/rimozione/sostituzione dinamica di componenti

28 Venezia--Novembre 200728 Un esempio publish/subscribe service publish/subscribe service want low air fares to Europe want low air fares to Europe want to fly December DEN-MXP want to fly December DEN-MXP want special offers by United want special offers by United subscribe notify United offers DEN-MXP October United offers DEN-MXP October Alitalia offers DEN-MXP Nov-Feb Alitalia offers DEN-MXP Nov-Feb publish subscriber publisher subscription publication notification Dovuto a Carzaniga e Wolf

29 Venezia--Novembre 200729 E-commerce TIBCO, ION-MkView, smartsockets operatori finanziari (compravendita di azioni) gateway verso altri mercati dispatcher componenti applicativi

30 Venezia--Novembre 200730 Spazi di tuple (Linda-like) C3C4C5C6 C1C2 Tuple space invia tupla rimuove tupla via pattern matching legge tupla via pattern matching read e remove nondeterministiche e bloccanti

31 Venezia--Novembre 200731 Binding by contract COMPONENT required interfaceprovided interface interfaccia descritta da una SPECIFICA La specifica descrive signature comportamento funzionale comportamento nonfunzionale Bisogna gestire le violazioni di contratto

32 Venezia--Novembre 200732 Potenziali benefici Chiara separazione tra "what", "how" e "when" –possibili diverse politiche early/late context-aware ottimizzazione di figure di merito –legame al "current best" –"self-organization" –necessaria descrizione semanticamente ricca delle interfacce deve descrivere la QoS

33 Venezia--Novembre 200733 BBC per composizione di servizi La composizione può essere descritta da un workflow, che specifica una orchestrazione astratta –il workflow viene eseguito dal direttore ch fa da coordinatore –i servizi esterni sono definiti tramite specifica che consente BBC –binding a servzi concreti viene fatto dinamicamente

34 Venezia--Novembre 200734 Le sfide del mondo aperto Vanno ripensate tutte le attivit à del ciclo di vita –requisiti –specifica –design&implementazione –verifica&convalida

35 Venezia--Novembre 200735 Zoom-in #1 Dynamic self-adapting service orchestration via BBC collaborazioni con L. Baresi, D. Bianculli,E. Di Nitto, S. Guinea, P. Spoletini

36 Venezia--Novembre 200736 Web service orchestrations L'orchestrazione di Web services con BPEL consente di sviluppare servizi complessi per composizione BPEL viene esteso per consentire di denotare servizi partner astratti Binding a servizi concreti realizzato a run-time, a causa del mondo aperto, poich è –i servizi possono cambiare nel tempo ( in meglio o in peggio ) –nuovi servizi si rendono disponibili ( e si vuol sfruttare la loro disponibilit à, che può dipendere dal contesto )

37 Venezia--Novembre 200737 Verifica&convalida + BBC fornisce flessibilit à e dinamismo - BBC richiede perpetua V&V –late binding+composizione dinamica danno flessibilit à al costo di ridotta affidabilit à –l'intero spettro possibile di regimi di binding uno spettro completo di attivit à di V&V

38 Venezia--Novembre 200738 2 tipi di convalida 1 linguaggio ALBERT: un linguaggio in logica temporale per processi BPEL –può esprimere propriet à funzionale e non-funzionali –utilizzabile per due tipi di convalida design-time ( model checking ) –si assume che il mondo esterno soddisfi certe propriet à e sulla base di ciò –si garantisce che valgano certe propriet à del servizio composto run-time ( monitoring ) –si verifica il mantenimento delle propriet à Un unico e coerente framework per la convalida

39 Venezia--Novembre 200739 Assume-guarantee Un approccio potente alla progettazione e verifica –definire ciò che il mondo esterno deve garantire si assume che valga e ci si fida che sia cos ì –a ciò che a nostra volta dobbiamo garantire abbiamo naturalmente l'onere della prova che sia davvero cos ì Naturalmente esiste l'onere di prova/check che ciò che si assume riguardo a X sia davvero garantito da X

40 Venezia--Novembre 200740 Che succede se il contratto è violato? Strategie di re-binding Comportamenti autonomici –qui non ne parliamo

41 Venezia--Novembre 200741 Il processo TeleAssistance receive while pick invoke switch invoke "mild" panic button invoke "high"

42 Venezia--Novembre 200742 Qualche propriet à LabServiceTime : la risposta del lab arriva entro 1 ora dall'invio dei dati del paziente FASConfirmHospitalization : se il FAS viene chiamato 3 volte in 1 settimana con severit à High per un certo paziente, si deve notificare il TA, entro 1 giorno, che il paziente è stato ricoverato FASInvokeMildAlarm : dopo la ricezione di un messaggio dal LAB che indica che deve essere mandato un allarme al FAS, TA dve invocare il servizio FAS entro 4 ore, con una severit à Mild dell'allarme MDCheckUp : se un paziente preme pButtonMsg 3 volte in una settimana, il FAS ospedalizza il paziente entro 1 giorno

43 Venezia--Novembre 200743 Specifiche nonfunzionali performance dependability response time throughtputreliabilityavailability richiedono tempo esplicito e una metrica la distanza tra tempi conteggi (negli intervalli di tempo)

44 Venezia--Novembre 200744 ALBERT Un linguaggio temporale che predica su eventi e durate Consente di esprimere statement di QoS Le proprietà sono espresse come invarianti del processo Sintassi:

45 Venezia--Novembre 200745 Stati Semantica espressa con riferimento a sequenze di stati (con time- stamp) del processo BPEL

46 Venezia--Novembre 200746 Becomes and Until Becomes(A) Until(A,B)

47 Venezia--Novembre 200747 Between and Within Between(A,B,6) Within(A,6)

48 Venezia--Novembre 200748 past and elapsed past(A,onEvent(Y),2) elapsed(onEvent(X))

49 Venezia--Novembre 200749 count In i11: – count(Becomes(B), 36) = 1 – Becomes(count(B, 36) = 4) is true – count(B, onEvent(Y), 36) = 2 count(B,36)

50 Venezia--Novembre 200750 Esempi LabServiceTime: MDCheckUp: la risposta del lab arriva entro 1 ora dall'invio dei dati del paziente se un paziente preme pButtonMsg 3 volte in una settimana, il FAS ospedalizza il paziente entro 1 giorno x(Becomes(count($alarmNotif/level=`high x = $alarmNotif/pID, onEvent(pButtonMsg), 10080) = 3) Within(onEvent(patHospitalizedMsg) $patHospitalized/pId=x, 1440)) onEvent(start_analyzeData) Within(onEvent(end_analyzeData), 60)

51 Venezia--Novembre 200751 Esecuzione e monitoring via AOP

52 Venezia--Novembre 200752 Valutazione di ALBERT a run time Per le proprietà che fanno riferimento solo allo stato presente o alla storia passata –la storia è bounded Per le proprietà che fanno riferimento al futuro –si genera un nuovo task parallelo, ma ancora si ha memoria bounded

53 Venezia--Novembre 200753 Zoom-in #2 Design and accurate verification of Publish-Subscribe architectures joint work with L. Baresi, L. Mottola, L. Zanolin

54 Venezia--Novembre 200754 Premise Modern distributed applications for dynamic environments ask for a flexible and reconfigurable software infrastructure Publish-Subscribe provides an answer to these needs –fostering an anonymous, implicit, multi-point communication paradigm Hard to design and verify "global behavior" of composite applications –component interactions change dynamically –focus on each reactive component, "global picture" is missing –real-world Publish-Subscribe systems differ along several dimensions

55 Venezia--Novembre 200755 Enterprise Systems Dynamic Topologies Sensor Networks Variety of approaches (1) From enterprise to embedded systems

56 Venezia--Novembre 200756 Variety of approaches (2) Different guarantees provided GuaranteeChoices Message ReliabilityAbsent, Present Message Ordering Random, Pair-wise FIFO, System- wide FIFO, Causal Order, Total Order FilteringPrecise, Approximate Real-time GuaranteesAbsent, Present Subscription Propagation Delay Absent, Present Repliable MessagesAbsent, Present Message PrioritiesAbsent, Present Queue Drop PolicyNone, Tail Drop, Priority Drop ……

57 Venezia--Novembre 200757 Existing systems Guarantee JMS-compliant [jmsSpec] REDS [cugola07reds] DSWare [li04event] Message ReliabilityPresent Absent Message OrderingPair-wise FIFORandom FilteringPrecisePrecise, ApproximatePrecise Real-time GuaranteesAbsent Present Subscription Propagation DelayAbsentPresent Repliable MessagesPresent Absent Message PrioritiesPresentAbsent Queue Drop PolicyPriority DropTail Drop

58 Venezia--Novembre 200758 Message ordering C2 C1 C3 t1: e1 t2: e2 C2 C1 C3 t1: e1 t2: e2

59 Venezia--Novembre 200759 Ordering of events Hypothesis: C1 generates e1 for C2, C3 C2 generates e2 and then e3 for C3 e3 generated by C2 as a consequence of receipt of e1 C1C2C3 Total ordering e1 e2 e3 C1C2C3 Causal ordering e1 e2 e3 C1C2C3 Ordering relative to sender e1 e2 e3 C1C2C3 None e1 e2 e3

60 Venezia--Novembre 200760 A designer's workbench Provide a model of the architecture The model embodies the amount of detail that the designer wishes to express The model is verified against certain properties The model is changed or details are added as needed GOAL: assess design and detect design flaws prior to moving to implementation

61 Venezia--Novembre 200761 State of the art Model checking proposed to address the verification issue –standard tools (e.g., SPIN) used to model both the application and the PubSub infrastructure (e.g., [garlan03], [baresi ghezzi zanolin03]) – fine-grained models unfeasible due to state space explosion – parametric models difficult due to little support for parameterization in the modeling language A change of perspective: embed the PubSub communication paradigm within the model-checker

62 Venezia--Novembre 200762 Our solution Fine grained parametric models implemented in the model checker –PubSub APIs as primitive constructs of the modeling language easier to specify the application model Domain-specific knowledge can achieve application- specific state abstraction –addresses the state space explosion problem

63 Venezia--Novembre 200763 Performing the verification Specify the application model using the PubSub API Specify the properties to be checker (LTL) Select combination of PubSub guarantees the application relies on Instantiate the parametric dispatcher within Bogor Depending on the verification outcome: –modify the application model –change the guarantees selected Allows one to explore the interplay between application and comm infrastructure

64 Venezia--Novembre 200764 PubSub APIs The PubSub infrastructure is offered as a generic abstract data type –each instance represents a connection to the PubSub dispatcher –customized w.r.t. the type of messages used by the application – operations are used to issue subscriptions, publish messages, … typealias MessagePriority int (0,9); enum DropPolicy {TAIL_DROP, PRIORITY_DROP } extension PubSubConnection for polimi.bogor.bogorps.PubSubModule { typedef type ; expdef PubSubConnection.type register (); expdef PubSubConnection.type registerWithDropping (int, DropPolicy); actiondef subscribe (PubSubConnection.type, 'a -> boolean); actiondef publish (PubSubConnection.type, 'a); actiondef publishWithPriority (PubSubConnection.type, 'a, MessagePriority); expdef boolean waitingMessage (PubSubConnection.type ); actiondef getNextMessage (PubSubConnection.type, lazy 'a); } Subscriptions as boolean functions!

65 Venezia--Novembre 200765 Using PubSub APIs record MyMessage {int value;} MyMessage receivedEvent := new MyMessage; active thread Publisher() { MyMessage publishedEvent = new MyMessage; PubSubConnection.type ps; loc loc0: // Connection setup do { ps := PubSubConnection.register ();} goto loc1; loc loc1: // Publishing a message do { publishedEvent.value := 1; PubSubConnection.publish (ps, publishedEvent);} return; } Publishes a message record MyMessage {int value;} fun isGreaterThanZero(MyMessage event) returns boolean = event.value > 0; active thread Subscriber() { PubSubConnection.type ps; loc loc0: // Connection setup and subscription do { ps := PubSubConnection.register (); PubSubConnection.subscribe (ps, isGreaterThanZero);} goto loc1; loc loc1: // Message receive when PubSubConnection.waitingMessage (ps) do { PubSubConnection.getNextMessage (ps, receivedEvent);} return; } Issues a (matching) subscription Defines a subscription Receives a message

66 Venezia--Novembre 200766 Representing the system state Let the system state be described by a tuple: In turn, let us also define SystemState = i-th thread (application component) state DispatcherState = Subscriptions issued Bookkeeping data to model specific guarantees Messages in transit

67 Venezia--Novembre 200767 Domain-specific model checker state abstraction - Example 1 A message is delivered to an application component if at least one of its subscriptions matches –the order in which subscriptions are examined is immaterial We model the subscription table as a set DispatcherState =

68 Venezia--Novembre 200768 As messages are delivered, bookkeeping information must be stored at the dispatcher to enforce a specific message ordering –from the dispatcher perspective, they change every time a message is published From the application perspective, the state of the incoming queue may be viewed as unchanged even though some messages directed to it have been issued DispatcherState = Domain-specific model checker state abstraction - Example 2

69 Venezia--Novembre 200769 Domain-specific model checker state abstraction - Example 3 Publish-Subscribe often needs to duplicate messages Message duplication does not affect the application state All supporting data structures hidden in our Bogor extension

70 Venezia--Novembre 200770 More on "why Bogor" Multi-point communication feasible also with other tools (e.g., using Promela channels) –cannot model dynamic sender-receiver pairs –cannot be detached to serve a different pair of processes –cannot model fine-grained guarantees

71 Venezia--Novembre 200771 Evaluation A set of synthetic scenarios stressing sample PubSub guarantees –5 threads subscribing to messages coming from another thread Comparing against SPIN/Promela [zanolin03approach] ScenarioPublish Ops. Bogor w/ PubSubSPIN/Promela MemoryTimeMemoryTime Causal1232.8 Mb103 sec298.3 Mb> 15 min Causal2545.6 Mb132 sec589.6 Mb> 1 hour Causal3752.3 Mb158 secOutOfMemNotCompleted Causal41061.1 Mb189 secOutOfMemNotCompleted Priorities1218.3 Mb47 sec192 Mb> 10 min Priorities2526.9 Mb103 sec471.2 Mb> 30 min Priorities3737.9 Mb134 secOutOfMemNotCompleted Priorities41049.1 Mb163 secOutOfMemNotCompleted

72 Venezia--Novembre 200772 Case study An application for fire monitoring in a tunnel Communication patterns expressed as subscriptions A set of requirements –R1 - when a truck enters the tunnel, ventilation must increase –R2 - when temperature increases, smoke sensors must be queried –R3 - when temperature increases, notify cs and contact fb to inspect the environment. It reports to cs which checks that control occurred –R4 - messages from the control station to command the traffic lights must be delivered with a maximum delay of five time units Requirements expressed in LTL PubSub guarantees initially set to DSWare

73 Venezia--Novembre 200773 Verification - Step 1 The initial application model took message reliability for granted –R1 ( ventilation must increase when a truck enters the tunnel ) fails immediately Message reliability currently investigated in embedded networked systems –assume it is provided by the communication infrastructure R1 fails Select reliability

74 Venezia--Novembre 200774 Verification - Step 2 R3 (… contact the fire brigade to inspect the environment and report to the control station ) fails without causal ordering CO is key in safety applications Push CO in the PubSub infrastructure R3 fails Select CO

75 Venezia--Novembre 200775 Verification - Step 3 R3 also requires the subscription from the fire brigade to propagate instantaneously Unreasonable to assume in a distributed environment Modify the application R3 fails Repeat publish until ACK

76 Venezia--Novembre 200776 Verification - Step 4 R2 ( when temperature increases, smoke sensors must be queried ) requires a query reply interaction R2 fails because of subscription propagation delays Query-reply provided by embedded system middleware R2 fails Select repliable messages

77 Venezia--Novembre 200777 Verification - Step 5 R4 ( messages … must be delivered with a maximum delay of five time units) requires RT DSWare already provides it R4 succeeds

78 Venezia--Novembre 200778 Conclusions A tool supporting exploration of the design space Enables exploring the interplay between application and communication infrastructure Proposed a change of perspective in the use of model checking –embed domain specific mechanisms and export them as primitive constructs of the modeling language Make fine-grained, parametric models feasible

79 Venezia--Novembre 200779 The end Fundamental problems continue to exist in a new and more difficult form –Process level combine process agility and product quality –harder for distributed and inter-organization developments –Product level requirements and specification architecture/implementation verification

80 Venezia--Novembre 200780 Acknowledgements Projects SeCSE, Cascadas, Plastic, ArtDeco People –L. Baresi, E. Di Nitto, G.P. Picco, G. Cugola, S. Guinea, D. Bianculli, P. Spoletini, L. Mottola … student*

81 Venezia--Novembre 200781 Some papers C. Ghezzi, L. Baresi, E Di Nitto "Towards Open-World Software". Computer, IEEE, Volume 39, Number 10: 36-43, October 2006 L. Baresi, C. Ghezzi, and S. Guinea, "Smart Monitors for Composed Services", 2nd Int.l Conf. on Service Oriented Computing. Nov. 2004 L. Baresi, C. Ghezzi, and S. Guinea "Towards Self-healing Compositions of Services" In Bernd J. Kraemer and Wolfgang A. Halang (eds.) Contributions to Ubiquitous Computing. Volume 42 of Studies in Computational Intellligence, Springer, 2006 L. Baresi, E. Di Nitto, C. Ghezzi, S. Guinea "A Flexible Framework for the Deployment of Service-Centric Systems", Service Oriented Computing and Applications, 1, 1, 2007 L. Baresi, D. Bianculli, C. Ghezzi, P. Spoletini. Monitoring Web Service Orchestrations Using Timed WSCoL Proc. of Int.l Conference on Web Services (ICWS), 2007 D. Bianculli, C. Ghezzi, Monitoring Conversational Web Services, SOSWE 2007. L. Baresi, D. Bianculli, C. Ghezzi, S. Guinea, P. Spoletini. Validation of Web service compositions. To appear on IEE Proceedings Software, 2007 L. Baresi, C. Ghezzi, and L. Mottola "On Accurate Automatic Verification of Publish-Subscribe Architectures", ICSE 2007 D. Bianculli, R. Jurca, W. Binder, C. Ghezzi, B.Faltings. Automated Dynamic Maintenance of Composite Services based on Service Reputation. In Proc. of Int.l Conf. on Service Oriented Computing (ICSOC), 2007 L. Zanolin, C. Ghezzi, and L. Baresi. "An Approach to Model and Validate Publish/Subscribe Architectures". In Proc. of the SAVCBS03 Workshop, 2003 L. Baresi, C. Ghezzi, and L. Mottola. "Towards Fine-Grained Automated Verification of Publish-Subscribe Architectures". In Proc. of the 26 th Int. Conf. on Formal Methods for Networked and Distributed Systems (FORTE06), 2006 L. Baresi, C. Ghezzi, and L. Mottola. "On Accurate Automatic Verification of Publish-Subscribe Architectures". Proc. of the 29 th Int. Conf. on Software Engineering (ICSE07), 2007 L. Baresi, G. Gerosa, C. Ghezzi, and L. Mottola. "Playing with Time in PublishSubscribe using a DomainSpecific Model Checker". In Proc. of the SAVCBS03 Workshop, 2007