Patterns for Software Architectures

  Arvind S Krishna      

Information and Computer Science Department

University of California, Irvine CA


It is a common observation that engineering disciplines have handbooks that describe successful solutions. Patterns are an attempt to describe successful solutions to common software problems with the long-term goal of developing handbooks for software engineers. Patterns exist at different levels of abstraction starting at the architectural level and percolating down to implementation issues. Patterns thus have the potential of reducing the development life cycle of software by providing a standardized solution to recurring architectural, design and implementation issues.

The first section provides insights into Pattern Properties, Pattern Categories and systems for Pattern documentation. The main focus of the paper is to discuss patterns at the architectural level. In depth analysis of the Layers Pattern, the Broker Pattern and Model View Controller Pattern is given. Succinct overview of architectural styles and frameworks used in conjunction with patterns is provided. Finally musings on the future of pattern research is presented.


Keywords: software architectures, patterns, object orientation, architectural styles, frameworks, pattern systems, and pattern languages


1. Patterns:

Origin of Patterns can be traced to Christopher Alexander, an Architect who recorded design rationale in a structured format. In his book [ALE 79], he shows how patterns could be applied in urban planning. Ward Cunnigham and Kent Black, SmallTalk hackers, continued with this notion of Patterns and discussed in OOPLSA 87. Erich Gamma’s Ph.D. thesis and the seminal book Design Patterns by the Gang of Four [GHJV 95] ushered in widespread interest in Patterns. In its current state patterns is a hot topic in research, there is separate conference Pattern Languages of Programs (PLoP)TM .


1.1 What is a Pattern?

“A Pattern could be defined as a three part rule that expresses a relation between a certain context, a problem and a solution.” [Ale 79]. Context describes the situations in which the problem occurs. Problem helps in solving the concrete design issues that the pattern intends at solving and the Solution part elucidates how to solve the recurring design issue. It also describes runtime issues involved like collaboration, communication and organization of the components of the system. An Anti Pattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences. Anti Patterns are easier to figure out than patterns: It is often easier to recognize a defective situation than to implement a solution.


1.2 Properties of Patterns:


·        Patterns address recurring design problems and provide solutions for them. Patterns also serve as documentation of well proven design solutions. They are not invented or created artificially.

·        Patterns provide means of reuse. Designers while encountering similar situations need just to plug the pattern in place and need not have to “reinvent the wheel”.

·        Patterns are analogous to Best Practices applied in the organizational context. Instead of knowledge existing only in the minds of the experts, Patterns make them available generally.  Using Patterns thus produces high quality software.

·        Patterns provide a common vocabulary for understanding of design principles. Pattern names become a part of the design literature. The name of the pattern could be used for understanding the design of the system, its analysis and also its refinement.  They obviate the necessity to explain the solution to a problem in a lengthy manner.  E.g. Layered Pattern helps in understanding the system and also its constituent elements and their interactions without verbose explanations.

·        Patterns serve as a means of documenting software architectures. They help in capturing the vision of the architect and prevent the violation of this vision.  They also help in the construction of software with well-defined properties. They provide a template for the functional behavior and help in the implementation of the functionality of the application.

·        Patterns act as building blocks for the construction of more complex software systems. Combination of patterns results in Pattern Systems.

·        Patterns help in reducing development time of a software system and help managing the complexity of the software.


1.3 Pattern Categories

 Patterns cover various ranges and scales of abstractions. They are classified in my raid fashions. Erich Gamma [GHJV 93] categorize patterns into creational (process of object creation), behavioral (the way in which the classes and or objects collaborate and share responsibility) and structural (composition of the classes or objects) patterns. Frank Buschman et al in their book [BMRSS 95], classify patterns into finer grained criteria as adaptable systems, communication, distributed systems and organization of work. Patterns also range from Domain independent to Domain specific patterns.  In general Patterns fall into three broad categories:


·        Architectural Patterns: They are templates for concrete software architecture. They lay down the structural specification of the system and also determine the architecture of the sub systems and specify their responsibilities.

·        Design Patterns: Are medium scale patterns. They provide the schema for refining the sub systems or the components of the software system. They are smaller in scale than the architectural patterns but tend to be independent of the programming language used.

