[C/C++] Creare una interfaccia ?

[misterx]

ciao,
ho un programmone fatto da un software house che non è più adattabile al nuovo hardware che stiamo per acquistare.

Per rendere compatibile il vecchio software col nuovo hardware, si dovrebbe intervenire pesantemente in esso e forte di questo problema, mi piacerebbe capire come si potrebbe ovviare in futuro a problemi di questo tipo scrivendo qualcosa di più attuale e più furbo.

Non ho esperienze in merito e quindi considero un pò questo 3d una sorta di ricerca per capire cosa fare e cosa usare di già pronto.

Mi basterebbe inventarmi una sorta di lunguaggio (interfaccia) col quale far comunicare il programma lato utente col programma lato hardware che cambia sempre?

[pabloski]

in che senso non più adattabile? è compilato per un'altra architettura?

l'unica cosa che puoi fare, se il problema lo consente, è pilotarlo tramite un altro programma che redireziona l'I/O in modo da passargli dati e ricevere risposte

ovviamente se il programma produce dei file durante l'elaborazione si possono usare quelli per prelevare risultati parziali/definitivi ed importarli nel programma pilota

[misterx]

adattabile nel senso che:


livello programma utente
----------------------------------------
livello libreria del costruttore dell'hardware
----------------------------------------
livello hardware


il livello programma utente è una interfaccia modificabile a piacere e serve a mostrare graficamente lo stato dell'hardware sottostante. Al suo interno ci sono funzioni implementate nella libreria del costruttore.

Ora cambiando sia l'hardware che la libreria si è costretti a modificare in modo massiccio anche il livello utente.

Cercavo uno stratagemma per evitare di toccare in futuro il livello utente in modo che sia del tutto trasparente per l'utente finale il cambio dell'hardware.

[pabloski]

la vedo dura, essendoci una libreria del costruttore....se ci fosse stato un programma del costruttore allora si poteva eseguire il programma cli, leggerne i risultati dallo standard output e visualizzarli

potresti però crearlo tu un programma cli per ogni hardware....in questo modo dovresti comunque creare un nuovo programma per ogni nuovo hardware, ma almeno il programma utente resterebbe immodificato

[cdere]

Originariamente inviato da misterx

Mi basterebbe inventarmi una sorta di linguaggio (interfaccia) col quale far comunicare il programma lato utente col programma lato hardware che cambia sempre?

sì, una interfaccia il più possibile "sottile" da cambiare di volta in volta è l'unica, ti progetti un protocollo (una serie di comandi, o come dici tu, un linguaggio) e l'app che sta sopra non si accorge di nulla, tu ogni volta che ne hai bisogno sai di mettere le mani solo sull'interfaccia che è lo stretto indispensabile

[misterx]

Originariamente inviato da cdere

sì, una interfaccia il più possibile "sottile" da cambiare di volta in volta è l'unica, ti progetti un protocollo (una serie di comandi, o come dici tu, un linguaggio) e l'app che sta sopra non si accorge di nulla, tu ogni volta che ne hai bisogno sai di mettere le mani solo sull'interfaccia che è lo stretto indispensabile

ciao,
ho ad esempio funzioni nella libreria del costruttore del tipo:

- visualizza lo stato di un bit
- carica un programma
- cancella un programma
- setta tutti i bit di un indirizzo a zero etc...

Io dovrei implementare quasi tutte le funzioni presenti nella libreria del costruttore in una mia libreria giusto?

In definitiva avrei

programma utente con le sue interfacce che può non cambiare mai
----------------------------------------------------------------
mia libreria
----------------------------------------------------------------
libreria del costruttore
----------------------------------------------------------------
hardware

[pabloski]

libreria o programma, l'importante è che ci sia un livello che astrae i dettagli della libreria del costruttore

l'unico problema è che tua libreria deve contemplare tutti i casi di librerie del costruttore possibili

[cdere]

Originariamente inviato da misterx

ciao,
ho ad esempio funzioni nella libreria del costruttore del tipo:

- visualizza lo stato di un bit
- carica un programma
- cancella un programma
- setta tutti i bit di un indirizzo a zero etc...

Io dovrei implementare quasi tutte le funzioni presenti nella libreria del costruttore in una mia libreria giusto?

In definitiva avrei

programma utente con le sue interfacce che può non cambiare mai
----------------------------------------------------------------
mia libreria
----------------------------------------------------------------
libreria del costruttore
----------------------------------------------------------------
hardware

yeah!

Originariamente inviato da pabloski

libreria o programma, l'importante è che ci sia un livello che astrae i dettagli della libreria del costruttore

l'unico problema è che tua libreria deve contemplare tutti i casi di librerie del costruttore possibili

no, la sua libreria contemplerà il caso di libreria che implementerà di volta in volta

[pabloski]

Originariamente inviato da cdere

