Obiettivi della lezione

• Che cos’è la progettazione?

– Un processo che anticipa un futuro artefatto
mediante problem solving creativo
Analisi e progettazione • Quali sono le regole di buona progettazione?
• Aspetti critici nel progetto del software a oggetti
orientate agli oggetti – Analisi delle alternative
– Iterazioni (è raro azzeccarla alla prima)
– Fattorizzazioni (semplificare il design)
– Architetture di riferimento (tecnologie e standard)
• Come si impara a progettare a oggetti?

1 2

Discorso sul metodo Analisi e progettazione

• La progettazione si apprende studiando i principali
paradigmi evolutisi in relazione al progresso della L’analisi si occupa di:
tecnologia e delle applicazioni; esistono oggi • Definire la soluzione giusta per il problema giusto
parecchi paradigmi di progettazione
La progettazione si occupa di
– Metodologia
• Insieme di metodi, regole e postulati impiegati da una
• Descrivere (anticipare) una soluzione al problema
disciplina mediante un modello
• Analisi dei principi di conoscenza in un dominio specifico;
studio dei metodi di analisi di tale dominio
Un modello è una rappresentazione
– Paradigma semplificata della realtà che contiene
• Esempio, modello
• Il paradigma attualmente dominante è l’“object-oriented”
informazioni ottenute focalizzando l’attenzione
(OO), che si basa sulla costruzione di modelli su alcuni aspetti cruciali e ignorando alcuni
3 dettagli 4
 I modelli del sw richiedono più viste Perché più viste
• Un buon modello include almeno quattro viste: • La vista teleologica descrive scopo e usi del sistema
– Vista Teleologica (scopo) da progettare (eg. Documento di Marketing)
– Vista Funzionale (compiti in relazione allo scopo) • La vista funzionale descrive il comportamento di un
sistema in relazione allo scopo (eg. Casi d’uso)
– Vista Strutturale (elementi e relazioni)
• La vista comportamentale descrive il comportamento
– Vista Comportamentale (interazione dinamica tra di un sistema in relazione ai cambiamenti del suo
Funzionale e Strutturale) ambiente
Esempio: in UML abbiamo • La vista strutturale descrive i componenti di un
sistema e le loro relazioni
Use Cases Interaction Diagrams Class Diagrams
Interactions between a User Behavior of core business Basic business elements
and their relationships.
and the system. elements in process.
Le prime due viste sono “soggettive” (descrivono le
Process Description State Diagrams Deployment Diagrams intenzioni del progettista), le seconde “oggettive”
Overview of process goals, Life cycle of core system
participants and collaboration. elements in process.
Actual structure of the final system
(descrivono proprietà future del sistema)
5 6
Funzione Comportamento Struttura

Progettazione Complessità del software

• Vista “sorgente” di un’applicazione”
• Dopo l’analisi, distinguiamo almeno due theStorage

fasi di progettazione: aWarehouse

UML-A Generated Association Class:aNavPoint Association (0.5)

aRoute
(1.0)

– Progettazione architetturale
UML-A Generated Dependency Class:aRouteCollection Association (0.5)

UML-A Generated Dependency Class:aRouteCollection Association (0.25)

theVehicleCollection
UML-A Generated Association Class:aWarehouse Association (1.0)

• Decomporre il sistema in moduli aVehicle

UML-A Generated Dependency Class:theRouter Dependency (1.0)

UML-A Generated Dependency Class:theRouter Dependency (0.5)

UML-A Generated Dependency

UML-A Generated Dependency Class:theRouter
Class:theRouter
Association
UML-A UML-A (0.25)
Generated
UML-A
Generated
Association
UML-A
Generated
Association
UML-A
Generated
Class:aNavPoint
Association
Generated
UML-A
Class:aNavPoint
Association
Class:aNavPoint
Generated
Association
UML-A UML-A
Association
Class:aNavPoint
Association
Generated
Association
GeneratedClass:aNavPoint
(1.0)
Association
Dependency
(1.0)
Class:theWarehouseCollection
Association
Association (1.0)
Association
Class:aRouteCollection
(1.0) (1.0)
Class:theRouter AssociationDependency
Association
(0.25) (0.5)
(0.5) UML-A Generated Association Class:aRoute Association (0.5)
UML-AUML-A
Generated
UML-A
Generated
Association
UML-A
Generated
Association
UML-A
Generated
Class:theVehicleCollection
Association
UML-A
Generated UML-A UML-A
Class:theVehicleCollection
Association
UML-A
Generated
Class:theVehicleCollection
Association
UML-A
Generated
Generated Generated
Class:theVehicleCollection
Association Dependency
Class:theVehicleCollection
Association
Generalization
UML-A
Generated
Class:theVehicleCollection
Association
Generalization
Generated Class:theRouter
Class:theVehicleCollection
Association
Generalization
(1.0)
Class:theVehicleCollection
Association
Generalization
(1.0)
Class:theVehicleCollection
Generalization
(1.0) Dependency
Class:theVehicleCollection
Generalization
(1.0)
Generalization
(1.0)Generalization
(1.0)
Generalization (1.0) (1.0) Dependency (1.0)
(0.5)
(1.0)Generalization
(1.0)
aTruck aShip aAirplane theWarehouseCollection

