Introduzione Ai Diagrammi IDEF1X

UNIVERSITA’ POLITECNICA DELLE MARCHE Prof. F.
Mandorli
Integration DEFinition methods

IDEF1X
• Prof. F. Mandorli
UNIVERSITA’ POLITECNICA DELLE MARCHE Prof. F. Mandorli
La Famiglia di Metodologie IDEF

• IDEF = Integration DEFinition methods
• La famiglia di metodi IDEF è stata sviluppata
all’interno del progetto ICAM (Integrated
Computer Aided Manufacturing) della Air
Force Americana nei primi anni ‘70
• Lo scopo era lo sviluppo di un insieme di
strumenti formali per descrivere, analizzare
e valutare processi aziendali
Design Tools & Methods Group - f.mandorli@staff.univpm.it

DIISM – Università Politecnica delle Marche - Via Brecce Bianche – 60131 ANCONA
www.idef.com
– IDEF0: modellazione delle azioni/funzioni
– IDEF1: modellazione delle informazioni,
identificazione delle necessità e delle richieste
– IDEF1x: modellazione delle relazioni tra i dati
– IDEF2: identificazione del comportamento
dinamico del sistema
– IDEF3: modellazione dell processo produttivo e
del Work-Flow
– IDEF4: analisi object-oriented
– IDEF5: analisi ontologica
– IDEF6: analisi del processo decisionale
IDEF: i più usati

• IDEFØ
– per modellare cosa fa l’azienda
– rappresenta le attività in termini di input, output, controlli e
strumenti
• IDEF3
– per descrivere come lo fa
– Rappresenta il flusso delle attività nel processo
• IDEF1/1X
– per rappresentare strutture gerarchiche
– Rappresenta strutture gerarchiche che possono essere dati
(data-base) o la struttura del prodotto

IDEF1X: Concetti di base

• Mette in evidenza la struttura dei dati coinvolti
nella gestione di un processo
• Per struttura dati si intende l’informazione
strutturata che è necessario gestire all’interno
di un processo
• Il focus è sugli oggetti e sulle interazioni
esistenti tra essi in termini di scambio di
informazioni
• L’approccio è di tipo Object-Oriented


• L’obiettivo è quello di rappresentare sistemi
complessi mediante tecniche di decomposizione
Struttura di un PC
(oggetto fisico)
Anche la struttura di
un’azienda è un sistema
complesso!!!!


• Manca la rappresentazione della sequenzialità
delle azioni
• Più adatto per la rappresentazione di prodotto
che di processo

OOA: Classi ed oggetti

• Una classe è definita dal suo nome e da un
insieme di attributi e servizi ad essa associati
• Un oggetto, istanza di una classe, è definito
assegnando dei valori agli attributi
– Es: classe = catalogo
oggetto = elemento del catalogo

OOA: Astrazione
• Gli oggetti del mondo reale sono estremamente più
complessi di quanto sia possibile rappresentare
• L’obiettivo dell’astrazione è quello di gestire la
complessità mediante i seguenti principi logici:
– Classificazione
– Ereditarietà
– Incapsulazione
– Polimorfismo
– Aggregazione
– Associazione
– Collaborazione

OOA: Classificazione
• Usata per raggruppare entità che
condividono le stesse caratteristiche, definite
da un insieme di coppie proprietà/valore
• Un oggetto è sempre un membro (istanza) di
una classe
– es. la FIAT 500 è un istanza della classe delle
autovetture

OOA: Ereditarietà
• Esprime le similarità tra classi tramite i concetti
di generalizzazione (cosa è uguale) e
specializzazione (cosa è differente)
• Crea una gerarchia di classi
– Es: la classe delle autovetture è una specializzazione
della classe dei mezzi di trasporto (e, viceversa, la
classe dei mezzi di trasporto è una generalizzazione
della classe delle autovetture)

OOA: Incapsulazione
• L’incapsulazione è il concetto che permette di
considerare un oggetto come una scatola nera:
si conoscono i servizi resi disponibili ma non si
entra nel merito di come sono realizzati
• Definisce le interfacce dell’oggetto verso gli
altri oggetti del sistema
– Es: l’oggetto motore è associato alla potenza erogata
senza entrare nel merito del funzionamento del
motore

OOA: Polimorfismo
• Il polimorfismo permettere di esprime il
concetto di servizi comuni offerti da oggetti
di tipo diverso
• I servizi comuni offerti saranno realizzati in
maniera differente dai diversi oggetti
– Es: un motociclo, un’autovettura ed una bicicletta
offrono il servizio di trasporto

OOA: Aggregazione
• L’aggregazione permette di raggruppare gli
oggetti. Corrisponde al tradizionale concetto di
assieme
• L’oggetto raggruppato può essere considerato
come un unico oggetto
– Es: un autovettura è composta da motore,
trasmissione, frizione, ecc.

OOA: Associazione
• Il concetto di associazione serve a definire
relazioni tra oggetti, diverse da quella
espressa dall’aggregazione
• Può essere usato per rappresentare
connessioni logiche
– Es: ad un autovettura è associato un proprietario

