Newsgroup: it.comp.programmare
Titolo: Progetto gestionale vendita al dettaglio in c#

Salve a tutto il newsgroup.
Sono alle prese con un'esercitazione corposa dell'uso dell'oop.
Ho scelto un gestionale di vendita al dettaglio e fatturazione per il 
mio progetto pilota.
Il linguaggio che vorrei utilizzare è il c#.
Il problema è abbandonare il modo di pensare procedurale ed abbracciare 
quello oop: ma non da un punto di vista teorico ma mettendo in pratica 
quello che ho appreso per un progetto, un pò + corposo.
Es. Fornitore e Cliente potrebbero essere un'unica classe no ??
Mi serve documentazione in tal senso e se magari c'è già del codice 
pronto tanto meglio.
thanks.


Posto che il problema è tutt'altro che semplice (anzi è molto articolato), parti 
utilizzando una o più matite e tanta carta. In questi casi il PC va utilizzato 
solamente nell'ultima fase.
Alcuni passi da seguire (a mio avviso) sono:
1) stesura delle specifiche: cosa deve fare il sw e come lo deve fare. 
Caratteristiche del sw in termini di librerie per salvataggio dei dati: dbms 
relazionali o binari, con serializzazione degli oggetti o traduzione dei dati in 
un formato binario.
Comunicazione del sistema con altri sistemi uguali (più postazioni che lavorano 
in modo concorrente, ad esempio) o comunicazione con altri sistemi esistenti 
(importazione/esportazione).
Architettura client/server o distribuita o accesso singolo.
Supporto per utenti e simili.
2) stesura dei diagrammi relativi al back-end, ossia tutta quella parte del sw 
che tratta solamente la gestione dei dati.
3) stesura dei diagrammi relativi ai front-end (la grafica) con schemi delle 
pagine di controllo (come devono essere fatte, cosa devono fare, chi deve accederci)
4) Iniziare a mettere giù uno schema dei dati per il dbms e lo schema delle classi
5) Riguardare gli schemi fatti al punto 4 per correzioni e/o aggiustamenti
6) Reiterare il punto 5 fintanto che è necessario
7) A questo punto puoi iniziare a sviluppare il sw (mi raccomando i commenti)
*Consiglio* commenta bene tutto il codice in modo da poter utilizzare programmi 
che estrapolano la documentazione dal sw stesso. Ne avrai bisogno.
8) generare test con Nunit per parti significative del codice
9) ogni volta che modifichi una parte già scritta, lancia di nuovo i test di nunit
Nunit è un sistema che permette di verificare l'invarianza delle classi: ogni 
modifica ha numerosi effetti collaterali. Questo test ti permette di verificare 
che modifiche fatte al sw non introducano errori in altre parti del sw.
In caso di test falliti, verifichi se è il caso di correggere gli errori o 
aggiornare il test.
10) segui scrupolosamente il progetto fatto fino a prima del punto 7. Con un 
progetto ben fatto, le specifiche non dovrebbero subire cambiamenti. In caso di 
errori o imprecisioni (modifiche al progetto) il prgretto andrebbe rivisto per 
essere verificato nella sua interezza.
Questo accadrebbe in teoria. In pratica piccole modifiche possono capitare. Se 
fossero necessarie modifiche strutturali dovresti bloccarti e ripartire dal 
punto 1, perché ci sono errori gravi nella progettazione.
11) fai testare il sw da qualcun altro.
Detta in modo molto semplice (in realtà sarebbe ancora più complesso) dovresti 
seguire questi passi.
Su alcuni dettagli, come ad esempio l'equivalenza tra fornitori e clienti, la 
risposta viene dal punto 4.
In alcune realtà le due entità sono equivalenti, in altre hanno profonde 
differenze, per esempio i fornitori possono essere fornitori di prodotti o 
fornitori di servizi, i clienti potrebbero avere informazioni relative a 
fatturazioni o consegne o magazzini a loro dedicati.
Luca

Luca Pascali ha scritto:

