See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/235651500

The Explanation of the Design Patterns by the Symmetry Concepts

Conference Paper · June 2011

DOI: 10.2316/P.2011.716-009

CITATIONS READS
2 198

3 authors:

Siniša Vlajić Dusan Savic

Faculty of organisational sciences - University of Belgrade University of Belgrade
41 PUBLICATIONS   52 CITATIONS    26 PUBLICATIONS   41 CITATIONS   

SEE PROFILE SEE PROFILE

Ilija Antović
University of Belgrade
20 PUBLICATIONS   34 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

SilabMDD View project

All content following this page was uploaded by Dusan Savic on 30 May 2014.

The user has requested enhancement of the downloaded file.

 The Explanation of the Design Patterns by the Symmetry Concepts
Siniša Vlajić, Dušan Savić, Antović Ilija
Department of Software Engineering, Faculty of Organizational Sciences,
Jove Ilića 154, Belgrade, Serbia.
e-mail: vlajic@fon.bg.ac.rs, dules@fon.bg.ac.rs, ilijaa@fon.bg.ac.rs
ABSTRACT
The aim of this paper is to establish a connection
between software engineering and other science
disciplines, such as mathematics, physics, and alike ,with
the intent to use the knowledge from these disciplines to
create a new software system which will be more stable
and sustainable than existing systems. To this aim, this
paper formally explains the design patterns through the
concepts of symmetry; symmetry transformations and
symmetry groups. We give the formal definition of design
patterns and explain when and how the design patterns are
occurring. Therefore, we have made the formal basis to
create stable and sustainable software systems, based on
symmetry concepts, which will be both changeable but
also immune to change. We have defined the theorems
that connect concepts of symmetry and class diagrams
and pointed out the cases when classes make a symmetry
transformation and when a set of classes make the
symmetry and no-symmetry group. Finally, we have
given an example to show the process of making design
patterns by using the symmetry concepts.
KEY WORDS
Design patterns, Symmetry concepts
1. Introduction
The book Design Patterns: Elements of Reusable Object-
Oriented Software [1] has launched an avalanche in the
world of software engineering and put the patterns in the
center of software development in a very practical way. It
is one of the most important source in understanding
object-oriented design theory and practice.
Design patterns are one of the most important
mechanisms in the development of sustainable software
systems. Up to now, many design patterns are made and
used in the development of numerous software systems.
Design patterns are primarily seen as a generic solution
that can be applied several times in different problem-
situations. In addition, design patterns provide great
flexibility in the program during its maintenance and
upgrades. These positive pattern features (re-usability
and easy maintenance) have led to formalisation of the
design pattern (Figure 1). With this notion a lot of pattern
languages are made (Balanced pattern specification
language (BPSL), Design Pattern Modelling Language
(DPML),…, LePUS`: A Formal Language for Modelling
Design Patterns) [2] to : a) better understand patterns and
their composition b) accurately describe patterns to avoid
their duplication and to simplify the process of the pattern
repository management, and to c) allow the development
of the tool support in activities related to patterns in
the software development process.
GOF DESIGN PATTERNS
PROBLEM SOLUTION
DPIO BSPL DPML Lepus
Ontology Pattern
Formalisms
Fig. 1: The formalisms for describing the design patterns
However, these languages neither give a precise formal
definition of design patterns in a general sense, nor
explain when and how the patterns are occurring. If we
understand the patterns as a solution to a problem in a
context [3], then we can say that these pattern languages
are focused on a precise definition and specification of
solutions, while less attention is paid to the problem
being solved. Formalization of patterns, from the
perspective of the problem, is described in the paper of
Holger Kampffmeyer and Steffen Zschaler a [4], in which
design patterns are formalized and classified according to
their purpose (problem-solving) by DPIO (Design
Patterns Intent Ontology).
The above formalisms in a conceptual way explain the
connection between a problem and a solution of the
pattern, without going into a deeper understanding of
the relationship between elements of the problem and
solution of the pattern. This paper tries to point out the
connection between the elements of the problem and the
solution of the pattern and to formally explain the
process of transforming (T) the problem into the
solution through the symmetry concepts (symmetry
transformations and symmetry groups) (Figure 2).

GOF DESIGN
PATTERNS
T indicate the fact that the patterns are at the same time the
PROBLEM SOLUTION
SYMMETRY
CONCEPTS
SYMMETRY SYMMETRY GROUP
TRANSFORMATION
Fig. 2: The transformation process T described by the
symmetry concepts
Jim Copline and Liping Zhao stressed the importance of
the symmetry concepts in understanding the patterns [5]:
“...contemporary attempts to formalize patterns ignore
both the prior art and the most relevant foundations for
potential formalization.... Pattern and symmetry are
closely related ... ".
The formalization of the symmetry concepts is well
described in the book Symmetry Rules [6]. According to
the definition of symmetry given by Rosen: Symmetry is
immunity to a possible change, the aim of this paper is to
define a formal basis for making the stable and
sustainable software systems, based on symmetry
concepts, which will be abl eboth to change but will also
be immune to change. We maintain that further
development of software systems should seriously
consider the concepts of symmetry because they exist in
the bases of any of the conservation laws, e.g.
Conservation of Energy, Conservation of Linear
Momentum, Conservation of Angular Momentum.
We have derived our theory on the base analysis of the
GOF (Gang Of Four) design pattern [1] where we have
observed the structure of solutions which is common to
most of the GOF design patterns. This has led us to
hypothesize that defined structure is a key mechanism for
the design pattern and that it is the "core", "being" or
"essence" of the design patterns. Based on that structure
we have defined the structure of the problem and
explained how to transform the structure of the problem
into the structure of the solution. Using this approach we
logically associated (through the symmetry concepts) the
structures of the problem and solution.This allowed us to
explain, in general terms, what the patterns are and when
and how patterns are occurring.
2. The patterns in the general sense
Before we commence the analysis of design patterns we
will give some definitions of the patterns in general sense
to perceive the key elements of the patterns and to
structure and process (Figure 3).
Christopher Alexander says [7]: “Each pattern describes
a problem which occurs over and over again in our
environment, and then describes the core of the solution
to that problem, in such a way that you can use this
solution a million times over, without ever doing it the
same way twice.” While Erich Gamma gives the
following definition of patterns [1]:
“The design patterns are descriptions of communicating
objects and classes that are customized to solve a general
design problem in a particular context“.
From the above definitions, it is clear that patterns have
two important parts, the problem and solution. The
solution of a problem can be reused several times for
different problem domains, from which stems a
reusability concept as an important property of patterns.
Also, Alexander points out : “The pattern is, in short, at
the same time a thing, which happens in the world, and
the rule which tells us how to create that thing, and when
we must create it. It is both a process and a thing; both a
description of a thing which is alive, and a description of
the process which will generate that thing.”
Jim Coplien [8], a famous expert in the field of the
patterns, told us a similar thing when he spoke about the
patterns:
“… it is the rule for making the thing, but it is also, in
many respect, the thing itself”.
These experts tell that the pattern is at the same time the
structure (thing) and the process. A pattern has the
structure of the problem and the solution. The pattern is a
process that explains when and how it the structure of the
solution from structure of the problem is created.
PATTERNS
STRUCTURE
T
SOLUTION
PROBLEM
PROCESS
Fig. 3: The structure and process as the basic properties of
patterns
3. Analysis of the design patterns
To understand the process of transforming the problem
into solution for the design patterns we had to find the
structure of the problem and the solution in a most general
sense. We first analysed the GOF design patterns in order
to find the structure of solutions, which as a whole or a
part, can be found in the most of the GOF patterns. As a
result of the analysis we have obtained the structure of the
solution that exists in 20 GOF patterns and has the
following form:
Where CL is an abbreviation for Client, AS for
AbstractServer and CSi for ConcreteServeri (i = 1..n, n is
the number of concrete servers). We believe the structure
of the solution (Figure 4) represents “key mechanism”,
"the core", "being" or "essence" of the design patterns.
CL
AS
CS1 CS2 CSn
Fig. 4: The basic pattern structure of solution (BPSS)
We call this structure: “The basic pattern structure of the
solution (BPSS)”.The significance of this structure
reflects in a weak dependence between CL and CS, which
allows great flexibility of the software system during its
maintenance and upgrades. The dependence between the
CL and CS is indirect through AS. BPSS structure can be
found in most GOF design patterns. BPSS essentially
solves the problem of a strong binding between the client
and more concrete servers (Figure 5):
CS1
CL
CS2
CSn
Fig. 5: The basic pattern structure of the problem (BPSP)
We call this structure: "The basic pattern structure of the
problem (BPSP)". Based on the above analysis we have
concluded that the structure of the problem - BPSP is
transformed into the structure of solutions - BPSS
(Figure 6).
GOF DESIGN PATTERNS
BPSP T BPSS
Fig.6: Transforming the structure of the problem-BPSP
into the structure of the solution-BPSP.
4. Theorem of the symmetry transformation
for the given injective function (Theorem of
STIF –Symmetry Transformation Injective
Function)
At this point we will explain symmetry concepts which is
the basis for the development of our theory of the design
patterns. To understand the symmetry concepts we will
start from the notion of the system.
A system can be in several (n) different states. The system
is, at the time of its creation, in an initial state. The system
is under various influences that can transform its state.
The transformation (T) of the state si in the state sj, we
present as:
T
si ---> sj, si, sj State; i,j n , where n is the number
of possible states of the system.
After transformation we can examine the relation R
between states si and sj:
si R sj
Different relations may exist between si and sj, for
example, equivalence relation or order relation. The
equivalence relation between two states exists if it
satisfies the following conditions: reflexivity, symmetry
and transitivity.
1. Reflexivity. a  a for all a (every element of the set is
equivalent to itself).
2. Symmetry. a  b  b  a for all a, b.
3. Transitivity. a  b, b  c  a c for all a,
b, c.
Theorem of STIF: The transformation T is said to be
symmetry transformation S, if between si and sj exists an
equivalence relation  after the transformation.
T
si ---> sj  si
Between states si and sj there is the relation of
equivalence if there is the injective function f which
satisfies: f(si) = f(sj) => si = sj (if f(si) equal to f(sj), It
follows that si equal to sj)
Proof: If the function f, which we call " function of
origination ":
f (si) = a) f(sj) , if sj is image of si,
 b) si between si and sj exist equivalence relation for the
State= { s1,s2,…,sn} – set of states injective "function of origination" f, for which applies: if
si, sj State, where is i,j 1..n (si,sj are elements of f(si) = f(sj), then si = sj
State) Symmetry transformation is essentially a function fst
if  => sj is image of si , where is  criteria that which maps si in sj: fst (si,sj)
determines when sj is image of si. The theorem of STIF will be presented by UML class
diagram (Figure 7). System has many states.
If the function f is applied to si and sj, we obtain : Transformation T is defined between two states si and sj.
f(si) = f(sj) => sk = sk After transformation between si and sj a relation exists. If
It follows: between si and sj there is an equivalence relation after
f(si) = f(sj) => si = sj transformation then a symmetry transformation is
which can be presented as follows: executed. The equivalence relation exists if it is defined
sk = sk by function of origination (f). The equivalence relation
f↑ T f ↑ is realized by Equality operation.
si ---> sj
Based on the above, we can conclude that there exists the
equivalence relation ≡ between si and sj: si ≡ sj, which is
realized by the equality operation = between si and sj: si
= sj if there is a injective function f for which applies: if
f(si) = f(sj), then si = sj, for all si and sj.
Thus the theorem is proven. The transformation T
between si and sj is symmetry transformation because

Function of The transformation T is said to be symmetry

origination (f) transformation S, if between si and sj exist the
equivalence relation after the transformation.
gives the same result is performed on

1 * 1 (si)
System * State T
1 (sj)
1 1
Between states si and sj exist the
equivalence relation, if exist the injective
function f, for which applies: f(si) = f(sj) =>
Symmetry transformation (S)
si = sj
Relation - fst

Equivalence relation ()

Equality operation

Fig. 7: The theorem of STIF

5. The Application of the theorem of STIF at
the class diagram
The theorem of STIF (Figure 8) can be applied at the
class diagram of the UML [9]. The concepts of the
theorem are mapped in the concepts of the class diagram.
The system is represented by the class diagrams. The
states of the system(s1, s2 ,..., sn) are the classes.
For the "function of origination" f needs to define criteria
 which determinates when sj is an image of si. In the
case of class diagram, the criteria  is defined as:
si has sj
si sj
si is original, while sj is image.
b) si is sj
sj
si
si is original, while sj is an image.
This means that the "function of origination" for class
diagram is defined as follows:
if si HAS sj or si IS sj => sj is image of si
If function f apply to si and sj, we obtain:
f(si) = f(sj), sj = sj,
It follows:
f(si) = f(sj) => si = sj
This means that IS and HAS relationships, between
classes si and sj, realize equivalence relation between
these classes. It follows that there is a symmetry
transformation between si and sj.
6. Theorems of the Symmetry Group realised
by the Class diagram
There are two theorems that realise symmetry group by IS
(first theorem) and HAS (second theorem) relationship of
the class diagram.
,..., Yn-1) of the class diagram. The transformation of the
system states are operations of the classes. The relations
between the states of the system are relationships between
classes. The equivalence relation between the states of the
system are has (aggregation) and is (generalization)
relationships between classes, which will be further
explained in more detalis.
6.1 Theorem of the Symmetry Group realised by the
IS relationship of the Class diagram
If the classes Y1, Y2 ,..., Yn inherit class Y (Figure 8),
between each pair of classes ({Y1,Y}, {Y2,Y},...,{Yn,Y}) a
symmetry transformation exists according to the theorem
of STIF. This set of symmetry transformations makes the
symmetry group.
Y
Y1 Y2 Yn
...
Fig. 8 IS relationships between class Y and the classes Y1,
Y2 ,..., Yn
Proof: The above statement is true if it is proven that each
of these symmetry transformations is invertible and the
set of the symmetry transformation satisfies the following
4 axioms [Coplien 2001] which defines the group:
1. Closure. For all a, b  G, the set G is closed under
composition: ab, ba  G.
2. Associativity. For all a, b, c  G, the composition is
associative: (ab)c = a(bc).
3. Existence of an Identity Element. For all a  G, there
exists an element e  G such that ae = a = ea.
4. Existence of Inverses. For each a  G, there exists an
a-1  G such that aa-1 = e = a-1a.
If the function of origination f applied to each pair,
S1 S1
f(Y1) ---> f(Y) => Y ---> Y
S2 S2
f(Y2) ---> f(Y) => Y ---> Y
...
Sn Sn
f(Yn) ---> f(Y) => Y ---> Y
the equality exists betwen S1,S2,...,Sn (S1 = S2 = ... =
Sn). This means that all symmetry transformations are the
same if classes Y, Y1, Y2, ..., Yn are under of the influence Fig. 9:HAS relationships between classes Y1, Y2 ,..., Yn
of the injective function f. and class Y
This set of symmetry transformations makes the
symmetry group because: Proof for above theorem is performed in a similar way as
a) Closure. For all s1, s2  G the set G is closed under the proof of the Theorem of the Symmetry Group realised
composition: s1s2, by the IS relationship of the Class diagram.
s2s1  G, G S1 S2, …, Sn) We mark the symmetry group with::
s1 s2 fsg (Y,X)
Y ---> Y ---> Y The symmetry group consists of a set symmetry
Result of s1s2 is equal to S where S is equal to any of transformation between pairs (Y1, X), (Y2, X ),..., (Yn, X),
these symmetry transformations: S1 = S2 = ... = Sn = S for which an equivalence relation is defined.
The same goes for s2s1: fsg (Y,X) = fst(Y1,X) + fst(Y2,X),..., + fst(Yn, X),
s2 s1 fst(Y1,X) = fst(Y2,X),..., = fst(Yn,X)
Y ---> Y ---> Y
b) Associativity. For all s1,s2,s3  G, the composition is
associative: (s1s2)s3 = s1(s2s3), G  S1 S2, …,
Sn ) 7. Theorems of the no-Symmetry Group
s1 s2 s3 s1 s2 s3
realised by the Class diagram
(Y ---> Y ---> Y ) ---> Y = Y ---> (Y ---> Y ---> Y)
There are two theorems that realise no-symmetry group
s1s2 s3 s1 s2s3 by has (first theorem) and is (second theorem)
Y ---> Y ---> Y = Y ---> Y ---> Y relationship of the class diagram.
3. Existence of an Identity Element. For all s  G, there
exists an element e  G such that se = s = es, G 7.1: Theorem of the No-Symmetry Group realised by
the HAS relationship of the Class diagram
 S1 S2, …, Sn )
s e s e s If the class X has (related to) several classes Y1, Y2 ,..., Yn
(Y ---> Y ---> Y) = (Y ---> Y) = Y ---> Y ---> Y (Figure 10), between each pair of classes
({X,Y1},{X,Y2},...,{X,Yn}) there exists the symmetry
e can be any of the symmetry transformations from the set
transformation according to the theorem of STIF. This set
G.
’ of the symmetry transformations does not make the
4. Existence of Inverses. For each s  G, there exists an symmetry group.
s-1  G such that ss-1 = e = s-1s, G  S1 S2, …, Y1
Sn X
s s-1 e s-1 s Y2
(Y ---> Y ---> Y) = (Y ---> Y) = Y ---> Y ---> Y
s-1 and e can be any of the symmetry transformations from
the set G.
6.2 Theorem of the Symmetry Group realised by the
HAS relationship of the Class diagram Yn
If the classes Y1, Y2 ,..., Yn has the class X (Figure 9),
between each pair of the classes ({Y1,X}, Fig. 10:HAS relationships between class Y and classes
{Y2,X},...,{Yn,X}) exists the symmetry transformation Y1, Y2 ,..., Yn
according to the theorem of STIF. This set of the
symmetry transformations makes the symmetry group. Proof: The above statement is true if it is proven that set
of symmetry transformations does not satisfy one of the
Y1 following 4 axioms [CoplienSym1] which define the
X group, as it is explained in the proof of the Theorem of
Y2 the Symmetry Group realised by the IS relationship of the
Class diagram.

If the function of origination f applied to each pair,

S1 S1
Yn
f(X) ---> f(Y1) => Y1 ---> Y1
 fst(X,Y1) ≠ fst(X,Y2),..., ≠ fst(X,Yn)
S2 S2
f(X) ---> f(Y2) => Y2 ---> Y2
... 8. The explanation of the design pattern by
Sn Sn the symmetry concepts
f(X) ---> f(Yn) => Yn ---> Yn
the inequality exists between S1,S2,…,Sn (S1 ≠ S2 ≠ ... ≠ The design patterns will be explained by the symmetry
Sn). Thit means, the symmetry transformations are not the concepts through the example of the program that will be
same if the classes X,Y1,Y2,...,Yn are under the influence written in intuitive object pseudocode which is similar to
of the injective function f. the Java programming language.
This set of the symmetry transformation does not make If the pattern is considered as a relation beetwen the
the symmetry group because it does not satisfy one of the problem and its solution, then the pattern can be explained
axioms (closure) which define the group: as follows: For the given original X there is an image Y1,
which can be represented by the relation of a symmetry
a) Closure. For all s1, s2  G the set G is closed under transformation beetwen X and Y1 (Figure 12): fst(X,Y1)
composition: s1s2, s2s1  G, G  S1 S2, …, Sn )
Example in object pseudocode:
These sets of the symmetry transformations S1 S2, ..., class X // fst (X,Y1)
Sn cannot, among themselves, make the composition. { Y1 y1;
X() {y1 = new Y1(); }
void m() { y1.m(); }
In this way, it is proved that the given a set of symmetry }
transformations does not make the symmetry group.
class Y1
7.2: Theorem of the No-Symmetry Group realised by { void m() {…}}
the IS relationship of the Class diagram class Main
If class X inherits the classes Y1,Y2,...,Yn (Figure 16): {
public static void main(String arg[])
Y1 { X x = new X();
x.m();
X }
}
Y2 fst(X,Y1)
X Y1

Fig. 12: The symmetry transformation between X and Y1

Yn When the symmetry transformation between X and Y1 is

broken (symmetry breaking), then symmetry
transformation (this is moment when the pattern begins to
Fig. 11: IS relationships between classes Y1, Y2 ,..., Yn occur):
and class Y
fst(X,Y1)
between each pair of the classes ({X,Y1},{X,Y2},...,{X,Yn}) becomes no-symmetry group (problem in the
exists the symmetry transformation according to the pattern)(Figure 13):
theorem of STIF. This set of the symmetry
transformations does not make a symmetry group. fst(X,Y1) + fst(X,Y2)
The proof for the above theorem is performed in a similar which can be marked with:
way as the proof of Theorem of the No-Symmetry Group
realised by the HAS relationship of the Class diagram. fnsg(X,Y)
fnsg(X,Y)
We mark the No-Symmetry group with: Y1
X
fnsg (X,Y)
Y2
The No-Symmetry group consists of the set of the
symmetry transformations between pairs (X,Y1), (X,Y2 )
,..., (X,Yn), for which is not defined equivalence relation.

fnsg (X,Y) = fst(X,Y1) + fst(X,Y2),..., + fst(X,Yn),

Yn
 2. The symmetry group, which consists of the set of the
symmetry transformations between concrete image (Y)
and its abstract image (Y’):
Fig. 13: The no-symmetry group between X and Y
fsg(Y,Y’) = fst(Y1,Y’) + fst(Y2,Y’)
Continued example:
fst(X,Y’)
class X // fnsg(X,Y) = fst(X,Y1) + fst(X,Y2)
{ Y1 y1; X
Y’
Y2 y2;
X() {y1 = new Y1(); y2 = new Y2();}
void m() fsg(Y,Y’)
{ if (condition1)
y1.m();
else
y2.m();
} Y1 Y2
}

class Y1
{ void m() {…}} Fig. 14: The symmetry transformation between X and Y’
class Y2
and symmetry group between Y and Y’
{ void m() {…}}
Based on the aforementioned, the symmetrisation process
class Main (Figure 15) can be represented as follows:
{
public static void main(String arg[])
{ X x = new X(); fnsg(X,Y) -> fst(X,Y’) + fsg(Y,Y’)
x.m(); Definition PT1: The Design pattern is the symmetrisation
} process (fsp) that no-symmetry group of originale (X) and
}
its image (Y) transforms to:
a) the symmetry transformation between the original (X)
After that, the symmetrisation process happens, which
and its abstract image (Y’) and b) the symmetry group of
transforms no-symmetry to symmetry group (how the
the concrete image (Y) and its abstract image (Y’) .
pattern is occuring). The No-Symmetry group:
In this sense, the symmetrisation process SP can be
fnsg(X,Y) represented as the following pattern:
is being transformed into (solution in pattern) (Figure 19): SP ( fnsg(X,Y) , fst(X,Y’)  fsg(Y,Y’) )
1. the symmetry transformation between the original (X)
Here is another definition that easily explains what the
and its abstract image (Y’):
design patterns are:
fst(X,Y’)
Definition PT2 : A Design pattern is a process which
and
transforms the no-symmetry structure (problem) into the
symmetry structure (solution).
SOLUTION
PROBLEM

fst(X,Y’)

Y1
SP X Y’
X
fsg(Y,Y’)
Y2

fnsg(X,Y) Y1 Y2

DESIGN PATTERN
Fig. 15: The design patterns as the symmetrisation process
class X // fst(X,Y’) + fsg(Y,Y’) If we want to ensure that the process of the construction is
{ Y y;
independent of the presentation we introduce a new
X(Y y1) {y1 = y;}
void m() element Builder (abstract image) which together with the
{ y.m(); Director establishes symmetry transformation:
}
}
fst(Director,Builder)
abstract class Y’ whereas with the ConcreteBuilder element establish
{ abstract void m(); } symetry group:
class Y1 extends Y fsg(ConcreteBuilder,Builder)
{ void m() {…} } Accordint to PT1 Builder pattern has a form:
class Y2 extends Y fnsg(Director,ConcreteBuilder) ->
{ void m() {…}} fst(Director,Builder) + fsg(ConcreteBuilder,Builder)
class Main
{ public static void main(String arg[]) Bridge pattern provides an independent abstraction of
{ X x; an operation from its implementations. One abstraction of
if (condition1) an operation can have more implementations
x = new X(new Y1());
else (realisations). This pattern has the following elements:
x = new X(new Y2()); Abstraction (original) and ConcreteImplementor (image),
x.m(); which is represented by the set of elements:
}
ConcreteImplementor1,ConcreteBuilder
}
concreteImplementor ,..., ConcreteBuildern.
Between Abstraction and ConcreteImplementor no-
9. The examples of the design pattern symmetry group (problem in the pattern), is formed,
explained by the symmetry concepts which can be marked:

Here, we will explain the Builder and Bridge GOF fnsg(Abstraction,ConcreteImplementor)

patterns by the symmetry concepts.
Builder pattern provides an independent construction of
a complex object from its representation, so that the same
construction process can create different representations.
The construction process should not be changed when
adding a new representation. This pattern has the
following elements: Director (original) and
ConcreteBuilder (image), which is represented by the set
of elements: ConcreteBuilder1, ConcreteBuilder2 ,...,
ConcreteBuildern. Between Director and ConcreteBuilder
a no-symmetry group (problem in the pattern), is formed,
which can be marked:
fnsg(Director,ConcreteBuilder)
The Director, which is responsible for the construction
process, is connected to an n different ConcreteBuilder,
where each ConcreteBuilder is connected to a concrete
representation of the product. If we inserted a new
ConcreteBuildera we would have to change the structure
of Director. In this case we have to change a construction
process.
The Abstraction, which is responsible for the description
of the abstraction of operation, is connected with an n
different ConcreteImplementor(CI), where each
ConcreteImplementor provides concrete implementation
of operation (it gives n different implementations). If we
inserted a new ConcreteImplementora we would have to
change the structure of Abstraction, i.e. we would have to
change abstraction of operation.
If we want to ensure that abstraction of the operation is
independent of its implementation we introduce a new
element of the Implementer (abstract image), which
together with Abstraction element establish symmetry
transformation:
fst(Abstraction,Implementor)
whereas with ConcreteImplementor element establishes
symetry group:
fsg(CI,Implementor)
Accordint to PT1 Bridge pattern has a following form:
fnsg(Abstraction,CI) -> fst(Abstraction,Implementor)
+ fsg(CI,Implementor)
In a similar way it can be explained, in whole or any part
all remains GOF patterns, which are presented in Table 1:

GOF patterns / Elements of pattern Original Abstract image Concrete image Comment [F1]: Profesore, ovde ste negde stvljali
Abstract Factory Client AbstractFactory ConcreteFactoryi slovo i na kraju naziva paterna.
Client AbstractProductA ProductAi
Client AbstractProductB ProductBi
Builder Director Builder ConcreteBuilder
Factory Method main Creator ConcreteCreator
Prototype Client Prototype ConcretePrototypei
Singleton Singleton
Adapter Client Target Adapter
Bridge Abstraction Implementor ConcreteImplementori
Composite Client Component Leaf
Client Component Composite
Composite Component Leaf
Composite Component Composite
Decorator Decorator Component ConcreteComponent
Decorator Component Decorator
Façade main Façade
Flyweight FlyweightFactory Flyweight ConcreteFlyweighti
Proxy Client Subject Proxy
Chain of Responsibility Client Handler ConcreteHandleri
Handler Handler ConcreteHandleri
Command Invoker Command ConcreteCommand
Interpreter Client AbstractExpression TerminalExpression
Client AbstractExpression NonterminalExpression
NonterminalExpression AbstractExpression TerminalExpression
NonterminalExpression AbstractExpression NonterminalExpression
Iterator Client Agregate ConcreteAgregate
Client Iterator ConcreteIterator
Mediator Colleague Mediator ConcreteColleaguei
Memento CareTaker Memento
Observer Subject Observer ConcreteObserver
State Context State ConcreteStatei
Strategy Context Strategy ConcreteStrategyi
Template Method main AbstractClass ConcreteClass
Visitor Client Visitor ConcreteVisitori
ObjectStructure Element ConcreteElementi

Table 1: Elements of GOF design patterns explain by concepts of our theory (Original, Abstract image, Concrete image)

10. Conclusion
If we look at previous attempts to formalize design
patterns, we can say that they mostly try to create the
formal languages (BPSL, DPML ,..., Lepus) which will
describe the design patterns. These languages are focused
on a precise definition and specification of solutions,
while less attention is given to a problem being solved.
This paper explains formally the design patterns as the
process of transformation (T) the problem into the
solution through the symmetry concepts (symmetry
transformations and symmetry groups). We have tried to
confirm formally the attitudes of Jim Copliena and Liping
Zhao which were the first to suggest a link between
patterns and symmetry concepts.
Our theory is derived on the base analysis of the design
pattern [1] in which we have observed the structure of
solutions which is common to the most of the GOF
patterns. Based on that structure we have defined the
structure of the problem and explained how to perform
the transformation of the structure of the problem into the
structure of the solution.
We have defined the theorem of the symmetry
transformation for the given injective function, where we
explained the cases when between the two states, after the
transformation, there is an equivalence relation. We have
shown the application of these theorems in class diagrams
and pointed out the cases in which the "function of
origination" is applicable. Thereafter, we have defined the
theorems of the symmetry group realized by the class
diagram and the theorems of the no-symmetry group
realized by the class diagram where we have shown the
cases in which the set of classes makes, or does not make
the symmetry group. At the end of the paper we have
described the design patterns by one program which is
explained with the symmetry concepts. The result of the
paper is two definitions of the design patterns:
Definition PT1: The Design pattern is the symmetry
process (fsp) that no-symmetry group of origin (X) and its
image (Y) transforms to:
a) the symmetry transformation between the original (X)
and its abstract image (Y’) and b) the symmetry group of
the concrete image (Y) and its abstract image (Y’) .
Definition PT2 : The Design pattern is the process which
transforms the no- symmetry structure (problem) into the
symmetry structure (solution).
We think that this study formally explains what the
patterns are and when and how patterns are occurring.
According to the definition of symmetry given by Rosen
[6]: Symmetry is immunity to a possible change, the aim
of this study is to define a formal basis for making the
stable and sustainable software systems, based on
symmetry concepts, which will be able to change but will
also be immune to change. We consider that further
development of software systems should seriously
consider the concepts of symmetry because they exist in
the bases of all conservation laws (Conservation of
Energy, Conservation of Linear Momentum,
Conservation of Angular Momentum, ...). In this sense,
Noether's Theorem, states that there is a one-to-one
correspondence between conservation laws and
symmetries of differentiable physical systems. Nobel
laureate PW Anderson, said: "It is only slightly
overstating the case to say that physics is the study of
symmetry." We believe that in times to come,
“Conservation Laws of the software system“ and the
study of symmetry in this context, will bring software
systems and the physical systems close togather and
enable the use the considerable knowledge from the
physics in the software engineering.

References

[1] GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J.

1994. Design Patterns. Addison-Wesley Professional, Reading,
Massachusetts.
[2] TOUFIK, T. 2007. Design Pattern Formalisation
Techniques, IGI Publishing, Hershey, Pennsylvania.
[3] FOWLER, M.2006: Writing software patterns.
http://www.martinfowler.com/articles/writingPatterns.html
[4] KAMPFFMEYER, H., ZSCHALER, S. 2007: Finding the
Pattern You Need: The Design Pattern Intent Ontology, in
MoDELS, Springer-Verlag, volume 4735/2007, 211-225.
[5] COPLIEN, J., ZHAO, L. 2001. Symmetry Breaking in
Software Patterns, LNCS, Springer-Verlag, volume
2177/2001,37-54.
[6] ROSEN, J. 2008. Symmetry rules – how science and nature
are founded on symmetry, Springer-Verlag Berlin Heidelberg.
[7] CHRISTOPHER, A., ISHIKAWA S., SILVERSTEIN, M.,
JACOBSON, M., FIKSDAHL-KING, I., ANGEL, S. A Pattern
Language. Oxford University Press, New York, 1977.
[8] COPLIEN, J. 1996: Software Patterns, SIGS, New York.
[9] OMG. 2010. Unified Modeing Language Specification,
version 2.3,
http://www.omg.org /spec/UML/2.3/Superstructure/PDF.

View publication stats