I diagrammi di struttura - I parte

Transcript

1 I diagrammi di struttura - I parte Laboratorio di Ingegneria del Software Prof. Paolo Ciancarini Dott. Sara Zuppiroli A.A. 2010/2011 Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

2 Pre-requisiti per l analisi del sistema Diagrammi dei casi d uso Le descrizione delle sequenze Alcuni scenari necessari Il documento di glossario Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

3 Analisi Si trovano le entità coinvolte Si studiano i legami tra le entità (relazioni tra le entità) Si sta individuando la struttura del sistema Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

4 Analisi vs. Progettazione L analisi modella i concetti chiave del dominio del problema. La progettazione adatta il modello di analisi e lo completa affinché diventi implementabile. In altre parole... L analisi è più vicina al problema. La progettazione è più vicina all implementazione. Dal punto di vista di UML, si usano gli stessi tipi di diagramma con diversi livelli di dettaglio (i diagrammi di analisi sono più astratti di quelli di progettazione). Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

5 Classi e oggetti Costituiscono i mattoni della struttura di un sistema. Classe: É il descrittore di un insieme di oggetti che condividono: attributi, operazioni, metodi, relazioni e comportamento. Definisce un insieme di oggetti che hanno le stesse caratteristiche. Oggetto: É un entità discreta con confini ben definiti che cattura stato e comportamento; un istanza di una classe. Nell analisi si modella il dominio del problema attraverso l uso delle classi di analisi. Sono poi raffinate nelle classi di progettazione più simili a quelle da implementare. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

6 Stato e Comportamento di un Oggetto Stato: É stabilito dai valori degli attributi di un oggetto in un dato istante. Lo stato di un oggetto dipende dal valore dei sui attributi Comportamento: Indica cosa può fare un oggetto. I comportamenti sono descritti come operazioni in analisi. L esecuzione di un operazione comporta spesso una modifica dello stato di un oggetto. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

7 Come fare l analisi Estrarre un insieme di classi partendo dalla specifica del problema. Individuate le classi ragionare su quali attributi e quali operazioni sono utili a risolvere il problema. Stendere una mappa delle classi e delle relazioni che le legano. Chiarire la dinamica che intercorrono tra le classi attraverso i diagrammi di comportamento. Procedere in maniera iterativa (per raffinamenti successivi) per produrre un modello che rappresenti efficacemente il dominio del problema. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

8 Come progettare Si raffina il modello di analisi che contiene classi abbastanza generiche. I costrutti più astratti di UML vengono trasformati in altri più concreti che possono essere implementati in un linguaggio di programmazione OO. Si considerano i vincoli di piattaforma, linguaggio, e tutti i requisiti non funzionali. Si utilizza un metodo iterativo. Il risultato è un modello pronto per l implementazione. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

9 Come procedere: estrarre le classi di analisi Una classe di analisi modella un concetto o entità del problema: se la specifica dei casi d uso è buona i concetti basilari sono già in evidenza. I candidati più probabili sono nomi che compaiono nella specifica e nella documentazione. Una ragione in più per tenere un glossario di progetto: le parole nel glossario sono spesso candidati ideali per diventare classi di analisi. Le classi di analisi non sopravviveranno necessariamente alla progettazione. Due metodi molto diffusi per trovare le classi di analisi: analisi nome-verbo analisi CRC Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

10 Analisi nome-verbo Si analizza tutta la documentazione disponibile e si sottolineano: I nomi: (conto corrente) sono i potenziali candidati per divenire classi o attributi. I predicati nominali: (numero del conto corrente) sono i potenziali candidati per divenire classi o attributi. I verbi: (aprire) sono potenziali candidati a divenire responsabilità di classe. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

11 Analisi CRC Class-Responsibilities-Collaborators Si tratta di un metodo di brainstorming di gruppo che coinvolge sviluppatori, esperti, committenti. Si individuano i nomi delle classi, un insieme ristretto di responsabilità (cose che la classe sa/fa) e di classi collaboratori (alle quali viene richiesto comportamento/informazione). Si usano post-it divisi in tre sezioni chiamate proprio in questo modo. Le schede sono suddivise e la loro vicinanza fisica rispecchia quella logica. Si procede iterativamente per raffinamenti successivi. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

12 Esempio di sceda CRC Un esempio di scheda CRC Nome Classe: Conto Corrente Responsabilità Collaboratori Gestire saldo Banca Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

