Home Page
Articoli
Tips & Tricks
News
Forum
Archivio Forum
Blogs
Sondaggi
Rss
Video
Utenti
Chi Siamo
Contattaci
Username:
Password:
Login
Registrati ora!
Recupera Password
Home Page
Stanze Forum
.NET Framework
Applicativo costituito da più programmi
lunedì 18 luglio 2011 - 14.01
Elenco Threads
Stanze Forum
Aggiungi ai Preferiti
Cerca nel forum
max81
Profilo
| Newbie
15
messaggi | Data Invio:
lun 18 lug 2011 - 14:01
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
6
messaggi | Data Invio:
mer 20 lug 2011 - 09:12
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
15
messaggi | Data Invio:
gio 21 lug 2011 - 15:52
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
6
messaggi | Data Invio:
gio 21 lug 2011 - 16:47
>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
15
messaggi | Data Invio:
ven 22 lug 2011 - 09:47
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
6
messaggi | Data Invio:
ven 22 lug 2011 - 10:10
>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
15
messaggi | Data Invio:
mar 26 lug 2011 - 09:44
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
6
messaggi | Data Invio:
mar 26 lug 2011 - 10:04
>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
15
messaggi | Data Invio:
mer 27 lug 2011 - 11:02
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
Torna su
Stanze Forum
Elenco Threads
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 !