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 DesignFase 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 passiviindice

Design delle Information Hiding Classes

Information hiding classes:Divise in categorie secondo stereotipiDocumentate 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 modelda rivedere nel Design

Solution domainsoftware 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 medianteInteraction ModelFinite State Machine ModelStatic 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 chiamata operazione

nome messaggio nome operazione

parametri messaggio parametri operazione

Design delle operazioni: usando Interaction Model

Analysis Model versus Design Model:Analysis model:

Enfasi sulle informazioni passate tra gli oggettiMessaggi senza indicazione dei parametri

Design model: Specifico le operazioni usando messaggi sincroniSpecifico 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

<<device interface>>

:CashDispenser

Interface

<<user interface>>

:OperatorInterface

<<entity>>

:ATMCash

Analysis model: collaboration diagram

Cash

Added

Cash Withdrawl Amount

Cash Response

Usando Interaction Model: esempio Data Abstraction Class

<<device interface>>

:CashDispenser

Interface

<<user interface>>

:OperatorInterface

<<data abstraction>>

:ATMCash

Design model: collaboration diagram

addCash (fivesAdded, tensAdded, twentiesAdded)

withdrawCash (in CashAmount, out fivesToDispense, out tensToDispense, out twentiesToDispense)

Usando Interaction Model: esempio Data Abstraction Class

<<data abstraction>> ATMCash

- cashAvailable: Integer = 0

- fives: Integer = 0

- tens: Integer = 0

- twenties: Integer = 0

+ WithdrawCash (in CashAmount, out fivesToDispense, out tensToDispense, out twentiesToDispense)

+ AddCash (in fivesAdded, in tensAdded, in twentiesAdded)

Design Model: class diagram

Esempio2

Interaction model: ulteriori esempi

Design delle operazioni: Usando Finite State Machine

ModelUso 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 tablemantiene lo stato corrente di un oggetto

Usando Finite State Machine Model: esempio

State-Dependent Class

Operazioni per: accedere alla state transition tableprocessare gli eventi

Una operazione per ogni evento oppureUso di due operazioni prestabilite:

processEvent

currentState

Usando Finite State Machine M.: es. State-Dependent Class

<<device interface>>

:startCalibration ButtonInterface

<<state dependent control>>

:CalibrationControl

<<entity>>

:Calibration Constant

Analysis model: collaboration diagram

Ca1.2: Start, Ca2.2: Stop<<device

interface>>

:stopCalibration ButtonInterface

Ca1.1:Calibration Start

Ca2.1:Calibration Stop

Usando Finite State Machine M.: es. State-Dependent Class

Not Measuring

Measuring Mile

Ca1.1:Calibration Start/Ca1.2:Start

Ca2.1:Calibration Stop/Ca2.2:Stop

Calibration Start/Stop

Analysis model: Statechart dell’oggetto CalibrationControl

Usando Finite State Machine M.: es. State-Dependent Class

<<device interface>>

:startCalibration ButtonInterface

<<state dependent control>>

:CalibrationControl

<<data abstraction>>

:Calibration Constant

Design model: collaboration diagram

start(),stop()<<device interface>>

:stopCalibration ButtonInterface

processEvent (calibrationStart)

processEvent (calibrationStop)

Usando Finite State Machine M.: es. State-Dependent Class

<<state dependent control>> CalibrationControl

+ processEvent(event)

+ currentState(): State

Design Model: class diagram

<<data abstraction>>

CalibrationConstant

+ start()+ stop()

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 DatabaseAttributi RelazioneOperazioni 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

Analysis model

<<entity>>DebitCard

cardID:StringPIN: StringstartDate: DateexpirationDate:DateStatus: IntegerLimit:RealTotal: Real

Usando Static Model: esempio Database Wrapper Class

Design model

<<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)

In the relational database:

DebitCard (cardID, PIN, startDate, exDate,status, limit, total, customerSSN )

indice

Inheritance nel DesignInheritance: 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-downBottom-up

Inheritance nel Design:gerarchie di classi

Difetti:Inheritance viola il concetto di

information hidingLe gerarchie di classi non devono

avere troppi livelli

Inheritance nel Design: classi astratte

Classe astratta:una classe senza istanzeUsata 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:esempioAccount

#accountNum: Integer#balance: Real=0+ open(accountNum: Integer)+ credit(amount: Real)+ debit(amount: Real)+ readBalance(): Real+ close()

CheckingAccount- lastDepositAmount = 0

+ readLastDepositAmount() : Real

SavingsAccount-cumulativeInterest: Real = 0-debitCount: Integer = 0+debit(amount: Real)+clearDebitCount()+addInterest(interestRate: Real)+readCumulativeInterest():Real

indice

Class Interface SpecificationDefinisce:l’interfaccia della Information Hiding Class la specifica delle operazioni fornite dalla

classeIn particolare:

Le informazioni nascoste dalla classe Il tipo della classeLe assunzioni fatte nello specificare la classeI cambiamenti possibiliLa superclasseLe operazioni ereditate e fornite dalla classe

Class Interface Specification:esempio

<<data abstraction>>SensorActuatorRepository

+ readSensor (in sensorID, out sensorValue) + updateActuator (in actuatorID, in actuatorValue)+ updateSensor(in sensorID, in sensorValue) + readActuator (in actuatorID, out actuatorValue)

Classe:

Class Interface Specification:esempioClasse: 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:esempioOperazioni 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 cambiatoPostcondizione: il valore del sensore è stato lettoParametri in input: sensorIDParametri in output: sensorValueOperazioni di altre classi usate: nessuna

Analogamente per la altre operazioniindice