·        Idioms: Are the lowest level of patterns. They describe how to implement the particular aspects of the components. Idioms address both the design and the implementation issues of the components.

It is common to find other terms like Architectural Styles and Frameworks used in juxtaposition with Patterns.


Architectural Styles: The notion of architectural styles was first coined by Perry and Wolf in their paper, [PEW 92] and may be defined as a family of software systems defined in terms of its structural organization. “An Architectural style expresses components and relationships between them, with the constraints on their application and the associated design rules for their construction” [BMRSS 95].  In general a style represents a particular structure of the system together with the methods the specify how to construct the system.  The exact difference between an architectural style and a Pattern is hazy and for all practical purposes architectural styles are equivalent to architectural patterns. But Buschmann et al in their book [BMRSS 95] bring out some differences between styles and patterns.

·        Styles only describe the overall structural framework for applications. Patterns exist at various levels of abstractions from the architectural level to idioms at the application level.

·        Architectural styles are independent of each other, while patterns depend on smaller patterns that they encompass.

·        Patterns are more practical in that they have documented solutions, problem types they solve and the underlying logic behind their usage.


David Garlan, in the paper [DAV 95] describes some of the properties of Architectural Styles

·        Provide a vocabulary for component and connector types such as pipes, filters, clients, servers etc.

·        Define a set of topological constraints that determine the compositional rules of the elements.

·        Define semantics of the applications that adds meaning to it.

·        Performance analysis of systems built in that style. E.g. Deadlock Detection for applications built adhering to a particular style.


Some of the benefits of Styles include [DRA 97]:

·        Design reuse: the routine solutions that are applied in problems can be reused repeatedly.

·        Code Reuse: shared implementation is possible. E.g. Unix Pipe and filter style may reuse Unix operating system primitives.

·        Ease of understanding if the structure of the system were to be conventionalized.

·        The use of standard styles may also promote interoperability. E.g. the OSI protocol stack and CORBA object oriented architecture.

·        Style specific analysis is possible.



Framework is a partially completed software system that is ready for instantiation. It provides the architecture for the family of sub system and provides building blocks to create them. A framework for applications in a specific domain is called an application framework. This viewed from the perspective of patterns is a pattern for a complete software system in a given application domain.

1.4 Pattern Descriptions


Patterns need to be represented in a clear and intuitive fashion if one has to understand and discuss them. A good description enables the reader to grasp the essence of the pattern and cull the necessary details for the implementation of the pattern. Patterns also need to be described uniformly as this helps in comparing patterns and also in their analysis. Patterns literature today comes with well-defined ways of tabulating patterns.  In their book [GHJV 95] document Patterns as


·        Pattern Name and Classification

·        Intent: the rationale behind the patterns

·        Motivation: Scenarios that illustrate the use of the patterns.

·        Applicability: where does the pattern apply?

·        Collaboration: how the components interact and provide some sample code.


[BMRSS 95] in their book on Pattern Oriented Software Architecture, tabulate patterns as


·        Pattern Name

·        Example: Problem statement of the example and also diagrammatic representation.

·        Context: condition of applicability

·        Structure: CRC diagram (Class, Responsibilities and Collaborators)

·        Implementation and Example: heuristics for the solution provided

·        Known Uses and Consequences: benefits and drawbacks


Mary Shaw [Shaw 96] tabulates them into


·        Name and Problem

·        Context and Solution: system model, types of components, type of connectors, control structure.

·        Significant Variants:

·        Examples and References to use patterns.



2.0 Architectural Patterns


Architectural Patterns express fundamental structural organization schemas for software systems and also provide a set of predefined sub systems.  They represent the highest level patterns in a pattern system. There at present does not exists a very exhaustive list of architectural patterns. The categorization of existing patterns has been driven by the general properties of the application of systems. It is also an accepted fact that software systems may not be structured according to a single architectural pattern, as they need to support different system requirements. A single architectural pattern or a system of patterns is not complete software architecture in itself. It remains as structural framework that has to be refined further. Patterns are only the first step in specifying the architecture. Mary Shaw in her paper [Shaw 95] asserts that patterns differ according to the intuition behind the pattern, kind of components that are used to construct the system, interaction between the components and their execution.  Several patterns address issues at the architectural level of systems. As seen earlier patterns may be categorized into several boxes with different nomenclatures. The paper analyses patterns by describing:

