F2OAS: Towards a standard framework to organizing software architectural styles

ISSN:2249-5789
Gholam Ali Nejad HajAli Irani et al, International Journal of Computer Science & Communication Networks,Vol 2(1), 87-92

F2OAS: Towards a Standard Framework to Organizing Software
Architectural Styles
GholamAli Nejad HajAli Irani
Faculty of Engineering, University of Bonab, Iran


Abstract
The selection or development of software architectural
style is one of the most important issues in the software
architecture. The number and variety of architectural
styles are rising. There is not any proper and standard
classification to organizing software architectural
styles.
In this paper, a standard organization (F2OAS) to
all software architectural styles has been provided. To
obtain this aim, all previous classifications and
categories for architectural styles have been collected.
Then by analysis of existing approaches, all different
aspect of a standard organization has been
investigated. Finally a new process model to
developing a standard organization has been provided.
F2OSA can help software architects to develop very
powerful and robust architectures and the process of
developing software architecture be done in less time.
F2OAS can be used in software product line
architecture or any intelligence and automatic software
architecture projects.
Keywords: Software Architecture, Architectural Styles

evaluating and documentation

1. Introduction
The most important steps in developing large-scale
software is developing there architecture. Developing
large-scale software systems need to provide a suitable
and robust architecture. So providing a proper
architecture for large-scale software systems is very
critical.
Software Architecture is the fundamental
organization of a system, embodied in its components,
their relationships to each other and the environment,
and the principles governing its design and evolution
[10].
There are many definitions for software architecture.
In [22] other definitions and analysis of their elements
cab be found.
Different styles of architecture shows the differences
between different designs.

Styles can be assumed like a set of rules on
architecture. Software architecture style is set of rules
for design various types of components and connectors
in the architecture, with internal or external restrictions
on how their composition and topology of them.
Architectural styles have many definitions like
architecture. In [17], [19], [7] and [2] some definitions
can be found.
Since a variety of architectural styles is presented.
The first classification for architectural styles has

provided by Garlan and Shaw in [19]. Data Centered
Styles, Data Flow Styles, Virtual Machine Styles are
examples of the classification.
A good software architect to developing a proper
architecture, should be familiar all architectural styles
that exist in him/his scope.
In other words, an architect should have sufficient
mastery of architectural styles and advantages,
disadvantages and applications, each of them.
New software architectural styles are provided every
day by any groups and number and variety of them are
being larger. So a good architect to learn the new
provided architectural styles, should collect and
investigate all new styles in a period of time, for
example in every month.
Therefore the problems can be expressed as follows.
1.

2.
3.

4.

With the increasing of architectural styles, there is
no central control unit for them and there is a
scattering on provided architectural styles.
Lack of a complete catalog of software
architectural styles.
There is no single method of selection and
evaluation for the styles offered by different

groups.
To provide a new software architectural style, there
is no standard documentation method that to
follow.

87


ISSN:2249-5789
Gholam Ali Nejad HajAli Irani et al, International Journal of Computer Science & Communication Networks,Vol 2(1), 87-92

So, a new standard organization is necessary.

2. Investigating previous approaches
Different categories for architectural styles have
been presented. The categories can be classified in two
types. Some of the methods were categorized
architecture styles based on their style type. We named
them “Subject Base classifications”. Firstly, provides
categories of styles types and then put architectural
styles in these categories. Some other classification,
categorize styles based on system types. We named
them ”System Base Classifications”. In the reminder
two types of categories have been described.

2.1 Subject Base classifications
Classification that put architectural styles based on
style types in the different groups.
Based on this approach, firstly a classification of
styles types has been provided and then all styles put in

these types.
[19], [20] and [8] are examples of this type. Latest
classification is Component and connector method in
[7]. In this classification, specific concept such as
viewtype is presented. And three types of viewtypes
that named Module viewtype, Allocation viewtype and
Component and connector viewtype is given which is
shown in table 1. This classification is also a type of
subject base classification.
Table 1. Component and Connector classification [7].
Module Viewtype
 Decomposition
 Uses
 Generalization
 Layered
Allocation Viewtype
 Deployment
 Implementation
 Work Assignment

Component and
Connector Viewtype
 Pipe-and-Filter
 Shared-Data
 Publish-Subscribe
 Client-Server
 Peer-to-Peer
 CommunicatingProcesses

2.2 System Base classifications

In some books and papers different styles are
presented for specific systems. In principle, these
groups are not discussed as categories or classification
for architectural styles. But some architectural styles
are presented for a particular system.
For example the first paper in [6], categorized style
based on system types which is shown in table 2.
Other types of this type of classification are:
[16] for distributed processig systems, [13] for
Enterprise Information Systems, [9] for Adaptable SelfHealing Dependable Systems, [21] for ecommerce
systems, [12] for Resource Management systems and
etc.

