# [OT] sviluppare un'applicazione

## croot

Devo svilluppare un'applicazione (la mia prima applicazione seria), si tratta di un gestionale.

La mia idea era quella di partire a disegnando la gui e poi passare al cuore dell'applicazione, secondo voi è corretto come approccio ?

Non vorrei ritrovarmi a riscriverla totalmente perchè sono partito col piede sbagliato.

Il linguaggio di sviluppo sarà python e si appoggerà a un db postgresql, le librerie grafiche saranno wx.

Ciao.

----------

## !equilibrium

 *croot wrote:*   

> Devo svilluppare un'applicazione (la mia prima applicazione seria), si tratta di un gestionale.
> 
> La mia idea era quella di partire a disegnando la gui e poi passare al cuore dell'applicazione, secondo voi ï¿½ corretto come approccio ?
> 
> Non vorrei ritrovarmi a riscriverla totalmente perchï¿½ sono partito col piede sbagliato.
> ...

 

si l'approccio che vuoi usare Ã¨ sbagliato, proprio per il motivo che hai detto, finiresti per dover riscrivere in tutto o parte la gui.

p.s.: di programmai gestionali opensource ne esistono svariati, io propendo sempre per estendere un progetto giÃ  esistente e condividerne le risorse piuttosto che creare l'ennesimo programma replica dove cambia solo gui  :Wink:  (ma degustibus)

----------

## .:chrome:.

quello che vuoi adottare è un metodo di sviluppo esistente. non è sbagliato. si chiama out-inside, perché parti dall'esterno (l'interfaccia) e adatti l'interno (il funzionamento) a quello che hai fatto in precedenza. richiede però la perfetta conoscenza a priori di quello che devi fare, preclude l'espandibilità del software in fase di sviluppo, e richiede un'organizzazione impeccabile. se mi dici che è il tuo primo programma lascia stare

secondo me sarebbe più adatto un top-down, in cui fai un'analisi APPROFONDITA di quello che il programma deve fare, stabilisci quali funzioni ti servono, e scrivi il codice partendo da funzioni elementari (magari che non fanno neppure niente) e lo rendi man mano più dettagliato aggiungendo gerarchia di funzioni e codice. se fai così l'interfaccia è l'ultima cosa che fai.

----------

## croot

Scusate non vi ho detto tutto .. il fatto è che l'applicazione esiste già ma è closed source, commerciale e gira solo su win con db access (ossia ha tutti i mali del mondo) e devo "soltanto" "ricopiarla". Pensavo di partire dalla gui perchè comunque la gui non potrà che essere in quel modo li, e magari strada facendo mi sarei fatto anche un'idea di quello che mi serviva "inside".

Secondo voi mi ritroverò comunque nei casini ?

----------

## xchris

la scelta di wx e' corretta perche' e' meglio su windows avere il look nativo (e schifoso) di windows.

Io consiglio di usare un gui designer anche se non avrai vita facile. (il mio preferito era wxglade)

Io sono passato definitivamente a pygtk perche' sotto Linux e' decisamente meglio sia come API che come designer! (glade)

Visto il tipo di progetto (di copia) il tuo approccio va bene. (attenzione pero' al copyright... modifica un po'  :Wink:  )

ciao

----------

## Peach

nn ho mai visto il programma

ma per quanto riguarda la strutturazione, se nn ci avevi già pensato, ti potrei consigliare vivamente una veloce lettura sui design patterns. IMHO.

----------

## Danilo

Non sono daccordo con xchris circa l'approccio: e' il primo programma e piuttosto che iniziare dalla interfaccia direi di iniziare dalla base dati: studiarla e cercare di capire cosa c'e' dietro l'interfaccia.

Si comincia comunque a studiare il problema, chiavi e potenziali rischi (anche di perforformances). 

Poi dopo la base dati (se proprio prudono le dita) passare al disegno della finestra...

Se hai la possibilita' di usare degli editor di maschere e' un'ottima cosa non so per wx cosa consigliarti.

Per i casini mettili comunque in conto.

----------

## federico

 *xchris wrote:*   

> Io sono passato definitivamente a pygtk perche' sotto Linux e' decisamente meglio sia come API che come designer! (glade)

 

Specialmente visto che glade non e' piu' dipendenza.

Io continuo a disegnarea mano i programmi, ma preferisco se vuoi un consiglio un approccio che prevede prima la definizione di quello che deve fare il programma, poi una volta scritte le routine principali, l'interfaccia grafica.

Fede

----------

## !equilibrium

 *croot wrote:*   

