A Survey on Different Software Architectural Styles

Goutham V Atreya, Govind S and Sandeep Ramalingam

7th Semester, Department of Information Science and Engineering

JSS Academy of Technical Education, JSS Campus
Uttarahalli-Kengeri Main Road, Bangalore – 60

Abstract — This paper highlights the importance of it is strictly described and commonly available, it is a pattern
Software architecture in the present IT industry scenario. It [4]. Numerous domains use Patterns, thereby building trust
focuses on different architectural styles and their suitability in and supporting reuse. The Patterns drive the design activity, as
existing projects. The paper provides an overall view of the they also come with a set of properties – the ultimate purpose
importance of Software Architecture in the present context. being, to meet a set of pre-required requirements.
The intricacies involved in the design issues are also Architecture description Languages (ADL) is used to
highlighted. describe a Software Architecture. Software Architecture is to
system developers, what Data Structures is to Programmers
Index Terms — Software architecture, Architectural styles, [7].
Patterns.

II. ARCHITECTURAL STYLES

I. INTRODUCTION
Software Architecture has organizational styles. This section
The Software Architecture (SA) of a program or a
covers the details regarding the various architectural styles.
computing system is a depiction of the system that helps in
understanding the behavior of the system. It is the structure or A. Layered Architecture
structures of the system, which comprises of software Layered Architecture is an architectural style that
elements, the externally visible properties of those elements, organizes the software hierarchically, each layer in the
and the relationships among them [1]. hierarchy providing service to the layer above it and serving as
The architecture of a software system defines that system in a client to the layer below it. A layer can be loosely defined as
terms of computational components and interactions among a set of (sub) systems with the same degree of generality.
these components. Components are things such as client- The layers architectural pattern helps to structure
servers, databases, filters, etc. [7]. applications that can be decomposed into groups of subtasks in
One can trace back the idea of software systems having which each group of subtask is at a particular level of
architectures to the date when one started thinking of abstraction [5].
modularizing programs (a kind of architectural style, in itself). The layered architectural style has been described as an
With growing complex demands of the system stakeholders, inverted pyramid of reuse where each layer aggregates the
the architecture design practice became well rooted in the responsibilities and abstractions of the layer directly beneath
overall development of the software system i.e. in the software it.
development process cycle. Although one recognizes the The common principles for designs that use the layered
importance of architecture, designing software architectures architectural style include:
remains a complex, poorly guided activity [8]. i. Abstraction: This style provides the functionality,
The importance of the Software Architecture stems from the while abstracting the roles and responsibilities of
desire to have better software development support. individual layers and their inter-relation.
Furthermore, Architecture models are a manifestation of the ii. Encapsulation: The layer boundaries are not exposed
early design decisions [1, 2] and a means of abstraction [1]. to the features such as data types, methods,
The concept of architecture is useful from a software safety implementation details, achieving the required
perspective as it can be used to impose a separation of encapsulation.
concerns between decisions about the architecture of a iii. Specify the services: Each layer has to specify a
software artifact versus the implementation [3]. distinct functionality. The behavior and flow of data
The most important among the architecture concepts is that within the layer boundaries are also to be specified
of Software Patterns [4]. The Pattern, in short, at the same in clear terms.
time a thing, which happens in the world, and the rule which iv. Reusable: There exists no dependencies between the
tells us how to create that thing, and when to create it. It is Lower layers and the upper ones; we can reuse them
both a process and a thing; both a description of a thing which in other scenarios.
is alive, and a description of the process which will generate v. Coupling between layers: Provide coupling,
abstractly, between layers to establish
that thing [5]. For Example, layered architecture is a call-and-
communication among them.
return style, when it defines an overall style to interact. When
 with new sets of data that inter-operate with these applications
Example: Layers in the Android Architecture being added every other day, it becomes difficult to access
data effectively as one encounter the problems of duplicate,
inconsistent data. One solution for this is to adapt the
Repository or Data Centered Architecture style. It is applicable
in a distributed environment. It introduces a repository
manager which sends notification of data creation or
modification to the software components [2].
The repository retrieves the data and maps it to the entity
model from the business logic that acts on the model, thereby
mediating between the data source and the business of the
application. It queries the data source for the data, maps the
data from the data source to a business entity and changes
persists in the business entity to the data source. It separates
the business logic from the interactions with the underlying
data source or Web service. This kind of separation has the
following advantages [9].
i. It centralizes the data logic or Web service access
logic.
ii. It provides a substitution point for the unit tests.
iii. It provides a flexible architecture that can be adapted
as the overall design of the application evolves
[10].
Figure 1 – Android Layered Architecture

Figure1 shows the layered architecture of the Android