• Determinare le relazioni tra i moduli

UML-A Generated Generalization Class:availableVehicleCollection Dependency (1.0) UML-A Generated UML-A Generated
Association AssociationAssociation
Class:aNavPoint Class:theWarehouseCollection
(1.0) De
UML-A
UML-A
Generated
GeneratedAssociation
Association
Class:theVehicleCollection
Class:availableVehicleCollection
Dependency
Dependency
(0.5) (0.5) UML-A Generated Association Class:theRouter Association (0.25)
UML-A Generated Dependency Class:theRouter Association (0.5)
UML-A Generated Dependency Class:theRouter Association (0.25)

UML-A Generated Dependency Class:theRouter Dependency (1.0)

UML-A Generated Dependency Class:theRouter Dependency (1.0) UML-AUML-A
Generated
Generated
Association
Association
Class:aDifficiency
Class:aDifficiency
Association
Association
(1.0) (1.0)
theRouter UML-AUML-A
Generated
Generated
UML-A Association
Association
Generated Class:aDifficiency
Class:aDifficiency
Association Association
Association
Class:aDifficiency (1.0)Association
(1.0)Association
Association (1.0) Association
UML-A UML-A
Generated
UML-A
Generated
Association
Generated
UML-AAssociation
UML-A Association
Class:aDifficiency
Generated Class:aDifficiency
Generated Class:aDifficiency
Association
Association (1.0) Association
Class:aDifficiency (1.0) (1.0)
Class:aDifficiency Association
(1.0) (1.0)
UML-A Generated Association Class:aNavPoint Association (0.25) UML-AUML-A Generated
Generated Association
Association Class:aSurplus
Class:aSurplus Association
Association (0.5) (1.0)

– Progettazione dettagliata
UML-A Generated Association Class:aNavPoint Association (0.25)
UML-A Generated AssociationAssociation
Class:aWarehouse Association (0.5)Generated
UML-A UML-A Generated Association Class:aNavPoint
(0.25) Association (0.25)
UML-A Generated Class:aWarehouse Association (1.0) Association Class:aNavPoint Association
UML-A Generated Dependency Class:theWarehouseCollection Dependency (1.0)
availableVehicleCollection aRouteCollection
UML-A Generated Dependency Class:theRouter Association (1.0)
UML-A Generated Dependency Class:theRouter Association (0.5)
UML-A Generated Association Class:theWarehouseCollection Dependency (0.5)
UML-A Generated
UML-ADependency
Generated Dependency
Class:theRouter
Class:theRouter
Association Association
(1.0) (1.0)

• Specifica delle interfacce dei moduli

theCargoRouter

UML-A Generated Association Class:theWarehouseCollection Dependency (0.25)

UML-A Generated Association Class:aRoute Association (0.5)

theAWT aLocation
UML-A Generated Association Class:theRouter Association (0.25)

• Descrizione funzionale dei moduli aVehiceDialog aWarehouseDialog aPortDialog

UML-A
UML-A
UML-A Generated
UML-A
UML-A Generated

aRouterDialog aNavPoint
UML-A Generated UML-A
Generated
Generated
Association
Generated
Association

Generated
Association
UML-A Generated Association Class:aWarehouse Association (0.5)
Association
Association
Class:aNavPoint
Association
Class:aRoute
Class:aRoute
Class:aNavPoint
UML-A Generated

AssociationAssociation
Class:aNavPoint
Association

Class:aWarehouse
(0.5)
Association
AssociationAssociation
Class:aRoute (0.5)
(0.25)
(0.25)
(0.5) (0.25)
AssociationAssociation Class:aRoute Association (0.25)

