Differenze tra le versioni di "Fondamenti di sistemi distribuiti/2006-2007"

Da WikiDsy.
(Lezione di Venerdi' 3 Novembre)
(Lezione di Venerdi' 3 Novembre)
Riga 121: Riga 121:
 
<br>Differenze tra RdP, CSP, CCS e Actors per quanto riguarda il tipo di comunicazione e la semantica.
 
<br>Differenze tra RdP, CSP, CCS e Actors per quanto riguarda il tipo di comunicazione e la semantica.
 
<br><b>Per chi ha gia' composto il gruppo, la prof ha consigliato di iniziare a guardare i casi di studio presenti sul libro all'inizio della parte 3°(pag.459) in modo da farsi un'idea.</b>
 
<br><b>Per chi ha gia' composto il gruppo, la prof ha consigliato di iniziare a guardare i casi di studio presenti sul libro all'inizio della parte 3°(pag.459) in modo da farsi un'idea.</b>
 +
 +
=== Lezione di Martedi' 7 Novembre ===
 +
 +
A partire da una discussione sulle criticità proprie, dell'attività di sviluppo del software, si è identificato il ruolo del software come duplice astrazione - del problem domain e del computing system - ed  il ciclo di vita del software come un processo che consente di passare, attraverso le attività di analisi, progettazione e implementazione, dalla identificazione di esigenze nel contesto di un problem domain alla realizzazione di codice funzionante correttamente su un dato computing system.

Versione delle 19:00, 7 nov 2006

Informazioni generali

Orari delle lezioni

MARTEDI' : 9-10.30 (in Aula Beta)
VENERDI' : 9-10.30 (in Aula Beta)

Orario di ricevimento studenti

MARTEDI' : dalle 11 in poi.

Avvisi

  • Martedi' 17 Ottobre e Martedi' 24 Ottobre non ci sara' lezione.

Link

Sito del corso: questo
Forum: dal sito di jli, mettete user e password e cliccate in basso a destra sul link FORUM.

Materiale didattico

- Slide
- "Designing Concurrent, distributed and real-time application with UML - Gomaa", Addison-Wesley, 2001
- Videolezioni raggiungibili a questo : link

Modalità d'esame

Frequentanti: un compitino + analisi caso di studio.
Non frequentante: Due compitini o esame completo + analisi caso di studio.
Per il caso di studio bisogna farlo in gruppi di 2.(una volta si poteva anche in 3 mentre la prof ha deciso che da quest'anno non sara' piu' possibile)
Iscrizione al corso
Per iscriversi bisogna andare sul sito jli , cliccare su "form di autoregistrazione" e inserire user e password del silab. Quindi effettuare il login e compilare il questionario del corso. Se siete gia' iscritti e avete problemi nel visualizzare il questionario andate a questo link per maggiori info.

Diario del corso

Lezione di Martedi' 3 Ottobre

Dalla triennale alla magistrale: why?what?
Fsd: di cosa si occupa?
Progettazione di sistemi distribuiti.

Lezione di Venerdi' 6 Ottobre

Caratterizzazione della nozione di sistema.
Nozioni di componente e sottosistema, osservatore e comportamento esibito.

Lezione di Martedi' 10 Ottobre

Componenti come oggetti Descrizione di una componente (del sistema) come oggetto. Alcune nozioni della programmazione ad oggetti. Esempio del BUFFER a una cella. Automa per la modellazione dei passaggi di stato. Caratterizzazione semantica delle operazioni. Possibilita' di rappresentare la medesima situazione con una gerarchia tra classi o con una sola classe con oggetti differezianti per stato.

Esercizio

classe PRODUCER: prende dall'ambiente un elemento da processare alla volta, lo usa per produrre quel che deve e lo rende disponibile ad altre componenti (oggetti); classe CONSUMER: prende da altre componenti del sistema elementi di prodotto, se necessario li processa ulteriormente (li conusma) e di rilascia all'ambiente. Ragionate infine su come comporre i comportamenti per modellare

1- sistema

   PRODUCER || CONSUMER 

dove || sta per 'composizione parallela sincrona', cioe i due processi si scambiano l'item direttamente in una comunicazione sincrona atomica

2- sistema

   PRODUCER || BUFFER || CONSUMER

cioe' il Buffer disaccoppia la comunicazione tra PRODUCER e CONSUMER;

Lezione di Venerdi' 13 Ottobre

Dal sequenziale al concorrente. Esempio Producer-Buffer-Consumer. Modellare il comportamento di un sistema ottenuto per sincronizzazione (sincrona o asincrona) delle componenti che lo costituiscono. Confrontare i sistemi cosi' ottenuti.

Lezione di Martedi' 17 Ottobre

Non c'era lezione!

Lezione di Venerdi' 20 Ottobre

Si sono consolidate le nozioni di base che consentono di modellare il comportamento di un sistema distribuito per mezzo di una Rete di Petri, introducendo le definizione di rete, sistema, abiltazione e scatto di un evento e di un insieme di eventi (concorrenza). Si è inoltre introdotto il principio di estensionalità per la caratterizzazione degli eventi e, su questa base, si sono introdotte e discusse situazioni di contatto e side-condition.

Lezione di Martedi' 24 Ottobre

Non c'e' lezione!

Lezione di Venerdi' 27 Ottobre

Svolgimento esercizi che la prof ha dato le lezioni scorse. Case Graph. Situazione di "confusione" piu' esercizio da risolvere a casa.

Lezione di Martedi' 31 Ottobre

Svolgimento degli esercizi che la prof aveva assegnato le lezioni scorse.
Sistema 1-Vivo, Transizione morta, Blocco del sistema.
Proprieta' di buon comportamento del sistema. Proprieta' di vivezza. Sistema Vivo.

Lezione di Venerdi' 3 Novembre

Svolgimento esercizio assegnato la lezione scorsa.
Differenze tra sequenziale e concorrente.
Reti di occorrenza o processi, dipendenza o indipendenza causale.
Semantiche della concorrenza:

  • interleaving
  • a step
  • a ordinamenti parziali


Ci sono altri modelli oltre alle Reti di Petri:

  • Communicating Sequential Processes (CSP - Hoare 1978)
  • Calculus for Communicating Systems (CCS - Milner 1980)
  • Actors (Hewitt 1973)


Differenze tra RdP, CSP, CCS e Actors per quanto riguarda il tipo di comunicazione e la semantica.
Per chi ha gia' composto il gruppo, la prof ha consigliato di iniziare a guardare i casi di studio presenti sul libro all'inizio della parte 3°(pag.459) in modo da farsi un'idea.

Lezione di Martedi' 7 Novembre

A partire da una discussione sulle criticità proprie, dell'attività di sviluppo del software, si è identificato il ruolo del software come duplice astrazione - del problem domain e del computing system - ed il ciclo di vita del software come un processo che consente di passare, attraverso le attività di analisi, progettazione e implementazione, dalla identificazione di esigenze nel contesto di un problem domain alla realizzazione di codice funzionante correttamente su un dato computing system.