So I'm designing an Education Management System and I'm wondering if I should be creating the Use Cases or the Class Diagrams first?


You should be first defining how the tool you are creating is going to look, feel, and be used by your users/customers. That is what dictates how your software will be architected.

People use your software, not computers, so design how people will interact with it first. If you design around how software components should fit together, your user interface will be made for robots, not human beings.

| improve this answer | |

Always create Use Cases first. However the detail with which use-cases are worked out depends on your familiarity/comfort with the domain, if you have worked within the domain before initially you can keep your use-cases brief and expand it later on along with the development.

| improve this answer | |
  • I agree with what both of you say but I think he worded it a little better, that's why I gave him the answer checkbox – Jarred Sumner Dec 26 '10 at 7:22
  • @Indebi That's OK I am bit lazy at explaining :-) – Gaurav Dec 26 '10 at 7:28

Actually, Jim Coplien advises not to dive into the Use Case diagrams too soon, but rather to first find out the simplest mental model for the domain.

Focus on the essence of the system form (what the system is) without being unduly influenced by the functionality that the system provides (what the system does).


For if your system thinks about the domain in different terms and concepts than its users, they'll have trouble understanding each other. And if your domain model is solid, it will be easier to implement changing requirements on top of it.

So I think the answer is: That depends on what you're planning to put in those Use Case and Class diagrams.

I'd start thinking about classes for the domain model. Talk with people who currently are working in this domain, find out in which terms they think and talk about education. Once you understand the domain, think about the Use Cases. Then as you start implementing technical stuff, think about the classes and objects that you'll use to implement this.

Don't be shy to produce code rather than diagrams all along. A picture is nice, but compiling and running code is a lot more concrete. So classes that model your domain are a good first and reusable artefact, even better than a class diagram.

| improve this answer | |
  • You had almost the perfect answer until the last paragraph, but I upvoted anyways. The process of creating Use-Cases reveals new domain classes, whereas the process of creating the domain class diagram helps create the use-cases. In particular, by defining specific names and helping to see when the use-cases are getting to detailed. Domain classes can end up being implementation classes but not always. They are better described as modules. IME, heading straight to code ends up with brittle classes. If you are going to take the time to do use-cases you should also spend some time doing design. – Dunk Sep 24 '14 at 13:53

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.