Class Design In COMET Elena Balladore. Indice Che cos’ è il Class DesignChe cos’ è il Class...
-
Upload
nerina-antonini -
Category
Documents
-
view
214 -
download
1
Transcript of Class Design In COMET Elena Balladore. Indice Che cos’ è il Class DesignChe cos’ è il Class...
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