[TimeTracker] Dal class-diagram al diagramma ER
Ho iniziato a lavorare ad un progetto di cui parlerò fra qualche settimana. Anticipo che si tratta di un TimeTracker, il cui scopo principale è quello di racchiudere vari principi del design object oriented e di metodologie di sviluppo del software. L'obiettivo sarebbe anche quello di creare un presentation layer che offra degli spunti concreti ed infine avere a disposizione un TimeTracker realmente utilizzabile.

Nel frattempo scriverò qualche post durante "l'avanzamento dei lavori". Ho quasi terminato il disegno del class diagram e la cosa che mi ha dato maggiormente soddisfazione al momento è il fatto di essere in grado di generare il database direttamente dal class diagram attraverso NHibernate e la corretta definizione dei file di mapping.

Per un motivo (database già esistente) o l'altro (mancanza di tempo) non ho mai sfruttato questa feature di NHibernate davvero utile.

I due vantaggi sostanziali sono:
- possibilità di generare qualunque database supportato da NHibernate
- definizione dei vincoli nei file di mapping

Anche se alla fine della fiera si tratta solamente di query T-SQL "create table" o "alter table", è stupefacente avere il database (Sql Server 2005) vuoto un momento e il momento dopo averlo completamente popolato ovviamente ottenendo gratis anche il database diagram.

Una cosa fatta meglio del diagramma ER (Management Studio) rispetto al class diagram (VIsual Studio 2008): il metodo di riorganizzazione del grafico... per il resto, beh è come sparare sulla croce rossa :-D. Il confronto tra i due modelli:
Class diagram
Class diagram TimeTracker
Diagramma ER
Diagramma ER TimeTracker

Spero di avere abbastanza tempo per poter andare avanti speditamente :-). In teoria dovrebbe anche entrarci Silverlight 1.1 in minima parte, ma è da vedere.

A breve seguiranno altre notizie.

Matteo Migliore.

Comments

# re: [TimeTracker] Dal class-diagram al diagramma ER
Gravatar Ciao Davide,

ciò che (intepreto) Matteo ha fatto è semplicemente far generare a NH lo script SQL per la creazione dello schema in base a quanto specificato nel mapping.

Concettualmente non ci vedo nulla di male, per il semplice fatto che non è NH ad inventarsi lo schema, che invece è *assolutamente progettato* da chi realizza il mapping. Il problema, semmai, è che si tratta di un approccio utilizzabile solo in casi estremamente semplici, perché quando le tabelle diventano dell'ordine delle centinaia, la vedo dura ad andare avanti senza un apposito strumento di progettazione (che so... Erwin, tanto per citarne uno).

Che poi in questo caso specifico Matteo abbia deciso di mappare *tutta la gerarchia* di classi, tra l'altro in table-per-subclass, trovandosi poi quello schema "strano", è un altro paio di maniche. Ma ribadisco: è una scelta esplicita di Matteo, che magari io e te non condividiamo, ma non è nulla di autogenerato da un qualche tool.
Left by Marco De Sanctis on 1/7/2008 11:01 AM
# re: [TimeTracker] Dal class-diagram al diagramma ER
Gravatar Scusa ma quello che usi non mi sembra il tono da usare sul blog altrui. "Non dire stupidate" evitalo, per evitare che cancelli i commenti. Chi dice stupidate, è stupido, ed io non lo sono. Questo *non* uno spazio dove fare polemica. Detto questo, il modello ER è antecedente, e molto più povero del class diagram. Non esiste behavior per una tabella. Ripeto, la scelta di creare una tabella UniqueObjects è dovuta ad implementazioni future (versioning, localizzazione al momento). Comunque aspetta la fine del progetto, e se vorrai partecipare, tanto meglio! :-). Un saluto amichevole.
Left by Matteo Migliore on 1/7/2008 10:44 PM
# re: [TimeTracker] Dal class-diagram al diagramma ER
Gravatar "il modello ER è antecedente, e molto più povero del class diagram. Non esiste behavior per una tabella. "
Matteo dovresti sapere che il modello relazionale è *ovvio* che rappresenti solamente dati non metodi. Ciò è stato fatto per poter utilizzare solamente una logica dichiarativa per l'implementazione di constraint di validazione delle business rules. In particolare "First order logic": http://en.wikipedia.org/wiki/First-order_logic.

In questo modo in un db relazionale tutto può (dovrebbe) essere definito in modo dichiarativo, permenttendo allo sviluppatore di specifcare COSA vuole ottenere e lasciando il COME all'optimizer (e questa idea è talmente valida che oggi LINQ ti permette di fare la stessa cosa)

Per il resto, ho solo corretto un errore madornale che ha scritto sulla mia persona (che mi ha dato perticolaremente fastidio, visto che se critico o apprezzo un modello lo faccio perchè lo conosco e non per sentito dire).

Non vediamo invettive laddove non ce ne sono :-)

Un saluto amichevole anche da parte mia.
Left by Davide Mauri on 1/8/2008 8:10 AM
# Validation Framework ed Inversion Of Control
Gravatar Validation Framework ed Inversion Of Control
Comments have been closed on this topic.