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

  • Is this a rhetorical question? Otherwise, my answer would be to skip the class diagram for now and write an automated acceptance test from the use case. Then write code until the test pass. Then refactor your design. Then generate a class diagram from the working code. – Martin Wickman Feb 20 '11 at 12:06
  • @Martin Wickman: I imagine you are kidding, right? – CesarGon Feb 20 '11 at 13:52
  • Assuming the use case is short enough to be captured in a few tests, no. This is a valid approach where you derive the OO design through tests and refactoring. The idea is that creating working software is more important than producing designs. – Martin Wickman Feb 20 '11 at 14:16
  • 2
    Greetings. I would highly recommend you look into 'Crc Cards'. Also would recommend reading 'UML Distilled'. Its a nice intro with some examples – Imran Omar Bukhsh Feb 20 '11 at 17:11
  • 2
    @Martin Wickman: OK, I agree that approach may work for extremely simple systems. But real-life, complex, business-critical systems (not to mention life-critical or avionics, for example) are not that simplistic. You really want a solid method that takes you from a user-centred, functional description such as use cases to a solution-centred, structural specification such as a class model. – CesarGon Feb 22 '11 at 11:27

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.

  • Thanks for sharing César. What is the type of diagram used for the service model? – James P. Feb 18 '11 at 12:41
  • 2
    The diagram type is a service state diagram. You can find it documented in the OPEN/Metis White Paper (verdewek.com/openmetis/Download/OPENMetisWhitePaper.zip). – CesarGon Feb 18 '11 at 13:12
  • 1
    This is one specific way of doing so. – Gabriel Ščerbák Feb 20 '11 at 0:19
  • @Gabriel Ščerbák: Yes, it is one specific way. But it is the only specific way that I've found to be systematically successful after 15 years of trying alternatives. Do you know of any alternative ways of doing it? – CesarGon Feb 20 '11 at 13:59
  • @CesarGon I mention some in my answer. I don't think your approach isn't good, I just say it isn't "the one thing" that obviously everybody does. – Gabriel Ščerbák Feb 20 '11 at 18:16

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".

  • Funnily enough I was thinking of doing this on oDesk ;) . This is for a end-of-studies project though and I'm a bit tight on resources. I'll definitely give it a go later on as being in contact with someone experienced definitely helps. – James P. Feb 18 '11 at 12:43
  • If not the definite answer, you can get some pointers, the point of SO is not to be Wikipedia for programmers:)... Btw. getting a fish and fishing are two separeate things;) – Gabriel Ščerbák Feb 20 '11 at 0:18
  • 1
    My CSE undergrad focused an entire course on software design. It was software programming for a quarter without the programming aspect. Focus was put towards project design, documentation and specifications. – Chris Feb 20 '11 at 13:27

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.

  • 1
    In my experience (see slides referred to in my answer on this page), a large proportion of classes in the system are nothing to do with the application domain. And CRC is good at finding application domain classes, but quite bad at discovering classes beyond that. For this reason, CRC is not enough, and I think that alternative techniques are necessary. – CesarGon Feb 20 '11 at 13:55
  • 1
    @CesarGon : Agreed, but use cases are application domain. For developing requirements models it is eminently suitable. For implementation models less so. I think I pretty much said that in the last paragraph. That said architectural modelling, the first step of mapping requirements to a solution, and modelling sub-sets of a solution CRC might still be useful, but at the detail level often you will often be involving too many staff in something that need not be that collaborative. – user17821 Feb 20 '11 at 16:47
  • Yes, CRC is useful, no doubt about that. My point is that you need something else in addition to CRC whenever you want to move past certain point into detailed design. – CesarGon Feb 20 '11 at 17:38

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.

  • 1
    This is a great answer because Use Case Diagrams have little information. They're akin to a table of contents of a book. The details are in the English of the use-cases (scenarios, alternate flows, stakeholders, interests, etc.). UML is not a methodology. – Fuhrmanator Jul 24 '17 at 13:56

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.


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.

  • Well, I (and a few teams and organisations) have been successfully using use cases as the primary source of input for OO design for over 15 years. The presentation and the white paper that I mention in my answer here on this page contain the details. – CesarGon Feb 20 '11 at 13:56
  • 2
    I have to agree with Cesar. I have also successfully been using Use-Cases to drive everything for years. The software requirements through the design on through system's testing. I can't think of much that doesn't tie back to the Use-Cases. Although, I agree the Use-Case Diagram itself is just a step above useless, but the Use-Cases themselves are essential. – Dunk Feb 20 '11 at 17:11
  • 2
    @Dunk: +1 for "the Use-Case Diagram itself is just a step above useless". – CesarGon Feb 20 '11 at 17:39
  • @CesarGon & @Dunk: Don't get me wrong, I have nothing against use cases, I think they are very useful. I just wanted to stress that there isn't a direct straightforward mapping between them and e.g. the class hierarchy, therefore there are many techniques to evolve the design from use cases. – Gabriel Ščerbák Feb 20 '11 at 18:13
  • @Gabriel Ščerbák: I agree that there is no trivial mapping between use cases and classes. But forward and backward traceability can be achieved (see materials referenced in my answer), and I find it's often necessary. – CesarGon Feb 20 '11 at 18:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.