> Scusate non vi ho detto tutto .. il fatto ï¿½ che l'applicazione esiste giï¿½ ma ï¿½ closed source, commerciale e gira solo su win con db access (ossia ha tutti i mali del mondo) e devo "soltanto" "ricopiarla". Pensavo di partire dalla gui perchï¿½ comunque la gui non potrï¿½ che essere in quel modo li, e magari strada facendo mi sarei fatto anche un'idea di quello che mi serviva "inside".
> 
> Secondo voi mi ritroverï¿½ comunque nei casini ?

 

se sai "perfettamente" come funziona a livello di codice il programma closed source, allora puoi tranquillamente seguire le linee guide suggerite da me e k.gothmong, non penso avrai casini.

----------

## xchris

@Danilo:

Si sa gia' bene o male come deve essere la GUI. Partire da quella non e' un problema anche perche' e' bene separarla dal corpo del programma stesso (visto che sara' corposo) e quindi eventuali modifiche saranno sempre semplici da fare.

La Gui al momento e' bene o male l'unica cosa definita... partire da qulla almeno non disincentiva chi sta per iniziare.

Partire con un approccio serio al primo programma (serio) mentre si sta studiando un nuovo mondo (wxpython) rischia di diventare una cosa abbastanza pallosetta...

Il mio consiglio:

- GUI (e' l'unica cosa certa)

- definizione strutture dati principali &co

- inizio sviluppo routine principali

ciao

----------

## Sasdo

Ciao, qualche tempo fa mi sono ritrovato nella tua stessa, medesima situazione.

Programma di gestione con database access.

Dovevo rifare il programma per potenziarlo un po', ho avuto fortuna perchè avevo carta bianca, per cui mi sono buttato sul Java.

Avevo tentato un approccio C/C++ ma purtroppo la faccenda si complicava un po'.

Ho portato avanti così il progetto:

- progettato l'interfaccia (sapevo esattamente cosa doveva fare il programma)

- progettato la comunicazione con il db (che ho fatto migrare su MySQL =)

- fatto il resto.

Difficoltà riscontrate:

l'API di Java per stampare su carta è qualcosa di indegno.

Ora ho un programma funzionante, quasi portabile, per nulla espandibile (a meno di rimaneggiamenti sul codice) e (ahimè) scritto da cani, per cui pensavo di rifarlo per bene quando avrei avuto un po' di tempo.

Conclusione?

Anche se sai com'è l'interfaccia, secondo me il consiglio di k.gothmog e altri è da preferirsi.

Ciao!

----------

## SilverXXX

Domandina: sai già come strutturare il programma e il db?

----------

## xchris

cmq in tema di programmazione sapere in anticipo esattamente cosa si vuole... bhe non e' proprio sempre una cosa scontata.

Io sto facendo un mp3player ma ogni giorno devo rivoluzionare perche' ho nuove idee che mi vengono solo nel momento in cui lavoro a qc routine particolare. (intendo idee su funzionalità)

La fantasia diciamo che non aiuta in questo senso  :Laughing: 

La definizione di una GUI pura non pregiudica nulla.(ad es io ho un file gui.glade dentro cui non c'e' nulla delle routine ovviamente)

Ovviamente IMHO

----------

## croot

@silverXXX

no, apparte la gui e il fatto che userò postgreSQL, non ho alcuna idea di come lo strutturerò. Comunque visto che il software è abbastanza complesso oggi mi devo far dare una lezione su come funziona. Tra l'altro so che è multiutente con una gerarchia.. alcuni utenti possono fare certe cose altri altre.. poi quelli in alto nella gerarchia hanno maggiori privilegi.

Per via di access ci sono tante altre limitazioni di cui spero di sbarazzarmi usando pg.

So già che probabilmente una volta scritto dovrò riscriverlo.. sperò di no e farò di tutto per fare un lavoro pulito ma intanto lo metto in conto.

Il software "modello" usa un'unica tabella da 1 giga con decine se non 1-2 centinaia di campi e sicuramente questa struttura del db non è per nulla adeguata.. in teoria ci sarebbero delle utiliti per portare l'intero db su pg ... ma visto che voglio strutturarlo diversamente non mi serviranno a nulla.

Penso che alla fine seguirò i consigli di xchris ed altri ... tra l'altro è esattamente come dice xchris sapere già in anticipo come fare non è semplice.. e secondo me anche poco pratico.. perchè magari ti trovi di fronte a difficoltà la cui soluzione stravolge totalmente i tuoi progetti.. quindi preferisco procedere ed affrontare l'organizzazzione a piccoli bocconi.

Partirò con la gui usando wxglade e contemporaneamente faccio pratica sul programma per capire esattamente cosa fa e farmi un idea di come riprodurlo.

Successivamente affronterò l'organizzazzione del db che è la cosa che più mi interessa...vabbè spero di divertirmi.. ah devo anche ringraziare Peach per l'accenno a design patterns di cui non sapevo nulla e che trovo un argomento molto interessante.

Tra l'altro ho trovato un libro su gorilla.it in italiano che probabilmente comprerò.. grazie a tutti e spero di divertirmi. ciao.  :Very Happy: 

----------

## Danilo

 *croot wrote:*   

> 
> 
> Il software "modello" usa un'unica tabella da 1 giga con decine se non 1-2 centinaia di campi e sicuramente questa struttura del db non è per nulla adeguata.. in teoria ci sarebbero delle utiliti per portare l'intero db su pg ... ma visto che voglio strutturarlo diversamente non mi serviranno a nulla.

 

Aio,  temevo il casino db.

Disegnare una interfaccia sembrerebbe essere la cosa piu' semplice, invece e' solo un modo per spostare il problema a dopo.

Hai le maschere fa una lista delle funzionalita' che implementano le varie maschere ed una di priorita' almeno delle maschere stesse (se non delle funzioni di base): al tuo cliente servono proprio tutte?  Sarebbe il primo programma che vedo.

Parti dalla prima, quella piu' importante, disegnala ed implementa quello che c'e' sotto completamente (o quasi) ti fai le ossa ed impari ad andare avanti.

Ed intanto da uno sguardo alle performances, se sono accettabili, e se non conviene creare qualche piccola tabella nuova. 

Disegnare le finestre (tutte) e poi passare all'implementazione del core te lo avrei consigliato stesso (essendo una copia) se eri gia' esperto, ma in quel caso non l'avresti domandato  :Wink: 

Buon lavoro e facci sapere come va.  :Smile: 

----------

## Sparker

 *croot wrote:*   

> 
> 
> Il software "modello" usa un'unica tabella da 1 giga con decine se non 1-2 centinaia di campi e sicuramente questa struttura del db non è per nulla adeguata..

 

 :Shocked: 

Ma chi mai puo' aver adottato un approccio cosi' orripilante? Probabilmente viola *qualsiasi* regola per la strutturazione di db!!

----------

## Danilo

 *Sparker wrote:*   

> 
> 
> Ma chi mai puo' aver adottato un approccio cosi' orripilante? Probabilmente viola *qualsiasi* regola per la strutturazione di db!!

 

E poi qualcuno si lamenta : "Ma come un mese per aggiungere questa funzionalita' ?"

Gia' visto.

----------

## DevOne

 *croot wrote:*   

> Scusate non vi ho detto tutto .. il fatto è che l'applicazione esiste già ma è closed source, commerciale e gira solo su win con db access (ossia ha tutti i mali del mondo) e devo "soltanto" "ricopiarla". Pensavo di partire dalla gui perchè comunque la gui non potrà che essere in quel modo li, e magari strada facendo mi sarei fatto anche un'idea di quello che mi serviva "inside".
> 
> Secondo voi mi ritroverò comunque nei casini ?

 

Non si parte mai dalla gui...è l'ultima cosa che si fa sempre!!

Questo perchè la gui, e altre parti del codice, sono strettamente dipendenti dall'implementazione dei dati.

Anche se il software che vuoi copiare ha già una gui prestabilita e con tutte le funzionalità già stabilite, ricorda che il tuo clone non le ha

ancora; il che significa che per motivi vari, idee migliori, più funzionalità, inutilità di altre funzionalità ecc..., il tuo software inevitabilmente

risulterà diverso come implementazione in tutti i sensi.

In genere, come ti hanno detto, si parte per prima cosa dall'analisi il più completa possibile sulla base di dati, cercando di includere tutte le funzionalità intenzionate ed eventualmente adattarlo già per esigenze future; poi si procede per quelle che sono gli oggetti o le funzioni che rappresentano il cuore del software (cioè quelle che si occupano di interagire con la base di dati in modo generico: selezione dati, inserimento, cancellazione ecc..., funzioni di manipolazione che possono essere utili/indispensabili) e testarle fino in fondo assicurandosi di non aver commesso errori. Una volta fatto questo, incominci l'approccio top-down (quindi parti dal generico fino ad arrivare allo specifico implementando via via tutte le funzionalità e relative interfacce grafiche.

----------

## klaudyo

Ora, se si obbligato a fare la GUI così pace, ma se hai libertà di scelta nelle tecnologie che puoi usare io ti suggerisco caldamente di trasformare il gestionale in un'applicazione web. 

Ripeto, non so se ti hanno chiesto esplicitamente che l'applicazione deve essere non web. In quasto caso non hai troppa scelta. 

Ti consiglio il web visto che moltissime cose sono più facili e anche l'interfaccia grafica (senza troppe pretese) la fai velocemente. Un suggerimento? PHP.

Anche il suggerimento di partire dai dati secondo me è molto azzeccato. Studia il tuo problema, disegna lo schema ER per il DB e procedi con lo schema fisico del db. Vedrai che molti problemi li avrai già risolti quando inizierai a scrivere l'applicazione (o quanto meno avrai già pensato a come affrontarli!).

Altro consiglio: per il web adotta lo schema 3 tier. Ovvero separa bene il concetto di dati da quello business logic e da quello di GUI. Così facendo il progetto assumerà una forma gestibile. In verità secondo me questo è uno schema validissimo anche per un'applicazione non web. Se poi metti davanti al DB un Web Service allora ancora meglio!!!

Il fatto di dove ricopiare un'applicazione secondo me è la cosa più brutta che ti possa capitare! Perchè non proponi di creare un'applicazione con funzionalità equivalenti, ma diversa? Ti troveresti con un sacco di libertà in più!!!

A ultima cosa. Per esperienza i gestionali sono brutte bestie. All'inizio sembrano facili da realizzare ma nel giro di poco vengono fuori un sacco di problemi!!!! Quindi organizza bene il progetto!

Ciao

----------

## Ic3M4n

tralasciando i metodi per la progettazione di un programma, dato che il mio principale ispiratore, k.gothmog, ti ha già illustrato saggiamente il suo pensiero che condivido, ti presento un'applicazione nata per fare quello che dovresti fare tu, ovvero boa-constructor, attualmente alla release ~0.4.4_alpha, ha come scopo:  Python GUI RAD development tool.

----------

## croot

 *Sparker wrote:*   

>  *croot wrote:*   
> 
> Il software "modello" usa un'unica tabella da 1 giga con decine se non 1-2 centinaia di campi e sicuramente questa struttura del db non è per nulla adeguata.. 
> 
> Ma chi mai puo' aver adottato un approccio cosi' orripilante? Probabilmente viola *qualsiasi* regola per la strutturazione di db!!

 

ok, ieri mi sono fatto illustrare il funzionamento del programma ... è un casino! Cms me lo sono portato a casa e gli ho dato un occhiata più da vicino e ho visto che ci sono una marea di piccole tabelle in formato sempre .dbf e questa mega tabella da 1 giga che raccoglie gli "elementi" che commercializza l'azienda. Penso che il software sia stato progettato in maniera così semplicistica perchè all'inizio non si prevedeva (sia da parte dell'azienda che da parte del programmatore) un volume di documenti così alto.  

@klaudyo

Per quanto riguarda la possibilità di realizzare un interfaccia web non è neanche da prendere in considerazione per le seguenti ragioni:

a)avete in mente degli utenti aziendali che da 10 anni usano sempre lo stesso software ?

b)progettare un applicazione da capo è troppo per le mie capacità in più ho già molta .. moltissima carne al fuoco.

c)è una scusa per imparare python con una gui.

