Microsoft and DSLs

[Phil Tomson]

Found in the Software Developers Magazine Agile newsletter in my inbox
this morning. Since there has been some discussion of DSLs (domain
specific languages) in recent days I thought it might be pertinant.

It seems that M$ isn't totally happy with UML so they're trying a
different approach to modelling:

"Luckily, the OMG isn't the only modeling game in town. Microsoft
has struck out on its own, a strategy that has clearly served it well
in the past, and is suggesting a new approach to modeling: Domain
Specific Languages (DSLs). As the name implies, a DSL is aimed
at addressing a specific task. For example, you could define a DSL
to model a Web services-based architecture or the physical schema
of a relational database. This is a far different approach than UML's
general, wide-purpose models. For example, UML class diagrams
can be used for conceptual modeling, object-oriented analysis
modeling, object-oriented design modeling, logical data modeling and
physical data modeling. DSLs can be visual or textual, and are
described in detail in the book Software Factories (see review below),
and the concept is being implemented in the upcoming version of
Visual Studio."

This is one case where M$ seems to be on the right track (did I say
that?. I am not a fan of UML, but I am a fan of DSLs. And Ruby is
great for creating DSLs.

Phil

 

[Austin Ziegler]

"[...]This is a far different approach than UML's
general, wide-purpose models. For example, UML class diagrams
can be used for conceptual modeling, object-oriented analysis
modeling, object-oriented design modeling, logical data modeling and
physical data modeling.[...]"

FWIW, the author of that statement is wrong. UML cannot be effectively
used for either logical or physical data modeling. It's too based in
object modeling. People who use UML for ER/data modeling are making a
huge mistake. There's far better modeling methodologies out there than
UML.

Other than that, I agree -- the move toward DSLs is encouraging. The
one thing that would be useful with DSLs is encouraging people to
share their DSL specifications and implementations so that people can
work from similar concepts. This won't necessarily lead to a "unified"
DSL (which is undesirable) but it will reduce the likelihood of
duplicate work that is just slightly mismatched.

-a

 

[Robert Klemme]

[...]

"[...]This is a far different approach than UML's
general, wide-purpose models. For example, UML class diagrams
can be used for conceptual modeling, object-oriented analysis
modeling, object-oriented design modeling, logical data modeling and
physical data modeling.[...]"

FWIW, the author of that statement is wrong. UML cannot be effectively
used for either logical or physical data modeling. It's too based in
object modeling. People who use UML for ER/data modeling are making a
huge mistake. There's far better modeling methodologies out there than
UML.

Just curios: what do you think are the major shortcomings of URL that make
it inappropriate for ER modeling?

Kind regards

robert

 

[Austin Ziegler]

On Fri, 18 Feb 2005 18:34:51 +0900, Phil Tomson

"[...]This is a far different approach than UML's general,
wide-purpose models. For example, UML class diagrams can be used
for conceptual modeling, object-oriented analysis modeling,
object-oriented design modeling, logical data modeling and
physical data modeling.[...]"

FWIW, the author of that statement is wrong. UML cannot be
effectively used for either logical or physical data modeling.
It's too based in object modeling. People who use UML for ER/data
modeling are making a huge mistake. There's far better modeling
methodologies out there than UML.

Just curios: what do you think are the major shortcomings of URL
that make it inappropriate for ER modeling?

I laid out much of this in a response to Markus in the first Ilias
thread, but I'll repeat it here.

Everything. UML has a bunch of problems, ranging mostly from the
fact that it tries to be capable of modeling everything all the
time. That means that to attempt to do ER/data modeling, you have to
repurpose the class diagram. Except that tables don't have methods,
so you have to ignore that entirely. And that UML uses C/C++/Java
types explicitly, which aren't as rich as or don't map well to SQL
databases by and large.

Object oriented mechanisms are generally good at what I call "one-
way browsing." That is to say that there's generally only one way to
access certain pieces of information in a given object model. A
perfect example would be the case of a cellular phone company's
billing policies. Typically, a customer (C) will have one or more
rate plans (P) that can also be assigned to other customers; a
standard many-to-many relationship.

The object model for this will typically design C and P as separate
classes, but C will contain a "list" of P objects. The reverse
relationship (where P contains a "list" of C object) will generally
not be implemented (indeed, it is usually seen as a BAD THING for a
component to have to know about its parents), which means that in an
object model (or an OO database, because its object model *is* its
data model) will only be able to browse P objects one way -- through
C objects. To find which set of C contain P[35], you have to browse
through each C object.

A relational model, however, will do the logical model as an
explicit many-to-many case, which generally forces the physical
model to have C, P, and CP tables. Now, because the relationship is
stored externally of either C or P, it's very easy to say:

SELECT COUNT(*)
FROM cp
WHERE p = 'P35';

And you know immediately how many customers would be affected if you
change the definition of P35.

UML is based on Jacobsen, Booch and Rumbaugh; they are all object
oriented theorists. And they're wrong when it comes to the supremacy
of OO design over proper ER design. But UML encodes that bias and
forces you to make choices that you should not have to make in your
ER modeling if you're making the mistake of using UML for that
instead of the established models for ER. (Indeed, for some types of
database design -- typically data warehousing, ER isn't appropriate
either -- you need what is called Dimensional Modeling, and I know
very little about that.)

Note that I'd *never* suggest that ERD should be used for object
modeling. UML Class Diagrams are perfectly good for that. But that's
about *all* they're good for, and they're not always good for that
in all languages because they make assumptions about the language
that will be used. Products like ArcStyle might be able to help with
that, but they'll still never produce a good database schema from an
object model. Never.

-austin

 

[James G. Britt]

...
Note that I'd *never* suggest that ERD should be used for object
modeling. UML Class Diagrams are perfectly good for that. But that's
about *all* they're good for, and they're not always good for that
in all languages because they make assumptions about the language
that will be used. Products like ArcStyle might be able to help with
that, but they'll still never produce a good database schema from an
object model. Never.

Does this have any bearing on O/R libs such as Og and ActiveRecord?

I figure it has to; it is quite unlikely that, beyond really basic
scenarios, your object model will have an isomorphic fit to your
database. In many cases this simply may not matter; the speed in
development and the cleaner conceptual model (from a OO developers
point of view) may well compensate for any inefficiencies.

But I'm wondering if there are guidelines that indicate when the
mismatch between the OO model and a proper E/R model is too great for
any automated lib to do a good job.

James

 

[Robert Klemme]

]
"[...]This is a far different approach than UML's general,
wide-purpose models. For example, UML class diagrams can be used
for conceptual modeling, object-oriented analysis modeling,
object-oriented design modeling, logical data modeling and
physical data modeling.[...]"
FWIW, the author of that statement is wrong. UML cannot be
effectively used for either logical or physical data modeling.
It's too based in object modeling. People who use UML for ER/data
modeling are making a huge mistake. There's far better modeling
methodologies out there than UML.