Association (0.5)

availableGoods aPortCollection theTimeNeeded

UML-A Generated
UML-A Generated Association
Association Class:aWarehouse
Class:aWarehouse Association
Association (0.5) (0.5)

UML-A Generated Association Class:aWarehouse Association (0.5)

7 UML-A Generated
UML-A
aPort

Association
Generated
aSurplus aDifficiency
UML-A Generated Association Class:aWarehouse Association (0.5)

Class:availableGoods
Association Class:aWarehouse
Association (0.5)
Association (0.5)
8
theGoods
 L’architettura permette di
Vista di “reverse engineering” controllare la complessità
• Vista architetturale Clock :
Clock

• “We can think of the 8: request

architecture of a
ClockConn

9: notification 10: notification

system as the common Warehouse DeliveryPort

7: request
Vehicle

vision that all the 4: request

1: request
3: request

workers (i.e., RouterConn

2: notification

developers and other CargoRouter

stakeholders) must 5: request

agree on or at least GraphicsConn

6: notification

9
accept” GraphicsBinding :
GraphicsBinding
10

Cosa NON è un’architettura Architettare vs integrare

• La maggior parte delle classi con Approccio tradizionale Approccio Moderno
operazioni, interfacce e attributi privati • Analisi dei Requisiti • Analisi del mercato
(nascosti) • Design • Riuso di componenti OTS
• Implementazione • Adattamento e
• Meno del 10% delle classi sono rilevanti
Integrazione
per l’architettura (l’altro 90% non è
Il processo è sequenziale
visibile)
Il processo è concorrente
• La maggior parte dei casi d’uso
• I casi di test e le procedure di test
11 12
 Elementi della progettazione Livelli di astrazione

}
• Procedure • Strutture dati e algoritmo
• Classe (strutture dati e molti algoritmi)
• Funzioni • Package/Moduli (gruppi di classi correlate, magari
• Coroutine interagenti via design pattern)
Questi diversi meccanismi • Moduli/Sottosistemi (moduli interagenti contenenti
• Processi linguistici vengono presi ciascuno molte classi; solo le interfacce pubbliche
• Moduli come elementi atomici della interagiscono con altri moduli/sottosistemi)
progettazione architetturale • Sistemi (sistemi interagenti con altri sistemi - hardware,
• Oggetti
software ed esseri umani)
• Componenti
• Agenti La progettazione architetturale riguarda gli ultimi due
13
livelli 14

Progetto semplice o
Obiettivi di progettazione
complesso?
• Semplicità
CPU con 3 chip (classi)
– Spesso si coniuga con eleganza CPU con 3 chips (classi)
– Il codice è più semplice da capire e correggere Chip 1 Chip 2
– Riduce gli errori Chip 1 Chip 2

• Affidabilità e robustezza
– Gestire input inattesi AND gates OR gates
– Superare gli errori senza crash Registers
ALU
– Non far danni ALU

• Efficacia
Chip 3
– Risolvere i problemi giusti
Shifter
SHIFTER
– Efficienza Chip 3 NOT gates

– Integrazione e compatibilità con altro software

15 16
 Progetto semplice o complesso? Coesione dei moduli
• I due progetti sono funzionalmente equivalenti, • Misura della coerenza funzionale di un
ma quello di destra è modulo
– Difficile da capire
• Ogni modulo dovrebbe avere coesione alta
– Difficile da correggere
• Un modulo ha coerenza funzionale se fa una
– Difficile da estendere o migliorare
cosa sola - e la fa bene
– Difficile da riusare.
– Costoso da manutenere • Le classi componenti di grossi moduli
dovrebbero essere funzionalmente correlate
• Il progetto di sinistra è migliore:
– Massimizza le relazioni intraclasse (coesione)
– Minimizza le relazioni interclasse (accoppiamento)
17 18

Decidere il livello di coesione

Tipi di coesione
Coincidentale Temporale Comunicativa Funzionale

Logica Procedurale

Bassa Spettro della coesione Alta

“incoerente” “coerente”

