Slide 1 Lezione 6. Modelli astratti: ER, UML Class diagrams, DF [S2000, Cap. 7] [GJM91, Cap. 5]...
-
Upload
silvana-gatto -
Category
Documents
-
view
214 -
download
0
Transcript of Slide 1 Lezione 6. Modelli astratti: ER, UML Class diagrams, DF [S2000, Cap. 7] [GJM91, Cap. 5]...
Slide 1
Lezione 6. Modelli astratti: ER, UML Class diagrams, DF
• [S2000, Cap. 7]
• [GJM91, Cap. 5]
• [BRJ99, Capp. 4, 5]
Modelli astratti classificati secondo il loro orientamento a rappresentare dati/funzioni/controllo.
Entity-Relation (-Attribute) diagrams UML Class diagrams and class relationships
• dependency, generalization, association, aggregation, composition
Data-Flow diagrams
Slide 2
Feasibilitystudy
Requirementselicitation and
analysisRequirementsspecification
Requirementsvalidation
Feasibilityreport
Systemmodels
User and systemrequirements
Requirementsdocument
System models nel contesto R.E.
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 3
Sistemi = funzioni + dati + controllo
Programmi
Algoritmi
DatiAlgoritmi
Logica Controllo
Sistemi
Funzioni
Controllo
Dati
Slide 4
Relazioni fra modelli rispetto alle ‘dimensioni’ dati/funzioni
Rappresentazionedi dati e loro relazioni
Rappresentazione di funzionie loro input-output
E.R.
O-OO-O
XFSM/P.A.XFSM/P.A.
Data Flow
Usano ereditarieta’
Trattano il controllo
E. R. = Entity relationO-O = Object-Oriented (Class diagrams)XFSA = Extended Finite State MachinesP.A. = Process algebra (p.es LOTOS)
= meno formale, incompleto (black-box), Enfatizza un solo aspetto ==> adatto alla fasedei Requirements
Slide 5
Formalismi rispetto Dati/Funzioni/Controllo
FSM = Finite State MachinesXFSM = Extended FSMPN = Petri NetPr/T = Predicate/TransitionO-O = Object-Oriented DesignDFD = Data Flow DiagramsER = Entity-Relation diagramsADT = Abstract Data Types
Z
Slide 6
Expressive dimensions and model applicability
Requiremens analysis Design
Abstract models
Formal specSoftwareSpec.
LowLevel
design
HighLevel
architecture
ER (data)
DFD (function)1 dim.
FSM, PN, Basic LOTOS (Control + Function)
ADT, Z (Data + Function)2 dim.
3 dim.XFSM, Pr/T Nets, Full LOTOSO-O (Data+Function+Control),
Slide 7
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 8
Example: ERA structure of a Software Design
Design
namedescriptionC-dateM-date
Link
nametype
Node
nametype
links
has-links
12
1 n
Label
nametexticon
has-labelshas-labels
1
n
1
n
has-linkshas-nodes is-a
1
n
1
n1
1
Complementsthe DFD for theCASE toolset(slide 11)
C-date:creation date
M-Date:modification date
La freccia serve soloa facilitarela lettura della relazioneed è indipendente dalleindicazioni di molteplicità
Slide 9
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...
• Rimarrebbe poi da stabilire la mutua consistenza di link e has_links...
UK = 0
infinito
Node X Linkk
Slide 10
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 11
E-R notation [GJM91]
Relations are binary, but might have attributes too.
Proficiency
student
class
enrolledIn
NameAgeSex
SubjectCourseIdMaxEnroll
Relation is formed of pairs in student X class (or triples in student X class X scores)
Slide 12
A BR A R B is one to one
A BR A R B is one to many
A BR A R B is many to one
A BR 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
La relazione, sempre binaria, puo’ essere vincolata:
Slide 13
Notazioni di molteplicità da UML
Risolvono parte dei limiti espressivi precedenti
Ogni A e’ associato con un B
Ogni A e’ associato con uno o piu’ B
Ogni A e’ associato con zero o un B
Ogni A e’ associato con zero o piu’ B
A B
A B
A B
A B
1
1..*
0..1
*
Ammesse anche le annotazioni ‘11’ (squadra-calciatore), ‘2..4’ (canasta-giocatore), ‘2,4’ (automobile-sportello).
Slide 14
node link*2 Relazione fra nodi e link
in un design (cfr. Slide 21)
una classe deve avere almeno 5 studentie uno studente puo’ seguire al massimo 4 classi
class student5..*0..4
Slide 15
Class diagrams in UML
Descrizione di un insieme di oggetti che condividono gli stessi attributi, operazioni, relazioni, semantica.
Shape
origin
move()resize()display()
nome
attributi
operazioni
Slide 16
Attributo
Una proprietà della classe, che puo’ assumere diversi valorinelle diverse istanze della classe: in ogni istante, un oggetto di una classe avrà uno specifico valore per ogni attributo della classe.
Customer
nameaddressphonebirthDate
Wall
height: Floatwidth: Floatthickness: FloatisLoadBearing: Boolean = false
Classedell’ attributo
Valore iniziale di default
Slide 17
Operazione
Un servizio che puo’ essere richiesto a qualunque oggetto della classe, per (far) farequalcosa all’oggetto stesso, come modificare il valore di un suo attributo.
Rectangle
add()grow()move()isEmpty()
TemperatureSensor
reset()setAlarm(t: Temperature)value(): Temperature
Segnaturadell’operazione(classi degli argomenti e deirisultati)
Funzione(restituisceun valore)
Slide 18
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 19
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).
11. Identificare le entità che utenti/implementatori usano per descrivere problema/soluzione. Tecniche possibili: CRC cards, use-case-based analysis
22. Individuare e ripartire in modo bilanciato le responsabilità fra di esse:ogni entità deve fare una cosa sola, e farla bene
33. Modellare in concreto ogni ‘entitità responsabilizzata’ come una classe, con attributi e operazioni.
Slide 20
Classi per un sistema di vendita merci
Queste classi modellano entità fisiche del dominio del problema
ShipmentEntità astratta, serve a tener traccia degli spostamenti del prodotto spedito
TransactionEntità astratta, legata alla soluzione del problema
Slide 21
Distribuzione di responsabilità in Smalltalk
Model
Responsibilities-- manage the state of the model
View
Responsibilities-- render the model on the screen-- manage movement and resizing of the view-- intercept user eventsController
Responsibilities-- synchronize changes in the model and its views
Slide 22
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 23
Esempi di relazioni
Slide 24
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:
FilmClipnameplayOn(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 25
2. Generalization
X è una specializzazione di Y, o Y è una generalizzazione di X
Gli oggetti della sottoclasse (figlio) possono essere usati ovunque vengono usatiquelli della superclasse (genitore), ma non viceversaUn 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 26
Inheritance, abstract class, abstract operation
Abstract class
Abstract operation
- Una classe astratta non puo’ essereistanziata- Una operazione astratta in classe X deve essere implementata dalle sottoclassi di X
Slide 27
3. Association
CompanyPersonWorks for
Name and name direction
CompanyPersonEmployee
Role names
Employer
1..* *
Multiplicity
Association è una relazione genericaesistono due casi particolari di association: aggregation e composition
Slide 28
3.1 Aggregation
X has_a Y
Una associazione fra un ‘tutto’ e le sue ‘parti’ (whole/part), che pero’ non implicadi per sé relazioni fra le durate in vita dei due oggetti.
School
Student
1..*
Slide 29
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
Frame
composition
Slide 30
Esempi di aggregation e composition
Structural relationships
Slide 31
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 (top-down e bottom-up)
Quando usati in fase di Architectural Design, descrivono lo scambio dati fra sottosistemi
Slide 32
Modelli simili a data-flow diagrams
PERT diagrams (Project Evaluation and Review Technique)• Struttura un progetto come insieme parzialmente ordinato di attività, ciascuno con una durata (non
identifica i dati)
Activity networks • (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]• 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]• 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 33
DFD for processing an equipment order
Completeorder form
Orderdetails +
blankorder form
Valida teorder
Recordorder
Send tosupplier
Adjustavailablebudget
Budgetfile
Ordersfile
Completedorder form
Signedorder form
Signedorder form
Checked andsigned order
+ ordernotification
Orderamount
+ accountdetails
Signedorder form
Orderdetails
Slide 34
DFD for equipment procurement
Get costestimates
Acceptdelivery ofequipment
Checkdelivered
items
Validatespecification
Specifyequipmentrequired
Choosesupplier
Placeequipment
order
Installequipment
Findsuppliers
Supplierdatabase
Acceptdelivered
equipment
Equipmentdatabase
Equipmentspec.
Checkedspec.
Deliverynote
Deliverynote
Ordernotification
Installationinstructions
Installationacceptance
Equipmentdetails
Checked andsigned order form
Orderdetails +
Blank orderform
Spec. +supplier +estimate
SupplierlistEquipment
spec.
Slide 35
DFD for a CASE toolset
Designeditor
Designcross checker
Designanalyser
Reportgenerator
Designdatabase
Code skeletongenerator
Designdatabase
Inputdesign
Validdesign
Checkeddesign
Designanalysis
Userreport
and
Referenceddesigns
Checkeddesign Output
code
Slide 36
Data Flow Diagrams - varianti [GJM91, sez.5.5.1]
Adatti a modellare le funzioni di sistemi informativi Semiformali: sintassi formale, semantica informale
Function Input device Output device
Data-flow Data store
Slide 37
DFD per una espressione aritmetica
+ * +
*
b a d c
(a+b) * (c + a*d)
Slide 38
DFD per sistema informativo di una biblioteca
Slide 39
DFD della biblioteca: parziale raffinamento
Slide 40
‘Limiti’ del modello DFD La semantica di una funzione e’ tutta nel suo nome...
• ‘+’ e’ autoesplicativa
• ‘Find Book Position’ 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 41
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)
f
trigger
Slide 42
Ambiguita’ sulle configurazioni in input e output • in3 e out2 sono sempre necessari?
Un DFD ‘arricchito’ potrebbe specificare modalita’ AND oppure OR per gli output
f
in1
in2
in3
out1
out2
Slide 43
Ambiguita’ sulla capacita’ dei canali di flusso
• Sono ammesse piu’ istanze di d nel canale? (buffering)
• Un DFD ‘arricchito’ potrebbe specificare per ogni canale la modalita’ di trasmissione synchronous / asynchronous
Ambiguita’ sull’effetto del flusso dei dati sui data base• (Shelves - {book} ? ListOfAuthors - {author} ?!)
Non trattamento delle eccezioni• estendibile come nei Data/Control charts di VORD
f1 f2d