Ingegneria del software - paniere completo

Set domande: ingegneria del software

Ingegneria informatica e dell'automazione (D.M. 270/04)

Docente: Sarti Luigi

Indice

• Lezione 002 ............................................................................................................................. p. 4
• Lezione 003 ............................................................................................................................. p. 5
• Lezione 004 ............................................................................................................................. p. 6
• Lezione 005 ............................................................................................................................. p. 9
• Lezione 006 ............................................................................................................................. p. 11
• Lezione 007 ............................................................................................................................. p. 12
• Lezione 008 ............................................................................................................................. p. 14
• Lezione 009 ............................................................................................................................. p. 16
• Lezione 010 ............................................................................................................................. p. 17
• Lezione 011 ............................................................................................................................. p. 19
• Lezione 012 ............................................................................................................................. p. 21
• Lezione 013 ............................................................................................................................. p. 22
• Lezione 014 ............................................................................................................................. p. 23
• Lezione 017 ............................................................................................................................. p. 24
• Lezione 018 ............................................................................................................................. p. 25
• Lezione 019 ............................................................................................................................. p. 26
• Lezione 020 ............................................................................................................................. p. 28
• Lezione 021 ............................................................................................................................. p. 29
• Lezione 022 ............................................................................................................................. p. 31
• Lezione 023 ............................................................................................................................. p. 34
• Lezione 024 ............................................................................................................................. p. 35
• Lezione 025 ............................................................................................................................. p. 36
• Lezione 026 ............................................................................................................................. p. 38
• Lezione 027 ............................................................................................................................. p. 40
• Lezione 028 ............................................................................................................................. p. 41
• Lezione 029 ............................................................................................................................. p. 42
• Lezione 030 ............................................................................................................................. p. 44
• Lezione 031 ............................................................................................................................. p. 45
• Lezione 032 ............................................................................................................................. p. 46
• Lezione 033 ............................................................................................................................. p. 47
• Lezione 034 ............................................................................................................................. p. 49
• Lezione 035 ............................................................................................................................. p. 51
• Lezione 037 ............................................................................................................................. p. 52
• Lezione 038 ............................................................................................................................. p. 55
• Lezione 039 ............................................................................................................................. p. 56
• Lezione 040 ............................................................................................................................. p. 57
• Lezione 042 ............................................................................................................................. p. 58
• Lezione 044 ............................................................................................................................. p. 59

Lezione 002

Ruolo

1. Che significato assume il termine nel contesto di un progetto di sviluppo software?
   • Con il termine ruolo indichiamo l'elenco ordinato delle procedure che regolano lo sviluppo del software.
   • Con il termine ruolo indichiamo l'insieme dei casi di test assegnati ad un utente pilota in fase di validazione del sistema.
   • Con il termine ruolo indichiamo un insieme di responsabilità nel progetto del sistema.
   • Con il termine ruolo indichiamo il singolo compito assegnato ad un utente in fase di elicitazione dei requisiti.
2. Una delle seguenti affermazioni, relative al concetto di modello, non è corretta. Quale?
   • I metodi orientati agli oggetti combinano il modello e quello delle soluzioni.
   • Il modello delle soluzioni è il risultato di una trasformazione del modello.
   • Lo sviluppo di un sistema software richiede di identificare e descrivere il sistema come un insieme di modelli che affrontano i problemi del progettista.
   • Il modello viene inizialmente costruito come un insieme di oggetti e relazioni, che rappresentano i concetti del mondo reale che devono essere manipolati.
3. Una delle seguenti affermazioni, relative al concetto di modello, non è corretta. Quale?
   • Il modello di un sistema software include fin dalle prime fasi di sviluppo la specifica del dominio delle soluzioni, che spiega come dominare la complessità delle possibili soluzioni.
   • Un modello è una rappresentazione astratta di un sistema.
   • I progettisti di un sistema software costruiscono il modello di un sistema che ancora non esiste.
   • Un modello è utile quando le dimensioni del sistema, o il suo livello di complessità, o ancora problemi di accessibilità e sicurezza lo rendono difficilmente manipolabile in modo diretto.
4. Che cos'è un deliverable?
   • È un documento o un prototipo da sottoporre al committente.
   • È un modello assimilabile ad un design pattern.
   • È una componente software riusabile.
   • È un semilavorato ad uso interno da parte di altri sviluppatori.