Coincidentale:
Coincidentale:Molteplici
Moltepliciazioni
azionieecomponenti
componenticompletamente
completamentescorrelati
scorrelati
Logica:
Logica:serie
seriedidiazioni
azionioocomponenti
componenticorrelate
correlate(e.g.
(e.g.libreria
libreriadidifunzioni
funzionididiIO)
IO)
Temporale:
Temporale: serie di azioni o componenti simultanee (e.g. modulididiinizializzazione)
serie di azioni o componenti simultanee (e.g. moduli inizializzazione) • Se le attività in un
Procedurale:
Procedurale:serie
seriedidiazioni
azioniche
checondividono
condividonosequenze
sequenzedidipassi
passi modulo hanno
Comunicativa:
Comunicativa:coeasione
coeasioneprocedurale
proceduralesugli
suglistessi
stessidati
dati diversi livelli di
Funzionale:
Funzionale:una
unasola
solaazione
azioneoofunzione
funzione coesione, il
modulo ha il grado
19 di livello peggiore 20
 Accoppiamento dei moduli Tipi di accoppiamento
• Accoppiamento: Misura del grado di indipendenza di un
Assenza di accoppiamento
insieme di moduli Stamp Coupling Esterno Contenuto
• I moduli di un sistema dovrebbero riportare un accoppiamento Dati Controllo Comune
basso (o lasco)
• Questo si ottiene quando ci sono solo poche dipendenze tra i
moduli, tutte funzionalmente rilevanti e necessarie Basso Spettro dell’accoppiamento Alto
• Il software ad alto accoppiamento è fatto male
(difficile da capire, mantenere, correggere, ecc…) Misura dell’indipendenza funzionale di un insieme di moduli
L’accoppiamento tra i moduli si riduce:
• eliminando relazioni non necessarie Contenuto:
Contenuto:ununmodulo
modulochechereferenzia
referenziaililcontenuto
contenutodidiununaltro
altromodulo
modulo
• riducendo il numero delle relazioni necessarie Comune:
Comune:dueduemoduli
modulihanno
hannoaccesso
accessoagli
aglistessi
stessidati
datiglobali
globali
Esterno: dati comuni tra due moduli con accesso strutturato
Esterno: dati comuni tra due moduli con accesso strutturato
• rilassando le relazioni necessarie. Controllo:
Controllo:un
unmodulo
modulopassa
passaun
unelemento
elementodidicontrollo
controlloadadun
unaltro
altromodulo
modulo
Stamp:
Stamp:ununmodulo
modulofornisce
fornisceparte
partedidiuna
unastruttura
strutturadati
datiper
perun
unaltro
altromodulo
modulo
Dati:
Dati:un
unmodulo
moduloproduce
produceunaunastruttura
strutturadati
datiper
perun
unaltro
altromodulo
moduloche chelalaconsuma
consuma
21 22

Relazioni gerarchiche tra

Gerarchia
moduli
• La gerarchia dei moduli di un sistema sw • X usa Y (dipendenza funzionale, es. call)
riduce le dipendenze vincolando la topologia
• X è_composto_da {Y,Z,W}
delle relazioni ra i moduli (scomposizione architetturale: solo le foglie sono “vero” codice)
• La struttura gerarchica dei moduli forma la • X is_a Y (ereditarietà)
base di progetto
– Decompone il dominio del problema • X has_a Y (contenimento)
– Facilita lo sviluppo parallelo
– Isola le ramificazioni di modifica e versionamento
– Permette la prototipazione rapida
23 24
 Errori progettuali più comuni
• Progettazione “depth first”
• Raffinamento diretto della specifica dei
requisiti
• Non considerare possibili modifiche
• Progettazione iperdettagliata
25
Principali linguaggi OO
• Simula (anni ’60)
• Smalltalk (fine anni ’70)
• C++ (inizio anni ’80)
• Objective C (fine anni ’80)
• Eiffel (fine anni ’80)
• Visual Basic (inizio anni ’90)
• Delphi (Object Pascal, TurboPascal, 1995)
• Java (1995)
• C# (2000)
27
OO: Storia breve
• 1967. Simula 67 - linguaggio per simulazione
• 1980. Primi linguaggi basati su oggetti. Smalltalk e
C++
• 1984. MacOs è basato su Object Pascal
• 1987. Next è interamente basato su Objective-C
• 1990. Primi metodi di analisi e progettazione basati
su oggetti: Coad, Wirfs-Brock, Booch, Rumbaugh,
Jacobson
• 1995. Java: gli oggetti vanno in rete!
• 1997: UML 1.1 diventa uno standard OMG
26
Evoluzione dei linguaggi OO
! Dahl …(1960s)…SIMULA
! Dijkstra…(1970s)…Abstraction
Parnas…(1970s)…Information Hiding
!
28
 Classi e oggetti
