Risposte aperte paniere di Ingegneria del software

Domande aperte sul tema dell'ingegneria del software

Definizione di notazione

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 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, di seguito un esempio di tale notazione:

Definizione di metodologia

Che cos'è, nel contesto dell'Ingegneria del Software, una metodologia? In che cosa si differenzia da un metodo?

Un metodo è una tecnica ripetibile che specifica i passi richiesti per risolvere un dato problema. Una metodologia, invece, è una collezione di metodi per risolvere una classe di problemi che specifica come e quando ogni metodo debba essere usato. Le metodologie di sviluppo software dividono il processo in attività e per ogni attività (es. analisi, progettazione del sistema), la metodologia identifica uno o più metodi.

Diagrammi UML

Diagramma delle classi per la relazione genitori e figli

Disegna un diagramma delle classi per rappresentare la relazione tra genitori e figli. Considera che una persona può avere sia genitori che figli. Annota le associazioni con ruoli e molteplicità.

Diagramma delle classi per un libro

Disegna un diagramma delle classi che rappresenta un libro definito così: "un libro è composto da parti, a loro volta composte da capitoli; un capitolo è composto da sezioni". Concentrati sulle classi e le relazioni.

Notazioni UML

Definizione di vincolo

Nell'ambito delle notazioni adottate nei diagrammi UML, che cos'è un vincolo (constraint)? Fornisci un esempio.

Un vincolo è una regola che, collegata a un elemento di modello UML, ne restringe la semantica; questo consente di rappresentare fenomeni altrimenti impossibili da esprimere in UML. Ad esempio un Incidente può essere associato a più di un ReportEmergenza; però è importante che il Controllore possa visualizzarli in ordine cronologico. Possiamo rappresentare cronologico come un vincolo, espresso come stringa in linguaggio naturale.

Definizione di package

Nell'ambito delle notazioni adottate nei diagrammi UML, che cos'è un package? Fornisci un esempio.

La complessità dei modelli può essere dominata raggruppando in packages gli elementi tra loro correlati. Un package è un raggruppamento di elementi di un modello, come casi d'uso o classi, che definisce un ambito di comprensione. Un package è visualizzato come un rettangolo dotato di linguetta superiore sinistro. Packages per organizzare i casi d'uso in gruppi e concentrarsi su pochi casi alla volta. Packages con dettagli nascosti.

Definizione di nota

Nell'ambito delle notazioni adottate nei diagrammi UML, che cos'è una nota? Fornisci un esempio.

Una nota è un commento annesso a un diagramma. Le note sono usate dagli sviluppatori per aggiungere informazioni ai modelli e agli elementi del modello. Questo meccanismo serve ad esplicitare aspetti importanti per un modello, chiarire un punto complesso, indicare elementi che richiedono ulteriori elaborazioni oppure registrare promemoria.

Definizione di stereotipo

Nell'ambito delle notazioni adottate nei diagrammi UML, che cos'è uno stereotipo? Fornisci un esempio.

Uno stereotipo è un meccanismo di estensione che consente di classificare gli elementi dei modelli in UML. Esso è rappresentato con una stringa di caratteri «» racchiusa tra virgolette basse, dette anche francesi, all'elemento del modello al quale si applica, ad es. una classe o un'associazione. In fase di analisi è possibile classificare gli oggetti in tre categorie: entity, boundary e control:

• Gli oggetti di tipo Entity rappresentano le informazioni persistenti che il sistema mantiene.
• Gli oggetti di tipo Boundary rappresentano le interazioni tra gli attori e il sistema.
• Gli oggetti di tipo Control implementano i casi d'uso.

Elicitazione dei requisiti

Definizione di affidabilità

In merito al tema dell'elicitazione dei requisiti, che cosa si intende con affidabilità di un sistema?

L'affidabilità di un sistema è la capacità del sistema stesso, o di un componente facente parte, di eseguire le funzioni per le quali è stato progettato sotto determinate condizioni e per uno specifico lasso temporale. I requisiti di affidabilità includono, ad esempio, un accettabile tempo di funzionamento esente da guasti, la capacità di rilevare automaticamente particolari guasti, o di resistere a specifici attacchi di sicurezza.

Definizione di usabilità

In merito al tema dell'elicitazione dei requisiti, che cosa si intende con usabilità di un sistema o di una sua componente?

