Hardware, servizi, plugin e       testabilità        Un caso reale
AutoreRicci Gian MariaE-mail: ricci.gm@nablasoft.comBlog: http://www.codewrecks.com         http://blogs.ugidotnet.org/rgm
La situazione attuale              Il software è un unico programma              winform che contiene tutta la logica nelM...
L’evoluzione richiesta                 Il software deve poter essere eseguito                 come servizio di windows, qu...
Il “desiderata”                Poter effettuare test funzionali di interfaccia senza avere                l’hardware conne...
Come si è proceduto         As-Is        Hardware     WCF           Servizio     PluginSi è proceduto prendendo un softwar...
Lavorare con l’hardware               In molti casi è possibile identificare un               comportamento simile tra var...
Si comincia con l’hardware                Quando si ha a che fare con hardware, non                esiste refactoring che ...
DEMOIsolare l’hardware tramite interfacce
Comunicazione                  Dato che il codice che contiene la «business                  logic» dovrà essere eseguito ...
WCF Discovery                      WCF contiene una funzionalità interessante                      chiamata DiscoveryServi...
DEMOImpostazione della comunicazione    interprocesso con WCF
Flessibilità di deploy                              Nel primo scenario il software viene deployato                        ...
DEMOAbilitazione della modalità servizio,     singletier e UI-Unattended
DEMOWCF discovery
Plugin                      Spesso vi è la necessità di applicare logiche                      simili a più hardwareHardwa...
MEF                      Mef permette di gestire con facilità la                      complessità di «individuare» e «cari...
PluginPer lasciare il tutto molto semplice si utilizzano solamente lefunzionalità base di MEF introducendo una Interfaccia...
DEMOVersione finale con caricamentodinamico dei plugin tramite MEF
Testing                      La creazione di plugin di Testing permette                      di poter verificare la busine...
Question time• Iniziamo la discussione su quanto visto!!
Upcoming SlideShare
Loading in …5
×

Hardware e plugin

524 views

Published on

