re: UML

22 Jun 2005 - 2:46pm
9 years ago
8 replies
1589 reads
ji kim
2004

Hmm...from my experience....it's good for interaction designers to understand interpreting UML written by Product Managers, Business Analysts, Engineers, or other stakeholders in the project. For example, I worked at a software company where our product teams were spread out in three different continents - where lot of team members did not speak/write english fluently, and using UML kind of helped (it helped communication between designers, engineers, PM's and etc using common symbols and lines created from UML).
Here were some problems we encountered: we did find out later in the game, learning UML is not that easy - it has bit of learning curve and tools were very expensive (although there are some opensource/cheaper ones now).

Trend I've seen in my job (most in large enterprise software companies), more and more engineering architects, product managers, and developers are using UML with their specs. So if you want to speak their language, then you should enough of UML to communicate and comment.

Implementing UML to your design is your choice - but ask your self this: do you have enough understanding of UML? have proper tool? and will people you work with adapt it? In smaller software projects, just my personal opinion, might be an overkill. But for large projects, it might be worth exploring.

In side note: yes OVID is quite old, but for last few years IBM consulting have been trying to pitch their User Engineering process that use UML quite a bit. Not to mention, IBM bought Rational Rose. Few years back, at Ease of Use conference at IBM research center in california, they gave tutorials on using UML with their user engineering process. My feeling was that, for most non-ibm participants (lot of them were designers with no engineering background) were overwelmed with UML.

my 2cents,

Ji

Comments

22 Jun 2005 - 3:41pm
Lada Gorlenko
2004

jk> In side note: yes OVID is quite old, but for last few years IBM
jk> consulting have been trying to pitch their User Engineering
jk> process that use UML quite a bit. Not to mention, IBM bought
jk> Rational Rose. Few years back, at Ease of Use conference at IBM
jk> research center in california, they gave tutorials on using UML
jk> with their user engineering process. My feeling was that, for most
jk> non-ibm participants (lot of them were designers with no
jk> engineering background) were overwelmed with UML.

The OVID tutorial is available for download at
http://www-306.ibm.com/ibm/easy/eou_ext.nsf/publish/589

On the surface, full-scale UML modelling may indeed seem an overkill
on smaller projects. However, I would rather draw a line for UML
recommendation not between project sizes, but between individual/team
preferences. UML is a notation for "engineering minds" ("engineering"
is used with great respect here) and works very well in product teams
dominated by abstract thinkers and the engineering culture. If you or
your team don't think as engineers, forcing the notation on your work
will only lead to dissatisfaction and (often inaccurate) blame of UML
for being a bad design tool. If you do, however, it's worth investing
in learning UML and OVID - it injects a great deal of structure into
the design process and clarity into design communication.

I am fortunate to work with designers who love UML (and created OVID)
as well as with designers who wholeheartedly dislike UML and try
avoiding it at any cost. Listening to both sides over the years, I
came to the conclusion that it's not about the fitness of UML for
design, it's about relationships between the designer and the method.
After all, some prefer eating noodles with a fork and some do with
chopsticks. Choose wisely what's appropriate not only for the industry
at large, but also for you and your specific design environment.

Lada

22 Jun 2005 - 4:14pm
Wendy Fischer
2004

In my HCI System & Analysis Class way back when, we learned a an OO notation for connotating actors, states, objects, etc in order to do our use case analysis. It was similar to UML notation (which is a merger of Booch/Grady anyway).

In real life, I tend to do my own internal system analysis this way when I analyze complex systems. However, whenever I've tried explaining it to designers, I've just gotten blank stares. I've tried seeing about using at other places that are already using UML/Rational Rose to create their object model for the development, and been told that the engineers are already doing that type of analsyis, or the PM was doing the use cases (which were usually weak).

I think it's definitely useful as part of analysis and design. I think that way in the background but it's just the one of the techniques that I am going to push in an organization because I've just never seen the interest in employing it as a technique. I think I have enough battles to fight, using UML notation is not even on the list....

-Wendy

23 Jun 2005 - 8:58am
Tom George
2004

On Jun 22, 2005, at 05:14 PM, Wendy Fischer wrote:

> ...and been told that the engineers are already doing that type of
> analsyis, or the PM was doing the use cases (which were usually weak).
>

That's right... don't worry your little designer head about it. Big
brains are at work in the back ;-)

> I think I have enough battles to fight, using UML notation is not even
> on the list....

In my experience UML is talked about more than used. Most developers
can't even read it properly much less write it. And they have a point.
Class, object, and interaction diagrams can be very good for
illuminating hard to understand structures but using UML to model
simple classes or relationships (80% of any project) is relatively
pointless. The actual code is often more succinct and expressive.

As for UML in modeling interaction design... hmmmm. I think that
scenarios can be expressed effectively as use cases but what is the
point of the stick man diagrams? Anyway, the audiences are often
expecting different things. We recently delivered a fairly
comprehensive set of scenarios disguised as use cases (written not
diagrams) to an IT department. First thing they did was re-write them
in a looser more "use case" style, which, in my opinion, made them less
actionable. Our use cases could be used to verify the completeness of
the UI framework and wireframes. After the IT dept. was done they were
only suitable for light reading.

-Tom

--

Tom George
DesignAxiom Ltd.

http://www.designaxiom.com

23 Jun 2005 - 11:55am
Wendy Fischer
2004

No, I think the glassy eyes and the looks that I am insane that come from the designers that usually do me in (this describes a past experience where I tried this once and the designers were more clearly on the right brained contingent than the left brained contingent)......better to babble about process, user profiles, architeture and the aesthetics of the Ipod than to blather about UML......

To quote somebody, a fomer pointy haired boss:

"There are only just designers. There are right brained designers and left brained designers and designers in between."