L'usabilità di un sistema, è la facilità con cui un utente può imparare ad operare il Sistema o una sua componente, prepararne i dati di input ed interpretarne gli output. I requisiti di usabilità includono, ad esempio, le convenzioni e le metafore adottate per l'interfaccia utente, l'ampiezza dell'help online, i livelli di documentazione per l'utente, ecc. Spesso il committente richiede che l'interfaccia del sistema venga sviluppata secondo specifiche linee guida, schemi di colore, includa un particolare logo, usi determinati font ecc.

Definizione di supportabilità

In merito al tema dell'elicitazione dei requisiti, che cosa si intende con supportabilità di un sistema?

I requisiti di supportabilità sono relativi alla capacità di garantire assistenza e mantenimento, e alla facilità di apportare cambiamenti al sistema dopo il suo rilascio, come:

• Adattabilità, ossia la capacità di modificare il sistema per integrare ulteriori concetti;
• Manutenibilità, la capacità di modificare il sistema per correggerne i difetti;
• Internazionalizzazione, la capacità di modificare il sistema per integrare nuove convenzioni internazionali, come linguaggi, unità di misura, ecc;
• Portabilità, la facilità con cui un sistema o una componente possono essere trasferiti da un ambiente hardware-software ad un altro.

Requisiti di validazione

Durante la progettazione del sistema i requisiti sono frequentemente validati con il committente e con gli utenti. La validazione dei requisiti si articola in controlli di completezza, consistenza, non-ambiguità e correttezza. Descrivi il significato di queste categorie di validazione.

La specifica dei requisiti si ritiene:

• Completa, se rappresenta tutti i possibili scenari di descrizione del sistema, inclusi i comportamenti eccezionali;
• Consistente, se non si contraddice;
• Non-ambigua, se definisce esattamente un sistema e non ha interpretazioni alternative;
• Corretta, se rappresenta accuratamente il sistema che il committente si aspetta e che gli sviluppatori intendono costruire.

Proprietà desiderabili della specifica dei requisiti

Tre proprietà desiderabili della specifica dei requisiti sono che essa sia realistica, verificabile e tracciabile. Descrivi queste tre proprietà.

Un requisito è definito:

• Realistico se il sistema può essere realizzato nel contesto dei vincoli considerati;
• Verificabile se, una volta costruito il sistema, test ripetibili possono essere usati per dimostrare che il sistema soddisfa i requisiti;
• Tracciabile se, per ogni requisito è possibile, durante tutto il processo di sviluppo, identificare le corrispondenti funzionalità del sistema, e se da ogni funzionalità è possibile risalire a ritroso ai corrispondenti requisiti.

Greenfield engineering

Che cosa si intende con il termine greenfield engineering?

Nell'ingegnerizzazione ex-novo (greenfield engineering) lo sviluppo parte da zero: non esiste un sistema precedente da integrare o sostituire. I requisiti sono forniti dal committente e dagli utenti. Il progetto è innescato da un'esigenza degli utenti, dalla creazione di un nuovo mercato, ecc.

Requisiti relativi alle prestazioni

In merito al tema dell'elicitazione dei requisiti, i requisiti relativi alle prestazioni (performance) coinvolgono attributi quantificabili del sistema. Cita almeno tre esempi di tali attributi.

I requisiti relativi alle prestazioni coinvolgono attributi quantificabili del sistema, come ad esempio:

• Il tempo di risposta, ossia quanto velocemente il sistema reagisce all'input dell'utente;
• L'accuratezza dell'output, cioè il livello di precisione ed esattezza (sul piano quantitativo o qualitativo) prodotto dal sistema o da una componente;
• La capacità di produzione, ossia quanto lavoro il sistema può svolgere nell'unità di tempo.

Documentazione e analisi dei requisiti

Struttura del documento di analisi dei requisiti (RAD)

Descrivi la struttura del documento di analisi dei requisiti (RAD) dell'elicitazione.

I risultati dell'elicitazione dei requisiti e delle attività di analisi sono documentati nel Documento di Analisi dei Requisiti (RAD). Il RAD descrive completamente il sistema in termini di requisiti funzionali e non-funzionali. Tale documento si struttura in 4 parti che sono:

