A class model, taken alone, is a description of the static structure of a system; this means that it shows the system in a way that is independent of time. In the library system discussed earlier, the individual books may come and go, and individual members for that matter, but the classes “Book” and “Member” persist. To say that a lending libraries has books and members is true, independent of time.

Of course, in reality the system will change over time. This change is reflected in the values of the attributes of objects, and the numbers of instances of each class. The library may begin with 1000 books, and ten years later it may have 10 000 books; but there will never be a time when the class “Book” is not a valid one for the library. Similarly, the addresses and even the names of the members will change. This will be reflected in the values of the attributes of the instances of class “Member”.

The sum total of information carried by the attributes of an object is called its state. If we know the state of an object, then we know everything there is to know about it. This last statement is true by definition. If in describing an object the designer finds that its attributes are not sufficient to specify its state completely, then they have overlooked some attributes.

If the state of an object is given by the values of all its attributes, then the state of the system if given by the states of all its objects. In other words, the values of all the attributes of all the objects completely specify the state of the system at any given time.

If state is so important, why can it not be represented on a class model? The reason is that there are far better ways to represent changes in state. The UML provides state transition modelling for this purpose. In a full design it may be necessary to provide state transition diagrams for some or all classes, to describe their state changes in detail. The pattern of state change over time is called the dynamic behaviour of a system, and modelling this is called dynamic modelling. As well as state transition modelling, the UML provides object interaction diagrams, activity diagrams, sequence diagrams and communication diagrams for dynamic modelling. One can, of course, describe the dynamic behaviour of classes in plain language as well, and one probably should.

Only objects have state; classes do not have a state. This is because a class specifies properties that are true of all objects of that class. However, a class can have a default state. This is the set of attribute values that an object of that class will have by default, that is, if not provided with any other information.