From: Jean-Louis Leroy
Subject: Multimethods vs UML
Date: 
Message-ID: <m3og2yv1l4.fsf@enterprise.newedgeconcept>
How do you people go about representing multimethods in UML diagrams?
How do you represent mere functions FTM?

2 notes:

1) I'm not interested in a debate about UML being a hindrance when
working with languages like Lisp & CLOS; chances are I agree with many
such arguments anyway. I'm working on sthing that will also exist in
C++, Perl and other such languages and I've decided that UML there
will be...

2) I'm interested in both theoretical and *practical* advice,
especially when working with ArgoUML and Rational Rose.

TIA.
-- 
Jean-Louis Leroy
http://users.skynet.be/jll

From: Frank A. Adrian
Subject: Re: Multimethods vs UML
Date: 
Message-ID: <wcgl5.721$tc.207924@news.uswest.net>
"Jean-Louis Leroy" <···@skynet.be> wrote in message
···················@enterprise.newedgeconcept...
> How do you people go about representing multimethods in UML diagrams?
> How do you represent mere functions FTM?
As you are probably aware, UML was designed for languages taking a
class-oriented view of the world.  As far as I know, it doesn't handle
non-method functions well in any language.  For this reason, it doesn't map
well to CLOS' view of the OO world.  The best way to work around this would
either be to (1) choose a "most important class" to bind the MM's to or (2)
create a single global class to hold all of the MM's and global functions.
As such, you won't really be using UML very well.  Also, your obstinance at
using it despite its unsuitability says something, but not about CLOS IMHO.

faa
From: Jean-Louis Leroy
Subject: Re: Multimethods vs UML
Date: 
Message-ID: <m3bsyyuilt.fsf@enterprise.newedgeconcept>
"Frank A. Adrian" <·······@uswest.net> writes:

> Also, your obstinance at using it despite its unsuitability says
> something, but not about CLOS IMHO.

<sigh> Please don't be to hard on me. More often than not I have lost
'points of credibility' by pointing out that just because OO is a good
idea doesn't mean that functions are a bad idea. Needless to say, I'm
no big fan of Java - nor of cheap empty statements about 'purity' ftm.

As I said I'm building in CLOS a tool that will also exist in other
languages. The tool uses rather complex data structures, and UML class
diagrams - entity-relationship diagrams augmented with inheritance -
are not totally useless for describing/documenting it. I didn't say
for *designing* it. However, like it or not, CLOS is not the most
popular way of communicating designs these days.

Besides, the idea of having a common idiom for representing designs is
not stupid in itself. This was my question I guess: has the CLOS
community designed extensions to UML that would make it a more able
tool?
-- 
Jean-Louis Leroy
http://users.skynet.be/jll
From: Fernando D. Mato Mira
Subject: Merge: LispOS + Multimethods vs UML
Date: 
Message-ID: <3995EA3B.42C1BB8A@iname.com>
Jean-Louis Leroy wrote:

> not stupid in itself. This was my question I guess: has the CLOS
> community designed extensions to UML that would make it a more able
> tool?

Fernando's Lisp Life Project "TODO" List:

1. Implement Sky Red in ECLOS
2. Finish 3D Graphics Toolkit in CLOS
3. Implement ECLOS-based, constraint-managed Son of CLIM
4. Invent MM methodology
5. Write CASE tool with ECLOS/Son of CLIM
6. Specify Core Lisp
7. Specify "Pure" Core Lisp
8. Implement "Pure" Core Lisp Compiler
9. Implement "Pure" Common Scheme
10. Implement Common Lisp-1 compatibility library
11. Implement "Pure" Son of CLIM Window Manager
12. Get rid of all the other Unix userland crud
13. Implement SysCore Lisp
...

Unfortunately, I have some other "life" project right now.. ;)

Xah, become rich and famous: do 6 and 7.

Talk is cheap..

-- 
Fernando D. Mato Mira			   Phone    : +41 (78) 778 FDMM
 				           E-mail   : matomira AT acm DOT org
