Important UML Diagrams Required to Work with Object Oriented Design Patterns

There is a saying that a picture can speak thousand words. UML diagrams are those pictures which can speak all those words about your design.

There are many categories of UML diagrams. This note will contain those class diagram components that are really required for representing your design decisions, design patterns and principles.

UML Diagrams may be classified as static and dynamic. Static diagrams include class diagram, object diagram, use case diagram. Implementation model diagrams, which are a subset of static diagrams include component diagram, deployment diagram, package diagram. Dynamic diagrams include sequence diagram, communication diagram, state diagram and activity diagram. Agile development practice recommends developing models in parallel working on static and dynamic models at the same time.

Knowledge of UML is required for both waterfall and agile approaches. While we do diagrams in a common doc and get approval in waterfall, we may simply draw them in whiteboards in Agile during project discussions. People may even take a picture of it in mobile and send it across or leave the boards with the drawings until the design process is over. Drawing diagrams is the best way to learn a design pattern. To be a good designer, you need to keep drawing as much as possible.

Common Class Diagram notations for working with design patterns

Class Diagram

Visibility / Access modifiers (public, private, protected and default) are denoted using below symbols

Class Diagram Example with attributes, methods, their naming convention etc.

Abstract classes are denoted using italic names or specific stereotypes

More stereotype examples

We can denote Realization (or interface implementation) as:

Interfaces have additional notations than using stereotypes

While the first one on left say that CA implements IA or CA provides IA, the second one on right say that CA consumes IA or CA has reference to interface IA.

Generalization (or extends) is shown as below.

Association and dependencies can be shown as below.

This say that CB contains a direct reference to CA.

This says that CB contains a dependency to CA and CA may be injected.

Multiplicity may be shown as below.

Employee can be part of 1,2 or 3 department.

Note that no array may be shown in bidirectional relationship.

Inner classes are shown as below.

Procedures for operations can be shown as below.

It is a good practice to shown the usage as well. For example, how would you use your design from say a main method.

Special thanks for Sneha for drawing the diagrams for this note.