Just curios: what do you think are the major shortcomings of URL
that make it inappropriate for ER modeling?

I laid out much of this in a response to Markus in the first Ilias
thread, but I'll repeat it here.

Thank you for investing that effort. I'm neither an UML expert nor an UML
devotee. Still, I think not all your arguments against UML are valid.

Everything. UML has a bunch of problems, ranging mostly from the
fact that it tries to be capable of modeling everything all the
time.

True, that's one big source of problems. See my personal UML drawback
list at the end.

That means that to attempt to do ER/data modeling, you have to
repurpose the class diagram. Except that tables don't have methods,
so you have to ignore that entirely. And that UML uses C/C++/Java
types explicitly, which aren't as rich as or don't map well to SQL
databases by and large.

You probably used an UML tool that makes use of Java, C++ etc. types - but
that's not a feature of UML itself. It's just something that makes code
generation possible / easier for a concrete programming language and I
think that's the reason why vendors do this.

Object oriented mechanisms are generally good at what I call "one-
way browsing." That is to say that there's generally only one way to
access certain pieces of information in a given object model. A
perfect example would be the case of a cellular phone company's
billing policies. Typically, a customer (C) will have one or more
rate plans (P) that can also be assigned to other customers; a
standard many-to-many relationship.

I'd say you're right with regards to OOPL: most of them do in fact lack
proper mechanisms for modeling relationships. I don't subscribe to this
statement with regard to OO modeling: UML does quite a good job at
modeling all differnt kinds of relationships - even n-ary relationships.