OOA: Collaborazione
• Esprime la capacità degli oggetti di scambiarsi
informazioni e servizi
• Serve per rappresentare il flusso delle
informazioni tra gli oggetti
– Es: un sensore comunica un’anomalia alla
centralina elettronica

IDEF1x: Sintassi
• Entità (classificazione)
– Rappresentano elementi reali o astratti, definiti da
un insieme di proprietà comuni
– Una entità è indipendente se ogni istanza può
essere identificata univocamente,
indipendentemente dalle sue relazioni con altre entità
Entità indipendente Entità dipendente

IDEF1x: Sintassi
• Attributi (classificazione)
– Rappresentano le proprietà che definiscono un'entità
– Quando un attributo assume un valore diventa una
istanza dell'attributo
– Gli attributi primary-key sono quelli che permettono
di identificare univocamente l'entità (es. codice)

IDEF1x: Sintassi
• Categorie (ereditarietà)
– Esprime una relazione in cui a un'entità più
generica ne viene associata una più dettagliata
– Permette di creare una struttura gerarchica di
entità; quelle di livello più alto contengono gli
attributi comuni

IDEF1x: Sintassi
• Categorie (ereditarietà)
– È possibile indicare che la classificazione è completa
(sono elencate tutte le entità di dettaglio), oppure
incompleta (non tutte le entità di dettaglio sono
elencate)

IDEF1x: Sintassi
• Relazione (associazione)
– È una connessione di tipo padre/figlio in cui ogni
istanza padre può essere associate a zero, una o più
istanze figlio e, viceversa, ogni istanza figlio può
essere associate a zero, una o più istanze padre
– La cardinalità predefinita della relazione è zero, una o
più di una entità associata
– È possibile specificare altri tipi di cardinalità,
utilizzando delle lettere poste a fianco della relazione

IDEF1x: Sintassi
– Indicazione della cardinalità

IDEF1x: Sintassi
• Relazione (associazione con ereditarietà)
– Identifying relationships:
– È un'istanza 'figlio' che per essere identificata univocamente
deve essere associata ad un 'padre'
– In questo caso, ogni istanza 'figlio' deve essere associata con
esattamente una istanza 'padre'
– Es: se una entità task è identificabile univocamente all'interno di
un progetto, potremo avere una entità progetto 'padre' e una
entità task 'figlio' con una relazione di tipo identifying
relationship

IDEF1x: Sintassi
• Relazione (associazione con ereditarietà)
– Identifying relationships:
– In questo caso, l'entità figlio
è sempre di tipo
identifier-dependent e
gli attribute primary key
del padre migrano
nell'entità figlio

IDEF1x: Sintassi
– Non-identifying relationships:
– È un'istanza 'figlio' che può essere identificata univocamente
senza la sua associazione con il 'padre'
– Es: può esistere una relazione tra un'entità acquirente e
un'entità ordine di acquisto ma un ordine di acquisto può essere
identificato univocamente da un numero d'ordine, senza dover
conoscere l'entità acquirente

IDEF1x: Sintassi
– In questo caso, sia l'entità figlio
che l'entità padre sono di tipo
identifier-independent (a
meno che uno o entrambi non
siano entità 'figlio' di un 'padre'
necessario per identificarle)

IDEF1x: Sintassi
– Mandatory: ogni istanza 'figlio' è in
relazione esattamente con una
entità 'padre'
– Optional: ogni istanza 'figlio' è in
relazione con zero o una istanza
padre

IDEF1x: Conclusioni
• Presenta numerose analogie con altri schemi di
rappresentazione OO, di cui forse il più famoso à
OOAD
– Object Oriented Analysis, Peter Coad and Ed
Yourdon, 1991
– Object Oriented Design, Peter Coad and Ed Yourdon,
1991
– Object Oriented Programming, Peter Coad and Jill
Nicola, 1993
– Object Oriented Design and Analysis, Grady Booch,
1994
IDEF1x: Esempio

IDEF1x: esercizio proposto

• Modellare entità e relazioni per la definizione di
un database per la gestione di squadre (di calcio)
e giocatori, includendo gestione dello stadio e del
management della squadra


Introduzione Ai Diagrammi IDEF1X

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Introduzione Ai Diagrammi IDEF1X

Caricato da

Copyright:

Formati disponibili

UNIVERSITA’ POLITECNICA DELLE MARCHE Prof. F.

Integration DEFinition methods

La Famiglia di Metodologie IDEF

Design Tools & Methods Group - f.mandorli@staff.univpm.it

IDEF: i più usati

Design Tools & Methods Group - f.mandorli@staff.univpm.it

IDEF1X: Concetti di base

Design Tools & Methods Group - f.mandorli@staff.univpm.it

IDEF1X: Concetti di base

Design Tools & Methods Group - f.mandorli@staff.univpm.it

IDEF1X: Concetti di base

Design Tools & Methods Group - f.mandorli@staff.univpm.it

OOA: Classi ed oggetti

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Entità indipendente Entità dipendente

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Design Tools & Methods Group - f.mandorli@staff.univpm.it

IDEF1x: esercizio proposto

Design Tools & Methods Group - f.mandorli@staff.univpm.it

Potrebbero piacerti anche