Scala and UML

[Chapin, Peter @ VTC]

Hello!

 

I’m in a situation where I may need to develop some UML diagrams for a Scala program I’m working on. I’m not very knowledgeable about UML right now but my preliminary attempts to work with it have run into some problems. Am I correct in saying that UML is not expressive enough to really capture Scala design patterns? UML seems like a good match for Java’s expressive capabilities, but I get the feeling that it can’t keep up with Scala. Just as one small example, I’m not sure how to use UML to model things like abstract type members of traits.

 

So this leads to my next question… is there a modeling language that can cope with the richness of Scala? I did a little digging around and I found some posts on other forums pertaining to modeling functional languages. The people in those threads said things like, “use the type system,” or “use the language itself to model your programs.” I can appreciate those ideas. On the other hand it seems like Scala’s OO/functional hybrid nature makes the question a richer one. In Scala I can have stateful objects that interact in complicated ways. Yet I still find UML not up to the task of dealing with the richness of even just Scala’s object oriented features. Perhaps I just need to study more UML.

 

Peter

 

[Geir Hedemark]

On 2012, Apr 2, at 12:46 PM, Chapin, Peter @ VTC wrote:

I’m in a situation where I may need to develop some UML diagrams for a Scala program I’m working on.

I think the question you need to answer first is why you need the UML diagrams. The answer will be very different depending on where you are coming from. 

Some people want to generate code from their UML. Others just want to communicate their design, in which case you really don't need UML - you just need something that will communicate your intent.

All too often, the answer seems to be "because that is what our design guidelines say", with no one being able to explain why the guideline was introduced in the first case.

Geir

[Chapin, Peter @ VTC]

In my case, I think the reason is a combination of your second (communicate the design) and third (that’s what the guidelines say) points, with an emphasis on the third point. I’m not in love with UML. In fact, I don’t really know much about it and I don’t feel a burning need to learn it for its own sake. If I can convince others in my group that it’s not an appropriate way to go, particularly in a Scala context, I’d be happy with that.

 

On the other hand I can see the value in having an effective way of communicating the software’s design that’s less verbose than the source code itself… or long winded narrative text.

 

Peter

[Nils Kilden-Pedersen]

On Mon, Apr 2, 2012 at 5:46 AM, Chapin, Peter @ VTC <PCh...@vtc.vsc.edu> wrote:

Hello!

 

I’m in a situation where I may need to develop some UML diagrams for a Scala program I’m working on. I’m not very knowledgeable about UML right now but my preliminary attempts to work with it have run into some problems. Am I correct in saying that UML is not expressive enough to really capture Scala design patterns? UML seems like a good match for Java’s expressive capabilities, but I get the feeling that it can’t keep up with Scala. Just as one small example, I’m not sure how to use UML to model things like abstract type members of traits.

http://stackoverflow.com/questions/4786771/uml-class-diagram-and-generics

[Geir Hedemark]

On 2012, Apr 2, at 2:39 PM, Chapin, Peter @ VTC wrote:

In my case, I think the reason is a combination of your second (communicate the design) and third (that’s what the guidelines say) points, with an emphasis on the third point. I’m not in love with UML. In fact, I don’t really know much about it and I don’t feel a burning need to learn it for its own sake. If I can convince others in my group that it’s not an appropriate way to go, particularly in a Scala context, I’d be happy with that.

I think UML is a good basic toolbox to use while communicating over a whiteboard, but all the places I have worked where we have used UML we have evolved a number of "shorthand" notations that fit our domain model. We usually let the UML die, except for top-level architectural drawings and the domain model itself.

I guess the architectural part is where UML falls to bits on you?

Geir

[Razvan Cojocaru]

It’s there a graphical/geometrical design representation of functional programs/designs?

 

Is this an issue of graphical versus algebraic communication preferences?

 

We know UML hasn’t kept pace with innovation (well, Lisp has been around for decades so I don’t know if it’s innovation it hasn’t kept pace with or ‘mainstream’) the question is why?

 

UML is the medium of choice for many organizations, for instance in the telecom space (tmf.org) and there have been already some discussions about its limitations, but to no avail.

 

In any case, this discussion is probably limited to UML class diagrams – others like use case, deployment etc have no dependency or issues with scala…

 

Cheers,

Razie

 

From: scala...@googlegroups.com [mailto:scala...@googlegroups.com] On Behalf Of Geir Hedemark
Sent: April-02-12 6:56 AM
To: Chapin, Peter @ VTC
Cc: scala...@googlegroups.com
Subject: Re: [scala-user] Scala and UML

 

