Patterns for Software Architectures
Arvind S
Krishna
Information and Computer Science Department
University of California, Irvine CA
Abstract:
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.
References: