6. Glossario, Definizione e Specifica Glossario dei termini Tecniche per definire e specificare i requisiti di un sistema software Un metodo basato su “forms” per stilare la definizione dei requisiti Metodi per scrivere specifiche precise L’importanza dei requisiti non funzionali, e come questi possono essere specificati 1 Dizionario dei dati Un dizionario dei dati è una lista dei nomi di tutti gli oggetti prodotti o consumati dal software con relativa descrizione E’ qui che vengono raccolte tutte le informazioni utili al sistema E’ un ponte tra l’analisi e l’implementazione Serve come riferimento comune nel lavoro d’equipe (risoluzione di ambiguità) 2 Voci del dizionario Tutti i nomi usati nel modello del sistema, nella progettazione e nell’implementazione devono essere presenti come voci nel dizionario dei dati Usare software di supporto per creare, mantenere e interrogare il dizionario Il dizionario può essere integrato con strumenti CASE per automatizzarne parzialmente la costruzione 3 Voci del dizionario Name Description 1:N relation between entities of type has_labels Node or Link and entities of type Label. Holds structured or unstructured Label information about nodes or links. Labels can be text or can be an icon. Represents a relation between design Link entities represented as nodes. Links are typed and may be named. Each label has a name which name (label) identifies the type of label. The name must be unique within the set of label types used in a design. Each node has a name which must be name (node) unique within a design. The name maybe up to 64 characters long. Type Date Relation 5.10.93 Entity 8.12.93 Relation 8.12.93 Attribute 8.12.93 Attribute 15.11.93 4 Definizione dei Requisiti Descrizione delle funzionalità del sistema e dei vincoli operazionali, orientata al cliente Deve specificare il comportamento esterno del sistema: i requisiti non devono essere definiti usando un modello computazionale Include requisiti funzionali e non funzionali Requisiti funzionali: dichiarazione di servizi che il sistema deve offrire Requisiti non funzionali = vincoli sui servizi e sulle operazioni che il sistema deve realizzare 5 Scrivere una definizione di requisito Il modo normale di scrivere le definizione dei requisiti è usando il linguaggio naturale arricchito da diagrammi e tabelle Problemi: Mancanza di chiarezza. La precisione è direttamente proporzionale alla difficoltà di leggere il documento. Confusione tra requisiti. Requisiti funzionali e nonfunzionali tendono ad essere mescolati Amalgama di requisiti. Diversi requisiti espressi tutti in una volta anziché in modo distinto 6 Esempio 4.A.5 Il database deve supportare la creazione e il controllo di oggetti di configurazione, ovvero di oggetti che sono a loro volta raggruppamenti di altri oggetti nel database. Le facilities di controllo di configurazione devono consentire di accedere a un raggruppamento di oggetti usando un nome incompleto. E’ un caso di amalgama: si mettono assieme concetti (prima frase) e dettagli (seconda frase) 7 Esempio 2.6 Griglia Per aiutarsi nel posizionamento di entità in un diagramma, l’utente può attivare una griglia, in centimetri o pollici, attraverso una opzione del pannello di controllo. La griglia può essere attivata o disattivata in qualsiasi momento del processo di editing e può essere impostata in centimetri o pollici in qualsiasi momento. Nella riduzione delle dimensioni del documento nella finestra (reduce-to-fit) il numero di linee della griglia deve essere ridotto per evitare di riempire il diagramma solo con linee fitte della griglia. Confusione di requisiti funzionali e non funzionali La definizione è incompleta 8 Esempio 2.6 Griglia Per aiutarsi nel posizionamento di entità in un diagramma, l’utente può attivare una griglia, in centimetri o pollici, attraverso una opzione del pannello di controllo. La griglia può essere attivata o disattivata in qualsiasi momento del processo di editing e può essere impostata in centimetri o pollici in qualsiasi momento. Nella riduzione delle dimensioni del documento nella finestra (reduce-to-fit) il numero di linee della griglia deve essere ridotto per evitare di riempire il diagramma solo con linee fitte della griglia. Confusione di requisiti funzionali e non funzionali La definizione è incompleta 9 Regole di stesura Aderire ad un formato standard: permette di evitare omissioni e semplifica i controlli incrociati Raggruppare i requisiti che sono legati fra loro Evidenziare i requisiti principali Associare motivazioni ai requisiti 10 Definizione di una grigia di un editor 2.6 Griglia 2.6.1 L’editor deve offrire una griglia di linee orizzontali e verticali come sfondo della finestra di editing. Questa griglia deve essere una griglia passiva. E’ lasciata all’utente la responsabilità di allineare o meno le entità. Motivazione: Una griglia aiuta l’utente a creare diagrammi ordinati con entità ben posizionate. A differenza di una griglia attiva, dove le entità sono “catturate” dalle linee della griglia, il posizionamento è impreciso. E’ l’utente che deve decidere dove posizionare le entità. . 2.6.2 Quando la griglia viene usata in modalità ‘reduce-to-fit’ (see 2.1), il numero di punti che separano le linee della griglia deve essere incrementato. Motivazione: Se non si incrementa la spaziatura tra linee, lo sfondo diventerebbe offuscato dalle linee della griglia. 11 Motivazione del requisito La motivazione di un requisito è importante per aiutare lo sviluppatore a capire il dominio di applicazione e a capire perché il requisito è descritto in quella forma E’ particolarmente importante quando si debbano modificare i requisiti: la presenza della motivazione di un requisito riduce la probabilità che il cambiamento produca effetti inaspettati. 12 Creazione di un nuovo nodo 3.5.1 Adding nodes to a design 3.5.1.1 The editor shall provide a facility where users can add nodes of a specified type to a design. Nodes are selected (see 3.4) when they are added to the design. 3.5.1.2 The sequence of actions to add a node should be as follows: 1. The user should select the type of node to be added. 2. The user moves the cursor to the approximate node position in the diagram and indicates that the node symbol should be added at that point. 3. The symbol may then be dragged to its final position. Rationale: The user is the best person to decide where to position a node on the diagram. This approach gives the user direct control over node type selection and positioning. Specification: ECLIPSE/WS/Tools/DE/FS. Section 3.5.1 13 Specifica dei Requisiti Descrizione precisa e dettagliata delle funzionalità del sistema. Serve come base da una parte per il contratto, e dall’altra per la progettazione e lo sviluppo. Deve essere consistente con la definizione. Di solito viene presentata con il modello di sistema sviluppato nell’analisi dei requisiti Spesso scritta in linguaggio naturale, anche se questo può essere problematico 14 Problemi col linguaggio naturale Si assume che chi scrive e chi legge usino la stessa parola per lo stesso concetto Problemi di troppa flessibilità e di diverse interpretazioni Le strutture linguistiche del linguaggio naturale possono non essere sufficienti a partizionare i requisiti. 15 Alternative al linguaggio naturale Linguaggio naturale strutturato Linguaggi di Descrizione di Programmi (PDL) Notazioni grafiche (SADT) Specifiche formali: Reti di Petri Sistema Z Sistema B Logiche temporali Asserzioni di specifica 16 Tracciabilità dei requisiti Tracciabilità = requisiti correlati sono in qualche modo raggiungibili l’uno dall’altro. Assegna ad ogni requisito un numero (unico) Inserisci riferimenti incrociati a requisiti che sono correlati Scrivi una matrice di riferimenti incrociati che evidenzia la correlazione tra requisiti. Occorreranno diverse matrici per i diversi tipi di relazione 17 Specifiche basate su “forms” Forma limitata di linguaggio naturale: impone un grado di uniformità alla specifica. Metodo: Descrizione della funzione o entità da specificare Descrizione degli input e da dove provengono Descrizione degli output e dove vanno a finire Indicazioni di altre entità richieste Pre e post condizioni Effetti collaterali (se ce ne sono) 18 Specifica basata su “forms” di un nodo ECLIPSE/Workstation/Tools/DE/FS/3.5.1 Function Add node Description Addsa node to an existing design. The user selects the type of node, and its position. When added to the design, the node becomesthe current selection. The user chooses the node position by moving the cursor to the area where the node is added. Inputs Node type, Node position, Design identifier. Source Node type and Node position are input by the user, Design identifier from the database. Outputs Design identifier. Destination operation. The design database. The design is committed to the database on completion of the Requires Design graph rooted at input design identifier. Pre-condition The design is open and displayed on the user's screen. Post-condition at the given position. The design is unchanged apart from the addition of a node of the specified type Side-effects None Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1 19 Definizione dei requisiti con PDL I requisiti possono essere definiti in modo operazionale usando un linguaggio simile ad un linguaggio di programmazione ma più espressivo Metodo appropriato in due casi Quando un’operazione è specificata come sequenza di azioni e l’ordine è importante Quando si devono specificare interfacce hardware e software Svantaggi Il PDL può non essere abbastanza espressivo da definire i concetti del dominio in modo adeguato Si può generare confusione tra specifica e progettazione 20 Descrizione in PDL di un ATM procedure ATM is PIN: Pin_no ; Acc_no: Account_number ; Balance: Amount ; Service: Available_services ; Valid_card, Valid_PIN: Boolean ; begin loop Get_card ( Acc_no, PIN, Valid_card) ; if Valid_card then Validate_PIN (PIN, Valid_PIN) ; if Valid_PIN then Get_account (Acc_no, Balance) ; Get_service (Service) ; while a service is selected loop Deliver_selected_service ; Get_service (Service) ; end loop ; Return_card ; end if ; end if ; end loop ; end ATM ; 21 Specifica di interfacce in PDL Tutti i sistemi software operano in un ambiente con altri sistemi. Possono interfacciarsi a questi sistemi in vari modi Le interfacce che una specifica di requisiti può trovarsi a dover definire sono di tre tipi Interfacce procedurali: i sottosistemi offrono un certo insieme di servizi Interfacce di rappresentazione dei dati. Scambio di strutture-dati Interfacce di rappresentazione concreta. Rappresentazioni (dei dati) fissate da sottosistemi esistenti 22 Esempio: interfaccia procedurale package Print_server is procedure Initialise (P: PRINTER) ; procedure Print (P: PRINTER ; F: PRINT_FILE ) ; procedure Display_print_queue (P: PRINTER ) ; procedure Cancel_print_job (P: PRINTER; N: PRINT_ID) ; procedure Switch_printer (P1, P2: PRINTER; N: PRINT_ID) ; end Print_server ; (Linguaggio Ada) 23 Esempio: interfaccia di dati type MESSAGE is record Sender : SYSTEM_ID; Receiver : SYSTEM_ID; Dispatch_time : DATE; Length: MESSAGE_LENGTH ; Terminator: CHARACTER ; Message : TEXT; end record; type SYSTEM_ID is range 20_000..30_000 ; type YEAR_TYPE is range 1980..2080 ; type DATE is record Seconds: NATURAL ; Year: YEAR_TYPE ; end record ; type MESSAGE_LENGTH is range 0..10_000 ; type TEXT is array (MESSAGE_LENGTH) of CHARACTER ; 24 Esempio: interfaccia di rappresentazione Rappresentazione di size for SYSTEM_ID’SIZE use 2*BYTE ; for YEAR_TYPE’SIZE use 2*BYTE ; for MESSAGE_LENGTH’SIZE use 2*BYTE ; Rappresentazione di stato condiviso type STATE is (Halted, Waiting, Ready, Running); for STATE use (Halted => 1, Waiting => 4, Ready => 16, Running => 256); 25 Requisiti non funzionali Proprietà di comportamento del sistema: affidabilità, tempi di risposta e di memorizzazione, vicoli sull’I/O, ecc. Possono essere più critici dei requisiti funzionali, perché possono rendere inutile il sistema se non sono soddisfatti Tipologia dei requisiti non funzionali requisiti di prodotto requisiti di processo requisit esterni 26 Classificazione dei requisiti non funzionali Requisiti di prodotto Specificano che il prodotto deve comportarsi in un certo modo, es. velocità di esecuzione, affidabilità, ecc. Requisiti di processo Requisiti che sono conseguenza di scelte di tipo organizzativo, ad es. standard di processo utilizzato, requisiti sull’implementazione ecc. Requisiti esterni Requisiti che derivano da fattori esterni al sistema e al suo processo di sviluppo, ad es. requisiti legislativi, etici ecc. 27 Requisiti non funzionali Requisiti di Prodotto Requisiti di usabilità Requisiti di efficienza Performance Requisiti di spazio Requisiti di affidabilità Requisiti di portabilità Requisiti Esterni Requisiti di interoperabilità Requisiti etici Requisiti legali Privacy Sicurezza Requisiti di Processo Requisiti sulle deliveries Requisiti sull’implementazione Requisiti sugli standards 28 Esempio Requisiti di prodotto 4.C.8 It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard Ada character set. Requisiti di processo 9.3.2 The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95. Requisiti esterni 7.6.5 The system shall provide facilities that allow any user to check if personal data is maintained on the system. A procedure must be defined and supported in the software that will allow users to inspect personal data and to correct any errors in that data. 29 Verificabilità dei requisiti I requisiti devono essere scritti in modo da poter essere facilmente verificati Evitare termini vaghi: non ha senso scrivere Il sistema deve essere facile da usare per un operatore specializzato e dev’essere organizzato in modo da minimizzare gli errori Ma bisogna “quantificare”: Un operatore specializzato deve essere in grado di utilizzare il sietma dopo due ore di training. Dopo tale training, il numero medio di errori fatti da un operatore specializzato deve essere inferiore a due per giorno lavorativo 30 Misure per i requisiti Property Speed Size Ease of use Reliability Robustness Portability Measure Processed transactions/second User/Event response time Screen refresh time K Bytes Number of RAM chips Training time Number of help frames Mean time to failure Probability of unavailability Rate of failure occurrence Availability Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Percentage of target dependent statements Number of target systems 31 Requisiti a livello di sistema Alcuni requisiti pongono dei vincoli al sistema nella sua interezza, non a funzioni specifiche Esempio Il tempo richiesto per la formazione degli operatori del sistema non dovrà eccedere i 2 giorni lavorativi Ci possono essere dei requisiti che non possono essere derivati da nessun singolo sottoinsieme di requisiti del sistema 32