Formally Depicting Classes, Relationships, Objects, and Links

Classes and Objects are depicted as 3 drawer rectangles. (Only the first drawer is required.) In the top drawer appears the name of the class, and if the class is inherited from other base classes, the name of the class is appended to the other classes separated by colons. The figure on the left shows a well-defined class.

The second ‘drawer’ contains the attributes of the class. These attributes may or may not be hidden from the clients of that class. If hidden, they may be obtained using methods that set and get those attributes and protect them from unintended or forbidden manipulation. In the class diagram, the type of the attribute variables is defined, as well as their initialization value.

The third drawer contains the methods of the class, that might be public (accessible from other classes) or private (restricted to use by objects of this class alone). Or they may be protected or friend functions, which are accessible to only certain other units of the program. The method-method- functions are also defined by type of return value, and list of arguments. The format for declaring methods is methodname(list of arguments, other arguments,…):returnvaluetype. The symbols alongside the attributes and methods of a class signify their visibility. Private items are marked with a minus sign (-), Public items are marked with a plus sign(+), and protected items are marked with a number sign (#). These designations are marked in Visio only on the class diagramand not on the object.


There are some minor differences between the notation, depending on whose standard one is using. For instance, some standards call for the class definition beginning with a colonwhile others do not. However, all definitions support the depiction of an object (on the right) as being followed by the its class name, or at least by a colon. So ‘Chris:’ would always be an object, while ‘:Manager’ would always be a class. Some ambiguities still exist. For instance, ‘:Employee:Executive:Manager’ could be either a Manager class who has inherited properties from Executive and Employee classes, or an Executive named ‘Manager’.

There are also some differences in the presentation style. For instance, methods frequently require many parameters in order to do their job properly. Though these parameters need to be included in the documentation and code that is written, their presentation on a structural modeling chart might be distracting. So Vision gives options about which features will be displayed in each kind of chart. This allows the developer to include data, which is of interest to the development team but is too fine-grained to easily present to the users.

In the Microsoft standard, much of this ‘grammar’ is managed for you, allowing the developer to concentrate on the abstraction of the system, rather than the formalities of documentation. Although Microsoft is not generally thought of as one of the prime movers of UML, it has some late entry products that are worthy of mention. Several years ago, Microsoft bought a product called Visio, a version of which now comes with the Microsoft Office package. Visio is an object-oriented program which handles shapes, much like Word handles documents, and Excel handles numbers modeling.

At any rate Microsoft in their latest .NET Enterprise package has bundled a Visio UML developer package with the platform. This allows the developer to create the project ‘scaffolding’ in a language that is easy for the users to converse in and allow changes while the system is under development. The .NET platform can then take those Visio diagrams and create the outline of the required classes with their attributes and functions. This self-documenting feature is a boon to the developers and users alike. This is an innovative tour de force of the magnitude of PowerPoint. It will increase the efficiency of IT projects, and decrease costs and time on projects dramatically over the next 10 years. Relationships between classes are shown by connecting lines. The nature of these relationships is further defined by labeling and arrows, among other things.


The above left class diagram shows the classes Manager, DevelopmentTeam, and Project, together with the association between them. The Manager class obtains project requirements from the Project Class. The Manager class then sets the goals and defines the tasks for the developmeFebruary 11, 2008ows the relationship between 3 classes, going from most general to specific. The hollow arrow points to the more general class.



UML Tutorial on Class Diagrams

This resource provides insightful information on UML Class diagrams.

Article on UMLDiagrams

This is an informative article on UML diagrams.