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

Da WikiDsy.
(Lezione di Venerdi' 27 Ottobre)
(Lezione di Martedi' 5 Dicembre)
 
(20 versioni intermedie di 4 utenti non mostrate)
Riga 29: Riga 29:
 
=== Modalità d'esame ===
 
=== Modalità d'esame ===
  
Due compitini o esame completo + analisi caso di studio.
+
Frequentanti: un compitino + analisi caso di studio.<br>
 +
Non frequentante: Due compitini o esame completo + analisi caso di studio.<br>
 
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)<br>
 
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)<br>
 
''' Iscrizione al corso '''
 
''' Iscrizione al corso '''
Riga 102: Riga 103:
 
Sistema 1-Vivo, Transizione morta, Blocco del sistema.<br>
 
Sistema 1-Vivo, Transizione morta, Blocco del sistema.<br>
 
Proprieta' di buon comportamento del sistema. Proprieta' di vivezza. Sistema Vivo.
 
Proprieta' di buon comportamento del sistema. Proprieta' di vivezza. Sistema Vivo.
 +
 +
=== Lezione di Venerdi' 3 Novembre ===
 +
 +
Svolgimento esercizio assegnato la lezione scorsa.
 +
<br>Differenze tra sequenziale e concorrente.<br>
 +
Reti di occorrenza o processi, dipendenza o indipendenza causale.<br>
 +
Semantiche della concorrenza:
 +
* interleaving
 +
* a step
 +
* a ordinamenti parziali
 +
 +
<br>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)
 +
 +
<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>
 +
 +
=== 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.
 +
 +
=== Lezione di Venerdi' 10 Novembre ===
 +
 +
Il compitino si terra' il 21 Novembre dalle 8.30 circa in poi.<br>
 +
Metodologia UML-compliant COMET (Concurrent Object Modelling and architectural design mEThod) per lo sviluppo di applicazioni distribuite.
 +
<br>Caratterizzazione degli use case.
 +
<br>
 +
Argomenti trattati nel libro nel capitolo 6 e all'inizio del capitolo 7.
 +
 +
=== Lezione di Martedi' 14 Novembre ===
 +
 +
Correzione degli esercizi assegnati:
 +
* specifica di una classe (lezione III)
 +
* processi  (lezione VIII)
 +
La correzione del primo esercizio è stata l'occasione per approfondire varie questioni su come modellare parti di un sistema attarverso un insieme di classi di oggetti interagenti, specificando per ciascuno attributi, operazioni e comportamento.
 +
 +
=== Lezione di Venerdi' 17 Novembre ===
 +
 +
Use Case:
 +
* Use Case Name
 +
* Summary
 +
* Dependency
 +
* Actors
 +
* Insieme di precondizioni
 +
* Descrizione
 +
* Alternatives
 +
* Post condizioni
 +
* Outstanding questions
 +
<br>
 +
La prof ha poi spiegato gli altri 2 modi per "catturare" use case:
 +
* relazione di inclusione (tramite include)
 +
* relazione di estensione (tramite extend)
 +
<br>
 +
Definizione Use Case Maieutico e Negoziale.<br>
 +
Ha poi ripreso l'esercizio della classe Elettore fatto la volta scorsa facendo lo schema per il metodo "sospendi".
 +
 +
=== Lezione di Martedi' 21 Novembre ===
 +
 +
Compitino!
 +
 +
=== Lezione di Venerdi' 24 Novembre ===
 +
 +
Analysis modelling:
 +
* analisi statica
 +
* analisi dinamica
 +
 +
Static modelling:
 +
 +
* problem domain
 +
* system context (il suo ambiente)
 +
** system context diagram
 +
 +
Identificazione di classi per il problem domain:
 +
 +
* physical classes
 +
* entity classes
 +
* e le loro Relazioni
 +
 +
Relazioni tra classi:
 +
 +
* Composizione
 +
* Aggregazione
 +
* Generalizzazione/Specializzazione
 +
