The Architecture – L’Architettura
GeRi è una piattaforma software che nasce con lo scopo di gestire tutte le attività, dirette e indirette, connesse ad una centro assistenza.
Analizziamo di seguito alcune scelte di tipo architetturale, prima di passare direttamente alla fase di design dell’applicativo.

SOA - Service Oriented Application.
Come è stato evidenziato nei precedenti articoli, la nostra piattaforma deve essere in grado di “agganciarsi” a servizi di fornitori esterni per espletare alcune operazioni.
Un esempio su tutti è la necessità di inviare messaggi SMS.
Ma oltre ad usufruire di servizi esterni, la nostra piattaforma deve essere anche in grado di erogare servizi, acquisendo e garantendo quindi un certo grado di flessibilità con il mondo dell’integrazione.
Erogare/esporre servizi, significa anche permettere facilmente a sistemi esterni (magari realizzati con linguaggi e tecnologie differenti) in prima istanza di dialogare con il nostro sistema, e in seconda istanza di implementare moduli di integrazione con la nostra piattaforma.
Ad esempio non è da ritenersi rara la possibilità di “integrazione” del nostro sistema con sistemi di fatturazione di terze parti.
Per questo motivo ritengo valido scegliere un’architettura di tipo SOA ovvero “Orientata ai Servizi”.

Architectural View
Avendo ben chiaro il contesto architetturale nel quale intendiamo realizzare la nostra applicazione, analizziamo di seguito alcune scelte su come organizzare l’architettura dell’applicativo.

L’applicazione sarà organizzata secondo una classica architettura di tipo N-Tier.
Ma cos’è un applicazione N-Tier?
Una architettura di tipo N-Tier indica una particolare architettura software che prevede la suddivisione del sistema in N diversi livelli (logici e fisici) che svolgono funzionalità diverse (opzionalmente su nodi diversi della rete).
Ad esempio esiste il livello per la gestione dell’interfaccia utente (UI Layer), quello per la logica funzionale (Business Layer) e quello per la gestione della persistenza dei dati (Data Access Layer).
In questo modo, ciascuno degli N livelli può essere modificato o sostituito indipendentemente dagli altri.
Nella maggior parte dei casi, si intende anche che i diversi livelli siano distribuiti su diversi nodi di una rete anche eterogenea.
Questo è alla base della distinzione tra Layer e Tier.

• Un Layer indica un raggruppamento logico delle funzionalità
• Un Tier indica un raggruppamento fisico delle funzionalità

Un esempio tipico di architettura N-Tier, dove N=3, detta appunto three-tier prevede, per esempio:

1. un Tier di presentazione identificato da un PC dedicato all’interfaccia utente grafica (su cui persiste quindi il layer di presentazione o UI Layer)
2. un Tier di Business Logic indentificato da una workstation o un application server per l’esecuzione di business logic
3. un Tier di Database indentificato da un database server o un mainframe per la gestione dei dati.

In merito alla nostra applicazione avremo quindi i seguenti Layers :

1. Data Access Layer (da ora in poi DAL) è il livello di interazione con la base di dati, dove si effettuano le connessioni e si eseguono query di selezione, inserimento, aggiornamento o cancellazione.
2. Business Layer (da ora in poi BL) è il livello che ha la responsabilità di gestire le richieste utente ricevute attraverso l’Uil o SL, di effettuare il routing di queste richieste agli appropriati elementi di business, di processare i risultati dell’elaborazione e ritornare i dati necessari all’Uil o SL per la successiva presentazione all’utente.
3. Service Layer (da ora in poi SL) è il livello che svolge la funzione di “collante” tra il BL e l’UiL ed è caratterizzato da un numero di servizi che espongono al “mondo esterno” le funzionalità business.
4. User Interface Layer (da ora in poi UiL) è il livello che si occupa della presentazione e della logica di interazione con l’utente, interagendo con il BL per l’accesso ai servizi richiesti.

Organizzati nei seguenti Tiers :

