balladore

Class Design
In COMET
Elena Balladore
Indice
 Che cos’ è il Class Design
 Design delle information hiding classes
 Design delle operazioni di una classe
 Inheritance nel Design
•
•
Gerarchia delle classi
Classi astratte
 Class Interface Specification
Che cos’è il Class Design
Fase di Class Design:
si progettano le information hiding
classes e le operazioni
Information hiding:
Un oggetto incapsula le decisioni a livello
software design
 L’interfaccia dell’oggetto rivela solo le
informazioni necessarie a chi usa la classe

Si considerano oggetti passivi
indice
Design delle Information
Hiding Classes
Information hiding classes:
 Divise
in categorie secondo stereotipi
 Documentate attraverso Class Interface
Specification
Design delle Information
Hiding Classes
Nel Design le classi sono determinate
dal:
 Problem
domain
entity classes, interface classes, control
classes, application logic classes
introdotte nell’analysis model
 da rivedere nel Design

 Solution
domain
software decision classes
Design delle Information
Hiding Classes
Software decision classes:
•Determinate nella fase di design
•Nascondono le decisioni prese dai
software designers
indice
Design delle operazioni
Operazioni determinate mediante
 Interaction
Model
 Finite State Machine Model
 Static Model
Meglio usare il dynamic model
Design delle operazioni:
usando Interaction Model
Quali oggetti invocano le operazioni e
quali devono fornirle
Dynamic Interaction Model:
Fornisce la DIREZIONE in cui un
oggetto spedisce un messaggio ad
un altro oggetto
Design delle operazioni:
usando Interaction Model
Da interaction diagram A Class diagram
messaggio
nome messaggio
parametri messaggio
chiamata operazione
nome operazione
parametri operazione
Design delle operazioni:
usando Interaction Model
Analysis Model versus Design Model:
 Analysis
model:
 Enfasi
sulle informazioni passate tra gli oggetti
 Messaggi senza indicazione dei parametri
 Design
model:
 Specifico
le operazioni usando messaggi sincroni
 Specifico i parametri
Usando Interaction Model: esempio
Data Abstraction Class
Analysis model: entity class
Design model: data abstraction class
Attributi: decisi nello static model
Operazioni: si considera come
accedere ai dati memorizzati nella
classe
Usando Interaction Model: esempio
Data Abstraction Class
<<user
interface>>
Analysis model:
collaboration diagram
:OperatorInterface
Cash
Added
<<device
interface>>
Cash Withdrawl
Amount
<<entity>>
:CashDispenser
Interface
:ATMCash
Cash Response
Usando Interaction Model: esempio
Data Abstraction Class
Design model:
collaboration diagram
<<device
interface>>
:CashDispenser
Interface
withdrawCash (in
CashAmount, out
fivesToDispense, out
tensToDispense, out
twentiesToDispense)
<<user
interface>>
:OperatorInterface
addCash
(fivesAdded,
tensAdded,
twentiesAdded)
<<data
abstraction>>
:ATMCash
Usando Interaction Model: esempio
Data Abstraction Class
Design Model:
class diagram
<<data abstraction>>
ATMCash
- cashAvailable: Integer = 0
- fives: Integer = 0
- tens: Integer = 0
Esempio2
- twenties: Integer = 0
+ WithdrawCash (in CashAmount, out
fivesToDispense, out tensToDispense, out
twentiesToDispense)
Interaction model:
ulteriori esempi
+ AddCash (in fivesAdded, in tensAdded, in
twentiesAdded)
Design delle operazioni:
Usando Finite State Machine
Model
Uso di statechart diagram (oltre a
collaboration diagram)
 Statechart
contiene attività e azioni che
diventano operazioni
Per individuare le operazioni si può
usare soltanto un collaboration diagram
Usando Finite State Machine Model:
esempio
State-Dependent Class
Statechart, eseguito da un oggetto
state-dependent, è trasformato in una
STATE TRANSITION TABLE
State-Dependent Class:
 nasconde
il contenuto di una state
transition table
 mantiene lo stato corrente di un oggetto
Usando Finite State Machine Model:
esempio
State-Dependent Class
Operazioni per:
 accedere alla state transition table
 processare gli eventi
 Una
operazione per ogni evento oppure
 Uso di due operazioni prestabilite:
processEvent
currentState
Usando Finite State Machine M.: es.
State-Dependent Class
<<device
interface>>
:startCalibration
ButtonInterface
<<device
interface>>
Ca1.1:Calibration
Start
<<state dependent
control>>
:CalibrationControl
Ca2.1:Calibration
Stop
:stopCalibration
ButtonInterface
Analysis model: collaboration
diagram
Ca1.2: Start,
Ca2.2: Stop
<<entity>>
:Calibration
Constant
Usando Finite State Machine M.: es.
State-Dependent Class
Analysis model:
Statechart
dell’oggetto
CalibrationControl
Not Measuring
Ca1.1:Calibration Start/
Ca1.2:Start
Ca2.1:Calibration Stop/
Ca2.2:Stop
Measuring Mile
Calibration Start/Stop
Usando Finite State Machine M.: es.
State-Dependent Class
<<device
interface>>
:startCalibration
ButtonInterface
<<device
interface>>
processEvent
(calibrationStart)
processEvent
(calibrationStop)
<<state dependent
control>>
:CalibrationControl
start(),stop()
:stopCalibration
ButtonInterface
<<data
abstraction>>
Design model: collaboration
diagram
:Calibration
Constant
Usando Finite State Machine M.: es.
State-Dependent Class
<<data abstraction>>
CalibrationConstant
<<state dependent control>>
CalibrationControl
+ processEvent(event)
+ currentState(): State
+ start()
+ stop()
Design Model: class diagram
Design delle operazioni:
usando Static Model
Utilizzato soprattutto per le entity
classes, che contengono delle
operazioni standard
Usando Static Model: esempio
Database Wrapper Class
Analysis model: entity class
Design:
 Dati
