A late reply (sorry!) to Alejandro.
> From: Alejandro Imass <aim...@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
_______________________________________________ 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