·        Example: where the pattern could be useful

·        Problem and Context:

·        Solution: the system model captured by the pattern.

·        Heuristics for implementation: steps that need to be followed for the implementation of the pattern

·        Known uses and Benefits: where is the pattern put to use and some of the advantages of using the pattern.


 The Layers pattern, Broker pattern and the Model View Controller pattern are analyzed in accordance with the above-mentioned scheme.






3.0 Layers Pattern


This pattern is suitable for applications that could be broken down into groups of sub tasks where each group is at a different level of abstraction.


Figure 3.1: TCP/IP Protocol Stack along with the Data Segments in Different Layers.


·        Example: Networking protocols are the probably the best examples of the Layers patterns. Fig 3.1 provides hierarchy of the TCP/IP protocol stack.  Each layer deals with a different aspect of communication and uses the functionality of the adjoining lower layer. The layers communicate with each other through well-defined interfaces.


·        Context and Problem: A large system that requires decomposition. This kind of a pattern is most applicable in situations where there is a mix of lower and higher level issues and the higher level operations rely on the lower level ones.  The pattern of communication could be top down or bottom up.  For example requests could move from the top to bottom layers and responses could move from bottom to the top layers. Another issue is the portability of the systems in different environments, usually the higher layers tend not be that portable.


·        Solution: from a higher level viewpoint the solution is very simple to identify the number of layers that the system requires and to place them one top of the other.  The order in which the layers are to be designed are not specified in the literature. Other issues include whether layer J could be a complex layer that could be subdivided further. One of the essential constraints is that within each layer the constituent components need to work at the same level of abstraction.  The structure of the individual layer may be specified as follow using CRC(Class, Responsibilities and Collaborators) cards




Figure 3.2 CRC Card for Layer J

It is seen that Layer J+1 only uses the services of Layer J.  These services are usually provided through well-defined interfaces. There does not exist any further dependency between the layers. System may also be developed where a layer J could access services provided by any of the layers below it. Here the lower layers are not opaque to the higher layers.


Heuristics for Implementation: The implementation the system maybe done in a bottom up or a top down fashion. The following gives a top down solution for the problem.


·        Define criterion for grouping tasks into layers. This is conceptual in nature.

·        Determine the number of levels using the abstraction criterion. Each abstraction level corresponds to one layer of the pattern. Consider issues like placement of function in different layers and the composition of every layer.

·        Give a suitable name for the layers and assign tasks to them. While designing the tasks consideration needs to be given for the placement of the tasks in layers and also arrangement in a hierarchy.

·        Decide on the services that the layers are going to offer to the higher layers. The layers have to be strictly separate from each other.  The return types of the functions and also the parameters that the functions take are to be hammered out. Usually the services that are used frequently are located in the lower layers. Also as you go down the hierarchy the functions tend to be system specific like OS system calls etc.

·        Specification of the interfaces provided with every layer.  Lower layers act as a black box to the higher layers. In a white box approach the functionality of the lower layers is visible to the higher layers.

·        Communication between the layers:

- Push Mechanism: the higher layer pushes the information on to the lower layers when required.

- Pull Mechanism: the lower layers fetch information from higher layers at their own discretion.

·        Design of a proper error handling strategy.  An error may be handled in the layer where it occurs or could be passed on to a higher layer. In this the case the error description needs to be transformed into a format that is understood by the higher layer.  It is advantageous to have general error format that may be propagated in all the layers and it is easier to handle errors in the lower layers than at a higher level.


Advantages and Liabilities: Some of the scenarios where this pattern is useful are [BAM 91] [FRI 85] [LAS 79] and [PAU 85]. Virtual Machines fall seamlessly in this category. The virtual machine at every layer insulates higher layers from low-level details or varying hardware. Application Programming interfaces are usually hierarchical in nature.  Business domain has a two-layer architecture. The bottom layer being the Database and many layers work concurrently on top of the Database.


Advantages of using the Layers pattern is that the lower layers can be potentially reused. The layers have well defined interfaces and may be reused in multiple contexts.  This could reduce the effort involved in developing systems as concurrent teams may work on each of the layers. This also allows for standardization of the tasks and the interfaces of the layers. Thus different vendors could provide solutions for the different interfaces. The standardized interfaces enable local changes without regard to higher layers. Algorithms may be changed without regard to the higher layers.


