active.requirementlogo

active.requirements

Patterns

A pattern is a way of capturing best practice and recording it in a standardised manner so that it can be reused by others who face a similar problem without having to begin from first principles. The notion of patterns, in both structures and relationships between those structures, was first articulated by Christopher Alexander [1, 2] Alexander was an architect, and his work was in the domain of designing buildings and communities. Simply put, he defines a pattern as "a three-part rule, which expresses a relation between a certain context, a problem, and a solution."
Patterns are related to, but different from, idioms, principles, heuristics, or paradigms. An idiom is a language specific way of combining elementary building blocks that holds true for a particular programming language but is not valid more generally. A principle, on the other hand, is an invariant that holds true more globally and is not constrained by a particular language. An heuristic is an aid to decision making, although it makes no absolute claim as to the goodness of the action suggested. Heuristics could be used to choose among alternative patterns. A paradigm is a very abstract pattern [3]. In comparison, a pattern is a more concrete concept that provides detailed, but non-proscriptive instruction, regarding the solution to a standard, recurring problem that is presented in a formalised written structure [4]. They are therefore a mechanism for the communication of concepts designed to be reused. They provide effective 'shorthand' for communicating complex concepts effectively. Patterns are a solution to a problem in a context [5]. They help new developers ignore traps and pitfalls that normally can only be learned from costly experience. Patterns have a context in which they apply. There are advantages and disadvantages to the application of any particular pattern, thus they are subject to opposing forces that must be balanced. All solutions have costs and these costs are explicitly stated. There is nothing new about the concept behind patterns, as by definition they capture experience. The pattern movement is a systematic attempt to document common abstractions in the domain of software engineering [6].

To read more download the appropriate section from the literature survey from the download page.

[1.] Alexander, C., Ishikawa, S., M., S., Jacobson, M., Fiksdahl-King, I., and Angel, S., A Pattern Language - Towns, Buildings, Construction. (1976), New York, N.Y., Oxford University Press (OUP)
[2.] Alexander, C., The Timeless Way of Building. (1979), New York, NY, Oxford University Press (OUP)
[3.] Viljamaa, P., The Patterns Business: Impressions from PLoP 94. ACM Software Engineering Notes, (1995). 20(1) Amercian Computing Machinery (ACM)
[4.] Coplien, J., Software Patterns. (1996), N.Y., N.Y., SIGS Books & Multimedia
[5.] Beck, K., Crocker, R., Meszaros, G., Coplien, J., Dominick, L., and Paulisch, F., Industrial Experience with Design Patterns. Proceedings of ICSE-18, (1996)
[6.] Schmidt, D., Johnson, R., and Fayad, M., Software Patterns. Communications of the ACM, (1996). 39(10) Amercian Computing Machinery (ACM) http://www.cs.wustl.edu/~schmidt/CACM-editorial.html

Selected Bibliography

[1.] Alexander, C., et al., A Pattern Language - Towns, Buildings, Construction. 1977: Oxford University Press

[2.] Gamma, E., et al., Design Patterns - Elements of reusable object-oriented software. 1995, Upper Saddle River, N.J.: Addison Wesley Longman

[3.] Lord, J., Facilitating the application development process using the IBM Patterns for e-business, 2001, IBM

[4.] IBM, IBM Patterns for e-business 2002

[5.] Fowler, M., Analysis Patterns - Reusable Object Models. 1997, Menlo Park, CA: Addison Wesley Longman, Inc

[6.] Adolph, S., et al., Patterns for Effective Use Cases. 2002: Addison Wesley

[7.] Robertson, S., Requirements Patterns via Events/Use Cases, 2002l

Selected Links

Website handcrafted by the Accent Design Group