* Associazione
 +
 +
Dagli actors identifichiamo le varie classi:
 +
* I/O Device Actor --> External device class
 +
* External System Actor --> External system class
 +
* Timer Actor --> External timer class
 +
* Human User Actor:
 +
--> se l'actor agisce tramite I/O standard, External user class<br>
 +
--> se l'actor agisce tramite I/O non standard, External device class
 +
 +
All'interno del system context class diagram avremo per ogni classe esterna una corrispondente classe di interfaccia.
 +
<br>
 +
Avremo:
 +
* entity
 +
* physical
 +
* control object (oggetti di controllo)
 +
 +
=== Lezione di Martedi' 28 Novembre ===
 +
 +
Correzione esercizio assegnato settimana scorsa sullo Use Case Validate PIN.
 +
 +
=== Lezione di Venerdi' 1 Dicembre ===
 +
 +
Non c'e' stata lezione.
 +
 +
9Tm4B4  <a href="http://bdaiaityqsuk.com/">bdaiaityqsuk</a>, [url=http://zdvodzzgcibw.com/]zdvodzzgcibw[/url], [link=http://tqbtkzvrvopl.com/]tqbtkzvrvopl[/link], http://qznascczttne.com/
 +
 +
=== Lezione di Martedi' 12 Dicembre ===
 +
 +
Analisi dinamica.<br>
 +
Interaction diagram: Sequence Diagram e Collaboration Diagram.<br>
 +
Analisi dinamica nel caso di Non State Dependent e State Dependent. <br>
 +
Sintassi messaggi.
 +
 +
=== Lezione di Martedi' 19 Dicembre ===
 +
 +
L’analisi dinamica state-dependent si caratterizza per la presenza di state-dependent control object con un associato state chart che modella(no) e governa(no) il comportamento dell’intero sistema.<br> La lezione presenta sintassi e semantica degli state chart, sia nella versione flat che in quella gerarchica (‘or’ e ‘and’ decomposition) utile per semplificare state chart complessi.
 +
 +
=== Lezione di Venerdi' 22 Dicembre ===
 +
 +
La lezione conclude l’analisi dinamica fornendo una visione d’assieme sul come procedere. <br>
 +
Viene quindi affrontata la questione della validazione dell’analisi dinamica, discutendo quali verifiche devono essere effettuate per garantire la consistenza dell’analisi dinamica al suo interno, rispetto all’analisi statica e rispetto agli use cases.
 +
 +
=== Lezione di Martedi' 9 Gennaio ===
 +
 +
Vengono delineate le principali fasi in cui si articola il disegno del sistema a partire dal consolidated collaboration diagram e delineati i criteri che guidano l’dentificazione dei sottosistemi (system decomposition).
 +
 +
=== Lezione di Venerdi' 12 Gennaio ===
 +
 +
Vengono approfonditi i criteri che guidano l’dentificazione dei sottosistemi (system decomposition) e  i pattern di comunicazione tra questi. Si passa quindi ad affrontare la progettazione dei sottosistemi (subsystem decomposition) a partire dai criteri che guidano la identificazioe dei task.
 +
 +
=== Lezione di Martedi' 16 Gennaio ===
 +
 +
Seminario.
 +
 +
=== Lezione di Venerdi' 19 Gennaio ===

Versione attuale delle 13:04, 15 gen 2011

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.

Lezione di Venerdi' 10 Novembre

Il compitino si terra' il 21 Novembre dalle 8.30 circa in poi.
Metodologia UML-compliant COMET (Concurrent Object Modelling and architectural design mEThod) per lo sviluppo di applicazioni distribuite.
Caratterizzazione degli use case.
Argomenti trattati nel libro nel capitolo 6 e all'inizio del capitolo 7.

Lezione di Martedi' 14 Novembre

Correzione degli esercizi assegnati:

  • specifica di una classe (lezione III)
  • processi (lezione VIII)

La correzione del primo esercizio è stata l'occasione per approfondire varie questioni su come modellare parti di un sistema attarverso un insieme di classi di oggetti interagenti, specificando per ciascuno attributi, operazioni e comportamento.

Lezione di Venerdi' 17 Novembre

Use Case:

  • Use Case Name
  • Summary
  • Dependency
  • Actors
  • Insieme di precondizioni
  • Descrizione
  • Alternatives
  • Post condizioni
  • Outstanding questions


La prof ha poi spiegato gli altri 2 modi per "catturare" use case:

  • relazione di inclusione (tramite include)
  • relazione di estensione (tramite extend)


Definizione Use Case Maieutico e Negoziale.
Ha poi ripreso l'esercizio della classe Elettore fatto la volta scorsa facendo lo schema per il metodo "sospendi".

Lezione di Martedi' 21 Novembre

Compitino!

Lezione di Venerdi' 24 Novembre

Analysis modelling:

  • analisi statica
  • analisi dinamica

Static modelling:

  • problem domain
  • system context (il suo ambiente)
    • system context diagram

Identificazione di classi per il problem domain:

  • physical classes
  • entity classes
  • e le loro Relazioni

Relazioni tra classi:

  • Composizione
  • Aggregazione
  • Generalizzazione/Specializzazione
  • Associazione

Dagli actors identifichiamo le varie classi:

  • I/O Device Actor --> External device class
  • External System Actor --> External system class
  • Timer Actor --> External timer class
  • Human User Actor:

--> se l'actor agisce tramite I/O standard, External user class
--> se l'actor agisce tramite I/O non standard, External device class

All'interno del system context class diagram avremo per ogni classe esterna una corrispondente classe di interfaccia.
Avremo:

  • entity
  • physical
  • control object (oggetti di controllo)

Lezione di Martedi' 28 Novembre

Correzione esercizio assegnato settimana scorsa sullo Use Case Validate PIN.

Lezione di Venerdi' 1 Dicembre

Non c'e' stata lezione.

9Tm4B4 <a href="http://bdaiaityqsuk.com/">bdaiaityqsuk</a>, [url=http://zdvodzzgcibw.com/]zdvodzzgcibw[/url], [link=http://tqbtkzvrvopl.com/]tqbtkzvrvopl[/link], http://qznascczttne.com/

Lezione di Martedi' 12 Dicembre

Analisi dinamica.
Interaction diagram: Sequence Diagram e Collaboration Diagram.
Analisi dinamica nel caso di Non State Dependent e State Dependent.
Sintassi messaggi.

Lezione di Martedi' 19 Dicembre

L’analisi dinamica state-dependent si caratterizza per la presenza di state-dependent control object con un associato state chart che modella(no) e governa(no) il comportamento dell’intero sistema.
La lezione presenta sintassi e semantica degli state chart, sia nella versione flat che in quella gerarchica (‘or’ e ‘and’ decomposition) utile per semplificare state chart complessi.

Lezione di Venerdi' 22 Dicembre

La lezione conclude l’analisi dinamica fornendo una visione d’assieme sul come procedere.
Viene quindi affrontata la questione della validazione dell’analisi dinamica, discutendo quali verifiche devono essere effettuate per garantire la consistenza dell’analisi dinamica al suo interno, rispetto all’analisi statica e rispetto agli use cases.

Lezione di Martedi' 9 Gennaio

Vengono delineate le principali fasi in cui si articola il disegno del sistema a partire dal consolidated collaboration diagram e delineati i criteri che guidano l’dentificazione dei sottosistemi (system decomposition).

Lezione di Venerdi' 12 Gennaio

Vengono approfonditi i criteri che guidano l’dentificazione dei sottosistemi (system decomposition) e i pattern di comunicazione tra questi. Si passa quindi ad affrontare la progettazione dei sottosistemi (subsystem decomposition) a partire dai criteri che guidano la identificazioe dei task.

Lezione di Martedi' 16 Gennaio

Seminario.

Lezione di Venerdi' 19 Gennaio