What are the design defects that can be spotted by using a class diagram, and how?

I am not concerned about syntactical/ representational defects, but in things like the following:

  • Do the classes/objects have data elements or getter/setters and no actual business methods. If yes, immediate red flag, design is probably a database model or some procedural type design.

  • Cyclic dependencies.

  • The amount of technical jargon in class and method names. Ideally none, the more there is, the worse the design probably is. Technical jargon is things like: Manager, Entity, ValueObject, Object, Repository, Service, etc. None of these things should be visible.

  • Deep hierarchies in classes

I could not find a list of the commonly occurring errors, only research papers.

Which OO principles can be validated by looking at a class diagram, for example, the SOLID principles (like in this former SE question)? Or is there anything more?

  • By looking at the diagram and analyzing it. The whole point of making such a diagram is to provide a visual representation of your object graph so that you can spot things like cyclical dependencies. A rigorous treatment of every possible thing that can go wrong with the diagram is not necessary; it's just a design tool. The resulting program will demonstrate soon enough the things you missed. – Robert Harvey May 9 at 2:11
  • Can you please name some common pitfalls(like cyclic dependencies ) or know a good resource about the pitfalls, i want to keep the question simple. – Sheikh May 9 at 3:13
  • @RobertHarvey , i think the class diagram should abide by the SOLID principles (Am i right about my opinion, please add to it), i want to make similar points out for my question – Sheikh May 9 at 3:16
  • 3
    The quality of any model is as good as its representation of the reality behind it. You can make a technically perfect model that is useless nonetheless. The most common mistake is not matching that reality but that cannot be spotted by just looking at the model, without knowledge of the reality it is supposed to represent. – Martin Maat May 9 at 7:55
  • 2
    You ask about defects in a class diagram but I guess you actually meant find design issues via a class diagram? The first is only UML syntactical compliance. Maybe you should adapt the question title. – qwerty_so May 9 at 11:47

You will not find many design defects in a class diagram itself:

  • The class diagram is a language to communicate about the design. If you’d use English language to communicate about your design, you wouldn’t probably look at the choice of words or the structure of the sentences to find flaws in the reasoning, would you?
  • Moreover the class diagram only shows the static structure of your design. It does’t tell anything about the intents, the roles and responsibilities and the dynamic of the collaboration between the classes. So most of the design issues are anyway elsewhere.

You may find the defect by understanding the classes and how they are supposed to work together, so making deductions a out the missing parts. But this relies more on your knowledge and experience of similar designs rather than on the diagram.

Finally, the only flaws that you will find directly in the class diagrams are structural flaws: for example the existence of dependencies that are not desired. Or properties and operations which do not seem in line with sound practice (e.g. a long list of unrelated operations, or a property which seem to belong to another class). But even here, the defects that you may catch are not in the diagram, but in the way the diagram matches your knowledge of the domain and your interpretation of what a sound design should be.

About this last point, keep in mind that the class diagram is the communication tool that will facilitate the discussion between designers, and only the argument brought forward in these discussions really help to judge if for a given challenge the class structure it is a good design or not.

| improve this answer | |
  • Here's a thread on this website where people are finding which SOLID Principles the class diagram breaks. The community are divided in their comprehension about this topic.You said it is the code that can abide by or go against the SOLID Principles. They are practically doing the opposite. Thread Link : softwareengineering.stackexchange.com/questions/381648/… – Sheikh May 9 at 22:43
  • 2
    @Sheikh As you can see, I answered the question in that other thread. So you can believe me when I tell you that I used exactly the techniques I’ve described here. The diagram alone about books and ebooks was not sufficient: to find the flaw: I had to use my domain knowledge about books, ebooks and stock management and to understand how the classes mapped to these domain concepts in order to find out that there was a design issue. Would the classes, the properties and the operation be named in a foreign language in that diagram, I wouldn’t have been able to spot any flaw. – Christophe May 9 at 22:52

Yes, diagrams can be used to find overall / high level defects in the modeling and design and are sometimes a good base for discussions. Be aware however that design is a highly subjective topic.

First, forget the SOLID principles! There are much more usable and practical ways to determine whether a design looks good or not. Here are some mechanical (easy to spot) things I use to get a first impression:

  • Complexity / size. The more items there are the worse the design is. The best designs look like you could come up with it in 10 minutes.
  • Do the classes/objects have data elements or getter/setters and no actuall business methods. If yes, immediate red flag, design is probably a database model or some procedural type design.
  • Cyclic dependencies. As you've said, those are bad. Ideally there should be none.
  • The amount of technical jargon in class and method names. Ideally none, the more there is, the worse the design probably is. Technical jargon is things like: Manager, Entity, ValueObject, Object, Repository, Service, etc. None of these things should be visible.

