Class Design In COMET Elena Balladore. Indice Che cos’ è il Class DesignChe cos’ è il Class Design Design delle information hiding classes Design delle.

Slides:



Advertisements
Presentazioni simili
Il paradigma Object Oriented
Advertisements

Progettazione dei Sistemi Interattivi (A.A. 2004/05) - Lezione 2 1 Progettazione e Sviluppo di Software ad Oggetti 4 OBJECT-ORIENTED ANALYSIS Processo.
Recupero debito quarto anno Primo incontro
Unità D2 Database nel web. Obiettivi Comprendere il concetto di interfaccia utente Comprendere la struttura e i livelli che compongono unapplicazione.
Informatica 2 Lezione 4 Corso di laurea in matematica Informatica 2 Dott. Ing. Leonardo Vito Corso di laurea matematica indirizzo matematica per le applicazioni.
Le gerarchie di tipi.
Università degli Studi di Modena e Reggio Emilia
Principi di Programmazione Object-Oriented
Principi di Programmazione Object-Oriented
Amministrazione di una rete con Active Directory.
1 Defect testing Lobiettivo: scoprire difetti in un programma Un test ha successo se forza il programma a comportarsi in modo anomalo I test provano la.
1 9: Progettazione Architetturale Obiettivo: stabilire la struttura globale di un sistema software Descriveremo diversi tipi di modello di architettura,
1 Basi di dati e Web Prof. Stefano Paraboschi Prof. Barbara Pernici.
Analisi dettagliata e design B. Pernici M.G. Fugini AA
1 Programmazione ad oggetti in Java E.Mumolo, DEEI
Introduzione al linguaggio Java
eliana minicozzi linguaggi1a.a lezione2
Overriding.
Programmazione II: Tecniche Avanzate. (A.A. 1999/2000) - Lezione 6 1 Estensione di classi: il Contratto INTERFACCIA E REALIZZAZIONE Che cosa realizza una.
UML: Extension Mechanism Corso IS I /03 Gianna Reggio Versione 0.0.
La Riflessione computazione Elisa Ferrando. Cos è la Riflessione La Riflessione Sistema riflessivo Sistema computazionale.
© CEFRIEL Ricettario dei principali pattern GoF Docente: Gabriele Lombardi
1 Le gerarchie di tipi. 2 Supertipi e sottotipi 4 un supertipo –class –interface 4 può avere più sottotipi –un sottotipo extends il supertipo ( class.
memoria gestita staticamente:
Sistemi Operativi GESTIONE DEI PROCESSI.
Modello Relazionale Definisce tipi attraverso il costruttore relazione, che organizza i dati secondo record a struttura fissa, rappresentabili attraverso.
Elaborazione di Franco Grivet Chin
Java base IV: Java e la programmazione O.O.
Java concetti A.Natali Marzo Java Dai concetti ai costrutti.
A.Natali DL Maggio1999 Oggetti Concetti fondamentali.
Introduzione alla modellazione di sistemi interattivi
L’ingegneria del software
Introduzione alla programmazione Object Oriented
Il Sistema Operativo (1)
Ingegneria del software Modulo 2 -Il software come prodotto Unità didattica 2 - I costi del software Ernesto Damiani Università degli Studi di Milano Lezione.
Dati e DBMS DBMS relazionali SQL Progettazione di una base di dati Programma del Corso.
I nomi in Java F. Bombi 18 novembre novembre 2003.
1 cin>>c8 s.r.l A.A Generalità Uno dei concetti largamente adottati negli ultimi anni dai professionisti del software in fase di sviluppo.
INTRODUZIONE A JAVASCRIPT
1 Progettazione Architetturale. 2 Obiettivo: stabilire la struttura globale di un sistema software Descriveremo diversi tipi di modello di architettura,
Programmazione ad oggetti
Lezione 1 Panoramica sui paradigmi di programmazione
SISTEMI DI GESTIONE DI WORKFLOW
Dynamic Modeling in COMET Seconda parte Valentina Cordì.
FUNZIONI Dichiarazione: Definizione:
CRUISE CONTROL AND MONITORING SYSTEM Case study Luigi Tosetto.
Incapsulamento e information hiding
Programmazione ad oggetti
Laboratorio di Servizi Web - servlet - Ardissono 1 Java Servlet API package javax.servlet: include classi e interfacce di gestione di servlet indipendenti.
Task Structuring COMET TASK STRUCTURING - Prima parte -
Ereditarieta’. Contenuti Introduciamo un meccanismo fondamentale di Java: l’ereditarieta’ Permette di estendere classi gia’ definite (ovvero di definire.
Analisi dettagliata e design
Caso di studio Sistema Bancario Seconda parte: Design Vallarino Paola.
SOFTWARE ARCHITECTURAL DESIGN NEL METODO COMET Corso di Ingegneria del Software 2 Anno Accademico Demergasso Daniela.
COMET Elevator Control System Case Study - Prima parte - Elevator Control System Case Study.
Esercizio ODBC. Configurare il driver ODBC Start  Control Panel  Administrative Tools Aprire: Data Source(ODBC) User DSN  Add…. Selezionare il driver.
Fondamenti di Informatica 2 Ingegneria Informatica Docente: Giovanni Macchia a.a
TW Asp - Active Server Pages Nicola Gessa. TW Nicola Gessa Introduzione n Con l’acronimo ASP (Active Server Pages) si identifica NON un linguaggio di.
OBJECT ORIENTED DATABASE introduzione. OGGETTO Ha due componenti:  stato: valore di alcune variabili (variabili di istanza)  comportamento: insieme.
Sistemi operativi di rete Ing. A. Stile – Ing. L. Marchesano – 1/18.
Progettare una classe 21 Febbraio La classe BankAccount Vogliamo realizzare una classe i cui oggetti sono dei semplici conti bancari. * Identifichiamo.
LIP: 11 Maggio 2007 Classi Astratte. Cos’e’ una Classe Astratta una classe astratta e’ un particolare tipo di classe permette di fornire una implementazione.
Esercitazione sull’ ordinamento 20 maggio 2003
PHP.  HTML (Hyper Text Markup Language)  CSS (Cascading Style Sheets)  Javascript (linguaggio di programmazione client)  PHP ( Hypertext Preprocessor.
28/12/2001package 1 Package Pacchetti e interfacce.
Introduzione alle Classi e agli Oggetti in Java 1.
La gestione della rete e dei server. Lista delle attività  Organizzare la rete  Configurare i servizi di base  Creare gli utenti e i gruppi  Condividere.
Transcript della presentazione:

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