Tuesday, 6 March 2007

Pattern in Software Industry (Week 3)

The second task of our lecture in week 3 was to identify a design pattern example other than the ones listed in handouts, I came across following example of design pattern;J2EE Design Patterns.


J2EE-specific design patterns identify the minimal set of known problems that application architecture should solve. These patterns are based on experiences of the J2EE community and use J2EE technologies to solve problems. The advantages of applying a design pattern are: proven solutions to the problems, reusability, improved performance, increased maintainability, and so on. [11]

It has a total of 13 patterns. J2EE Design Pattern Catalogue [2]

Business Delegate – Reduce coupling between web and enterprise JavaBeans tiers

Composite Entity – Model a network of related business entities

Composite View – Separately manage layout and content of multiple composed views

Data Access Object – Abstract and encapsulate data access mechanisms

Fast Lane Reader – Improve read performance of tabular data

Front Controller – Centralize application request processing

Intercepting FilterPre- and post-process application requests

Model View Controller – Decouple data representation, application behavior, and presentation

Service Locator – Simplify client access to enterprise business services

Session Façade – Coordinate operations between multiple business objects in a workflow

Transfer Object – Transfer business data between tiersValue List Handler – Efficiently iterate a virtual list

Value List handler - Efficiently Iterates a virtual List

View Helper – Simplify access to model state and data access logic


References

[1] J2EE Design Pattern Examples
Available
from URL
http://www.oracle.com/technology/sample_code/tech/java/j2ee/designpattern/index.html

[2] J2EE Design Pattern – Design Pattern Catalogue
Available
from URL
http://java.sun.com/blueprints/patterns/catalog.html

Criticism of GoF Pattern Preserving Technique (Week - 3)

Today’s lecture was about the introduction to Design patterns. The lecturer discussed different topics under the umbrella of Design patterns like;

  • Introduction to Design Patterns
  • Uses of Design Patterns
  • Types of Design Patterns
  • GoF Pattern preserving technique

As per the task given in the class, the students were required to identify one pattern from GoF Design Patterns and critically analyze their preserving technique.

The author went through the first pattern that is Abstract factory, understood the concept of each element in preserving technique, the elements and criticism of their preserving technique is as follows;


1) Pattern Name and Classification

Description
The pattern’s name conveys the essence of the pattern succinctly. A good name is vital, because it will become part of your design vocabulary. Every pattern should have a descriptive and unique name that helps in identifying and referring to it. Additionally a pattern should be classified according to a classification. This classification helps in identifying the use of the pattern. [1]

Criticism
I totally agree with the descriptive nature of pattern name, because a patterns name should be such that highlights the pattern essence and it should also be unique so that two patterns are not mixed. Pattern should be added in its relevant classification such that it highlights the uses of that pattern.


2) Intent

Description
Intent is a short statement that answers the following questions: what does the design pattern do? What is its rationale and intent? What particular design issue or problem it address? This describes the goal behind the pattern and the reason of using it. It resembles the problem part of the pattern. [1]

Criticism
Indeed Intent should be included while preserving a design pattern, before we actually go to the detail of the pattern a small description of the pattern is very useful and handy as it explains the purpose of developing the pattern.


3) Also Known as

Description
A pattern could have more than one name; these names are documented in this section. [1]

Criticism
I do not think that this part is vital for every single pattern and it can be avoided in certain situations. Not every pattern has other names, however if any pattern has some other names, they can be included in “Pattern Name and Classification”


4) Motivation

Description
This section provides a scenario consisting of a problem and a context in which this pattern can be used. By doing so this section shows when this pattern can be used. [1]

Criticism
It is important to include motivation section in catalogue because it proves with example that when and where this pattern can be used, which is handy for end user.


5) Applicability

Description
This section includes situations in which this pattern is usable; it represents the context part of the pattern. [1]

Criticism
The context part makes sense to use because it describes the context of the pattern, however the usage part can be avoided because we have already described of the use of this pattern in “Name and its Classification” and “Motivation” stages of catalogue.


6) Structure

Description
This section presents a graphical picture of the pattern using class diagrams and interaction diagrams. [1]

Criticism
“A picture portrays a thousand words”, following this statement it is very important to include this section as the picture would give the overview of the pattern.


7) Participants

Description
A listing of the classes and objects used in the pattern and their roles in the design. [1]

Criticism
Developers from different backgrounds would find this section beneficial as it conveys the purpose of classes and objects in simple terms so that they can be applied in different languages easily.


8) Collaboration

Description
Describes how classes and objects interact with each other. [1]

Criticism
Again this part would prove to be beneficial for developers who use different languages, technologies and tools; it should be included in catalogue.


9) Consequences

Description
This section describes the result, side effects and trade offs caused by using this pattern. [1]

Criticism
Everything has advantages and disadvantages associated with it, this part would describe the key advantages and disadvantages allied with this pattern, and it should be included.


10) Implementation

