Ingegneria del Software. Simulazione Prova parziale del 24/4/2015

Transcript

1 Cognome Nome Matricola Ingegneria del Software Simulazione Prova parziale del 24/4/2015 Durata: 1h 30' Esercizio 1. Descrivere il seguente diagramma UML di attività, rappresentante la procedura di analisi di messaggi inviate a una nuova applicazione della CTM per monitorare eventuali lamentele sui disservizi che altrimenti andrebbero ignorate: Note: il sistema è in grado di categorizzare automaticamente i messaggi inviati dagli utenti tramite un algoritmo di sentiment analysis.

2 Descrizione: Il sistema analizza il messaggio inviato dall'utente e effettua una prima categorizzazione, etichettandolo come messaggio offensivo, come lamentela o come altra categoria. Nel caso non si né un messaggio offensivo né una lamentela, il messaggio viene categorizzato diversamente e archiviato, e l'attività finisce. Se si tratta di un messaggio offensivo, viene segnalato ad un amministratore del sistema, determinando anche in questo caso la cessazione dell'attività. Diversamente, nel caso si tratti di una lamentela, l'elaborazione risulta più complessa. Infatti, vengono avviati in parallelo due flussi d'elaborazione. Uno si occupa di verificare se si tratta o no di una lamentela isolata. Se si tratta di una lamentela isolata, il flusso relativo a questa elaborazione termina (Flow Final Node), ma, se è ancora attivo il flusso ad esso parallelo, l'attività non termina. Se ci sono lamentele simili, invece, viene segnalato il problema alla direzione CTM, e l'attività termina. In corrispondenza dell'altro flusso generato dal fork viene invece richiesta una serie di informazioni più dettagliate all'utente tramite un form standard. Se il problema è trascurabile, termina il flusso, ma non l'attività. L'attività termina solo se terminano tutti i flussi, ossia se tutti i token vengono eliminati. Sempre al nodo di decisione per il form compilato dall'utente, se il problema è grave, viene segnalato alla direzione della CTM e l'attività termina. Pertanto, la direzione può venire avvertita della lamentela sia nel caso che ce ne siano molte simili, sia nel caso che si tratti di un problema grave. Notare che si potrebbe osservare che l'attività termina anche se tutti i token vengono consumati, pur non avendo alcun flusso che termina in un Activity Final Node. Tuttavia, è preferibile realizzare diagrammi di attività senza questo tipo di comportamento possibile, essendo la semantica poco chiara in questo scenario.

3 Esercizio 2 La Blizzard, azienda che realizza videogiochi, affida al vostro team di sviluppo un modulo di Starcraft 2, un RTS (Real Time Strategy) ambientato in uno scenario futuristico fantascientifico. Nel modulo affidatovi vi sono alcune costruzioni per la razza Terran. Fra queste si trova anche il Bunker, al cui interno il giocatore può sistemare fino a 4 Marine al fine di proteggerli maggiormente dagli attacchi nemici. Il Bunker risulta presente solo nel momento in cui il giocatore decide di farlo costruire da un'unità Lavoratore e lo ha già posizionato. Il giocatore può interrompere la costruzione del Bunker in qualsiasi momento; se lo fa, il lavoratore si sposta da una parte e, successivamente, può essere rimandato a continuare la costruzione. Per costruire il Bunker è necessario un certo periodo di tempo. In nessun caso potrà ospitare Marine se non è stato ancora completato ma, una volta pronto, può ospitare fino a 4 Marine. In seguito a un attacco, occorre aggiornare la resistenza del Bunker per tenere conto del danno subito. In qualsiasi momento della partita, se il Bunker subisce danni superiori alla sua resistenza corrente a causa di un attacco, viene distrutto a seguito di una esplosione. Disegnare il diagramma di stato del bunker. Suggerimento: prestare bene attenzione a quali sono gli attributi più rilevanti in ogni stato, in particolare a quelli che possono essere legati ai controlli per i passaggi di stato. Soluzione possibile:

4 Quiz (30min) 1. Quale di queste affermazioni sulle User Stories sono vere (anche più di una)): Affermazione Vera Falsa Sono scritte dal cliente o dal Product Owner, mentre lo þ sviluppatore le stima e ne definisce la priorità Danno una descrizione nel complesso esaustiva del requisito þ a cui sono associate I test di accettazione associati alle US sono scritti dal cliente þ o dal Product Owner Le US possono descrivere bene i requisiti funzionali, ma possono anche includere requisiti non funzionali e vincoli þ 2. Il modello dinamico di UML a) mostra le istanze delle classi durante uno scenario di funzionamento del sistema b) comprende i diagrammi di dispiegamento c) comprende i diagrammi di stato d) è slegato dalle caratteristiche comportamentali del sistema 4. Quale delle seguenti affermazioni riguardo al diagramma dei componenti è errata? a) Solitamente, un nodo è un'unità modulare autonoma con un'interfaccia ben definita. (lo è sempre) b) I componenti di un diagramma dei componenti possono essere utilizzati nei diagrammi di dispiegamento per costruire diagrammi complessi. c) Un connettore può collegare l'interfaccia di un componente alla sua struttura interna. d) Un rettangolo, in combinazione con delle relazioni di dipendenza, può anche sostituire l'insieme pallino-presa, oltre che il semplice lollipop. 3. Mettere in corrispondenza i seguenti simboli col loro significato in UML: Simbolo UML Decision/ Flow Final Activity Final Fork/ Merge Join þ þ

5 þ þ 5. Quale di queste affermazioni sui diagrammi di stato UML sono vere (anche più di una)): Affermazione Vera Falsa Il diagramma di stato è un diagramma comportamentale þ perché descrive come un'entità si comporta al variare del tempo Le guardie sono condizioni che, se vere, permettono il þ passaggio di stato È obbligatorio indicare almeno un evento per ogni transizione þ È obbligatorio dare un nome a ogni stato þ 6. Descrivere i test di accettazione (TA). I test di accettazione sono associati alle User Stories. Sono scritti dal cliente o dal PO; per ogni storia può essere definito anche più di un test di accettazione. I test sono automatizzati dal team di sviluppo e devono essere ripetibili. Hanno la funzione di verificare che la funzionalità richiesta dal cliente sia stata implementata correttamente. Una storia si ritiene completata quando vengono superati con successo tutti i test di accettazione ad essa relativi.