Fondamenti di Informatica T2 Modulo 2. Corso di Laurea in Ingegneria Informatica Anno accademico 2014/2015. Ancora Phone Plan

Transcript

1 Università degli Studi di Bologna Scuola di Ingegneria e Architettura Fondamenti di Informatica T2 Modulo 2 Corso di Laurea in Ingegneria Informatica Anno accademico 2014/2015 Ancora Phone Plan Quanto fatto sui piani telefonici è bellissimo ma c è qualche problema 1. Il concetto di operatore non è sufficiente La tariffa da applicare alle chiamate all estero è dipendente dalla zona verso cui si chiama, non tanto dall operatore In generale, come trattare le chiamate la cui tariffa non dipende dall operatore? 2. Si tiene conto solamente del costo dell intervallo (scatto) all inizio della chiamata Se la chiamata si estende su due fasce tariffarie? 3. Non è possibile specificare opzioni tariffarie in aggiunta al piano Acquisto traffico flat Holiday Card chiamate verso tutti per un mese a costi ridotti 2

2 Ancora Phone Plan La soluzione è introdurre: 1. il concetto di Tariffa (Rate) che prenderà il posto dell operatore Il costo delle chiamate non è più direttamente dipendente dall operatore di destinazione La tariffa può dipendere da altre variabili non solo dall operatore di destinazione! 2. un algoritmo di calcolo più preciso 3. Il concetto di opzione tariffaria che va ad affiancarsi ai concetti esistenti per consentire di calcolare il costo di una chiamata in modo più flessibile Ho comprato un opzione con la quale posso chiamare gratis dalle 2 alle 3 del mattino. Ti chiamo per farti un saluto? Anche no! 3 Problema 1 Operatore/Tariffa Tariffa (Rate): non può essere 1:1 con l operatore di destinazione «sa» se può essere applicata ad un certo numero di telefono Alla tariffa si può chiedere se sia applicabile ad un certo numero di telefono è un entità caratterizzata da un nome e permette di: chiedere se la tariffa è applicabile ad un certo numero telefonico ottenere il costo per intervallo in un dato istante di tempo chiedere se la tariffa è valida 4

3 Tariffa (Rate) Definiamo subito l interfaccia pubblica dell oggetto Rate È una classe astratta? Ha metodi definiti? È un interfaccia? È un astrazione pura? Usiamo le Rate tramite la loro interfaccia pubblica: Notare che non si è ancora parlato nel dettagli di Rate concrete Le astrazioni vanno progettate con cura Un loro cambiamento può avere effetti devastanti sul progetto Devono essere le parti più stabili in assoluto 5 Classe Astratta o Interfaccia? Classe Astratta È un astrazione (non istanziabile) È solo parzialmente implementata Consente un buon disaccoppiamento Dipendere da un astrazione (anche se solo parziale) è meglio che dipendere da un entità concreta (completamente implementata quindi più instabile) Possibilità di realizzazioni diverse (v. PhonePlanAdapter) all interno di una gerarchia di ereditarietà Interfaccia È un astrazione pura (non istanziabile) Nessuna implementazione, solo dichiarazione Consente un ottimo disaccoppiamento Dipendere da un interfaccia significa non dipendere da alcuna implementazione specifica Possibilità di realizzazioni diverse eventualmente perpendicolari a gerarchie d ereditarietà e non si «brucia» l ereditarietà ma si «brucia» l ereditarietà 6

