Hi guys, (cc'ed to pharo list - we're talking about the UML diagram used in OBEnhancement)
2009/5/6 David Röthlisberger <[email protected]>: > 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 [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