This pattern is not without is share of liabilities. It is seen that this pattern is usually not very efficient as volumes of data has to be exchanged between the layers and passed down from one layer to the other. This is also true for the error messages that need to be propagated up in the hierarchy. There exists lot of duplication of functionality. Several layers perform the same function. As in the TCP/IP error checking is done by more than one layer, leading to redundancy. 

The decision of assigning the granularity of the layers and assignment of tasks to the layers is very difficult to make but is essential to the success of the architecture.


4.0 Pipe and Filter Pattern:


The pattern provides a structure for systems processing streams of data. Each of the processing steps is encapsulated in a filter component.  Pipes enable the transfer of data between the adjacent components.


Figure 4.1 Pipe and Filter Pattern


·        Example: The best example of the pipe and filter pattern is the Unix pipe and filter, where an output of a command is fed as the input of another. Frequent tasks like program compilation and document creation are usually done using pipes in Unix. CMS pipelines are extensions that help in supporting pipes in IBM Mainframes. CMS pipelines provide reuse and integration platform in the same way as Unix.  LASSP[SET 95] Tools is a tool set that mainly contains filter programs that also use Unix Pipes.


·        Context and Problem: This pattern is applicable in a setting where there are processing data streams that the system needs to transform. The system task decomposes naturally into several stages and requirements likely to change.  The pattern is most suitable for applications that require a defined series of independent computations to be performed on data.  The computations are performed incrementally on the data stream and in principle proceed in parallel. This reduces the latency of the system.


·        Solution: Divide the tasks into several sequential processing steps. The output of one step is connected as the input of the other. The individual steps are implemented using the filter components.

To achieve low latency and real parallel processing the filter consumes and delivers data incrementally. Outputs may flow into a data sink, a file, a terminal, animation program etc. Pipes connect the data source, filters and the sink and the sequence of filters combined with pipes is called a pipeline. The structure of the pipes and filters may be defined using CRC cards.



Figure 4.2 CRC diagram for the Filter and Pipe Class



Figure 4.3 CRC diagram for the Data Source and Sink Class


Heuristics for Implementation:

The implementation of the pipe and filter architecture is straightforward. Message queues or Unix like pipes may be used. The implementation of the Data Source and Sink follow that of the pipe and filter.


·        Divide the system’s task into a sequence of processing stages. Each stage depends only on the output of its predecessor. The stages are connected by data flow.

·        Data format to be passed along each of the pipes needs to be decided. Deciding on a uniform format helps in flexibility because it makes recombination of the filters easy.  Usually it is seen that one data format stymies the flexibility of the messages. For e.g. choosing ASCII text as the format may lead to improper conversion of the float data type from and to strings. To solve the problem it is better to create filters to convert from one format to another.

·        Decide on the implementation of the each pipe connection. This also determines if the filters are active or passive components and whether the pipes act in the push or the pull mode.  Using direct calls between filters for data transfer is a simple solution. Synchronization could also be done for adjacent active layers.

·        Designing the filter. The design depends on the tasks that it performs and also on the adjacent pipes. Passive filters may be implemented as function for pull or a procedure for push.  Active filters may be implemented as threads or as processes. Control over the behavior of the filters promotes reuse of the filters. Filters could also allow parameters to be passed to them.

·        Design for Error handling: This becomes hard, as there is no global state. It is very difficult to provide for a generalized error-handling pattern for the pipe and filter architecture. One of the mechanisms suggested is the use of buffering in case of crashing of filters.


Advantages and Liabilities:

One of the significant advantages is that there are no intermediate files that are necessary but may be present. Results could be computed using separate programs by storing intermediate results in a pipe. Filters tend to have a simple interface. The reusability of the filter components allows the creation of new processing pipelines by rearranging the filters. This recombination promotes reuse of the components. This also leads in rapid prototyping of the system from existing filters. Parallel processing leads to achieving efficiency.

