Lezione 6.
Modelli astratti: ER, UML Class diagrams, DF
•
•
•



Modelli astratti classificati secondo il loro
orientamento a rappresentare dati/funzioni/controllo.
Entity-Relation (-Attribute) diagrams
UML Class diagrams and class relationships
•

[S2000, Cap. 7]
[GJM91, Cap. 5]
[BRJ99, Capp. 4, 5]
dependency, generalization, association, aggregation, composition
Data-Flow diagrams
Slide 1
System models nel contesto R.E.
Feasibility
study
Requirements
elicitation and
analysis
Requir ements
specification
Feasibility
report
Requirements
validation
System
models
User and system
requirements
Requirements
document


System models help understand data, functionality, and perhaps control aspects
of the system, and to communicate with the Client. They must leave out details
Different models provide complementary viewpoints about the system (not
VORD viewpoints)
Slide 2
Sistemi = funzioni + dati + controllo
Programmi
Algoritmi
Sistemi
Dati
Algoritmi
Logica
Funzioni
Dati
Controllo
Controllo
Slide 3
Relazioni fra modelli rispetto alle ‘dimensioni’ dati/funzioni
Rappresentazione
di dati e loro relazioni
E.R.
E. R. = Entity relation
O-O = Object-Oriented (Class diagrams)
XFSA = Extended Finite State Machines
P.A. = Process algebra (p.es LOTOS)
= meno formale, incompleto (black-box),
Enfatizza un solo aspetto ==> adatto alla fase
dei Requirements
Usano
ereditarieta’
O-O
Trattano
il controllo
Rappresentazione
di funzioni
e loro input-output
XFSM/P.A.
Data Flow
Slide 4
Formalismi rispetto Dati/Funzioni/Controllo
FSM = Finite State Machines
XFSM = Extended FSM
PN = Petri Net
Pr/T = Predicate/Transition
O-O = Object-Oriented Design
DFD = Data Flow Diagrams
ER = Entity-Relation diagrams
ADT = Abstract Data Types
Z
Slide 5
Expressive dimensions and model applicability
Requiremens analysis
Abstract models
1 dim.
Formal spec
Software
High
Spec.
Level
architecture
Design
Low
Level
design
ER (data)
DFD (function)
FSM, PN, Basic LOTOS (Control + Function)
2 dim.
3 dim.
ADT, Z (Data + Function)
XFSM, Pr/T Nets, Full LOTOS
O-O (Data+Function+Control),
Slide 6
ER diagrams for data modeling




Entity-relation-attribute (ER or ERA) model identifies
the entities in the system, their relations and attributes
Also used to describe the logical structure of data
processed by the system
Widely used in database design ==> information systems.
Can readily be implemented using commercial relational
databases
Similar to UML Class Diagrams
•
but classes include attributes and operations
Slide 7
Example: ERA structure of a Software Design
Design
Complements
the DFD for the
CASE toolset
(slide 11)
1
is-a
has-nodes
C-date:
creation date
M-Date:
modification date
name
description
C-date
M-date
1
has-links
1
n
n
1
Node
has-links
1
name
type
name
type
2
1
links
1
La freccia serve solo
a facilitare
la lettura della relazione
ed è indipendente dalle
indicazioni di molteplicità
Link
n
1
has-labels
has-labels
Label
n
name
text
icon
n
Slide 8

Node<---2-<links>-1----Link denota una relazione ternaria in
Node X Node X Link
•

NOTA: il diagramma non dice se e’ ammesso il caso (N1, N2, Link1)  links e
(N1, N2, Link2)  links, o se uno stesso link puo’ essere associato a 2 coppie
distinte di nodi.
Node----1-<has_links>-N--->Link denota una relazione ad
arità non fissa in...
infinito
U
K=0
•
Node X Link
k
Rimarrebbe poi da stabilire la mutua consistenza di link e has_links...
Slide 9
nota



