Sviluppo Progetto in MSAccess

Proposta: per i dati perche' non appogiarsi a SqlServer, a mio vedere prenderebbe 10 punti di professionalita'

saluti

Il padre di quel progetto è Willy, io sono al massimo lo zio avendo offerto solo qualche funzione e un paio di idee.

Sua è la visione di assieme che sarebbe utile in questo di progetto; fin'ora però non si è fatto avanti. Gregorio invece ha esperienza specifica sul tema, sarebbe un ottimo punto di partenza la struttura del suo db.

Ciao

Un saluto a tutti.

Mi inserisco nel thread cercando di ampliare gli elementi e nel contempo indicare dei punti di riflessione.

Premesso che applicativi che permettano di automatizzare in tutto o in parte le fasi del ciclo di vita del software (analisi, progettazione, realizzazione, manutenzione e relativa documentazione e utility) ve ne sono una moltitudine (sviluppati nel corso del tempo) che coprono quegli aspetti ricorrenti che potevano facilitare il compito dello sviluppatore.

In ogni caso, da quanto evidenziato:

accessato wrote: l’idea è quella di predisporre un “GESTIONALE” con l’intenzione di renderlo, il massimo possibile, VERSATILE, cioè applicabile in più settori (dalla gestione del magazzino di un negozio di confezioni, al negozio di articoli sportivi o allo studio di un dentista

gregorio wrote: Ho un mdb che forma la banca dati - dati fissi e altri mdb con le tabelle per ogni attività ... Evidentemente l'esempio su esposto potrebbe essere una base di partenza per una più approfondita analisi, che per me è importantissima prima di iniziare lo sviluppo di qualsiasi programma

Obiettivo sarebbe quindi realizzare un applicativo general-purpose che favorisca il compito di chi debba affrontare problematiche informatiche nell'ambito gestionale.

Un primo fattore è quello di avere disponibili le informazioni delle strutture dati e delle loro relazioni.. E' tutta quella fase in cui si analizza l'esigenza e si cerca di ricondurla ad un insieme correlato di tabelle.
Questo è l'elemento più importante che proviene dall'esperienza dello sviluppatore (che può comprendere, in tutto o in parte, le figure professionali di progettista, analista o programmatore).

E' quindi una attività che, come evidenziato da Gregorio, cerca di re-impiegare il software precedentemente sviluppato appoggiandosi a strutture dati in parte fisse ed in parte variabili che rendono personalizzato l'applicativo.

Di conseguenza già realizzare un ambiente ove sia possibile inserire le strutture dati e avere un legame fra le tabelle in ambito amministrativo-contabile è una facilità per chi alle prime armi si trovi a dover affrontare problemi di gestione e magari non abbia una visione d’insieme delle problematiche da affrontare. Per cui parte con determinate strutture dati e dopo deve sconvolgerle per adattarle alle esigenze magari perché l’analisi preventiva non è stata adeguata.
In un contenitore di questo tipo dovrebbe confluire l’esperienza di chi ha realizzato progetti (più o meno complessi) in modo che si possa coprire una casistica più ampia di casi. Ciò faciliterebbe anche chi non ha una specifica esigenza in un determinato problema ma questa magari, verrà informatizzata in una successiva fase.
Faccio un esempio per rendere più chiaro il concetto: immaginiamo di avere la gestione contabile con (clienti, fornitori, acquisti, tentata vendita, fatturazione, magazzino ecc) e magari vi sia, nell’azienda in oggetto, l’esigenza di generare in proprio una serie di prodotti per cui vi sia il bisogno di integrare l’applicativo con una “distinta base” e strutturare la tabella articoli in elementi base e composti.
Già quindi la conoscenza della problematica e/o l’ insieme di processi automatici (che ne possono scaturire) favorisce la soluzione della problematica e la crescita complessiva di chi deve realizzarla.

Un primo aspetto (che la procedura dovrebbe coprire) sarebbe, quindi, quello di poter gestire le tabelle dati e le loro relazioni.
Può essere realizzata in Access anche se è chiaro che potrebbe trovare soluzione in qualsiasi ambito o linguaggio di programmazione e magari anche slegato dall’ambiente di sviluppo.

Creato il “data-repository” della conoscenza di base sulle “strutture dati e le loro correlazioni” nasce il problema di generare le strutture dati di impiego effettivo e/o l’accesso ai dati stessi. In questo caso realizzare separatamente FE (Front-End) e BE (Back-End) mi pare naturale. E’ da tenere presente che appoggiarsi per il BE ad un database più complesso di Access quali SQL-Server, MySQL. Oracle ecc. sarebbe auspicabile che fosse una funzionalità disponibile.
Per quanto riguarda il FE si possono generare delle maschere di interfaccia (sulla scorta delle tabelle). E’ quindi una funzionalità simile a quella disponibile in Access che “crea una tabella mediante una creazione guidata” in cui si seleziona la tabella e in un elenco di campi si indica quelli di interesse. Già qui, però, nasce una problematica la generazione può avvenire “una tantum” (magari nella fase di inizializzazione) oppure per una esigenza integrativa effettuata successivamente.
Se l’applicativo tiene traccia di quanto creato è possibile effettuare più volte la generazione. Vi è però un ulteriore vincolo che dipende da quanto viene aggiunto al di fuori della struttura di gestione. Nel passato i generatori di applicazioni permettevano dei punti di iniezione (contrassegnati in qualche forma) in modo che il codice prodotto potesse reinserire quelle parti personalizzate.
Inoltre un ulteriore aspetto problematico nasce dall’esigenza di gestire le tabelle correlate in un sistema automatico di generazione. Qualora la struttura è fissa (perché analizzata a priori) è possibile fornire delle soluzioni predefinite Se invece è dinamica diventa più complesso generare a run-time le relazioni e i relativi contenuti. Se poi le relazioni comprendono più di due tabelle si incrementa la difficoltà in quanto le strutture possono comprendere vari tipi di “viste”.

Per quanto indicato da accessato e laky_66 sulla licenza: io propongo la licenza GNU (General Public License). La “Licenza Pubblica Generica” stabilisce che il programma è software libero ed è possibile ridistribuirlo e / o modificarlo secondo i termini (della GNU General Public License) come pubblicata dalla Free Software Foundation

Tale motivazione scaturisce dall'esame, alla luce odierna, di come sono andati, anche nel passato, progetti di integrazione in ambito amministrativo-contabile
Questo in quanto se vediamo progetti (che possiamo considerare similari come problematica) gestiti in modo centralizzato da IBM al massimo del suo fulgore negli anni 80

Ad esempio le “Applicazioni Contabili” in Basic (non Visual Basic) con vari pacchetti di gestione aziendale, contabilità, fatturazione, paghe e stipendi ecc. in cui le software-house italiane sviluppavano sotto supervisione IBM sono state subito soppiantate come si è reso disponibile un linguaggio più strutturato integrato nel database (vedi Dbase e Clipper). Inoltre è da tenere presente la parcellizzazione delle software-house e le peculiarità che ciascun sviluppatore non hanno portato, nel nostro paese,  ad un criterio condiviso su progetti comuni.

Forse un successo maggiore lo hanno avuto le ACG (Applicazioni Contabili Gestionali) prodotte da IBM per il mercato italiano su S/36-38 e AS/400 ma queste erano fornite, quasi a corredo del sistema hardware e con costi comprensivi che venivano ripartiti nella soluzione che la software-house (affiliata-IBM) assicurava nel progetto complessivo di personalizzazione.

Anche progetti successivi (quali Zucchetti, Maggioli, ecc) si sono basati sul supporto fornito all’applicativo realizzato , magari a fronte delle variazioni normative, per cui le software-house (magari rivenditori del pacchetto) hanno apportato delle integrazioni ma sempre in una logica che potremmo dire “chiusa” sulla realizzazione stessa.

Alla luce delle esigenze odierne, dovendo rivolgersi ad un pubblico amplio quale quello del forum e facendo affidamento proprio sull’utenza che possa implementare tale applicativo mi pare logico che l’unica strada sia quella di un pacchetto “open”.

Ritengo che prima di avviare la realizzazione del codice si debba scrivere un documento in cui si stabiliscano le linee guida, gli obiettivi e le modalità di realizzazione, in modo che chi voglia partecipare (anche in una fase successiva) possa valutare il proprio apporto (del tutto volontario) e quindi ritengo senza scopi di lucro, ma anzi come una attività di “volontariato” in favore di chi magari è alle prime armi con tali problematiche. Credo che ciascuno possa fornire il suo contributo, magari quale tester su un ambiente particolare o nella documentazione a supporto.

Anche se prematuro, mi vedo in linea con Gregorio sull’impiego di Access 2003 (in quanto piattaforma di più largo utilizzo e che contiene le funzionalità di base per interfacciarsi a sistemi più ampi). Anche l’opportunità, intravista da Accessato, del “cloud” (Office 365) può essere presa in considerazione. In ogni caso, come ho indicato prima, l’aspetto pratico/realizzativo definitivo, lo valuterei successivamente. Come ho indicato, inizialmente, ritengo prioritario stabilire l’obiettivo e il quadro di riferimento con un documento in cui ciascuno possa riconoscersi, e se lo ritiene, partecipare al team.

Buon lavoro a tutti

Willy

P.S. Per chi voglia ampliare gli argomenti allego dei link ove è possibile prendere in considerazione elementi correlati che riguardano i programmi Open-Source e utilità per Access (Tools, RAD, generatori di codice ecc.) che potrebbero avere un influsso sul progetto.

Definizione di Software Libero (Open Source)
http://www.gnu.org/philosophy/free-sw.it.html
http://it.wikipedia.org/wiki/Open_Source_Definition

Esempi di gestionali Open Source
http://sosopensource.com/it/187.html
http://www.giovannizuccaro.it/tecnologia/7-progetti-open-sou rce-che-vale-la-pena-seguire/
http://grigio.org/gestionali_open_source_tutti_gusti

Software RAD (Rapid Application Development)
http://en.wikipedia.org/wiki/List_of_rapid_application_devel opment_tools

Discussioni su RAD con alcuni aspetti di Access
http://it.toolbox.com/blogs/smunk/a-word-about-rapid-applica tion-development-tools-10351
http://blogs.office.com/b/microsoft-access/archive/2009/10/2 1/net-developer-blogs-about-access-2010.aspx
http://searchcloudcomputing.techtarget.com/feature/Microsoft -brings-rapid-application-development-to-the-cloud

Creazione interfaccia utente con Access
http://www.databasedev.co.uk/user-interface-builder.html

Creare Add in per Access o VB
http://msdn.microsoft.com/en-us/library/Aa155702
http://msdn.microsoft.com/en-us/library/Aa260355
http://www.tdeinformatica.it/Articoli/AddInForAccess.aspx
http://access.mvps.org/access/resources/downloads.htm

Data Access Layer
http://www.radsoftware.com.au/articles/dataaccesslayerdesign 1.aspx

Alternative ad Access come Front-End
http://stackoverflow.com/questions/221995/ms-access-front-en d-alternative

Utility per database
http://www.codeproject.com/KB/database/

Tools con Access
http://www.mztools.com/v3/download.aspx
http://officetipsandmethods.com/?p=580
http://www.caspio.com/l/default.ashx?s=385&gclid=CK_WpLa c86sCFSVItAod6iIQiQ

Editor in VB
http://msdn.microsoft.com/en-us/library/Aa201309