Why do class diagrams don't include all classes?

Question

Most UML class diagrams I have seen are almost what an ER diagram would be and lack classes that are programmed.

If i'm interested in web based apps. These ones have classes that access REST resources (which I believe are like boundary elements), they also contain classes that provide services or perform operations (control elements maybe) and finally classes that represent what is in the database (entity elements I suppose). So most UML examples i see around only diagram the entity elements. Why is that? Is it too much detail to place the other classes?

For example: An app which performs this 2 user stories.

1. A client performs a login from the webpage.
2. A logged client requests an order.

I would model the following classes:

1. A REST class which receives the information from the Front End of the application.
2. A Login class which performs the operation of searching and validating the information received by the REST class and then create an instance of user with the information.
3. A User class which has a method to request an order.
4. An Order class.

So why are all these classes not modeled in a class diagram?

Answer 1

Analysis of a problem domain is critically important to software and database systems. Without analysis of the problem domain, one cannot understand system requirements, and one cannot implement a system correctly. A rush into the solution domain is often at the root of failed projects.

Classes should be a way of organizing information and relevant code fragments in a way that is more durable than the ever-changing technology or framework de jour. Over time, one should be able to replace the implementation of problem domain classes with new technology to satisfy non-functional requirements. If you start with a "REST" class, you've lost durability because REST will be something else in a few years. If you create a "Login" class, you've also lost durability. What happens when some near-field technology makes typing a password completely irrelevant? You might be "logging" the user, but I bet the implementation will be all wrong. The problem domain tends to change much more slowly than technology. For example, the domain of "trade" hasn't changed much since ancient times.

UML is particularly useful for thinking through the problem domain. Some prefer to use it for sketching, but others have been compiling UML analysis models into code for quite some time. (For more, see Mellor and Balcer's book, Executable UML: A Foundation for Model-Driven Architecture, or H. S. Lahman's book, Model-Based Development: Applications.) You may be surprised to hear that some really big companies use this all the time for mission-critical software.

UML's suitability for analysis is one reason why you tend to see UML class diagrams that look more like ER diagrams. UML and ER are both ways of analyzing the problem domain; UML can just take it much much farther. Another reason you won't see many design models is that most developers would rather implement than design.