[Pharo-project] UML diagram (OBEnhancement)
Hi guys, (cc'ed to pharo list - we're talking about the UML diagram used in OBEnhancement) 2009/5/6 David Röthlisberger <roethlis@iam.unibe.ch>:
Hi Cédric,
I also like what you did for the UML diagram.
I didn't push it to the repository because they were some personal choices and you underlined some of them.
Some issues I encountered:
- class-side methods should not be at the bottom, but at the top, and displayed with underlined font to be more UML-compliant.
Oh I forgot about that. Looks ok to me though I don't know yet how to underline text in Mondrian (the text is a single stream with cr's)
- not sure about adding the method protocol. If included, I'd rather go for ordering the method alphabetically and then show the protocol in parentheses
yes there is an ordering problem. The alphabetical order is ok, but printing the protocol beside could lead to long lines and then wide rectangles in the diagrams. Even if not standard, I actually prefer the ordering by protocol mainly because it shows the method intention and it forces to use them. Nevertheless, to be consistent, I'd like to have a list of predefined protocols that can be ordered (initialize, accessing, ...) but this is outside the scope of the UML diagram. Could we agree on that in Pharo (standard list of method protocols) ? Can someone propose a starting point... What do you think ? (we could also provide an alternative ordering trough a popumenu "alphabetical/protocol")
- accessors should be present, IMO.
I agree for the general case but decided to not show them in my diagrams. This is part of a wider strategy. I explore using ivar as slots and hence not consider accessors as methods. Each ivar has automatic accessors that I try to complete with pragma's for further processing. Something like <type: min: max: visibility: >... Just experiencing... but anyways, I find accessing methods adding too much extra noise in the diagrams. I'd prefer completing ivars with their visibility characteristic. Maybe another candidate for the popumenu (hide accessors).
- empty areas at the end should not be shown at all, eg. if there are no class methods, class vars. I'd instead suggest to show class vars underlined in the variable area at the top, class methods underlined at the top of the method area, which means that there are only two areas. If there are no vars or methods defined, keep the empty area, but having two or three empty areas is very confusing (and non-standard).
ok, you're right. Still, I need to know how to underline text... Do I need to use TextAttribute ? Any pointers ?
For classes without methods and vars (there are some of those...) we should only show the rectangle with the class name.
ok.
I'd very much appreciate if you could extend your implementation to address these issues.
I'll try to do so ;) I've also planned to fill menus (browse, implement, senders, variables, etc... + export as PNG + ...) and hoverText (class comment, method definitions ...). Such a diagram could be an alternative/complementary way of browsing code...
Note that OB uses your implementation, as we rely on the class UMLEnhClassDiagram from Alex' Mondrian version containing your extensions.
Yep, I saw that ;) Cheers, Cédrick
Thanks a lot, David
I like your extension. Adding edges will not be a problem. You're the second one to ask for it. I will do some coding tonight or tomorrow, will come back to you soon.
Cheers, Alexandre
On 30 Apr 2009, at 16:59, Cédrick Béler wrote:
Hi Alexandre and David,
I just saw that you merged the development of Mondrian with OBDiagram. Sounds good to me. Though, I missed some information in the UML class diagram, so I did my own. I joined it in cas you'd like it (plus a diagram example). One remark though, I simply remove accessing methods as I find they "pollute" my diagrams. It's ok for me but I guess not for general diagrams.
I actually play more with accessing method so that I can have their status and type (declaration in pragmas). Do you think it will be doable to draw associations between classes (if declared in pragmas) ?
Cheers,
-- Cédrick <UMLFullClassDiagram.st><xorp.png>
I would not put superOb in scriptloader like that you can do what you want and we too :) Stef On May 6, 2009, at 4:18 PM, Cédrick Béler wrote:
Hi guys, (cc'ed to pharo list - we're talking about the UML diagram used in OBEnhancement)
2009/5/6 David Röthlisberger <roethlis@iam.unibe.ch>:
Hi Cédric,
I also like what you did for the UML diagram.
I didn't push it to the repository because they were some personal choices and you underlined some of them.
Some issues I encountered:
- class-side methods should not be at the bottom, but at the top, and displayed with underlined font to be more UML-compliant.
Oh I forgot about that. Looks ok to me though I don't know yet how to underline text in Mondrian (the text is a single stream with cr's)
- not sure about adding the method protocol. If included, I'd rather go for ordering the method alphabetically and then show the protocol in parentheses
yes there is an ordering problem. The alphabetical order is ok, but printing the protocol beside could lead to long lines and then wide rectangles in the diagrams.
Even if not standard, I actually prefer the ordering by protocol mainly because it shows the method intention and it forces to use them. Nevertheless, to be consistent, I'd like to have a list of predefined protocols that can be ordered (initialize, accessing, ...) but this is outside the scope of the UML diagram.
Could we agree on that in Pharo (standard list of method protocols) ? Can someone propose a starting point...
What do you think ? (we could also provide an alternative ordering trough a popumenu "alphabetical/protocol")
- accessors should be present, IMO.
I agree for the general case but decided to not show them in my diagrams.
This is part of a wider strategy. I explore using ivar as slots and hence not consider accessors as methods. Each ivar has automatic accessors that I try to complete with pragma's for further processing. Something like <type: min: max: visibility: >... Just experiencing... but anyways, I find accessing methods adding too much extra noise in the diagrams. I'd prefer completing ivars with their visibility characteristic. Maybe another candidate for the popumenu (hide accessors).
- empty areas at the end should not be shown at all, eg. if there are no class methods, class vars. I'd instead suggest to show class vars underlined in the variable area at the top, class methods underlined at the top of the method area, which means that there are only two areas. If there are no vars or methods defined, keep the empty area, but having two or three empty areas is very confusing (and non-standard).
ok, you're right. Still, I need to know how to underline text... Do I need to use TextAttribute ? Any pointers ?
For classes without methods and vars (there are some of those...) we should only show the rectangle with the class name.
ok.
I'd very much appreciate if you could extend your implementation to address these issues.
I'll try to do so ;)
I've also planned to fill menus (browse, implement, senders, variables, etc... + export as PNG + ...) and hoverText (class comment, method definitions ...).
Such a diagram could be an alternative/complementary way of browsing code...
Note that OB uses your implementation, as we rely on the class UMLEnhClassDiagram from Alex' Mondrian version containing your extensions.
Yep, I saw that ;)
Cheers,
Cédrick
Thanks a lot, David
I like your extension. Adding edges will not be a problem. You're the second one to ask for it. I will do some coding tonight or tomorrow, will come back to you soon.
Cheers, Alexandre
On 30 Apr 2009, at 16:59, Cédrick Béler wrote:
Hi Alexandre and David,
I just saw that you merged the development of Mondrian with OBDiagram. Sounds good to me. Though, I missed some information in the UML class diagram, so I did my own. I joined it in cas you'd like it (plus a diagram example). One remark though, I simply remove accessing methods as I find they "pollute" my diagrams. It's ok for me but I guess not for general diagrams.
I actually play more with accessing method so that I can have their status and type (declaration in pragmas). Do you think it will be doable to draw associations between classes (if declared in pragmas) ?
Cheers,
-- Cédrick <UMLFullClassDiagram.st><xorp.png>
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I would not put superOb in scriptloader like that you can do what you want and we too :)
I don't think there are compatibility problems. The discussion just made me ask if it would be a good thing to have a set of "standard" method protocol ? Concerning what I experiment (pragma declaration), I won't push it to the OB repository anyway ;) Cédrick
Stef
I would not put superOb in scriptloader like that you can do what you want and we too :)
superOB per se is cool to have, the question is just which code OB uses for the UML generation. This code is defined in Mondrian, not in OB. So instead of removing superOB we better agree on a standard UML diagram format to be displayed. People can then switch themselves to an extended format, if they please. David
On May 6, 2009, at 4:18 PM, Cédrick Béler wrote:
Hi guys, (cc'ed to pharo list - we're talking about the UML diagram used in OBEnhancement)
2009/5/6 David Röthlisberger <roethlis@iam.unibe.ch>:
Hi Cédric,
I also like what you did for the UML diagram. I didn't push it to the repository because they were some personal choices and you underlined some of them.
Some issues I encountered:
- class-side methods should not be at the bottom, but at the top, and displayed with underlined font to be more UML-compliant. Oh I forgot about that. Looks ok to me though I don't know yet how to underline text in Mondrian (the text is a single stream with cr's)
- not sure about adding the method protocol. If included, I'd rather go for ordering the method alphabetically and then show the protocol in parentheses yes there is an ordering problem. The alphabetical order is ok, but printing the protocol beside could lead to long lines and then wide rectangles in the diagrams.
Even if not standard, I actually prefer the ordering by protocol mainly because it shows the method intention and it forces to use them. Nevertheless, to be consistent, I'd like to have a list of predefined protocols that can be ordered (initialize, accessing, ...) but this is outside the scope of the UML diagram.
Could we agree on that in Pharo (standard list of method protocols) ? Can someone propose a starting point...
What do you think ? (we could also provide an alternative ordering trough a popumenu "alphabetical/protocol")
- accessors should be present, IMO. I agree for the general case but decided to not show them in my diagrams.
This is part of a wider strategy. I explore using ivar as slots and hence not consider accessors as methods. Each ivar has automatic accessors that I try to complete with pragma's for further processing. Something like <type: min: max: visibility: >... Just experiencing... but anyways, I find accessing methods adding too much extra noise in the diagrams. I'd prefer completing ivars with their visibility characteristic. Maybe another candidate for the popumenu (hide accessors).
- empty areas at the end should not be shown at all, eg. if there are no class methods, class vars. I'd instead suggest to show class vars underlined in the variable area at the top, class methods underlined at the top of the method area, which means that there are only two areas. If there are no vars or methods defined, keep the empty area, but having two or three empty areas is very confusing (and non-standard). ok, you're right. Still, I need to know how to underline text... Do I need to use TextAttribute ? Any pointers ?
For classes without methods and vars (there are some of those...) we should only show the rectangle with the class name. ok.
I'd very much appreciate if you could extend your implementation to address these issues. I'll try to do so ;)
I've also planned to fill menus (browse, implement, senders, variables, etc... + export as PNG + ...) and hoverText (class comment, method definitions ...).
Such a diagram could be an alternative/complementary way of browsing code...
Note that OB uses your implementation, as we rely on the class UMLEnhClassDiagram from Alex' Mondrian version containing your extensions. Yep, I saw that ;)
Cheers,
Cédrick
Thanks a lot, David
I like your extension. Adding edges will not be a problem. You're the second one to ask for it. I will do some coding tonight or tomorrow, will come back to you soon.
Cheers, Alexandre
On 30 Apr 2009, at 16:59, Cédrick Béler wrote:
Hi Alexandre and David,
I just saw that you merged the development of Mondrian with OBDiagram. Sounds good to me. Though, I missed some information in the UML class diagram, so I did my own. I joined it in cas you'd like it (plus a diagram example). One remark though, I simply remove accessing methods as I find they "pollute" my diagrams. It's ok for me but I guess not for general diagrams.
I actually play more with accessing method so that I can have their status and type (declaration in pragmas). Do you think it will be doable to draw associations between classes (if declared in pragmas) ?
Cheers,
-- Cédrick <UMLFullClassDiagram.st><xorp.png>
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
ok, you're right. Still, I need to know how to underline text... Do I need to use TextAttribute ? Any pointers ?
Underlining is currently not supported. Let me work on this, it will be easier for me. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (4)
-
Alexandre Bergel -
Cédrick Béler -
David Röthlisberger -
Stéphane Ducasse