Una classe in Java
• I linguaggi ad oggetti includono sempre un tipo di
modulo chiamato classe, che è uno schema class Main
{
dichiarativo che definisce tipi di oggetti public static void main(String args[])
{
• La dichiarazione di classe incapsula la definizione Account paolo = new Account();
Account figaro = new Account();

dei campi e dei metodi degli oggetti creabili come double obtained;
System.out.println( "Saldo di Paolo = " +
paolo.account_balance() );
istanza della classe paolo.deposit(100.00);
System.out.println( "Saldo di Paolo = " +
mike.account_balance() );
obtained = paolo.withdraw(20.00);
System.out.println( "Paolo ha ritirato : " +
classe oggetto obtained);
System.out.println( " Saldo di Paolo = " +
paolo.account_balance() );
figaro.deposit(50.00);
System.out.println( " Saldo di Figaro = " +
figaro.account_balance() );
}
}
29 30

Terminologia
L’icona di classe in UML
• Classe. Nome collettivo (dichiarazione di tipo) di tutti gli
oggetti che hanno gli stessi metodi e variabili di istanza.
• Definisce
– Uno stato persistente • Oggetto: Entità strutturata (codice, dati) e con stato la cui
– Un comportamento struttura e stato è invisibile all’esterno dell’oggetto.
• La classe ha • Stato: Lo stato di un oggetto si accede e manipola
– Nome mediante messaggi che invocano metodi
– Attributi
• Variabili di istanza: Variabili contenute nell’oggetto che
– Operazioni
rappresentano il suo stato interno
• Ha una rappresentazione
grafica in forma di un • Messaggio Richiesta ad un oggetto di invocazione di uno
rettangolo diviso in tre parti dei suoi metodi
• Metodo Azione che accede o manipola lo stato interno
del’oggetto (di solito le variabili di istanza).
L’implementazione di tale azione è nascosta al cliente che
31 spedisce messaggi all’oggetto 32
 Metodi di analisi OO Il processo OO
I processi OOA hanno tutti la seguente
• Analisi OO: inizio di un processo di sviluppo OO struttura:
• Metodi di analisi OO: 1. Elicitazione dei requisiti
– Booch: processo evolutivo basato un “modello” astratto a 2. Identificazione di scenari e casi d’uso
oggetti
3. “Estrazione” delle classi candidate
– Rumbaugh: OMT (Object Modeling Technique) enfasi su
modelli dinamici e funzionali 4. Identificazione di attributi e metodi
– Jacobson: OOSE (Object Oriented Software Engineering) 5. Definizione di una gerarchia di classi
enfasi sui casi d’uso
6. Costruzione di un modello a oggetti e relazioni
– Coad and Yourdon: enfasi sui livelli della modellazione
– Wirfs-Brock: analisi e progetto sono un continuum
7. Costruzione di un modello di comportamento
degli oggetti
• Simili, con differenze noiose
8. Revisione dell’analisi rispetto ai casi d’uso
• Booch, Rumbaugh e Jacobson si allearono per
creare UML ed il RUP 9. Iterare se necessario
33 34

Dall’Analisi al Progetto (Pressman)

Il linguaggio di modellazione
sc e n a r i o- ba se d
e l e me n ts
f l ow- or i e n te d
Com ponent -
Lev el Design
• Un linguaggio di modellazione
permette di specificare, visualizzare e
e l e me n ts
use-cases - text data flow diagrams
use-case diagrams control-flow diagrams
activity diagrams processing narratives
swim lane diagrams

Analysis Model
Int erfa c e Design documentare un processo di sviluppo OO
c l a ss- ba se d be h a v i or a l
Arc hit ec t ura l Design
• I modelli sono strumenti di
e l e me n ts
class diagrams
analysis packages
e l e me n ts
state diagrams
sequence diagrams
comunicazione tra cliente e sviluppatori
CRC models Da t a / Cla ss Design

• I linguaggi di modellazione più usati sono

collaboration diagrams

Design Model
anche standardizzati

35 36
 Analisi = Processo + Modelli