4 Classe Astratta o Interfaccia? Meglio un interfaccia! Lascia più libertà nelle fasi successive Eventualmente si realizzerà un apposito Adapter per fornire una prima implementazione in modo che non si debba ricominciare sempre da capo class plans «interface» Rate + getcostperinterval(current :LocalDateTime) : double + isapplicableto(destinationnumber :String) : boolean 7 Tariffa: progettazione Per definire una tariffa dipendente dal numero di class rates destinazione e dalla fascia oraria «interface» plans::rate + getcostperinterval(current :LocalDateTime) : double + isapplicableto(destinationnumber :String) : boolean Rate basato su fasce orarie BandsRate Band + BandsRate(name :String, bands :Band[]) + getbands() : Band[] + getcostperinterval(datetime :LocalDateTime) : double + isapplicableto(number :String) : boolean + sortbandsbystarttime(bands :Band[]) : void + Band(startTime :LocalTime, endtime :LocalTime, days :DayOfWeek[], costperinterval :double) -bands + getcombineddays() : DayOfWeek[] + getcostperinterval() : double + getendtime() : LocalTime + getstarttime() : LocalTime + isinband(datetime :LocalDateTime) : boolean DestinationOperatorBandRate OperatorDecoder + DestinationOperatorBandRate(name :String, bands :Band[], operatorname :String) + isapplicableto(destinationnumber :String) : boolean «use» + getnamefromnumber(destinationnumber :String) : String Simile al vecchio Operator Determina a quale operatore appartiene un certo numero 8

5 Problema 2 Calcolo Preciso Ferma restando la validità dell algoritmo precedente (impreciso) si pone il problema di permettere la presenza di algoritmi alternativi di calcolo Però, nel vecchio progetto è stata realizzata la classe Plan con tutti i dettagli del caso E ORA!? 9 Problema 2 Calcolo Preciso Il progetto non era poi così buono (sigh!) Che fine fa Plan? Come si possono avere diversi tipi di piani telefonici intercambiabili? Refactoring 10

6 Soluzione Problema 2 Una gerarchia di piani telefonici! PRIMA decidere quale interfaccia debba esporre il piano generico POI decidere cosa sia possibile implementare subito e cosa differire POI capire come, in questo nuovo contesto, si collochino Plan e le sue alternative Pattern Strategy! 11 Strategy Il pattern Strategy permette di definire una famiglia di algoritmi, incapsularli e renderli intercambiabili INCAPSULARLI (1) = sapere dove sono concettualmente contenuti = sapere dove "mettere le mani" per migliorarli, correggerli, etc RENDERLI INTERCAMBIABILI = poterli variare in modo indipendente dal contesto Si ottiene così un meccanismo di configurazione flessibile possibilità di scegliere al momento dell'uso un comportamento specifico fra quelli disponibili Questo concetto marchiatevelo a fuoco dove preferite purché sia un posto ben visibile... La gerarchia di Filter di MyMedia non sarà mica stato uno Strategy!? 12

7 Strategy: gli ingredienti di base Tre ingredienti di base: una classe Strategia (una classe astratta o anche una interfaccia) che dichiara la signature di riferimento per gli algoritmi concreti un insieme di classi concrete (o di implementazione) di Strategia, ognuna delle quali implementa un particolare algoritmo utilizzando la signature definita da Strategia una classe Contesto che configura un insieme di oggetti Strategia e le usa per eseguire l algoritmo concreto Potrebbe anche essere una interfaccia con le relative classi di implementazione 13 Interface PhonePlan class plans «interface» PhonePlan + getcallcost(call :PhoneCall) : double Non sa nulla di algoritmi, tariffe, operatori: dietro l interfaccia può esserci qualsiasi cosa! È caratterizzato da un nome Consente di: ottenere il costo di una chiamata date le sue caratteristiche: il numero chiamato e la data/ora di inizio e fine verificare la validità del piano ottenere il suo nome 14

8 PhonePlanAdapter Tipicamente, un piano telefonico coinvolge tariffe, scatti alla risposta, intervalli, PhonePlanAdapter è una classe astratta che implementa alcuni metodi dell interfaccia e che propone una realizzazione standard di PhonePlan prevedendo un calcolo basato su: Tariffe differenziate a seconda del numero chiamato (Rate) Eventuale scatto alla risposta Intervallo di tempo base PhonePlanAdapter implementa già la verifica di validità ma lascia astratto il metodo di calcolo del costo della chiamata 15 PhonePlanAdapter class plans «interface» PhonePlan + getcallcost(call :PhoneCall) : double Una qualsiasi delle Rate possibili PhonePlanAdapter + getcallcost(call :PhoneCall) : double + getintervalinmillis() : int # getratebydestination(destinationnumber :String) : Rate + getstartcallcost() : double # PhonePlanAdapter(name :String, intervalinmillis :int, startcallcost :double, rates :Rate[]) -rates «interface» Rate + getcostperinterval(current :LocalDateTime) : double + isapplicableto(destinationnumber :String) : boolean 16