Some of the liabilities of this pattern are, if a large amount of global data needs to be shared then application of this pattern proves to be inefficient. Efficiency gains due to parallel processing are often unrealistic. Synchronization of filters via pipes may stop and start pipes often, esp. if the buffer in the pipe is very small. Finally the implementation of a single error handling mechanism is close to impossible in the pattern.


5.0 Broker Pattern:


This pattern is used to model the interaction between distributed systems with de coupled components that interact using remote service location. A broker component coordinates the requests, responses, error and results between the components.  Platforms such as Microsoft’s OLE  (Object Linking and Embedding) [BRO 94] and OMG’s CORBA [OMG 92], IBM’s SOM and DSOM [CAM 94] are based on this pattern. The groups of users who could benefit from this pattern are those working with existing broker systems and interested in understanding the system, those who want to build lean system out of the existing systems or those who want to build a full fledged Broker system.



Figure 5.1 Highest Level Abstraction of the Broker in CORBA

·        Example: This form of an application is suited for communication between distributed systems seamlessly. The application is unaware of the location of the service or the physical location of the host providing the services. The hosts may also speak different languages. A host invokes a function call on the remote host as if it were a local procedural call. The Broker is responsible for passing the requests from the client to the host in another environment and invoking the appropriate function in that host and returning the execution status of the invocation. All the while the client is unaware of the Server’s location.


·        Context and Problem: The context is an environment that is distributed and possibly heterogeneous and has independent cooperating components. The main task is to design the application as sets of inter operating components than as a monolithic application. To make the application distributed the functionality is split between the components. This also makes the application flexible and scalable. However some form of inter process communication is required and the implementation of the broker is language specific in nature.  Services for adding locating and removing components also need to be considered.  The application should only see the interface of the object. It should not know anything about the implementation details of the object or its physical location. Components should be able to access services provided by other components through domain transparent remote location services.


·        Solution: Broker component is introduced for better de coupling of the components. Servers register themselves with the clients and make their services available to the clients through interfaces.  There are six types of participating component clients, servers, brokers, bridges, client side and server side proxies.  A Server implements the services and exposes the functions through interfaces. These interfaces are defined using IDLs Interface Definition Languages or through binaries.  Clients are applications that access the services of at lest one of the servers. Clients forward requests to the broker and receive exceptions or responses from the broker. The CRC cards for the Clients are servers are given below



Figure 4.2 CRC of Client and the Server Class

A broker is a messenger that is responsible for the transmission of requests from the clients to the servers and the responses or the error message back to the client. The broker must have some means of locating the receiver of a request based on unique system identification. It offers APIs to the Client and the Server for the above operations.


Figure 4.3 CRC of Broker Class

The client side proxies represent a layer between clients and the broker. This additional layer is used for the transparency purposes. Proxies help in hiding implementation details form the clients like inter process communication messages. Marshalling of parameters and results. Proxies are also responsible for translation of the pattern specified in the broker into object model used in the programming language in the client.  Server side proxies are responsible for receiving requests and unpacking them and invoking the appropriate services.


Figure 4.5 CRC of the Proxies on the Client and the Server

Heuristics for Implementation:

·        Define an object model. This should include information like names, requests, values, exceptions, type extensions and interfaces and operations. Semantic issues also need to be considered.

·        The kind of component interoperability that the system should offer. This could be dome using the interface definition language or using binaries. The binary approach needs programming language support e.g. use of binary method tables in Microsoft’s OLE.

·        Specify the API’s that the broker component provides for spelling out the collaboration between the client and the server. Use of Proxy objects to hide the implementation of the client and the servers.

·        Development of the wire level protocols for the interaction between the client and the server side proxies.

·        When a client invokes a procedure call of the server then the Broker system is responsible for returning all the error messages and the results to the client. It needs to remember which client accessed which server.

These are some of the very high level issues that need to be incorporated in the broker pattern.


Advantages and Liabilities:

The pattern offers location transparency to the clients. Clients do not have any information about the location of the servers. The functionality of the servers could change, as long as the interfaces remain the same. The use of proxies and bridges increase the reusability of the components. Portability, the broker hides the operating system and network details from the clients and the servers. This enables the clients and the server components to be ported to different components. Different broker system can communicate if they all understand the same protocol.

This pattern is not without its liabilities. It is usually seen that applications using brokers are slower than application distributions that are static and known. Most of the bindings are implementation specific in nature. A broker-based system also offers a lower fault tolerance when compared to a non distributed software system.