Unified Modelling Language Processo Modello prodotto
1. Elicitazione dei requisiti Diagrammi e scenari dei casi
• UML è un sistema di notazioni principalmente grafiche d’utente e identificazione dei d’uso
(con sintassi, semantica e pragmatica predefinite) per casi d’uso
la modellazione OO 2. Estrazione delle classi Schede Classe- Responsabilità
• UML non è un processo, né è proprietario candidate, identificazione Collaboratore (CRC)
degli attributi e dei metodi,
• Combina le notazioni di Booch, Rumbaugh e Jacobson definizione della gerarchia
• E' uno standard OMG (Object Management Group) delle classi
• E' definito mediante un metamodello 3. Costruzione di un modello a Diagramma delle classi
oggetti e relazioni
• Include:
– Viste (mostrano diverse facce del sistema: utente, strutturale,
operazionale, ecc., anche in relazione al processo di sviluppo) 4. Costruzione di un modello Diagramma delle interazioni
operazionale degli oggetti
– Diagrammi (grafi che descrivono i contenuti di una vista)
– Elementi di modellazione (costrutti usati nei diagrammi)
37 38

Casi d’uso Che cos’è la progettazione

• Vista del sistema che mostra il suo comportamento
OO?
come apparirà agli utenti esterni Orientato agli oggetti:
• Partiziona le funzionalità in transazioni (‘casi d’uso’) • Decomposizione di un sistema mediante astrazioni di oggetto
significative per gli utenti (‘attori’).
• Diversa dalla decomposizione funzionale/procedurale
• Consiste di scenari - interazioni tipiche tra un utente
ed un sistema informatico
• Proprietà: OO Design, Analysis e Programming:
– Mostra funzioni visibili all’utente OOA: Esaminare e decomporre il problema… analysis
– Raggiunge obiettivi specifici pr l’utente
– Non rappresenta l’ordine o il numero di volte che una funzione OOD: Costruire un modello…design
viene eseguita OOP: realizzare il modello…programming
• Si ottiene dialogando con l’utente e il cliente
• Si usa per costruire i modelli strutturali e OOA OOD OOP Exec
operazionali e per costruire casi di test Problem System Model Program Solution
39 40
 Approccio OO
• I componenti sono classi e oggetti
Approccio funzionale (non OO) • Astrazione e incapsulamento sono i meccanismi
principali
• I componenti sono blocchi funzionali • Il sistema finale rispecchia il dominio del problema
• Astrazione e incapsulamento assenti o poveri • Concorrenza (thread multipli)
• Non modella il dominio del problema
• Sequenziale (thread singolo)

41 42

Il paradigma OO secondo G.Booch Forma canonica di un sistema OO

Oggetti
D1
! Definizione e classificazione di nozioni base
ssi
! Modelli e notazioni Cla C1

! Pragmatica D2 D3
C2 C3
! Base di UML e UP (con i “Three Amigos” di Rational)
D5
D4
C4 C5

D6

C6 C7

The three amigos:

43 44
Grady Booch, Jim Rumbaugh, Ivar Jacobson
 Principali elementi del paradigma Elementi minori del paradigma di
OO secondo Booch Booch
! Astrazione Il progettista crea le classi e Tipaggio Vincoli su classi e oggetti
gli oggetti
Concorrenza Thread multipli
! Incapsulamento Information hiding
Persistenza Oggetti che sopravvivono
! Modularità Decomposizione in moduli nello spazio e nel tempo al programma
ad accoppiamento lasco che li crea
! Gerarchia ordinamento di astrazioni
mediante ereditarietà
45 46

Diagrammi di classe secondo Booch

Il “cubo” di Booch
! Vista logica e vista fisica Classi, relazioni tra classi, utilità di classe
! Semantica statica e semantica dinamica

Sem dinamica name name

name

Sem statica
Classe
Utilità di classe
Struttura classi
Vista logica Relazioni tra classi
Struttura oggetti

Vista fisica Arch. Moduli

Arch. Processi
47 48
Relazioni tra classi nel paradigma di
Booch Associazioni
Relazioni tra oggetti contiene Company
! Job 1..!
employer employee Person

usa
Job boss
salary
0..1
worker !

Relazioni tra classi Manages

Metaclasse Person
eredita
Usa Account
{X or}

Istanza Corporation

Fig. 3-40, UML Notation Guide

49 50
Riferimento: Tutorial OMG su UML di Cris Kobryn

Composizione Generalizzazione
Shape

Window Separate Target Style

scrollbar [2]: Slider

title: Header
body: Panel
Polygon Ellipse Spline ...

Window
1
1 1
Shape
Shared Target Style
scrollbar 2 title 1 body 1

Slider Header Panel