This is the presentation of my talk at #guisa1 event in Ital

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
524
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Hardware e plugin

  1. 1. Hardware, servizi, plugin e testabilità Un caso reale
  2. 2. AutoreRicci Gian MariaE-mail: ricci.gm@nablasoft.comBlog: http://www.codewrecks.com http://blogs.ugidotnet.org/rgm
  3. 3. La situazione attuale Il software è un unico programma winform che contiene tutta la logica nelMonolitico code behind di una form L’accesso all’hardware è effettuato direttamente nel code-behind, il softwareHardware può quindi essere lanciato solamente in presenza dell’hardware Non è presente nessun test automatizzato, i test vengono fattiBad testing lanciando il software ed utilizzandolo con l’hardware connesso
  4. 4. L’evoluzione richiesta Il software deve poter essere eseguito come servizio di windows, quindi senzaServizi interazione con l’utente e senza ui È comunque necessario avere una interfaccia per poter inviare alcuniUser interface messaggi e verificare lo stato del servizio
  5. 5. Il “desiderata” Poter effettuare test funzionali di interfaccia senza avere l’hardware connesso. Possibilità di simulare le varie condizioni dell’hardware (faulting, disconnection, etc)Hardware Free Essere se possibile indipendenti dall’hardware, poter quindi riusare la UI e la logica in presenza di hardware differenti con cambiamenti minimali al codicePlugin Poter decidere come deployare il software, o come servizio con UI disconnessa, o come eseguibile monolitico, oppure in modalità UI-UnattendedVersatilità Dialogare con un servizio o con la modalità UI-Unattended da macchine remote previa connessione di rete.Remote UI
  6. 6. Come si è proceduto As-Is Hardware WCF Servizio PluginSi è proceduto prendendo un software minimale il cui scopo èsemplicemente ricevere dei codici letti da una serie di barcode scannerindustriali e scriverli su di una cartellaL’obiettivo era quello di creare una proof of concept che mostrasse i passinecessari per rifatorizzare un progetto esistente dalla versione monolitica,alla versione desiderataIl risultato serve a dimostrare il processo necessario alla rifattorizzazione, siacostituisce una reference implementation minimale su cui basare i successivisoftware.
  7. 7. Lavorare con l’hardware In molti casi è possibile identificare un comportamento simile tra vari hardware, ad esempio dei lettori di codici a barre o lettori RFID sono in grado di essere interrogati per ricevere una stringa. HardwareL’individuazione di una interfaccia IGenericCodeReaderserve quindi ad astrarre il comportamento di ungenerico hardware appartenente ad una determinatacategoria.Questo è il primo passo per poter essere indipendentidall’hardware
  8. 8. Si comincia con l’hardware Quando si ha a che fare con hardware, non esiste refactoring che non parta dal permettere di utilizzare il software con dei «simulatori» di hardware HardwareLa necessità di operare e di effettuare test conhardware connesso rende molto difficili le operazionidi test e quindi ogni possibile refactoring.La soluzione è astrarre l’hardware con una interfacciaed iniziare il lavoro con un simulatore
  9. 9. DEMOIsolare l’hardware tramite interfacce
  10. 10. Comunicazione Dato che il codice che contiene la «business logic» dovrà essere eseguito in un servizio la UI deve eseguire una comunicazione Interprocesso HardwareIn .NET la soluzione migliore è utilizzare una infrastrutturaWCF, il servizio esporrà quindi un host WCF che può esserecontattato da uno o più interfacce remote.Tramite WCF si può connettere una interfaccia al servizio diun altro computer, semplificando la manutenzione
  11. 11. WCF Discovery WCF contiene una funzionalità interessante chiamata DiscoveryServizioHardware UI Grazie al discovery, un applicativo può cercare se nella rete è presente un Host wcf che soddisfa una determinata interfacciaServizio Servizio Il Discovery può semplificare la gestione delle interfacce remote perché permette di presentare all’utente una lista di host attivi, dove ogni host è una istanza del servizio in esecuzione
  12. 12. DEMOImpostazione della comunicazione interprocesso con WCF
  13. 13. Flessibilità di deploy Nel primo scenario il software viene deployato come «windows service», se necessario si accede con una UI remotaServizio UI Nel secondo scenario si esegue il software con una interfaccia minimale, usualmente con un bottone Start/Stop e poco piùMinimal-UI UI Nel terzo scenario il software viene eseguito in un singolo tier, interfaccia di monitor e codice di business logic vengono eseguiti nello stesso processo (come nella as-is)All-in-onLa necessità di supportare questi tre scenari è richiesta peraumentare la flessibilità e non «complicarsi la vita con i windowsservice quando non serve»
  14. 14. DEMOAbilitazione della modalità servizio, singletier e UI-Unattended
  15. 15. DEMOWCF discovery
  16. 16. Plugin Spesso vi è la necessità di applicare logiche simili a più hardwareHardware Logic Gli hardware possono essere eguali o eterogenei e condividere solo una certa interfaccia (es. lettori di codici)Hardware Hardware Una business logic deve quindi poter caricare «dinamicamente» i plugin che va ad utilizzare Questa struttura può essere implementata con poco sforzo grazie a MEF, che si occupa del discovery e della istanziazione dei plugin
  17. 17. MEF Mef permette di gestire con facilità la complessità di «individuare» e «caricare» iHardware Logic plugin a run-time Grazie a MEF e poche righe di codice il nostro progetto è in grado di scandire laHardware Hardware cartella principale alla ricerca di plugin. I concetti base sono Export ed Import, ovvero fornire e consumare parti di software
  18. 18. PluginPer lasciare il tutto molto semplice si utilizzano solamente lefunzionalità base di MEF introducendo una Interfacciachiamata IGenericCodeReaderFactoryTale interfaccia ha lo scopo di creare le reali istanze dei plugin.Grazie a MEF verranno automaticamente caricate tutte le classiconcrete disponibili che implementano questa interfaccia new MEF Factory A Plugin A Hardware Plugin ASoftware new Factory B Plugin B Plugin B
  19. 19. DEMOVersione finale con caricamentodinamico dei plugin tramite MEF
  20. 20. Testing La creazione di plugin di Testing permette di poter verificare la business logic e leHardware Logic logiche di interfaccia senza un hardware reale. Un plugin di test permette quindi diHardware Hardware «simulare» i comportamenti dell’hardware e verificarne le corrispettive risposte del sistema Grazie a questo è possibile non solo effettuare test manuali, ma anche creare UnitTest ripetibili e senza smell È possibile sfruttare strumenti come i Coded-Ui-Test
  21. 21. Question time• Iniziamo la discussione su quanto visto!!

×