Operating System. It is a software stack of different layers
where each layer is a group of several different components
[13].
The basic layer is the Linux kernel on which the whole of
Android OS is built on (version Linux 2.6 kernel). This acts as
an abstraction between the hardware and the software layers.
The next layer is the native libraries which enables the
device to handle different types of data. These are written in C
or C++ and are specific for particular hardware.
Android Runtime layer consists of The Dalvik Virtual
Machine and the core java libraries. Figure 2 – Repository model
The Dalvik Virtual Machine is a type of Java Virtual
Machine used in Android devices to run the applications and is The following are some of the shortcomings of this model:
optimized for low processing power and low memory . The i. The associated systems must agree on the repository
DVM allows multiple instances of Virtual machine to be model, inevitably compromising on the specific
created simultaneously providing, security, and memory needs of each, adversely affecting performance.
management, isolation and threading support. ii. Evolution may be difficult when large volumes of
Application framework is the layer above the Android information is generated according to an agreed
Runtime and this the block where the applications directly model, and translating this to a newer model may
interacts with and this block includes Activity manager, be very expensive, difficult or impossible.
Window manager ,notification manager, package manager, iii. Activities such as backup, security, access control and
resource manager and content providers. recovery may be different for different associated
The topmost layer of the Android architecture is the systems, resulting in additional and unnecessary
Application layer that supports writing applications in two overheads [11].
modes; Native Android Apps and in the Third party Apps
thereby providing an endless opportunity to the developers. C. Pipes and Filters
In a Pipe and Filter style each component has a set of
inputs and a set of outputs. A component reads stream of data
B. Data centered architecture (Repositories)
on its inputs and produces stream of data on its outputs,
One sees that as the applications are becoming diverse, delivering a complete instance of result in standard order. This
 is accomplished by applying a local transformation to the input computation based on the context. The middle-end generates
streams and computing incrementally so output begins before another IR for the following backend. Most optimization
input is consumed. Hence components are termed “Filters” [5]. efforts are focused on this part.
The connectors of this style serve as conduits for the streams, The back end is responsible for translating the IR from the
transmitting outputs of one filter to inputs of another. middle-end into assembly code. The target instruction(s) are
chosen for each IR instruction. Register allocation assigns
processor registers for the program variables where possible.
The backend utilizes the hardware by figuring out how to keep
parallel execution units busy, filling delay slots, and so on.
Although most algorithms for optimization are in NP, heuristic
techniques are well-developed [14].

PUMP SINK

Figure 3- Pipes and Filters

.
i. The filter transforms or filters the data it receives via
the pipes with which it is connected. A filter can
have any number of input pipes and any number of
output pipes.
ii. The pipe is the connector that passes data from one
filter to the next. It is a directional stream of data,
which is usually implemented by a data buffer to
store all data, until the next filter has time to
process it.
iii. The pump or producer is the data source. It can be a
static text file, or a keyboard input device,
continuously creating new data.
iv. The sink or consumer is the data target. It can be
another file, a database, or a computer screen [6].
Figure 4- Compiler Design
Some examples of Pipe Filter architecture are as follows
Some problems encountered in Pipe and Filter architecture
Unix programs The output of one program can be linked to
includes that If a filter needs to wait until it has received all
the input of another program.
data (e.g. a sort filter), its data buffer may overflow, or it may
Compilers The consecutive filters perform lexical analysis,
deadlock. Also, If the pipes only allow for a single data type
parsing, semantic analysis, and code generation [4].
(a character or byte) the filters will need to do some parsing.
Compilers translate source programs in high-level languages
This complicates things and slows them down. If you create
to the machine code of the underlying hardware. A compiler
different pipes for different data types, you cannot link any
consists of three main parts: the frontend, the intermediate
pipe to any filter.
code optimizer, and the backend.
The front end checks whether the program is correctly
written in terms of the programming language syntax and D. Client Server Architecture
semantics. Here legal and illegal programs are recognized. The Client Server model is a computing model that acts as a
Errors are reported, if any, in a useful way. Type checking is distributed application which partitions tasks or workloads
also performed by collecting type information. The frontend between the providers of a resource or service, called servers
then generates an intermediate representation or IR of the and service requesters called clients. The client/server
source code for processing by the middle-end. characteristic describes the relationship of cooperating
The intermediate code optimizer is where optimization takes programs in an application. The server component provides a
place. Typical transformations for optimization are removal of function or service to one or many clients, which initiate
useless or unreachable code, discovery and propagation of requests for such services.
constant values, relocation of computation to a less frequently There are two types of client server architectures:
executed place (e.g., out of a loop), or specialization of
 2-tier architectures: In this architecture, client directly call typically blocks until a client connects with the
