Use Case Diagram and Activity Diagram, Chicken and Egg?

Question

I want to question and/or perhaps challenge the school of thought on UML behavioral diagrams.

Firstly, I want to ask, what comes first: Use Case or Activity?

I was taught that Use Case diagrams come first and then for each Use Case, you have one or more Activity diagrams to represent successful and alternate flows. From the Activity diagrams, you can identify nouns to establish classes.

I have, however, read other articles which say you create an Activity diagram for the end to end process and then from that, you can identify Use Cases.

I can see both scenarios working, and am confused, as to me it seems a case of hierarchy. For example, say I have a high level business process which is 'Grading Student Results'. If I map it as an Activity diagram, within which I would see swim-lanes. I would be able to pick out Use Cases, such as 'Determine Grade Boundaries,' 'Submit Results,' 'Convert Result to Grade,' and so on.

You could argue they are the same thing, i.e. both diagrams would meet this process modeling need. I then want to model the next level, for example, how you 'Submit Results.'

Can someone advise on the best practice: whether a Use Case diagram comes before or after an Activity diagram?

Answer 1

First:

There is no competition between any of the UML diagrams to be the "first one". Sometimes it is better to work on some diagrams simultaneously and iteratively.

Second:

Each diagram can be used in different contexts and for different purposes.

Use Case Diagram vs. Activity Diagram

"Use Cases" are scenarios which show how the user will use the system to achieve their goals.

So:

Instead of showing this "scenario" with written use cases, you can visualize its' steps with an activity diagram.

But in order to find use cases, you should discover the system requirements to some degree, (e.g. the scope, broad feature set, priority, cost, etc.).

In some business domains, such as for an automation project, in order to discover requirements/use cases, you may have to investigate current business flow. Sometimes this business flow can be complex, so you may want to investigate it with an activity diagram.

So:

An activity diagram can be used to investigate a business process to understand and discover the flow, to better discover requirements.

So:

An Activity Diagram can be used at different levels of software development stages for different purposes.

Just like other diagrams, you can use the Activity Diagram at any time, anywhere, as soon as it can help you to ask the right question, to understand and explore any issue related to your purpose.

Here is a summary purpose of Activity Diagrams:

The purpose of the activity diagram is to model the procedural flow of actions that are part of a larger activity. In projects in which use cases are present, activity diagrams can model a specific use case at a more detailed level. However, activity diagrams can be used independently of use cases for modeling a business-level function, such as buying a concert ticket or registering for a college class. Activity diagrams can also be used to model system-level functions, such as how a ticket reservation data-mart populates a corporate sales system's data warehouse. UML Basics : The activity diagram by by Donald Bell

To get a quick grasp of which diagrams can be used for which purposes, I advise you to check out Scott W. Ambler's mini book: The Elements of UML(TM) 2.0 Style