no, la sua libreria contemplerà il caso di libreria che implementerà di volta in volta

quindi una sua libreria per ogni libreria del costruttore

[cdere]

sì

[misterx]

stavo pensando anche ad inventrami un linguaggio molto elementare che verrà usato nell'interfaccia utente del livello più alto.

Avrò necessità di un parser ?

Se così fosse, il codice del parser che cercherà di capire quale funzione ha richiamato l'utente sarà semplicemente una lunga serie di case xyz: ......?

[tomminno]

Originariamente inviato da misterx

stavo pensando anche ad inventrami un linguaggio molto elementare che verrà usato nell'interfaccia utente del livello più alto.

Avrò necessità di un parser ?

Se così fosse, il codice del parser che cercherà di capire quale funzione ha richiamato l'utente sarà semplicemente una lunga serie di case xyz: ......?

Lascia perdere nuovi linguaggi, non arriverai a niente.

Per quanto riguarda il tuo progetto la parte grafica deve gestire a basso livello l'hardware oppure deve fornire delle funzionalità logiche che bene o male astraggono dall'implementazione hardware sottostante?

Parli di "mostrare graficamente lo stato dell'hardware sottostante", questa operazione ha un equivalente logico a più alto livello che non "analizzare il bit-rate sul pin 9"?

Penso che gli harware facciano più o meno le stesse cose (forse di più nel nuovo) e sicuramente in modo differente, ma che possano essere raggruppate secondo funzionalità logiche di più alto livello.

Se si un normale applicativo strutturato a 3 livelli (o più) risolverebbe il tuo problema, la GUI mostra le funzionalità logiche, lo strato intermedio adatta la funzionalità logica a quanto richiesto dallo strato sottostante, la libreria dedicata alla gestione dell'hardware fa il resto. Cambiando fornitore (a parità di funzionalità "logiche" gestite) devi riadattare solo lo strato intermedio, eventualmente aggiungendo nuove funzionalità come moduli indipendenti se la libreria di basso livello lo consente.

Se invece il tuo software è una diretta visualizzazione della libreria hardware, probabilmente data la scarsa frequenza di aggiornamento dell'hardware può anche darsi che convenga più implementare un'interfaccia ad hoc tutte le volte, piuttosto che realizzare un software che in teoria può fare di tutto, che non verrà mai usato per come è stato pensato e che molto probabilmente non lo farà nemmeno bene nel momento in cui sarà richiesto.

[misterx]

Originariamente inviato da tomminno

Lascia perdere nuovi linguaggi, non arriverai a niente.

Per quanto riguarda il tuo progetto la parte grafica deve gestire a basso livello l'hardware oppure deve fornire delle funzionalità logiche che bene o male astraggono dall'implementazione hardware sottostante?

Parli di "mostrare graficamente lo stato dell'hardware sottostante", questa operazione ha un equivalente logico a più alto livello che non "analizzare il bit-rate sul pin 9"?

Penso che gli harware facciano più o meno le stesse cose (forse di più nel nuovo) e sicuramente in modo differente, ma che possano essere raggruppate secondo funzionalità logiche di più alto livello.

Se si un normale applicativo strutturato a 3 livelli (o più) risolverebbe il tuo problema, la GUI mostra le funzionalità logiche, lo strato intermedio adatta la funzionalità logica a quanto richiesto dallo strato sottostante, la libreria dedicata alla gestione dell'hardware fa il resto. Cambiando fornitore (a parità di funzionalità "logiche" gestite) devi riadattare solo lo strato intermedio, eventualmente aggiungendo nuove funzionalità come moduli indipendenti se la libreria di basso livello lo consente.

Se invece il tuo software è una diretta visualizzazione della libreria hardware, probabilmente data la scarsa frequenza di aggiornamento dell'hardware può anche darsi che convenga più implementare un'interfaccia ad hoc tutte le volte, piuttosto che realizzare un software che in teoria può fare di tutto, che non verrà mai usato per come è stato pensato e che molto probabilmente non lo farà nemmeno bene nel momento in cui sarà richiesto.

ciao,
non so se ho colto il tuo dubbio ma allo stato attuale tutto il codice è legato all'interfaccia e quindi se cambia l'hardware sottostante, cambia la libreria e tutti i parametri e sono tanti, che inserisce l'utente nell'interfaccia.

Dunque l'idea è di mantenere l'interfaccia invariata, idem per i parametri in modo da non confondere le idee agli utenti e rendere trasparente agli utenti dell'interfaccia il cambio di hardware sottostante.

In breve, se implementassi un linguaggio del tipo:
MostraStatobit(100)
SettaBit(115)
ResettaBi(10)
etc....

manterrei il livello 1 sempre invariato, al caso, magari con una qualche aggiunta di tanto in tanto ma non sconvolgere tutta l'interfaccia che è molto complessa, soprattutto da gestire.

[misterx]

qualche altra idea?