Laboratorio di Ingegneria del Software. Discussione risultati attività svolte. Introduzione agli Use Case

Dimensione: px

Iniziare la visualizzazioe della pagina:

Download "Laboratorio di Ingegneria del Software. Discussione risultati attività svolte. Introduzione agli Use Case"

Federico Morelli
6 anni fa
Visualizzazioni

1 Laboratorio di Ingegneria del Software Discussione risultati attività svolte Introduzione agli Use Case Giuseppe Lami I.S.T.I. C.N.R. - Programma della sessione di laboratorio 15 Dicembre 2004 Revisione e discussione sui risultati delle attività svolte nelle sessioni precedenti Produzione di Use Case Presentazione degli Use Case Lavori di gruppo Revisione Conclusioni 1

2 Discussione sulle Attività svolte 1. Scrittura di un documento di requisiti 2. Analisi di requisiti per mezzo di un tool automatico Analisi di requisiti Documento composto da 346 requisiti di sistema Vero documento di lavoro industriale Informazioni dettagliate sul contesto e il dominio applicativo del sistema descritto non disponibili Consegnate n. 4 nuove versioni del documento dopo la revisione 2

3 Analisi di requisiti Optionality Analysis Requisiti evidenziati come PD (potenzialmente difettosi): ATIA1961: The system shall identify and produce, if appropriate, all training products, materials, and/or information necessary to train one or more critical collective or individual task(s). ATIA2033: The system shall provide security measures to ensure only authorized user access to restricted and/or sensitive information. ATIA1961 Falso positivo: 3 Difettoso: 1 correzione: duplicazione req. and + or ATIA2033 Falso positivo: 1 Difettoso: 3 correzione: and/or -> and (1); and/or -> or(1); duplicazione req. and + or Analisi di requisiti Optionality analysis (continued) Dizionario modificato 1 caso: aggiunta del termine: one or more n. 47 di occorrenze nel documento Esempio: ATIA : The system shall associate a collective task with one or more element-mission combination. (?) Subjectivity analysis: Nessun difetto segnalato 3

4 Analisi di requisiti Vagueness Analysis: Numero Requisiti PD = 6 ATIA590: The system shall provide for display of a brief textual help message when the pointer is over an object. Falso positivo: 0 Difettoso: 4 correzione: eliminazione termine vago (3), sostituzione con five rows (1) ATIA1961: The system shall identify and produce, if appropriate, all training products, materials, and/or information necessary to train one or more critical collective or individual task(s). Falso positivo: 4 Difettoso: 0 (vedi optionality) ATIA2276: The system shall provide appropriate data integrity and access controls. Falso positivo: 2 Difettoso: 2 correzione: eliminazione termine vago (2) ATIA484: The system shall provide the capability to provide appropriate access to users of education/training documents and materials. Falso positivo: 1 Difettoso: 3 correzione: eliminazione termine vago (3) Analisi di requisiti Vagueness Analysis (continued) ATIA1256: The system shall provide appropriate data and access security. Falso positivo: 1 Difettoso: 3 correzione: eliminazione termine vago (1), sost. con correct (1), sost.: data of the current day -> appropriate data (1) ATIA1311: The system shall provide flexible object level security for database objects. Falso positivo: 2 Difettoso: 2 correzione: eliminazione termine vago (2) 4

5 Analisi di requisiti Weakness analysis: Nessun difetto segnalato Implicity analysis: Numero requisiti PD = 27 Numero FP = 27 Esempio: ATIA2564: The system shall provide the capability to maintain Army Universal Task List (AUTL) information. This requirement has not been AOGapproved. Analisi di requisiti Underspecification analysis Numero requisiti PD = 37 Interpretazione risultati: Falsi positivi 37/37 (2), falsi positivi 34/37 (1), NA (1) ATIA : The system shall associate a collective task with one or more unit types. ATIA2623: The system shall associate document with one or more category items. This requirement has not been AOG approved. ATIA395: The system shall provide capability to process registration and enrollment requests directly from individuals, units, or from the reservation process. Nota: il termine requirement non è stato considerato US 5

6 Analisi di requisiti Security View Nessuna evidenza di analisi di consistenza/completezza ATIA1302: The system shall provide access to individual and collective training data. ATIA484: The system shall provide the capability to provide access to users of education/training documents and materials. ATIA2481: The system shall provide users tailored access to a list of training material based on their profile. ATIA1302 e ATIA484 ridondanti (?) ATIA2481 in conflitto con ATIA1302 e ATIA484 (?) Scrittura di un documento di requisiti Consegnati n. 5 documenti SMA Requirements Lingua usata: Italiano (4), Inglese (1) 6