...
Polygon Ellipse Spline

Fig. 3-45, UML Notation Guide 51 52

Fig. 3-47, UML Notation Guide
 Diagramma di classi in UML

Dipendenze
ClassA ClassB ClassD
«friend»
«friend»
operationZ()
«instantiate»

«call» ClassC

«refine»
ClassC combines
two logical classes

ClassD ClassE

Fig. 3-50, UML Notation Guide 53 54

Diagrammi degli oggetti Diagrammi dei moduli (Gradygrammi)

! Oggetti e relazioni tra oggetti: Main Subprogram Generic Subprogram

program Specification Subprogram Body
name name name name
List of msg.
name Label
label

oggetto relazioni tra oggetti

Task Task Package Generic Package
!Visibilità e sincronizzazione Specification Body Specification Package Body
name name name name name
!Object diagram templates

55 56
 Diagrammi dei processi
Aspetti linguistici degli oggetti

! Connessioni tra processore e dispositivo • Identità

• Classificazione
Processore Dispositivo • Ereditarietà
Name label
Name Name
Name • Polimorfismo
• Information hiding (incapsulamento)

! Process diagram templates

57 58

Identità
• Ogni oggetto denota i dati che gestisce
• Ogni oggetto ha una identità
possono esistere due oggetti con dati
identici e diversa identità
• L’identità degli oggetti si può realizzare con
un id unico o con una chiave (logical pointer)
• Gli oggetti vengono acceduti mediante l’id
unico
è possibile mescolare i meccanismi
59
Classificazione
• Raccolta di oggetti simili: classe
stessi attributi (variabili d’istanza)
stesse operazioni (servizi/messaggi)
• Classe: astrazione di attributi rilevanti
– le classi si riferiscono al dominio dell’applicazione
– Una classe descrive un insieme (infinite) di
oggetti = istanze della classe
60
 Esempio: classe poligono Classe vs tipo
• Tipo di dato (in senso tradizionale):
• class polygon – dominio + operazioni (e.g. Integer)
– attributi – Si usa per dichiarare variabili
• set of points • Classe:
– Costrutto linguistico, orientato all’implementazione
• line color
– Realizza uno o più tipi OO
• fill color • Tipo OO (interfaccia):
– operazioni – Protocollo compreso da un oggetto
• draw – Insieme di messaggi (operazioni)

• delete • Tipo di dato astratto:

– Specifica domini (sorte), operazioni e assiomi
• move – Nozione più astratta rispetto al tipo OO

61 62

Ereditarietà Usi dell’ereditarietà

• Uso condiviso di attributi e codice in classi diversi • Classificare le entità di un dominio
•title • Evitare ridondanze
Publication •Authors
•publ. year – Il codice identico si scrive una volta sola
•journal title • Diminuizione della dimensione del
Journal paper •Vol Book •ISBN
•issue codice
• Le sottoclassi ereditano tutte le proprietà della • Riuso del codice
superclasse

63 64
 Generalizzazione Polimorfismo
“calcola area di un cerchio”
• Classe: definizione implicita di un insieme di oggetti “calcola area di un quadrato”
classificazione – unVeicolo ! Veicolo = Insieme di tutti i veicoli
Le operazioni con lo stesso significato
• Generalizzazione: relazione di contenimento insiemistico dovrebbero avere lo stesso nome

generalizzazione
– Moto " Veicolo
• overloading =
Veicolo stesso nome di funzione, implementazione
Veicolo Moto
diversa
• Nei linguaggi procedurali (es.C):
Moto solo per i tipi base (e.g.: int * int, real * real)
una Fiat Marea
una Ducati 999F04
65 66

Information hiding Responsibility-Driven Design

• Nascondere i dettagli inessenziali
• Accesso solo mediante le operazioni
predefinite
• Tecnica in cui le responsabilità di un oggetto guidano il suo design
• Si concentra sul ruolo di un oggetto e su come il suo comportamento
influenza gli altri oggetti
• Se si comincia dalle responsabilità di un oggetto poi è più semplice
– Creare la sua interfaccia pubblica (come il mondo esterno accede le sue
funzioni)
– Progettare il suo funzionamento interno
– Tener conto degli eventi da esso riconosciuti

• Prospettive di modellazione (Rebecca Wirfs-Brock)

