Hi, I built a new visualization that has two goals: 1. show how the architecture of a system is fluid rather than rigid. 2. look good and serve as advertisement device for Moose, Roassal and Pharo. A description of mainly point 1. can be found here: http://www.humane-assessment.com/blog/system-attraction/ I already used it as a splash screen for a couple of presentations, and it catches the eye. The code can be found in Moose, in a separate tiny FAMIXSystemAttraction class. You can invoke it on any class group (note: it can take a long time to render for large groups). Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"
I think this is the nicest looking visualization made so far with Roassal. Consider it for the next Roassal contest next year. Amazing job! Truly beautiful. Alexandre On Oct 3, 2013, at 6:34 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I built a new visualization that has two goals:
1. show how the architecture of a system is fluid rather than rigid. 2. look good and serve as advertisement device for Moose, Roassal and Pharo.
A description of mainly point 1. can be found here: http://www.humane-assessment.com/blog/system-attraction/
I already used it as a splash screen for a couple of presentations, and it catches the eye.
The code can be found in Moose, in a separate tiny FAMIXSystemAttraction class. You can invoke it on any class group (note: it can take a long time to render for large groups).
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Cool! It really catches the eye, Doru! On Oct 3, 2013, at 11:37 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
I think this is the nicest looking visualization made so far with Roassal. Consider it for the next Roassal contest next year.
Amazing job! Truly beautiful.
Alexandre
On Oct 3, 2013, at 6:34 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I built a new visualization that has two goals:
1. show how the architecture of a system is fluid rather than rigid. 2. look good and serve as advertisement device for Moose, Roassal and Pharo.
A description of mainly point 1. can be found here: http://www.humane-assessment.com/blog/system-attraction/
I already used it as a splash screen for a couple of presentations, and it catches the eye.
The code can be found in Moose, in a separate tiny FAMIXSystemAttraction class. You can invoke it on any class group (note: it can take a long time to render for large groups).
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Tudor, I found your visualisation very interesting, and wondered about one thing linked to your blog post and if I got it right. The visualisation you're showing is able to show, at the single class level, if a class is more or less regular (i.e. tidy == well designed?) but you show that it will loose very shortly it's tidy shape if the classes it joins to are added to the visualisation. And I wondered if this was a choice on the graph layout algorithm you've choosen, i.e. that maintaining the tidiness of the class could be done with a different layout algorithm? Maybe one which has a measure of tidiness of the class at the local level, and weight it against the position and attraction of its links to the other components in the application? In the mean time, I'm slowly discovering we have amazing software architecture visualisation tools :) Would really like to setup a project on that if I get the chance. Regards, Thierry Le 03/10/2013 23:34, Tudor Girba a écrit :
Hi,
I built a new visualization that has two goals:
1. show how the architecture of a system is fluid rather than rigid. 2. look good and serve as advertisement device for Moose, Roassal and Pharo.
A description of mainly point 1. can be found here: http://www.humane-assessment.com/blog/system-attraction/
I already used it as a splash screen for a couple of presentations, and it catches the eye.
The code can be found in Moose, in a separate tiny FAMIXSystemAttraction class. You can invoke it on any class group (note: it can take a long time to render for large groups).
Cheers, Doru
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Hi, On Fri, Oct 4, 2013 at 1:41 PM, Goubier Thierry <thierry.goubier@cea.fr>wrote:
Hi Tudor,
I found your visualisation very interesting, and wondered about one thing linked to your blog post and if I got it right.
The visualisation you're showing is able to show, at the single class level, if a class is more or less regular (i.e. tidy == well designed?) but you show that it will loose very shortly it's tidy shape if the classes it joins to are added to the visualisation. And I wondered if this was a choice on the graph layout algorithm you've choosen, i.e. that maintaining the tidiness of the class could be done with a different layout algorithm? Maybe one which has a measure of tidiness of the class at the local level, and weight it against the position and attraction of its links to the other components in the application?
My argumentation is that if we look at a class isolated it will have a certain shape, and because we are exposed to this view (the IDE is always showing me only that) all the time we will optimize it such that the shape is tidy. But if we look at the class in the context of its interactions the shape will be less recognizable. The chosen layout is a very simple one, and the goal is not to say whether the structure is good or bad. This is neither good nor bad. It simply argues how steering the architecture has to take these forces into account. In the mean time, I'm slowly discovering we have amazing software
architecture visualisation tools :)
They really are amazing :). If you want to get more information about it, you can join the Moose mailing list: http://www.moosetechnology.org/about/contact Would really like to setup a project on that if I get the chance.
What do you mean? What kind of a project? Cheers, Doru Regards,
Thierry
Le 03/10/2013 23:34, Tudor Girba a écrit :
Hi,
I built a new visualization that has two goals:
1. show how the architecture of a system is fluid rather than rigid. 2. look good and serve as advertisement device for Moose, Roassal and Pharo.
A description of mainly point 1. can be found here: http://www.humane-assessment.**com/blog/system-attraction/<http://www.humane-assessment.com/blog/system-attraction/>
I already used it as a splash screen for a couple of presentations, and it catches the eye.
The code can be found in Moose, in a separate tiny FAMIXSystemAttraction class. You can invoke it on any class group (note: it can take a long time to render for large groups).
Cheers, Doru
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
-- www.tudorgirba.com "Every thing has its own flow"
Le 04/10/2013 14:14, Tudor Girba a écrit :
Hi,
On Fri, Oct 4, 2013 at 1:41 PM, Goubier Thierry <thierry.goubier@cea.fr <mailto:thierry.goubier@cea.fr>> wrote:
Hi Tudor,
I found your visualisation very interesting, and wondered about one thing linked to your blog post and if I got it right.
The visualisation you're showing is able to show, at the single class level, if a class is more or less regular (i.e. tidy == well designed?) but you show that it will loose very shortly it's tidy shape if the classes it joins to are added to the visualisation. And I wondered if this was a choice on the graph layout algorithm you've choosen, i.e. that maintaining the tidiness of the class could be done with a different layout algorithm? Maybe one which has a measure of tidiness of the class at the local level, and weight it against the position and attraction of its links to the other components in the application?
My argumentation is that if we look at a class isolated it will have a certain shape, and because we are exposed to this view (the IDE is always showing me only that) all the time we will optimize it such that the shape is tidy. But if we look at the class in the context of its interactions the shape will be less recognizable. The chosen layout is a very simple one, and the goal is not to say whether the structure is good or bad. This is neither good nor bad. It simply argues how steering the architecture has to take these forces into account.
Hum, my point would be that a locally well designed class is a factor to strive for; also that the overall architecture has it's impact on it as well, but not so as to so easily erase the local good property when looking at the visualisation, otherwise the latter may not end up so usefull, that's all. I do agree with your point, I just believe the layout could carry a bit more insight in trying to both show the local property the code was trying to achieve (and areas where it failed) and the "emergence" of the architecture coupling on it. Your representation seemed to imply that local good design is unimportant in the architectural view, and I'm sure this is not what it is supposed to convey.
In the mean time, I'm slowly discovering we have amazing software architecture visualisation tools :)
They really are amazing :). If you want to get more information about it, you can join the Moose mailing list: http://www.moosetechnology.org/about/contact
I'll do once I have a strong/practical incentive :) I know its there, Stéphane showed a lot of interesting things in it when he came here, but I didn't managed to organize things around that subject.
Would really like to setup a project on that if I get the chance.
What do you mean? What kind of a project?
Collaborative R or R&D project :) Only way I can justify working on something like that... A good fit would be visualisation of large software in my lab expertise area : high performance and real time massively parallel software on embedded systems. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Hi, On Fri, Oct 4, 2013 at 2:42 PM, Goubier Thierry <thierry.goubier@cea.fr>wrote:
Le 04/10/2013 14:14, Tudor Girba a écrit :
Hi,
On Fri, Oct 4, 2013 at 1:41 PM, Goubier Thierry <thierry.goubier@cea.fr <mailto:thierry.goubier@cea.fr**>> wrote:
Hi Tudor,
I found your visualisation very interesting, and wondered about one thing linked to your blog post and if I got it right.
The visualisation you're showing is able to show, at the single class level, if a class is more or less regular (i.e. tidy == well designed?) but you show that it will loose very shortly it's tidy shape if the classes it joins to are added to the visualisation. And I wondered if this was a choice on the graph layout algorithm you've choosen, i.e. that maintaining the tidiness of the class could be done with a different layout algorithm? Maybe one which has a measure of tidiness of the class at the local level, and weight it against the position and attraction of its links to the other components in the application?
My argumentation is that if we look at a class isolated it will have a certain shape, and because we are exposed to this view (the IDE is always showing me only that) all the time we will optimize it such that the shape is tidy. But if we look at the class in the context of its interactions the shape will be less recognizable. The chosen layout is a very simple one, and the goal is not to say whether the structure is good or bad. This is neither good nor bad. It simply argues how steering the architecture has to take these forces into account.
Hum, my point would be that a locally well designed class is a factor to strive for; also that the overall architecture has it's impact on it as well, but not so as to so easily erase the local good property when looking at the visualisation, otherwise the latter may not end up so usefull, that's all.
I do agree with your point, I just believe the layout could carry a bit more insight in trying to both show the local property the code was trying to achieve (and areas where it failed) and the "emergence" of the architecture coupling on it. Your representation seemed to imply that local good design is unimportant in the architectural view, and I'm sure this is not what it is supposed to convey.
There are many visualizations that try to capture good and bad, but I distinctly did not want the visualization to be about this. It is about how context changes the shape. As a consequence, architecture does not exist without the context, and as the context evolves in millions of little ways, so does architecture. Constantly. That is all. The main goal is to support technical people argue when discussing with managers, rather than necessarily having a say about the value. But, here is a challenge: would you like to play with it and propose a different approach? Btw, the current implementation has 19 lines :).
In the mean time, I'm slowly discovering we have amazing software
architecture visualisation tools :)
They really are amazing :). If you want to get more information about it, you can join the Moose mailing list: http://www.moosetechnology.**org/about/contact<http://www.moosetechnology.org/about/contact>
I'll do once I have a strong/practical incentive :) I know its there, Stéphane showed a lot of interesting things in it when he came here, but I didn't managed to organize things around that subject.
Would really like to setup a project on that if I get the chance.
What do you mean? What kind of a project?
Collaborative R or R&D project :) Only way I can justify working on something like that...
A good fit would be visualisation of large software in my lab expertise area : high performance and real time massively parallel software on embedded systems.
Perhaps you can get some inspiration of places to use Moose in on the humane-assessment.com site. In particular, on the blog I try to offer examples and stories for how assessment should change the face of development :). Cheers, Doru Thierry
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
-- www.tudorgirba.com "Every thing has its own flow"
On Thu, Oct 3, 2013 at 11:34 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I built a new visualization that has two goals:
1. show how the architecture of a system is fluid rather than rigid. 2. look good and serve as advertisement device for Moose, Roassal and Pharo.
A description of mainly point 1. can be found here: http://www.humane-assessment.com/blog/system-attraction/
I already used it as a splash screen for a couple of presentations, and it catches the eye.
The code can be found in Moose, in a separate tiny FAMIXSystemAttraction class. You can invoke it on any class group (note: it can take a long time to render for large groups).
I try to render the system attraction visualization. Nice work ! But very slow even on small examples ... Do you use a magic trick to enhance the performance ? Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
But very slow even on small examples ... Do you use a magic trick to enhance the performance ?
Not really. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
System Attraction is pretty, but slow due to the complexity of the force based layout. Doru On Wed, Oct 16, 2013 at 1:34 PM, Alexandre Bergel <alexandre.bergel@me.com>wrote:
But very slow even on small examples ... Do you use a magic trick to enhance the performance ?
Not really.
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- www.tudorgirba.com "Every thing has its own flow"
It would be great to have a domain specific force based layout. For example, if you want to connect methods with their defining classes, and have many classes on screen. It is more important to have a strong repulsion between the classes, than having the methods of a class repulsing from methods from another class. Alexandre On Oct 16, 2013, at 11:09 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
System Attraction is pretty, but slow due to the complexity of the force based layout.
Doru
On Wed, Oct 16, 2013 at 1:34 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
But very slow even on small examples ... Do you use a magic trick to enhance the performance ?
Not really.
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Does this make sense to you? I would like to have this as a student project for next semester Alexandre On Oct 16, 2013, at 11:27 AM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
It would be great to have a domain specific force based layout.
For example, if you want to connect methods with their defining classes, and have many classes on screen. It is more important to have a strong repulsion between the classes, than having the methods of a class repulsing from methods from another class.
Alexandre
On Oct 16, 2013, at 11:09 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
System Attraction is pretty, but slow due to the complexity of the force based layout.
Doru
On Wed, Oct 16, 2013 at 1:34 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
But very slow even on small examples ... Do you use a magic trick to enhance the performance ?
Not really.
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Wed, Oct 16, 2013 at 4:27 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
It would be great to have a domain specific force based layout.
For example, if you want to connect methods with their defining classes, and have many classes on screen. It is more important to have a strong repulsion between the classes, than having the methods of a class repulsing from methods from another class.
I like the idea, but what do you mean by domain-specific ? Do you want to visualize something else than software ? -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
For example, if you want to connect methods with their defining classes, and have many classes on screen. It is more important to have a strong repulsion between the classes, than having the methods of a class repulsing from methods from another class.
I like the idea, but what do you mean by domain-specific ? Do you want to visualize something else than software ?
The force base layout gives to all the edges and nodes the same value. But maybe, if you can tell that some nodes are more important than other, then the complexity can be significantly reduced. The algo can be used for anything that is represented as a graph. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
That does sound interesting. So the new (student-based) force algorithm would allow for a 'everything is equal' default, or set a certain class of things as more important than others. Or maybe a hierarchy of things a more important (so, classes most important, then packages, then whatever is left over). I haven't yet personally figured out how I would apply this yet (even the original use), but I am definitely thinking on it. And, yes, if I do find a use, it will probably be outside of software as well. I am really enjoying this toolset known as Moose - both for software analysis, and other business-related analysis. -Chris On Wed, Oct 16, 2013 at 10:12 AM, Alexandre Bergel <alexandre.bergel@me.com>wrote:
For example, if you want to connect methods with their defining classes, and have many classes on screen. It is more important to have a strong repulsion between the classes, than having the methods of a class repulsing from methods from another class.
I like the idea, but what do you mean by domain-specific ? Do you want to visualize something else than software ?
The force base layout gives to all the edges and nodes the same value. But maybe, if you can tell that some nodes are more important than other, then the complexity can be significantly reduced.
The algo can be used for anything that is represented as a graph.
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
That does sound interesting. So the new (student-based) force algorithm would allow for a 'everything is equal' default, or set a certain class of things as more important than others. Or maybe a hierarchy of things a more important (so, classes most important, then packages, then whatever is left over).
Yes
I haven't yet personally figured out how I would apply this yet (even the original use), but I am definitely thinking on it.
And, yes, if I do find a use, it will probably be outside of software as well. I am really enjoying this toolset known as Moose - both for software analysis, and other business-related analysis.
:-) Alexandre
On Wed, Oct 16, 2013 at 10:12 AM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
For example, if you want to connect methods with their defining classes, and have many classes on screen. It is more important to have a strong repulsion between the classes, than having the methods of a class repulsing from methods from another class.
I like the idea, but what do you mean by domain-specific ? Do you want to visualize something else than software ?
The force base layout gives to all the edges and nodes the same value. But maybe, if you can tell that some nodes are more important than other, then the complexity can be significantly reduced.
The algo can be used for anything that is represented as a graph.
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (6)
-
Alexandre Bergel -
Chris Cunningham -
Goubier Thierry -
roberto.minelli＠usi.ch -
Serge Stinckwich -
Tudor Girba