5. Una delle affermazioni che seguono non è corretta. Quale?
   • Un compito consuma risorse e produce un prodotto.
   • Una risorsa può essere un partecipante, un periodo di tempo o della attrezzatura.
   • Un progetto di sviluppo di un sistema software è articolato in compiti (task), e ogni compito è composto da un certo numero di attività.
   • Un prodotto può essere un sistema, un modello o un documento.
6. Che cos'è, nel contesto dell'ingegneria del software, una notazione? Fornisci un esempio.
   • Una notazione è un insieme di regole grafiche o testuali usate per rappresentare un modello. Le notazioni sono importanti perché ci permettono di esprimere dei concetti complessi in modo sintetico e preciso. Le notazioni adottate in un progetto devono avere una semantica ben definita, essere adeguate a rappresentare aspetti specifici del sistema, ed essere ben comprese dai partecipanti al progetto. UML (Unified Modeling Language) è un esempio di notazione usata per rappresentare i modelli orientati ad oggetti.
7. Che cos'è, nel contesto dell'ingegneria del software, una metodologia? In che cosa si differenzia da un metodo?
   • Una metodologia è una collezione di metodi per risolvere una classe di problemi specifica come e quando ogni metodo debba essere usato. Le metodologie di sviluppo software decompongono il processo in attività. Per ogni attività la metodologia identifica uno o più metodi. Il metodo è una tecnica ripetibile che specifica i passi richiesti per risolvere un dato problema.

Lezione 003

Elicitazione dei requisiti

1. In merito all'attività di elicitazione dei requisiti, una delle affermazioni seguenti non è corretta. Quale?
   • Le tipologie di attore sono tre: l'utente, il committente e lo sviluppatore.
   • Il risultato dell'attività di elicitazione dei requisiti è una descrizione del sistema in termini di attori e casi d'uso.
   • Durante l'elicitazione dei requisiti il cliente e gli sviluppatori definiscono lo scopo del sistema.
   • I casi d'uso sono sequenze generali di eventi che descrivono tutte le possibili interazioni col sistema per una data funzionalità.
2. In merito all'attività di analisi dei requisiti, una delle affermazioni seguenti non è corretta. Quale?
   • Durante l'analisi gli sviluppatori producono un modello del sistema che sia corretto, completo, consistente e non ambiguo.
   • Il risultato è un modello del sistema annotato con attributi, operazioni e associazioni, e descritto in termini sia strutturali che dinamici.
   • I casi d'uso prodotti nella fase di elicitazione dei requisiti vengono tradotti in un modello relazionale che descrive la struttura delle classi del sistema, ma trascura per il momento la definizione dell'interfaccia utente.
   • Eventuali ambiguità e inconsistenze nei casi d'uso vengono risolte con la collaborazione dell'utente.
3. In merito all'attività di progettazione del sistema, una delle affermazioni seguenti non è corretta. Quale?
   • Per consentire agli utenti di contribuire alla validazione del modello a oggetti del system design, questo viene rappresentato in una notazione a loro facilmente comprensibile.
   • Durante il system design vengono selezionati il database management system e il controllo di flusso globale.
   • Durante il system design gli sviluppatori definiscono gli obiettivi del design e decompongono il sistema in sottosistemi più piccoli.
   • Durante il system design vengono selezionate la piattaforma hw/sw e le politiche di accesso.
4. In merito all'attività di progettazione degli oggetti, una delle affermazioni seguenti non è corretta. Quale?
   • L'attività di object design include la selezione di componenti riusabili.
   • L'attività di object design include la descrizione precisa degli oggetti e delle interfacce dei sottosistemi.
   • Durante l'object design gli sviluppatori definiscono gli oggetti del dominio delle soluzioni.
   • La fase di object design ha lo scopo di colmare la distanza tra il modello dell'analisi e la piattaforma hw/sw identificata nella fase di elicitazione dei requisiti.
5. In merito all'attività di validazione (testing), una delle affermazioni seguenti non è corretta. Quale?
   • Durante il testing gli utenti cercano differenze tra il sistema e i suoi modelli, eseguendo il sistema con campioni di dati di output.
   • Durante i test di integrazione i sottosistemi sono aggregati e confrontati con il modello del system design.
   • Durante il system testing il sistema viene eseguito con casi tipici ed eccezioni e confrontato col modello dei requisiti.
   • Durante lo unit testing gli sviluppatori confrontano il modello dell'object design con ogni oggetto e sottosistema.
6. Il ruolo di manager di un progetto di sviluppo software richiede lo svolgimento di numerose attività. Quale, tra quelle elencate di seguito, è considerata la più critica, e richiede in genere il maggiore investimento di tempo?
   • La gestione del rationale.
   • La gestione della configurazione software.
   • Il coordinamento delle comunicazioni tra i partecipanti del gruppo di lavoro.
   • Il monitoraggio dello stato di avanzamento del progetto.

Lezione 004

Diagrammi UML delle classi

1. In merito ai diagrammi UML delle classi, una delle affermazioni che seguono non è corretta. Quale?
   • I diagrammi delle classi sono usati per descrivere la struttura di un sistema.
   • Gli oggetti sono astrazioni che specificano la struttura e il comportamento in comune ad un insieme di classi.
   • I diagrammi delle classi descrivono il sistema in termini di oggetti, classi, attributi, operazioni e associazioni.
   • Un oggetto è dotato di uno stato, che include i valori dei suoi attributi e i collegamenti (link) con altri oggetti.
2. In merito ai diagrammi UML dei casi d'uso, una delle affermazioni che seguono non è corretta. Quale?
   • Un caso d'uso descrive una funzione che, offerta dal sistema, produce un risultato visibile per un attore.
   • L'identificazione di attori e casi d'uso ha come effetto la delimitazione dei confini del sistema.
   • Un attore descrive un'entità che interagisce col sistema: un utente, un altro sistema, l'ambiente fisico in cui il sistema si trova ecc.
   • I casi d'uso sono utili nelle fasi di elicitazione dei requisiti e di analisi per rappresentare le funzionalità del sistema. Essi mettono a fuoco il comportamento del sistema dal punto di vista dello sviluppatore.
3. In merito al modello dinamico, una delle affermazioni che seguono non è corretta. Quale?
   • I diagrammi di interazione descrivono il comportamento interno del sistema come una sequenza di messaggi scambiati tra un insieme di oggetti.
   • I diagrammi di stato descrivono il comportamento nei termini degli stati che oggetti individuali possono assumere, e delle transizioni tra tali stati.
   • I diagrammi di sequenza descrivono l'ordine in cui i processi paralleli devono essere serializzati.
   • I diagrammi di attività descrivono il comportamento in termini di flussi di controllo e di flussi dei dati.
4. In merito ai diagrammi UML delle interazioni, una delle affermazioni che seguono non è corretta. Quale?
   • I diagrammi delle interazioni consentono di visualizzare le comunicazioni tra gli oggetti.
   • I diagrammi delle interazioni consentono di formalizzare il comportamento dinamico del sistema.
   • I diagrammi delle interazioni consentono di modellare le caratteristiche grafiche degli oggetti boundary.
   • I diagrammi delle interazioni consentono di identificare ulteriori oggetti partecipanti nel caso d'uso.
5. In merito ai diagrammi UML degli stati, una delle affermazioni che seguono non è corretta. Quale?
   • Uno stato rappresenta un particolare insieme di valori che gli attributi dell'oggetto possono assumere.
   • Dato uno stato, una transizione identifica uno stato futuro in cui l'oggetto può portarsi.
   • I diagrammi degli stati descrivono il comportamento dinamico di un singolo oggetto.
   • I diagrammi degli stati sono rappresentati mediante grafi diretti aciclici (DAG).
6. Il diagramma che segue descrive, in termini introduttivi, la fase di analisi dei requisiti: Che etichetta deve essere specificata nel box con il punto interrogativo?
   • Modello dinamico
   • Casi di test
   • Casi d'uso
   • Modello delle classi
7. In merito ai diagrammi UML delle attività, una delle affermazioni che seguono non è corretta. Quale?
   • L'esecuzione di un'attività può essere innescata da un evento esterno.
   • L'esecuzione di un'attività può essere innescata dalla sopravvenuta disponibilità di un oggetto.
   • L'esecuzione di un'attività può essere innescata dal completamento di un'altra attività.
   • Un diagramma di attività descrive il comportamento di un utente in base ai compiti che lo stesso utente affronta.
8. Il diagramma che segue descrive in termini introduttivi la fase di object design: Che etichetta deve essere inserita nel box con il punto interrogativo?
   • Modello dinamico
   • Casi di test
   • Decomposizione in sottosistemi
   • Casi d'uso
9. Il diagramma seguente descrive in termini introduttivi la fase di system design: Che etichetta deve essere inserita nel box con il punto interrogativo?
   • Casi di test
   • Elicitazione dei requisiti
   • Modello dinamico
   • Casi d'uso
10. Nel seguito sono elencate alcune possibili caratteristiche della notazione adottata in un progetto. Solo tre di queste caratteristiche sono indicate, nella lezione 4, come indispensabili. Qual'è l'intrusa?