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!