Architetture software

Anno accademico 2011-2012

Prof. Luca Cabibbo

• avvisi 
• introduzione al corso 
• programma
• lezioni
• homework
• materiale didattico
• esami
• informazioni per gli studenti del corso di Ingegneria del software (ord. 509/99)
• informazioni per gli studenti Erasmus

Avvisi

(È disponibile anche un elenco completo degli avvisi.)

Al fine di ridurre eventuali problemi legati al maltempo, la prova scritta degli esami di Architetture software e Ingegneria del software del 13 febbraio avrà inizio alle ore 10:00 anziché alle ore 9:00.

Inoltre, la prova scritta si svolgerà in aula N1 anziché in aula N13A.

Alcune informazioni circa lo svolgimento degli esami di Architetture software e Ingegneria del software nella sessione di febbraio 2012:

• la prova scritta sarà lunedì 13 febbraio 2012, alle ore 9:00 ore 10:00, in aula N13A aula N1
• tutti gli studenti che intendono sostenere l'esame di Architetture software (studenti dell'ordinamento 270) e Ingegneria del software (studenti dell'ordinamento 509) nell'appello di febbraio devono prenotarsi tramite portale dello studente entro mercoledì 8 febbraio - oppure, per posta elettronica, preferibilmente sempre entro l'8 febbraio, e comunque non oltre le ore 9:00 di venerdì 10 febbraio 
• gli orali si svolgeranno a partire dal 13 febbraio stesso, per proseguire, orientativamente, fino a venerdì 17 febbraio - se necessario, alcuni orali potranno svolgersi nella settimana successiva, ovvero tra il 20 e il 24 febbraio
• gli studenti potranno esprimere le loro eventuali preferenze per lo svolgimento degli orali durante la prova scritta (vi prego di non contattarmi in anticipo per questo, a meno che la preferenza è sostenere la prova orale al di fuori del periodo indicato qui sopra)
• ciascuno studente del corso di Ingegneria del software (ordinamento 509) che si prenota all'esame è invitato a contattarmi, sempre entro l'8 febbraio), per posta elettronica, per comunicarmi se intende sostenere l'esame con il programma dell'ultima edizione del corso di Ingegneria del software (vedi Ingegneria del software) oppure con il programma "ridotto" di Architetture software (ovvero, il programma di Architetture software di quest'ultima edizione, ad eccezione della parte sulle tattiche software)
  • in caso di mancata o tardiva comunicazione, assumerò per gli studenti 509 che intendono sostenere l'esame con l'ultimo programma di Ingegneria del software

Gli studenti che intendono frequentare il corso di Architetture software sono invitati a registrarsi al corso usando l'apposito modulo di registrazione.
Perché? Per sapere chi e quanti siete, e per conoscere i vostri indirizzi di posta elettronica, nel caso dovessi contattarvi).

Inoltre, a partire da questo anno accademico (per ora solo in via sperimentale) gli studenti iscritti al corso di Laurea Magistrale in Ingegneria informatica devono, all’inizio di ogni semestre, iscriversi ai corsi che intendono seguire nel semestre. Fare riferimento all'avviso in proposito sul sito del collegio didattico.

Gli studenti Erasmus, invece, sono invitati a leggere queste informazioni, e a registrarsi al corso usando quest'altro  modulo di registrazione.

Introduzione al corso

Introduzione al corso.

Architetture software

In breve, la disciplina delle architetture software – o architettura del software

• è interessata ai sistemi software complessi
• si occupa delle parti interessate allo sviluppo di un sistema e dei loro interessi, sia funzionali che, soprattutto, di qualità – ad es., prestazioni, disponibilità, modificabilità
• si occupa della strutturazione fondamentale interna del sistema in elementi e relazioni tra elementi - sia dal punto di vista metodologico che da quello tecnologico
• studia le relazioni tra la struttura interna del sistema e le sue qualità esterne
  • la comprensione di tali relazioni è alla base della progettazione dei sistemi software complessi
  • sulla base di questa comprensione, la progettazione dell'architettura software di un sistema può essere guidata dalle qualità fondamentali che il sistema deve esibire, e procedere sulla base dell’applicazione di principi, linee guida e soluzioni pre-esistenti

