OO diagrams - the class diagram
The class diagram in OO is one of the fundamental diagrams used for designing programs. This diagram allows you to build up a conceptual model (an abstraction) of a system you intend to program. It shows you the different classes that will need to be programmed and how the classes relate to each other. This diagram is important. Once you have completed it, a team of engineers and programmers will have something around which they can discuss, to ensure they have covered everything. It gives everyone a focal point; everyone is singing from the same song sheet (working towards completing the same class diagram design) rather than their own idea of what needs to be done. It allows a Project Manager to check that all work is being done, to track the progress of a system as each part is completed and to have a clear, overall picture of the software that is being built.
The class in OO programming is the blueprint, the template, from which you can stamp out or create actual instances of a class in your program. For example, you might have a class that defines the what a person is. That is your template for a person and defines what information you will keep about a person but it's not an actual instance of someone. However, you use this class to create an instance called Jack Jones, and you use it again to create another instance called Mary Smith, and so on.
Each class is represented by a three-part box. The top part show the class name. The middle part shows what attributes the class holds and what data type each of those attributes are. The bottom part shows what methods you can carry out. In the bottom part, you will typically have at least one constructor method. This is used to create real, actual instances of the class. You then typically have what are known as 'set' and 'get' methods. These are used to give actual data to an attribute and to retrieve the data from an attribute. You may then also have other methods, for example, ones that carry out some calculations.
When you design a system, you would draw one of these three-part boxes for each class in your system. Because one class can inherit all of the attributes and all of the methods of another class, we would also add arrows, to show which classes are inheriting properties (the subclasses) from other classes (the superclasses).
Here is an example, based in a school, college or university setting. We might be designing a new program to track student progress, for example.
We have a class for a person, which has attributes and methods associated with every person in the system, such as their name, their gender and their date of birth.
We then have a class called Student. This class inherits all of the attributes and methods from the Person class so we don't need to add them to the class. We can just show an arrow pointing to the class that it is inheriting properties from. We can say that Student is a subclass of the superclass Person. What we do have in the class for Student are the extra attributes and methods that only students have, like what course they are on, for example. We also need to include a constructor class, so we can make actual, real instances of a student when we need to.
We also have a class called Teacher. Again, this is inheriting properties from Person, so we don't need to add those to the Teacher class. We can just show where it will inherit those properties from, with an arrow. We can say that Teacher is also a subclass of the superclass Person. What we do have in the class for Teacher are the extra attributes and methods that only teachers have, like what course they teach, for example. We also need to include a constructor class, so we can make actual, real instances of a teacher when we need to.
What we now have made is a 'class diagram', a set of classes and the relationships between them. It is a conceptual model of a system that might exist in a school or university, for example. The class diagram shows the classes in the system, the names, attributes and methods needed and who the classes relate to each other. We might go further and add a class for 'Course', another for 'Special student', another for 'Classroom' and so on, until our system is complete.
The point about this diagram, however, is that it gives everyone involved in a project the opportunity to see what the plan is and to comment on it, to point out improvements or possible errors. The Project Manager will also be able to use this diagram as one method of making sure that all the jobs that need to be done to actually program the system are actually carried out. Diagrams that summarise information in this way are always useful points of reference.