Class Design In COMET Elena Balladore
Indice Che cos’ è il Class DesignChe 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 operazioniinformation hiding classes 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 passivioggetti passivi indice
Oggetto passivo Oggetto che non ha un thread di controllo. Contiene delle operazioni che possono essere invocate da altri oggetti, sia attivi che passivi.
Information Hiding Class Strutturata in accordo con il concetto di information hiding Può essere acceduta attraverso delle operazioni
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 classesentity classesinterface classescontrol classesapplication 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 Information Hiding Classes Entity classes : Contengono dei dati Nel Design si dividono in: 1. DATA ABSTRACTION CLASSES: contengono strutture dati 2. WRAPPER CLASSES: nascondono i dettagli sulla comunicazione con sistemi esterni (dove sono contenuti i dati)
Design delle Information Hiding Classes Interface classes : interfaccia verso l’ambiente esterno Sono divise in: 1.SYSTEM INTERFACE CLASSES (sistema esterno) 2.USER INTERFACE CLASSES (utente umano) 3.DEVICE INTERFACE CLASSES (I/O)
Design delle Information Hiding Classes Control classes : coordinano un insieme di oggetti che fanno parte di uno use case Sono divise in: 1.STATE-DEPENDENT CLASSES 2.COORDINATOR CLASSES 3.TIMER CLASSES
Design delle Information Hiding Classes Application logic classes : contengono algoritmi e business logic rules relative ad una applicazione specifica Si dividono in: 1.BUSINESS LOGIC CLASSES 2.ALGORITHM CLASSES
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 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 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 > :CashDispenser Interface > :OperatorInterface > :ATMCash Analysis model: collaboration diagram Cash Added Cash Withdrawl Amount Cash Response
Usando Interaction Model: esempio Data Abstraction Class > :CashDispenser Interface > :OperatorInterface > :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 > 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 ulteriori esempi
Usando Interaction Model: esempio Data Abstraction Class(2) > :CardReader Interface > :ATMCard > :CustomerInterface Analysis model: collaboration diagram Card Data Card Request Card Input Data
Usando Interaction Model: esempio Data Abstraction Class(2) > :CardReader Interface > :ATMCard > :CustomerInterface Design model: collaboration diagram read(out cardData) write(cardData)
Usando Interaction Model: esempio Data Abstraction Class(2) > ATMCard - cardNumber:Integer - startDate:Date - expirationDate:Date + write(in cardData) + read(out cardData) Design Model: class diagram
Usando Interaction Model: esempio Device Interface Class Interfaccia virtuale che nasconde l’interfaccia reale usata verso il dispositivo di I/O nel mondo esterno Isola dai cambiamenti del mondo reale Nasconde le decisioni prese a livello design di come interagire con uno specifico dispositivo di I/O
Usando Interaction Model: esempio Device Interface Class Design delle operazioni: Operazioni per leggere e/o scrivere sul dispositivo Operazioni caratteristiche del device Operazione initialize: per inizializzare il dispositivo e le variabili interne usate dalla classe
Usando Interaction Model: esempio Input Device Interface Class > :TripFuel Consumption > :GasTank > :GasTankInterface Analysis model: collaboration diagram Fuel Input Read Fuel Amount Fuel Amount Read Hw/Sw boundary
Usando Interaction Model: esempio Input Device Interface Class > :TripFuel Consumption > :GasTank > :GasTankInterface Design model: collaboration diagram read (out fuelInput) Hw/Sw boundary read (out fuelAmount)
Usando Interaction Model: esempio Input Device Interface Class > GasTankInterface - fuelLevel: Real + initialize () +read (out fuelAmount) Design Model: class diagram
Usando Interaction Model: esempio Output Device Interface Class > :TripSpeed > :TripDisplay Interface > :TripDisplay Analysis model: collaboration diagram Mileage Display Data Hw/Sw boundary > :TripFuel Consumption Average Speed Average Fuel Consumption
Usando Interaction Model: esempio Output Device Interface Class > :TripSpeed > :TripDisplay Interface > :TripDisplay Design model: collaboration diagram mileage Display Data Hw/Sw boundary > :TripFuel Consumption displayAvSpeed(speed) displayAvFuelCons (fuelCons)
Usando Interaction Model: esempio Output Device Interface Class > TripDisplayInterface -averageSpeed: Real - averageFuelConsumption: Real + initialize () + displayAvSpeed(speed) + displayAvFuelCons(fuelCons) Design Model: class diagram Oltre alle interfacce verso i dispositivi esterni, esistono le interfacce verso l’utente del sistemainterfacce verso l’utente
User Interface Class Nasconde i dettagli dell’interfaccia usata verso l’utente Una interfaccia utente è: Una linea di comando gestita da una User Interface Class Una GUI (Graphical User Interface) gestita da più User Interface Classes
User Interface Class:esempio > Customer GUI + displayPINWindow(out PIN) + displayWithdrawalWindow(out AccountNum, out amount) + displayTransferWindow(out fromAccountNum, out to Account Num, out amount) + displayQueryWindow(out AccountNum) + displayMenu(out selection) + displayPrompt(out promptText) User Interface Class con le operazioni
User Interface Class:esempio Struttura di una Composite User Interface Class > Customer GUI > PIN Window > Menu Window > Withdrawal Window > Query Window > Transfer Window > Prompt Window
Usando Interaction Model: esempio Algorithm Class Contiene un algoritmo usato nel dominio applicativo e i dati locali necessari a quest’ultimo Usate nei sistemi real-time e nelle applicazioni scientifiche
Usando Interaction Model: esempio Algorithm Class > :TripSpeedTimer > :TripSpeed > :TripDisplay Interface Analysis model: collaboration diagram Average Speed > :MileageReset Button Calculate Reset
Usando Interaction Model: esempio Algorithm Class > :TripSpeedTimer > :TripSpeed > :TripDisplay Interface Design model: collaboration diagram display (avSpeed) > :MileageReset Button calculate() reset()
Usando Interaction Model: esempio Algorithm Class > TripSpeed -initialDistance: Real - initialTime: Real + reset() + calculate() Design Model: class diagram
Usando Interaction Model: esempio Business Logic Class Contiene le business logic rules, cioè delle procedure specifiche legate alla particolare applicazione sviluppata e alle richieste del cliente
Usando Interaction Model: esempio Business Logic Class Analysis model: collaboration diagram > :BankTransaction Server > :Withdrawal TransactionManager Withdraw, Confirm, Abort Withdraw Response
Usando Interaction Model: esempio Business Logic Class Design model: collaboration diagram > :BankTransaction Server > :Withdrawal TransactionManager withdraw(in accountNum, in amount, out response), confirm(accountNum, amount), abort(accountNum, amount),
Interaction Model: esempio Business Logic Class > WithdrawalTransactionManager + initialize( ) + withdraw(in accountNum, in amount, out response) +confirm(accountNum, amount) +abort(accountNum, amount) Design Model: class diagram
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 TABLEoggetto state-dependent STATE TRANSITION TABLE State-Dependent Class : nasconde il contenuto di una state transition table mantiene lo stato corrente di un oggetto
State-Dependent object Oggetto che nasconde i dettagli di una Finite State Machine, cioè un oggetto che contiene uno statechart È un’istanza di una state-dependent class
State Transition Table È una rappresentazione tabulare di una Finite State Machine Per ogni combinazione (stato, evento, condizioni (opzionali) ) indica il nuovo stato raggiunto e le eventuali azioni da eseguire
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 > :startCalibration ButtonInterface > :CalibrationControl > :Calibration Constant Analysis model: collaboration diagram Ca1.2: Start, Ca2.2: Stop > :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 > :startCalibration ButtonInterface > :CalibrationControl > :Calibration Constant Design model: collaboration diagram start(),stop() > :stopCalibration ButtonInterface processEvent (calibrationStart) processEvent (calibrationStop)
Usando Finite State Machine M.: es. State-Dependent Class > CalibrationControl + processEvent(event) + currentState(): State Design Model: class diagram > 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 Database AttributiRelazione Operazioni 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 > DebitCard cardID:String PIN: String startDate: Date expirationDate:Date Status: Integer Limit:Real Total: Real
Usando Static Model: esempio Database Wrapper Class Design model > 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 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
Inheritance nel Design: aspetti aggiuntivi Polimorfismo: due classi diverse possono avere una operazione con la stessa segnatura, ma una implementazione diversa Binding Dinamico: associazione a run- time di una richiesta di una operazione fornita da un oggetto Binding a compile-time Binding Dinamico
Superclasses and Subclasses:esempio Account #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
Abstract Superclasses:esempio Maintenance {abstract} #initialMileage: Real + reset () #check () {abstract} OilChangeMaint -oilMaintMileage: Real=5,000 + check () MajorServiceMaint -majorServiceMaint Mileage: Real=15,000 + check () AirFilterMaint -airMaintMileage: Real=10,000 + check ()
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 > 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: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