From: Edward Jason Riedy
Subject: Re: Multimethods vs UML
Date: 
Message-ID: <8n4pb8$2an$1@agate.berkeley.edu>
And Jean-Louis Leroy writes:
 - How do you people go about representing multimethods in UML diagrams?

I'm playing with the idea of representing multimethods as objects
themselves.  The actual implementations are overloaded members
implementing __call__ or operator() or whatever.  If you think in
a MOP-ish way, then this is pretty good...

 - How do you represent mere functions FTM?

I've seen this discussed, but I can't remember where.  Probably
either comp.lang.object or http://www.c2.com/cgi-bin/wiki .  I
think I'd just use a stereotype over whatever notation is used
for generic functions (<<sealed>> or <<final>>, maybe).

Jason
From: Fernando D. Mato Mira
Subject: Re: Multimethods vs UML
Date: 
Message-ID: <3995EDF0.C7370A26@iname.com>
Edward Jason Riedy wrote:
> 
> And Jean-Louis Leroy writes:
>  - How do you people go about representing multimethods in UML diagrams?
> 
> I'm playing with the idea of representing multimethods as objects
> themselves.  The actual implementations are overloaded members
> implementing __call__ or operator() or whatever.  If you think in
> a MOP-ish way, then this is pretty good...
> 
>  - How do you represent mere functions FTM?

What about just throwing in some plain old SA diagrams? With a good tool
like Win[Mac]A&D mixing methods is no problem
(http://www.excelsoftware.com/)

-- 
Fernando D. Mato Mira			   Phone    : +41 (78) 778 FDMM
 				           E-mail   : matomira AT acm DOT org
From: Jean-Louis Leroy
Subject: Re: Multimethods vs UML
Date: 
Message-ID: <m31yztuh97.fsf@enterprise.newedgeconcept>
···@lotus.CS.Berkeley.EDU (Edward Jason Riedy) writes:

> And Jean-Louis Leroy writes:
>  - How do you people go about representing multimethods in UML diagrams?
> 
> I'm playing with the idea of representing multimethods as objects
> themselves.  The actual implementations are overloaded members
> implementing __call__ or operator() or whatever.  If you think in
> a MOP-ish way, then this is pretty good...

I've had similar ideas.

Now when you think about it, there's a lot of resemblance between CLOS
multi-argument dispatch and C++ partial specialization of templates
(the main difference being of course that templates are selected at
compile-time).

Perhaps it would make sense to represent a generic as a
(pseudo-templatized) class that has a single method `funcall' (pure
virtual) and several specializations.

Also, about my other question (representing functions) a closure
pretty much looks like an object that has attributes (the captured
variables) and, again, a single method `funcall'. And an ordinary
function could be viewed as the single instance of a class that has no
state.
-- 
Jean-Louis Leroy
http://users.skynet.be/jll
From: Edward Jason Riedy
Subject: Re: Multimethods vs UML
Date: 
Message-ID: <8n6ii5$4ve$1@agate.berkeley.edu>
And Jean-Louis Leroy writes:
 - 
 - (the main difference being of course that templates are selected at
 - compile-time).

I tend to think the main difference is when compile time occurs...
You can also make it look somewhat like C++ function overloading at 
link-time, again raising the question of when that occurs.

 - Perhaps it would make sense to represent a generic as a
 - (pseudo-templatized) class that has a single method `funcall' (pure
 - virtual) and several specializations.

You get half a zillion little boxes all over.  Yech.  That depends
on how you're using the diagrams, though.  Sometimes it'll make more
sense, like when you only want to show one or two of the methods.

BTW, I'm one of those nuts who just uses the basic visual conventions
of UML, not one of those nuts who follows every last `formal' rule in 
the UML specs.  The choice between putting everything in one box 
versus having a specialized box for each defined method will depend
on what aspects the original poster wants to emphasize.  Both may be
useful in different contexts.

Jason
From: Mark Dalgarno
Subject: Re: Multimethods vs UML
Date: 
Message-ID: <3997ac25.887276@mail-relay.scientia.com>
On 12 Aug 2000 19:19:51 +0200, Jean-Louis Leroy <···@skynet.be> wrote:

>How do you people go about representing multimethods in UML diagrams?

Tony Willoughby did a talk about extending UML to cater for multi-methods
at a Lisp User Group meeting in London in 1998. ISTR that it involved an
enhancement to activity diagrams. Perhaps someone has a copy of the slides
somewhere ?

Mark
From: Jochen Schmidt
Subject: Re: Multimethods vs UML
Date: 
Message-ID: <8n78ph$7pad2$1@ID-22205.news.cis.dfn.de>
Jean-Louis Leroy wrote:

> How do you people go about representing multimethods in UML diagrams?

Why not write the method in all classes that it specializes on?

> How do you represent mere functions FTM?

You need not to describe your hole program in _one_ diagram. Its only _a_ 
view of the design.
I would only describe the most abstracted classes of your design in a UML
diagram.
The diagram is not the program, it's only a  map for finding what you want 
- an overview of the whole thing.
You won't ask how a street-lantern is represented in a road-map won't you?

> 1) I'm not interested in a debate about UML being a hindrance when
> working with languages like Lisp & CLOS; chances are I agree with many
> such arguments anyway. I'm working on sthing that will also exist in
> C++, Perl and other such languages and I've decided that UML there
> will be...

