Buongiorno a tutti,
vorrei avere qualche suggerimento a proposito di tool UML Open Source da utilizzare.
Saluti
Gianni Bianconi
A mia conoscenza non ci sono tool open source UML nati per modellare db spaziali.
L’unico che conosco, e che ho avuto modo di usare abbastanza, è GeoUML Catalogue, che non è (ancora) open source; è scaricabile qui:
http://geo.spatialdbgroup.polimi.it/it/
A differenza di altri tool:
- è nato con lo specifico obiettivo di facilitare la modellazione di db spaziali
- dà la possibilità di generare modelli implementativi diversi (SQL per PostGIS e Oracle, e SHP)
- non è un tool grafico, ma piuttosto “ipertestuale” (quindi più adatto a chi non mastica UML)
Qui, in ogni caso, trovi una lista esaustiva di tool UML sia open che non:
https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools
···
Il giorno 13 agosto 2015 11:43, Gianni Bianconi <gianni.bia@iperbole.bologna.it> ha scritto:
Buongiorno a tutti,
vorrei avere qualche suggerimento a proposito di tool UML Open Source da utilizzare.Saluti
Gianni Bianconi
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
750 iscritti al 18.3.2015
pg
Piergiorgio Cipriano
https://twitter.com/PgCipriano
Il 17/08/2015 20:40, Piergiorgio Cipriano ha scritto:
A mia conoscenza non ci sono tool open source UML nati per modellare db
spaziali.
L'unico che conosco, e che ho avuto modo di usare abbastanza, è GeoUML
Catalogue, che non è (ancora) open source; è scaricabile qui:
http://geo.spatialdbgroup.polimi.it/it/
Perdonatemi la provocazione (ma è una domanda seria, mi piacerebbe
sapere cosa ne pensa chi li usa in produzione): questi strumenti servono
*davvero*? A cosa, in concreto?
Grazie.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
in produzione è molto utile se si sa usare molto bene, altrimenti si perde solo del tempo.
è molto utile in fase di progettazione del DB, cosa che bisogna fare bene altrimenti si avranno casini dopo.
quindi permette una progettazione passando dal modello concettuale a quello logico e si risparmia del tempo nella generazione del DB, nella generazione reale delle tabelle in qualsiasi Sistema di gestione di DB.
io ho fatto delle prove con RISE Editor che ha pure un generatore di DB postgresql.
ma è solo teoria; credo che sia molto più utile a livello accademico o DB con molte tabelle.
···
Il giorno 18 agosto 2015 09:29, Paolo Cavallini <cavallini@faunalia.it> ha scritto:
Il 17/08/2015 20:40, Piergiorgio Cipriano ha scritto:
A mia conoscenza non ci sono tool open source UML nati per modellare db
spaziali.
L’unico che conosco, e che ho avuto modo di usare abbastanza, è GeoUML
Catalogue, che non è (ancora) open source; è scaricabile qui:
http://geo.spatialdbgroup.polimi.it/it/Perdonatemi la provocazione (ma è una domanda seria, mi piacerebbe
sapere cosa ne pensa chi li usa in produzione): questi strumenti servono
davvero? A cosa, in concreto?
Grazie.Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
750 iscritti al 18.3.2015
–
Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51’0.54"N 10°34’27.62"E - EPSG:4326
Il 18/08/2015 14:14, Totò Fiandaca ha scritto:
in produzione è molto utile se si sa usare_molto bene_, altrimenti si
perde solo del tempo.
era anche la mia sensazione: ci puoi fare esempi, ed aiutare a capire
cosa vuol dire in concreto "usare molto bene"?
grazie!
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
Non voglio risponderti al posto di Totò, ma ti dico una mia spiegazione .. se
ti può essere utile !
Quando devi progettare DB molto grossi, intendo con un gran numero di
tabelle (diverse decine) molte delle quali correlate e devi per esempio:
-) capire quali sono le tabelle con i dati "base"
-) quali chiavi ti conviene usare per le relazioni
-) come realizzare tra le relazioni tra tabelle senza ingrovigliarti e
creare "loop"
-) evitare la ridondanza dei dati (nelle diverse tabelle)
.. e per finire "normalizzare" il DB,
se lo fai "a manina" per prove successive, aggiustando/modificando tabelle
e relazioni in corso d'opera, puoi perdere molto tempo e comunque realizzare
un DB poco performante e con l'insidia di bugs, che poi ti spuntano fuori in
seguito, facendo delle queries.
E' in questo casi che un strumento di "DB design" se, come dice Totò "lo sai
usare", ti permette di progettare a monte un buon DB, evitando correzioni
successive,
Ma come ti dicevo primo, è quasi inutile per DB fatti da poche tabelle e
poche relazioni !!
Io per esempio, nella mia esperienza, per GeoDB fin'ora non è ho mai avuto
bisogno.
E' una spiegazione poco "accademica" che spero ti sia utile !
Salutoni
Nino
--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Tool-UML-per-geodatabase-design-tp7593414p7593450.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.
Il 18/08/2015 17:45, nformica ha scritto:
Non voglio risponderti al posto di Totò, ma ti dico una mia spiegazione .. se
ti può essere utile !
E' una spiegazione poco "accademica" che spero ti sia utile !
si', certo, grazie; questo e' anche il mio approccio.
sono sempre stato a favore del principio KISS[0], o per meglio dire del
rasoio di Occam[1]: gli strumenti migliori sono quasi sempre quelli più
semplici. Per questo mi interessa capire quali sono i casi reali in cui
sia giustificato l'uso di strumenti così complessi.
Saluti.
[0] https://it.wikipedia.org/wiki/KISS_(informatica)
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> in produzione è molto utile se si sa usare molto bene, altrimenti si perde solo del tempo.
… come tutti gli strumenti (e non solo quelli software).
Secondo me varrebbe la pena sentire il parere di Stefano Campus o di altri che lavorano in enti e avere una loro opinione.
Personalmente ho usato Rose, Visio, Enterprise Architect, Jude/Astah e ArgoUML (e forse qualche altro tool che non ricordo) e come tutti gli strumenti il GeoUML Catalogue va prima studiato un pochino, poi usato e poi, se e quando saranno disponibili i sorgenti, migliorato e corretto.
Concordo con la citazione di Paolo: il Catalogue è sì migliorabile ma rispetto ad altri tool è decisamente più “KISS”, proprio perché non è necessario conoscere (bene) UML per poter modellare.
Rispetto a quanto ho scritto ieri aggiungo anche che oltre il GeoUML Catalogue, il PoliMI ha sviluppato anche il Validator, che di fatto permette di gestire in maniera immediata e automatica la correttezza dei dati rispetto alla specifica definita (cioè modello dati).
Sia per quanto riguarda la struttura, che la semantica che i controlli, anche topologici intra e interclasse.
···
Il giorno 18 agosto 2015 17:53, Paolo Cavallini <cavallini@faunalia.it> ha scritto:
Il 18/08/2015 17:45, nformica ha scritto:
Non voglio risponderti al posto di Totò, ma ti dico una mia spiegazione … se
ti può essere utile !E’ una spiegazione poco “accademica” che spero ti sia utile !
si’, certo, grazie; questo e’ anche il mio approccio.
sono sempre stato a favore del principio KISS[0], o per meglio dire del
rasoio di Occam[1]: gli strumenti migliori sono quasi sempre quelli più
semplici. Per questo mi interessa capire quali sono i casi reali in cui
sia giustificato l’uso di strumenti così complessi.
Saluti.[0] https://it.wikipedia.org/wiki/KISS_%28informatica%29
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
750 iscritti al 18.3.2015
pg
Piergiorgio Cipriano
https://twitter.com/PgCipriano
spiego meglio il mio pensiero su ‘usarlo molto bene’ facendo un paragone stupido:
quasi tutti usiamo Word o simili, e tutti diciamo che sappiamo usarlo; io invece dico sempre che è uno dei programmi più difficili che abbia mai usato; è facile scrivere una lettera, una lista di cose da fare, ma sfido ad usare Word per scrivere un libro, con capitoli, sotto sottocapitoli, indice, sommario, tabelle, immagini e chi ne ha più ne metta.
In generale saper usare bene un programma semplifica la vita, ma saperlo usare bene è tutt’altra storia.
Usare questi tool semplificano la vita ma bisogna saperli usare bene altrimenti in fase di generazione del DB escono fuori tabelle che non sapevi esistessero (per esempio nei casi di relazioni molti a molti) oppure ti genera nomi dei campi che non credevi avessi creato ecc…
···
Il giorno 18 agosto 2015 17:53, Paolo Cavallini <cavallini@faunalia.it> ha scritto:
Il 18/08/2015 17:45, nformica ha scritto:
Non voglio risponderti al posto di Totò, ma ti dico una mia spiegazione … se
ti può essere utile !E’ una spiegazione poco “accademica” che spero ti sia utile !
si’, certo, grazie; questo e’ anche il mio approccio.
sono sempre stato a favore del principio KISS[0], o per meglio dire del
rasoio di Occam[1]: gli strumenti migliori sono quasi sempre quelli più
semplici. Per questo mi interessa capire quali sono i casi reali in cui
sia giustificato l’uso di strumenti così complessi.
Saluti.[0] https://it.wikipedia.org/wiki/KISS_%28informatica%29
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
750 iscritti al 18.3.2015
–
Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51’0.54"N 10°34’27.62"E - EPSG:4326
Secondo me piu' che sapere usare bene un programma di case serve che
uno sappia far bene la progettazione di un DB.
Se e' bravo e sa progettare un DB, il case puo' anche non servirgli,
almeno finche' le tabelle sono poche.
Se non e' bravo, il case non serve a niente. Non aiuta a risolvere le carenze.
Poi, a parte questo discorso, se le tabelle sono molte serve
sicuramente un CASE, anche solo per gestire la costruzione grafica del
diagramma ER.
Che da sola aiuta moltissimo a identificare i problemi.
Poi, se si scende nell'operativo.
DIciamo che un case , su una progettazione importante , aiuta a
contenere i costi.
Faccio un esempio di brutta pratica.
Brutta pratica e' ad esmepio progettare una base dait pensando di
avere chiaro come debba essere fatta, contando esclusivamente sulla
propria esperienza e conoscenza dei dati, ma senza tenere in acun
conto l'uso che di essa va fatto e senza porsi il dilemma di come
verra' impiegata. Con quali strumenti e con quali meccanismi.
Quello che sovente succede, e' che viene progetttaa una base dati. Poi
su di essa si comincia a realizzare sistemi informativi che la
impiegano.
Quando si arriva in fondo al percorso, e tutto e' stato fatto, arriva
in mano agli utenti e si scopre che alcune informazioni essenziali o
comunque utili sono state trascurate o travisate.
Ecco che la revisione risale fino alla riprogettazione della Base
dati, con tutta una serie di costi che finiscono per esplodere.
Questo modo di operare non e' risolto dall'impiego di un RAD, perche'
l'errore sta' piuttosto nella testa delle persone.
Ci sono pero' altri casi in cui un RAD aiuta a evitare dei problemi.
Quando il problema non è di supponenza di chi progetta, ma piuttosto
di un mero errore materiale nel legare due o piu' tabelle. Nel
definire male una foreign-key o nel legarla al campo errato, magari
legando un campo stringa con un campo intero.
Oppure nel creare degli anelli di relazione che poi renderebbero
difficile la loro gestione.
In tutti questi casi e anche in altri, un buon RAD che controlla la
corretta impostazione delle regoledi integrita' referenziale di una
base dati. Sicuramente aiuta.
AIuta nel senso che se non ci si accorge dell'errore in sede di
progettazione e si passa alla realizzazione . Se si scopre l'errore
durante la programmazione.
Dubito che il programmatore si accolli lui a gratis lonere di
riscrivere il programma perche' il progettista dela DB aveva sbagliato
nel comporla.
Qui casca l'asino.
Se il progettista fosse chiamato a rispondere in solido dell'errata
progettazione di una BD, forse si porrebbe lui per primo il dubbio di
usare strumentiche lo aiutino nel suo lavoro.
Se invece si tratta di un costo che comunque finisce per riadere sul
committente di riffa o di raffa.
Allora il RAD non e' percepito come un aiuto nel proprio lavoro ed' e'
vissuto piuttosto come un costo inutile.
Ma qui forse sono cattivo io.
per cui scusatemi.
Termino citando che nel caso del nostro progetto OMERO.
Con cui si e' realizzato un plugin per qgis (disponibile sul repo di
qgis) per la catalogazione e la gestione di una anagrafe edilizia.
Il progetto e' basato su un db sqlite.
La base dati e' abbastanza complessa per i miei canoni usuali.
Va detto che pero' ce ne sono di ben piu' complicate e per chi lavora
qutidianamente sui DB questa sarebbe pure semplice.
In ogni caos la BD del progetto Omero e' di per se' gia' sufficiente
per essere considerata una BD non piccola e per questo ho dovuto fare
uso di un buon RAD. Nello specifico ho usato un prodotto commerciale
(che mi ero procurato autonomamente).
Con esso ho progettato la base dati e sempre con esso ho potuto
generare in automatico gli scrpts di creazione per sqlite/spatialite.
Le tabelle geometriche , le trattavo come blob e poi modificavo a mano
lo script. Le tabelle con geometria erano poche (2 solamente).
L'impiego del RAD e' risultato pero' fondamentale.
Infatti il committente (altri colleghi) vedevano lo schema grafico, si
discuteva e spesso emergevano esigenze di nuove tabelle o di
correzioni sulle esistenti.
Correggere su uno schema disegnato e poi con un click rigenerare la
miriade di tabelle e rigenerare sul momento anche lo schema grafico ER
in gif e' una comodita' assoluta e ha abbassato molto i tempi e quindi
i costi.
Per chi e' interessato a farsi una idea della base dati o vuole
curiosare nel plugin Omero.
Se vuole se lopuo' installare.
Poi se va nelle cartelle del plugin stesso, ci trova una sottocartella
di documentazione con lo schema grafico in GIF e lo script di
creazione della base dati.
Dal GF capisce subito la dimensione della base dati e la numerosit'a
delle relazione di FK presenti. Impossibili da gestire a mano libera.
Senza commettere errori, anche solo nel tenere allineati ildisegno e
gli script di creazione.
A.
Il 18 agosto 2015 18:18, Totò Fiandaca <pigrecoinfinito@gmail.com> ha scritto:
spiego meglio il mio pensiero su 'usarlo molto bene' facendo un paragone
stupido:
quasi tutti usiamo Word o simili, e tutti diciamo che sappiamo usarlo; io
invece dico sempre che è uno dei programmi più difficili che abbia mai
usato; è facile scrivere una lettera, una lista di cose da fare, ma sfido ad
usare Word per scrivere un libro, con capitoli, sotto sottocapitoli, indice,
sommario, tabelle, immagini e chi ne ha più ne metta.
In generale saper usare bene un programma semplifica la vita, ma saperlo
usare bene è tutt'altra storia.Usare questi tool semplificano la vita ma bisogna saperli usare bene
altrimenti in fase di generazione del DB escono fuori tabelle che non sapevi
esistessero (per esempio nei casi di relazioni molti a molti) oppure ti
genera nomi dei campi che non credevi avessi creato ecc...Il giorno 18 agosto 2015 17:53, Paolo Cavallini <cavallini@faunalia.it> ha
scritto:Il 18/08/2015 17:45, nformica ha scritto:
> Non voglio risponderti al posto di Totò, ma ti dico una mia spiegazione
> .. se
> ti può essere utile !> E' una spiegazione poco "accademica" che spero ti sia utile !
si', certo, grazie; questo e' anche il mio approccio.
sono sempre stato a favore del principio KISS[0], o per meglio dire del
rasoio di Occam[1]: gli strumenti migliori sono quasi sempre quelli più
semplici. Per questo mi interessa capire quali sono i casi reali in cui
sia giustificato l'uso di strumenti così complessi.
Saluti.[0] https://it.wikipedia.org/wiki/KISS_(informatica)
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015--
Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51'0.54"N 10°34'27.62"E - EPSG:4326_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
Ciao Paolo,
la mia esperienza si basa essenzialmente sull’uso di Enterprise Architect per i modelli dati di INSPIRE (qui una visualizzazione HTML http://inspire.ec.europa.eu/data-model/approved/r4618-ir/html/) e lì, così come nel mondo degli standard OGC e ISO geografici, la modellazione parte dall’UML…
Ale
···
On 18/08/2015 09:29, Paolo Cavallini wrote:
Il 17/08/2015 20:40, Piergiorgio Cipriano ha scritto:A mia conoscenza non ci sono tool open source UML nati per modellare db spaziali. L'unico che conosco, e che ho avuto modo di usare abbastanza, è GeoUML Catalogue, che non è (ancora) open source; è scaricabile qui: [http://geo.spatialdbgroup.polimi.it/it/](http://geo.spatialdbgroup.polimi.it/it/)Perdonatemi la provocazione (ma è una domanda seria, mi piacerebbe sapere cosa ne pensa chi li usa in produzione): questi strumenti servono *davvero*? A cosa, in concreto? Grazie.
–
Alessandro Sarretta
skype/twitter: alesarrett
Web: ilsarrett.wordpress.com
Research information: