More

    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.

    Recent Articles

    OAUTH – FREQUENTLY ASKED QUESTIONS FOR INTERVIEWS AND SELF EVALUATION

    Why is refresh token needed when you have access token? Access tokens are usually short-lived and refresh tokens are...

    SUMO LOGIC VIDEOS AND TUTORIALS

    Sumo Logic Basics - Part 1 of 2 (link is external) (Sep 29, 2016)Sumo Logic Basics - Part 2 of 2...

    GIT – USEFUL COMMANDS

    Discard all local changes, but save them for possible re-use later:  git stash Discarding local changes...

    DISTRIBUTED COMPUTING – RECORDED LECTURES (BITS)

    Module 1 - INTRODUCTION Recorded Lecture - 1.1 Introduction Part I – Definition

    BOOK REVIEW GUIDELINES FOR COOKBOOKS

    Whenever you add reviews for the book, please follow below rules. Write issues in an excel.Create an excel...

    Related Stories

    Leave A Reply

    Please enter your comment!
    Please enter your name here

    Stay on op - Ge the daily news in your inbox