Design advice request (somewhat but not completely Roassal focussed)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Design advice request (somewhat but not completely Roassal focussed)

Ben Coman
This is stretching the scope of this list, I am looking for some OO design advise (related to using Roassal for my application).  I've been playing around with this for a while but stalled a bit right now.  I'm  just looking for some general comments to give me something to stimulate my focus.
 
Much of the usage of Moose and indirectly Mondrian/Roassal is related to software analysis.  However I want to use Rossal as the basis for a Computer Aided Design drawing application
based on a predefined standardized model [1][2].  Part of me thinks that in line with keeping a separation of model and view, many/most of the classes of this model may require a matching parallel class for its graphical representation - perhaps one that inherits from ROShape or ROElement.  However the graphical representations need to follow the same inheritance path as the model.  For instance, there is a "Container" which has several subclasses which I need to look the same as the "Container" class. At some point I guess do need to link a graphic to each class, so I was thinking that at a minimum the model might have a standard selector #shape which returns the class of the graphic eg...
    MyModelClass1>>shape
       ^ MyModelClass1Shape
or...
    MyModelClass1>>shape
       ^ ROBox + ROCircle
...my thinking being that specifying "what should be drawn was a lite enough coupling to be reasonable, leaving the "how to draw it" defined elsewhere.

However there are different types of diagrams with different representations of model elements, so perhaps with only a few diagram types I could just use a few selectors like MyModelClass1>>schematicDiagramShape and MyModelClass1>>wiringDiagramShape, or otherwise would require some class to maintain a mapping (DiagramType, ModelClass, Shape)

There actually is an associated standard for Graphics Exchange [3] that I ultimately may align myself with, but not really worried about for now.

Anyhow, not sure if you can make sense of any of that but any advice will be appreciated.

cheers -ben

[1] International Electrotechnical Commission IEC61970 Common Information Model for Power Systems
[2]  https://cimphony.com/cim-intro.pdf just have a quick look at Figs 3.9, 3.10., 3.13
[3] http://cimug.ucaiug.org/Meetings/Milan2010/Presentations/15%20IEC%2061970-453.pdf
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Design advice request (somewhat but not completely Roassal focussed)

abergel
> Much of the usage of Moose and indirectly Mondrian/Roassal is related to software analysis.  

That was true at the beginning of Moose. It is not true anymore. You can model really anything in Moose. Moose give you saving/loading of any arbitrary model, browsing, metrics, visualization, ...

> However I want to use Rossal as the basis for a Computer Aided Design drawing application
> based on a predefined standardized model [1][2].  Part of me thinks that in line with keeping a separation of model and view, many/most of the classes of this model may require a matching parallel class for its graphical representation - perhaps one that inherits from ROShape or ROElement.  

For the visualizations in Moose, we have the following convention of using #viewXXXOn:
For example, a famix class know how to render itself as a UML diagram (e.g., FAMIXClass>>viewUML, viewUMLOn:). It also knows how to render a blueprint (e.g., FAMIXClass>>viewBlueprint, viewBlueprintOn:).
Visualizations can be easily composed. For example, a FAMIXClassGroup has a method #viewUML, #viewUMLOn: and so on...

I suspect you will need for your domain to scope your visualization and have different representations. You may want to follow the same convention.


>     MyModelClass1>>shape
>        ^ MyModelClass1Shape
> or...
>     MyModelClass1>>shape
>        ^ ROBox + ROCircle

It could be:
MyModelClass1>>viewOn: aMondrianBuilder
       

Hope it helps
Cheers,
Alexandre




> ...my thinking being that specifying "what should be drawn was a lite enough coupling to be reasonable, leaving the "how to draw it" defined elsewhere.
>
> However there are different types of diagrams with different representations of model elements, so perhaps with only a few diagram types I could just use a few selectors like MyModelClass1>>schematicDiagramShape and MyModelClass1>>wiringDiagramShape, or otherwise would require some class to maintain a mapping (DiagramType, ModelClass, Shape)
>
> There actually is an associated standard for Graphics Exchange [3] that I ultimately may align myself with, but not really worried about for now.
>
> Anyhow, not sure if you can make sense of any of that but any advice will be appreciated.
>
> cheers -ben
>
> [1] International Electrotechnical Commission IEC61970 Common Information Model for Power Systems
> [2]  https://cimphony.com/cim-intro.pdf just have a quick look at Figs 3.9, 3.10., 3.13
> [3] http://cimug.ucaiug.org/Meetings/Milan2010/Presentations/15%20IEC%2061970-453.pdf
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev