On Thu, Jul 18, 2013 at 10:35 AM, Stuart Rossiter <stuart.p.rossi...@gmail.com> wrote: >
[...] >> >> From: Alejandro Imass <aim...@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 _______________________________________________ dia-list mailing list dia-list@gnome.org https://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://live.gnome.org/Dia/Faq Main page at http://live.gnome.org/Dia
