I diagrammi di struttura - I parte
Laboratorio di Ingegneria del Software Prof. Paolo Ciancarini
Dott. Sara Zuppiroli
A.A. 2010/2011
Pre-requisiti per l’analisi del sistema
Diagrammi dei casi d’uso
Le descrizione delle sequenze Alcuni scenari necessari
Il documento di glossario
Analisi
Si trovano le entità coinvolte
Si studiano i legami tra le entità (relazioni tra le entità) Si sta individuando la struttura del sistema
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).
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.
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.
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.
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.
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:
I analisi nome-verbo
I analisi CRC
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.
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.
Esempio di sceda CRC
Un esempio di scheda CRC
Nome Classe: Conto Corrente Responsabilità Collaboratori
Gestire saldo Banca
... ...
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
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
Classi e oggetti in UML
Person
-age : int
+getAge() : int Person
age = 10
Jim : Person
: 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.
Relazione tra classe e oggetto
-age : int
+getAge() : int Person
age = 10
Jim : Person
<<instanceOf>>
Si tratta di una dipendenza con stereotipo «instanceOf» (o
«istanzia» sul libro).
Classe: notazione
-numero : String -correntista : String -saldo : double = 0.0
+create(numero : String, correntista : String) +deposito(somma : double)
+preleva(somma : double) +getNumero() : String +getCorrentista() : String +getSaldo() : double
<<entity>>
ContoBancario Stereotipo
Nome
Sottosezione attributi
Sottosezione operazioni
Visibilità
Operazione!con!ambito!di!classe
Questo livello di dettaglio è tipico delle classi di progettazione, non quelle di analisi.
Classi di analisi vs. classi di progettazione in UML
Classi di analisi:
I contengono tipicamente solo pochi attributi e operazioni (candidati)
I a volte basta indicare solo il nome della classe
I pochi ornamenti, specifica incompleta (omessi tipi, signature delle operazioni, etc.)
Classi di progettazione:
I modellano una classe del linguaggio di programmazione scelto
I specifica completa (implementabile)
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.
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 del- la classe (o suo sottopackage annidato) può accedere ai membri della classe con visibilità package
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.
Ambito
Ambito di istanza:
I gli oggetti hanno una propria copia degli attributi, quindi oggetti diversi possono avere diversi valori negli attributi
I Le operazioni agiscono su oggetti specifici
Ambito di classe:
I gli oggetti di una stessa classe condividono lo stesso valore per un attributo
I le operazioni non operano solo su una particolare istanza della classe, ma alla classe stessa. Ad esempio: costruttori e distruttori di classe.
I rappresentato sottolineando l’attributo/operazione
I analogo alla parola chiave static in Java
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à.
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
Generalizzazione
Vertebrate Mammal
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.
Generalizzazione: stili grafici
ExamplesPackage PowerTypes
In Figure 7.42, the Person class can be specialized as either a Female Person or a Male Person. Furthermore, Person’s can be specialized as an Employee. Here, Female Person or a Male Person of Person constitute one GeneralizationSet and Manager another. This illustration employs the notation forms depicted in the diagram above.
Figure 7.41 - Examples of generalizations between classes
Shape
Polygon Ellipse Spline
Shape
Polygon Ellipse Spline
Separate target style
Shared target style
Female Person PersonMale
Employee Person
gender
Female Person
Male
Person Employee
Person
employment status gender
Female Person
Male
Person Employee
Person
gender
gender employment
status
employment status
Female Person
Male
Person Employee
Person
Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/2011 26 / 58
Insiemi di generalizzazione
70 UML Superstructure Specification, v2.0
Examples
Package PowerTypes
In Figure 7.42, the Person class can be specialized as either a Female Person or a Male Person. Furthermore, Person’s can be specialized as an Employee. Here, Female Person or a Male Person of Person constitute one GeneralizationSet and Manager another. This illustration employs the notation forms depicted in the diagram above.
Figure 7.41 - Examples of generalizations between classes
Figure 7.42 - Multiple subtype partitions (GeneralizationSets) example
Shape
Polygon Ellipse Spline
Shape
Polygon Ellipse Spline
Separate target style
Shared target style
Female Person
PersonMale
Employee Person
gender
Female Person
Male
Person Employee
Person
employment status gender
Female Person
Male
Person Employee
Person
gender
gender employment
status
employment status
Female Person
Male
Person Employee
Person
Permettono di partizionare lo stesso elemento generale in modi diversi.
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.
Figli di classi astratte
-origin -width -height +draw()
+getArea() : int Shape
+draw()
+getArea() : int Rectangle
+draw()
+getArea() : int Circle
I figli forniscono il comportamento definito come astratto in Shape.
Ereditarietà multipla
Child
Parent1 Parent2
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
Associazione
Person Company employer employee
*
1 employs
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.
Sintassi delle associazioni
Person Company employer employee
*
1 employs
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
Molteplicità
Person
Company employer employee
*
1 employs
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:
I 1
I 0..1
I 1..*
I *
Associazioni riflessive
Directory File
parent 0..1
child
* 1
*
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
Esercizio sugli oggetti istanza di associazioni riflessive
Directory File
parent 0..1
child
* 1
*
Disegnare il dagramma degli oggetti dato il diagramma delle classi.
Associazioni riflessive e istanze
Directory File
parent 0..1
child
* 1
*
Una possibile realtà che soddisfa l’associazione...
home : Directory
projects : Directory pictures : Directory
memo.txt : File
Navigabilità (1)
Player Year
player year
playedInYear
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.
Navigabilità (2)
The following examples show notation for navigable ends.
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.
• The fifth pair IJ shows a binary association with one end navigable and the other having unspecified navigability.
Figure 7.22 shows that the attribute notation can be used for an association end owned by a class, because an association end owned by a class is also an attribute. This notation may be used in conjunction with the line-arrow notation to make it perfectly clear that the attribute is also an association end.
Figure 7.21 - Examples of navigable ends
A b B
2..5 1..4
a
E F
2..5 f 1..4
e
C D
2..5 d 1..4
c
h
G H
2..5 1..4
g
I J
2..5 j 1..4
i
A b B
2..5 1..4
a
E F
2..5 f 1..4
e
C D
2..5 d 1..4
c
h
G H
2..5 1..4
g
I J
2..5 j 1..4
i
Alcuni esempi di navigabilità.
Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/2011 38 / 58
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:
I non si usano le croci
I l’assenza di frecce indica navigabilità in entrambe le direzioni
I una freccia indica navigabilità in quella direzione e assenza di navigabilità nell’altra
I doppia navigabilità risulta indistinguibile da navigabilità non specificata, ma non è un problema in pratica
Attributi come associazioni
Examples
Figure 7.28 - Examples of attributes
The attributes in Figure 7.28 are explained below.
• ClassA::name is an attribute with type String.
• ClassA::shape is an attribute with type Rectangle.
• ClassA::size is a public attribute of type Integer with multiplicity 0..1.
• ClassA::area is a derived attribute with type Integer. It is marked as read-only.
• ClassA::height is an attribute of type Integer with a default initial value of 5.
• ClassA::width is an attribute of type Integer.
• ClassB::id is an attribute that redefines ClassA::name.
• ClassB::shape is an attribute that redefines ClassA::shape. It has type Square, a specialization of Rectangle.
• ClassB::height is an attribute that redefines ClassA::height. It has a default of 7 for ClassB instances that overrides the ClassA default of 5.
• ClassB::width is a derived attribute that redefines ClassA::width, which is not derived.
An attribute may also be shown using association notation, with no adornments at the tail of the arrow as shown in Figure 7.29.
Figure 7.29 - Association-like notation for attribute
ClassB id {redefines name}
shape: Square height = 7
/ width
ClassA name: String
shape: Rectangle + size: Integer [0..1]
/ area: Integer {readOnly}
height: Integer= 5 width: Integer
Area
Window
size1
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.
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:
I una persona può essere occupata in molte aziende
I un’azienda può avere più impiegati
I dove inserire l’attributo salario?
I se inseriamo salario su persona potremmo avere il caso che una persona lavora per più aziende con uno stipendio
diverso per ogniuna di esse
I se inseriamo salario come attributo della classe Azienda perchè ogni azienda impiega molte persone.
I questo attributo quindi non si riferisce a persona o a compagnia, ma alla loro relazione
Si usano le classi di associazione.
Classi di associazione (2)
7.3.5 BehavioralFeature (from Kernel)
A behavioral feature is a feature of a classifier that specifies an aspect of the behavior of its instances.
Generalizations
• “Feature (from Kernel)” on page 66
• “Namespace (from Kernel)” on page 95
Description
A behavioral feature specifies that an instance of a classifier will respond to a designated request by invoking a behavior.
BehavioralFeature is an abstract metaclass specializing Feature and Namespace. Kinds of behavioral aspects are modeled by subclasses of BehavioralFeature.
Attributes
No additional attributes
Associations
• ownedParameter: Parameter[*] Specifies the ordered set of formal parameters owned by this BehavioralFeature.
The parameter direction can be ‘in,’ ‘inout,’ ‘out,’ or ‘return’ to specify input, output, or return parameters. Subsets Namespace::ownedMember
• raisedException: Type[*] References the Types representing exceptions that may be raised during an invocation of this operation.
Constraints
No additional constraints Additional Operations
Figure 7.25 - An AssociationClass is depicted by an association symbol (a line) and a class symbol (a box) connected with a dashed line. The diagram shows the association class Job, which is defined between the two classes Person and Company.
Company
Person * Job 1..*
Job
salary
person company
Si tratta di una classe a tutti gli effetti, chiamata come la relazione.
Collegata alla relazione tramite una linea tratteggiata.
Puoc possedere attributi, operazioni e altre associazioni.
Il significato della classe associazione in figura è dato un oggetto Persona e un’oggetto Azienda esiste un solo
oggetto Lavoro.
Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/2011 42 / 58
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
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
*
*
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.
Aggregazione e composizione: notazione
Aggregazione
ComputerCluster 0..1 * Computer
Composizione
House 1 1..* Room
Ancora sulla notazione
Figure 7.23 shows the notation for a derived union. The attribute A::b is derived by being the strict union of all of the attributes that subset it. In this case there is just one of these, A1::b1. So for an instance of the class A1, b1 is a subset of b, and b is derived from b1.
Figure 7.24 shows the black diamond notation for composite aggregation.
Changes from previous UML
AssociationEnd was a metaclass in prior UML, now demoted to a member of Association. The metaatribute targetScope that characterized AssociationEnd in prior UML is no longer supported. Fundamental changes in the abstract syntax make it impossible to continue targetScope or replace it by a new metaattribute, or even a standard tag, there being no
appropriate model element to tag. In UML 2, the type of the property determines the nature of the values represented by the members of an Association.
7.3.4 AssociationClass (from AssociationClasses)
A model element that has both association and class properties. An AssociationClass can be seen as an association that also has class properties, or as a class that also has association properties. It not only connects a set of classifiers but also defines a set of features that belong to the relationship itself and not to any of the classifiers.
Generalizations
• “Association (from Kernel)” on page 36
• “Class (from Kernel)” on page 45
Figure 7.23 - Derived supersets (union)
Figure 7.24 - Composite aggregation is depicted as a black diamond
A B
0..*
/b {union}
0..1 a
A1 B1
0..*
b1 0..1
a
{subsets b}
Window
Slider
Header Panel
+scrollbar
+title +body
1 1 1
2 1 1
Aggregazione e composizione possono essere combinate con le altre notazioni per le associazioni.
Lab di Ingegneria del Software () I diagrammi di struttura - I parte A.A. 2010/2011 47 / 58
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.
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.
Esempio di ciclo illegale
A
*
*
:A
:A
:A
Data un’aggregazione riflessiva (es. struttura dati albero), ecco
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.
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.
I puntatori
I array
I references
I oggetti
Alcune associazioni vanno trasformate in una forma implementabile (reificate) durante la progettazione.
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.
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.
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.
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.
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.
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.
