Re: [racket-users] Re: Racket + Graphviz

2019-08-03 Thread Neil Van Dyke

Hadi, that looks great so far!

There are some adornments you can still add, such as to indicate which 
attributes are candidates for being keys (or are keys), but those can 
just be added to existing text strings.


One important thing still to do is labeling the relations.  You might do 
it with a name for each relation (which usually is read in one 
direction), and/or with with names for the respective role each entity 
plays in each relation.  One reason for this (just mentioning it for 
racket-users) is that, in practice, it's not-unusual to end up with 
relations for which the purpose is not obvious, and even multiple 
relations among the same pair of entities (and in the case of multiple 
relations, each expressing role cardinalities in your meta-model, which 
one is which).


Another reason for naming associations, which might be more semantics 
than you want to get into for your immediate purpose, is that there's 
richer semantics one might use in analysis, which might end up conflated 
in current implementation, *but* that can be useful to capture for 
documentation, and maybe also sometimes useful as a cognitive prompt 
while working through it.


For an old example, if you're modeling a system involving multiple 
companies and their employees, you might start with Company and Employee 
entities, and maybe label the many-to-many relation between them 
Employment.  But, when you go place a Salary attribute, you see it could 
be considered an attribute of the Employment named relationship between 
a Company and a Person (optional role names: Employer and Employee), and 
you realize that it's useful for other parts of your system to talk 
about a Person as distinct from being an Employee (e.g., for 
representing multiple employments of a person, and things about a person 
distinct from any employment). And maybe, in your analysis model, 
attributions of a relation is how it appears (if your ER meta-model 
supports that), which preserves the roles, even though, in the 
implementation, that ends up mapping to implementation the same as an 
entity does (to, e.g., a table or object class).


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/eb94edd2-4a8b-e5bf-967d-9a28dd53e323%40neilvandyke.org.


Re: [racket-users] Re: Racket + Graphviz

2019-08-03 Thread Hadi Moshayedi
On Thu, Aug 1, 2019 at 12:23 PM Ryan Kramer 
wrote:

> This looks interesting! I have thought about trying to generate Entity
> Relationship diagrams given a database schema, but assumed that laying out
> the boxes would be a hard problem. Looks like GraphViz might do a decent
> job at this. I'll try it out and let you know how it goes.
>

I actually tried this today. I added a function er-diagram which you can
find an example
usage of at https://gist.github.com/pykello/639746c78498135f0fc1a9947cb92fe0

The script linked above generates the following diagram:

[image: image.png]

Not perfect, but not too bad.

You can find implementation of the er-diagram function at
https://github.com/pykello/racket-graphviz/blob/master/lib/erdiagram.rkt

(The API for the package is evolving, so I am holding off on writing a
documentation until
it becomes stable. But thanks to Stephen, I've uploaded the package to the
package catalog,
so you can now do "raco pkg install racket-graphviz")

-- Hadi

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAK%3D1%3DWqz5R1vUOeRa65frF_CxFDSEw2Uhzc%2B27PYoUOZmZrhEw%40mail.gmail.com.


Re: [racket-users] Re: Racket + Graphviz

2019-08-01 Thread Neil Van Dyke

Hadi Moshayedi wrote on 8/1/19 4:14 PM:
On Thu, Aug 1, 2019 at 12:23 PM Ryan Kramer > wrote:


This looks interesting! I have thought about trying to generate
Entity Relationship diagrams given a database schema, but assumed
that laying out the boxes would be a hard problem. Looks like
GraphViz might do a decent job at this. I'll try it out and let
you know how it goes.

Yesterday I learnt that also PlantUML can be used using stdin/stdout 
interface and it can generate SVG, which can be converted to Pict 
using rsvg. I was thinking spending some time on trying to have some 
kind of Racket library for that too. It might be a better tool for 
generating ER diagrams. See http://plantuml.com/ie-diagram


I tend to use UML's notation for "static object modeling" when doing 
what's essentially entity-relationship modeling.  (There's other UML 
models, but usually people just mean the main diagram, and often just to 
show only attributes and inheritance and nothing else.  Few people might 
do rigorous state modeling, protocol event traces, etc.)


Your DB schema is relational?  If you're willing to represent DB 
relational tables and columns as UML classes with attributes, the UML 
notation might be more compact and understandable than an ER one you'd 
use, but you have to decide how much of the DB semantics you want to 
represent, and how.  For example, if you want to talk about DB joins you 
use, you might just use only attribute annotations for candidate keys, 
*or* you might use much more visual UML associations that are in 
addition to the attributes.  (For target implementations *without* joins 
like that, you'd probably instead use association roles, without 
attributes at all, and indicate navigability directions of the 
associations.)