5.0 Model View Controller Pattern:

Figure 5.1 MVC Interaction Diagram


This pattern divides the interactive application into three parts. The model contains the core functionality and the data. View displays information to the user and controllers handle user the inputs. Views and the controller together provide the user interface.


Context and Problem: Useful for interactive applications with a flexible human- computer interface. User interfaces are prone to change. Different users place conflicting requirements on the interfaces. Thus building the system tightly interwoven with the interface makes the system inflexible and inextensible. This would entail developing different systems for each of the user interface implementations.  


Solution: MVC was first introduced in SmallTalk –80 programming environment [LP 91] [KPP88]. The Document View Variant of MVC is incorporated in MFC in VC++ environment [KRU 96]. MVC divides the applications into three areas the processing, input and output. The model component contains the functional core of the application. It encapsulates the appropriate data, provides for the necessary export and import functions to perform program specific processing. The model also notifies all the views when the data changes. The change propagation mechanism maintains a registry of dependent components within the module. This acts as the only link between the model and the views and the controllers. The View component presents information to the user. Different views present information of the models in different ways. Each view has an update procedure that is called and is activated by the change propagation mechanism. During initialization all views are associated with the model and have a suitable controller.  Views also offer functionality that the controller can use to modify the display. The Controller component accept user inputs as events. How these are delivered to the controller depends on the user interface platforms. If the behavior of a controller depends on the state of the model then the controller registers itself with the change propagation mechanism and implements an update procedure.  The CRC representation of the View and the Container components are given below.



Figure 5.2 CRC of the View and the Controller Class


Heuristics for Implementation:

·        Separate human computer interaction from the core functionality. Model the model component to encapsulate both the data and the functionality needs of the core. Add an interface to the parts that are to be exposed to the controller.

·        Implementation of the change propagation mechanism: Following the publisher subscriber pattern [GHJV 95] for this is recommended and assignment of the roles of the publisher model. Providing services for the views and controllers to subscribe and unsubscribe to the change propagation mechanism.  Call notify functions for reporting change in the state of the model.

·        Design and implementation of views: Usually a draw procedure is specified for the rendering the views differently on different platforms and based on user specification.  Implement update procedures to reflect changes to the model.

·        Design and implementation of controllers: for every view there needs to be specifications of how the user actions are going to be handled by the system.  The controller interprets these events using a dedicated procedure. Depends on the state of the model.

·        Design and implementation of the view and controller relationships: A view typically creates its associated controller during its initialization.  It is better to build a hierarchy of views and controllers. It is better to use the factory method pattern. [GHJV 95]

·        Implement the set up of MVC: the set up model first initializes the model and then creates and initializes the views.


Advantages and Liabilities:

MVC strictly separates the model from the user interface components. Hence multiple views may be implemented in the single model. Also views may be opened and closed dynamically. The change propagation mechanism of the model ensures that all attached observers are notified when the model changes at the same time. This leads to synchrony in the system. The user interfaces objects may be changed at runtime seamlessly as the view and the controller objects may be interchanged.  There are also portability advantages, as the interfaces are separated from the model the system ca potentially run on many of the platforms.

Liabilities: It is commonly seen that the MVC approach increases the complexity of the system and does not gain that much in functionality.  If a single user action leads to many updates then the model should skip the unnecessary updates. The controller and the view are closely related that prevents reuse of them individually.  The use of the high level toolkits or user interfaces builders usually makes the use of MVC almost impossible.


6.0 Patterns Future:

Some of the most important issues related to patterns are Where are patterns going? There are multitudes of issues that are important. In the ensuing paragraphs I have highlighted some of the areas that gain importance.


Ø      Pattern Management:

As new patterns are added into the literature, a main issue in the future will be that of mining new patterns. Patterns generally rest at the architectural level, developers still need to rack their brains on issues at the algorithmic level. Only a combination of algorithms and Design patterns will help in solving the problems of the developers. Design patterns would support the instantiation of algorithms. For this there is a requirement that existing algorithms be described in a patterns form. Future research would use the same scheme used in patterns for describing the algorithms. As new developments in software transpire some patterns become obsolete and need to be replaced by other patterns. Some of the future work will also be to maintain patterns history, revisions and variants. These involve configuration management issues for Pattern management.