manipolati direttamente dalla classe
Data Abstraction Class
 Dati inseriti in un database
Database Wrapper Class
Usando Static Model: esempio
Database Wrapper Class
Da Entity Class
A Database
Attributi
Operazioni
Relazione
DB Wrapper Class
(per accedere agli attributi)
Associazioni
chiavi esterne
(del class diagram)
Nel database si devono determinare le
chiavi primarie
Usando Static Model: esempio
Database Wrapper Class
<<entity>>
DebitCard
cardID:String
PIN: String
startDate: Date
expirationDate:Date
Status: Integer
Limit:Real
Total: Real
Analysis model
Usando Static Model: esempio
Database Wrapper Class
In the relational
database:
DebitCard (cardID,
PIN, startDate,
exDate,status, limit,
total, customerSSN )
Design model
indice
<<database wrapper>>
DebitCard
+ create(cardID)
+ validate(cardID)
+ updatePIN(cardID, PIN)
+ checkDailyLimit(cardID, amount)
+ updateDailyTotal(cardID, amount)
+ updateExpirationDate(cardID, exDate)
+ updateCardStatus(cardID, status)
+ updateDailyLimit(cardID, newLimit)
+ clearTotal(cardID)
+ delete(cardID)
+ read(in cardID, out PIN, out exDate,
out status, out limit, out total)
Inheritance nel Design
Inheritance:
 meccanismo
per condividere e riusare il
codice tra le classi
 usata quando si progettano due o più
classi simili
Vantaggio:
facilita la generazione e la maintenance del
codice
Inheritance nel Design:
Gerarchie di Classi
Chiamate anche gerarchie di
generalizzazione/specializzazione
e gerarchie di inheritance
Due approcci per determinare una
gerarchia:
 Top-down
 Bottom-up
Inheritance nel Design:
gerarchie di classi
Difetti:
 Inheritance
viola il concetto di
information hiding
 Le gerarchie di classi non devono
avere troppi livelli
Inheritance nel Design:
classi astratte
Classe astratta:
 una
classe senza istanze
 Usata come modello per creare
sottoclassi
Operazione astratta:
 operazione
dichiarata in una classe
astratta, ma non implementata
Una classe astratta deve avere almeno
una operazione astratta
Superclasses and Subclasses:esempio
Account
#accountNum: Integer
#balance: Real=0
+ open(accountNum: Integer)
+ credit(amount: Real)
+ debit(amount: Real)
+ readBalance(): Real
+ close()
SavingsAccount
CheckingAccount
- lastDepositAmount = 0
+ readLastDepositAmount() : Real
indice
-cumulativeInterest: Real = 0
-debitCount: Integer = 0
+debit(amount: Real)
+clearDebitCount()
+addInterest(interestRate: Real)
+readCumulativeInterest():Real
Class Interface Specification
Definisce:
 l’interfaccia
della Information Hiding Class
 la specifica delle operazioni fornite dalla
classe
In particolare:
Le
informazioni nascoste dalla classe
Il tipo della classe
Le assunzioni fatte nello specificare la classe
I cambiamenti possibili
La superclasse
Le operazioni ereditate e fornite dalla classe
Class Interface Specification:esempio
Classe:
<<data abstraction>>
SensorActuatorRepository
+ readSensor (in sensorID, out sensorValue)
+ updateActuator (in actuatorID, in actuatorValue)
+ updateSensor(in sensorID, in sensorValue)
+ readActuator (in actuatorID, out actuatorValue)
Class Interface Specification:esempio
Classe: SensorActuatorRepository
Informazioni nascoste: strutture dati per sensori e
attuatori
Tipo di classe: Data Abstraction Class
Assunzioni: le operazioni devono essere accedute
in modo concorrente
Cambiamenti possibili: attualmente sono
considerati solo sensori e attuatori a valori booleani.
Sono possibili delle estensioni
Superclassi: nessuna
Class Interface Specification:esempio
Operazioni ereditate: nessuna
Operazioni fornite:


readSensor (in sensorID, out sensorValue)
 Funzione: dato l’ID di un sensore, ritorna il valore
corrente
 Precondizione: il valore del sensore è stato
aggiornato
 Invariante: il valore del sensore non viene cambiato
 Postcondizione: il valore del sensore è stato letto
 Parametri in input: sensorID
 Parametri in output: sensorValue
 Operazioni di altre classi usate: nessuna
Analogamente per la altre operazioni
indice