Re: UML 2 shapes and/or related tools

[Alejandro Imass <aimass yabarana com>]

On Thu, Jul 18, 2013 at 10:35 AM, Stuart Rossiter
<stuart p rossiter gmail com> wrote:
>

[...]

> > From: Alejandro Imass <aimass yabarana com>
> >
> >
> > What exactly are you missing for UML 2? We use the UML 2 standard with
> > DIA (albeit not religiously a la OMG/Rational) but we are very fluent
> > in V2 and we use DIA for all our work. Can you provide an example of
> > what you are trying to do?
>
>
> Alejandro: a fair question. Unfortunately this was a bit of a
> 'fire-and-forget' post, as the UML modelling work I did that brought up some
> apparent shortcomings was quite a long time ago. I'm in the middle of some
> other work and don't have time to go back over it (I'm not even sure which
> particular diagram types I had frustrations with), but I appreciate that I
> probably can't expect too much help without more details!
>
> I may also not have 'thought laterally' enough in terms of adapting existing
> shapes for my needs.
>
> If/when I have time, I'll go back through everything and post again. Out of
> interest, what are the normal set of diagram types you use and where (if at
> all) do you need to use shapes outside the UML set? (I know that, in
> principle in UML 2, these are not rigid divisions...)


We are not UML experts by any means, being a small and dynamic shop so
we only use about 5/6 artifacts in most of our work:

1) Use Cases: extensively used during requirements phases and also
internally to discuss scope, etc.
2) Activity Diagrams: for business process definitions, specifications
and also scoping.
3) Communication Diagrams (prev known as Collaboration Diagrams in UML
1): we use these extensively for design, to count components,
packaging work and planning. Perhaps we abuse Communication Diagrams
because we are probably combining Object and Component in a
behavioural view but they have been very useful for us since UML 1.
They are easy to understand by everyone so we bend the rules here.
Besides, we use UML as a guideline not as religion.
4) Class Diagrams: we use these twofold. Sometimes for software design
or to emphasize some particular design feature, though not common
because we program full iterative + TDD so class design is mostly on
the fly. However, we do use Class Diagrams extensively in database
design and we create the SQL-DDL scripts directly from the diagrams
using dia2code. This also allows to document any triggers as methods
on the tables though it's only informational. All comments on
properties are used to automatically create the data dictionaries for
documentation simply with an XLS sheet that extracts this info from
the DIA file.
5) OSD: Only in cases where timings are really important we use OSD.
6) Package Diagrams: we have used them but usually #3 above does the
job for most of the development we do.

I have used DIA since about 1998 with UML 1 and then switched to UML2
style probably around 2010. Actually it's a funny story because we
wouldn't have changed anything if it wasn't for a customer who
happened to be a university professor and rejected all our documents
because they were "all wrong". We were in fact somewhat updated to UML
1.4-1.5 at the time, but he forced us to adapt to UML 2 so we forced
to catch up. In reality though, our problems had nothing to do with
UML versions but rather was abuse of use cases (as we would violate
the requirement - design frontier) and that we didn't use Activity
Diagrams at all, things we could have corrected using UML 1, but we
had already read-up on the new stuff so we "upgraded".

For our work the impact was very low and we found no limitations with
DIA to keep up with the new UML 2 styles. If you do find them, let's
discuss theme here and see if we can contribute together to solve
them.

Best,

-- 
Alejandro Imass