Ø      Pattern Languages:

Much of the existing literature on patterns is organized as design pattern catalogs [BMRSS 95, GHJV 95]. These catalogs present a collection of relatively independent solutions to common design problems. As more experience is gained using these patterns, developers and authors will need to integrate groups of related patterns to form pattern languages. These pattern languages will encompass a family of related patterns that cover particular domains and disciplines. E.g. concurrency, distribution, organizational design, software reuse, real-time systems, business and electronic commerce, and human interface design etc.

Just as frameworks support larger-scale reuse of design and code than do stand-alone functions and class libraries, pattern languages will support larger-scale reuse of software architecture and design than individual patterns. Developing comprehensive pattern languages prove to be challenging and time consuming, also as patterns develop more efficient patterns would emerge and work better with existing patterns. Challenges would be to categorize and tabulate them.


Ø      Integration of design patterns and frameworks:

Some of the most useful patterns describe frameworks. Such patterns can be viewed as abstract descriptions of frameworks that facilitate widespread reuse of software architecture [SCH 95]. Similarly, frameworks can be viewed as concrete realizations of patterns that facilitate direct reuse of design and code. One difference between patterns and frameworks is that patterns are described in language-independent manner, whereas frameworks are generally implemented in a particular language. However, patterns and frameworks are highly cohesive in nature. The next generation of object-oriented frameworks will explicitly embody many patterns and patterns will be widely used to document the form and contents of frameworks


Ø      Formalizing Patterns:

In principle, one must demonstrate that patterns can indeed be formalized [MEG 99]. In [AHE 98] Eden provides an analysis of the specification of the solutions of design patterns in the GoF book [GHJV 95]. Eden divides the specifications into six categories according to their generality and precision, four of which are precise, one is semi precise, and one is very difficult to formalize. Additionally, evidence appears to indicate that, due to the effort by the GoF, the majority of the specifications in the book belong to the first 5 categories. Patterns help to alleviate software complexity at several phases in the software lifecycle. Although patterns are not a software development method or process, they complement existing methods and processes. Formalisms in pattern would lay down structure in pattern descriptions, as most of the description of patterns today is informal in nature.  Formalization of structure, dynamics and semantics of the patterns are possible. These would in turn support the development of pattern tools better than the informal patterns of today. However it also becomes harder to match formalized pattern to a design as the designs are not formalized. A formalized solution may also narrow down the applicability of the pattern. In future these aspects need to be analyzed in detail and the trade off considered.


Ø      Automatic Code Generation:

Patterns could also be used for automatic code generation. Idioms captures implementation level patterns and thus could aid in auto code generations. For e.g. if C1 and C2 were to be two classes and we are interested in making C1 the observer of C2, then we could use the Observer Pattern and the “tool” would generate code for making C1 an observer of C2. Also we could do the reverse given a source code and the OO language used and a precise specification of a pattern, discern whether the code is an instance of the pattern (Validation). We could also find out if a subset of the code is an implementation of some pattern and could extend this to the entire application and if possible arrive at the architectural pattern of the system (Recognition). We could also check if some elements in a language form valid patterns (Discovery). In future patterns will focus on using Patterns to help code generation.


Ø      Domain Specific Design Pattern:

Are collections of components and objects that represent, in software, a well-defined (encapsulated, clear boundary, highly cohesive) partitions of a particular system domain.  The main goal of the approach is to clearly describe a flexible architecture in terms of well defined, highly encapsulated, manageable parts that are in alignment with the natural constraints of the domain. The main advantages of the approach are the development of well-defined components that may be easily reusable. One of the advantages of Domain Specific patterns could be the generation of code automatically from them. As the formalism in patterns increase generators could be used to generate automatic code[FJM]. Performance analysis techniques may also be applied on the patterns to arrive at the optimal solution.







6.0 Conclusions:


The paper provides a basic overview of patterns their domain of applicability and their characteristics.  Similarities between patterns with frameworks and styles are also briefly analyzed. Architectural patterns are analyzed in detail. The domain of applicability, their characteristics, heuristics for their implementation and some trade off involved in using the pattern are also delved on. The structure of each of the components in the classes is described using CRC cards. The patterns described include the Layers, Pipe and Filter, Broker and the Model View Controller Patterns. Finally some of areas for future research is discusses. These include pattern mining, appropriate pattern documentation, Pattern Languages, Automatic Code generation from patterns and finally domain specific patterns for an industry e.g. Telecommunications or for a business.





[ALE 79]

C.Alexander, The Timeless way of Building, Oxford University Press,1979.

[AHE 98]

A. H. Eden (1998d). "Giving 'The Quality' a Name". Journal of Object Oriented Programming, guest column, Vol. 11 No. 3, pp. 5-11, June 1998. New York: SIGS Publications.

[BAM 91]

D. Batory and S. O’Malley. “The Design and Implementation of Hierarchical Software Systems Using  Reusable Components”. TR 91-22, Dept. of Computer Science, University of Texas, Austin, June 1991.

[BMRSS 95]

Patterns Oriented Software Architecture, Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerland, Micheal Stal, Siemens Germany, Addison Wesley. 1995.

[BRO 94]

K Brockschmidt: Inside OLE2, Micro Soft Press 1994.

[CAM 94]

F.R Campagnoni: IBM’s system Object Model, Dr Doobs Journal, Special Report, #225 Winter 1994/95, pp 24-28.

[DAV 95]

David Garlan, What is Style? Proceedings of Dagshtul workshop on Software Architecture, Feb 1995.

[DRA 97]

David Garlan, Robert T Monroe, andrew Kompanek, Ralph Menton, et al, “Architectural styles Design Patterns and Objects” IEE Software 1997.


Pattern-Based Code Generation for Well-Defined Application Domains, Frank Heister, Jan Peter Riegel, Martin Schuetze, Stefan Schulz, Gerhard.

[FRI 85]

Marek Fridrich and William Older. “Helix: The Architecture of the XMS Distributed File System”. IEEE Software, vol 2, no 3, May 1985 (pp. 21-29).

[GHJV 95]

E. Gamma, R. Helm, R Johnson, J Vissides: Design PatternsElements of Reusable Object Oriented Software, Addison Wesley, 1995.

[GHJV 93]

E. Gamma, R. Helm, R Johnson, J Vissides, Design Patterns: Abstractions and Reuse of Object Oriented Design, Proceedings of 7th European Conference, Germany.


G E Krasner, S.T. Pope: A cookbook for using the Model View Controller user interface paradigm in Small Talk, Journal of Object Oriented Programming, August 1988, SIGS Publications.

[KRU 96]

D Kruglinsky, Inside Visual C++, Microsoft Press.

[LAS 79]

Hugh C. Lauer and Ed. H. Satterthwaite. “Impact of MESA on System Design. Proc Third Int’l Conf. on Software Engineering”, May 1979.

[LP 91]

WR LaLonde, JR Pugh: Inside SmallTalk, Volume II, Prentice Hall, 1991.

[MEG 99]

M. Ersson, A Gustavsson (1999). "Formalizing the Intent of Design Patterns." Technical report 1999-004, Institute of Information Technology, Uppsala University.

[OMG 92]

Object Management Group, The Common Object Broker Request: Architecture and Specification,  OMG Document Number 91.12.1 Revision 1.1.1992.

[Paulk 85]

Mark C. Paulk. The ARC Network: A Case Study. IEEE Software, Vol 2 no 3, May 1985, pp. 62-69

[PEW 92]

Pery and Wolf, “Foundations for the study of Software Architecture”, ACM Sig Soft Volume 17, Oct 1992.

[SCH 95]

Schmidt, Douglas, Using Design Patterns to Develop Reusable Object-Oriented Communication Software, CACM, (Special Issue on Object-Oriented Experiences, Mohamed Fayad and W.T. Tsai Eds.), 38, 10, October 1995.

[Shaw 95]

Mary Shaw. “Patterns for Software Architectures”. In Coplien & Schmidt (eds),Pattern Languages of Program Design, Addison-Wesley 1995, pp. 453-462.

[Shaw 96]

Mary Shaw, “Some Patterns for Software Architectures” 1996.

[SET 95]

J.Sethna: LASSP Tools: Graphical and Numerical Extensions to Unix,