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?

Solution 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

Solution 2

Activity diagram is one of the those with widest abstraction range in UML. An activity can be used for anything between a business process (very abstract, comparing with software system) and a single method algorithm (code-level, practically blue-print, meaning kind of abstraction ground level).

Use Cases on the other side are in practice very limited in their abstraction. They show the interaction between a user and the system and would be somewhere in the middle of the abstraction scale. Not as abstract as a business process, and definitelly a lot more abstract than the implementation diagram.

Software projects tend to start working on a very abstract level (business goal for example) and finish with the abstracion 0 (implemented system). During the project analysts, architects and developers work together to gradually lower this abstraction producing always less abstract artifacts/models - business processes, use cases, architecture, design, code.

After this introduction it is not hard to answer your question - any of those can be used first and that depends on type of your project and its size. SOme examples:

1. A large project of development an ERP system. It is almost certain that in this kind of project the first thing to model is the business process. A long before even thinking of its functionality, the team must understand the business background. The best UML diagram for this is naturally the activity diagram. Some time after, when the process is clear and the high-level reqs known, the use case modelling can start.
2. A middle sized of relativelly small project, with no complex processes in background (for example a mobile app development) can start directly with use cases, identifying the users and their features. Later on, these can be further refined using activities.
3. A very small development of some interface, driver of communication gateway, highely technical, where even the user interaction is minimal, the modelling can start with the activities again, showing the concrete algorithm too be implemented. USe cases can be completelly skipped.

As a summary I would conclude that there are no unbreakable rules of this kind in software development. Each project is unique, each development methodology is unique, even each development team is special and unique. To think about "which diagram" to do first is straight and simply WRONG! Think about what kind of analysis or specification you need in a given moment - what is easiest and most usefull to be modelled. When this is clear - there are 13 UML diagrams to pick up from in order to optimally fulfill the aim.

Choice of UML diagram is the "HOW". More important than that is more often than not - the the "WHAT".

Comments

[ARG]

Nice answer but suppose if we have 10 usecases then we need to make 10 diagrams for it ? or we can all explain them in 1 diagram ?

[Hippias Minor]

If you have 10 use cases and you decide to explain them using activity diagram, then show them in separate 10 activity diagram. To explain 10 use cases in single activity diagram ? Not a good idea. But the main point is you can understand and other understand it...Then even you can show it on toilet paper...

[Hippias Minor]

Use Cases are just requirements [what system will do, without how ]. So if you show 10 use cases as a single activity daigram maybe 10 use cases are just one use case: maybe some use cases are not real they are part of or step of a scenario.