A design that scores high on those is very likely a good start. Then you can switch to semantics, whether the design reflects the requirements. For this you'll have to be familiar with the domain. Here are some criteria for that:

  • Can I "read" back requirements from the design? Example: It must be possible to freeze all credit cards to an account, I should see Account.freezeAllCreditCards(), etc. Though not everything is this clear-cut admittedly.
  • How easy it is to construct a series of random method calls that semantically do not make any sense. I.e. how tightly is the domain modeled. The more nonsense I can do with the objects, the more imprecise and error-prone is my design.

After all this works, only then would I go into details about whether an object could be split because it does too much, or whether an interface could be extracted, or similar things.

| improve this answer | |
  • 2
    I voted down not because I do not agree with most of what you wrote (I do) but because I think you have the priorities wrong. Semantics should be first, technicalities last. Technicalities can be fixed, if you have the semantics wrong it is never going to work. Rules of thumb (of which you provide a lot) are nice as indicators but hardly address the question. – Martin Maat May 9 at 10:53
  • @MartinMaat Fair enough. I've rarely seen any design diagram, especially here on stackoverflow which clears even the very easy technical checks I mentioned. That is why I think it is important to mention. It doesn't make sense to look at specific things if even the basics aren't right. – Robert Bräutigam May 9 at 11:08
  • @RobertBräutigam : What are the solutions for fixing the issues you have discussed like Complexity/Size and Cyclic dependencies ? – Sheikh May 9 at 22:55
  • @MartinMaat, i agree with your comment that the class diagram must first reflect the real world scenario and then we fix the technical issues. Nice. – Sheikh May 9 at 22:56
  • @Sheikh Cyclic dependency: Usually splitting out some behavior from one of the objects that then both depend on breaks the cycle. Complexity/Size is more difficult to solve. It involves creating abstractions, so each individual piece doesn't get large. I tried to describe why this is important in an article of mine with the somewhat pompous title: Transcending the Limitations of the Human Mind – Robert Bräutigam May 10 at 10:54

Trying to find defects in a design by just using a class diagram, without implementing the classes in code is like trying to find bugs in code without tests. -

So don't get me wrong, I am not saying it is completely impossible to find some defects (or "design smells"), but in total it is not very efficient.

So yes, one can look at the diagram and review it, but that will only allow one to fix the most obvious things, like bad class and method naming. But if there are "faults" in the design which really matter only the real code will demonstrate.

For example, since you mentioned it, let us take the SOLID principles:

  • S: if a class follows the "Single responsibility principle" depends heavily on what is happening inside it's methods, semantically. Something you cannot really determine from a class diagram (only guess by method naming, if you are lucky)

  • O: the OCP is not about having extension points in a class - it is about having the right extension points, the ones which are necessary to reuse a class later for certain scenarios without changing it. A class diagram can only tell you if you have extension points, and how they are named, but not if they are the correct ones required.

  • L: the LSP is about obeying contracts in derived classes. A class diagram may tell you the most obvious flaws like shadowing public attributes, but not if the semantics of the implementation of a method will violate the LSP

  • I: if two methods belong into the same interface, or if they should better be separated is something which usually shows up when someone really tries to provide different interface implementations - not at a class design stage, but, for example, when reusing a certain component.

  • D: dependency injection: a class diagram can tell which dependencies are going to be injected into the constructor of a class, but not if those are the right ones required to get the degree of decoupling which matters to the actual system.

So in short, class diagrams lack the description of the semantics of the code to which they belong, that is why their usage to find defects in the design is only very restricted.

| improve this answer | |
  • 2
    "You can't" is indeed the right answer, and the reason why incremental and iterative development with rapid feedback loops has become so popular. Personally, I think class diagrams are documentation and should be generated from the code, not the other way around. – Jörg W Mittag May 9 at 7:26
  • @JörgWMittag: thanks. Obviously we have still some people here who don't want to understand this. – Doc Brown May 9 at 7:34
  • I have come to a conclusion after this discussion that real defects in the class design/diagram can only be caught after coding it ,however, seemingly it should abide by all the SOLID DesIgn principles before even being coded/implemented. Can you please vet my statement. – Sheikh May 9 at 7:50
  • @Sheikh: no. The SOLID principles cannot effectively be abided or violated before a class gets coded, you follow (or violate) them during coding. I recommend not to think in terms of "class diagram is most of the design (like a blueprint for a building), and implementation like something just following the design." It is quite the other way round: the code is the real design of your system, and a class diagram only visualizes some aspects of it and reflects the code, but too few to find real defects or SOLID violations. – Doc Brown May 9 at 8:01
  • A class diagram is only about structure. And that can well be tested. A bad structure is a bad structure and can be found by discussing. Of course you can't find anything about behavior. – qwerty_so May 9 at 8:35

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