Re: UML 2 shapes and/or related tools

[Stuart Rossiter <stuart p rossiter gmail com>]

A late reply (sorry!) to Alejandro.

From: Alejandro Imass <aimass yabarana com>

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'm currently a researcher (simulating social systems), so focus on more conceptual use of UML. As such, I mainly use class and activity diagrams.

I still do a fair amount of research software development though, and was previously a 'proper' software developer. In that context, I'd add use cases and package/deployment diagrams and, in special circumstances, sequence diagrams.

I found Fowler's UML Distilled (and Scott Ambler's online agile development UML stuff) to be useful guides, though both are very software-oriented and thus not very in-tune with conceptual UML. I have a very out-of-date copy of UML in a Nutshell which, at least in that edition, did focus on UML as a generic modelling language.

 

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".

Yes, us academics are not renowned for our tact :-)

 

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".

Yes, stopping design leaking into (use case) requirements is very important and sometimes very difficult. Martin Fowler (again) has some nice little 'mini-essays':

http://martinfowler.com/tags/requirements%20analysis.html

http://martinfowler.com/tags/uml.html

 

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.

Yes, will do. (If I ever find the time!)

Stuart