A Proposal of Reference Architecture for the Reconfigurable Software Development

1. The 24th International Conference on Software Engineering and Knowledge Engineering (SEKE 2012) A Proposal of Reference Architecture for theReconfigurable Software Development Evandro Luis Linhari Rodrigues Department of Electrical Engineering University of São Paulo - USP São Carlos - SP, Brazil evandro@sc.usp.br Frank José Affonso Department of Statistics, Applied Mathematics and Computation Univ Estadual Paulista - UNESP Rio Claro - SP, Brazil affonso.frank@gmail.com / frank@rc.unesp.br July / 2012

2. Main topics • Introduction; • Concepts and Definitions; • Related Work; • A Proposal of Reference Architecture; • Conclusions;

3. 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.

4. Introduction (cont.) • The Development of Reconfigurable Software needs: • Reconfigurable Software Development Methodology (RSDM); • Reconfigurable Execution Environment (REE); • Software engineering tool; • Architectural models;

5. 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.

6. Concepts and Definitions (cont.) • Reflection: Reflections Reflections Humans Software

7. Related Work • According to some authors, the reconfigurable software development is associated: • Flexible Architectural Model; • Automated Processes; • Software Engineering Tools;

8. 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.

9. A Reference Architecture (cont.) • Reconfiguration like “assembly line”; Uncertainties Process conducted by human

10. A Reference Architecture (cont.) • Reconfiguration like “assembly line”; Automated process

11. A Reference Architecture (cont.) • Model organized in packages:

12. 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.

13. 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.

14. A Reference Architecture (cont.) • The reflection moduleaims 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 metamodelis transferred to the source code generator module to create the new artifact.

15. 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);

16. 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 rulesFactoryis 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.

17. A Reference Architecture (cont.) • The configuration moduleaims 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.

18. A Reference Architecture (cont.) • The reconfiguration modulecan 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 (reconfiguratorpackage) between the dynamic compiler (dynamicCompilerpackage) and dynamic classloader(dynamicClassLoaderpackage); • The module functionalities aim to compile/recompile the artifacts software and upload its binary code in runtime (memory).

19. 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.

20. 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, “Managingcrosscutting 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, “Anadldealingwith 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.