Obiettivo formativo

Il corso di Architetture software ha l’obiettivo di presentare gli aspetti sia metodologici che tecnologici relativi alle architetture software, che hanno un ruolo fondamentale nel raggiungimento degli obiettivi di qualità (requisiti non funzionali) dei sistemi software.

Specificamente, ha l’obiettivo di presentare metodologie e strumenti per la progettazione e la valutazione di architetture software e, in particolare, di architetture per sistemi software distribuiti e di tipo enterprise, incluse le architetture basate su componenti e le architetture orientate ai servizi.

Alla fine del corso lo studente dovrebbe sapere impostare un progetto di un’architettura software, analizzandone dettagli e problematiche tecnologiche e metodologiche, e valutare l’architettura in termini di raggiungimento di obiettivi di qualità.

Prerequisiti

Il corso non prevede specifici prerequisiti: tutto ciò che è stato studiato sarà utile - ma niente indispensabile.
Un prerequisito importante è certamente il corso di Analisi e progettazione del software. Altri prerequisiti molto utili sono i corsi di Sistemi informativi su web e Sistemi operativi. Utile Basi di dati II, così come Programmazione concorrente e Sicurezza dei sistemi informatici e delle reti.

Per questo motivo, la partecipazione al corso:

• è fortemente sconsigliata agli studenti della laurea triennale;
• è sconsigliata anche agli studenti del primo anno della laurea magistrale - nel senso che possono fruire meglio di questo corso al secondo anno.

È inoltre utile una buona conoscenza della lingua inglese.

Programma

Programma del corso di Architetture software relativo all'anno accademico 2011-2012.

• Architetture software:
  • introduzione e concetti di base
  • processo di definizione dell'architettura software
  • parti interessate e interessi - requisiti e qualità
  • descrivere l'architettura - punti di vista e viste
  • progettare per le qualità - tattiche architetturali - stili architetturali - prospettive architetturali (cenni)
  • valutazione di architetture software (cenni)
• Architetture dei sistemi distribuiti
  • architetture distribuite: client/server, architettura a oggetti distribuiti, messaging e integrazione di applicazioni, architetture a componenti, web services, architettura orientata ai servizi, cloud computing 
• Middleware e tecnologie per sistemi distribuiti
  • tecnologie a oggetti distribuiti, messaging, componenti, web services, tecnologie per il cloud computing 

Lezioni

Le lezioni del corso di Architetture software si svolgeranno

• nel primo semestre - dal 3 ottobre al 15 (credo) dicembre 2011, e dal 9 al 27 gennaio 2012
• lunedì e giovedì - talvolta anche il mercoledì (avvisi in proposito dati in anticipo a lezione e sul sito del corso)
• dalle 11:30 alle 13:00
• in aula DS3A

Argomenti delle lezioni

Homework

Gli homework, scritti a mano, vanno fatti pervenire al docente durante le lezioni del corso o al ricevimento studenti, nei tempi indicati nella seguente tabella. In particolare, se la data di consegna è un giorno in cui è prevista lezione, la consegna va fatta entro l'inizio della lezione stessa.

