A Proposal of Reference Architecture for the Reconfigurable

Report
The 24th International Conference on Software
Engineering and Knowledge Engineering
(SEKE 2012)
A Proposal of Reference Architecture for the
Reconfigurable Software Development
Frank José Affonso
Department of Statistics, Applied Mathematics and Computation
Univ Estadual Paulista - UNESP
Rio Claro - SP, Brazil
[email protected] / [email protected]
Evandro Luis Linhari Rodrigues
Department of Electrical Engineering
University of São Paulo - USP
São Carlos - SP, Brazil
[email protected]
1
July / 2012
Main topics
• Introduction;
• Concepts and Definitions;
• Related Work;
• A Proposal of Reference
Architecture;
• Conclusions;
2
Introduction
• Computational systems endowed with runtime
reconfiguration characteristics;
• Ability to incorporate customers’ emerging
needs;
• Reconfigurable software must attend many
development approach:
•
•
•
•
Object-Oriented;
Aspect-Oriented;
Service-Oriented;
Remote Method Invocation.
3
Introduction (cont.)
• The Development of Reconfigurable Software
needs:
• Reconfigurable Software Development Methodology
(RSDM);
• Reconfigurable Execution Environment (REE);
• Software engineering tool;
• Architectural models;
4
Concepts and Definitions
• The Computational Reflection can be defined as
any activity performed by a system on itself;
• The main objective is to obtain information
about its own activities, aiming to improve its
performance, introduce new capabilities
(features or functionality), or even solve its
problems by choosing the best procedure.
5
Concepts and Definitions (cont.)
• Reflection:
Reflections
Humans
Reflections
Software
6
Related Work
• According to some authors, the reconfigurable
software development is associated:
• Flexible Architectural Model;
• Automated Processes;
• Software Engineering Tools;
7
A Reference Architecture
• The Reference architecture model for the
reconfigurable software development such as
automated processes;
• This model represents a real solution
(abstraction), based on a particular domain
(reconfigurable systems) and experience
(patterns) to treat the runtime software
reconfiguration without the developers’
participation.
8
A Reference Architecture (cont.)
• Reconfiguration like “assembly line”;
Uncertainties
Process
conducted
by human
9
A Reference Architecture (cont.)
• Reconfiguration like “assembly line”;
10
Automated process
A Reference Architecture (cont.)
• Model organized in packages:
11
A Reference Architecture (cont.)
• The annotations module aims to assist the
software engineer in the definition of artifacts
reconfiguration level which are being developed:
• Metadata (annotation) indicating the reconfiguration
level supported by the artifact must be present;
• It is recommended that this module has a functionality
to verify if the annotations were inserted correctly.
12
A Reference Architecture (cont.)
• The state management module aims to preserve
the artifacts execution state;
• When a software artifact is selected for manual
or automatic reconfiguration, the information
contained in its current state must be preserved.
13
A Reference Architecture (cont.)
• The reflection module aims to perform the
artifacts "disassembly" to obtain structural
information (attributes) and behavior (methods):
• The artifacts are disassembled;
• A metamodel is instantiated;
• New information, according to the clients' interests,
are added to create a new metamodel;
• The new metamodel is transferred to the source code
generator module to create the new artifact.
14
A Reference Architecture (cont.)
• The source code generator module aims to
generate the software artifacts based on
metamodel (instantiated in reflection module);
• To execute this operation, the software engineer
must provide:
• An artifact template based on the architectural pattern
(logical layer, persistence layer, and others);
15
A Reference Architecture (cont.)
• The query and rules module aims to be
consulted by software artifacts in REE
repositories;
• When an artifact is developed and inserted into
the REE, an automatic mechanism rulesFactory
is responsible for disassembling this artifact and
creating rules set that describes the artifact
functionalities.
• These rules are stored in REE repositories and
reused when a search is performed.
16
A Reference Architecture (cont.)
• The configuration module aims to control the
size of software artifacts when the
reconfiguration is performed;
• The artifacts are developed to meet specific
requirements and to act in a specific domain;
• This module allows performing the growth
control in the artifacts size and a number of
adaptations.
17
A Reference Architecture (cont.)
• The reconfiguration module can be considered the
"orchestrator" of the model, since it performs call
and coordinates all the activities of the other
modules;
• This module must implement a "connection point"
as a system supervisor (reconfigurator package)
between the dynamic compiler (dynamicCompiler
package) and dynamic classloader
(dynamicClassLoader package);
• The module functionalities aim to
compile/recompile the artifacts software and upload
its binary code in runtime (memory).
18
Conclusions
• This work presented a proposal for reference
architecture model for the reconfigurable
systems development using automated
processes;
• Standardization should be adopted in the design
and development of reconfigurable systems;
• Reusability of the reference architectural model
and creation of concrete architecture model for
reconfigurable software development.
19
Main References
•
•
•
•
•
•
•
•
•
•
•
•
X. Hongzhen and Z. Guosun, “Retracted: Specification and verification of dynamic evolution of software
architectures,” Journal of Systems Architecture, vol. 56, no. 10, pp. 523 – 533, 2010.
P. Maes, “Concepts and experiments in computational reflection,” SIGPLAN Not., vol. 22, no. 12, pp. 147–155, Dec.
1987.
F. J. Affonso, “Metodologia para desenvolvimento de software reconfigurável apoiada por ferramentas de
implementação: uma aplicação em ambiente de execução distribuído e reconfigurável,” Tese de doutorado,
EESC/USP, maio 2009.
J. Whitehead, “Collaboration in software engineering: A roadmap,” in 2007 Future of Software Engineering.
Washington, DC, USA: IEEE Computer Society, 2007, pp. 214–225.
E. Y. Nakagawa, F. C. Ferrari, M. M. Sasaki, and J. C. Maldonado, “An aspect-oriented reference architecture for
software engineering environments,” Journal of Systems and Software, vol. 84, no. 10, pp. 1670 – 1684, 2011.
F. J. Affonso and E. L. L. Rodrigues, “Reflecttools: Uma ferramenta de apoio ao desenvolvimento de software
reconfigurável,” Revista Brasileira de Computação Aplicada, vol. 3, no. 2, pp. 73–90, 2011.
P. J. Clemente, J. Hernández, J. M. Conejero, and G. Ortiz, “Managing crosscutting concerns in component based
systems using a model driven development approach,” Journal of Systems and Software, vol. 84, no. 6, pp. 1032 –
1053, 2011.
H. Gomaa and M. Hussein, “Software reconfiguration patterns for dynamic evolution of software architectures,” in
Software Architecture, 2004. WICSA 2004. Proceedings. Fourth Working IEEE/IFIP Conference on, june 2004, pp. 79
– 88.
B. J. Williams and J. C. Carver, “Characterizing software architecture changes: A systematic review,” Information and
Software Technology, vol. 52, no. 1, pp. 31 – 51, 2010.
A. Navasa, M. A. Pérez-Toledano, and J. M. Murillo, “An adl dealing with aspects at software architecture stage,”
Information and Software Technology, vol. 51, no. 2, pp. 306 – 324, 2009.
A. L. Santos, K. Koskimies, and A. Lopes, “Automating the construction of domain-specific modeling languages for
object-oriented frameworks,” Journal of Systems and Software, vol. 83, no. 7, pp. 1078 – 1093, 2010.
R. Kazman, L. Bass, and M. Klein, “The essential components of software architecture design and analysis,” Journal
of Systems and Software, vol. 79, no. 8, pp. 1207 – 1216, 2006.
20

similar documents