UML & Class diagrams for li'l folks

We have a peer level discussion within our team on various tech. topics. Here is my session transcript on Class diagrams.

What is UML?

This is the obvious and terrifying question every newbie has when hearing this acronym. Well, UML is a simple modelling language. As with a language there are syntaxes, grammer, notation & rules. There are 3 kinds of notations. Functional, Dynamic, Structural. Class diagrams fall under the structural notation. Each naotation has its own target audience. For example, a business analyst is interested in how a system needs to be behave for a user. So a use case diagram is sufficient for him/her to convey the ideas. An application designer will be interested in depicting how the internal components are designed. So, a class, object diagram conveys it and if there are messages flowing across the system, a sequence diagram will be fine. Finally when it comes to deploying the application in a client place, a package deployment diagram comes in handy.

Assume if all the stakeholders in the above scneraio are well versed with UML. It does solve the confusion arising out of incorrect assumptions or design.

What is a UML Class Diagram?
Class diagrams are the backbone of almost every object-oriented method including UML. They describe the static structure of a system. That is, how entities involved in the system are associated to each other are described in this diagram.

When is a class diagram used?

Primarily class diagrams are used during the design phase of a project. It is used to describe the various classes that form part of the requirements and how they are associated with each other.

Basic Class Diagram Symbols and Notations

Classes represent an abstraction of entities with common characteristics. Associations represent the relationships between classes.


Illustrate classes with rectangles divided into compartments. Place the name of the class in the first partition (centered, bolded, and capitalized), list the attributes in the second partition, and write operations into the third.

Active Class

Active Class
Active classes initiate and control the flow of activity, while passive classes store data and serve other classes. Illustrate active classes with a thicker border.



Interfaces are those classes that extract the common functionality and expose them as derivable functions. Interfaces are denoted like <> in the uppermost compartment of the class diagram.

Visibility of attributes or operations restrict the consumer classes from accessing them. Examples of visibility includes private (-), public (+), protected (#). Use visibility markers to signify who can access the information contained within a class. Private visibility hides information from anything outside the class partition. Public visibility allows all other classes to view the marked information. Protected visibility allows child classes to access information they inherited from a parent class. For static attributes, underline the attribute name.


Associations represent static relationships between classes. Place association names above, on, or below the association line. Use a filled arrow to indicate the direction of the relationship. Place roles near the end of an association. Roles represent the way the two classes see each other.
Note: It's uncommon to name both the association and the class roles.

Directional navigation

Utilize a navigation arrow on the association line when one class can
communicate one way with another. Show directional navigation with an arrowhead at one
end of the association, indicating the direction of allowable communication. For bidirectional association no arrow heads are necessary(just makes it clumsy)

Multiplicity (Cardinality)
Multpilicity indicates the number of times one class is related to another. For example, one company will have one or more employees, but each employee works for one company only. Place multiplicity notations near the ends of an association. These symbols indicate the number of instances of one class linked to one instance of the other class. Normally * indicates no definite upper limit. Example, number of issues solved by a developer in a day. This can vary from 0..*. In case if the organization has stipulated levels like a developer needs to solve at least 2 issues per day, the multiplicity will 2..*

In case there are conditions to be looked in to when designing, use constraints. Place constraints inside curly braces {}. For example, if there is a condition like needs to solve issues only if the severity of the issue is 0 (0 indicates top priority), we depict it like {severity =0} above the association line.

Composition and Aggregation
Composition is a special type of aggregation that denotes a strong ownership between Class A, the whole, and Class B, its part. We can illustrate composition with a filled diamond. Use a hollow diamond to represent a simple aggregation relationship, in which the "whole" class plays a more important role than the "part" class, but the two classes are not dependent on each other. The diamond end in both a composition and aggregation relationship points toward the "whole" class or the aggregate.

Example: A product consists of many features. So remove all the features you actually kill the product. This is for composition. Many developers might work on a product. Assume all the features are complete and the product is in stable mode, the developers can be moved to another product. This is aggregation. (this situation is hypothetical and is used for simplicity in illustration only).

This is used to depict the important OO concept of inheritance. It is another name for inheritance or an "is a" relationship. It refers to a relationship between two classes where one class is a specialized version of another. For example, an employee within a software organization can be a manager, developer, quality analyst and so on. But all of these instances share common attributes like designation, ID etc.

It is depicted with an arrow drawn from the child class to base class, the arrow head pointing to the base class.

In real life coding examples, the difference between inheritance and aggregation can be confusing. If you have an aggregation relationship, the aggregate (the whole) can access only the PUBLIC functions of the part class. On the other hand, inheritance allows the inheriting class to access both the PUBLIC and PROTECTED functions of the superclass.


My Other blog

Search This Blog


Welcome reader, you are reading my blog that showcases positive news to cheer up.
In my other life, I love software architecture and design, I also focus on project management skills. My other blog, concentrates on technical and project management related articles and notes.