What should be the sequence of diagrams creation in UML?

Question

As we know UML contains 13 types of diagrams (structural and behavioral)

before starting a software developement, we are in requirement and design phase so which diagram should be create and when? .. What should be the sequence of diagrams creation in UML in requirement and design phase?

In fact if there is no rigid sequence then first we need to create structural diagram rigidly but the behaviour like Activity diagram may change according to user experience?

Can we create a deployment diagram and component diagram as one only?

Answer 1

There's absoultely no rule regarding the sequence of such diagrams.

Sometimes, when the structure of the data and the behavior of your domain model is easily defined or well documented, creating the class diagrams first allow for clearer abstractions that aid in creating a sequence diagram that makes sense.

In other cases, when the nature of the domain model is unknown or unclear, it will make more sense to create a sequence diagram first, and then glean classes from that.

What I am sure of is that revisions of these diagrams will become concurrent with each other (e.g., sequence diagrams may reveal something that wasn't taken into account for in the class diagrams, and vice versa).

Likewise, after starting software development these diagrams may change yet again, as more intuitive, or more maintainable abstractions and designs reveal themselves whether via unit tests or user-experience testing and so on and so forth.

Never get enamoured with the idea that these diagrams are rigid in any way and thus requires a sequence in creation -- trust me, they won't be. If you treat them as rigid and infallible, you're shooting yourself in the foot AND tying one arm behind you in your software development effort.

UPDATE As reflected in the comments, if you're really lost as to what diagram to go first with, the Use Case Diagram would be very important as early as the requirements gathering phase.

Beyond that, what I wrote above applies.

Answer 2

In fact if there is no rigid sequence then first we need to create structural diagram rigidly but the behaviour like Activity diagram may change according to user experience?

Form follows function. If you need to change the behaviour, there's a good chance you need to change the structure from which that behaviour emerges.

Answer 3

I agree with Jon and Pete, but respectfully add that UML is the what and the how varies. There are processes like OOA and OOD (OOAD) which describe the how and what is UML. The wiki articles helpful, but it works more like this. Many RUP processes developed also involve the how of UML.

A standard set of orders for a user involved project (again use what you need): 1. Use Case (Focused on User/System Interaction. 2. Activity/Sequence that drills into the Use Cases. 3. Component/Interface diagram if you are connecting systems. 4. Package/Class if you are doing a large OO build. 5. Deployment to show what goes where in the infrastructure.

Nothing magical about the model/diagram elements I listed above but this seems to be the common set.

Answer 4

Usecase analysis is an effective way to capture the goals from the requirements. Use the usecase descriptions to identify your domain objects and produce a domain model. I find CRC useful at this stage even though it not official UML. Once I have produced my domain model I produce a Sequence Diagram for each usecase. Though Activity diagrams are also a useful alternative. I resolved the Domain model into a more detail class model. At this stage it is straightforward to produce a deployment model.