Applicativo costituito da più programmi

lunedì 18 luglio 2011 - 14.01

max81 Profilo | Newbie

Un saluto a tutto il forum,
devo sviluppare un'applicazione per la raccolta di dati provenienti da una rete di sensori industriali, che dovrà gestire la raccolta, l'inserimento in un database e la generazione di report.
Essondo la mia prima applicazione di un certo spessore, in quanto ho sempre sviluppato delle semplici applicazioni, sto valutando come organizzare il programma e volevo un consiglio da voi.
Quello che avrei pensato è organizzare l'applicativo in più programmi console, uno costituito da un server TCP per la lettura dei dati da socket e per l'inserimento in un database, un'altro per la gestione della reportistica giornaliera da inviare via email, ed infine un'applicazione Winform superiore, per la configurazione, l'avvio, l'arresto e la visualizzazione dei file di log dei vari programmi console.
Il tutto sarà realizzato con C#, mentre in un secondo tempo si svilupperà un'applicazione ASP.NET per l'accesso remoto ai dati.
Vorrei sapere cosa ne pensate della soluzione proposta e se avete qualche consiglio da darmi.

Ringrazio in anticipo.

PS. Mi scuso per aver erroneamente postato per sbaglio due volte lo stesso thread.

Salvoro83 Profilo | Newbie

Ciao !
Io ho fatto la stessa cosa già in 4 (medie) aziende ma non credo che esista una risposta assolutamente giusta così come non credo ne esista una assolutamente sbagliata.
Per prima cosa terrei in considerazione che carico di lavoro avrebbe il server che acquisisce e registra i dati sul db.
Mi spiego meglio : se hai a che fare con un ciclo produttivo molto intenso (per esemprio trance che operano magari a 300/400 colpi al minuto, o peggio filatoi che fanno anche 1000 colpi/minuto) e devi registrare dati con cadenze temporali molto strette, lascerei svolgere al server solo quel compito (anche se questo discorso lo devi dimensionare al numero di macchine o di sensori dai quali intendi acquisire i dati).
Un'altra considerazione che farei io sarebbe quella di capire quali necessità di sviluppo future ci sono: se il rilevamento dati dai sensori rimarrà invariato (perchè i sensori o i datalogger che interroghi rimangono sempre quelli) delegherei la creazione dei report ad applicativi separati; questo perchè, in caso di nuove richieste come per esempio l'aggiunta di un nuovo tipo di report, non devi mettere mano alla parte di rilevamento e acquisizione, ma solo a quella di reportistica.
Questo perchè se ti dovesse capitare di trovare dirigenti "creativi" che ogni 20 gg ti chiedono nuove stampe non diventi matto a ricompilare tutto ogni volta.
Cerca di pensarlo in maniera modulare: un bello schema a blocchi di ciò che devi fare potrebbe aiutarti a capire quali sono i "mattoncini" base del tuo sistema.
Se posso permettermi un ultimo consiglio, non lesinare sul periodo di test !
Rompi i maroni fino a che non sei sicuro della correttezza dei dati; pretendi che per un determinato periodo di tempo, lo stesso lavoro che svolge il tuo sw venga svolto in parallelo al vecchio metodo utilizzato per ottenere le stesse informazioni (in modo da confrontare i risultati ottenuti), oppure a mano da una persona selezionata a tale scopo; le verifiche non sono mai abbastanza.
Prendi informazioni su quali possono essere le tue responsabilità nei confronti dell'azienda in caso di problemi: se i report emessi dal tuo applicativo fanno prendere decisioni strategiche all'azienda, come per esempio l'acquisto della materia prima in relazione a quella utilizzata, un piccolo errore potrebbe essere catastrofico.
Ultimissima osservazione : se la tua azienda è certificata secondo qualche sistema di qualità (es. ISO 9001, ISO TS 16949 etcetc) una lettura della norma potrebbe aiutarti a creare il SW in modo che torni utile all'azienda in caso di certificazione o di audit (nel caso fosse già certificata).
Spero di esserti stato di aiuto.
Buon lavoro !

Salvo

max81 Profilo | Newbie