interacts with the server. This type of architecture may have server. Send and receive data using the read() and
some security holes and performance problems. Internet write() system calls.
Explorer and the Web Server works on two tier architecture.
Here security problems are resolved using Secure Socket
Layer(SSL) [7].
3-tier architectures: In this architecture, one more software
sits in between client and server. This middle software is
called middleware. Middleware are used to perform all the
security checks and load balancing in case of heavy load. A
middleware takes all requests from the client and after doing
required authentication it passes that request to the server.
Then server does required processing and sends response back
to the middleware and finally middleware passes this response
back to the client. If you want to implement a 3-tier
architecture then you can keep any middle ware like Web
Logic or WebSphere software in between your Web Server
and Web Browsers [7].
Some disadvantages of Client Server architecture are
Dependence: The client-server network model relies on a
functioning and available centralized server. If the centralized
server is removed from the system or goes down due to
problems, the entire network cannot function.
Expense: The central server computer must be powerful
enough to maintain and share resources with the other
computers on the network. This entails a substantial cost.
Congestion: Centralized servers must handle the majority of
the network traffic, as all queries for resources are directed
toward the server. This can cause network congestion on the
network and slow down response times for each computer
available.
Maintenance: Client-server networks often require a staff
with at least a single network administrator to manage and
maintain the equipment and the network. Other network Figure 5 - TCP – IP
operating systems, such as peer-to-peer network systems, do
not require a network administrator to maintain machines, as
this work is distributed among individual clients and their III. CONCLUSION
related machines [9].
Example: TCP-IP The set of problems for which architectures can be designed
The steps involved in establishing a socket on the client side is very less when compared to those that can’t be. One has
are as follows [9]: come a long way from the initial days of modularized
i. Create a socket with the socket() system call. programs to robot architecture. There is wide scope for
ii. Connect the socket to the address of the server using improvement in the design area of the software architecture.
the connect() system call.
iii. Send and receive data. There are a number of ways to
do this, but the simplest is to use the read() and
write() system calls.
The steps involved in establishing a socket on the server
side are as follows:
i. Create a socket with the socket() system call.
ii. Bind the socket to an address using the bind() system
call. For a server socket on the Internet, an address
consists of a port number on the host machine.
iii. Listen for connections with the listen() system call.
iv. Accept a connection with the accept() system call. This Figure 6 - Future Work
 Although certain architectural models add certain level of
abstraction to our code, they make the code more difficult to
understand for developers who are unfamiliar with the pattern
[10]. The industrial view differs in orders of magnitude from
the academic view, resulting in a dire need to fulfill the gap.
We define architecture explicitly, while conceptual
understanding alone might suffice at times. The design does
not speak about the ad-hoc solutions explicitly. The confusion
between Architectural Description Languages (ADL) used to
design Architectures and Programming languages like C, C++
used to design the complete system adds more fuel to the fire.
Furthermore, the variations defined during the design phase
are not sufficient always. There are always some errors that
creep into the system that do not arise until they are deployed,
which is not a flaw of the architecture, but a practical difficulty
which can’t be addressed in the architecture design efficiently.

REFERENCES
[1] L. Bass, P. Clements, and R. Kazman, “Software Architecture in
practice,” Second Edition, Pearson Education.
[2] N. Rozanski, E. Woods, “Systems Architecture: Working With
stakeholders using viewpoints and perspectives,” New York. Addison-
Wesley Professional, 2005.
[3] M. J. Squair, “Safety, Software Architecture and MIL-STD-1760”,
Senior safety consultant, Jacobs Australia, GPO Box 1976, Canberra,
ACT 2601, 2007.
[4] K. Henttonen, M. Matinlassi, E. Niemelä and T. Kanstrén,
“Integrability and Extensibility Evaluation from Software Architectural
Models – A Case Study,” in The Open Software Engineering Journal,
2007, Volume 1.
[5] F. Bushmann., R. Meunier, H. Rohnert, P. Sammerlad, and M. Stall,
“Pattern Oriented Software Architecture: A System of Patterns,” John
Wiley & Sons Ltd., 2009.
[6] K. Henttonen, M. Matinlassi, E. Niemelä and T. Kanstrén,
“Integrability and Extensibility Evaluation from Software Architectural
Models – A Case Study,” in The Open Software Engineering Journal,
2007, Volume 1.
[7] M. Shaw, and D. Garlan, “Software Architecture Perspectives on an
Emerging Discipline,” Pearson Education, 2009.
[8] P. Landa, “Shared Repository pattern,” Thomson-CSF Corporate
Research Laboratory, Osray, France.
[9] B. A. Fourozan, “Data Communications and Networking”, 3rd edition,
TMH, 2006.
[10] “Repository Model,” MSDN Library, Microsoft Publications
[11] I. Sommerville, “Software Engineering,” 8th Edition, Pearson
Education, 2009
[12] R. N. Taylor, A. Van der Hoek, “Software Design and Architecture -
The once and future focus of software engineering,” University of
California.
[13] D. Ehringer, “The Dalvik Virtual Machine Architecture,” March 2010.
[14] Alfred V. Aho and Jeffrey D. Ullman, “Principles of Compiler Design,”
Addison-Wesley, 2007.