13 Le classi di analisi Le qualità di una buona classe di analisi: il suo nome ne rispecchia l intento è un astrazione ben definita, che modella uno specifico elemento del dominio del problema corrisponde ad una caratteristica ben identificabile del dominio ha un insieme ridotto e definito di responsabilità ha la massima coesione interna ha la minima interdipendenza con altre classi Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

14 Classi di analisi: regole pratiche 3-5 responsabilità per classe non isolata, collabora con un piccolo insieme di altre classi evitare il proliferare di classi troppo semplici evitare la concentrazione del modello in poche classi complesse evitare troppi livelli di ereditarietà tenere in mente i principi object-oriented Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

15 Classi e oggetti in UML Person Person -age : int +getage() : int Jim : Person age = 10 : Person Le classi possono avere fino a 3 slot: uno (obbligatorio) per il nome (in UpperCamelCase) e l eventuale stereotipo, uno per gli attributi e uno per le operazioni (opzionali). La stessa classe può apparire con diverse quantità di ornamenti in diagrammi diversi. Il titolo degli oggetti è sottolineato e del tipo nome : classe, con nome opzionale. Gli oggetti non hanno uno slot per le operazioni, possono definire valori per gli attributi. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

16 Relazione tra classe e oggetto Person -age : int +getage() : int <<instanceof>> Jim : Person age = 10 Si tratta di una dipendenza con stereotipo «instanceof» (o «istanzia» sul libro). Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

17 Classe: notazione Stereotipo Nome Sottosezione attributi Sottosezione operazioni Visibilità -numero : String -correntista : String -saldo : double = 0.0 <<entity>> ContoBancario +create(numero : String, correntista : String) +deposito(somma : double) +preleva(somma : double) +getnumero() : String +getcorrentista() : String +getsaldo() : double Operazione!con!ambito!di!classe Questo livello di dettaglio è tipico delle classi di progettazione, non quelle di analisi. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

18 Classi di analisi vs. classi di progettazione in UML Classi di analisi: contengono tipicamente solo pochi attributi e operazioni (candidati) a volte basta indicare solo il nome della classe pochi ornamenti, specifica incompleta (omessi tipi, signature delle operazioni, etc.) Classi di progettazione: modellano una classe del linguaggio di programmazione scelto specifica completa (implementabile) Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

19 Attributi visibilità nome molteplicità:tipo=valoreiniziale Solo il nome è obbligatorio Le classi di analisi solitamente contengono solo gli attributi più importanti (quelli che risultano evidenti dall analisi del dominio); spesso specificano solo il nome di un attributo. Assegnare un valore iniziale in una classe di analisi può evidenziare i vincoli di un problema. Le classi di progettazione forniscono una specifica completa (implementabile) della classe e dei suoi attributi. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

20 Tipi di visibilità + public ogni elemento che può accedere alla classe può anche accedere a ogni suo membro con visibilità pubblica - private solo le operazioni della classe possono accedere ai membri con visibilità privata # protected solo le operazioni appartenenti alla classe o ai suoi discendenti possono accedere ai membri con visibilità protetta package ogni elemento nello stesso package della classe (o suo sottopackage annidato) può accedere ai membri della classe con visibilità package Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

21 Operazioni visibilità nome (nomeparametro:tipoparametro,... ): tiporestituito Valgono le stesse considerazioni fatte a proposito degli attributi per quanto riguarda analisi e progettazione. In ogni classe non ci possono essere due operazioni con la stessa signature. Il nome di attributi ed operazioni è scritto in lowercamelcase. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

22 Ambito Ambito di istanza: gli oggetti hanno una propria copia degli attributi, quindi oggetti diversi possono avere diversi valori negli attributi Le operazioni agiscono su oggetti specifici Ambito di classe: gli oggetti di una stessa classe condividono lo stesso valore per un attributo le operazioni non operano solo su una particolare istanza della classe, ma alla classe stessa. Ad esempio: costruttori e distruttori di classe. rappresentato sottolineando l attributo/operazione analogo alla parola chiave static in Java Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

23 Ambito e accessibilità Operazioni con ambito di istanza possono accedere sia ad altre operazioni o attributi con ambito di istanza sia con ambito di classe. Operazioni con ambito di classe possono accedere solo ad altre operazioni e attributi con ambito di classe (altrimenti non si saprebbe quale istanza scegliere). Valgono le usuali restrizioni di visibilità. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

