N° 1890
SISTEMI INFORMATIVI AZIENDALI TEORIA ESERCIZI LABORATORI 2016-17
DI LUPO PAMINA
Centro Stampa
ATTENZIONE QUESTI APPUNTI SONO OPERA DI STUDENTI , NON SONO STATI VISIONATI DAL DOCENTE. IL NOME DEL PROFESSORE, SERVE SOLO PER IDENTIFICARE IL CORSO.
LEZIONE 1
DEFINIZIONE DI SISTEMA INFORMATIVO
Possiamo dare 2 definizioni:
• Senso ampio: sistema che memorizza, gestisce ed elabora informazioni utilizzate dalle organizzazioni. Come si può notare non è specificato se si tratta di un sistema cartaceo o informatico ecc, ma semplicemente di un sistema utilizzato dalle organizzazioni.
Questo sistema informativo comprende i pc ma anche l’informazione gestita su carta, ma comprende anche i soggetti che gestiscono questa informazione, che prendono il nome di attori, dal momento che svolgono una parte in questo processo ed infine il software su cui gira questo sistema. Il sistema informativo pertanto comprende una serie di strumenti che operano sull’informazione. Ci si dovrà chiedere poi se una operazione lascia traccia nel sistema informativo o meno.
Es: strappo un foglio di carta in due, non lascia traccia nel sistema informativo, mentre stampare un foglio x lascia traccia nel sistema informativo, dal momento che su quella carta rimane una informazione.
Se si iscrive un nuovo membro è una modifica dei dati, qualsiasi cosa accada comporta una modifica dei dati, altrimenti non è tracciabile.
• Senso stretto: computer based information system. E’ un sottoinsieme di quello precedente.
Rappresenta la parte informatica del sistema informativo che memorizza ed elabora le informazioni utilizzate dall’organizzazione. Ciò che non è informatizzato non lo vedo qui dentro.
Il computer in sé non è sufficiente poiché questo non potrebbe fare molto se gli venisse preclusa la possibilità di interagire con l’esterno. Il sistema informatico per avere una utilità deve essere inserito in un sistema più ampio.
Es. biglietti del tram. Nel momento in cui viene stampato il Sinformatico ha il dato del codice del biglietto che viene stampato. Poi quando viene stampato, questo diviene un pezzo di carta che è sempre parte del sistema informativo, poiché porta con se delle informazioni, ma non è più parte del sistema informatico. Quando lo timbro, l’obliteratrice trasmette l’informazione che quel codice, (corsa) è stata utilizzata e quindi l’informazione rientra nel sistema informatico mentre ha sempre fatto parte del sistema informativo.
Definizione del Laudon:
Sistema informativo è un sistema composto da componenti intercorrelati che devono lavorare insieme in modo coordinato, per processare, raccogliere, immagazzinare e diffondere informazioni.
Il sistema informatico composto da hardware e software fa parte del sistema informativo che vive all’interno dell’organizzazione, la quale a sua volta fa parte di un ambiente composto da enti esterni, ad es. clienti, fornitori, Stato, gli azionisti ecc… Tali entità interagiscono con l’organizzazione e pertanto il sistema informativo ne deve tenere conto. Le info che il SI elabora spesso provengono dall’esterno oltre che da processi interni.
Es. Devo pagare delle fatture. Per far ciò ho bisogno delle coordinate bancarie del mio cliente. Nel mio sistema informativo ci saranno delle informazioni relative alle coordinate bancarie del mio fornitore, cioè nel mio SI ci saranno dei dati relativi alla banca del mio fornitore. Questo non implica necessariamente che il mio sistema informativo sia collegato con quello della banca, può essere che il mio SI non interagisca con quello della banca ma abbia info sulla banca. In quest’ultimo caso il pagamento avviene collegandosi attraverso l’home banking.
Le informazioni di cui il SI viene a sono un input, tale input avviene spesso attraverso gli utenti del SI stesso, ad es. passo il badge, spingo il tasto, inserisco la carta nella fessura del bancomat ecc… C’è quindi un’azione esterna che deve fornire l’informazione. Alle volte è il SI stesso che può procurarsi l’informazione autonomamente es andando a leggere il segnale fornito da un sensore di temperatura.
Le informazioni il SI deve memorizzarle ed elaborarle, deve cioè trasformare informazioni in ingresso in informazioni in uscita.
Bisogna abituarsi a pensare su die livelli: un livello astratto (generale), nel quale io immagino un processo e lo descrivo, e un livello concreto, nel quale il processo descritto diventa uno schema che comprende tanti processi specifici che compongono quello principale.
LEZIONE 2-5
Esempio PROCESSO: abbiamo diversi attori, ognuno scambia informazioni diverse. Il sistema informativo è tanto più complesso quanto più aumenta il numero di attori e quanto più questi sono distanti. Se bisogna gestire un processo i cui attori sono sparsi nel mondo, serve un sistema informativo estremamente efficiente.
Esempio TWITTER: unico attore (tutti possiamo fare le stesse cose), ma tantissime istanze dello stesso attore (gli utenti). Tutti abbiamo lo stesso tipo di informazioni, ma ognuno ha le proprie.
Tutti possono fare le stesse cose. Alcune operazioni possono essere fatte in modo diverso.
MODELLAZIONE CONCETTUALE (c’è capitolo del prof online)
Modello è una descrizione precisa e formalizzata. Esistono vari enti che hanno proposto dei formalismi di modellazione e quello che impiegheremo sarà l’UML.
L’UML è composto da una serie di diagrammi ciascuno con un focus Diverso.
Nel modello concettuale si cercherà di andare a descrivere nel modo migliore possibile i concetti, le informazioni sulle quali il SI dovrà lavorare, descrivo nel modo più preciso possibile il mondo che il SI dovrà gestire.
DIAGRAMMA DELLE CLASSI
Andiamo quindi a descrivere quali sono le info che il SI dovrà gestire e come dovrà farlo, attraverso il Diagramma delle Classi.
Il modello concettuale dovrà definire delle classi che poi andranno a finire in tabelle di database.
Questa fase segue quella di raccolta, sollecitazione e analisi dei requisiti per poterli strutturare.
1° fase del processo di strutturazione dei requisiti raccolti è la definizione dei concetti principali e dei dati che vengono associati alla rappresentazione di ciascuno dei concetti e che rappresentano l’informazione associata a ciascun concetto.
Avremo quindi una serie di concetti principali, ciascuno dei quali avrà una serie di attributi descrittivi.
I concetti assumono significato anche sulla base delle relazioni esistenti tra i diversi concetti.
Es. Se uno studente è iscritto ad un corso di laurea, l’iscrizione a quel corso non è un’informazione dello studente, ma una relazione tra lo studente e il corso di Laurea, tra l’insieme degli studenti e l’insieme dei corsi di laurea. Attributi di oggetti e relazioni tra oggetti sono due cose diverse.
Quindi le tre caratteristiche che compongono la grammatica del diagramma delle classi sono:
- Disegno concetti (rettangolo con un nome)
- I dati associati ai concetti (elenco dei tipi di dati che un concetto può avere) - Le relazioni che legano un tipo di concetto ad un altro.
Il termine concetto è utilizzato qui poiché stiamo facendo riferimento al modello concettuale ma questo assumeva il termine di entità nel modello entità-relazione, assume il nome di classe se stiamo in programmazione ecc… A questo livello di astrazione questi termini sono tutti intercambiabili anche se noi lo chiameremo prevalentemente classe perché cosi vengono definiti dall’UML.
Classi
La classe può essere immaginata come un contenitore di elementi concreti. Ad esempio la classe impiegato è un concetto astratto di impiegato che poi in realtà corrisponderà a tanti singoli impiegati, distinti tra di loro e ciascuno con i suoi dati. Quindi oltre al livello astratto c’è quindi quello concreto delle istanze, degli oggetti di una classe, delle relazioni, degli elementi ecc…
Il SI dovrà lavorare sui dati di ciascun singolo impiegato in quanto il SI lavora sempre su dati concreti ma le regole che applica a questi dati concreti sono uguali per tutti gli elementi della classe ( impiegati nell’esempio specifico). Le regole generali che applico vengono definite a livello di classe astratte e non esiste pertanto il concetto di impiegato medio o tipo. Esiste la classe generale di impiegato su cui esistono dei dati, ma questi dati non sono quelli dell’impiegato astratto ma sono quelli che verranno impiegati ad ogni singolo impiegato concreto.
Se definisco poi una relazione tra impiegato e reparto sto definendo una relazione tra concetti astratti dicendo che per ogni impiegato concreto ci sarà una relazione tra quell’impiegato concreto e il reparto concreto che è una istanza della classe reparto.
La difficoltà sta proprio nel descrivere in termini astratti cose che succedono su livelli concreti. Il SI alla fine lavora su dati corrispondenti ad elementi concreti, le regole cioè i programmi che poi
scriviamo partono da delle generalizzazioni. E allora nella fase di specifica descriviamo cosa fa il SI sul livello astratto.
Il nome della classe definisce un insieme di entità che condividono le stesse caratteristiche, che hanno proprietà comuni e che possano esistere indipendentemente le une dalle altre.
Se definiamo il concetto\classe “vendita” allora stiamo dicendo che il sistema informativo dovrà gestire il concetto vendita e allora questo vuol dire che il sistema informativo dovrà gestire tante vendite e ciascuna di queste si comportano, in termini di regole di funzionamento, allo stesso modo.
La classe impiegato rappresenta il concetto impiegato. Nel modello concettuale stiamo descrivendo le informazioni che il SI ha, deve sapere o deve gestire relativamente all’impiegato. Ragionamento chiave: sono le informazioni a proposito dell’impiegato.
Ciascuna classe è fatta di tanti oggetti che sono tutti caratterizzati dalle stessa tipologia di informazioni. Per l’impiegato posso ad esempio immaginare di avere un modulo sul quale sono riportati o devo riportare tutti i dati relativi all’impiegato.
La classe rappresenta la forma del modulo mentre le singole istanze rappresentano i singoli fogli su cui sono riportati i dati di ciascuno specifico impiegato.
Se prevedo che il modulo relativo all’impiegato comprenda un campo nazionalità è una regola che io definisco a livello astratto ( di classe) ma questa regola poi si applica ai dati raccolti per ogni singolo impiegato. Ovvero ogni singolo impiegato dovrà avere un campo nel quale verrà riportata la sua nazionalità.
Questo ragionamento è valido per tutti gli oggetti.
Gli oggetti tra di loro sono correlati e quindi, non possono essere pensati come entità separate. Ad esempio tra impiegato e città ci può essere una informazione all’interno della scheda dell’impiegato es. la residenza che può connettere le due classi.
Se io sul mio foglio di carta immaginario descrivo l’impiegato con le sue proprietà, tra queste vi è la residenza, ma vi può essere anche il nome. C’è però una differenza semantica tra il nome e la residenza di una persona; per il nome infatti non c’è una lista predefinita di nomi accettati o una legge ben precisa che definisce come tu debba chiamarti, ti chiami come vuoi e questo implica che il nome è una stringa qualunque. Per la residenza invece non posso inserire un nome a caso ma deve essere una città esistente. Ma le città sono a loro volta un’entità del modello, per cui per ogni città avrò una scheda informativa riportante il nome, in che regione si trova, il n° di abitanti ecc…
Non posso sminuire il tutto inserendo nella scheda dell’impiegato il campo città poiché cosi facendo starei degradando una informazione; io ho una info più importante ovvero che gli impiegati, che è per me un concetto primario, sono residenti nelle città che è un altro concetto primario.
Devo rappresentare la relazione tra due concetti per me importanti.
Associazioni/relazioni
Ho tanti impiegati ciascuno dei quali è legato ad una città perché residente, ho quindi un legame esplicito tra i due concetti a cui devo dare un nome e questa è la residenza.
La relazione di residenza è una relazione che ciascuno di noi ha, quando poi salgo di livello e cerco di dare una descrizione astratta dirò che esiste una associazione tra la classe degli impiegati e la classe delle città, che rappresento attraverso una linea alla quale do un nome.
Un impiegato tuttavia potrebbe essere residente in una città e lavorare in un’altra e allora tra impiegato e città esiste una seconda relazione data dal luogo di lavoro.
Il triangolo presente lungo la linea non modifica il significato della relazione ma agevola la lettura della relazione e questo spesso è necessario nel momento in cui si esplica la relazione attraverso un verbo.
Il significato della relazione può essere invece modificato dalla regola con cui si accoppiano i due elementi.
Es. Un impiegato può essere residente in 1 sola città, mentre potrebbe lavorare in più di una ( si pensi ad esempio ad una impresa con più sedi). Una città invece quanti residenti potrà avere?
Potenzialmente molti. Ed è anche vero, inoltre, che una città potrà avere molti impiegati che lavorano al suo interno.
Una relazione quindi per essere ben specificata deve presentare:
• Un nome, spesso sottoforma di verbo, che mi specifica meglio di che natura è la relazione;
• La molteplicità, cioè i vincoli sul numero di quegli altri elementi (dell’altra classe) con cui ciascuno di noi è collegato. Per definire la molteplicità ci si fa sempre 2 domande, una da un lato ed una dall’altro.
Esempio.
Auto monta ruota. Ma data una specifica auto quante ruote ha montato? Normalmente 4.
Se io avessi le informazioni a proposito dell’auto es. targa e VIN e codice a barra su ogni singola ruota, sarei in grado di dire quante ruote monta l’auto (0,1,2,3,4 ma non più di 4). Questo mettendomi nel soggetto auto. La cardinalità mi indica valore minimo e massimo di oggetti dell’altra classe con cui ogni singolo oggetto di questa classe può entrare in relazione.
Viceversa se immaginiamo come soggetto la ruota: questa con quante auto si potrà relazionare? La ruota o è montata su una auto o su nessuna => min 0 e max 1.
Per ragionare sulla molteplicità devo scendere sempre sul livello di oggetti, di elementi concreto poiché se dicessi le ruote su quante macchine vengono messe (ragiono a livello astratto) ? su tante.
I vincoli pertanto li descrivo a livello di classe astratta ma si applicano su di oggetti concreti.
Quando ho la cardinalità massima pari a 1 allora se conosco la ruota => conosco anche l’auto, posso quindi individuare in modo univoco l’auto. Se è montata, può essere presente solo su quell’auto.
Se invece conosco l’auto non posso risalire alla ruota specifica poiché posso averne più di una.
La persona risiede in una sola città che quindi viene identificata in maniera univoca.
Valori della molteplicità da appunti prof.
Ordine e fattura sono legate tra di loro da una relazione di vendita. Faccio un ordine, quindi poi se la merce viene venduta allora collegata a quell’ordine ci sarà la fattura, ma le info presenti sull’ordine sono diverse da quelle presenti sulla fattura. Tuttavia nel momento in cui emetto la fattura questa deve far riferimento ad un ordine preciso ed ecco perché la molteplicità è 1. Se mi metto dentro la classe fattura quanti ordini vedo? 1 sola. Viceversa 0 se nn ho emesso fattura, 1 se l’ho emessa.
Le classi rimangono statiche, ma gli oggetti cambiano in continuazione: la classe studenti esiste sempre, ma gli oggetti variano in base ai nuovi iscritti, ai laureati ecc, man mano che il sistema informativo lavora.
Concetti, relazioni e cardinalità delle relazioni sono tutte cose che si definiscono a livello astratto ma si applicano a livello concreto.
Associazioni ricorsive o rifessive
Si hanno quando i due lati diversi dell’associazione insistono sulla stessa classe. E’ una relazione quindi tra oggetti di una classe e oggetti della stessa classe.
Se la relazione è simmetrica non è necessario specificare il verso (Friend), se non è simmetrica è necessario specificarlo (un impiegato è supervisore di un altro impiegato) . Inoltre diamo un nome ai due estremi della relazione, con i quali possiamo indicare il ruolo con cui l’istanza di questa classe entra nella relazione. I ruoli ai due estremi non sono interscambiabili.
Attributi
Abbiamo detto nell’esempio dell’impiegato che immaginiamo esista un modulo nel quale ci sono i dati dell’impiegato ma da qualche parte dovrò dire quali sono questi dati che sono presenti sul modulo.
Utilizzo per far ciò il secondo spazio del riquadro delle classi.
Le classi rappresentano dei concetti i quali sono legati tra di loro in qualche modo, ma ogni possibile concetto deve possedere delle informazioni che lo identificano.
Pertanto per l’impiegato avremo il nome, l’età, il salario percepito, mentre la residenza è una relazione e quindi non figura come attributo. Non si deve mai mettere sotto forma di attributo ciò che in realtà può essere espresso sotto forma di relazione. Quella associata alla residenza è una informazione relativa alla relazione e non all’attributo.
Gli attributi non sono altro che una serie di variabili, a cui diamo un nome e dei valori e di cui definiamo il tipo di dato con cui sono rappresentate.
Ogni istanza\oggetto di queste classi ha già in se un attributo identificatore.
Ogni classe deve avere un qualche attributo che distingua tra di loro istanze diverse che potrebbero avere per coincidenza gli stessi valori di tutti gli attributi. Solitamente questo potrebbe essere un ID, un codice identificativo, un contatore. Questo campo identificatore spesso è lasciato sottointeso in quanto deve esserci sempre. Noi pertanto elenchiamo i soli attributi che servono a rappresentare l’informazione e che quindi hanno significato dal punto di vista semantico, tra questi poi vi potrebbe eessere anche un attributo identificante (vd. la matricola per uno studente, per cui una volta nota questa lo studente è univocamente identificato).
E’ opportuno rappresentare in quel modo l’informazione sull’età? Non proprio perché l’età è un attributo variabile che quindi si modifica nel tempo. Quindi il sistema informativo dovrà preoccuparsi di andare periodicamente ad aggiornare quel valore e dovrà farlo nel periodo giusto, Se io invece inserissi come attributo la data di nascita e allora una volta inserita non vi è necessità di aggiornarla, ma non solo, l’età è comunque determinabile per differenza.
Altra informazione poco utile è quella del numero di abitanti della città in quanto questa potrebbe essere ricavata dalle molteplicità delle relazioni. Questa informazione non deve essere inserita nel modello, dove invece devono essere inseriti solo quei dati che possibilmente non cambiano più e che non siano derivabili da altri dati.
CASI PARTICOLARI DI ASSOCIAZIONI
- Aggregazione: tipo di relazione particolare che descrive che un oggetto di un certo tipo è composto da parti che sono oggetti di un altro tipo (A è composto da B, quindi B è parte di A). in questo caso è una relazione uno a molti
Esempio: A è il corso di laurea, B sono gli insegnamenti.
Esempio.
Sistema informativo di twitter: molteplicità molti a molti nel retweet significa che lo user può retweettare da zero a infiniti tweet, ma può retweettare ogni tweet una sola volta. Vale la stessa cosa per i biglietti dell’autobus. Posso convalidare infiniti biglietti ma non posso convalidare più di una volta un biglietto. Ne consegue che un tweet può essere retweettato da infiniti user ma mai più di una volta dallo stesso.
Come potremmo rappresentare la situazione in cui un tweet viene rappresentato tante volte?
Dovrei creare una classe “super retweet” che permette questo, inserendo la cardinalità uno a molti sia tra user e super retweet, sia tra super retweet e tweet. Quindi l’utente super ritweetta un tweet e un super retweet si riferisce a un tweet.
Association Class
In questo caso ci chiediamo come fare a modellare delle informazioni associate ad una relazione.
Se volessi ricordarmi la data di un retweet, non potrei metterla né in User né in Tweet. È possibile specificarlo aggiungendo nella tabella Excel l’informazione su quado è stato fatto. Ma in questo modo non compare nel diagramma delle classi.
Association class: mezza classe legata ad un’associazione. Non è una classe perché comprende degli attributi di una relazione. L’association class non cambia la natura, la molteplicità o l’esistenzadella situazione, ma serve per ottenere informazioni in più.
Regole di equivalenza
Nella immagine che segue troviamo due modi diversi di rappresentare la stessa cosa.
Abbiamo un consulente partita IVA che lavora per una azienda e ciascuna azienda avrà molti consulenti. Questo consulente ha una retribuzione oraria differente a seconda dell’azienda per cui lavora perché è riuscito a trattare in maniera differente la sua retribuzione oraria. Ne vien fuori che il salario del consulente non è una proprietà dell’azienda in quanto paga i diversi consulenti in modo diverso. Ma la retribuzione non è neanche una proprietà del consulente in quanto questo lavora con diversi clienti con un costo diverso è quindi una proprietà della relazione tra consulente ed azienda.
Alternativa alla Association Class: introduco il concetto di contratto (classe intermedia) per cui una azienda può stipulare molti contratti, un consulente può stipulare molti contratti. Ogni contratto è relativo ad una specifica azienda ed a uno specifico consulente, per cui il contratto avrà cardinalità pari a 1. A questo punto l’importo è parte del contratto ed è specificato nel contratto. Con la classe intermedia posso però rappresentare anche i casi in cui il consulente lavora più volte per la stessa azienda, mentre con l’associazione semplice non è possibile che esista più di un’istanza tra due oggetti.La classe contratto funge da classe intermedia e nasce per gestire una relazione complessa.
La regola di equivalenza è questa: quando una classe funge da classe intermedia le sue cardinalità in uscita sono sempre 1 altrimenti non sarebbe una rappresentazione della relazione. Le cardinalità vicine sono invece pari a quelle che avrebbe la relazione se stante.
Attenzione all’inversione delle molteplicità.
Il consulente nella prima relazione vedeva tante aziende e nel secondo caso vede tanti contratti ma il numero di aziende che vedevo prima ed il numero di contratti che vede nel secondo caso sono sempre lo stesso valore.
Non è detto che le cardinalità riportate siano poi necessariamente 0..* vi possono essere anche valori diversi. L’importante è che nel primo caso e nel secondo caso le cardinalità siano corrispondenti (insomma non ci devono essere alterazioni delle cardinalità nel passaggio da un caso all’altro.
Quale delle due strade scelgo se sono equivalenti?
La prima risoluzione è quella più semplice ed è preferibile. Quella inferiore è più articolata ma ha il vantaggio che dal momento che “contratto” diviene un’altra classe, “contratto” può partecipare anche ad altre associazioni con altre classi.
“Work_for” invece non è una classe vera e non è possibile farsi che partecipi ad altre associazioni con altre classi.
Ne consegue quindi che se tra biglietto e rivenditore le due strade mi risultavano indifferenti dal momento che “attiva2” non deve partecipare a null’altro pertanto è possibile modellarla con qualcosa di più leggero come una association class , non è vero nel caso di convalida; convalida non è semplicemente una association class tra biglietto e obliteratrice poiché convalida deve partecipare ad altre relazioni.
Domanda da porsi è la seguente: la classe intermedia fa anche altre cose o il suo unico scopo è quello di dare informazioni aggiuntive su quella relazione? Deve fare altre cose? E allora la modello come classe intermedia, altrimenti sta a noi fare la scelta.
Generalization/specialization di una classe in un’altra
Possono esistere classi che sono una versione più generale/specifica di altre classi.
Questo costrutto tratta l’ereditarietà tra una classe ed un'altra, avremo quindi una classe più generale e da questa ne derivo una più specialistica.
Questa relazione avviene quando abbiamo insiemi di elementi che in realtà sono un caso particolare di un insieme più ampio. Es. lo studente è un caso particolare di persona; l’autobus, il tram sono un caso particolare di mezzi di trasporto.
Possiamo quindi avere una classe più generale relativa ai mezzi di trasporto nella quale descrivi ciò accomuna tutti i mezzi di trasporto e poi abbiamo delle classi più specialistiche\specifiche\specializzate che riguardano sempre mezzi di trasporto ma in più so che è un tram, per cui potrà andare solo sulle linee provviste di rotaie oppure è un autobus per cui dovrò preoccuparmi di fare rifornimento cosa di cui non dovrei preoccuparmi invece se considerassi il tram.
La classe specializzata è una classe che fa tutto ciò che la classe generale faceva, perché è della stessa natura, in più ha delle specificità sue particolari che ci suggeriscono di doverla trattare in modo particolare.
La classe A è una classe generale e B è una classe che specializza A questo significa che le istanze\elementi\oggetti di B (i singoli autobus) hanno in se tutte le proprietà di un qualunque elemento di A (mezzi di trasporto)
Il concetto di generalizzazione è esattamente opposto a quello di specializzazione (relazione inversa) Il simbolo è una freccia con punta vuota e la freccia punta dalla classe specializzata verso quella generale.
Un impiegato ad esempio avrà tutti gli attributi di persona ed in più avrà l’attributo del salario.
Questa relazione si legge “employee is a person” dove “is a” indica sono un tipo particolare di persona e quindi significa che io impiegato sono anche un tipo particolare di persona.
Se considerassi la singola istanza della classe impiegato (per intenderci il singolo individuo che è impiegato) esso avrà l’attributo “salary” e gli attributi della classe “person”.
Questa è una relazione un po’ strana perché le relazioni viste sino ad ora mettevano in relazione le istanze di una classe con quelle di un’altra classe. Qui invece sto dicendo che tutto ciò che una persona ha ce l’ha anche l’impiegato. A livello insiemistico lo rappresenterei come un sottoinsieme per cui essere in B => automaticamente di essere in A.
Questo approccio è utile nel momento in cui mi trovassi ad avere una classe impiegato e una classe studente con molti attributi in comune, per cui anziché ripetere gli stessi attributi in entrambe creo la superclasse (classe generale) nella quale vado ad inserire gli attributi comuni ad entrambi. Le parti non comun i restano nelle relative classi.