Wendy

Tom George <tgeorge at designaxiom.com> wrote:
[Please voluntarily trim replies to include only relevant quoted material.]

On Jun 22, 2005, at 05:14 PM, Wendy Fischer wrote:

> ...and been told that the engineers are already doing that type of
> analsyis, or the PM was doing the use cases (which were usually weak).
>

That's right... don't worry your little designer head about it. Big
brains are at work in the back ;-)

> I think I have enough battles to fight, using UML notation is not even
> on the list....

In my experience UML is talked about more than used. Most developers
can't even read it properly much less write it. And they have a point.
Class, object, and interaction diagrams can be very good for
illuminating hard to understand structures but using UML to model
simple classes or relationships (80% of any project) is relatively
pointless. The actual code is often more succinct and expressive.

As for UML in modeling interaction design... hmmmm. I think that
scenarios can be expressed effectively as use cases but what is the
point of the stick man diagrams? Anyway, the audiences are often
expecting different things. We recently delivered a fairly
comprehensive set of scenarios disguised as use cases (written not
diagrams) to an IT department. First thing they did was re-write them
in a looser more "use case" style, which, in my opinion, made them less
actionable. Our use cases could be used to verify the completeness of
the UI framework and wireframes. After the IT dept. was done they were
only suitable for light reading.

-Tom

--

Tom George
DesignAxiom Ltd.

http://www.designaxiom.com

_______________________________________________
Welcome to the Interaction Design Group!
To post to this list ....... discuss at ixdg.org
(Un)Subscription Options ... http://discuss.ixdg.org/
Announcements List ......... http://subscribe-announce.ixdg.org/
Questions .................. lists at ixdg.org
Home ....................... http://ixdg.org/

24 Jun 2005 - 2:25pm
Anirudha Joshi
2003

Tom <As for UML in modeling interaction design... hmmmm>

I look at UML as more of delivery to the next stage than internal to
IxD. You still need scenarios, personas, storyboards, affinities
whatever else you use. But when you are done, give it back in UML. Then,
when there are changes (aren't there always), you should not need an
interpreter to translate back. You should be on the same page,
instantly.

Given this theory, did anyone actually do this ever?

Tom <First thing they did was re-write them in a looser more "use case"
style, which, in my opinion, made them less actionable. Our use cases
could be used to verify the completeness of the UI framework and
wireframes. After the IT dept. was done they were only suitable for
light reading.>

To each his own. One important reason to rewrite is not that earlier
writing was bad, but just to make sure that you understand everything. A
map your friend will draw for you giving directions to his house is
usually better than the printed map that you can buy at the airport, not
because your friend is a better designer, but because he knows what
information you need, and presents only that. Also because you drew the
map together.

But I get your point. It's still 'us and them' everywhere, isn't it? We
can't give them what they want, and even if we could, they don't trust
us. It doesn't sound like a team working together yet. That is why we
need to learn the other's language, and then get better at it.

Anirudha

24 Jun 2005 - 5:13am
Pierre Abel
2004

Tom George wrote:

>
> In my experience UML is talked about more than used. Most developers
> can't even read it properly much less write it. And they have a point.
> Class, object, and interaction diagrams can be very good for
> illuminating hard to understand structures but using UML to model
> simple classes or relationships (80% of any project) is relatively
> pointless. The actual code is often more succinct and expressive.
>
I just want to add some comments from a software developer/architect
point of view,
It is important to have a clear design document that contains all the
structure of the project. Personnaly, when I arrive on a project, what
I need is the design document (with the UML), not the code! As you
underline, it's rare to have such document, but hopefully there are some
reverse engineering tools that create the UML from the code.
UML is a productive tool for software/architect developper...and I can
tell you that if you don't design the architecture of your code, it is
really difficult to do something that runs correctly (except with really
small projet and also it depends on your experience). Developers that
cannot read/write UML are bad ones...

To compare with UCD, if you don't do the software architecture, it's
like if you do the first paper prototype without any analysis (of course
you should not go in the opposite way where you do too much
analysis......the middle path is the best!)

Pierre

24 Jun 2005 - 11:36am
Tom George
2004

On Jun 24, 2005, at 06:13 AM, Pierre Abel wrote:

> Developers that cannot read/write UML are bad ones...
>
> To compare with UCD, if you don't do the software architecture, it's
> like if you do the first paper prototype without any analysis (of
> course you should not go in the opposite way where you do too much
> analysis......the middle path is the best!)
>

Point well taken. And also Anirudha's point about UML as a delivery to
the next stage.

I think, however, it might be a bit harsh to classify all developers
who aren't UML literate as bad developers ;-)

If you first started designing and architecting with UML, it's probably
what you reach for first. For me, (yes, here's the confession) UML will
always be a bit of a second language and something formal rather than a
tool that I can think with.

-Tom

24 Jun 2005 - 12:45pm
Jim McCusker
2004

Tom George wrote:

> I think, however, it might be a bit harsh to classify all developers
> who aren't UML literate as bad developers ;-)
>
> If you first started designing and architecting with UML, it's
> probably what you reach for first. For me, (yes, here's the
> confession) UML will always be a bit of a second language and
> something formal rather than a tool that I can think with.

Hear hear! I've seen way too many auto-generated UML diagrams from an
unstructured pile of code that passes as "documentation" and far too few
successful round-trip engineering uses to feel that UML is really great.
It's useful for whiteboarding a class inheritance structure for intial
design, but the devil is in the details, and UML by definition hides
those details. I much prefer browsing around the source tree in emacs (I
can move between 10 different classes in as many seconds in it because
all of it is keyboard-based with no extra windows open) than trying to
scroll around a class diagram for learning about a new code base.

Jim

Syndicate content Get the feed