Progettazione database

[lelebug]

Ragazzi avrei bisogno di qualche piccolo consiglio da voi.
Lavoro come programmatore da ormai diversi anni (7 per l'esattezza) e mi sono sempre occupato di sviluppare progetti pronti e non mi sono mai dovuto occupare di analisi o cose di questo genere. Imparo abbastanza facilmente i vari linguaggi di programmazione (java, php, powerbuilder, ecc...) con, secondo me, ottimi risultati.
Da un po' di tempo a questa parte ho deciso di iniziare a creare qualche piccolo progetto (neanche troppo piccoli per la verita) per conto mio, e qui iniziano i guai. Perchè trovo molto difficile creare un progetto da zero, mi sento spaesato in mezzo a concetti quali Class Diagram, modelli er, ecc...
Il guaio è che io non so neanche da dove cominciare e mi sembra così assurdo visto la mia esperienza come programmatore.
Ora la domanda che volevo porvi era: c'è la possibilità di imparare a creare progetti software senza per forza laurearsi in ingegneria informatica oppure è meglio che lascio perdere fin da ora??

Vi ringrazio già da ora per tutti i buoni consigli che riuscirete a darmi.

Lele

[denis76]

Per quanto uno studi anche i programmatori hanno bisogno di una buona dose di senso pratico.

Io non ho mai scritto nulla di importante, ciò che so fare bene è capire quali sono i problemi dei clienti, scrivere qualcosa ed insegnare ai clienti che mediante una procedura al computer, un programma, tali problemi sono più facili da gestire.

[netarrow]

direi che si può imparare.
Penso che una laure in ingegneria informatica o del software risolva il problema, ma non sia indispensabile.
Per fare un progetto ci sono vari processi di sviluppo: a cascata, iterativo, a pianificazione perdittiva e adattiva, vari processi detti "agili" come la XP(eXtream Programming) la FDD(Feature Driven Development e DSDM(Dynamic System Development Method) ecc...
Infine c'è il RUP(Rational Unfied Process) che è un'infrastuttura per la definizione di processi.
Questo RUP ha vari stadi da percorrere:

1. Fase di avviamento, in pratica: "Mettiamo i soldi per questo progetto?"
2. Fase di elaborazione, iterativamente si fa una versione del progetto sempre più raffinata
3 Fase di costruzione, implementazione del software
4. Fase di transizione, attività che non si possono fare iterativamente: distribuire il sistema, formazione utenti ecc...

Uno strumento per modellare sistemi è UML. Ti consiglio "UML Distilled" 3a edizione guida rapida al linguaggio di modellaione standar, di Flower.
Sono 150 pagine, ma ti fanno un ampia introduzione da diversi punti di vista dato che ci sono più opinioni su come usare uml:chi dice di fare abbozzi, il progetto intero, altri che è una perdita di tempo e di usarlo il meno possibile.

[lelebug]

Grazie per i consigli.

Avevo già cercato di documentarmi sulla extream programming, sulle basi dell'UML e sui modelli ER per quanto riguarda i database e penso di aver assimilato abbastanza la teoria, ora quello che trovo veramente complicato è proprio mettere in pratica tutte queste nozioni, perchè quando finisco di creare il progetto e comincio l'implementazione troppo spesso mi succede di dover tornare sul progetto e stravolgerlo nuovamente; lo so che è una cosa normale e che accade a quasi tutti i progetti software però penso che potrei perdere molto meno tempo se seguissi un metodo "collaudato".

Un altro consiglio che vorrei chiedervi è: quando voi iniziate un progetto software aspettate di aver finito tutte le fasi della progettazione oppure cominciate a costruirvi dei "prototipi" da mostrare al cliente per far valutare da lui se state procedendo nella giusta direzione?

Grazie
Lele

[alka]

Originariamente inviato da lelebug
[...] perchè quando finisco di creare il progetto e comincio l'implementazione troppo spesso mi succede di dover tornare sul progetto e stravolgerlo nuovamente [...]

Ti capisco pienamente, dato che mi succede di continuo, sebbene l'effetto collaterale stia diminuendo negli ultimi periodi...forse, espedienti a parte (UML e altri "aiuti") si tratta anche di fare esperienza.

Originariamente inviato da lelebug
Un altro consiglio che vorrei chiedervi è: quando voi iniziate un progetto software aspettate di aver finito tutte le fasi della progettazione oppure cominciate a costruirvi dei "prototipi" da mostrare al cliente per far valutare da lui se state procedendo nella giusta direzione?

Credo che la strada da seguire dipenda particolarmente dal tipo di progetto; ad esempio, esistono casi in cui il cliente vuole seguire una parte del processo progettuale visionando periodicamente dei prototipi, altri casi in cui - per una determinata complessità del progetto, ad esempio - non è possibile fare ciò.

Ti dirò, personalmente sono abituato a passare più tempo sul lato della modellazione prima di passare all'implementazione vera e propria; è un tipo di approccio che ho acquisito negli anni, "aggravato" dalle caratteristiche object oriented dell'ambiente che uso (Delphi).
Tuttavia, esistono casi in cui bisogna equilibrare la modellazione con l'implementazione progressiva del progetto per poter offrire qualcosa da osservare al cliente (o spesso un collaboratore).
Ho dedicato un po' di tempo quest'estate allo studio del linguaggio UML applicato a "progetti reali" e a metodologie che consentano di poter comunque modellare le proprie classi, ma agendo per fasi e ottenendo dei traguardi progressivi, partendo da una vista più ampia e restringendo il campo di analisi. Ho avuto modo di sperimentare con buoni risultati questo metodo, che mi soddisfa dal lato progettuale riducendo il rischio di rifare tutto o stravolgere le classi create, riuscendo comunque a realizzare dei prototipi parziali suddivisi in varie fasi.

Per quanto riguarda l'esistenza di soluzioni collaudate, potresti dare un'occhiata ai Design Patterns.

Ciao!

[lelebug]

Grazie alka.
Potresti darmi qualche link o consigliarmi dei buoni manuali per approfondire i Design Patterns e lo studio del linguaggio UML applicato a progetti reali di cui mi hai parlato.

Grazie

[alka]

Ho letto recentemente UML Applied, una specie di documentazione "da corso" della Ariadne Training, ma credo che fosse più interessante quello suggerito da Bruce Eckel nel suo ormai celebre "Thinking In Java": UML Distilled di Martin Fowler e Kendall Scott.

Per quanto riguarda l'argomento Design Patters, puoi dare un'occhiata a questo sito, tanto per cominciare, anche se l'intera Rete è ricca di risorse a riguardo (basta usare un motore di ricerca). Probabilmente, mi dedicherò presto alla lettura di Thinking in Patterns (with Java), sempre di Bruce Eckel, non appena avrò completato il mio apprendistato autonomo su Java.

Ciao!

[lelebug]

Grazie ancora alka per i link e i consigli sui manuali.

Volevo chiederti ancora un consiglio.
Ora sto realizzando un progetto per un'agenzia di viaggi di un mio amico, in pratica si tratta di realizzare un database con il catalogo degli itinerari di viaggi di istruzione per le scuole, con le relative descrizioni e i relativi servizi associati alla "gita".
Ad ogni servizio vengono associati i prezzi in base alla selezione di alcuni parametri quali stagione, numero di partecipanti, provenienza, ecc...
I prezzi vengono poi presi automaticamente quando si crea il preventivo per la scuola che lo richiede.

La mia domanda è: per progettare un'applicazione del genere è proprio necessario dover creare tutti i diagrammi UML o basta progettare bene il database creando i relativi schemi ER e cominciare subito l'implementazione?
Tieni presente che io ho già un framework con tutti i componenti di cui ho bisogno già pronti; devo solo creare la GUI ereditando i componenti dal framework e associare i singoli campi al database.

Ti faccio questa domanda perchè a volte mi sembra di perdere tanto tempo inutilmente a progettare ogni singolo aspetto dell'applicazione e non avendo molta esperienza nel campo non so se ne vale la pena oppure no.

Grazie mille.
Ciao.

[alka]

Originariamente inviato da lelebug
La mia domanda è: per progettare un'applicazione del genere è proprio necessario dover creare tutti i diagrammi UML o basta progettare bene il database creando i relativi schemi ER e cominciare subito l'implementazione?

Senza entrare nel merito del progetto che stai realizzando, la regola generale (che si applica a tutti i progetti) è che non è (quasi) mai necessario realizzare tutti i diagrammi UML; i diagrammi sono come delle viste ed esistono per esclusiva utilità dello sviluppatore, quindi questo ne realizzerà tanti quanto crede siano necessari per comprendere bene i requisiti del cliente, applicare la propria soluzione e così via.

Poi, la quantità di diagrammi che ti ritroverai alla fine (cioè, quelli che disegnerai tu) dipenderà dalla natura del progetto e dal grado di dettaglio che vuoi raggiungere.

Purtroppo, non posso suggerirti qual è questo grado di dettaglio perchè la croce e delizia dell'UML sta proprio nel fatto che ciascun individuo decide autonomamente quanto approfondire o "decorare".

UML è un mezzo per modellare; io potrei avvalermene e creare 100 diagrammi perchè ritengo di non farcela senza un certo grado di dettaglio, tu potresti averne bisogno solamente di 10 perchè, a tuo avviso, sono sufficienti per avere una panoramica affidabile. E' soggettivo.

Originariamente inviato da lelebug
Tieni presente che io ho già un framework con tutti i componenti di cui ho bisogno già pronti; devo solo creare la GUI ereditando i componenti dal framework e associare i singoli campi al database.

Comprendo benissimo la tua situazione. In definitiva, si tratta di un'applicazione decisamente database bound dove hai principalmente delle maschere associate ai dati, no?
Potresti usare UML per modellare l'interfaccia grafica, se essa è costruita con una gerarchia di classi, oppure se accedi alla base dati usando un OPF, cioè un framework per modellare i dati usando classi che vengono poi immagazzinate all'interno di un database relazionale.
A parte suggerimenti di carattere generale, non saprei consigliarti meglio, perchè non posso conoscere in quali punti cruciali del tuo progetto tu abbia maggiore difficoltà nello scrivere codice che sia "definitivo" o comunque adatto alle caratteristiche preventivate dell'applicazione, quindi manutenibili con facilità.

Originariamente inviato da lelebug
Ti faccio questa domanda perchè a volte mi sembra di perdere tanto tempo inutilmente a progettare ogni singolo aspetto dell'applicazione e non avendo molta esperienza nel campo non so se ne vale la pena oppure no.

Comprendo benissimo. Secondo me, dovresti fare "mente locale" e vedere se, nel tuo progetto, vi sono delle prerogative o delle parti da implementare che ti appaiono "oscure", nel senso che non hai ben chiaro come possano collimare con altre parti dell'applicazione; in tal caso, ricorrere ad UML può esserti d'aiuto, perchè puoi disegnare quelle parti a tutti gli effetti e aggiustarle secondo necessità senza iniziare a scrivere del codice, operazione che potrebbe comportare un grosso dispendio di tempo se devi poi riscrivere tutto. Se conosci i diagrammi UML, utilizza quelli che ritieni indispensabili per descrivere e documentare la situazione critica fino a quando la soluzione, così come espressa dai diagrammi, non ti appare logicamente chiara; da quel punto in poi, scrivere il codice corrispondente è uno scherzo, e tieni conto anche del fatto che puoi riutilizzare i diagrammi per scrivere la documentazione (leggi "valore aggiunto al tuo prodotto finale")

P.S.: i diagrammi UML e ER non sono in mutua esclusione, puoi disegnare gli uni e gli altri per modellare la "business logic" con il primo e la struttura del database con il secondo.

Ciao!

[lelebug]

Quindi a quanto ho capito non esiste una metodologia di progettazione di applicazioni per così dire "collaudata" e che possa andare bene per tutti, per cui non mi resta che continuare a sperimentare sempre nuovi metodi finchè non individuo quello con cui mi trovo meglio . Nel frattempo posso solo cercare di sviluppare al meglio i progetti che ho già in "cantiere" usandoli anche per sperimentare nuove tecniche VVoVe: .

Grazie ancora alka per il tempo che mi hai dedicato, magari andando avanti con la mia "scoperta del mondo della progettazione software" ti disturberò ancora se sei d'accordo, per ora ti saluto.

Ciao