Design Patterns for Agile world

Design patterns with Design principle for Agile world

What are Design patterns?
Design patterns are solutions to real world problems that pop up time and again, so instead of reinventing the wheel, we follow the design patterns that are well-proven, tested by others, follow as safe guidelines.

What are Software Design principles?
Software design principles represent a set of guidelines that helps us to avoid having a bad design. The design principles are associated to Robert Martin who gathered them in "Agile Software Development: Principles, Patterns, and Practices". According to Robert Martin there are 3 important characteristics of a bad design that should be avoided:

Rigidity - It is hard to change because every change affects too many other parts of the system.
Fragility - When you make a change, unexpected parts of the system break.
Immobility - It is hard to reuse in another application because it cannot be disentangled from the current application.

Design principles are important when going with Agile development where requirements keep changing, dependency on different modules, lack of technical expertise, etc.

This happens in our day to day life and all of us might have faced above mentioned problems. 

How to handle these problems

We have to stick to Design principles in all the phases of SDLC (software development life cycle), we have to follow the software principles but need to take a special consideration during analysis, design and coding phases. When requirement changes, we need to deliberately analyze the code and make sure basic software principle shouldn't be violated.

Design principles followed by many :
The Single Responsibilities Principle (SRP)
Open and Close Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principles (ISP)
Dependency Inversion Principle (DIP)
[Above 5 principle are SOLID]
DRY (Don't repeat yourself)
YAGNI (You aren't gonna need it)

Note: If you see any corrections or have suggestions please do let me know.

UML Part I

UML Intro

UML stands for Unified Modeling Language. UML is a graphical language for visualizing, specifying, constructing & documenting the artifacts of a software system. It is a standard language for designing and documenting a system in an object oriented manner. UML provides blue print for Business process, System functioning, programming language statements, Database schema & reusable components.

UML is used in all phases of software development from Requirement Specification to Acceptance Test and from Designing a solution to Deploying/ Packaging. Modeling has been around for years not only in software field but also in other fields like Civil, Mechanical, etc. we get a model ready & approved before starting the production. Modeling makes complex system to break up into simple and discrete pieces that be individually understood. If we ask ourselves have we been doing/ following modeling, most of us would say NO. But all of us do modeling, the flowchart that we draw is a model for your module isn't it.

Now we should see what are the advantages of modeling:

1. Readability: Representing the whole architecture in flowcharts, class diagrams, state diagrams, ER diagrams, etc. makes our project more readable. Especially when we have programmer's changing job, handover becomes easier.
2. Re-usability: Once the system is readable and broken down to pieces, it becomes easier to identify redundant and similar modules. Thus increasing re-usability. We can decide of reusable components to be used across the application.Why shall we adopt UML?

Well different languages have different ways of coding and syntax's. In order to bring all languages under one roof UML comes into picture. As the term comes in UNIFIED, it unifies all different languages in one roof so people who are working on some other platforms can understand that.

There was an interesting question put up “Does UML fit in Agile/Scrum environment?” during a UML session presented by myself & one of my colleague at our office CastleRock, Kolkata.
Well the answer is yes, UML is not a methodology dependent you can apply it to any of the software development process. If we have a blueprint of the whole architecture, whenever we are required to make changes or alter a section/ module we can very easily trace which all sections/ modules would get effected & at the same time you can figure out how much time it might take to finish the job.

You can checkout the list of UML tools at http://www.sereferences.com/uml-tools.php.

In the next post I will cover different UML diagrams.