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.
Trang 1F2OAS: Towards a Standard Framework to Organizing Software
Architectural Styles
GholamAli Nejad HajAli Irani
Faculty of Engineering, University of Bonab, Iran
Irani@Bonabetu.ac.ir
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
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 With the increasing of architectural styles, there is
no central control unit for them and there is a scattering on provided architectural styles
2 Lack of a complete catalog of software architectural styles
3 There is no single method of selection and evaluation for the styles offered by different groups
4 To provide a new software architectural style, there
is no standard documentation method that to follow
Trang 2So, 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]
Component and Connector Viewtype
Pipe-and-Filter
Shared-Data
Publish-Subscribe
Client-Server
Peer-to-Peer
Communicating-Processes
Module Viewtype
Decomposition
Uses
Generalization
Layered
Allocation Viewtype
Deployment
Implementation
Work Assignment
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
Self-Healing 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]
Interactive Systems
Model-View-Controller (MVC)
Presentation-Abstraction-Control (PAC)
Adaptable Systems
Microkernel
Reflection
From Mud to Structure
Layers
Pipes and Filters
Blackboard
Distributed Systems
Broker
Pipes and Filters
Microkernel
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
Trang 3So, software architects must give quality attributes
of their requested style as well Therefore inputs and
outputs of F2OAS will be as in figure 1
Figure 1 Inputs and outputs of F2OAS
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.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
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
Figure 3 Observers and Perspectives of new category.
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]
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]
Perspectives
Style Types
Observers
System Types
F2OAS
Type of System
Type of Style
Quality
attributes of
requested style
Style consistent with the demands of the architect
Trang 4Step 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
Trang 5Figure 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
Documentation of Style k
Style :ODBC Connection Type :ODBC System :C/S
Syntax:
Documentation of Style 1
Style :ODBC Connection Type :ODBC System :C/S
Syntax:
Trang 68 References
[1] The ACM Computing Classification System, Publications
Dept., ACM, Inc , 2006, see
http://www.acm.org/class/1998/ccs98.html
[2] S.T Albin, the Art of Software Architecture: Design
Methods and Techniques, 2003
[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
[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
P1471-2000, IEEE Standards Department, The Architecture
Working Group of the Software Engineering Committee,
September 2000
[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
[14] C.S Langdon, Information Systems Architecture Styles
and Business Interaction Patterns: Toward theoretic correspondence, Information Systems and e-Business
Management, Springer Verlag, 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
[16] Y Morisawa, K Inoue, K Torii, Architectural Styles for
Distributed Processing Systems and Practical Selection Method, 2002
[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