Università degli Studi di Modena e Reggio Emilia Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica Tesina di Ingegneria del Software Gestione di una rosticceria di Fabio Zanella Matr. 1598
Capitolo 1...3 SRS: Specifiche del Problema...3 Capitolo 2...6 Activity Diagram...6 2.1 Commesso...6 2.2 Ordinazione...7 Capitolo 3...8 Use case diagram...8 3.1 Diagramma degli attori...8 3.2 Utente Generico...9 3.3 Direttore...9 3.4 Commesso...10 3.5 Ordinazione...11 3.6 Scorte...11 3.7 Diagramma delle interfacce...12 Capitolo 4...13 Class diagram...13 4.1 Package diagram...13 4.2 Varie...13 4.3 Persone...14 4.4 Prodotti...15 4.5 Ordinazioni...16 Capitolo 5...17 Sequence diagram...17 5.1 Registrazione Utente Generico...17 5.2 Accesso al sistema informativo...18 5.3 Gestione Cliente...19 5.4 Consulta Menù...20 Capitolo 6...21 State diagram...21 6.1 Ordinazione...21 Capitolo 7...23 Data Flow diagram...23 7.1 Ricerca...23 Capitolo 8 Bibliografia...24 2
Capitolo 1 SRS: Specifiche del Problema Per la raccolta delle specifiche del problema è stato adottato lo standard IEEE Std 830-1998. Tale standard si propone di fornire delle linee guida per la specifica dei requisiti del software che deve essere sviluppato. 1. Introduzione 1.1. Scopo. Si vuole progettare un sistema informativo di ausilio nella gestione di una rosticceria. 1.2. Campo di validità. Il sistema si deve occupare di mantenere un archivio degli utenti che possono accedervi (compresi i relativi privilegi), di gestire le ordinazioni dei pasti e la loro relativa consegna a domicilio. 1.3. Definizioni e abbreviazioni. Utenti del sistema informativo: sono tutti coloro che possono accedervi (naturalmente ve ne sono diverse categorie con diritti differenti). Clienti della rosticceria: sono tutte le persone che usufruiscono dei servizi della rosticceria. Utenti registrati: sono utenti che sono già stati precedentemente registrati nell archivio della rosticceria e che quindi sono possessori di un account che li identifica in modo univoco. L account è descritto da due abbreviazioni (UserId, Pwd) che verranno spesso utilizzate per indicare rispettivamente user identifier e password di un utente registrato (o comunque quelli che vengono utilizzati per la registrazione). Utenti generici: sono utenti che, non essendo mai stati registrati, non possono essere oggetto di controllo da parte della direzione della rosticceria, quindi è loro consentito un tipo di accesso molto ristretto che consente di ottenere soltanto informazioni sui prodotti venduti dalla rosticceria, ma non consente loro di effettuare ordinazioni. Prodotto: In questo documento, con questo termine si fa riferimento a qualsiasi articolo messo in vendita, quindi sia a prodotti alimentari come pastasciutta, pollo fritto e bevande. Commesso: Persona col compito di ricevere le ordinazioni dei clienti venuti al locale e dei clienti che telefonano. Dovrà, inoltre, essere in grado di fornire tutte le informazioni relative ai prodotti. 1.4. Referenze. Il software è completamente nuovo quindi non vi sono referenze degne di nota. 2. Descrizione generale. 2.1. Funzioni. Il software fornirà le seguenti funzioni: Archivio dei clienti. Tale archivio conterrà le informazioni necessarie per la consegna a domicilio dei pasti. Accesso al sistema informativo: si deve fare in modo che l accesso al sistema sia consentito a chiunque (registrato o meno), quindi il sistema deve essere di facile accesso, allo stesso tempo però si deve fare in modo che ciascun utente possa compiere solo le operazioni che gli sono consentite, quindi deve esserci anche un accesso sicuro al sistema. Nel momento in cui un utente necessiterà di maggiori informazioni e/o di dover compiere determinate operazioni non consentite a tutti, questi dovrà registrarsi. Archivio dei pasti e delle loro caratteristiche: questo tipo di archivio serve per soddisfare al meglio le richieste dei clienti. Di ogni pasto devono essere descritti gli ingredienti al fine di evitare un intolleranza alimentare da parte da parte del consumatore (glutine, latticini, uova, ). Ricerca su ogni tipo di informazione: deve essere data la possibilità di effettuare ricerche su tutti i prodotti e offerte disponibili, a partire da qualsiasi informazione disponibile per un qualsiasi prodotto. 3
Gestione delle ordinazioni: ogni ordinazione può essere richiesta da utenti locali o remoti (solo se registrati) tramite web o tramite telefono contattando il commesso della rosticceria. Gestione reclami sui prodotti venduti. Gestione delle scorte dei prodotti in vendita. 2.2. Utenti. Utente Generico: al fine di garantire l integrità e la protezione dei dati l accesso dell utente generico è particolarmente ristretto. È consentita soltanto la consultazione del menù. Nel caso in cui l utente voglia effettuare una ordinazione deve registrarsi e compilare il form relativo alla richiesta del pasto oppure rivolgersi al commesso personalmente o per telefono. Pubblico: una volta che l utente generico si registra ottenendo un account diviene un utente pubblico. Grazie alla registrazione l utente ottiene privilegi superiori rispetto a quelli di un utente generico, infatti oltre a poter fare tutto ciò che può fare l utente generico può in più eseguire ordinazioni. Commessi: vengono registrati come utenti del sistema informativo all atto dell assunzione. Questa registrazione consente loro di avere particolari privilegi nei confronti del sistema informativo e quindi di poter compiere tutte quelle operazioni che rientrano nelle loro mansioni quali l inserimento/cancellazione delle ordinazioni dei pasti, calcolo dei conti. Direttore: possiede tutti i privilegi dei dipendenti precedenti in più gode di privilegi supplementari quali quelli di poter aggiornare il listino prezzi, di gestire il personale (assunzioni, licenziamenti) e revocare gli account. 3. Requisiti del software. 3.1. Requisiti funzionali. 3.1.1. Requisito #1 3.1.1.1.Introduzione. Inserimento di un cliente nel database. 3.1.1.2. Input. Dati anagrafici del cliente: 3.1.1.2.1. Nome e cognome 3.1.1.2.2. Un account (UserId, Pwd) che li identifica in modo univoco 3.1.1.2.3. Domicilio (per le consegne) 3.1.1.2.4. Numero di telefono 3.1.1.2.5. Acquisti effettuati (per eventuali statistiche). 3.1.1.3. Processing. Il sistema controlla che la persona non sia già stata inserita fra i clienti della rosticceria, nel qual caso inserisce tutti i dati. 3.1.1.4. Output. Messaggio di conferma dell avvenuto inserimento oppure messaggio d errore. 3.1.2. Requisito #2 3.1.2.1.Introduzione. Consultazione Menù. 3.1.2.2. Input. account (UserId, Pwd) 3.1.2.3.Processing. Il menù contenente i prodotti in vendita e le offerte disponibili deve essere visualizzabile come elenco con le principali informazioni per ogni voce: codice, nome, disponibilità, prezzo. 3.1.2.4.Output. Di ogni voce del menù deve essere possibile visualizzare le informazioni dettagliate selezionandola dall'elenco. 3.1.3. Requisito #3 3.1.3.1. Introduzione. Funzioni di ricerca. 3.1.3.2. Input: termini della ricerca. 3.1.3.3. Processing. Deve essere data la possibilità di effettuare ricerche su tutti i prodotti e offerte, a partire da qualsiasi informazione disponibile per un qualsiasi prodotto. I termini di ricerca sono forniti tramite una stringa (lista di parole) contenente 4
tutte le parole che devono essere cercate. Ciascuna parola viene cercata in tutti i campi descrittivi di un prodotto e un prodotto corrisponde nella ricerca se sono presenti tutte le parole cercate. 3.1.3.4. Output: codice, nome, disponibilità, prezzo di ogni prodotto risultante dalla funzione di ricerca. 3.1.4. Requisito #4 3.1.4.1. Introduzione. Operazione di ordinazione. 3.1.4.2. Input. Tipo di pasto, numero di pasti. 3.1.4.3. Processing. Selezionando gli articoli durante la consultazione del menù, o dei risultati di una ricerca, deve essere possibile registrare una ordinazione di un cliente che sia stato già registrato nell'anagrafe clienti. In ogni momento, dell'ordinazione devono essere visualizzabili il prezzo totale e i prodotti che la compongono con i rispettivi prezzi. 3.1.4.4. Output. Il prezzo totale deve essere calcolato tenendo automaticamente conto di eventuali offerte riguardanti il cliente che sta facendo l'ordinazione o riguardanti i prodotti che compongono l'ordinazione. Quindi deve essere garantito che il costo totale calcolato sia il più basso possibile per quel cliente e quell'insieme di prodotti ordinati, senza la necessità di selezionare esplicitamente le offerte disponibili per quei prodotti. 3.1.5. Requisito #5 3.1.5.1. Introduzione. Gestione delle scorte dei prodotti in vendita. 3.1.5.2.Processing. Il software dovrà fornire gli strumenti per il mantenimento delle informazioni sulle scorte dei prodotti in vendita. 3.1.6. Requisito #6 3.1.6.1. Introduzione. Inserimento Reclamo. 3.1.6.2.Input: Ordinazione già avvenuta, descrizione reclamo. 3.1.6.3.Processing. Il software dovrà permettere la registrazione dei reclami, riferiti a ordinazioni esistenti, da parte dei clienti. 3.1.7. Requisito #7 3.1.7.1. Introduzione. Gestione Reclami. 3.1.7.2.Input: Prodotto. 3.1.7.3.Processing. Il software dovrà permettere la gestione dei reclami consentendo di consultarli e cancellarli. 3.1.7.4.Output. Reclami associati al prodotto. 3.1.8. Requisito #8 3.1.8.1. Introduzione. Statistiche varie. 3.1.8.2. Input. 3.1.8.3. Processing. Il software dovrà fornire gli strumenti per il mantenimento delle informazioni riguardanti: Prodotti con più reclami. Consegne effettuate da ciascun fattorino Clienti serviti da ciascun commesso. 5
Capitolo 2 Activity Diagram 2.1 Commesso Il commesso usa il software per caricare le informazioni fornite dal cliente, effettuare ricerche per rispondere alle richieste e registrare le ordinazioni. Queste sono tutte attività indipendenti l'una dall'altra, ed è possibile eseguirle in qualsiasi ordine ed eventualmente passare da una all'altra in ogni momento. Commesso Ricevi informazioni sul cliente Registra ordinazione [richiede informazioni] [nuovo cliente] Consulta esito ordinazione Consulta informazioni Registra cliente [conferma ordinazione] [rifiuta ordinazione] Accetta ordinazione Cancella ordinazione Figura 2-1 Activity Diagram: Commesso 6
2.2 Ordinazione In Figura 2-2, si rappresentano le attività che vengono svolte per soddisfare una nuova ordinazione di un cliente. Le colonne nella figura (dette corsie), identificano le aree di azione del software: Gestione Ordinazioni: l'ordinazione può essere presa in considerazione se il prodotto è disponibile. Quando l'ordinazione è confermata, viene presa da un cuoco (per la preparazione). Gestione Amministrativa: mentre viene preparato il pasto viene preparata anche la fattura. Gestione Scorte: riguarda la gestione delle scorte dei prodotti, ovvero il controllo del loro stato con l eventuale richiesta di nuove scorte nel caso di bassa disponibilità delle stesse. Gestione Consegne: le consegne vengono effettuate da un fattorino. Gestione Ordinazioni Gestione Consegne Gestione Amministrativa Gestione Scorte Ricevi Ordine Verifica Ordine [non valida] [confermata] Cancella Ordine Prepara Ordine Prepara Scontrino Aggiorna Scorte [Scorte Scarse] Rinnova Scorte Consegna Incasso Figura 2-2 Activity Diagram: Ordinazione 7
Capitolo 3 Use case diagram 3.1 Diagramma degli attori Il diagramma degli attori ci permette di poter meglio identificare tutti i possibili utenti del sistema. Attore Operatore Esterno Utente Generico Fornitore Utente Registrato Tutti coloro che accedono al sistema da client remoti. Pubblico Dipendente Direttore Cuoco Commesso Cassiere Fattorino Addetto Scorte Figura 3-1 Diagramma degli attori 8
3.2 Utente Generico Si tratta delle principali situazioni d'uso che coinvolgono un Utente Generico (Figura 3-2). Non essendo ancora registrato un utente generico può solamente consultare la lista dei prodotti venduti, effettuare il Login per diventare un utente registrato o compiere una richiesta di registrazione diventando un utente Pubblico. Un utente generico può diventare un dipendente solo tramite l intervento diretto e quindi la registrazione da parte del Direttore. Consulta menù Login Utente Generico Richiesta di registrazione "Actor" Sistema di accounting Figura 3-2 Use Case Utente Generico 3.3 Direttore Si tratta delle principali situazioni d'uso che coinvolgono un direttore (Figura 3-3). Gestione Dipendenti DBMS Listino prezzi DBMS Direttore Revoca account "Actor" Sistema di accounting Figura 3-3 Use Case Direttore 9
3.4 Commesso Si tratta delle principali situazioni d'uso che coinvolgono un commesso (Figura 3-4). La consultazione delle informazioni si riferisce sia alla ricerca dei prodotti nel menù, sia alla consultazione dei dati dei clienti. «extends» Registra Cliente Identifica Cliente «extends» Aggiorna Cliente Registra Reclamo Commesso Ricevi ordinazione «extends» <<include>> Consulta informazioni <<include>> Cancella ordinazione <<include>> Ordinazione non valida Verifica ordinazione «extends» Figura 3-4 Use case: Commesso 10
3.5 Ordinazione Si tratta delle principali situazioni d'uso per la gestione di una ordinazione (Figura 3-5). Registra incasso Fattorino Consegna ordinazione <<include>> Prepara scontrino Cassiere Cuoco Prendi ordinazione Figura 3-5 Use case: Ordinazione 3.6 Scorte Si tratta delle principali situazioni d'uso per la gestione delle scorte (Figura 3-6). L'addetto al mantenimento delle scorte controlla periodicamente se queste sono sufficienti e, in caso contrario, contatta un fornitore per ordinarne di nuove. All'arrivo delle nuove scorte aggiorna i dati sulla loro disponibilità. Aggiorna Scorte «extends» Scorte Insufficienti Addetto Scorte Controlla Scorte Fornitore Figura 3-6 Use case: Scorte 11
3.7 Diagramma delle interfacce Ad ognuno degli utenti, che utilizza il software di gestione della rosticceria, viene assegnata una interfaccia distinta. Interfaccia direttore Interfaccia sistema Interfaccia Utente Generico Interfaccia Utente Pubblico Interfaccia Commesso Figura 3-7 Diagramma delle interfacce 12
Capitolo 4 Class diagram 4.1 Package diagram Sono stati utilizzati quattro package per descrivere questo software. Nel package Varie non è stata indicata alcuna dipendenza; questo perché, in genere, tutti i package hanno una dipendenza da questo package. Ordinazioni Varie Prodotti Persone Figura 4-1 Package Diagram 4.2 Varie Le classi di questo package (Figura 4-2), descrivono tipi fondamentali usati in tutti gli altri package. Viene definita anche l'interfaccia List: il metodo cerca() richiede una stringa (lista di parole) contenente tutte le parole che devono essere cercate e ritorna a sua volta una lista che è poi visualizzabile chiamando il metodo visualizza(). Ciascuna parola viene cercata in tutti i campi descrittivi di un prodotto e un prodotto corrisponde nella ricerca se sono presenti tutte le parole cercate. Tramite l'interfaccia List si è stabilito un modo comune per effettuare ogni tipo di ricerca sia nell'anagrafe dei clienti, sia nel menù dei prodotti, sia nella lista dei reclami. <<interface>> List +cerca(cosa:string) : List() +visualizza() Unit +nome : String +sigla : String Quantity -ammontare : unsigned int -unità : Unit Money Figura 4-2 Class Diagram Varie 13
4.3 Persone Le classi di questo package (Figura 4-3), gestiscono i dati personali dei clienti e dei dipendenti. La seconda e terza statistica indicate nell SRS dal Requisito #8 sono mantenute come attributi derivati nelle classi dei rispettivi dipendenti. Queste informazioni sono infatti ricavabili consultando le ordinazioni (Figura 4-5), tuttavia tale ricerca sarebbe molto lunga per cui si è preferito aggiungere dei campi opportuni per mantenere questi valori. Le 2 composizioni con indirizzo non vanno bene. Sostituire con associaz. Anche l associazione con Anagrafe Cli. non va bene. Utente Generico Utente Registrato -Nome : String -Cognome : String -codicefiscale : String -telefono : String -UserId : String -Pwd : String +crea() +elimina() +visualizzadati() +modificadati() +RichiestaRegistrazione() +NuovoAccount() +Login() +Logout() 1 domicilio Indirizzo -via : String -numero : String -CAP : Integer -comune : String -provincia : String +modificadati() domicilio 1 Fornitore -RagioneSociale : String -PIVA : String +crea() +elimina() +visualizzadati() <<sovrapposta>> posizione Cliente -punteggio : Integer 1..1 Dipendente -datanascita : : Date -stipendio : Money 0..1 <<Dinamica>> Ruolo Direttore Cuoco Commesso Cassiere Fattorino Addetto Scorte -/nclienti : Integer -/nconsegne : Integer 0..* Carta di credito -istituto di emissione : String -NConto : Variant -NCarta : Variant -CIN : Variant -CAB : Variant -ABI : Variant +NuovaCarta() +EliminaCarta() Anagrafe Clienti -numeroclienti : Integer +VisualizzaClientiMigliori() <<interface>> List Figura 4-3 Class Diagram Persone 14
4.4 Prodotti Le classi di questo package (Figura 4-4), gestiscono i dati relativi ai prodotti in vendita. La prima statistica indicata nell SRS dal Requisito #8 è mantenuta come attributo derivato nella classe Prodotto. Questa informazione è ricavabile consultando le ordinazioni (Figura 4-5), tuttavia tale ricerca sarebbe molto lunga per cui si è preferito aggiungere il campo nreclami per memorizzare il numero di reclami fatto per ogni prodotto. La disponibilità di ogni prodotto, sarà in generale verificata in modo diverso per ciascun tipo di prodotto. La disponibilità di un'offerta dipende da quella dei prodotti che ne fanno parte e dal fatto che non sia passata la data di scadenza indicata. La disponibilità di un prodotto in scorta è verificata se la quantità in scorta è non nulla. Per ogni pasto devono essere sufficienti, invece, le quantità disponibili dei componenti (come indicato dal commento in Figura). Prodotto {abstract} -codice : String -nome : String -prezzo: Money -descrizione : String +disponibile : bool -nreclami : Integer voci 1..* Menù -validità: Range 1..* <<interface>> List Pasto Prodotto in scorta Offerta -nome : String -scorta: Quantity -scadenza : Date Componente -qta: Quantity componenti 1..* Ingrediente -nome : String Bibita -contenitore: Contenitore -quantità: Quantity disponibile se per ogni componente, (componente.qta <= componente.ingrediente.scorta) Figura 4-4 Class Diagram Prodotto 15
4.5 Ordinazioni Le classi di questo package (Figura 4-5) gestiscono i dati relativi alle ordinazioni dei clienti. Da notare come per ogni ordinazione si tenga traccia di tutti i dipendenti che l hanno gestita: l eventuale commesso che l ha registrata, nel caso non sia stata fatta tramite web; i cuochi che l hanno preparata; il fattorino che l ha consegnata. Questo serve per ricavare le statistiche richieste dal Requisito #8 dell SRS. Pagamento -modalità: modopagamento <<da Persone>> Commesso <<da Persone>> Cuoco <<da Persone>> Fattorino 0..1 * 0..1 ricevuto da presa da consegnata da 1 * * * Ordinazione -stato: OrderState -data : Date -/importo: Money +CalcolaImporto() numerovoce * * fatta da /luogo consegna 1 1 <<da Persone>> Cliente <<da Persone>> Indirizzo 1 * Reclamo -descrizione : String * * 1 <<da Prodotti>> Prodotto LineaOrdinazione -qtà : Quantity ListaReclami -reclami : Integer <<interface>> List Figura 4-5 Class Diagram Ordinazioni 16
Capitolo 5 Sequence diagram 5.1 Registrazione Utente Generico La registrazione di un utente, per diventare un Cliente e quindi per poter effettuare ordinazioni, può essere fatta sia da parte di un Commesso sia tramite il sito web. Consideriamo il Sequence Diagram di quest ultimo caso. Interfaccia Utente Generico Sistema di Accounting Cliente Utente Generico Accede al sito web RichiestaRegistrazione() Unico = cerca() [Not Unico] Unico [Not Unico] Account non unico [Unico] NuovoAccount() Conferma la Registrazione Conferma la Registrazione Conferma la Registrazione Figura 5-1 Sequence diagram Registrazione Utente Generico 17
5.2 Accesso al sistema informativo Per accedere al sistema informativo un utente generico deve effettuare il Login. Tale operazione permetterà di cambiare l interfaccia dell utente in modo che possa eseguire tutte le operazioni per le quali è abilitato. Al termine della sessione di lavoro si fa il Logout per disconnettere l utente dal sistema. Consideriamo il sequence diagram di un Cliente: Interfaccia Utente Generico Interfaccia Cliente Utente Registrato Pubblico Accede al sito web Login(UserId, Pwd) Ok = cerca(userid, Pwd) [Ok] Cambio di Interfaccia [Ok] Conferma Ingresso Logout() Cambio di Interfaccia Conferma Disconnessione Figura 5-2 Sequence diagram Accesso al sistema informativo 18
5.3 Gestione Cliente In Figura 5-3 sono mostrate le procedure di gestione delle informazioni dei clienti da parte del Commesso: ricerca dei dati, modifica dei dati, registrazione nuovo cliente. Quest'ultima include un controllo per evitare il reinserimento di un cliente già registrato. Interfaccia Commesso AnagrafeClienti Cliente Commesso cercacliente() * corrisponde = cerca() * [corrisponde] visualizzadati() modificadati() visualizzadati() nuovocliente() esiste = cercacliente() * corrisponde = cerca() * [corrisponde] visualizzadati() [esiste] visualizzaerrore() [non esiste] crea() [non esiste] visualizzadati() Figura 5-3 Sequence diagram Gestione Cliente 19
5.4 Consulta Menù In Figura 5-4 è mostrata la procedura di consultazione menù. Questa procedura è analoga per tutte le altre operazioni di ricerca poiché tutte vengono fatte tramite la medesima interfaccia definita nella classe List definita in Figura 4-2. Interfaccia Utente Generico Menù Prodotto Prodotto Utente Generico visualizza() * visualizzadati() visualizzascheda() * visualizzascheda() cerca() * corrisponde = cerca() * [corrisponde] visualizzadati() Figura 5-4 Sequence diagram Consulta Menù 20
Capitolo 6 State diagram 6.1 Ordinazione In Figura 6-1, è mostrato lo state diagram per le istanze della classe Ordinazione. Questo è strettamente correlato con il diagramma degli stati di LineaOrdine (Figura 6-2): una ordinazione, per essere valida, deve avere disponibili tutti i prodotti con essa ordinati, quindi ogni LineaOrdine deve controllare la disponibilità del prodotto prima di poter essere inserita nell'ordinazione. Se il prodotto è disponibile, la quantità ordinata viene bloccata nelle scorte (per evitare che un'altra ordinazione fatta contemporaneamente rovini l'ordinazione in corso) e viene rilasciata nel caso l'ordinazione sia annullata. Aggiungi prodotto Verificata entry/ Aggiorna scorte [cliente conferma] /approva() Preparato /pronto() Creata do/ Verifica scorte Conferma /conferma() Confermata Pronta Consegna /consegnato() Consegnata entry/ Registra pagamento [cliente non conferma] /cancella() Transizione sincrona su LineaOrdine Cancellazione /cancella() Cancellata Transizione sincrona su LineaOrdine Figura 6-1 State diagram Ordinazione 21
Consegna /consegnato() Confermata Creazione /crea() Creata Verifica /verifica() In Verifica do/ Verifica Disponibilità [disponibile] /conferma() Inserita entry/ Blocca scorte Cancellazione /cancella() Annullata entry/ Rilascia scorte [non disponibile] /cancella() Cancellazione /cancella() Cancellata Figura 6-2 State diagram LineaOrdine 22
Capitolo 7 Data Flow diagram 7.1 Ricerca In Figura 7-1, è mostrato il data flow diagram per una ricerca. Si può vedere che, per effettuare una ricerca, un commesso fornisce la stringa di ricerca (nel formato descritto nell SRS dal Requisito #3 ) al metodo cerca() del Menù. La ricerca viene quindi effettuata su ogni prodotto nel menù e a quelli corrispondenti viene detto di visualizzare i loro dati. Uno schema analogo vale per tutte le altre operazioni di ricerca. StringaRicerca Menù::cerca() StringaRicerca Prodotto::visualizzaDati() corrisponde{vero,falso} Commesso Dati Prodotto::cerca() Dati Database Prodotti Figura 7-1 Data Flow diagram 23
Capitolo 8 Bibliografia [1] IEEE Recommended Practice for Software Requirements Specification, The Institute of Electrical and Electronics Engineers, Inc. [2] Martin Fowler, Kendall Scott: UML Distilled: Appling the Standard Object Modelling Language, Addison-Wesley 24