UML Modelling – Part II. 20 Rules how to model Use Cases view

For many years it has been a standard part of the programmer’s practice to use class diagrams and data scheme diagrams where the experience proved their inevitability, especially for modelling of the information systems’ basic static features. Besides that, UML offers other innumerous modelling techniques – for 80% of system modelling only 20% of UML abilities are enough 🙂 and one of them is the Use Case modelling, which became a standard modelling tool for dynamic characteristics of the information systems over the past years.

Based on my experience here are some rules with Use Case modelling:

  1. Do not misuse Use Cases as a system specification – Use Case isn’t functional specification
  2. Do not misuse Use Case scenarios for test cases (Use Case scenario has nothing to do with system test)
  3. Write as little as possible (full Use Case forms are just a myth and a road to hell – remember that you have to transform analytical model into detail specification)
  4. Do not write alternative scenarios as extended Use Cases (rather through Use Case scenarios)
  5. Always use names and terms in your Use Cases that correspond with your domain model, name your Use Case scenarios with prefix based on Use Case unique identifier
  6. Firstly write happy day scenarios, after some analytical iterations write alternative scenarios and error scenarios
  7. In your scenarios use unique identifiers with scenario type postfix – happy day empty, alternative “a”, error “e”
  8. Use relations such as Include and Extend properly as per UML specification (“include” doesn’t mean functional inclusion)
  9. Do not write an extra Use Case for “Create”, “Read”, “Update” and “Delete”
  10. Do not write any implementation-specific information into Use Case, since it decreases readability and structuring of your model
  11. Try to define carefully all actors and use them in your Use Case diagrams
  12. Always capture with the Use Case any activity of the actor in the system, not a system feature (system feature = Use Case, system feature realizes Use Case)
  13. Try to recognize the most important business Use Cases with your customer firstly, focus on real-world objects
  14. Model conceptual Use Case diagrams – write Use Cases only and model all the dependencies; it’s not enough to explain all objectives of your systems, but try to capture the problem-oriented Use Case diagrams from as many possible points of view as you can
  15. Link your Use Cases with your model specification
  16. Utilize the Use Cases identifiers in source code or task management too, consequently Use Cases realization will be then more traceable throughout your whole implementation
  17. Categorise your Use Cases through stereotypes (for example Search, Listing, Edit, PrintReport, Validate, NonSystem, Diverse, Unknown, …)
  18. Build project-specific Use Cases styling for diverse projects
  19. Do not package Use Cases in very high granularity, try to achieve that all your Use Cases have a similar level of granularity
  20. Do not try to “build” source code from your Use Cases 🙂 – Use Case is an implementation- and technology-independent piece of abstraction just for communication between the customer and development team as well as within the development team.

Use Case modelling is mainly about WHAT the information system has to do, not about HOW – and has to be easy to read in order to be understandable for all project members from customer to software developers with the main focus on your customer’s needs.

Requirement Engineering, Business Analysis, Agile, Analysis and Design with UML, Java/J2EE, Liferay, Javascript, Embedded C++, MDD, Executable UML, Project Management