24 Relazioni tra classi Ci sono due relazioni statiche tra classi particolarmente importanti in UML: Generalizzazione Associazione Vi sono poi altre due relazioni che possono legare le classi anche ad altri tipi di elementi: Dipendenza Realizzazione Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

25 Generalizzazione Mammal Vertebrate Relazione tassonomica tra un elemento più generale e uno che lo specifica. La freccia parte dall elemento specifico e punta verso quello più generale. Si tratta dell ereditarietà in UML. Tra tutte le relazioni, questa è la più forte e vincolante. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

26 Generalizzazione: Examples stili grafici Shape Separate target style Polygon Ellipse Spline Shape Shared target style Polygon Ellipse Spline Figure Examples of generalizations between classes Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

27 be specialized as an Employee. Here, Female Person or a Male Person of Person constitute one Generalizatio Manager another. This illustration employs the notation forms depicted in the diagram above. Insiemi di generalizzazione Person Person gender Female Person gender Male Person employment status Employee gender Female Person Male Person employment status Employee Person Person gender employment status Female Person Male Person Employee Female Person Male Person Employee Figure Multiple subtype partitions (GeneralizationSets) example Permettono di partizionare lo stesso elemento generale in modi diversi. 70 UML Superstructure Specif Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

28 Classi astratte In UML, un classificatore può essere dichiarato astratto: significa che non è istanziabile. I classificatori astratti si riconoscono per il nome in corsivo. Le classi possono definire operazioni astratte (in corsivo), di cui non è data la specifica. Una classe con almeno un operazione astratta è automaticamente una classe astratta. Una classe astratta non è istanziabile... ma i suoi figli possono esserlo. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

29 Figli di classi astratte -origin -width -height Shape +draw() +getarea() : int Rectangle +draw() +getarea() : int Circle +draw() +getarea() : int I figli forniscono il comportamento definito come astratto in Shape. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

30 Ereditarietà multipla Parent1 Parent2 Child UML supporta l ereditarietà multipla: un classificatore può ereditare da un numero arbitrario di altri classificatori. A tempo di analisi questo permette di modellare efficacemente situazioni del mondo reale. Tuttavia, classi con ereditarietà multipla dovranno essere risolte a tempo di progettazione se il linguaggio scelto non la supporta. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

31 Associazione Company employer 1 employs employee * Person Si tratta del tipo di relazione più generico: indica solo l esistenza di collegamenti (link) tra le istanze delle classi. Rappresenta l abilità di un istanza di mandare messaggi a un altra istanza. Formalmente, definisce l esistenza di tuple tra istanze tipate (se o1 è associato a o2, la coppia ordinata (o1, o2) fa parte della relazione). Può coinvolgere più di due classi e la stessa classe più di una volta. Tra le relazioni è anche la più flessibile e la meno vincolante. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

32 Sintassi delle associazioni Company employer 1 employs employee * Person Nome dell associazione. Triangolo direzionale: opzionale. Specifica la direzione in cui leggere l associazione (aumenta la leggibilità). Nome dei ruoli: opzionali a ciascun estremo. Molteplicità: opzionale a ciascun estremo. Navigabilità: opzionale indica che è possibile spostarsi da un qualsiasi oggetto della classe origine a uno o più oggetti della classe destinazione dipende dalla molteplicità Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

33 Molteplicità Company employer 1 employs employee * Person In una relazione n-aria, indica quante istanze della classe in quell estremo possono partecipare alla relazione dopo aver fissato gli altri n-1 estremi. Può essere un numero o un intervallo min..max, con * che indica l infinito. 1..3,7 significa da 1 a 3 oppure 7. Molteplicità frequenti sono: * * Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

34 Associazioni riflessive parent 0..1 File * 1 Directory child * Un associazione riflessiva coinvolge la stessa classe più di una volta. Esempio: gerarchia di file system. Se si sostituisce la molteplicità 0..1 di parent con *, si generano grafi invece di alberi. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

35 Esercizio sugli oggetti istanza di associazioni riflessive parent 0..1 File * 1 Directory child * Disegnare il dagramma degli oggetti dato il diagramma delle classi. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

36 Associazioni riflessive e istanze parent 0..1 File * 1 Directory child * Una possibile realtà che soddisfa l associazione... home : Directory memo.txt : File projects : Directory pictures : Directory pic01.jpg : File Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