e comunque di certo la mia applicazione non sarà un clone dell'altra che ha parecchie limitazioni... per ex  essa è divisa in tre sezioni gerarchiche per l'inserimento e la manipolazione dei dati. Benchè essa sia multiutente quando un utente ha accesso alla prima sezione nessun'altro utente puo avere accesso alla stessa. Semplicemente perchè il programmatore non è riuscito a risolvere il problema di attribuire più progressivi contemporaneamente. Non so se mi sono spiegato.. faccio un esempio. Un utente deve inserire un elemento e gli viene attribuito un progressivo.. nello stesso momento si connette un altro utente e prende un progressivo che non puo essere quello che è stato assegnato all'altro e non puo neanche essere il successivo perchè:

1) è possibile che il primo utente rinunci a quella registrazione e quindi rimarrebbe un buco nei progressivi

2) è possibile che il primo utente registri più di un elemento che deve essere spesso contiguo a quello precedente perchè riguardante lo stesso cliente

Quindi il programmatore ha pensato bene di negare la registrazione a più utenti in parallelo.. Io voglio dare la possibilità di registrare gli elementi a più utenti contemporaneamente.... e questa è già una cosa che sarà diversa quindi.. non sarà un vero e proprio clone.

@Danilo

No, tante cose ho già in mente di toglierle.. farò le funzioni base e poi via via aggiungerò cose.. riguardo alle performance sono sicuro che quella tabellona è ridicibile in almeno altre 3 tabelle.. cmq è ovvio io cerco di sminuzzare un po'.. 

@Ic4M4n

si conosco Boa... ma ho letto un po' in giro che è instabile .. confermi ? smentisci ?

@DevOne

si l'analisi è una cosa importantissima .. comunque sia procederò partendo dalla gui, poi cuore ed infine unione del tutto..

benchè l'applicazione sia complessa ed io sia al mio primo programma.. la cosa in generale mi sembra abbastanza semplice... ma.. ho idea che all'inizio deve sembrare così a tutti....

ok, grazie a tutti... vi farò sapere.

ciao  :Very Happy: 

----------