In addition, all systems types which were provided
styles for them are as following:
 Adaptable Systems
 Network Based & Distributed Systems
 Electronic Commerce Systems
 Event-Based Systems
 Information Systems
 Knowledge Based Database Systems
 Real Time Systems
 Web Services & Web Based Systems
 Resource Management Systems
 Interactive Systems
Questions that are raised in this context are that can
these methods solve the problems? Certainly has not
solved. Subject based or system based classifications
will not solve the problems completely.
Consequently, other factors should be considered in

these categories. For example there are not any
standard for evaluating or documenting architectural
style. In addition all provided styles have not been
collected and categorized.
Therefore to solve above mentioned problems, a
standard organization to all architectural style is
needed.
Table 2. System base classification [6].
From Mud to Structure
 Layers
 Pipes and Filters
 Blackboard
Distributed Systems
 Broker
 Pipes and Filters
 Microkernel

Interactive Systems
 Model-ViewController (MVC)
 PresentationAbstraction-Control
(PAC)
Adaptable Systems
 Microkernel
 Reflection

3. Towards a new standard (F2OAS)
In this part a new method to classify and organize all
architectural styles has been provided that named
F2OAS. F2OAS is combination of previous methods
and a style will classify from both style type and

system type. In F2OAS, all aspects of software
architecture and architectural styles will be considered.

3.1 Inputs and outputs of F2OAS
The first point to provide a standard for organizing
styles is that, what the inputs of standard are and what
the outputs to the architects are.
First of all, system type and style type are necessary
as an input. May be for one type of style and one type
of system there is more than one style candidate.

88


ISSN:2249-5789
Gholam Ali Nejad HajAli Irani et al, International Journal of Computer Science & Communication Networks,Vol 2(1), 87-92

So, software architects must give quality attributes
of their requested style as well. Therefore inputs and
outputs of F2OAS will be as in figure 1.
Type of System

Type of Style

F2OAS

Quality
attributes of
requested style

Style
consistent
with the
demands of
the architect

Figure 1. Inputs and outputs of F2OAS.

same way, Perspectives are the perspectives of
architects that want to choose a style. So perspectives
of each architect can be the style types. Therefore a
standard category can be as figure 3.
Perspectives

Style Types

Observers

System Types

Figure 3. Observers and Perspectives of new category.

4. Aspects of providing F2OAS
In this section, aspects and issues of providing a
standard organization for architectural styles have been
investigated. This standard must consider all aspect of
software architecture.
Firstly, system categories or system types should
consider and support by F2OAS and for any given
systems type, F2OAS must return a list of styles.

Secondly, styles types should consider and support
by F2OAS and for any given style type, F2OAS must
return a list of styles.
Thirdly, F2OAS must be able to give some quality
attributes and filter style list. To obtain this aim,
F2OAS must support all quality attributes and
evaluation methods of them.
Fourthly, F2OAS must have a standard method to
documenting architectural styles and all styles must
catalog based on that standard documentation.
Finally all aspect that F2OAS must consider and
support which are shown in figure 2.

5. F2OAS Structure
F2OAS should be two main parts. Firstly, a standard
category for all architectural style likes a table. This
category must support systems based and subject based
categories and must support all quality attributes.
Secondly, a standard catalog to documenting all
architectural styles. This catalog must include all styles
documenting with their evaluation methods.

5.2 Standard catalog
A catalog needs to document all architectural styles.
This catalog must consider all aspect of a style and
must be in related with the standard category.
Process of developing this catalog is described in
figure 4.

6. Process Model of F2OAS

To developing F2OAS, a process model such as
waterfall, phased model or unified process can be used.
The proposed process model of F2OAS is described as
following:
(For some steps instances of previous attempts has
been collected.)
Phased 1: To provide required standards.
Step 1: To provide a standard category for all
software system types
Such as: [1]
Step 2: To provide a standard category for all
architectural style types
Such as: [7] or [18].
Step 3: To provide a standard to documenting any
architectural styles
Such as: [7].
Step 4: To provide a standard category for all
software quality attributes
Such as: [5] or [2] or [3] or [4].

5.1 Standard category
Well-known standards like Zachman, examined
elements of system with two dimensions, Observer and
Perspective. Rows can be Observers and columns can
be Perspectives. Following the Zachman Framework, in
architectural styles Observers are the architects of
systems, so Observers can be systems types. With the

Phased 2: To provide a standard category and standard
catalog

Step 1: To provide a standard category for all
architectural styles
Such as: [13] or [15] or [11] or [14].

89


ISSN:2249-5789
Gholam Ali Nejad HajAli Irani et al, International Journal of Computer Science & Communication Networks,Vol 2(1), 87-92

Step 2: To provide a standard documentation catalog
for all architectural styles
Phased 3: To collect and documenting all architectural
styles and evaluation methods
Step 1: To collect and add all existing subject based
architectural styles
Step 2: To collect and add all existing system based
architectural styles
Step 3: To collect or provide an evaluation method
for any style

Phased 4: To provide guidelines to applications and
evolution of standard
Step 1: To provide a standard for developing new
style
Step 2: To provide evolution principles of standard