37 Navigabilità (1) Player player playedinyear year Year Specifica se gli altri estremi dell associazione possono sapere a quali istanze sono associati. La freccia indica navigabilità. La croce indica assenza di navigabilità. La mancanza di entrambe significa navigabilità non specificata (tipico della fase di analisi). Un oggetto di tipo Player sa in quali anni ha giocato, un oggetto di tipo Year non sa quali giocatori giocarono quell anno. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

38 Navigabilità (2) The following examples show notation for navigable ends. A a 1..4 b 2..5 B C c 1..4 d 2..5 D E e 1..4 f 2..5 F G g 1..4 h 2..5 H I i 1..4 j 2..5 J Figure Examples of navigable ends Alcuni esempi di navigabilità. In Figure 7.21: The top pair AB shows a binary association with two navigable ends. The second pair CD shows a binary association with two non-navigable ends. The third pair EF shows a binary association with unspecified navigability. The fourth pair GH shows a binary association with one end navigable and the other non-navigable. Lab di Ingegneria del Software () The fifth pair IJ shows a binary association with one end navigable and the other having unspecified navigability I diagrammi di struttura - I parte A.A. 2010/ / 58

39 Notazione pratica per la navigabilità In pratica, si tende a non specificare la navigabilità di ogni estremo di ogni relazione. Un metodo diffuso è il seguente: non si usano le croci l assenza di frecce indica navigabilità in entrambe le direzioni una freccia indica navigabilità in quella direzione e assenza di navigabilità nell altra doppia navigabilità risulta indistinguibile da navigabilità non specificata, ma non è un problema in pratica Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

40 Figure Attributi come associazioni Window size 1 Area Figure Association-like notation for attribute UML permette di rappresentare un attributo di una classe con la notazione tipica di un associazione. Il nome dell attributo compare come ruolo insieme alla sua molteplicità. Non ci sono ornamenti dalla parte della classe che contiene l attributo. 52 Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

41 Classi di associazione (1) Spesso può capitare di avere un associazione tra classi e la necessità di aggiungere attributi e comportamento che non sembrano adatti a nessuna delle due classi. Ad esempio, si considerino le classi Persona e Azienda: una persona può essere occupata in molte aziende un azienda può avere più impiegati dove inserire l attributo salario? se inseriamo salario su persona potremmo avere il caso che una persona lavora per più aziende con uno stipendio diverso per ogniuna di esse se inseriamo salario come attributo della classe Azienda perchè ogni azienda impiega molte persone. questo attributo quindi non si riferisce a persona o a compagnia, ma alla loro relazione Si usano le classi di associazione. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

