Consider a store with multiple branches and a system generates reports for each branch monthly and annually and an overall report as well monthly and annually. So in total there are 4 types of reports

  1. Monthly branch-wise report
  2. Monthly overall report
  3. Annual branch-wise report
  4. Annual overall report

How are they to be depicted in a class diagram? I tried it as follows, which is correct? Trial 1

Trial 2


I'm sorry, but I have to inform you that there is no "correct" or "wrong" in class designs. You can do "wrong" UML by drawing strange unicorns into the diagram, but whether your design is good enough depends on a large amount of different factors. It's not as easy as simply telling us one requirement and expect to be able to derive a design from that.

The two designs you have are possible candidates. Another obvious one is similar to your second one, in that you create base classes for annual and monthly (instead of general and branch).

However, since your reports seem to have two unique dimensions (general/branch and monthly/annual) a tree-based design may be unsuitable. For example, your Monthly_branch and your Monthly_general classes are kind of related, but the design cannot express that any better than saying they are Reports. This may or may not be a problem in your specific use case though.

In general, making good designs (whereas "good" is defined by the design's implications down the road of project development) requires a lot of experience. As a starting point try to come up with at least half a dozen more design variations for your problem. There are countless ways to design a class model, and finding the best one for the job will always require you to be able to have a large set of candidates to pick from.

|improve this answer|||||

They are both correct, you just have to make a choice and hope that you picked the best one. The only thing that can increase your chances to pick the best one is you experience with that kind of problem you are trying to solve. For example there are some choices that are better in the short period but when it comes to maintain and update they aren't so good, vice versa some choice are more painful on the short term but in the future they turn out to be very smart. Again there's no way to tell if it's better to make a "short term" or "long term" choice since it depends on your project, your requisites, your relationship with the client, your budget and so on... Those are problem related to design decision, there's plenty of literature about that and i suggest you to start with wikipedia. The one thing that you have to keep in mind is that you are responsible for that decision in every possible scenario that could be a success or a disaster.

|improve this answer|||||

As the other questions point out, there is no "Correct" or "Incorrect" when choosing between those (and other valid) options.

You do seem to have identified that there are 2 pairs of differences between the reports, location ( branch / overall ) and time ( monthly / annually ). You can ask yourself "Am I likely going to be asked for quarterly / weekly reports? Am I likely going to be asked for reports grouped by regions (City / State / etc)?". In answering those questions you may see that one strategy would be easier to extend / maintain than the other.

As @Frank mentions, it sounds like both are likely extensions, so a design like the following may be prefferable:

class Report {
    timeGroup TimeGrouping,
    placeGroup LocationGrouping

class MonthlyGrouping : TimeGrouping {...} // dates in the same month together
class AnnualGrouping : TimeGrouping {...} // dates in the same year together

class BranchGrouping : LocationGrouping {...} // groups of size 1
class OverallGrouping : LocationGrouping {...} // one group of everything
|improve this answer|||||

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.