Sunday 18 February 2007

Software Patterns

What software engineering?

Software engineering is the application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software; that is, the application of engineering to software.[1]

Software engineering applies both computer science and engineering principles and practices to the creation, operation, and maintenance of software systems. It therefore covers technical and management issues (directing programming teams, scheduling, and budgeting) as of developing software systems.


What is a software pattern?

Software pattern represent a general repeatable solution to a commonly occurring problem in software design. The kind of problem is an engineering problem. Put simply a Software Pattern = (Software engineering Problem + Solution) in a context. Software patterns are not finished designs that can be transformed directly into code. Rather, they are a template for how to solve a problem that can be used in many different situations.


Frequently Asked Question about Software Patterns

1. Is a software pattern different from a pattern?

Yes. Software patterns deal solely with software problems while patterns a solution which can be applied to a reoccurring problem in a specific context. Software patterns apply only in the software designs. On the whole, software patterns are a subclass of patterns.


2. What is the difference between software patterns and

a class?

A software pattern is not an implementation. It simply describes when, why and how to go about creating an implementation or other engineering products. A class is a blueprint from which individual objects are created. Classes are implemented.

List of types of software pattern?

The following are some of the types of software patterns

  • Design patterns
  • Analysis pattern
  • Organisation patterns
  • Process patterns
  • Domain-specific patterns

3. Do we need software patterns?

Yes, we need. Software patterns help in the following ways.

1. Solve “real life” problems
2. Capture domain expertise
3. Document design decisions and rationale
4. Reuse wisdom and experience of master practitioners
5. Convey expert insight to novices
6. Form a shared vocabulary for problem-solving discussion[2]



[1] http://www.cs.queensu.ca/FAQs/SE/questions.html
[2] http://www.cmcrossroads.com/bradapp/docs/patternsnutshell.html#Pattern_Kinds

http://en.wikipedia.org/wiki/Design_pattern_(computer_science)