UML: what is the correct order of steps?

Question

I was reading an old text book "Beginning C# Object oriented programming" from 2011. The author in one case employs the "use case" to identify classes and then goes to draw a class diagram. In another case he goes through a textual description of a user scenario belonging to a "use case" to do the same thing.

This made me a bit confused on the order of the steps taken on analyzing a system with UML, particularly whether the use-case scenario step comes before the class diagram.

Do you use the nouns and verbs of the scenario in order to define the class diagram or does that happen in step number 2 "use case"?

And what comes after, the sequence diagram or the activity diagram?

1. SRS

2. use case

3. use case scenario or class diagram

4. sequence diagram or activity diagram

I don't know if order is important, or if people can just do the steps as they please, but I'm trying to think of it sequentially.

Answer 1

I totally agree with others here - UML is not a process. You need process and notation, and UML is a tool for the second.

Gathering requirements can be as agile and iterative as building the code.

The Use Case diagrams are a very high level summary. Behind each ellipse there are a number of scenarios. If you know the overall goal, you probably can intuitively identify a number of use cases, and you should write them down and build a first draft rough. And you can start to give them priorities, and start to map out scenarios.

Sooner or later, you'll refine use cases and scenarios. A sequence in a scenario might deserve to be a use case in its own right. Two use cases might be similar enough to merge into one. A use case may not really achieve a goal, so again it should be merged.

If a Use Case diagram is so high level, what's the benefit? Use Cases should deliver a goal for an actor, so they help us focus early on systems that are useful from the perspective of our users. They give us a list of discrete requirements that we can start to prioritise. When we reprioritise, we have units to trade off ("If you really want your pet use case Pay Supplier, you'll have to wait longer for this other use case Pay Salary"). When we prioritise up or down, it's easy to see which actors will be advantaged and disadvantaged.

The old advice to "underline nouns and verbs" is more about your scenarios. There's probably not enough detail in the Use Case diagram to identify candidate classes.

So as a starting point, Use Case comes before scenarios, but only as a starting point. There will be iteration and feedback as you work on your system. Similarly, scenarios come before classes as a first cut. When you get as far as operations, they should be organised into classes. So as a starting point, classes come first. When you identify an operation and it's not obvious where it should go, likely you'll create another class that you hadn't thought of before.

Activity diagrams are high level business process diagrams so may come earlier to communicate about your scenarios. Sequence diagrams document the behaviour of your operations and the classes and objects involved, so overall they'll come a bit later. Note that the UML Communication diagram shows similar information to the Sequence, but from a different perspective - time is easy to see in Sequence, the objects themselves have priority in a Communication diagram.

Answer 2

UML is just a language to draw pretty pictures with some chance that others understand what the shapes mean without an extensive explanation from you.

UML does not tell you which diagrams to use in your analysis and design of a system, nor in which order diagrams should, or even can, be used.

Which diagrams to use depends mostly on the information you want to convey to the people looking at those diagrams. The order in which you create them is entirely up to you.

Answer 3

Bart van Ingen Schenau's answer is right in that UML is just a language and not a methodology. However, there are some methodologies that are built around tools (including UML), such as the Rational Unified Process. Different UML diagrams are used throughout the different phases of RUP.

It's not really possible to specifically say how you can fit graphical modeling into your process without an understanding of your process. A sequential process is going to look different than an iterative and incremental process, for example. If you're basing your methodology on the agile and lean principles, that will also guide how you can apply graphical modeling into your process.

In a sequential process, Activity, State, and Use Case diagrams will likely be the first created. These can be used to capture business processes and activities at a much higher level of abstraction than some of the other diagrams. You may also start to see abstract Class, Component, and Sequence diagrams to start to capture business relations, but these will evolve over time to be more detailed. The other diagrams are closer to the architecture and code and will be created as you define your architecture.

The exact diagrams that you create will depend on what you are trying to communicate and who you are trying to communicate with. There's not much value in creating diagrams that don't help someone understand the system under design or progress with work. There are also diagrams and modeling techniques that aren't part of UML that could be useful.

Answer 4

If you're doing "object oriented analysis and design", then it makes sense to do the analysis before the design.

That would suggest developing use cases first, and sketching them out, before attempting to identify classes. Use cases really only need the actors and the primary systems in your design.

After that, and knowing what the system is supposed to do, you can start identifying classes. From that you can draw class diagrams.

The other diagrams you have mentioned need classes to be in place before you can draw them. So they would follow on next. But there's no specific order in which you have to do things, and you should work on an iterative bases, going back and refining earlier diagrams whenever it becomes clear that things aren't going to work out.

Answer 5

As the other answers said, UML is not a methodology, but a support for steps in a methodology. I found this classification useful to see how and where diagrams can fit in:

Since behavior also describes software from the user's perspective, those diagrams can also be used to model the external view of software (although I don't think I've ever seen someone use a Communication diagram for that!).

As for the question about "order" of steps, there are lots of development methodologies and many differ by a lot. But, they are all "heuristics", like asking someone for directions when you're lost in a city is a heuristic. Usually you get better results by asking someone (rather than wandering around), but there's no guarantee that it will get you to your end goal quickly (or even there at all). Writing software is not like navigating with GPS.

Answer 6

What is this approach?

Taking use-cases as basis to identify classes, as you describe, is typical of the Entity-Control-Boundary approach. It's not UML but rooted in the use-case driven software development methodologies such as:

• Objectory: promoted by Ivar Jacobson, the inventor of use-cases.
• Rational Unified Process: Rational hired Jacobson and the first RUP version was based on the Objectory methodology.
• Unified Process: the open version of RUP, also co-authored by Booch, Jacobson, and Rumbaugh, the founding fathers of UML.

It later entered the agile world, via the robustness diagrams of Agile Unified Process promoted by Scott Ambler.

What's next ?

Take a look at the above-mentioned methods for more details about steps, but keep in mind that UML is method-neutral.

It appears that use-cases are powerful to catch goals and requirements, but that they are by themselves a poor source for identifying classes:

• The classes are really identified in the discussions with the users (e.g. while a use case create order clearly suggest some classes like order or customer it will never tell you that orders could be linked to price offers or quote requests).
• UML use-cases can only help to prepare yourself thinking about the first obvious classes. Use-Case 2.0 by Ivar Jacobson, user story maps by Jeff Patton, or user-stories may be alternative to structure the needs more dynamically, without getting lost in an up-front analysis to which the to traditional use-cases (e.g. detailed step by step scenario) often lead.
• classes of the domain model tend to be designed using domain driven design.
• popular architectural patterns (MVC, MVP, MVVM, ...) and frameworks (e.g. persistence frameworks) will lead to the definition of most of the remaining classes.

Conclusions

You may follow your book as a kind of mental gymnastics and to learn some modelling tricks. But keep in mind that it's far from reality. Invest some time in having a look at DDD: this will be a very fruitful investment ;-)