UML is based on Jacobsen, Booch and Rumbaugh; they are all object
oriented theorists. And they're wrong when it comes to the supremacy
of OO design over proper ER design.

Do they actually claim that?

But UML encodes that bias and
forces you to make choices that you should not have to make in your
ER modeling if you're making the mistake of using UML for that
instead of the established models for ER. (Indeed, for some types of
database design -- typically data warehousing, ER isn't appropriate
either -- you need what is called Dimensional Modeling, and I know
very little about that.)

Note that I'd *never* suggest that ERD should be used for object
modeling. UML Class Diagrams are perfectly good for that. But that's
about *all* they're good for, and they're not always good for that
in all languages because they make assumptions about the language
that will be used.

UML itself is quite general in fact, I assume you are rather talking about
specific tools.

Products like ArcStyle might be able to help with
that, but they'll still never produce a good database schema from an
object model. Never.

Hm, I have the impression that you've worked with awful UML tools (or UML
tools that were not suited to the task you wanted them to fulfill) and now
you blame UML. IMHO we should keep that separate.

Here's my UML drawback list (TM)

- Too many versions

- UML is used for modeling *and* graphical programming. IMHO it's better
suited to modeling than to programming; the difficulties getting a proper
UML tool with working reverse engineering are a good indication for this
point.

- People often do not distinguish between these two use cases of UML and
that creates some confusion.

I still find UML (or rather a subset of it) quite useful to sketch or
design certain aspects of a system. I never use it for direct code
manipulation as I've experienced too many problems with this. Also I
think it's not productive to model a complete system down do every detail
with UML - which is what you would have to do if you wanted to get code
out of this.

Kind regards

robert

 

[Jim Weirich]

Robert Klemme said:

- UML is used for modeling *and* graphical programming. IMHO it's better
suited to modeling than to programming; the difficulties getting a proper
UML tool with working reverse engineering are a good indication for this
point.

- People often do not distinguish between these two use cases of UML and
that creates some confusion.

I still find UML (or rather a subset of it) quite useful to sketch or
design certain aspects of a system. I never use it for direct code
manipulation as I've experienced too many problems with this. Also I
think it's not productive to model a complete system down do every detail
with UML - which is what you would have to do if you wanted to get code
out of this.

I like Martin Fowler's descriptions of how UML is used (cf.
http://martinfowler.com/bliki/UmlMode.html): As a Sketch, as a Blue Print
and as a Programming Language. I definitely fall in the the UmlAsSketch
category, with occasional excursions into the land of UmlAsBluePrint.
Unfortunately, the UML standardization process is heavily oriented toward
the UmlAsProgrammingLanguage camp (i.e. MDA) and UML 2.0 is loaded with
heavy semantics that most people will most people will probably never
bother to understand.

 

[Robert Klemme]

Robert Klemme said:

I like Martin Fowler's descriptions of how UML is used (cf.
http://martinfowler.com/bliki/UmlMode.html): As a Sketch, as a Blue Print
and as a Programming Language. I definitely fall in the the UmlAsSketch
category, with occasional excursions into the land of UmlAsBluePrint.

Very sensible remarks. I like this one especially: "CASE has become a
dirty word and vendors try to avoid it now." This is not a surprise -
after all "CASE" is a four letter term...

Unfortunately, the UML standardization process is heavily oriented toward
the UmlAsProgrammingLanguage camp (i.e. MDA) and UML 2.0 is loaded with
heavy semantics that most people will most people will probably never
bother to understand.

That's exactly what I meant by "versioning": they're making UML more
complex with every release. That defies the purpose of an widely used
allround tool.

Cheers

robert