• sistemi peer to peer
• simulatori

Come in tutti i sistemi, da quelli più semplici a quelli più complessi, durante la progettazione e lo sviluppo delle singole componenti, si rende necessario l’analisi dei comportamenti dei singoli elementi, ovvero controllare che le operazioni svolte dai singoli peer nell’interagire con l’ambiente esterno siano corrette e (soprattutto) siano eseguite nell’ordine corretto. Avendo a che fare con gruppi eterogenei composti da molti peer aventi magari caratteristiche, servizi e comportamenti molto differenti, si è reso necessario dotarsi di uno strumento, di un tool in grado di analizzare il comportamento di ogni singola unità in modo da poter essere confrontato con gli altri in un determinato contesto per cercare di capirne il funzionamento ed eventualmente i problemi.
Per capire il comportamento di singola unità P2P, l’applicazione dovrebbe poter simulare tutti i possibili workflow, sia in assenza che in presenza di fault: solo in questo modo si potrebbe analizzare in maniera soddisfacente il comportamento complessivo dell’entità (peer oppure servizio). Come è possibile intuire, la mole di dati computati dal programma potrebbe essere non indifferente quindi è naturale pensare ad un prototipo in grado di poter salvare questi dati in un formato standard (come, per esempio, xml) in modo da poterli riutilizzare (analizzare) in un secondo momento, anche con strumenti software differenti dal tool in questione (cioè con altri programmi con funzionalità totalmente differenti).
Inoltre, per poter usare lo strumento in maniera semplice, dovrebbe essere dotato di una interfaccia grafica snella, in grado di offrire naturalmente un accesso a tutte le funzionalità e in grado di visualizzare, istante per istante, lo stato corrente dell’applicazione in maniera chiara, istantanea.
In questa ottica è stato sviluppato un simulatore di workflows per il linguaggio di modellazione SMoL: con questa applicazione è possibile simulare tutte le possibili tracce (e quindi i comportamenti) descritte da un file SMoL affinché sia possibile, ancora prima di passare alla parte implementativa vera e propria (risparmiando così una discreta quantità di tempo), accertare la validità di un servizio o meno in presenza di fault, di comportamenti anomali o semplicemente durante una esecuzione normale ed eventualmente correggere queste anomalie.