Ciao Salvoro,
ti ringrazio per la risposta e per le considerazioni che hai descritto.
Si tratta di un'applicazione di telemonitoraggio con dinamica non molto spinta, in particolare devo acquisire delle misure da circa una decina di sensori ogni minuto.
Visto che il software dovra gestire due compiti indipendenti, realizzerò due programmi console, uno per ogni compito, così anche per sviluppi futuri non bisogna mettere mano a tutta l'applicazione, ma solo al modulo specifico, inoltre quando aggiungeremo nuove funzionalità, creeremo altri nuovi programmi separati.
La mia idea è quella di controllare il funzionamento dei due programmi attraverso dei file di log, e poi nel programma con winform, caricare le ultime 40-50 righe
all'interno dei textbox.
Ora chiedo un'info tecnica, come posso avviare un'applicazione console da winform e non far apparire la finestra nera della console?

Ringrazio nuovamente.

Salvoro83 Profilo | Newbie

>Ciao Salvoro,
Ciao Max

>ti ringrazio per la risposta e per le considerazioni che hai
>descritto.
Non c'è di che

>Si tratta di un'applicazione di telemonitoraggio con dinamica
>non molto spinta, in particolare devo acquisire delle misure
>da circa una decina di sensori ogni minuto.
>Visto che il software dovra gestire due compiti indipendenti,
>realizzerò due programmi console, uno per ogni compito, così
>anche per sviluppi futuri non bisogna mettere mano a tutta l'applicazione,
>ma solo al modulo specifico, inoltre quando aggiungeremo nuove
>funzionalità, creeremo altri nuovi programmi separati.
Perchè console ?

>La mia idea è quella di controllare il funzionamento dei due
>programmi attraverso dei file di log, e poi nel programma con
>winform, caricare le ultime 40-50 righe
>all'interno dei textbox.
Se il programma esegue sempre lo stesso ciclo di istruzioni (tra l'altro con cadenza fissa e predeterminata di un minuto) a che pro fargli genereare dei log ?
I dati devono essere registrati sul db; fatti avvisare nel caso questo non avvenga, non riempire file con log del tipo : "21/07/2011 - 16:44:25 - Dat inseriti correttamente - tutto ok".
Se poi devi visualizzare dei dati per delle statistiche, non credo che usare textbox sia il modo migliore ;)

>Ora chiedo un'info tecnica, come posso avviare un'applicazione
>console da winform e non far apparire la finestra nera della
>console?

Dim app as New ProcessStartInfo("tuaApp.exe")
app.WindowsStyle = ProcessWindowStyle.Minimized
Process.Start(app)

>
>Ringrazio nuovamente.
Prego

Ciao !

Salvo

max81 Profilo | Newbie

Ho pensato a programmi console in quanto l'utente non deve interagire con essi, in particolare i due programmi devono girare in background, poi il primo ascolta su una porta è appena arrivano dei dati, tramite socket tcp, gli inserisce all'interno del database, invece il secondo programma ad un'ora determinata, creerà un report giornagliero che invierà tramite mail.
La parte che interragirà con l'utente sarà realizzata in un secondo tempo in ASP.NET.
Il log lo utilizzo solo per inserire i messaggi d'errore prodotti dai vari blocchi try-catch, anche se all'inizio pensavo di inserire ogni singolo evento, ma questo lo utilizzo solo per i primi tempi, per verificare che tutto funzioni.

Ciao
Max

Salvoro83 Profilo | Newbie

>Ho pensato a programmi console in quanto l'utente non deve interagire
>con essi, in particolare i due programmi devono girare in background,
A questo punto credo che sia meglio creare un servizio più che un programma console: il programma console non è che non interagisca, interagisce solo in modo diverso (anzichè avere l'interfaccia grafica ha la linea di comando).
Se devi farlo girare minimizzato, che abbia una form o che sia una console, non fa differenza.

>poi il primo ascolta su una porta è appena arrivano dei dati,
>tramite socket tcp, gli inserisce all'interno del database, invece
>il secondo programma ad un'ora determinata, creerà un report
>giornagliero che invierà tramite mail.
Non conosco bene la situazione, ma voglio farmi un po di affari tuoi ;)
se devi creare dei report statistici, non ti conviene aspettare che il dato arrivi; crea un loop, magari con un timer, che legga i dati ogni minuto.
Dico questo perchè in termini di analisi conta anche il valore statico del rilevamento.
se hai deciso di leggerli ogni minuto, interroga i sensori ogni minuto; in questo modo avrai dei report confrontabili tra l'oro in liena temporale.
Esempio : devi leggere il valore di uminidità da una sonda.
Ogni minuto interroghi la sonda e ti registri il valore, fa niente se per due ore il valore è sempre lo stesso; personalmente l'elaborazione, come per esempio l'accorpamento di dati uguali in un intervallo di tempo, preferisco farli in fase di elaborazione, per una questione di completezza dell'informazione registrata.

>La parte che interragirà con l'utente sarà realizzata in un secondo
>tempo in ASP.NET.
ok

>Il log lo utilizzo solo per inserire i messaggi d'errore prodotti
>dai vari blocchi try-catch, anche se all'inizio pensavo di inserire
>ogni singolo evento, ma questo lo utilizzo solo per i primi tempi,
>per verificare che tutto funzioni.
Se usi i log solo per la fase di test, allora sono d'accordo :)

Ti è poi servito il suggerimento sul process.start ?
>
>Ciao
>Max

Ciao
Salvo

max81 Profilo | Newbie

Ciao Salvo,
in questi giorni ho pensato e sono arrivato ad un'idea, creo un programma winform che quando viene avviato crea un'icona nella taskbar, in cui cliccandoci sopra permette di aprire il form.
Per i due compiti creerò due thread avviati e arrestati da alcuni pulsanti sul form.
Per mettere qualche dettaglio in più, non è l'applicazione che scarica i dati, ma è il controller del sensore che ad ogni minuto contatta il server e invia le misure via socket.
Mentre per la gestione della reportistica, il thread dedicato continuerà a ciclare in un while sempre a true, e controllerà l'orario, quando è l'ora impostata, si creerà il report e lo si invia tramite email.
Come la vedi come soluzione? La trovi professionale?

Grazie e ciao.
Max

Salvoro83 Profilo | Newbie

>Ciao Salvo,
Ciao Max,

>in questi giorni ho pensato e sono arrivato ad un'idea, creo
>un programma winform che quando viene avviato crea un'icona nella
>taskbar, in cui cliccandoci sopra permette di aprire il form.
Il modo in cui visualizzi il form credo diventi secondario, quindi sta al tuo personale stile di programmazione.
Spero solo che la macchina dove risiede il sw che interroga i sensori e registra i dati sia dedicata a svolgere SOLO questa funzione.

>Per i due compiti creerò due thread avviati e arrestati da alcuni
>pulsanti sul form.
>Per mettere qualche dettaglio in più, non è l'applicazione che
>scarica i dati, ma è il controller del sensore che ad ogni minuto
>contatta il server e invia le misure via socket.
>Mentre per la gestione della reportistica, il thread dedicato
>continuerà a ciclare in un while sempre a true, e controllerà
>l'orario, quando è l'ora impostata, si creerà il report e lo
>si invia tramite email.
Non mi è molto chiara la situazione, quindi mi limito ad un commento di massima :
Se il tipo di report che devi emettere è sempre uguale e deve avvenire in modo ciclico, non vedo problemi nella tua soluzione.
Ma i sensori li devi interrogare tu o sono configurati (o configurabili) per scrivere il loro dato da qualche parte in modo autonomo ?

>Come la vedi come soluzione? La trovi professionale?
Con qualche informazione in più potrei essere più preciso, magari sapendo che tipo di senosri utilizzi e quali possibilità di comunicazione hanno.
>
>Grazie e ciao.
>Max

Ciao

Salvo

max81 Profilo | Newbie

Ciao Salvo,
purtroppo non posso mettere molti dettagli, è un applicazione innovativa, comunque il server non deve interrogare i sensori, ma è l'elettronica di bordo del sensore che interroga ciclicamente i sensori e invia i dati al server attraverso socket, in particolare il server dovrà solamente prendere i dati in arrivo sulla socket, controllarne il formato e inserirli nel database, mentre il report, che ha sempre la stessa struttura, verrà generato prendendo i dati dal database ad un'ora specifica della giornata.
Adesso devo accantonare un po' la cosa per un altro lavoro.

Ti ringrazio nuovamente.
Max
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2017
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5