1. Database Tier, ovvero il livello fisico su cui deployeremo il nostro Database.
2. Application Server Tier, ovvero il livello fisico su cui deployeremo il BL e il SL.
3. Presentation Tier, ovvero il livello fisico su cui deployeremo l’interfaccia grafica della nostra applicazione.

Ritengo concluso il terzo articolo della serie, che è servito a delineare l’aspetto architetturale su cui si fonda la soluzione da implementare.
Scopo del prossimo articolo sarà quello di “creare gli use cases” e quindi "disegnare il nostro Core".
Non mi resta quindi che finire con il classico :
See u in the next episode

(Fonte : Alessandro Forte - http://www.alessandroforte.it/)

1. IDE: VS 2008 (in attesa di VS 2010)
2. Debugger: di default quello installato con VS2008 altrimenti WinDbg
3. Refactoring: Resharper 4
4. Source Control: AnkhSVN + Tortoise SVN
5. Diff and Merge Tool: WinMerge
6. Text Editor: Notepad++
7. Browsers: Firefox 3 with these Add-ons:
   Web Developer,
   Firebug,
   Poster,
   Firecookie,
   FireFTP,
   FirePHP,
   ReloadEvery,
   Selenium IDE
8. Regular Expression Testing Tool: Expresso
9. Continuous Integration: CCTray

Ovviamente è inutile dire che questo è un Post-In-Progress e che ogni “suggerimento” è veramente ben accetto.

The Problem – Il Problema
GeRi è una piattaforma software che nasce con lo scopo di gestire tutte le attività, dirette e indirette, connesse ad una centro assistenza.
In generale possiamo dire che il punto focale e primario di un centro assistenza (e di molte altre attività, come in seguito approfondiremo), verte sul concetto di Riparazione.
Possiamo sicuramente definire una riparazione come un processo.
In quanto tale essa è caratterizzata da più fasi, e da diversi attori che prendono parte al processo. Addentriamoci quindi nel merito della descrizione delle fasi e degli attori che costituiscono il processo di riparazione.

La prima fase del nostro processo di riparazione è denominata : Ingresso.
In questa fase un Utente, possessore dell’oggetto da riparare, consegna il suddetto presso il centro di riparazione.
Nell’operazione di ingresso, l’Operatore deputato all’ingresso degli oggetti da riparare, prende in consegna l’oggetto da riparare compilando un’apposita Scheda di Ingresso.
Tale Scheda prevede l’inserimento di diverse informazioni, di seguito elencate :

• Anagrafica cliente (Inserimento o recupero di un’anagrafica già esistente)
• Data di ingresso dell’oggetto
• Dati di acquisto dell’oggetto nel caso in cui l’oggetto fosse in garanzia
  (incluse Tipo Documento Acquisto, Numero, Data)
• Descrizione caratteristiche dell’oggetto
  (incluse Tipologia, Marca, Modello, Numero Serie Primario e Secondario)
• Descrizione degli eventuali accessori consegnati con l’oggetto
• Descrizione dello stato generale dell’oggetto
• Descrizione preliminare del malfunzionamento
• Descrizione di eventuali non conformità
• Locazione dell’oggetto
• Eventuale acquisizione di un immagine dell’oggetto
• Definizione dell’eventuale “muletto” e/o apparecchio di cortesia consegnato al cliente

mentre contempla la generazione da parte del sistema delle seguenti informazioni :

• Codice riparazione (nella duplice modalità Testo/BarCode)
• Operatore assegnato alla riparazione
  (L’assegnazione avviene per associazione diretta o tramite un apposito algoritmo)
• Cambiamento dello stato della riparazione
• Clausole contrattuali/legali legate alla riparazione

La fase di ingresso si conclude con la stampa della Scheda di Ingresso da consegnare al cliente come ricevuta.
Tale ricevuta dovrà successivamente essere presentata dall’utente per il ritiro dell’oggetto.

La seconda fase del nostro processo di riparazione è denominata : Riparazione.
In questa fase un Tecnico, figura deputata alla riparazione dell’oggetto da riparare, prende in consegna l’oggetto (con la relativa scheda di ingresso) e comincia l’analisi della riparazione da effettuare.
Nell’operazione di riparazione, il Tecnico deputato alla riparazione dell’oggetto da riparare, esegue le necessarie operazioni di analisi e riparazioni sull’oggetto e al termine dell’intervento compila un’apposita Scheda di Intervento.
Tale Scheda prevede l’inserimento di diverse informazioni, di seguito elencate :

• Descrizione della riparazione
• Definizione dei costi della riparazione
  (inclusi Costo Sostenuto [ricami + manodopera], Costo Riparazione)
• Descrizione di eventuali committenti e/o centri esterni di riparazione

mentre contempla la generazione da parte del sistema delle seguenti informazioni :

• Cambiamento dello stato della riparazione
• Data di riparazione dell’oggetto
• Notifica a mezzo SMS dell’avvenuta riparazione

La fase di riparazione può “momentaneamente” interrompersi in virtù delle seguenti situazioni :

1. Attesa di ricambi
2. Presentazione di un Preventivo, previa riparazione dell’oggetto

La fase di riparazione si conclude con la redazione, da parte del Tecnico, della Scheda di Intervento che descrive l’elenco delle operazioni effettuate.
Idealmente tale documento dovrebbe essere storato all’interno di un DMS - Document Management System, o “allegato” alla riparazione stessa. Tale funzionalità sarà oggetto di discussione nelle future implementazioni.

La terza ed ultima fase del nostro processo di riparazione è denominata : Riconsegna.
In questa fase l’Utente, proprietario dell’oggetto da riparare, passa a ritirare il suddetto presso il centro di riparazione.
Nell’operazione di riconsegna, l’Operatore deputato alla riconsegna degli oggetti da riparare, restituisce l’oggetto riparato stampando e consegnando al cliente l’apposita Scheda di Ingresso.
Tale Scheda non prevede l’inserimento di alcuna informazione ma contempla la generazione da parte del sistema delle seguenti informazioni :

• Cambiamento dello stato della riparazione
• Data di riconsegna dell’oggetto

La fase di riconsegna si conclude con la stampa della Scheda di Riconsegna da consegnare al cliente come ricevuta.

Queste operazioni concludono quello che abbiamo definito come processo di riparazione.
Risulta chiaro dall’analisi, che connesse direttamente al processo di riparazione, ci sono tutta una serie di informazioni secondarie  non di minore importanza.
In particolare il nostro sistema dovrà contemplare la presenza di :

1. Anagrafica Clienti, Fornitori, Centri Esterni di Assistenza, Committenti
2. Tabelle, per l’inserimento rapido delle informazioni
3. Aggancio a sistemi terzi per la notifica a mezzo SMS dello stato delle riparazioni

Ritengo concluso il secondo articolo della serie, che è servito esclusivamente come descrizione del problema.
Scopo del prossimo articolo sarà quello di “avanzare un proposta di architettura“.
Non mi resta quindi che finire con il classico :
See u in the next episode

(Fonte : Alessandro Forte - http://www.alessandroforte.it/)

1. Il sistema operativo è Windows Vista
2. Il Visual Studio 2008 è esente da Service Pack 1 (che è la mia ultima speranza…ovviamente installo e riposto se risolvo)

Ogni aiuto è davvero ben accetto.

Ho inviato già qualche mail di segnalazione errori, entrando anche nello specifico dell’errore…vista la tecnologia adoperata : Il nostro amato Asp.Net.
Non mi resta che attendere che il bug-fix sia completato!

In questa serie di articoli, mi pongo un duplice obiettivo.
Il primo è quello di portare a termine un lavoro che mi hanno commissionato.
Il secondo è quello, ben più sperimentale e interessante, di portare a compimento il lavoro che mi hanno commissionato tramite il vostro aiuto, rendendo poi libero il codice sorgente dell’applicativo.
Ho pensato di sviluppare il primo open source software in Co-Produzione con i miei utenti.
E ho deciso di sfruttare sia il mio blog personale che quello dello UG a cui appartengo per diffondere e rendere noto il mio progetto.
Per Co-Produzione (o per meglio dire Co-Design/Co-Production/Co-Brand) intendo la capacità, partendo da miei suggerimenti, di raffinare i concetti basandomi totalmente sui vostri suggerimenti e vagliandoli uno ad uno.

Ma passiamo subito alla fase operativa e cerchiamo di capire :

1. Cosa dobbiamo realizzare?
2. Come lo dobbiamo realizzare?
3. Chi lo deve realizzare?
4. Perchè lo dobbiamo realizzare insieme?

Rispondiamo per punti alle varie domande, partendo in ordine inverso.

Perchè lo dobbiamo realizzare insieme
Il concetto di Co-Design, Co-Produzione, ecc… mi è venuto leggendo una nota rivista. Viene attualmente utilizzato in moltissimi settori e anche in informatica.
Ovviamente nel settore informatico l’Open Source ne rappresenta un degno esempio .
Chi lo deve realizzare
Io sarò il primo sviluppatore “ufficiale” (diciamo che quasi non ve l’aspettavate giusto?).
A me si aggiungeranno tutti colori i quali saranno ritenuti validi al corretto svolgimento delle attività.
Per validità non intendo solo il punto di vista strettamente tecnico, ma anche e sopratutto coloro i quali mostreranno serietà e dedizione.
Spero di avervi convinto almeno un pò

Come lo dobbiamo realizzare
Ecco qui viene il bello della faccenda. Poichè io questo sistema lo devo realizzare e commercializzare, proporrò step by step la mia visione del lavoro. Abbraccerò tutti i punti di vista. Spazierò dall’architettura, all’organizzazione del codice, alla schedulazione delle milestones, ecc…
Ma il punto di forza del progetto, come già ripetuto diverse volte, sarà la vostra visione e il vostro modo di interagire con il sottoscritto apponendo critiche e suggerimenti alle soluzioni che di volta in volta proporrò

Cosa dobbiamo realizzare
Il progetto da realizzare è il GeRi acronimo di Gestione Riparazioni.
Il software in questione dovrà risolvere tutti i problemi (e vi assicuro che ve ne sono tanti) legati alla gestione delle riparazioni. Inoltre il termine Riparazione deve assolvere a qualunque significato gli sia dato all’interno di contesti diversi quali possa essere un centro di assistenza telefonica piuttuosto che un negozio di computer.

Ritengo concluso il mio primo articolo della serie, che è servito esclusivamente come manifesto.
Scopo del prossimo articolo sarà quello di “dare una descrizione esaustiva del problema da risolvere“.
Tutto questo in preparazione dei primi articoli veri e propri che verteranno sull’acquisizione dei requisiti, sull’architettura sul sistema, e su come realizzare il sistema in esame.
Non mi resta quindi che finire con il classico :
See u in the next episode

Porta il nome dello psicologo Charles Spearman che lo ideò nel 1904 e viene indicata solitamente con la lettera greca ρ_s (rho).

Diversamente dal coefficiente di correlazione lineare di Pearson, non misura una relazione lineare anche qualora venissero usate misure intervallari.

E’ alla base di uno dei metodi (ovviamente ho semplificato di tantissimo la definizione) che ci troviamo ogni giorno ad utilizzare quasi senza accorgercene…
Vi e’ mai capitato di dover giudicare, sulla base di N parametri, se due “giudizi” risultano uguali?
Bhe’ questa e’ la forma Matematica che consente di pervenire scientificamente al risultato.

Non e’ che improvvisamente io sia impazzito ed ho cominciato a pensare a caso al coefficiente di Spearman eh sia chiaro…la conoscenza mi e’ stata passata da un esperto di Marketing Internazionale con cui sto elaborando un nuovo software che ha l’intento di correlare Marketing e Informatica da un punto di vista che oserei definire un po’ “nuovo”…
Affascinato da cotanta meraviglia ho perso 30 min. del mio tempo per scriverne un software.
Lo allego per chiunque volesse “guardarlo” : Scarica qui