Description
This section describes the implementation of the pattern and represents the solution part of the pattern. It provides the techniques used in implementing this patterns and suggests ways for this implementation. [1]

Criticism
Techniques and ways to implement the system would be handy for developer, these techniques and ways can be used by novice developers.


11) Sample Code

Description
An illustration of how this pattern can be used in a programming language. [1]

Criticism
This part would only be handy for developers who work in the same environment as used in this section. For example a pattern whose sample code is given in C++ would be valuable for C++ programmers only.


12) Known Uses

Description
This section includes real usage of this pattern. [1]

Criticism
Details of real world examples regarding a particular pattern would be handy because it highlights where this pattern has been used before and in what situations.


13) Related Patterns

Description
This section includes other patterns that have some relation with this pattern, so that they can be used along with this pattern or instead of this pattern. It also includes the similarities and differences with these patterns. [1]

Criticism
This section should be included as it describes other patterns that use similar concepts and relations between these patterns.

Reference

[1] Lecture Handouts given By Lecturer
Week (3) - Introduction to Design patterns
Slide Number 15 to 18

Introduction to Software Pattern and FAQ about Software Patterns (Week - 2)

In today’s lecture Dr. Sri gave us an overview of software pattern, and at the end he gave us a task to develop a pattern FAQ.

Software Pattern

Developing patterns for software is emerging topic of discussion from the object oriented community. Software patterns are answers to reoccurring problems in software development. The purpose of developing such patterns is;

  1. To provide a common solution that can be applied in different languages and making code easily understandable
  2. To support reuse
  3. To decrease the development time by using tested, proven development solutions
  4. Increasing the reliability, efficiency and reuse of a design
  5. Each solution to a problem is made over a period of time and it goes through many refinements, thus it increases the quality of the solution

Pattern FAQ’s

Q – 1: What is a software pattern?

Software Patterns are solutions to problems that occur over and over again in software development, basically software pattern is “if you come across this problem in software development, solve it like this”.

Software Pattern = (Problem + Solution) in a context

Q – 2: Are patterns localized to one area in software development or they address other problems occurred in software development?

No, patterns are not localized just to one phase or area of software development; they can be applied in other phases of software development life cycle like [1];

Programming – reuse of some classes in C++ and Java
Algorithms – in parallel processing
Protocols – in concurrent object systems
Analysis Model – in dealing with accounting rules
Development Process – in steps and strategies in object oriented design

Q – 3: Can one problem has more than one pattern to solve it?

Yes, one problem can have more than one pattern. People working in different environment might come up with different solutions to same problem, both solutions might be correct , but since there is no standard or a governing body in this field so a particular solution can not be generalized.


Q – 4: How can a pattern reduce development time and increase quality at the same time?

Solutions to reoccurring problems are not found over night; these solutions are proposed and are thoroughly tested and verified, so they are of high quality. Since the solutions are already present, problems can be solved immediately.


Q – 5: If I develop my own pattern, how can I write it or preserve it?

There are different pattern preserving techniques, commonly followed are Alexander Christopher’s pattern preserving technique and GoF pattern preserving technique. These techniques can be used to write a pattern or as a developer of the pattern one can develop his/her own technique to write pattern.

Reference

[1] Patterns-Discussion FAQ

Available from URl

http://g.oswego.edu/dl/pd-FAQ/pd-FAQ.html

Introduction to Patterns (Week - 1)

Today was the first lecture of Patterns for Software Design, before going into actual detail Dr. Sri gave us a summary of what patterns are and how they help us in real life.
During lecture, we discussed how the idea of patterns was put forward by Christopher Alexander.

After today’s lecture about patterns, my understanding says that patterns are answers to a problem in a context provided the problem is reoccurring. A same problem can crop up numerous times over a period of time, so instead of designing a solution every time, existing solutions can be utilized.

The aim of developing patterns is to;

Reduce the problem solving technique – if a problem is encountered and we have the solution already designed, then it saves time for the developer
Provide reusable solutions – solutions are reusable and can be used for same kind of problem
Solve specific problems – solutions are to one specific problem i.e. same context
Act as template – reusable solution act as a template


Patterns can be found in our daily lives as well, we follow different patterns but we do not realize them until we study about patterns, like we all have work patterns, traveling patterns, building patters, eating patterns etc

One such example of a real life pattern would be;

Context
Mr. Thompson is going on holidays with his family, cruising along M25, suddenly Mr. Thompson hear a strange sound coming from one of the rear tires of the car. He stops the car and sees a flat tire. Checking the boot of the car, he finds out that he doesn’t have the Jack to change the tire. Now Mr. Thompson can not leave his family in the middle of the road and he is not even registered with RAC so that he can call them for help.

Problem
How to replace flat tire?

Solution
In this situation Mr. Thompson should wait for any car passing by for helping him out or wait for police. Waiting for another passer or police wouldn’t take long as M25 is a busy motorway. To avoid any future accident, he should check car boot for all necessary equipment especially before going on a long journey and should get himself registered with RAC.