42 Classi di associazione (2) Person * Job 1..* person company Company Job salary Figure An AssociationClass is depicted by an association symbol (a with a dashed line. The diagram shows the association class Job, which is and Company. Si tratta di una classe a tutti gli effetti, chiamata come la relazione BehavioralFeature (from Kernel) Collegata alla relazione tramite una linea tratteggiata. Puoc possedere attributi, operazioni e altre associazioni. A behavioral feature is a feature of a classifier that specifies an aspect of the Il significato della classe associazione in figura è dato un Generalizations oggetto Persona e un oggetto Azienda esiste un solo oggetto Lavoro. Feature (from Kernel) on page 66 Namespace (from Kernel) on page 95 Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

43 Esempio classi associazione Disegnare il diagramma delle classi che risolve la seguente frase: Una persona può avere da zero a più cittadinanze. La cittadinanza è la relazione che esiste tra una persona e uno stato. Una persona può avere più di un lavoro retribuito in una specifica azienda. Una persona può avere al più un lavoro in diverse aziende Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

44 Reificare le classi di associazione Le classi di associazione sono un ottimo strumento di analisi... ma nella progettazione? Trasformarle in una forma implementabile significa reificarle. Si spezza l associazione in due e si trasforma in una normale classe. Company * * Person Job Company 1 * * 1 Job Person Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

45 Aggregazione e composizione Si tratta di particolari forme di associazione che rappresentano la relazione whole-part (tutto-parte) tra un aggregato e le sue parti. Aggregazione: relazione poco forte (le parti esistono anche senza il tutto; es. i computer e il loro cluster). Composizione: relazione molto forte (le parti dipendono dal tutto e non possono esistere al di fuori di esso; es. le stanze e la casa). Non è sempre semplice capire quale delle due modella meglio una situazione. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

46 Aggregazione e composizione: notazione Aggregazione ComputerCluster 0..1 * Computer Composizione House 1 1..* Room Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

47 Figure Derived supersets (union) Ancora sulla notazione Figure 7.24 shows the black diamond notation for composite aggrega Window scrollbar Slider 2 +title 1 +body 1 Header Panel Aggregazione e composizione possono essere combinate con le altre notazioni per le associazioni. Changes from previous UML Figure Composite aggregation is depicted as a black diamond AssociationEnd was a metaclass in prior UML, now demoted to a me Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

48 Aggregazione: semantica (1) L aggregato può in alcuni casi esistere indipendentemente dalle parti, ma in altri casi no. Le parti possono esistere indipendentemente dall aggregato. L aggregato è in qualche modo incompleto se mancano alcune delle sue parti. È possibile che più aggregati condividano una stessa parte. L aggregazione è transitiva. L aggregazione è asimmetrica. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

49 Aggregazione: semantica (2) Il vincolo più importante di una aggregazione è che le istanze devono essere acicliche. In altre parole, la parte non deve essere in grado di contenere il tutto. Se il problema richiede di avere cicli, bisogna usare una normale associazione. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

50 Esempio di ciclo illegale * A * :A :A :A Data un aggregazione riflessiva (es. struttura dati albero), ecco un diagramma degli oggetti non valido. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

51 Composizione: semantica (1) Ogni parte può appartenere ad un solo composito per volta. Il composito è l unico responsabile di tutte le sue parti: questo vuol dire che è responsabile della loro creazione e distruzione. Il composito può rilasciare una sua parte, a patto che un altro oggetto si prenda la relativa responsabilità. Se il composito viene distrutto, deve distruggere tutte le sue parti o cederne la responsabilità a qualche altro oggetto. In altre parole, la composizione è come l aggregazione, ma la parte non può esistere separata dal tutto. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

52 Associazioni e linguaggi di programmazione Cosa diventano le associazioni quando sono implementate in un linguaggio di programmazione? Dipende dalle caratteristiche del linguaggio e dal tipo e molteplicità dell associazione. puntatori array references oggetti Alcune associazioni vanno trasformate in una forma implementabile (reificate) durante la progettazione. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

53 Associazioni durante la progettazione La navigabilità viene generalmente aggiunta in fase di progettazione (le associazioni di analisi tendono ad essere bidirezionali). La navigabilità in un solo senso è vantaggiosa in vista dell implementazione. Aggregazione e composizione sono spesso aggiunte in fase di progettazione. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

54 Esercizio Che tipi di associazioni legano le seguenti proposizioni: La macchina è un mezzo di trasporto. Un mazzo di carte francesi ha 52 carte. Un anzienda ha diversi dipendenti. La bicicletta ha 2 ruote. Il sistema solare è formato da pianeti. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

55 Esercizio negozio on-line Disegnare il diagramma delle classi di analisi del seguente problema: Un negozio di articoli sportivi desidera acquistare un applicazione che permetta l acquisto on-line di alcuni articoli. I clienti si dovranno registrare. Il cliente potrà scegliere gli articoli secondo alcuni parametri raccolti nel catalogo definito dall amministratore del negozio on-line. Si potranno acquistare più articoli in una sola transazione, questi articoli formeranno un carrello. Al termine dell acquisto saranno disponibili diversi metodi di pagamento. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

56 Esercizio gestione biblioteca Viene richiesto un sistema che permetta al bibliotecario e a un utente di effettuare ricerche di libri. Il bibliotecario deve poter effettuare il prestito e gestire la restituzione del libro. Un utente deve restituire il libro entro una certa data. Se il prestito risulta scaduto per la prima volta il sistema emette un avviso, se è la seconda volta il bibliotecario registra e stampa una multa. L utente a questo punto può decidere se pagare la multa subito oppure no. Il sistema deve permettere la registrazione del pagamento. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

57 Esercizio ricerche prodotti Utilizzando il metodo CRC individuare le classi di analisi del seguente problema: Una libreria ha la necessità di un sistema che le permetta di far effettuare ricerche al suo personale nel suo catalogo. All interno della libreria vengono venduti anche dvd video, e cd musicali. Questo catalogo è consultabile anche on-line dagli utenti che hanno la carta fedeltà della libreria. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58

58 Esercizio Se fosse la stessa azienda a produrre il software cosa potrebbe fare? Si potrebbe modificare le analisi fatte per rendere riusabile lavoro effettuato precedentemente? Disegna il nuovo diagramma delle classi. Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/ / 58