• La prima sezione del RAD, l'“introduzione”, si propone di fornire una breve panoramica sulle funzionalità del sistema, le ragioni per il suo sviluppo, la sua area di competenza e gli obiettivi da raggiungere.
• La seconda sezione, l'“Analisi dell’esistente”, se il sistema in via di realizzazione sostituirà un sistema esistente, questa sezione descrive le funzionalità e i problemi del vecchio sistema, altrimenti la sezione descrive come vengono realizzati ora i compiti che il nuovo sistema supporterà.
• La terza sezione, l'“analisi del proposto”, documenta i requisiti elicitati e il modello del nuovo sistema.
• La quarta sezione, il “glossario”, è utilizzato per costituire una chiara terminologia condivisa tra gli utenti e gli sviluppatori, questi ultimi identificano ogni oggetto partecipante nei vari casi d’uso e gli attribuiscono un nome e una descrizione non ambigua.

Tipologie di oggetti nell'analisi dei requisiti

Oggetti control

Nel contesto dell'analisi dei requisiti, che cosa sono gli oggetti control? Fornisci una definizione ed un esempio.

Il modello degli oggetti control consiste in tre tipi di oggetti di cui fanno parte gli oggetti Control, ossia l'implementazione dei vari casi d'uso. Ad esempio, nel caso di un orologio con gestione a due bottoni, l'oggetto Control è la funzione CambiaData che rappresenta l'attività di cambiare la data premendo una combinazione di bottoni.

Definizione di specializzazione

Nel contesto dell'analisi dei requisiti, che cosa intendiamo per specializzazione? Fornisci un esempio.

La specializzazione è l'attività che identifica concetti più specifici a partire da un concetto di alto livello. Ad esempio, supponiamo di discutere con il committente le funzionalità di un sistema di gestione delle emergenze. Il committente, per prima cosa descrive il concetto di Incidente, quindi spiega che ci sono tre tipi di incidente:

• I disastri, che richiedono la collaborazione di diverse agenzie;
• Le emergenze, che richiedono intervento immediato da parte di una singola agenzia;
• Gli incidenti a bassa priorità, che possono non essere gestiti immediatamente se le risorse sono impegnate in eventi più gravi.

Oggetti boundary

Nel contesto dell'analisi dei requisiti, che cosa sono gli oggetti boundary? Fornisci una definizione ed un esempio.

Il modello degli oggetti boundary consiste in tre tipi di oggetti di cui fanno parte gli oggetti Boundary, ossia le interazioni tra gli attori e il sistema. Ad esempio, nel caso di un orologio con gestione a due bottoni, gli oggetti Boundary sono i bottoni con il display, i cui creano un'interfaccia tra il sistema e l’utente.

Oggetti entity

Nel contesto dell'analisi dei requisiti, che cosa sono gli oggetti entity? Fornisci una definizione ed un esempio.

Il modello degli oggetti entity consiste in tre tipi di oggetti di cui fanno parte gli oggetti Entity che rappresentano le informazioni persistenti che il sistema mantiene. Ad esempio, nel caso di un orologio con gestione a due bottoni, gli oggetti Entity sono il mese, il giorno e l’anno.

Definizione di generalizzazione

Nel contesto dell'analisi dei requisiti, che cosa intendiamo per generalizzazione? Fornisci un esempio.

La generalizzazione è l'attività di modellizzazione che identifica concetti astratti partendo da concetti di più basso livello. Ad esempio, in un sistema di gestione delle emergenze dovremo gestire sia incidenti del traffico che incendi. Questi due eventi hanno alcune caratteristiche in comune, che possiamo astrarre: creeremo quindi un concetto astratto di “Emergenza” che descrive gli attributi e le operazioni in comune sia agli incidenti del traffico che agli incendi.

Architetture a strati

Architetture a strati chiuse

Descrivi le architetture a strati chiuse. Fornisci un esempio.

Una decomposizione gerarchica di un Sistema, produce un insieme ordinato di strati (layers). Un layer è un raggruppamento di sotto-sistemi che offrono servizi correlati, spesso realizzati usando i servizi di più basso livello offerti dallo strato sottostante. In un’architettura chiusa, ogni strato può accedere solo allo strato immediatamente sottostante. Un esempio noto di architettura chiusa è costituito dal modello di riferimento ISO-OSI, che descrive i servizi di connessione via rete, ed è strutturato in 7 strati. Ogni strato sfrutta i servizi resi disponibili dallo strato immediatamente sottostante.

Valutazione del coupling