Esempio: Prospettive di un cavallo
getArea() a value
• Vista strutturale: ha un corpo, una coda, quattro zampe
(componenti)
black box
• Vista comportamentale: cammina, mangia, emette versi (attività)
• Vista delle responsabilità: trasporta persone o merci, corre negli
67 ippodromi (scopo entro un sistema)
68
 Progettazione guidata dalle
Esempio
responsabilità
Le responsabilità di una classe si classificano • Una festa
come: – Quali sono gli oggetti?
• Padroni di casa Person (superclass)
• Conoscere • Ospiti
– A quali domande deve rispondere? • Invito
– Indirizzo
• Fare » Della festa
» Dell’ospite
– Quali operazioni deve eseguire? – Data
• Applicare – Tema
• Cibo e bevande
– Quali regole deve applicare e/o imporre? • Musica
69 70

Esempio Approccio
– Quali sono i metodi? • Definire il problema
• comprare • Creare gli scenari d’uso
• cucinare – Mediante interviste
• invitare – Concentrarsi sulel operazioni principali
– occorre la lista degli (oggetti) invitati
• Usare le schede CRC
• pulire la casa
– Oggetti
• RSVP • Iniziare con quelli più importanti
• andare alla festa – Responsabilità
– Quali sono le responsabilità dei vari • Le cose principali che fanno gli oggetti più importanti
oggetti? – Relazioni con altri oggetti
71 72
 Schede CRC CRC Card
• Classe, Responsabilità, Collaborazione
– responsabilità: compiti da eseguire
– collaborazioni: altri oggetti che cooperano con questo

Class name: Superclasse: Sottoclassi: Class name: Superclass: Subclasses:

Padrone Persona
Responsabilità: Collaborazioni: Responsibilities: Collaborations:

Invita Invito, Persona, Lista

Compra Denaro, Negozio, Cibo, …
Pulisce_casa Spugna, Straccio, …
73 74

CRC Card Da CRC a UML

• Le schede CRC definiscono le classi
principali e le loro interazioni
Class name: Superclass: Subclasses: – Strumento di brainstorming
Ospite Persona – Se ne scrivono tante, se ne buttano tante
Responsibilities: Collaborations:
• UML
RSVP Telefono, Padrone
– Per raffinare il progetto
– Per descrivere il progetto ad altri

75 76
 UML: Unified Modeling Language
I tre passi del progetto OO
• Tre passi iterabili
• Notazione per progetto OO 1. Modellazione dei casi d’uso
• Associata ad un metodo • Determinare come si ottengono i risultati principali
• Parecchi tipi di diagrammi • Orientata alle azioni
• Tecnica: linguaggio naturale
– Diagrammi di classe 2. Modellazione delle classi (e degli oggetti)
• Struttura statica
• Determinare le classi con attributi e relazioni
• Orientata ai dati
– Diagrammi Casi d’Uso
• Funzionalità • Tecnica: schede CRC e poi diagrammi UML di classe
3. Modellazione dinamica
– Diagrammi di sequenza • Determinare le azioni eseguite da o su ciascuna classe
• Vista temporale dello scambio di messaggi tra • Orientata alle azioni
le classi • Tecnica: diagrammi di sequenza e interazione
77 78

Riferimenti
Il design del sw nel SWEBOK • Capitolo 3 del SWEBOK “Software design”
Software Design • IEEE Recommended Practice for Software Design
Descriptions (IEEE 1016-1998)
1. Software Design
Fundamentals
2. Key Issues in
Software Design
3. Software Structure
and Architecture
4. Software Design
Quality Analysis and
5. Software
Design Notations
6. Software Design
Strategies and
• Booch, Object oriented analysis and design with
Evaluation Methods
applications, AW 1993
General design Quality attributes Structural General Strategies
Concurrency Architectural
concepts

The context of Control and handling

structures and
viewpoints
Quality analysis and
descriptions
(static view)
Function-oriented
• Wirfs-Brock and Mckean, Object Design: Roles,
software design

The software design

of events

Distribution of
Architectural styles
(macroarchitectural
patterns)
evaluation techniques Behavior descriptions
(dynamic view)
(structured) design

Object-oriented
Responsibilities and Collaborations, AW 2002
process components Measures design
Error and exception Design patterns
handline and fault (microarchitectural Data-structrure
Enabling techniques tolerance patterns) centered design
Interaction and Component-based
presentation Families of programs design (CBD)
and frameworks
Data persistence
Other methods

Figure 1 Breakdown of topics for the Software Design KA

79 80
Domande?

81