If these "thing" will also exist in other languages (that doesn't have MMs)
then the answer to your question should be pretty easy!
You should not need MMs for a Project that has a direct Mapping to e.g. C++
So why using MMs in your diagramms ????

Using MMs in software design makes the programmers life a lot easier but if 
you have a ready SM design you could also implement this in CLOS.

-- 
Jochen Schmidt
···@dataheaven.de
http://www.dataheaven.de
From: Jean-Louis Leroy
Subject: Re: Multimethods vs UML
Date: 
Message-ID: <m3wvhktegu.fsf@enterprise.newedgeconcept>
Jochen Schmidt <···@dataheaven.de> writes:

> You should not need MMs for a Project that has a direct Mapping to e.g. C++
> So why using MMs in your diagramms ????

MMs can be emulated in C++ in several different ways. The emulation
has no place in design diagrams.

> Using MMs in software design makes the programmers life a lot easier but if 
> you have a ready SM design you could also implement this in CLOS.

Interestingly I've been hesitating about a part of my design, which
was amenable to 'multimethod reduction'. The alternatives are:

Option #1 - using multimethods

    (defclass slot () ...)
    (defclass integer-slot (slot) ...)

    (make-relational-engine (schema)
        ;; ...
                (push slots (make-integer-slot)) ;; not using a push in real code
        )

    ;; C++: probably a global function that uses RTTI to emulate MMs

    (defmethod store ((engine relational-engine) (slot integer-slot))
        (do-things))

Option #2 - not using multimethods but costs more classes

    (defclass slot () ...)
    (defclass integer-slot (slot) ...)

    (defclass relational-slot (slot) ...)

    (defclass relational-integer-slot (integer-slot relational-slot) ...)

    (make-relational-engine (schema)
        ;; ...
                ;; all slots are relational-slots
                (push slots (make-relational-integer-slot))
        )

    ;; C++: virtual void relational_integer_slot::store(relational_engine*, ...)

    (defmethod store (engine (slot relational-integer-slot))
        (do-things))

Option #2 directly maps to C++ concepts, however, I find that #1
describes more clearly what's going on. OTOH #1 doesn't make it
explicit that all the 'slot' objects are of the same 'relational'
type. Hmm.

I'm considering describing this with two diagrams, one for what's
really going on, and one for the implementation in less able
languages. If only I find a convincing way of drawing MMs <g>
-- 
Jean-Louis Leroy
http://users.skynet.be/jll