On 2012, Apr 2, at 12:46 PM, Chapin, Peter @ VTC wrote:

[Meredith Gregory]

Dear Peter,

If you stay to the functional side of Scala, then categorical diagrams are a powerful diagrammatic representation of design. Here's a little tool for seeing some of the categorical constructions.

Best wishes,

--greg

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SW

Seattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

[Brian Maso]

There are a lot of functional concepts for which there is no official or even unofficial UML graphical representation. But there is the fairly underused Object Constaint Language -- an OO logic language that actually is part of the UML spec. Almost no one uses it, but I've found I can encode a lot of algorithmic and functional concepts in OCL that for the life of me I can't figure out how to diagram. It is "official" UML, though I'm willing to be if you use it very much then someone in your organization will make a "No OCL" rule.

I guess that's not really helpful. I wish someone had a good way to represent functions, type classes, and implicits in UML or even in some decent graphical rep, but I've never seen anything that comes close.

Brian

On Mon, Apr 2, 2012 at 7:52 AM, Razvan Cojocaru <p...@razie.com> wrote:

[Detering Dirk]

There are two questions here:

1.) What is the problem with the UML?

First, I suspect it to be too much bound to the concept of mutable objects.
While it is easy to design systems based on interfaces, classes, inheritance in
a class diagram, it is also about communication between more-than-short living
mutable instances when it comes to collaboration diagrams.

Second, the concept of mixins has no real representation in UML. When you want
to express the trait chain expressed with MyClass extends trait1 with trait2 with trait4,
you are left alone. What would you use to express the order of the traits?
Where is the linearisation semantics hidden in a UML hierarchy diagram?
Or would you much more note the linearisation by hand?

Third, to express singleton (scala: object), case class, sealed class, trait, you find no
first-class elements in the UML metamodel. The only solution would be to introduce
new stereotypes to annotate the existing classifiers.
Then again, representing a case class (or Algebraic Data Type) hierarchy -which is written in
three to few more lines in Scala- as a graphical representation of a boxes-connected-with-arrows
diagram does not gain anything.

Fourth: Expressing generic types in UML is a PITA. Even if the UML itsself is in general
capable to to this, the tools do not (at least the few ones I know), and longer type param
lists and/or deeper nesting of generics is unusable. Not to talk about variance annotations.
Huh, and let's not consider context bounds or view bounds ...

Fifth: Classifier have only two compartments: fields and operations. UML misses a
compartment for 'type' declarations. BTW: AFAIR there was a semantic blur between
classes and types in the UML spec.

Sixth: UML has no notion of first-class behaviour. I.e.: No first-class functions. Everything
behavioural is a method within a class. Not only can free functions not be expressed, neither
can their types, unless we resort to generics again, e.g.: Function1<R,T> , to be expressed
as generics in UML, which is a PITA, as we already know from 'fourth'.


=> UML is C++ (Java) in boxes. Full stop.

> -----Original Message-----
> From: scala...@googlegroups.com [mailto:scala...@googlegroups.com]

> On Behalf Of Brian Maso
>I wish someone had a good way to represent functions, type classes, and implicits in
> UML or even in some decent graphical
> rep, but I've never seen anything that comes close.

2.) Why?
Why would we want to represent functions ( a mapping between two domains) which can
be expressed concise and readable in textual notation in a graphical notation?
BTW: Not in UML anyway, as this is mainly for designing objects (= nouns), not behaviour (= verbs).

If we stay on the "interface" level, that is what class diagrams show:
classifiers have methods with a specific signature (implementation is only documented in form of spec notations).
The "interface" level for functions is their parameter and result types.
That is much easier written in a one-liner: def repeat:(String, Int) => String

The reason why graphical notation for functional design has not won over textual notation is
the same why -in general- graphical notation for set theory in mathematics has not won over
formula notation.
It mostly does not gain any expressiveness and correctness. It may only _sometimes_ be supportive.

And that is the reason for UML in the beginning: To gain expressiveness, keep orientation in a complex
system of dependencies and hierarchies.

And UML was created to _design_ systems. While it may be helpful sometimes to _get_ a graphical
representation of a system , e.g. as reverse engineered UML or as dependency graphs, I would never
want to _create_ a functional system by clicking, dragging, drawing shapes.
After working over ten years now in a MDSD environment, I consider UML as highly overestimated,
and I consider "model" much more as being an abstraction level of a certain code, not a difference
between graphical and textual.
So looking at the abstraction level of Scala's concepts and the cociseness of its syntax, Scala can in itself be
a modeling language, if applied as such.

Just my 2ct

KR
Det