i'd like to clarify *some* facts about UML and CL.
- please answer with the precision u use when programming.
- avoid referencing other languages.
- avoid context-switching.
- be friendly!
UML = Unified Modeling Language
CL = Common LISP
lc = language constructs
1. *can i model in UML what i can write in CL?*
1.1 which CL-lc cannot be modeled in UML?
1.2 which CL-lc cannot be modeled in UML straightforward?
1.2.1 Which lc of UML are used, to model those CL-lc under 1.2?
1.3 Which UML tools are specialized to CL?
ilias <·······@pontos.net> writes:
> - please answer with the precision u use when programming.
> - avoid referencing other languages.
> - avoid context-switching.
> - be friendly!
>
> i'd like to clarify *some* facts about UML and CL.
>
> UML = Unified Modeling Language
> CL = Common LISP
> lc = language constructs
>
> 1. *can i model in UML what i can write in CL?*
No. That is, you cannot make a UML model for an
arbitrary CL programs. [Anybody know if UML is turing complete? ;-)]
> 1.1 which CL-lc cannot be modeled in UML?
At least the following, off the top of my head.
Macros. Symbols. MOP operations. Multi-methods. Dynamic variables.
Anonymous functions.
> 1.2 which CL-lc cannot be modeled in UML straightforward?
I do not understand how this is different from 1.1.
"Please ask questions with the precision u use when programming." :-P
> 1.2.1 Which lc of UML are used, to model those CL-lc under 1.2?
?
> 1.3 Which UML tools are specialized to CL?
None, for obvious reasons.
Friendlily yours,
--ap
Alain Picard wrote:
> ilias <·······@pontos.net> writes:
>
>
>>- please answer with the precision u use when programming.
>>- avoid referencing other languages.
>>- avoid context-switching.
>>- be friendly!
>>
>>i'd like to clarify *some* facts about UML and CL.
>>
>>UML = Unified Modeling Language
>>CL = Common LISP
>>lc = language constructs
>>
>
>
>>1. *can i model in UML what i can write in CL?*
>
> No. That is, you cannot make a UML model for an
> arbitrary CL programs. [Anybody know if UML is turing complete? ;-)]
>
>>1.1 which CL-lc cannot be modeled in UML?
>
> At least the following, off the top of my head.
> Macros. Symbols. MOP operations. Multi-methods. Dynamic variables.
> Anonymous functions.
macros
symbols
MOP operations
multi-methods
dynamic variables
>>1.2 which CL-lc cannot be modeled in UML straightforward?
>
> I do not understand how this is different from 1.1.
> "Please ask questions with the precision u use when programming." :-P
example for straightforward:
- use of UML-lc class to model the java-lc class
example for not straightforward:
- use of a UML-class,
- add a UML-Stereotype (e.g. "CLMACRO") to the class
- modify the code-generator to recognise Sterotype "CLMACRO"
- generate the CL-MAKRO out of the information modeled in the UML-class
>>1.2.1 Which lc of UML are used, to model those CL-lc under 1.2?
>
> ?
Which language-constructs of UML are used, to model those
CL-language-constructs [possibly refered from you] under [the question]1.2
in the example i gave above:
- UML-lc "Stereotype"
- Custom-Code-Generation (not a UML-lc, but a UML-tool-functionality)
>>1.3 Which UML tools are specialized to CL?
>
> None, for obvious reasons.
>
> Friendlily yours,
> --ap
thank you.
i conclude (based on your answers): UML is incapable of modeling CL.
ilias <·······@pontos.net> writes:
> i conclude (based on your answers): UML is incapable of modeling CL.
This is not completely true because UML is not limited to the class
diagram. UML has 9 differents diagrams to give you some differents
view of your project (from the requierements to the deployment). You
can modelise the parts which are not really affected by the
implementation language you've choosen. You can always modelise
relations and messages exchanged between objects (or modules).
UML only implements *some* object concepts and makes assumptions about
how objects are made. For examples, with UML (as well as most
mainstream languages) all methods must belongs to an objects. So I
agree that some advanced OO concepts implemented by Common Lisp cannot
be directly modelised in a standard way in UML.
--
Frederic Brunel
Software Engineer
In-Fusio - Mobile Game Connections
Frederic Brunel wrote:
> ilias <·······@pontos.net> writes:
>
>>i conclude (based on your answers): UML is incapable of modeling CL.
>
>
> This is not completely true because UML is not limited to the class
> diagram. UML has 9 differents diagrams to give you some differents
> view of your project (from the requierements to the deployment). You
> can modelise the parts which are not really affected by the
> implementation language you've choosen. You can always modelise
> relations and messages exchanged between objects (or modules).
>
> UML only implements *some* object concepts and makes assumptions about
> how objects are made. For examples, with UML (as well as most
> mainstream languages) all methods must belongs to an objects. So I
> agree that some advanced OO concepts implemented by Common Lisp cannot
> be directly modelised in a standard way in UML.
>
i conclude (based on your comments): UML is incapable of modeling CL.
ilias <·······@pontos.net> writes:
> i conclude (based on your comments): UML is incapable of modeling CL.
I said that not all Common Lisp can be *directly* modeled using pure
UML. You can extend the UML syntax to help you modelise most of Common
Lisp concepts.
_If you question is_: can I model my Common Lisp programs (in a logical
view) using UML in its standard form? the answer is: no!. OTOH, if
your question is: can I model my Common Lisp programs using UML? the
answer is: yes! You have to define some way to represents the Common
Lisp concepts you want (like generic functions and so on) using UML
builing blocks.
--
Frederic Brunel
Software Engineer
In-Fusio - Mobile Game Connections
Frederic Brunel wrote:
> ilias <·······@pontos.net> writes:
>
>
>>i conclude (based on your comments): UML is incapable of modeling CL.
>
>
> I said that not all Common Lisp can be *directly* modeled using pure
> UML. You can extend the UML syntax to help you modelise most of Common
> Lisp concepts. ^^^^^^^
*most of*
i conclude (based on your comments): UML is incapable of modeling CL.
>
> _If you question is_: can I model my Common Lisp programs (in a logical
here my questions from my initial post:
(if some question is unclear, please request clarifications, quoting
what do you don't understad or what i've expressed unclear)
i'd like to clarify *some* facts about UML and CL.
- please answer with the precision u use when programming.
- avoid referencing other languages.
- avoid context-switching.
- be friendly!
UML = Unified Modeling Language
CL = Common LISP
lc = language constructs
1. *can i model in UML what i can write in CL?*
1.1 which CL-lc cannot be modeled in UML?
1.2 which CL-lc cannot be modeled in UML straightforward?
1.2.1 Which lc of UML are used, to model those CL-lc under 1.2?
1.3 Which UML tools are specialized to CL?
In article <··············@pontos.net>, ilias wrote:
> i'd like to clarify *some* facts about UML and CL.
>
> - please answer with the precision u use when programming.
> - avoid referencing other languages.
> - avoid context-switching.
> - be friendly!
>
> UML = Unified Modeling Language
> CL = Common LISP
> lc = language constructs
>
> 1. *can i model in UML what i can write in CL?*
UML is the result of an object-oriented programming orthodoxy, and is pushed by
people who think they know everything about software design, and who will
gladly sell you their ``process'' in the form of expensive documentation,
courses and software.
Because most UML users write in C++, UML caters to these users by trying to
have a graphical element every feature of the C++ type system. This is needed,
because modelling tools based on UML work with the language. You hack up the
UML, and then you can generate a skeleton. Or you can reverse-engineer code to
produce UML.
The assumption behind UML is that the classes are all important, and the
procedural stuff that is actually written into the method bodies is just an
irrelevant detail, even though that is what actually makes the software work,
and where all the bugs will hide.
> 1.1 which CL-lc cannot be modeled in UML?
Anything that is not object-oriented. What if you use macros to write your own
sublanguage? The use of that sublanguage throughout the rest of your program is
a crucial part of your programming *model* of that program. Yet the modelling
language won't represent that.
Of course, the ability to create your own language makes a modelling language
superfluous.
The principle behind a modeling language like UML is the acceptance of defeat
in the face of a bad programming language. Because it's impossible to write a
C++ or Java program that actually *expresses* its intended design, programmers
must accept that and switch to a redundant notation, which must be
painstakingly maintained in parallel with the program.
It's a way of capturing information that is *lost* in the transfer from the
programmer's mind to the programming language, because the programmer must
manually expand his abstractions into a low-level notation that is incapable of
expressing them directly.
The real solution is to use a programming language in which a programmer can
make all of her thoughts explicit. So that, for instance, if she has an idea
that results in a recurring pattern of coding throughout the program, she can
implement that pattern into the language, rather than manually instantiate all
variations of it.
You see, it's actually Lisp which can rightfully claim the title
``Universal Modelling Language''.
There is one useful idea in UML, which is the modelling of use cases. Use
cases capture interactions between the software and its users at a very high
level. Use cases don't constrain the internal architecture of the software in
any way.
> 1.2 which CL-lc cannot be modeled in UML straightforward?
Anything which freely uses the object system.
UML users would expect, for instance, that methods are properties of classes.
But in a UML diagram showing the class structure of a CLOS program, generic
functions ought to stand on their own as independent classifiers.
This means that you wouldn't write a box representing a class, and
then fill in methods. You would have a box representing a class, with
only data members. Then boxes representing generic functions, containing
methods.
Needless to say, this would not be understood by most of the UML-spewing
population.