La interpretazione delle etichette di molteplicità data da Sommerville,
illustrata nella slide precedente, appare diversa da quella adottata in UML, e
piu’ problematica… Per esempio, in una relazione Studente x Classe dove
ogni studente puo’ seguire piu’ classi, e ogni classe avere piu’ studenti, si
dovrebbero usare due stichette ‘n’ per le molteplicità. Ma che senso
avrebbe considerare tuple a dimensione variabile che contengono piu’
studenti e più classi?
In UML, le relazioni sono binarie, e le molteplicità determinano
semplicemente vincoli sull’insieme di coppie associato alla relazione.
Ma provando ad interpretare anche la relazione links di Sommerville come
binaria, e cercando di interpretare le indicazioni di molteplicità in Node<--2-<links>-1----Link come vincoli a questa relazione binaria, si giunge a
contraddizione, poiché nell’insieme di coppie di links è vero che un link
appare associato sempre a due diversi nodi, ma non sempre un nodo appare
associato ad un solo link.
Slide 10
E-R notation
[GJM91]
Relations are binary, but might have attributes too.
Name
Age
student Sex
enrolledIn
class
Proficiency
Subject
CourseId
MaxEnroll
Relation is formed of pairs in student X class (or triples in student X class X scores)
Slide 11
La relazione, sempre binaria, puo’ essere vincolata:
A
R
B
A R B is one to one
A
R
B
A R B is one to many
A
R
B
A R B is many to one
A
R
B
A R B is many to many
• Non si puo’ esprimere graficamente (formalmente)
che una classe deve avere almeno 5 studenti
• … o che uno studente puo’ prendere al massimo 4 classi
Slide 12
Notazioni di molteplicità da UML
Risolvono parte dei limiti espressivi precedenti

A
A
A
A
1 B
1..*
Ogni A e’ associato con un B
B
Ogni A e’ associato con uno o piu’ B
0..1 B
Ogni A e’ associato con zero o un B
*
B
Ogni A e’ associato con zero o piu’ B
Ammesse anche le annotazioni ‘11’ (squadra-calciatore),
‘2..4’ (canasta-giocatore), ‘2,4’ (automobile-sportello).
Slide 13
node
class
2
0..4
*
5..*
link
student
Relazione fra nodi e link
in un design (cfr. Slide 21)
una classe deve avere
almeno 5 studenti
e uno studente puo’ seguire
al massimo 4 classi
Slide 14
Class diagrams in UML
Descrizione di un insieme di oggetti che condividono
gli stessi attributi, operazioni, relazioni, semantica.
Shape
nome
origin
attributi
move()
resize()
display()
operazioni
Slide 15
Attributo
Una proprietà della classe, che puo’ assumere diversi valori
nelle diverse istanze della classe: in ogni istante, un oggetto di una classe
avrà uno specifico valore per ogni attributo della classe.
Customer
Wall
name
address
phone
birthDate
height: Float
width: Float
thickness: Float
isLoadBearing: Boolean = false
Classe
dell’ attributo
Valore iniziale
di default
Slide 16
Operazione
Un servizio che puo’ essere richiesto a qualunque oggetto della classe, per (far) fare
qualcosa all’oggetto stesso, come modificare il valore di un suo attributo.
Rectangle
TemperatureSensor
add()
grow()
move()
isEmpty()
reset()
setAlarm(t: Temperature)
value(): Temperature
Segnatura
dell’operazione
(classi degli
argomenti e dei
risultati)
Funzione
(restituisce
un valore)
Slide 17
Responsabilità
Un contratto o obbligo di cui una classe si fa carico.
Le responsabilità di una classe sono la formulazione astratta (in testo libero)
dei servizi che essa svolge.
FraudAgent
Responsibilities
-- determine the risk of a customer order
-- handle customer-specific criteria for fraud
Slide 18
Criteri per la identificazione di classi
Come identificare le classi utili?
Le classi costituiscono il vocabolario del sistema; esse modellano astrazioni di
entità che si trovano già:
- nel dominio del problema da risolvere (sistema da realizzare), e
- nella tecnologia che si intende utilizzare per risolverlo (realizzarlo).
1. Identificare le entità che utenti/implementatori usano per descrivere
problema/soluzione. Tecniche possibili: CRC cards, use-case-based analysis
2. Individuare e ripartire in modo bilanciato le responsabilità fra di esse:
ogni entità deve fare una cosa sola, e farla bene
3. Modellare in concreto ogni ‘entitità responsabilizzata’ come una classe, con
attributi e operazioni.
Slide 19
Classi per un sistema di vendita merci
Queste classi modellano entità fisiche
del dominio del problema
Shipment
Entità astratta, serve a tener traccia degli
spostamenti del prodotto spedito
Transaction
Entità astratta, legata alla soluzione
del problema
Slide 20
Distribuzione di responsabilità in Smalltalk
Model
View
Responsibilities
-- manage the state of the model
Controller
Responsibilities
-- render the model on the screen
-- manage movement and resizing
of the view
-- intercept user events
Responsibilities
-- synchronize changes in the model
and its views
Slide 21
Relazioni fra classi

Dopo aver individuato le classi, come modelli
delle entità in gioco, vanno modellate le loro
relazioni.
•
Dependencies (relazione dinamica)
» ‘using’: un’autoclave usa una pompa per pompare acqua
•
generalizations
» una classe è una specializzazione di una classe piu’ generale
» (superclass/subclass, parent/child):
» una bifora è una specializzazione di una finestra
•
associations (relazione statica)
» relazioni strutturali:
» una stanza consiste di pareti, soffitto, finestre, porta,…
Slide 22
Esempi di relazioni
Slide 23
1. Dependency
X usa Y.
Un cambiamento nella classe Y di arrivo della freccia (event)
puo’ comportare la necessità di cambiare la classe X di partenza (window),
ma non viceversa.
Tipica dipendenza: una operazione della classe X ha un parametro di classe Y:
FilmClip
name
playOn(c: Channel)
changeOrder()
status()
Channel
Il metodo PlayOn lavora su c, attivando metodi di classe Channel.
Se la classe Channel cambia, e non offre piu’ gli stessi metodi, PlayOn deve tenerne conto.
Slide 24
2. Generalization
X è una specializzazione di Y, o Y è una generalizzazione di X
Gli oggetti della sottoclasse (figlio) possono essere usati ovunque vengono usati
quelli della superclasse (genitore), ma non viceversa
Un falegname puo’ essere usato ogni volta che si puo’ usare un uomo,
ma un uomo non è sempre usabile dove serve un falegname
Inheritance. Il figlio eredita gli attributi e le operazioni del padre,
e spesso ne possiede altri, che lo rendono appunto specializzato.
Polimorfismo. Se una sottoclasse definisce una operazione con lo stesso nome
e segnatura di una operazione di una superclasse, l’operazione del figlio
rimpiazza quella del padre.
Multiple inheritance. Una classe puo’ ereditare da piu’ super-classi.
Slide 25
Inheritance, abstract class, abstract operation
Abstract class
Abstract operation
- Una classe astratta non puo’ essere
istanziata
- Una operazione astratta in classe X
deve essere implementata dalle
sottoclassi di X
Slide 26
3. Association
Name and name direction
Person
Works for
Company
Role names
Person
Employee
1..*
Employer
*
Company
Multiplicity
Association è una relazione generica
esistono due casi particolari di association: aggregation e composition
Slide 27
3.1 Aggregation
X has_a Y
Una associazione fra un ‘tutto’ e le sue ‘parti’ (whole/part), che pero’ non implica
di per sé relazioni fra le durate in vita dei due oggetti.
School
1..*
Student
Slide 28
3.2 Composition (‘composite aggregation’)


X ha_come_parte Y
E’ una aggregazione forte:
•
•
•
•
•
Y appartiene a un solo X (nella aggregazione semplice no), e
il suo intervallo di esistenza vita è incluso in quello di X.
Parti con molteplicità non fissa possono essere create solo dopo il tutto, e
muoiono assieme ad esso, o vengono esplicit. eliminate prima
Il tutto gestisce la creazione e distruzione delle sue parti
window
composition
Frame
Slide 29
Esempi di aggregation e composition
Structural relationships
Slide 30
Data-flow diagrams


Si diffondono dopo la pubblicazione del testo di De Marco (‘78) su
Structured Analysis and System Specification.
Il sistema è visto come una rete, in cui i nodi rappresentano funzioni, e
gli archi il flusso di dati.
•
Le funzioni possono avere diversi livelli di astrazione e complessita’, dalla somma di due numeri
al calcolo di una tabella di stipendi, e possono anche rappresentare funzioni svolte manualmente.

Escludono la descrizione del flusso di controllo

I DFD possono essere nidificati, con nodi funzione esplosi in nuovi DFD:
in questo caso lo sviluppo avviene in modo top-down, o anche misto (topdown e bottom-up)
Quando usati in fase di Architectural Design, descrivono lo scambio dati
fra sottosistemi


Slide 31
Modelli simili a data-flow diagrams

PERT diagrams (Project Evaluation and Review Technique)
•

Activity networks
•

