In article <3D5A2FFF.60
...@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?*
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.
