UML didn't trigger my brain

[kgillen]

Hi all,

UML Distilled.  For me this is the one book that is UML common sense.  Fowler does a great job explaining when and when not to use UMLie stuff.

On UML projects over the past 8 years I must have been responsible for selling 100's of copies of this book in various editions.  People seem to like it because it makes it simple.

If you are new to UML or just wish for an easy to read reference, this book delivers.

K.

[raf952]

I learned UML seriously about 5 years ago: I designed a complex system using VISIO and after walking through the deisgn with the director of architecture I realized that I spent a lot of time and energy coming up with my depictions of things that were already pretty well defined by the UML.

After that I committed to use UML all the time. At any meeting  I would keep notes about system behavior or logical structure using UML. I treated it like learning a foreign language.

Now I write UML models with ease. I keep the UML 2 Toolkit ready for less frequently used constructs, but as the saying goes, you can get about 80% done with about 20% of what's available.

Another reference I highly recommend besides the UML 2 Toolkit is Schaum's UML, Second Edition (ISBN: 0077107411). For about $12 on Amazon, it's a fantastic deal.

[mbc]

For most people that I know, "learning UML" is very different from learning a new language.
When you learn a new language, like French or English, you already know what you want to express with that language.
Most programmers who try to "learn UML" are not used to the process of abstracting problems and turning them into abstract designs, which is what UML is so useful for.
These people have to learn both the process (what to express) and the language (how to express it).

This, IMHO, is the great challenge in "learning UML". Not only do you have to learn the language (that is the simple part), you also have to learn what to use it for and why.

Mikkel

[Paolo F Cantoni]

For most people that I know, "learning UML" is very different from learning a new language.
When you learn a new language, like French or English, you already know what you want to express with that language.
Most programmers who try to "learn UML" are not used to the process of abstracting problems and turning them into abstract designs, which is what UML is so useful for.
These people have to learn both the process (what to express) and the language (how to express it).

This, IMHO, is the great challenge in "learning UML". Not only do you have to learn the language (that is the simple part), you also have to learn what to use it for and why.

Mikkel

Excellent observation Mikkel!

I think you are spot on!

If anyone is having difficulty abstracting then the discussions Jim Shaw and I are having may be of interest (see other threads in this Forum).  They are specifically targeted at creating the right level of abstraction for the various model forms in:
MDA (Model Driven Architecture)
the:
CIM (Computationally Independent Model)
PIM (Platform Independent Model)
PSM (Platform Specific Model)

Paolo

[mikewhit]

you also have to learn what to use it for and why.

My earlier posting (page 1) was also trying to note that without some experience, you might not even be able to see the point of some of the aspects of UML,  even if you could "learn why".

[raf952]

For most people that I know, "learning UML" is very different from learning a new language.
When you learn a new language, like French or English, you already know what you want to express with that language.

Indeed--and when I am listening to a stakeholder describe their business domain or express their expectations of what they need the solution to do, I want to express exactly what they said.

Most programmers who try to "learn UML" are not used to the process of abstracting problems and turning them into abstract designs, which is what UML is so useful for.

Agreed. but that's why I would recommend using it to express concrete domain models and the stakeholder's clear statement of expectations.

I lived in Asia for a couple of years. When I learned Chinese I first started expressing simple, concrete concepts and asking direct questions. Heck, that was hard enough!
Expressing abstract concepts and ideas was a lot harder, and took a while before I worked up to that.

These people have to learn both the process (what to express) and the language (how to express it).

This, IMHO, is the great challenge in "learning UML". Not only do you have to learn the language (that is the simple part), you also have to learn what to use it for and why.

Mikkel

That's exactly why I approached it like a language (after all, that's what the "L" in "UML" stands for. To me, it's a notational system I use to express concepts and ideas--just as I might write notes in English, German, or any other language. This one, like Chinese, uses little picture glyphs that can pack a lot of meaning. But just knowing a few characters and grammar rules doesn't make me a poet. Likewise, knowing a few diagrams and a tool like EA doesn't make one adept at modeling.

I invite you to give it a try: go a week where you take notes using UML--first perhaps take your conventional notes and represent key ideas using a class diagram, use case, or sequence diagram (you can get a lot of mileage just from those three).

Your mileage and experience may vary, but what do you think of the concept?

raf

[Kevin Brennan]

I think the concept is good. Modeling languages (like UML) aren't just pretty pictures, they're ways to analyse problems.

I learned UML much like everyone else here did, I think. I started by trying to express things I could describe in natural language in a class diagram or other model. Then once I could do that it became a lot easier to sketch the class model in the first place to help me express things.

For end users, I find it's best not to "teach them UML". Just get a white board and start drawing the diagram as you go through the domain model, then walk them through the diagram to confirm it.

[Paolo F Cantoni]

[size=13][SNIP][/size]
For end users, I find it's best not to "teach them UML". Just get a white board and start drawing the diagram as you go through the domain model, then walk them through the diagram to confirm it.

When I start modelling with end users, I tell them, not to worry about the funny signs, I'll verbalise the model to them as required.
After a point they reach an "appreciation" of the model.  They can see it does something and is conistent but they don't have to understand the detail.

Paolo

[raf952]

When I start modelling with end users, I tell them, not to worry about the funny signs, I'll verbalise the model to them as required.
{...}
Paolo

I do the same thing. I found the users "get it" quickly. Usually they have to deal with all sorts of creative diagrams from IT anyways that they appreciate the consistency of clean UML.

[mbc]

Agreed. but that's why I would recommend using it to express concrete domain models and the stakeholder's clear statement of expectations.

Modelling a domain and stakeholders expectations is a discipline of its own. If you are already a master of this discipline using other notations or languages, the transition to UML might not be so hard.
But most programmers that I know are not familiar with modelling at all, in any language! Someone told them that they have to learn UML, but they can't readily think of any other use for UML than documenting their source code in detail. The analysis activity is not familiar to them at all.

Mikkel

[jeshaw2]

The analysis activity is not familiar to them at all.

Some programmers may argue that point.  Analysis is the process of breaking thing down into simpler concepts.  Synthesis is the process of integrating things into something new.  

Coders predominately Forward Engineer the Dynamic models (analyzing processes) and they perceive the Class Inheritances from the perspective of Specialization.  They don't have much occasion to work on Generalization/Synthesis side of the UML; that seems backward to them.  When in reverse, my car runs slowly too  

This is also why modelers have difficulty writing code;  that puts their mind in reverse too.  

My problem is that I'm used to bi-directional thinking (modeling and coding), but my mind is always in a gear opposite to what I'm doing.    Seems, no matter which way I'm going, I'm in reverse gear.  

[raf952]

{...}
But most programmers that I know are not familiar with modelling at all, in any language! Someone told them that they have to learn UML, but they can't readily think of any other use for UML than documenting their source code in detail. The analysis activity is not familiar to them at all.

Mikkel

I believe we all model--we create mental models based on what we hear, what we understand, and what we decide (consicously or not) to focus on, both in analysis--understanding the problem, or design--formulating a solution

The challenge is many lack the skills to depict their mental models. Anthropologically they're stuck in oral tradition--sitting around a fire telling stories about their model. (arguably some are pre-oral, just grunting inarticulately).

With UML a software developer can progress from just an oral to a written tradition. Others are able to read my model, make corrections and extensions, and take action.

To me this is the value of the UML. It does nothing more than allow me to communicate my vision more clearly and effectively.

In a way it's just like musical notation: just because I know how to read a music staff doesn't make me a musician. Just because I can write notes on a page doesn't make me a composer (not a good one, at least).

raf
(stepping off of my soap box)