views:

140

answers:

4

Extends

Say you're looking at the 6 basic types of UML diagram (from this The Elements Of UML 2.0 Style)

  1. Class diagrams
  2. Use case diagrams
  3. State machine diagrams
  4. Activity diagram
  5. Sequence diagram
  6. Physical diagram

Pretend you're insane and you feel like drawing up all 6 diagrams for your system.

Which would you start with? Then which would you go to? What's the best order to visit each diagram if you have a pretty clear idea of what you want your system to do?

I think you should start with the physical diagram and work your way to class diagram. Top down, I always say..? Am I wrong?

A: 

Physical diagram is probably as good a place to start as any. I find activity diagrams really helpful in working out the kinks in a design, and sequences are good for much the same reason. I've rarely bothered with state machine diagrams.

I think realistically you're going to want to revisit whatever design you do first anyway (iterated design, woo!) so it's probably worth starting with whatever is going to bring the most clarity to your project.

arcwhite
A: 

UML diagrams are depictions of various models of a design. I am not sure that they can be cleanly serialized the way you describe. Frequently a class diagram is used in both the analysis and design phases of a process. Similarly other diagrams are used in multiple phases.

It depends on which aspect of a design you are interested in at any point in time you use the appropriate diagram to "view" a model of the design.

I have seen both "start with class diagram" and "start with use case model" proposed. I have come to realize that it really does not matter.

I think you want to start with the high level behaviour of the system using several diagrams then gradually work your way down to more detailed design using the same set of diagrams.

Vincent Ramdhanie
+1  A: 

Use cases are the main ones that define "what" your system does, possibly followed by state machines and activity diagrams (which could be seen either way -- normally the activity diagrams are more about the "what" and the state machines more about the "how", but I've seen counterexamples to each); class and sequence diagrams, and even more so component and deployment ones (collectively the "physical"), are more and more about how your system does what it does. I'd definitely go from the "what" towards the "how" as the reverse sequence makes little sense -- how can "how" make sense if you haven't defined the "what"?

So, summarizing, roughly: use cases, activity, state machine, class, sequence, component, deployment. This order makes sense because it gets deeper towards the implementation aspects and away from the analysis aspects, so e.g. somebody interested in understanding exactly what use cases you'll cater to and what business rules you'll apply (activity diagrams) may stop "reading" earlier than somebody who needs to understand the full detailed logic of your deployment strategy.

Alex Martelli
I have to say this answer was particularly helpful. I particularly enjoyed activity before state machine, and class before sequence, and activity before class.
bobobobo
@bobobobo, tx for the kudos -- always glad to be of help!
Alex Martelli
+1  A: 

Class, sequence and usecase diagram represents over 90% of usually created diagram inside a project. Class diagram itself sometimes represents more diagram than all the other diagrams.

The best solution is to keep it simple and adapt the modeling to the level of the team.

If no UML experience then just create class diagram to represent the skeleton of your application.

If beginner level then start with an usecase, sequence and class diagram.

If medium level then use all the diagrams because each diagram cover another view which is not always possible to code with Java. I mean that java is only related to class and sequence diagram.