Thursday, July 28, 2016

How effective are your Design patterns

Overview

Object-Oriented (OO) design patterns represent well known solutions to common design problems in a given context. The common belief is that applying design patterns results in a better OO design, therefore they improve software quality as well.
However, there have been very less empirical studies to prove this. How does application of Design patterns affect maintainability, reusability, and understandability. How to evaluate impact of design patterns on software design.
In context of design pattern effectiveness, following questions are of importance:
  1. Are there any traceable/measurable effects of applying design patterns
  2. Do patterns form an effective way of exchanging design knowledge
  3. Does applying the design pattern magic always produce the intended result
In this discussion we will try to answer the measurable effects of (GoF) design patterns using Hegedűs experiment. GoF design patterns are 23 patterns which are classified according to the purpose and according to the scope. This experiment was conducted by P. Hegedűs, B. Dénes, F. Rudolf and G. Tibor [1] and is one of the few studies that uses empirical values to analyze the design pattern effectiveness.

 

Measure effectiveness

To answer above questions the simple relationship that is used is:
         design pattern density : maintainability of software
A direct co-relation between these values would mean that design pattern do help in maintainability of software. There are other relationships also which have been used like defect frequency of pattern classes vs defect frequency of non-pattern classes but there have been more empirical studies around maintainability, and also because of its direct impact on development costs.

Before we start working on this relationship, lets understand what maintainability is, in IEEE standard glossary:
      Maintainability The ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment.

The problem in using this definition to measure maintainability as effort, the common unit of effort being man-hours, is that this unit in itself is very ambiguous. Hence, to measure maintainability in absolute terms, probabilistic quality model[3] is used. This model uses the quality characteristics defined by the ISO/IEC 9126 standard. The computation of the high level quality characteristics is based on a directed acyclic graph whose nodes correspond to quality properties that can either be internal (low-level) or external (high-level). Internal quality properties characterize the software product from an internal (developer) view and are usually estimated by using source code metrics. External quality properties characterize the software product from an external (end user) view and are usually aggregated somehow by using internal and other external quality properties. The edges of the graph represent dependencies between an internal and an external or two external properties. The aim is to evaluate all the external quality properties by performing an aggregation along the edges of the graph, called Attribute Dependency Graph (ADG).
For analyzing the relationship between design patterns and maintainability the following measures for every revision of given software system are used:
  1. Mr - an absolute measure of maintainability for the revision r of the system.
  2. TLLOC - the total number of logical lines of code in the system.
  3. TNCL - the total number of classes in the system.
  4. PInr - the number of pattern instances in revision r of the system.
  5. PClr - the number of classes playing a role in any pattern instances in revision r of the system.
  6. PLnrr - the total number of logical lines of classes playing a role in any pattern instances in revision r of the system.
  7. PDensr - the pattern line density of the system defined by the following formula: PLnr /T LLOC
The results and co-relationships between these measures for the sample system[2] did indicate on patterns improving maintainability of the system.


It can be seen that the two curves have a similar shape meaning that they move very much together. The Pearson correlation analysis of the entire data set shows the same result, the pattern line density and maintainability has a 0.89 correlation. This result may indicate that there is a strong relation between the rate of design patterns in the source code and the maintainability

[1] Hegedus et al. evaluated the impact of design patterns on maintainability directly by conducting an empirical analysis. They analyzed more than 300 revisions of the JHotDraw software system which relies heavily on some design patterns. They calculated the maintainability values with their
[2] http://www.jhotdraw.org/

Tuesday, March 15, 2016

Promise

I look down, when I look down below the hill
the hill of success that I climbed...
All I can see is grim and chill!!

chill that is in return of my coldness
coldness towards the souls I killed
killed them for my selfish ends
killed them to reach atop "the” hill!!

grim that my family and friends are feeling
for I was not with them while their lives were reeling
grim that I’ve caused to my nears and dears
grim in the lives which I had to cheer...

oh!! but no time is it late to begin
to make amends, to keep up the chin
so I promise to the world and I promise myself
I shall not let history repeat itself!!!