9 e tutti gli altri Ora basta realizzare l algoritmo di calcolo del costo in opportune sottoclassi di PhonePlanAdapter class plans «interface» PhonePlan + getcallcost(call :PhoneCall) : double Nuovo algoritmo «preciso»: viene valutato e sommato al totale il costo di ogni singolo intervallo PhonePlanAdapter + getcallcost(call :PhoneCall) : double + getintervalinmillis() : int # getratebydestination(destinationnumber :String) : Rate + getstartcallcost() : double # PhonePlanAdapter(name :String, intervalinmillis :int, startcallcost :double, rates :Rate[]) Stesso algoritmo del vecchio Plan PrecisePlan + getcallcost(phonecall :PhoneCall) : double + PrecisePlan(name :String, interval :int, startcallcost :double, rates :Rate[]) SimplePlan + getcallcost(phonecall :PhoneCall) : double + SimplePlan(name :String, intervalinmillis :int, startcallcost :int, rates :Rate[]) 17 Problema 2 Ora la struttura è ok, ma l algoritmo!? Per far funzionare bene le cose occorre, in ogni istante di tariffazione della chiamata, chiedere alla tariffa applicata quale sia il costo corrente tenendo conto del fatto che gli istanti in cui viene effettuato il calcolo sono comunque determinati dalla durata dell intervallo definita nel piano 18

10 Algoritmo preciso PrecisePlan.getCallCost Input: inizio/fine chiamata, numero destinazione 1. Selezionare la tariffa mediante il numero destinazione 2. Impostare la data ora dell istante corrente con data/ora di inizio chiamata 3. Se l istante corrente precede la data/ora di fine chiamata a. Ottenere dalla tariffa il costo per intervallo nell istante corrente e sommare il valore ottenuto al costo totale della chiamata b. Incrementare l istante corrente della durata dell intervallo in modo da ottenere un nuovo istante corrente c. Ripartire da Sommare al costo totale della chiamata il valore dello scatto alla risposta 19 Un opzione: Problema 3 Opzioni è un entità che, sotto determinate condizioni (applicabilità dell opzione) può sostituirsi al piano tariffario in modo trasparente cambiandone il comportamento apparente. può avere uno stato che cambia in base all utilizzo Ad esempio, opzioni con traffico a scalare su un plafond acquistato 20

11 Opzioni Le opzioni possono essere le più varie L importante è definire un interfaccia pubblica che possa essere comune a tutte le opzioni possibili Chi usa le opzioni non deve conoscere i dettagli implementativi di ogni singola opzione Idealmente, l Opzione dovrebbe essere invisibile! 21 Riassumendo: Opzioni e PhonePlan Un opzione deve intercettare le chiamate di calcolo del costo al piano telefonico (PhonePlan) di base Se l opzione è applicabile, allora prende il controllo e decide cosa fare altrimenti delega il calcolo al piano telefonico di base. Come da normali pratiche commerciali, è possibile «montare» più opzioni. 22

12 Opzioni e PhonePlan: Design L opzione può essere un PhonePlan «speciale» getcallcost(mycall) Option + getcallcost(phonecall) PhonePlan + getcallcost(phonecall) Da «fuori» si vede solo un normale PhonePlan L opzione incapsula un PhonePlan e può decidere se calcolare il costo della telefonata: in autonomia in collaborazione con il PhonePlan interno per delega totale al PhonePlan interno 23 Calcolo in autonomia: Esempi YouAndMe: se il numero di telefono è «quello giusto», allora il costo è nullo Calcolo in collaborazione: Spendi la metà: dimezza il costo restituito dal PhonePlan interno Calcolo in autonomia o delega: 400 minuti di traffico flat al mese: se i minuti «non sono finiti» allora il costo è nullo (0), altrimenti delega al PhonePlan interno Il traffico flat si consuma! l opzione cambia stato durante l uso! 24

