UML diagram (OBEnhancement)

>
> 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>
>>
>
>

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

> 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 <[hidden email]>:
>>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project