Class Diagram: An Easy Way to Understand Code

How is possible to conclude it?

Each icon means something, for example, the symbol * in each item means it is private. The best way to understand the differences between each icon is to create a sample with each possible case. Let's see a fake class created for this purpose. Show Base Class When we select the shape and open the context menu we have options that allow showing/hiding various details. Let's see the case to show the base class. Then after expanding the shape for MyBaseClass we will have something like: At this moment, there is one point that is important to be defined. To show the diagram, what is the most important information that should be shown in the diagram? It depends on what each developer likes or wants to see, but in general, we can define it as a pattern. We should show only public properties, methods, and events and hide all others (in some cases it can be useful to show everything defined as internal or protected). Hide compartment Selecting the shape and then the item we want to hide is possible and we can do that using the context menu, as in the following; The option “Show all members” will revert it, but in some cases, it is better to use the Class Details to revert it, because we can have other items hidden that we want to keep hidden. Each shape hides some item that will show the icon that it means, here is an example. Apply associations Returning to the Field Engineer Sample and choosing the class JobHistory, Job and Customer we will find that each one has a relationship with each other, let's highlight it using a red and orange rectangle, as in the following: Let's see how to show the association for properties and for collections. Show as Association

For properties that the data type is another class we can select the property in the shape and in the context menu we should select the option “Show as Association” as in the following: Show as a Collection Association For properties that are collections/lists we can choose the option “Show as Collection Association” as in the following: And the result will be something like: The number of arrows will define it as a property or a collection, but using a good name can be enough to see the differences. Show as Property

By selecting in the arrow it is possible to revert it, using the option “Show as property”. The final class diagram After defining all the arrows for all the associations and organizing the shapes we will have something as in the following: For this diagram, we can understand that the model has five classes and the MobileServiceContext is defined by these classes. The relationship among the classes is clear (for example).

A similar determination can be done for Equipment and Equipment Specifications. Note: it is possible to create arrows for the MobileServiceContext's properties but that will only make some noise and it is not important in this case to see these associations. Each developer should customize the class diagram and there are no fixed rules for it. With this kind of diagram, it is very simple to understand the model and in some cases find mistakes like wrong names, wrong relationships, or even missed features.

In conclusion, we can conclude that a class diagram is very useful for understanding the code made by us or by others, the relationship between the classes, and an easy way to find mistakes. In some cases, with a class diagram, it is possible to have a big picture of the application without seeing one line of code.