Class Design In COMET Elena Balladore Indice Che
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 L’interfaccia dell’oggetto rivela solo le informazioni necessarie a chi usa la classe l Si considerano oggetti passivi indice
Design delle Information Hiding Classes Information hiding classes: l Divise in categorie secondo stereotipi l Documentate attraverso Class Interface Specification
Design delle Information Hiding Classes Nel Design le classi sono determinate dal: l Problem domain entity classes, interface classes, control classes, application logic classes l introdotte nell’analysis model l da rivedere nel Design l 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 l Interaction Model l Finite State Machine Model l 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: l Analysis model: l Enfasi sulle informazioni passate tra gli oggetti l Messaggi senza indicazione dei parametri l Design model: l Specifico le operazioni usando messaggi sincroni l 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 : Operator. Interface Cash Added <<device interface>> Cash Withdrawl Amount : Cash. Dispenser Interface <<entity>> : ATMCash Response
Usando Interaction Model: esempio Data Abstraction Class Design model: collaboration diagram <<device interface>> : Cash. Dispenser Interface withdraw. Cash (in Cash. Amount, out fives. To. Dispense, out tens. To. Dispense, out twenties. To. Dispense) <<user interface>> : Operator. Interface add. Cash (fives. Added, tens. Added, twenties. Added) <<data abstraction>> : ATMCash
Usando Interaction Model: esempio Data Abstraction Class Design Model: class diagram <<data abstraction>> ATMCash - cash. Available: Integer = 0 - fives: Integer = 0 - tens: Integer = 0 Esempio 2 - twenties: Integer = 0 + Withdraw. Cash (in Cash. Amount, out fives. To. Dispense, out tens. To. Dispense, out twenties. To. Dispense) Interaction model: ulteriori esempi + Add. Cash (in fives. Added, in tens. Added, in twenties. Added)
Design delle operazioni: Usando Finite State Machine Model Uso di statechart diagram (oltre a collaboration diagram) l 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: l nasconde il contenuto di una state transition table l mantiene lo stato corrente di un oggetto
Usando Finite State Machine Model: esempio State-Dependent Class Operazioni per: l accedere alla state transition table l processare gli eventi l Una operazione per ogni evento oppure l Uso di due operazioni prestabilite: process. Event current. State
Usando Finite State Machine M. : es. State-Dependent Class <<device interface>> : start. Calibration Button. Interface <<device interface>> Ca 1. 1: Calibration Start <<state dependent control>> : Calibration. Control Ca 2. 1: Calibration Stop : stop. Calibration Button. Interface Analysis model: collaboration diagram Ca 1. 2: Start, Ca 2. 2: Stop <<entity>> : Calibration Constant
Usando Finite State Machine M. : es. State-Dependent Class Analysis model: Statechart dell’oggetto Calibration. Control Not Measuring Ca 1. 1: Calibration Start/ Ca 1. 2: Start Ca 2. 1: Calibration Stop/ Ca 2. 2: Stop Measuring Mile Calibration Start/Stop
Usando Finite State Machine M. : es. State-Dependent Class <<device interface>> : start. Calibration Button. Interface <<device interface>> process. Event (calibration. Start) process. Event (calibration. Stop) : stop. Calibration Button. Interface Design model: collaboration diagram <<state dependent control>> : Calibration. Control start(), stop() <<data abstraction>> : Calibration Constant
Usando Finite State Machine M. : es. State-Dependent Class <<data abstraction>> Calibration. Constant <<state dependent control>> Calibration. Control + process. Event(event) + current. State(): 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: l Dati manipolati direttamente dalla classe Data Abstraction Class l 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>> Debit. Card card. ID: String PIN: String start. Date: Date expiration. Date: Date Status: Integer Limit: Real Total: Real Analysis model
Usando Static Model: esempio Database Wrapper Class In the relational database: Debit. Card (card. ID, PIN, start. Date, ex. Date, status, limit, total, customer. SSN ) Design model indice <<database wrapper>> Debit. Card + create(card. ID) + validate(card. ID) + update. PIN(card. ID, PIN) + check. Daily. Limit(card. ID, amount) + update. Daily. Total(card. ID, amount) + update. Expiration. Date(card. ID, ex. Date) + update. Card. Status(card. ID, status) + update. Daily. Limit(card. ID, new. Limit) + clear. Total(card. ID) + delete(card. ID) + read(in card. ID, out PIN, out ex. Date, out status, out limit, out total)
Inheritance nel Design Inheritance: l meccanismo per condividere e riusare il codice tra le classi l 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: l Top-down l Bottom-up
Inheritance nel Design: gerarchie di classi Difetti: l Inheritance viola il concetto di information hiding l Le gerarchie di classi non devono avere troppi livelli
Inheritance nel Design: classi astratte Classe astratta: l una classe senza istanze l Usata come modello per creare sottoclassi Operazione astratta: l operazione dichiarata in una classe astratta, ma non implementata Una classe astratta deve avere almeno una operazione astratta
Superclasses and Subclasses: esempio Account #account. Num: Integer #balance: Real=0 + open(account. Num: Integer) + credit(amount: Real) + debit(amount: Real) + read. Balance(): Real + close() Checking. Account - last. Deposit. Amount = 0 + read. Last. Deposit. Amount() : Real indice Savings. Account -cumulative. Interest: Real = 0 -debit. Count: Integer = 0 +debit(amount: Real) +clear. Debit. Count() +add. Interest(interest. Rate: Real) +read. Cumulative. Interest(): Real
Class Interface Specification Definisce: l l’interfaccia della Information Hiding Class l la specifica delle operazioni fornite dalla classe In particolare: l. Le informazioni nascoste dalla classe l. Il tipo della classe l. Le assunzioni fatte nello specificare la classe l. I cambiamenti possibili l. La superclasse l. Le operazioni ereditate e fornite dalla classe
Class Interface Specification: esempio Classe: <<data abstraction>> Sensor. Actuator. Repository + read. Sensor (in sensor. ID, out sensor. Value) + update. Actuator (in actuator. ID, in actuator. Value) + update. Sensor(in sensor. ID, in sensor. Value) + read. Actuator (in actuator. ID, out actuator. Value)
Class Interface Specification: esempio Classe: Sensor. Actuator. Repository 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: l l read. Sensor (in sensor. ID, out sensor. Value) l Funzione: dato l’ID di un sensore, ritorna il valore corrente l Precondizione: il valore del sensore è stato aggiornato l Invariante: il valore del sensore non viene cambiato l Postcondizione: il valore del sensore è stato letto l Parametri in input: sensor. ID l Parametri in output: sensor. Value l Operazioni di altre classi usate: nessuna Analogamente per la altre operazioni indice
- Slides: 35