Figure 2. Aspects of developing F2OAS.

90

ISSN:2249-5789
Gholam Ali Nejad HajAli Irani et al, International Journal of Computer Science & Communication Networks,Vol 2(1), 87-92

Style :ODBC
Connection
System :C/S

Style :ODBC
Connection
System :C/S

=

Type :ODBC

Syntax:

+ ... +

Documentation of Style 1

+

=

=

Type :ODBC

Syntax:

Documentation of Style k

+ . . .+

+

+ . . .+

Figure 4. Process of developing standard catalog.

7. Conclusion and future works
F2OAS as a new standard has been proposed to
organizing all software architectural styles and a
process model has been provided based on all aspects
of software architecture and previous works and can be
a standard to developers of new styles.
F2OAS can defined as a widely project in any
research centers. F2OAS can be use in any large-scale
software development and any software product line

projects and software architects can develop
architecture in less time.
The approach of this paper can be used in any
aspects of software engineering. For example a
standard for business pattern, analysis pattern, design
patterns and etc can develop based on F2OAS
approach.

91


ISSN:2249-5789
Gholam Ali Nejad HajAli Irani et al, International Journal of Computer Science & Communication Networks,Vol 2(1), 87-92

8. References
[1] The ACM Computing Classification System, Publications
Dept.,
ACM,
Inc
,
2006,
see
/>
[14] C.S. Langdon, Information Systems Architecture Styles
and Business Interaction Patterns: Toward theoretic
correspondence, Information Systems and e-Business
Management, Springer Verlag, 2003

[2] S.T. Albin, the Art of Software Architecture: Design
Methods and Techniques, 2003.

[15] M.S. Mahmoud, M.M. Shaban, A Framework of
Architectural Styles for Distributed Business Information
Systems, IJICIS, Vol. 5, No. 1, July 2005

[3] H. Astudillo, Five Ontological Levels to Describe and
Evaluate Software Architectures, Departamento de

Informática, Universidad Técnica Federico Santa María
Avda.España 1680, Valparaíso, Chile, 2004

[16] Y. Morisawa, K. Inoue, K. Torii, Architectural Styles for
Distributed Processing Systems and Practical Selection
Method, 2002

[4] L. Bass, P. Clements, and R. Kazman, Software
Architecture in Practice, Second Edition, Addison-Wesley,
2003.
[5] P. Berander, L.O. Damm, J. Eriksson, T. Gorschek, K.
Henningsson, P. Jönsson, S. Kågström, D. Milicic, F.
Mårtensson, K. Rönkkö, P. Tomaszewski, Software Quality
Attributes and Trade-Offs, Blekinge Institute of Technology,
June 2005
[6] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad,
M. Stal, Pattern Oriented Software Architecture: A system of
Patters, Wiley Press, 1996
[7] P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers,
R. Little, R. Nord, J. Stafford, Documenting Software
Architecture, Addison Wesley, 2002.
[8] R.T. Fielding, Architectural Styles and the Design of
Network-based Software Architectures, 2000
[9] M.J. Hawthorne, D.E. Perry, Architectural Styles for
Adaptable Self-Healing Dependable Systems, 2005
[10] Recommended Practice for Architectural Description of
Software Intensive Systems. Technical Report IEEE P14712000, IEEE Standards Department, The Architecture
Working Group of the Software Engineering Committee,
September 2000.

[17] D.E. Perry, A.L. Wolf, Fundations of the study of
Software Architecture, ACM Sigsoft, Software Engineering
Notes vol 17 no 4, Oct 1992.
[18] J. Ryoo, H. Saiedian, A Sramework for classifying and
Developing Extensible Architectural Views, Article in
Press, Elsevier, 2005
[19] M. Shaw, D. Garlan, Software Architecture:
Perspectives on an Emerging Discipline, Prentice Hall,
1996.
[20] M. Shaw, P. Clements, Toward Boxology: Preliminary
Classification of Architectural Styles, Carnegie Mellon
University, Pittsburgh, PA 15213, 1996
[21] A. Widhani, S. Böge, A. Bartelt, W. Lamersdorf,
Software Architectures and Patterns for Electronic
Commerce Systems, University of Hamburg, Department
of Computer Science, 2002
[22] G. N. H. Irani, R. K. Dadashi, General Meta-Models to
Analysis of Software Architecture Definitions, International
Journal of Computer Science & Communication
Networks, Vol 1(3), 318-324, 2011

[11] J.H. Jahnke, D.M. German, J.P. Wadsack, Architectural
Patterns for Data Mediation in Web-centric Information
Systems, Department of Computer Science University of
Victoria, 2002
[12] M. Kircher, P. Jain, Pattern Oriented Software
Architecture: Patterns for Resource Management, Volume 3,
John Wiley & Sons, 2004
[13] M. Kolp, J. Mylopoulos, Architectural Styles for
Information Systems: An Organizational Perspective, 2001

92