UML: Going from Use Case to Class Diagram

Question

In simple steps how can one make the transition from a Use Case diagram to a Class diagram?

Answer 1

Here is my suggestion:

• rent a good software designer with some years of experience
• let him/her read the documentation of the use case diagram
• explain him any questions he/she has (or let this be done by someone who knows the domain well)
• let him/her make the class diagrams for you

And don't expect that the process "use case diagram -> class diagram" can be described here on SO in-depth in a few sentences. That's like "I have a picture of a car, please explain how I get from there to a blueprint of the engine".

Answer 2

Last year I gave a talk at ICSOFT 2010 that addressed that particular issue. The answer is not simple and I cannot describe it here in full, but you can download my presentation here. Scroll down to slide 23 "Moving from functional to structural models" for this topic.

The OPEN/Metis white paper contains additional information to complement the presentation.

The basic steps to obtain a class model from use cases are:

1. Create a service model for each use case.
2. Define operations for each service and busy state in your service models.
3. Determine the responsible class for each operation, adding new classes when necessary.

I will be happy to extend this answer with additional details if you have further questions.

Answer 3

The question is one of 'object discovery'; the process of investigating a system requirement and identifying the 'objects' that could implement or be involved in the operation of such a system. There are a number of techniques for object discovery, one of the most productive and communicative is the class-collaboration-responsibility (CRC) card technique.

Despite its name, CRC is primarily about object discovery, not class discovery, and perhaps (ORC would have been less confusing if you ever work in communications systems where CRC means something entirely different), but the latter follows from the discovery of the former, and this should always be object oriented design not class oriented after all.

Either way, by using CRC to generate candidate objects, and then using them to 'walk through' use case scenarios, you can refine your set of candidate objects (discarding unused ones, and creating new ones as necessary), and refine their responsibilities and collaborations as you go. When you then have a stack of cards that satisfy all the use case scenarios, you can use them to identify classifiers and class hierarchies. Often one card will become one class, though it may have represented several objects in the walk-throughs, you may even see that several objects have similar responsibilities and are in fact one class or sub-classes if a common super-class. All this informs the relationships and classes for your class diagram.

The collaborations discovered during the CRC exercise form the relationships in the class diagram, the nature of the collaboration may determine the use of aggregation, composition or otherwise, but that is often a detailed design or implementation issue and may not be obvious or even desirable at the use case level of design, which is generally more of an essential or requirements modelling exercise than an implementation modelling exercise. Use case -to-implementation is usually too large a step, especially if you have to verify your model with stakeholders with perhaps domain expertise, but not software architecture expertise.

Answer 4

Do you only have a Use-Case Diagram or do you have the scenarios to go along with the Use-Cases? If you only have the Use-Case Diagram then I would recommend creating the scenarios to go along with the Use-Cases. I like english sentences but activity diagrams work fine also.

After you have the scenarios, the next step is to create sequence diagrams. Assuming your scenarios were done properly then your domain classes will fall out of your sequence diagrams straight-forwardly. You can then optimize your domain classes to meet whatever criteria you deem is important in your system.

In any event, IMO, you absolutely don't come up with the classes first, despite some methods that suggest otherwise. It will only result in fitting square pegs into round holes. Let the classes identify themselves and they'll do that quite nicely in the sequence diagrams if you take the time to learn to do a sequence diagram properly and not just for hand-waving purposes.

Answer 5

What I do is to use classes with actor, usecases etc.. as stereotypes in my usecase diagram then drag and drop the same classes into my class diagrams. It does the job and it is pretty efficient.

Answer 6

This is a very good and intersting question without definite answers. There are many methodologies and practices encouraging similar yet different approaches. You can find one in another answer. Others include use case realizations and analytical modeling (UP), domain modeling (DDD), CRC cards (RDD) and many more. What I consider to be similar to these approaches is looking at steps in use case descriptions (use case diagrams are not of a much value per se) and identifiying input and output data and their relation to the problem domain. From there on it is mostly intuition I guess. Overall use cases aren't primary source of the OO design, they are important as specification of behaviour of the system and for managing requirements.