Regarding laying out the boxes, that particular UML notation might be 
modeled as a constraint satisfaction problem, but it's a tricky one.[1]  
For example, in practice, you might usually want your generalization 
associations to have a high priority for super being above sub, usually 
less so for aggregation assemblies, link attributes (if you have those) 
tending to come off a horizontal edge, etc.  Then you get into things 
like edge routing for reducing crossings and bends, while still spacing 
out your vertices, plus the various adornments on edges that complicate 
things.  And maybe you want stability of layout between changes to also 
be a factor... One of the several methodologists' camps that went into 
UML (and from which that particular UML notation largely came), Rumbaugh 
et al.'s OMT, developed an interactive diagramming tool that was more 
limited than real CASE systems, but did the best job of constraint-based 
interactive editing that I'd seen (but not enough constraints to do 
automatic layout): OMTool, from a GE lab.[2]


[1] For a similar visual language, my industry R&D group once hired a 
very smart PhD student in computational geometry graph drawing to tackle 
it, and they made some progress, but it still wasn't entirely a solved 
problem afterwards.


[2]  Racket aside: I actually used OMTool, until I no longer had access 
to it, and kludged up a simple but practical Java generator/updater for 
it, "https://www.neilvandyke.org/jomtool/";. You'll notice Jomtool was 
written in Emacs Lisp, rather than Java, even though I was an early Java 
expert and advocate, and working in Java.  When I went looking for a new 
platform for rapid R&D work, especially in PL and symbolic Web 
processing, I admitted that a Lisp was more productive than my beloved 
Java for many things, and I ended up choosing Scheme.  Even though 
Scheme didn't have basic OO features, and I'd been working very heavily 
in OO architecture/design/OOP/methodology, and had been invited to be on 
a UML committee -- it still looked like a win.  Scheme turned out to be 
a good choice for those R&D purposes, but industry is a much longer and 
more complicated story, and there are disruption opportunities close on 
the horizon.


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/f36020f9-acbd-d126-3013-ebe8eb2655af%40neilvandyke.org.


Re: [racket-users] Re: Racket + Graphviz

2019-08-01 Thread Hadi Moshayedi
On Thu, Aug 1, 2019 at 12:23 PM Ryan Kramer 
wrote:

> This looks interesting! I have thought about trying to generate Entity
> Relationship diagrams given a database schema, but assumed that laying out
> the boxes would be a hard problem. Looks like GraphViz might do a decent
> job at this. I'll try it out and let you know how it goes.
>

Yesterday I learnt that also PlantUML can be used using stdin/stdout
interface and it can generate SVG, which can be converted to Pict using
rsvg. I was thinking spending some time on trying to have some kind of
Racket library for that too. It might be a better tool for generating ER
diagrams. See http://plantuml.com/ie-diagram

-- Hadi

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAK%3D1%3DWq_MFLn4tHrfCWYGyC1qGdvYKGS7C_CxBy7Z4Zxfto4Pg%40mail.gmail.com.


[racket-users] Re: Racket + Graphviz

2019-08-01 Thread Ryan Kramer
This looks interesting! I have thought about trying to generate Entity 
Relationship diagrams given a database schema, but assumed that laying out 
the boxes would be a hard problem. Looks like GraphViz might do a decent 
job at this. I'll try it out and let you know how it goes.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/9566c624-74ce-4e8d-a332-00fc5b582ba4%40googlegroups.com.


[racket-users] Re: Racket + Graphviz

2019-08-01 Thread Stephen De Gabrielle
this looks very nice! Thank you for sharing this. 

Don't forget to put it in a `package` and publish it on 
https://pkgs.racket-lang.org/ 

kind regards, 

Stephen 


On Wednesday, July 31, 2019 at 11:52:05 PM UTC+1, Hadi Moshayedi wrote:
>
> Hello Racketeers,
>
> Recently I've started thinking about on how we can create different kinds 
> of diagrams in Racket. One of the tools that seemed easy to be exposed as a 
> library in Racket seems to be Graphviz. You can pipe in the graph 
> definition into it and it will pipe out the json layout of how to draw the 
> graph.
>
> So I started working on https://github.com/pykello/racket-graphviz, which 
> is in early stages, but I thought I can share here for some feedback.
>
> Some highlights are:
>  - Digraphs are defined as s-expressions
>  - (digraph->pict ...) converts the digraph to a Racket Pict which can be 
> composed with other Picts and you can use in slideshow, etc.
>  - Graphviz has some standard node shapes, but with this library you can 
> use any Pict value as the node shape! See the examples in the README file.
>
> I have plans like being able to query the layout of each node so we can 
> draw an arrow from a Graphviz layout to anything else.
>
> After making this something useful, I was thinking about writing some 
> other libraries to make different kinds of system diagrams (sequence 
> diagram, timeline diagram, ...) easy to generate in Racket.
>
> Any feedback? Do you think this can be useful?
>
> -- Hadi
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/f43b67f9-d594-4702-8d04-311b91244147%40googlegroups.com.