La riduzione del coupling in sede di progettazione dei sotto-sistemi è sempre un valore da perseguire in assoluto? In quali casi le controindicazioni prevalgono?

Ridurre a tutti i costi il coupling non è sempre consigliato. Per ridurre il coupling, gli sviluppatori sono portati ad introdurre vari livelli di astrazione, che tendono ad aumentare la complessità generale del sistema, consumano tempo di sviluppo e tempo di esecuzione. Un elevato livello di coupling è un problema solo quando la probabilità che un sotto-sistema cambi è elevata: in questi casi il costo dell'introduzione di un livello di de-coupling (disaccoppiamento) può essere effettivamente inferiore a quello causato dalla propagazione delle modifiche a numerosi sotto-sistemi.

Svantaggi delle architetture a strati

Quali sono gli svantaggi di un'architettura a strati?

Una decomposizione gerarchica di un Sistema, produce un insieme ordinato di strati (layers). Un layer è un raggruppamento di sotto-sistemi che offrono servizi correlati, spesso realizzati usando i servizi di più basso livello offerti dallo strato sottostante. Gli svantaggi di tale tipo di architettura sono che ogni livello introduce un sovraccarico nella memoria occupata e nei tempi di risposta, il che può rendere difficile soddisfare i corrispondenti requisiti non-funzionali. Inoltre, aggiungere in un secondo momento funzionalità inizialmente non previste, può risultare problematico.

Vantaggi delle architetture a strati

Quali sono i vantaggi di un'architettura a strati?

Una decomposizione gerarchica di un Sistema, produce un insieme ordinato di strati (layers). Un layer è un raggruppamento di sotto-sistemi che offrono servizi correlati, spesso realizzati usando i servizi di più basso livello offerti dallo strato sottostante. Utilizzare questo tipo di architettura ti da il vantaggio di avere un basso livello di coupling tra i sotto-sistemi, e che questi ultimi possono essere integrati e testati in modo incrementale.

Architetture a strati aperte

Descrivi le architetture a strati aperte. Fornisci un esempio.

Una decomposizione gerarchica di un Sistema, produce un insieme ordinato di strati (layers). Un layer è un raggruppamento di sotto-sistemi che offrono servizi correlati, spesso realizzati usando i servizi di più basso livello offerti dallo strato sottostante. In un’architettura aperta, uno strato può accedere a tutti gli strati sottostanti. Un esempio di architettura aperta è costituito dal toolkit per interfacce utente Java Swing. Il livello più basso è rappresentato dal sistema operativo, e offre servizi di base per la gestione di interfacce a finestra. Lo strato immediatamente superiore, AWT, è un’interfaccia astratta che Java offre per schermare le applicazioni da specifiche piattaforme a finestra. Swing è una libreria di oggetti che permette di realizzare numerose componenti utente. Un’applicazione Swing, in genere, accede solo all’interfaccia dell’AWT. Tuttavia il top layer può aggirare lo strato Swing ed accedere direttamente all’AWT per poter ottimizzare alcuni aspetti legati alle prestazioni.

Definizione di coupling

Che cosa si intende, in Ingegneria del Software, con il termine coupling?

Il coupling è la misura quantitativa delle dipendenze tra due sotto-sistemi. Se due sotto-sistemi sono accoppiati in modo lasco (basso livello di coupling) essi sono relativamente indipendenti, e le modifiche apportate ad uno dei due sotto-sistemi avranno poco impatto sull'altro. Viceversa, se due sotto-sistemi sono strettamente accoppiati (elevato livello di coupling), le modifiche apportate a uno di essi avranno probabilmente un impatto significativo anche sull'altro. Una proprietà desiderabile della decomposizione in sotto-sistemi è che questi risultino ragionevolmente disaccoppiati: in tal modo l’impatto di errori e future modifiche sarà localizzato in un solo sotto-sistema.

Definizione di coesione

Fornisci una definizione del concetto di coesione relativamente a un sotto-sistema software.

La coesione è la misura quantitativa delle dipendenze internamente a un sotto-sistema. Se un sotto-sistema contiene molti oggetti che sono collegati l'uno all'altro ed eseguono compiti simili, il suo livello di coesione è alto. Se un sotto-sistema contiene numerosi oggetti non reciprocamente correlati, il suo livello di coesione è basso. Una proprietà desiderabile della decomposizione in sotto-sistemi è che essa produca sotto-sistemi con alto livello di coesione.