DR. R. SRINIVASAN writes that problems arise when in a hurry to meet deadlines, software development teams stray away from the planned design structure analysis

THE identification of what to avoid is a critical factor in successful software development. AntiPatterns will lead us to identify mistakes committed in software development and will also be able to identify the so-called good solutions applied under the wrong context or situation. By elaborating the symptoms and consequences of implementing the bad solution or a good solution under a wrong context, AntiPatterns will offer a refactored solution for successful software development. What exactly is a refactored solution? It was in the conference on "Object World" in 1996, that Michael Akroyd of Motorola explained the concept of refactored solutions that give antipatterns a valuable purpose of providing a good solution to the identified problem and how to get out of trouble.

As mentioned in the last article, good architecture and structure are very important in software development to enable the system to be scalable or be enhanced in the future. This is where the problem arises because in a hurry to meet the deadlines, the software development team tends to stray away from the planned structure as determined by the architecture, analysis and design. To quote Brown, et al, "Software refactoring to improve the software structure in support of subsequent extension and long term maintenance." Identifying an AntiPatterns, followed by refactoring, will lead the situation from negative solutions to positive ones. However, while doing so, the goal should be to transform the code without affecting the correctness of the program that has already been implemented. Experts in this field advocate that refactoring prior to performance optimization because the latter might involve compromises to the program structure.

Conseq-uently, AntiPatterns and associated refactoring will effectively describe measures to be deployed at every stage of software development life-cycle like design, development execution and management. We will initially take up the AntiPatterns normally encountered at the design and development stage:

The Blob: It takes the name from the movie story where a jelly-like alien from outer space lands on earth and starts eating many earthlings to such an extent that it threatens to wipe out the entire planet. In a similar manner the Blob is identified in procedural-style software design where one object is tied up with numerous responsibilities where as others hold only data. This means that one class will be monopolizing the processing and the others will primarily encapsulate data.

"Blob occurs when an iterative method in the development of a prototype system is taken directly into a production system"

The AntiPattern under this context will be that the planned architecture has separated process from data, resulting in a procedural design even though the aim has been to have a system based on an object-oriented architecture.

It has also been identified by many that Blob occurs when an iterative method in the development of a prototype system is taken directly into a production system. Typical example of this is in the case of development using Visual Basic, which is based primarily on GUI concepts. Under this situation, normally partitioning of allocation of responsibilities is not taken care of, resulting in one module becoming dominant over others. Because of this predominant nature, the Blob will limit system enhancement and modifications without affecting the other modules. Similarly, modifications to other modules in turn will affect the Blob's software. Moreover, the Blob having the nature of procedural design, its software is too complex for reuse and testing, defeating the very basic concept of object-oriented design.

According to Brown et al, there are five main causes for the occurrence of Blob. These are:

a)	Lack of any architecture: The system components and their interactions are not will -defined, leading to the condition that the system will evolve in an ad hoc fashion, rather than in a structured manner.
b)	Lack of an object-oriented architecture: The system designers do not possess the basics on object-oriented concepts or the development team lacks the necessary abstraction skills.
c)	Lack of architecture enforcement: The software development process does not include review of the planned architecture.
d)	Too limited intervention: The software development team tends to add pieces of functionality to the existing working classes.
e)	Specified disaster: The Blob occurs in this case because of the reason that system architecture is spelt out as part of requirement analysis. This will lead to the case that it is not possible to change the architectural commitments made during SRS phase.

All these five points illustrate how important the architecture of the system is. The refactored solution for the Blob will be to move too much control away from Blob by reallocating behavior to some of the encapsulated data objects so that they are more capable and at the same time making the Blob less complex. We will discuss illustrations on other software development AntiPatterns in the next article.

(The author is Chief Technology Officer, Internet Component Management Group, Bangalore and can be contacted at: r.srinivasan@iCMGworld.com)