7 Scrittura di un documento di requisiti Requisiti funzionali?: Gli strumenti di rilevazione dei CdR agiscono direttamente sul territorio Il CdR è considerato guasto quando non risponde alle richieste oppure invia valori fuori scala Quando il CCL rileva un malfunzionamento di uno o più CdR non considera attendibili i dati da esso rilevati Quando il CdR non risponde alle richieste oppure invia valori fuori scala viene visualizzato un messaggio di CdR guasto sull interfaccia della CCL I dati letti da un CdR guasto non vengono memorizzati dalla CCL Scrittura di un documento di requisiti Incompletezze: Il collegamento fra CCL e CCP può rimanere inattivo per la massimo 72 ore Nel SMA può essere aggiunto (rimosso)un nuovo CdR Nel SMA può essere aggiunto (rimosso) un nuovo CCL Cosa fa il sistema quando un nuovo CdR (o CCL) viene aggiunto? Cosa fa il sistema quando il collegamento fra CCL e CCP rimane inattivo per più di 72 ore? 7

8 Scrittura di un documento di requisiti Vaghezza: function CdR2: il CdR deve misurare continuamente i parametri ambientali CdR must recover data from the environment every 30 sec. I dati storici devono essere preservati e trasmessi non appena possibile Scrittura di un documento di requisiti Testabilità: In caso di guasto ad una o più CdR il sistema dovrà rilevarne il malfunzionamento isolando il guasto cambiando la configurazione del sistema e informando il personale di servizio per permetterne il ripristino. Il sistema è tollerante a tale anomalia, e ciò permetterà un corretto funzionamento pur facendo a meno della parte guasta. In altre parole tale guasto causerà una perdita di informazioni ambientali ma non il blocco del sistema SMA. Il collegamento tra CCP e CCL non potrà interrompersi per più di 72 ore grazie alle attività di controllo del collegamento sia da parte delle CCL che CCP. 8

9 Scrittura di un documento di requisiti Molteplicità: Ogni CdR si comporta in modo passivo rispondendo alle interrogazioni periodiche del proprio CCL, inviando le misurazioni rilevate. (Ogni CdR afferisce ad un unico CCL). Ogni CdR afferisce ad un unico CCL Ogni CdR invia le misurazioni rilevate quando interrogato dalla CCL di afferenza. Scrittura di un documento di requisiti Ridondanza:. SMA must be composed by at least a number of Survey Units CdR as the number of CCL. CCP must be connected to all the CCL in the County. CCP must not be connected to anyone CdR. CCP must receive daily information from the CCL. CCL must be connected to at least one CdR. CdR must be connected at only one CCL.. 9

10 Scrittura di un documento di requisiti Incompletezza (II): 3.2) CCL functional specification.? CCL must recover data from all the CdR every 5 minutes.? CCL must set the security limits for every parameters recovered by every CdR.? CCL must verify if the data recovered is under the established security limits.? CCL must send to CCP the alarms relative to the surpassing of the security limits by the environment data.? CCL must send to CCP the environment data of is daily archive every 24h 3.2.1) CCL must recover data from all the CdR every 5 minutes ) CCL must set the security limits for every parameters recovered by every CdR ) CCL must verify if the data recovered is under the established limits.. 3.3).. Scrittura di un documento di requisiti Livelli: Elenco specifiche funzionali Centri di Controllo Locale CCL FL1 Lettura valori ambientali raccolti dalle centraline connesse FL2 Analisi valori ambientali entro limiti di soglia FL3 Memorizzazione valori limite per ogni centralina FL4 Modifica valori limite Descrizione FL1 Acquisizione parametri ambientali dalle centraline CdR connesse alla centrale locale FL2 Analisi valori rilevati dalle centraline e determinazione livello di guardia FL3 Memorizzazione valori limite per ogni centralina connessa al CCL FL4 Modifica valori limite per ogni centralina connessa alla CCL Non si aggiungono dettagli al livello più basso 10

11 USE CASES Use Cases Un requisito funzionale cattura il comportamento previsto di un sistema. Questo comportamento può essere espresso come servizio, compito o funzione che il sistema deve fornire La definizione di Use Case si deve a Alistair Cockburn: Cockburn A. Structuring Use Case with Goals Journal of Object - Oriented Programming, Sep.-Oct also available on Cockburn A. Basic Use Case Template available on 11

12 Use Cases: Modello semplificato Nome Scopo Precondizioni Attore Primario, e attori secondari il nome è lo scopo espresso con una breve frase con verbo attivo una definizione più lunga dello scopo nel contesto quale ci si aspetta che sia lo stato del mondo inizialmente - una denominzione del ruolo o la descrizione dell attore primario - altri sistemi ai quali ci si affida per completare lo Use Case Iniziatore (Trigger) Scenario Principale di successo l azione del sistema che innesca lo Use Case Step Azione 1 <i passi dello scenario dal trigger al raggiungimento dello scopo 2 <...> 3 Estensioni Step Azione 1a deviazioni / eccezioni Use Case per SMA Invio dati giornalieri da CCL a CCP Eliminazione di una CdR Visualizzazione del superamento della soglia di emergenza Rilevamento di un guasto ad una CdR 12

Documenti analoghi

A.A. 2006/2007 Laurea di Ingegneria Informatica. Fondamenti di C++ Horstmann Capitolo 3: Oggetti Revisione Prof. M. Angelaccio

A.A. 2006/2007 Laurea di Ingegneria Informatica Fondamenti di C++ Horstmann Capitolo 3: Oggetti Revisione Prof. M. Angelaccio Obbiettivi Acquisire familiarità con la nozione di oggetto Apprendere le proprietà