rappresentano esplicitamente fork e join, come Petri nets, e nodi di scelta (rombi o esagoni), come i
flow charts.
Predicate/Transition Petri nets [trattate in questo corso]
•

(Vedi [S2000], Fig. 4.6) - Simile a diagramma PERT, ma con nodi attività (funzione) e nodi
‘milestone’ (dati).
UML activity diagrams [trattate in questo corso]
•

Struttura un progetto come insieme parzialmente ordinato di attività, ciascuno con una durata (non
identifica i dati)
I predicati associati alle transizioni nella rete rappresentano funzioni; il flusso dei dati è modellato,
piu’ dettagliatamente che nei DFD, dal flusso dei token.
Dataflow algorithms/architectures [Dennis et al., 1975]
•
Il flusso di controllo è solo determinato dall’arrivo dei dati agli operatori (nodi funzione), detti
attori. Nei control-flow algorithms tradizionali, il controllo è gestito dal program counter.
Elemento comune:
ordinamento parziale delle attività (operazioni, funzioni)
Slide 32
DFD for processing an equipment order
Signed
order form
Completed
order form
Or der
details +
blank
order form
Complete
order form
Valida te
order
Signed
order form
Send to
supplier
Record
order
Order
details
Signed
order form
Checked and
signed order
+ order
notification
Adjust
available
budget
Order
amount
+ account
details
Orders
file
Budget
file
Slide 33
DFD for equipment procurement
Delivery
note
Specify
equipment
requir ed
Equipment
spec.
Checked
spec.
Validate
specification
Supplier
list
Equipment
spec.
Supplier
database
Find
suppliers
Accept
delivery of
equipment
Get cost
estimates
Spec. +
supplier +
estimate
Delivery
note
Order
notification
Choose
supplier
Order
details +
Blank order
form
Place
equipment
order
Checked and
signed or der form
Check
delivered
items
Installation
instructions
Install
equipment
Installation
acceptance
Accept
delivered
equipment
Equipment
details
Equipment
database
Slide 34
DFD for a CASE toolset
Input
design
Valid
design
Design
editor
Referenced
designs
Design
database
Checked
design
Design
cross checker
and
Design
analysis
Design
analyser
Checked
design
Code skeleton
generator
User
report
Report
generator
Output
code
Design
database
Slide 35
Data Flow Diagrams - varianti


[GJM91, sez.5.5.1]
Adatti a modellare le funzioni di sistemi informativi
Semiformali: sintassi formale, semantica informale
Function
Data-flow
Input device
Output device
Data store
Slide 36
DFD per una espressione aritmetica
(a+b) * (c + a*d)
b
a
+
d
c
*
+
*
Slide 37
DFD per sistema informativo di una biblioteca
Slide 38
DFD della biblioteca: parziale raffinamento
Slide 39
‘Limiti’ del modello DFD

La semantica di una funzione e’ tutta nel suo nome...
•
•

‘+’
‘Find Book Position’
e’ autoesplicativa
lo e’meno
Un DFD ‘arricchito’ potrebbe includere una notazione
formale per definire funzioni come FindBookPosition:
•
if author name and book title available
then
» Determine book position (if book exists;
» Otherwise print message)
•
elseif only the author name is given then
» Provide list of all books by that author and
» Ask user to select
•
elseif only the book title is given then...
Slide 40

Aspetti di controllo non specificati. Es:
•
•

L’ordine in cui le funzioni vengono eseguite
Gli eventuali segnali di controllo che attivano le funzioni
Un DFD ‘arricchito’ potrebbe includere archi di controllo
(come in Data/Control charts di VORD)
trigger
f
Slide 41

Ambiguita’ sulle configurazioni in input e output
•
in3 e out2 sono sempre necessari?
in1
in2
in3

out1
f
out2
Un DFD ‘arricchito’ potrebbe specificare modalita’ AND
oppure OR per gli output
Slide 42

Ambiguita’ sulla capacita’ dei canali di flusso
•
Sono ammesse piu’ istanze di d nel canale? (buffering)
f1
•

f2
Un DFD ‘arricchito’ potrebbe specificare per ogni canale la modalita’
di trasmissione synchronous / asynchronous
Ambiguita’ sull’effetto del flusso dei dati sui data base
•

d
(Shelves - {book} ? ListOfAuthors - {author} ?!)
Non trattamento delle eccezioni
•
estendibile come nei Data/Control charts di VORD
Slide 43