Ti ringrazio della spiegazione schematica che mi hai dato, ma ho come la 
sensazione che mi sono confuso + le idee.
Perchè non unire le idee, magari con altre persone, e abbozzare un 
progetto assieme ?
Es.
Anagrafiche : Fornitori, Clienti, Articoli
Gestione    : Fattura immediata Fornitore/Cliente
               Vendita a dettaglio
Magazzino   : Movimenti di magazzino.
tanto per iniziare da dei punti fermi.

 
Mi sembra di capire che tendi a confondere la struttura del DB con la struttura 
del programma.
Intanto dimmi, come vuoi salvare i dati? vuoi utilizzare un dbms relazionale 
(msde, mysql, sqlite, postgresql, altro?) o serializzare oggetti su file?
La domanda non è banale come sembra.
Il motivo è dato dal fatto che nel caso di un dmbs relazionale fornitori, 
clienti, articoli ed altro sono assimilabili a semplici strutture dati. Oggetti 
per la gestione diventano quindi solamente le fatture e i magazzini. La vendita 
al dettaglio è solo una procedura di prelievo da magazzino e inserimento in fattura.
Lo studio per fornitori, clienti, articoli, magazzino e fatture va fatto sul 
dbms per avere uno schema scalabile, efficente e congruente (aka non deve essere 
riprogettato alla minima variazione, non deve rispondere in ere geologiche e non 
si deve perdere i pezzi per strada).
Nel caso tu voglia utilizzare la serializzazione di oggetti per salvare i dati, 
allora anche tutte le entità come fornitori clienti e articoli vanno strutturati 
con una gerarchia di oggetti opportuna.
Purtroppo questi punti fermi sono ancora troppo generici. Del resto il progetto 
che hai in mente di realizzare è tutt'altro che semplice (ci sono decine e 
decine di programmi che fanno queste cose e non sono intercambiabili. La ditta 
dove lavoro ne realizza diversi e i lavori di personalizzazione per il cliente 
sono consistenti).
Ti posso proporre, se si tratta di un tuo esercizio privato, di scegliere un 
progetto un tantino più semplice prima di cimentarti in uno così complesso?
:-)
Luca

Luca Pascali ha scritto:

L'idea di base era quella di utilizzare un dmbs come SQL Server o Mysql.
Capisco che il progetto al quale mi sono indirizzato è piuttosto ostico,
ma è affascinante perchè completo. Non credi ?
Il mio obiettivo è procedere per passi:
cominciando da un db che possa abbracciare molte delle casistiche di un 
progetto di questo tipo e per fare questo non posso che affidarmi a 
gente che conosce il problema.

 gente che conosce il problema.
Allora ti consiglio di iniziare dal risultato: le fatture. Per ora lascia stare 
il magazzino.
Io provo a darti il La (in questo modo, raggiunto il risultato c'è maggiore 
soddisfazione, nel caso puoi sempre chiedere).
Sono sempre fermo sul discorso dividere interfaccia grafica da gestione dati. 
Complichi un poco la vita, ma il progetto viene più ordinato.
La fattura deve contenere una serie di voci con descrizione, prezzo, quantità, 
delle aliquote per le imposte e gli sconti (vedi tu se applicare gli sconti a 
livello di riga, fattura o entrambe), un emettitore (fisso, sei tu che vendi) e 
un destinatario.
Per ora può andare bene così.
L'emettitore, come il destinatario, deve avere una ragione sociale, un recapito 
(indirizzo, telefono, ecc) e una partita iva.
Di differente hai che l'emettitore ha un logo, e il destinatario ha delle 
preferenze per il pagamento (rimessa diretta, riba 30gg, assegno, ecc.) e poi 
vedi tu che altro mettere.
le voci, per ora, possono essere anche solo libere (testo arbitrario).
Iniza ad impostare il progetto in questo modo (occhio alla scalabilità) e usa 
molta carta prima di scrivere codice.
In un secondo tempo puoi provvedere a creare un archivio degli articoli (magari 
classificato) e successivamente anche un magazzino.
Luca

 (magari classificato) e successivamente anche un magazzino.
Se strutturati bene, i moduli potranno pure essere indipendenti tra 
loro, e interagire se installati tutti quanti.