13 Design dell Opzione È un piano telefonico: implementa l interfaccia PhonePlan Incapsula un piano telefonico: ha un riferimento ad un PhonePlan Incapsula un altra opzione ma è sempre essa stessa vista come un piano telefonico! Un opzione può incapsulare un altra opzione possibilità di creare una catena di opzioni che termina con un piano telefonico Opzione 1 Opzione 2 Phone Plan 25 Chain of Responsibility Si tratta di un altro pattern: altro problema noto, altra soluzione nota La richiesta di calcolo viene gestita dalla catena; ogni elemento può: Contribuire al calcolo Passare il controllo all elemento successivo per proseguire il calcolo Interrompere la catena e ritornare un risultato (all elemento precedente): non è detto che la richiesta arrivi sempre all ultimo elemento della catena. Chi sta fuori non vede la catena: fa una richiesta, ottiene una risposta Disaccoppiamento totale! Che spettacolo! 26

14 PhonePlanOption public abstract class PhonePlanOption implements PhonePlan { private String name; private PhonePlan next; protected PhonePlanOption(String name) { this.name = public String getname() { return public double getcallcost(phonecall call) { return public boolean isvalid() { return getnext()!= null && getnext().isvalid(); public PhonePlan getnext() { return this.next; public void setnext(phoneplan next) { this.next = next; Classe astratta! Non ha senso che sia concreta visto che serve solo come base per le opzioni. Nota: non ha metodi astratti. Comportamento di default 27 In public double getcallcost(phonecall call) { // eventuale pre-elaborazione dei parametri (call) // eventuale chiamata a next double result = getnext().getcallcost(call); // eventuale post-elaborazione del risultato return result; La pre-elaborazione è opzionale La chiamata a next è opzionale La post-elaborazione è opzionale è obbligatorio restituire qualcosa di sensato 28

15 Ordine delle Opzioni Poiché le opzioni sono concatenate, hanno un ordine predeterminato le prime sono quelle applicate per prime quindi possono essere considerate a priorità maggiore Ordinare diversamente le opzioni può dar luogo a risultati diversi In realtà si tratta di un problema puramente commerciale: basta creare la catena nel modo corretto 29 PhonePlanWithOptions Per comodità nella gestione «quotidiana» delle opzioni, la classe PhonePlanWithOptions (fornita nello Start Kit): Implementa PhonePlan Permette di aggiungere/eliminare opzioni Contiene un riferimento al PhonePlan effettivo Contiene un riferimento alla catena delle opzioni (che termina con il PhonePlan effettivo) 30

16 YouMeAndTheOther Opzioni Concrete Due numeri di telefono a costo costante per chiamata (configurabile) Nessuno scatto alla risposta FlatTime Mette a disposizione un certo numero di minuti prepagati (definibili all atto della costruzione) Intervallo di tariffazione a 1 minuto (pagamento anticipato) Nessuno scatto alla risposta Verificare il corretto funzionamento delle opzioni implementate (un test JUnit per ogni classe) prima di utilizzarle all interno di un piano 31 Opzioni class options plans::phoneplanoption + getcallcost(call :PhoneCall) : double + getnext() : PhonePlan # PhonePlanOption(name :String) + setnext(next :PhonePlan) : void FlatTime YouMeAndTheOther + FlatTime(flatPeriod :int) + getcallcost(call :PhoneCall) : double + getflatperiod() : int + getcallcost(call :PhoneCall) : double + getconstcost() : double + getdestnumber1() : String + getdestnumber2() : String + YouMeAndTheOther(destNumber1 :String, destnumber2 :String, constcost :double) 32

17 Diagramma UML Sono solo altre implementazioni della stessa interfaccia si aggiunge comportamento al sistema senza alterare quanto già esiste class plans PhonePlanOption + getcallcost(call :PhoneCall) : double + getnext() : PhonePlan # PhonePlanOption(name :String) + setnext(next :PhonePlan) : void -next -actualphoneplan «interface» PhonePlan + getcallcost(call :PhoneCall) : double «use» PhonePlanWithOptions + addoption(option :PhonePlanOption) : void + getcallcost(call :PhoneCall) : double + PhonePlanWithOptions(actualPhonePlan :PhonePlan) + removeoption(option :PhonePlanOption) : boolean + removeoptionbyname(optionname :String) : boolean 33 Note sul Testing Ricreare esattamente l ambiente di produzione può essere complicato o impossibile. Occorre trovare un modo per isolare i componenti dal loro ambiente reale. Ciò è possibile solo se dipendono da entità astratte! Prove sul «banco» Arrange: predisposizione dell ambiente di test Act: esecuzione delle azioni da testare Assert: verifica dello stato delle entità in gioco, verifica che le azioni sugli oggetti dipendenti siano state effettuate nel modo «giusto» 34

18 Note sul Testing Dopo aver realizzato PrecisePlan (sottoclasse di PhonePlanAdapter) come verificare che la classe si comporti «correttamente» con le tariffe (Rate) senza utilizzare tariffe vere? Posso definire nuove tariffe solo per il testing senza alterare il codice esistente? Sì, implementa una Rate FINTA! 35 Mock Objects Un mock object è un oggetto di test che simula in modo controllato il comportamento di un oggetto reale del sistema presenta la stessa interfaccia dell oggetto che simula risponde sempre in modo controllato e corretto agli input che riceve non ha algoritmi di calcolo al suo interno, ma fornisce una data risposta ad una data richiesta Vengono utilizzati per disaccoppiare i test di parti diverse del sistema: permettono di testare un determinato oggetto in modo isolato e senza risentire dell eventuale malfunzionamento di quegli oggetti che gli stanno intorno in ambiente di produzione. 36

19 MockRate public class MockRate implements Rate { public String getname() { return "MockRate"; public boolean isapplicableto(string destinationnumber) { return true; public double getcostperinterval(localdatetime current) { return 1; public boolean isvalid() { return true; 37 Il succo del discorso PrecisePlan è testato in modo indipendente delle opzioni concrete commerciali È stato inserito in un ambiente artificiale di cui la nuova MockRate fa parte È stato sollecitato per verificare le attese 38

20 Il succo del discorso L oggetto/componente argomento di test dovrebbe essere quanto più isolato possibile ed immerso in un ambiente artificiale noto Il funzionamento del componente non deve essere influenzato dagli oggetti collaboratori Se viene rilevato un problema, dov è il bug? 39 Il succo del discorso In termini di design, è necessario che una classe abbia quante meno dipendenze concrete possibile per massimizzare la riusabilità in generale l unità riusabile è composta dall oggetto più tutte le sue dipendenze concrete) per facilitare il testing l oggetto è completamente isolabile e può essere immerso in un ambiente completamente artificiale: gli oggetti concreti al contorno sono appositamente studiati solo per i test 40

21 Start Kit Rate e implementazioni varie oltre a tutto ciò che c era nella vecchia soluzione Rate, Band, BandsRate, DestinationOperatorBandsRate, OperatorDecoder, PhonePlanOption, PhonePlanWithOptions, MockRate, MockOption, MockPhonePlan GUARDATE COME SONO FATTI DENTRO!!! 41 Piani Telefonici (I) Prelevare la soluzione di Lab04 (PhonePlan) e realizzare: PhonePlan (interfaccia), PhonePlanAdapter, SimplePlan (refactoring vecchia soluzione) Adattare i test JUnit alla nuova situazione PrecisePlan (con algoritmo preciso per il calcolo del costo) Creare nuovi test Junit (usare MockRate!) 42

22 Piani Telefonici (II) Realizzare le opzioni FlatTime e YouMeAndTheOther Verificare il funzionamento delle opzioni realizzate mediante l ausilio di MockPhonePlan (nello Start Kit) che: Permette di impostare nome e costo (costante) per qualsiasi chiamata (il metodo getcallcost restituisce sempre lo stesso valore). Permette di sapere se e quante volte è stato invocato un certo metodo 43