E' possibile consegnare l'homework in ritardo rispetto alla data di consegna indicata nella tabella?
Sì, ma con le seguenti osservazioni: (i) il ritardo massimo è una lezione (ovvero, l'homework può essere consegnato al più alla lezione successiva rispetto alla data indicata in tabella) e (ii) il numero massimo di ritardi ammessi per ciascuno studente è uno (ovvero, uno studente non può consegnare due homework in ritardo).

Materiale didattico

Materiale didattico di riferimento

Il materiale didattico di riferimento per il corso, che sarà disponibile su questo sito web, è costituito da:

• dispense - i link alle dispense saranno disponibili nella sezione delle lezioni.
• articoli e presentazioni - i link sono qui sotto

Articoli e presentazioni (in programma) 

• [Kruchten, 1995] P. Kruchten, Architectural Blueprints - The "4+1" View Model of Software Architecture, IEEE Software, 1995 (copia locale)
  • presenta il famoso modello a 4+1 viste per la progettazione e la descrizione di architetture
• [Parnas, 1972] D.L. Parnas, On the Criteria To Be Used in Decomposing Systems into Modules, Communications of the ACM, 1972 (copia locale)
  • un altro famoso articolo
• [Bachmann, 2007] F. Bachmann, L. Bass, R. Nord, Modifiability Tactics, Rapporto tecnico CMU/SEI-2007-TR-002 (copia locale)
  • introduce le tattiche architetturali e presenta un catalogo di tattiche per la modificabilità
  • inoltre, correla le tattiche presentate con alcuni diffusi stili architetturali
• [UML Components] J. Daniels, UML Components (copia locale)
• [Berkeley, 2009] Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz, Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, Matei Zaharia, Above the Clouds: A Berkeley View of Cloud Computing, Technical Report EECS-2009-28, EECS Department, University of California, Berkeley. (copia locale)

Articoli e presentazioni (letture consigliate, ma non in programma)

• [IEEE 1471-2000] IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description of Software-Intensive Systems (copia locale)
  • uno standard IEEE relativo alle architetture software
• [Boehm, 1988] B.W. Boehm, A Spiral Model of Software Development and Enhancement, IEEE Computer, 1988 (copia locale)
  • presenta il famoso modello a spirale per lo sviluppo del software
• [Scott, 2009] J. Scott, R. Kazman, Realizing and refining Architectural Tactics: Availability, Rapporto tecnico CMU/SEI-2009-TR-006 (copia locale)
  • presenta un catalogo di tattiche per la disponibilità
  • a differenza di [Bachmann, 2007], lo presenta per differenza da [SAP], quindi non è un articolo del tutto autocontenuto
  • presenta anche uno studio di caso di progettazione basato su tattiche, non proprio semplice 
• [Kim, 2009] S. Kim, D.K. Kim, L. Lu, S. Park, Quality-driven architecture development using architectural tactics, The Journal of Systems and Software, 2009 (copia locale)
  • tra le altre cose (meno importanti) presenta uno studio di caso relativo alla progettazione basato su tattiche architetturali

Altro materiale didattico, di consultazione

Il corso ed il relativo materiale didattico è ispirato ad un certo numero di libri sulle architetture software, che sono pertanto utili per la consultazione (dovrebbero essere quasi tutti disponibili nella biblioteca di ateneo) ma non necessari, soprattutto in caso di regolare frequenza alle lezioni del corso. 

Altri articoli e presentazioni

• Google Chrome: Behind the Open Source Browser Project (copia locale)
• [Bernstein 1996] P.A. Bernstein, Middleware: A Model for Distributed System Services (copia locale)
• [C/S] Architetture client/server
  • Client/Server Software Architectures - an overview
  • Two-tier Software Architectures
  • Three-tier Software Architectures
• [S. Androutsellis-Theotokis, D. Spinellis, 2004] A Survey of Peer-to-Peer Content Distribution Technologies. ACM Computing Surveys, 2004.
• [Bakken 2003] D.E. Bakken, Middleware, in Encyclopedia of Distributed Computing (copia locale)
• [Lampson2004] B.W.Lampson, Computer Security in the Real World, IEEE Computer, 2004 (copia locale)

Altro materiale didattico sarà predisposto facendo riferimento, tra l'altro, anche ai seguenti libri:

Libri su architetture software

[SAP]

Len Bass, Paul Clements, Rick Kazman
Software architecture in practice (2nd edition)
Pearson, Addison Wesley, 2003

[POSA1]

Frank Buchmann, Regine Meunier, Peter Sommerlad, Michael Stal
Pattern-oriented software architecture – a system of patterns
John Wiley & Sons, 1996

[POSA4]

Frank Buchmann, Kevlin Henney, Douglas C. Schmidt
Pattern-oriented software architecture – a pattern language for distributed computing
John Wiley & Sons, 2007

[SSA]

Nick Rozanski e Eoin Woods
Software Systems Architecture
Addison Wesley, 2005

[DSA]

Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord, Judith Stafford
Documenting software architecture, views and beyond
Addison Wesley, 2003

[ESA]

Paul Clements, Rick Kazman, Mark Klein
Evaluating software architectures - methods and case studies
Addison Wesley, 2002

[TMD]

Richard N. Taylor, Nenad Medvidovic, Eric M. Dashofy
Software architecture - foundations, theory, and practice
John Wiley and Sons, 2010

[Gorton]

Ian Gorton
Essential software architecture
Springer, 2006

 

[Cheesman&Daniels]

J. Cheesman, J. Daniels
UML Components - un semplice processo per la specifica di software basato su componenti
Addison-Wesley, 2002

[Papazoglou]

Michael P. Papazoglou
Web services: Principles and Technology
Pearson Education, 2008

[ACKM]

Gustavo Alonso, Fabio Casati, Harumi Kuno, Vijay Machiraju
Web Services, concepts, architectures and applications
Springer-Verlag, 2004

[DEA/2e]

Inderjeet Singh, Beth Stearns, Mark Johnson and the Enterprise Team
Designing Enterprise Applications with the J2EE Platform (second edition)
Addison-Wesley, 2002

Libri su sistemi distribuiti e tecnologie enterprise

[CDK/4e]

George Coulouris, Jean Dollimore, Tim Kindberg
Distributed systems, concepts and design (4th edition)
Pearson, Addison Wesley, 2005

[EIP]

Gregor Hohpe, Bobby Woolf

Enterprise Integration Patterns - Designing, Building, and Deploying Messaging Solutions
Addison-Wesley, 2004

[Liu]

M. L. Liu

Distributed Computing - Principles and Applications
Pearson Education, 2004

[Mastering EJB/4ed]

Rima Patel Sriganesh, Gerald Brose, Micah Silverman
Mastering Enterprise JavaBeans 3.0 (4th edition)
Wiley, 2006

Libri sulla progettazione orientata agli oggetti 

[GoF]

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Design Pattern - Elements of Reusable Object-oriented Software
Addison-Wesley, 1995

[GoF] in italiano

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Design Pattern - Elementi per il riuso di software a oggetti
Addison-Wesley, 2002

[Larm/3e]

Craig Larman
Applicare UML e i pattern - Analisi e progettazione orientata agli oggetti
Terza edizione
Pearson Education Italia, 2005

Sito web del corso

• cabibbo.dia.uniroma3.it/asw

Newsgroup del corso

• Ospiti del forum di Architetture software presso Forum StudentiDia.org
• La partecipazione al newsgroup è libera, ma richiede un comportamento civile e responsabile.
  Si consiglia di leggere Etica e norme di buon uso dei servizi di rete, nonché il regolamento del forum che ci ospita.

Esami

L'esame di Architetture software consiste di:

• una prova scritta - circa 15 punti su 30
• una prova orale - circa 15 punti su 30

Le date previste per le prove scritte dell'esame di Architetture software sono:

• febbraio 2012
• giugno/luglio 2012
•  settembre 2012

Per partecipare all'esame è necessario prenotarsi all'esame presso il Portale dello studente. La prenotazione va fatta entro quattro giorni lavorativi (che corrispondono a circa una settimana effettiva) prima della data dell'appello (vedi date indicate sopra).

Chi avesse problemi a prenotarsi presso il sito delle prenotazioni è invitato caldamente a contattare il docente per posta elettronica entro gli stessi termini.

Per motivi organizzativi, gli studenti non prenotati sul Portale dello studente che non contatteranno il docente entro 24 ore dall'esame non saranno ammessi all'esame stesso.

Testi di prove d'esame di appelli conclusi

Non sono disponibili testi d'esame di appelli conclusi.

Informazioni per gli studenti del corso di Ingegneria del software (ord. 509/99)

Informazioni per gli studenti del corso spento di Ingegneria del software (della Laurea Specialistica in Ingegneria informatica secondo l'ordinamento 509/99):

• sito web del corso di Ingegneria del software
• gli studenti possono sostenere l'esame con riferimento al programma ed alle modalità d'esame dell'ultima edizione del corso di Ingegneria del software (informazioni sul sito web del corso di Ingegneria del software)
• in alternativa - e anche in considerazione del fatto che il corso di Architetture software condivide in modo significativo obiettivi formativi, programma, contenuti e materiale didattico del corso spento di Ingegneria del software - gli studenti possono sostenere l'esame con riferimento ad un opportuno sottoinsieme del programma d'esame di Architetture software, con alle modalità d'esame di Architetture software (con riferimento all'ultima edizione del corso tenuta)
• in ogni caso, è bene contattare il docente con congruo anticipo

Informazioni per gli studenti Erasmus

In passato, si sono verificate delle situazioni spiacevoli con alcuni studenti Erasmus.
(Ci tengo a sottolineare il fatto che ciò è avvenuto solo con alcuni studenti Erasmus: altri studenti Erasmus si sono comportati correttamente, ed hanno studiato in modo assolutamente dignitoso).

A causa di tali avvenimenti, gli studenti Erasmus interessati a frequentare e sostenere l'esame di Architetture software devono: 

• contattare il docente per incontrarlo e farsi conoscere, il prima possibile - per verificare che siano effettivamente interessati al corso e ne posseggano i prerequisiti necessari - altrimenti (se senza interesse o senza prerequisiti) è bene che cambino il loro learning agreement
• andare dal docente, a ricevimento studenti, almeno una volta al mese (fin dall'inizio del corso), e comunque con largo anticipo rispetto a quando intendono sostenere l'esame - per far sì che la preparazione proceda in modo corretto - ovvero per verificare che non stiano studiando poco o male

Si ricorda inoltre che al corso di Architetture software sono attribuiti 6 CFU (crediti formativi universitari), e che pertanto l'impegno richiesto ad uno studente in possesso dei prerequisiti del corso è di circa 6x25=150 ore.

Il docente sottolinea che finora ha trattato - e continuerà a trattare - gli studenti Erasmus allo stesso modo - dunque, né meglio né peggio - degli studenti locali.
In particolare (anche se non ci dovrebbe essere bisogno di dirlo) uno studente Erasmus che studia bene la materia verrà promosso all'esame, mentre uno studente Erasmus che studia poco o studia male la materia verrà bocciato all'esame - esattamente come verrebbe bocciato all'esame uno studente locale che studia poco o studia male. Questo indipendentemente da qualunque fatto o situazione che non riguarda strettamente lo studio e la comprensione della materia. E con l'ovvia considerazione che decidere se uno studente ha studiato bene o male è responsabilità della commissione d'esame - e non dello studente.

En pasado, se han verificado unas situaciones desagradables con unos estudiantes Erasmus.
(Quiero acentuar que esto ha pasado solo con unos estudiantes Erasmus: otros estudiantes se han comportado correctamente y han siempre estudiado de una manera absolutamente decente.) 

Por esos eventos, los estudiantes Erasmus que son interesados a frecuentar y dar el examen de Architetture Software tienen que: 

• contactar el profesor para encontrarlo y conocerlo lo más pronto posible, para verificar que sean realmente interesados al curso y que posean los requisitos necesarios – de otra manera (sin interese o sin requisitos) es mejor que cambien sus learning agreement
• ir dal profesor durante el recibimiento de los estudiantes por lo meno una vez al mes (desde el principio del curso), y de toda manera bastante tiempo antes del día del examen – para que sus preparación proceda de una manera correcta- es decir para verificar que no estudien poco o mal

Se recuerda tambien que al curso de Architetture Software se dan 6 CFU (crediti formativi universitari), y que entonces el empeño que se pide a un estudiante que ya posee los requisitos del curso es más o menos de 6x25=150 horas .

El profesor acentua que hasta ahora ha tratado – y seguirá tratando- los estudiantes Erasmus de la misma manera – es decir ni mejor ni pejor – de los estudiantes locales .
En particular, aunque no sea necesario decirlo, un estudiante Erasmus que estudia bien la materia aprobará el examen, mientras un estudiante Erasmus que estudia poco o mal la materia suspenderá el examen – de la misma manera de un estudiante local que estudia poco o estudia mal. Eso independientemente de todos los aspectos que no conciernen propiamente el estudio y la comprensión de la materia. Y, por supuesto,considerando tambien que es la Comision de Examen que decide si un estudiante ha estudiado poco o mal – y no el estudiante mismo.