Research Contributions on Adaptive Software Architectures: A Brazilian female perspective at UNICAMP Sheila K. Venero
Jane D. A. S. Eleutério
Cecília M. F. Rubira
Institute of Computing University of Campinas Campinas, SP, Brazil
Faculty of Computing Federal University of Mato Grosso do Sul Campo Grande, MS, Brazil
Institute of Computing University of Campinas Campinas, SP, Brazil
[email protected]
[email protected]
ABSTRACT The percentage of women in Computer Science in Brazil drops every year. In the Institute of Computing at the University of Campinas, we have a group, called Computing4all, that aims to increase diversity in Computer Science. Similarly, in the area of Software Architecture, the number of women remains disproportionately small. In particular, our former predominantly male research group has started to grow in its diversity, three girls are now part of our team. This paper presents three recent approaches developed by female graduate students in the research area of software architecture. These solutions apply the principles of self-adaptive systems and autonomic computing to achieve adaptation in the development of Dynamic Software Product Lines and Workflow Management Systems.
CCS Concepts •Software and its engineering → Software architectures; Model-driven software engineering; Software product lines; •Computer systems organization → Selforganizing autonomic computing; Dependable and faulttolerant systems and networks; •Applied computing → Business process management systems;
Keywords Software Architecture, Women in Computer Science, Selfadaptive Systems
1.
INTRODUCTION
Diversity is a fundamental feature of the workforce in business, especially in areas such as Computer Science. However in Brazil, although women represent 57.8% of higher education enrollment 1 , in Computer Science the number of 1 From ”Relat´ orio Educa¸ca ˜o para todos no Brasil 2000-2015” [in Portuguese], available on http://portal.mec.gov.br
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from
[email protected].
ECSAW ’16, November 28-December 02, 2016, Copenhagen, Denmark c 2016 ACM. ISBN 978-1-4503-4781-5/16/11. . . $15.00
DOI: http://dx.doi.org/10.1145/2993412.3004851
[email protected]
women has decreased from 24 % to 15% from 2002 to 2012 [16]. In 2016, at the University of Campinas (UNICAMP), women represent 42.8% of enrollments in higher education courses, but this number drops to 17.6% considering only the courses of Computer Science and Computer Engineering [7]. In order to increase the diversity in the Institute of Computing (IC) at UNICAMP, we have a group called Computing4All 2 that is committed to increasing not only the number of women in Computer Science but also of Black, Hispanic, Indian people and all other minority groups. According to [18], feminine expertise can bring concrete advantages in the creative process of architecting software. Nevertheless, considering the area of Software Architecture in Brazil, the number of women remains disproportionately small. At the industry, most of software architects are men. At the academia, there are some female researchers, but the number can still be considered low. In particular, in the Institute of Computing at UNICAMP, a research group focused on software engineering and dependability has been working on fault-tolerant software architectures for more than 20 years. More recently, women researchers joined the group which was essentially composed of men. This paper describes three architectural solutions recently developed by female students of our group. These solutions are related to software architectures for developing adaptive systems. The three architectures are based on the reflection pattern where the managing system (meta-level) deals with the adaptation logic, and the managed system (base-level) deals with the application logic. Moreover, the approaches apply the MAPE-K autonomic loop to perform dynamic adaptation. The first approach is a Dynamic Software Product Line (DSPL) infrastructure, called ArCMAPE, that supports a family of software fault tolerance techniques based on design diversity applied to Service-Oriented Architectures (SOA) [15]. The second approach is also a DSPL-based solution, called ISALYNE. It is a model-driven infrastructure to support the creation of DSPL applications focusing on autonomic control loops. The last approach, called DW-SAAArch, is an architecture for Workflow Management Systems that provides means of flexibility to dynamically reconfigure sequences of activities in workflow instances, allowing the workflow adaptation at runtime. This paper is organised as follows: Section 2 describes some common background for the approaches. Section 3 shows the ArCMAPE approach developed by [15]. 2
http://computing4all.ic.unicamp.br/
Section 4 shows the ISALYNE approach developed by [11]. Section 5 presents DW-SAAArch developed by [22]. Finally, Section 6 presents the conclusion.
2.
BACKGROUND
In this section, we present some main concepts involved in the development of the approaches.
2.1
Self-Adaptive Systems
Systems able to adapt their behaviour or structure at runtime are called Self-Adaptive Software Systems (SASSs) [24]. Weyns et al. [24] use two general terms: the managed subsystem and the managing subsystem, to denote the constituent parts of a SASS. The Managed subsystem, also called base-level subsystem, performs the application logic that provides the system domain functionality [24]. The managing subsystem, also called reflective subsystem or meta-level, manages the managed subsystem, it is organised according to an autonomic control loop [24]. At runtime, the managing subsystem intercepts the running system when an adaptation is required [24]. The MAPE-K loop is an instance of a generic autonomic control loop that is composed of four main activities: (i) Monitoring - monitors gather and process environmental context information that is relevant to the adaptation process, by using sensors; (ii) Analyse - analysers correlate context information to infer from data of the runtime environment and the system behaviour; (iii) Planning - planners use the analysed data to define adaptation plans; and (iv) Execute - executors plan to adapt the managed subsystem and get the desired behaviour, using effectors. Besides, there is a knowledge base that supports the required information flow throughout the loop [24].
2.2
Dynamic Software Product Line
The Dynamic Software Product Lines (DSPLs) extend the concept of conventional SPLs, allowing the generation of software variants at runtime [4]. A Software Product Line (SPL) identifies variabilities and commonalities of software systems [3]. Variabilities and commonalities can be represented in the form of features. A feature model is represented as an organised hierarchically set of features with different relations between themselves and model all possible products of the SPL in a certain context. Unlike traditional information models, a feature model represents not only a single product, but a family of products in the same model [3].
Dependability and Software Fault Tolerance
According to Avizienis et al. [2], over the years, many means have been developed to attain the various attributes of dependability. Those ways can be grouped into four categories: (i) Fault prevention: how to prevent the occurrence or introduction of faults; (ii) Fault tolerance: avoid services failures in the presence of faults; (iii) Fault removal: minimising the number and severity of failures; and (iv) Fault forecasting: estimate the current number, the future incidence and the likely consequences of faults. When implementing software fault tolerance, there is the need to structure and isolate the multiple versions of the software (design diversity) for preventing the propagation of design faults, which otherwise may cause the failure of the system [2].
2.5
Process-Aware Information System (PAIS)
A Process-Aware Information System is a software system that provides mechanisms for managing and executing operational processes involving people, applications, and/or information sources according to process models [8]. PAIS separates the processing logic from the application code. Thus, at design time the processing logic has to be explicitly defined by a meta-model. At runtime, PAIS orchestrates the process and coordinates process applications and other resources [23]. It provides tools for process modeling, process execution, process monitoring, and user interaction. Examples of PAISs include Workflow Management Systems (WFMS), case handling tools, and service orchestration engines. A WFMS can be seen as a particular kind of PAISs with an emphasis on process automation rather than redesign and analysis [1].
3.
Model Driven Engineering
It conceives software development as transformation chains where higher level models are transformed into lower level models [25]. In Model Driven Engineering, reuse is mainly achieved by means of model transformations, which are built once but can be enacted for a variety of input models that yield different results [25]. Models are considered as firstclass entities, are used to capture every important aspect of a software system for a given purpose, and are not just auxiliary documentation artefacts; rather, they are source artefacts and can be used for automated analysis and/or code generation.
2.3
2.4
ARCMAPE: A SOFTWARE PRODUCT LINE INFRASTRUCTURE TO SUPPORT FAULTTOLERANT COMPOSITE SERVICES
A number of solutions use software fault tolerance techniques based on design diversity to create fault-tolerant composite services that leverage functionally equivalent services. Nevertheless, these solutions are not able to adapt themselves at runtime to cope with dynamic changes of user requirements and fluctuations in the quality of services (QoS).
3.1
Solution
ArCMAPE is a self-adaptive solution that leverages ideas from DSPL [4] to support fault-tolerant composite services [15]. The solution is based on a feature model, called FTFM, and a product line architecture model, called FT-PLA, to capture the common and variable features among some software fault tolerance techniques based on design diversity [2] applied to Service-Oriented Architectures (SOA). At runtime, ArCMAPE intercepts the running system and customises software fault tolerance techniques according to the needs of each client and its particular context.
3.1.1
FT-FM: Feature Model for Fault Tolerance applied to SOA
To identify features, Nascimento et al. analysed: (i) the domain knowledge of design diversity - e.g.[14, 5]; (ii) the various types of adjudicators and their operations [14]; and (iii) requirements that service compositions in general should
Figure 1: An excerpt of FT-PLA.
encompass (e.g. autonomic composition of services and QoSaware service compositions [17]). FT-FM, presented in [13], is a valid model and it encompasses 36 products - considering the various subtypes of adjudicators, omitted to avoid an unreadable feature model.
3.1.2
FT-PLA: PLA for Fault Tolerance applied to SOA
Nascimento et al. adopted the FArM method (FeatureArchitecture Mapping) to map from features to a Product Line Architecture (PLA) [13, 19]. By iteratively refining the initial feature model, FArM enables the construction of a transformed feature model containing exclusively functional features, whose business logic can be implemented into architectural components [19]. In a simplified manner, FT-FM was transformed based on mutual dependencies between its features [13]. Figure 1 shows an excerpt of the resulting PLA for fault tolerance applied to SOA (FT-PLA). They have omitted architectural connectors and interface names for the sake of clarity.
3.1.3
Infrastructure and Architecture
As illustrated in Figure 2, ArCMAPE relies on a dynamic component framework and uses the principles of selfadaptive systems. The adaptation level, or meta-level, is independent of the application; thus, it can be reused across different domains. The meta-level relies on MAPE-K autonomic loop and leverages the FT-FM and FT-PLA models at runtime for reasoning on the fault tolerance adaptive behaviour. The M onitor Component collects details from the baselevel through Sensors. Sensors should log any significant changes that appear in the running system. The Analyse Component selects the most suitable features if an adaptation is required. The P lan Component identifies the set of software components to be (un)bound in order to adapt the running system in agreement with the requisition sent by the Analyse component. The Execute Component generates reconfiguration scripts on the fly in accordance with the adaptation plan sent by the Plan component. Effectors execute these scripts in order to finally instantiate the most adapted software fault tolerance technique. The fault tolerance level, also called base-level, encompasses the implementation of the FT-PLA, where are implemented both the mandatory features based on the FT-FM and the variable features based on the specific domain. This level is based on service-oriented architecture and service components can be added dynamically.
Figure 2: Overview of ArCMAPE.
3.2
Contributions
ArCMAPE allows leveraging a family of software fault tolerance techniques based on design diversity at runtime and instantiates the most suitable one by dynamic management of software variability. Preliminary results suggest that ArCMAPE is easily reused and customised and it does not introduce an excessive overhead to support the dynamic management of variability [15].
4.
ISALYNE: AN INFRASTRUCTURE TO SUPPORT AUTONOMIC CONTROL LOOPS IN DSPLS
Dynamic Software Product Lines (DSPLs) use dynamic variability to adapt itself to the environment or requirements changes. The use of DSPLs is a way to achieve self-adaptive systems. Most existing DSPL solutions do not use autonomic control loop, although some solutions perform the same loop activity implicitly.
4.1
Solution
ISALYNE (Infrastructure to Support Auto-nomic Control Loops in Dynamic Software Product Line), presented in [11], describes a solution to support the creation of applications based on DSPL[4], such as (i) a family of solutions for dependable DSPLs; (ii) a self-adaptive architecture for DSPLs; (iii) a model-driven infrastructure for developing DSPL, and (iv) a framework to support self-adaptation at runtime.
4.1.1
Feature Model for Dependable DSPLs
Regarding family of dependable DSPLs, the feature model [11], shown in Figure 3, represents variabilities and commonalities of the family of dependable DSPLs in a differentiated way to represent autonomic control loop activities [24] in order to achieve dependability [2]. Each phase, for example, Monitoring, was modelled as subdivided features that will compose its essence. As a result, Figure 3 shows the feature model of the dependable DSPL family. This feature model of dependable DSPL family provides two major variation points: (i) the selection of MAPE pattern - centralized or decentralized. Whether decentralized, the designer can choose one of the five decentralized MAPE patterns; and (ii) the selection of specificity
Figure 4: Overview of ISALYNE.
Figure 3: Dependable DSPLs feature model. for each MAPE activity. This featured model was modelled using solutions presented in [9, 10].
4.1.2
Infrastructure and Architecture
The ISALYNE infrastructure, shown in Figure 4, encompasses a set of process, methods, tools, and source code generation. The self-adaptive product line architecture consists of (i) components of managed subsystem; and (ii) MAPE-K components of managing subsystem. The generated product is also a framework, where managing subsystem components will be fulfilled with source code from ISALYNE and the managed subsystem components will be partially implemented. In other words, the created product will be composed of the full source code required by the managing subsystem and the structure (packages and files) and partial source code required by the managed subsystem. This model-driven infrastructure is implemented, and perform code generation according to COSMOS* [12] and Java programming language. COSMOS* component model is a generic platform-independent implementation model that uses object-oriented structures, such as interfaces, classes, and packages.
4.1.3
Framework and Support Tools
The ISALYNE solution also includes an extension of FeatureIDE plug-in for Eclipse, called ISALYNE-IDE, to model dynamic features [11, 20]. The feature model may contain static and dynamic compositions. For the static composition, decision-making is taken at design time, differently to the dynamic composition, which occurs at runtime. A dynamic composition is a relationship between dynamic features [4]. With ISALYNE-IDE, it is possible to specify the feature model, by defining some features as dynamic features. From the feature model created by the software architect
using ISALYNE-IDE plug-in, a XML file is generated. With the created XML file, this infrastructure creates a XML configuration file for mapping features and components and/or services, that will be implemented by the programmer. With both XML files and selected MAPE-K pattern, ISALYNE infrastructure generates a preliminary version of the selfadaptive product line architecture (PLA). These steps compose a semi-automatic process, which was proposed to provide to the software engineer a means to create DSPLs. For runtime, ISALYNE infrastructure also provides a framework to support self-adaptation [6]. This framework represents the managing subsystem which monitors and adapts the managed subsystem.
4.2
Contributions
Despite this study be an ongoing research, some contributions are identified. The creation of a family of DSPLs consolidates the understanding of how the solutions were implemented so far and what are their advantages and limitations. This solution provides focus on MAPE patterns and highlights the autonomic control loops, so that the software architect is able to select the most suitable DSPL techniques at design time in accordance with its domain, project needs, or requirements.
5.
DW-SAAARCH: AN ARCHITECTURE FOR DYNAMIC SELF-ADAPTATION IN WORKFLOWS
Workflow Management Systems (WFMS) are tools that allow companies to control and support their business processes. Traditional WFMSs usually work with well-structured, predictable and repetitive processes. However current business processes, due to their complexity and dynamism, are often required to be flexible in order to reflect foreseeable or unforeseeable changes in the environment. One of the drawbacks of these workflow platforms is that they usually cannot adapt their processes dynamically according to new or unexpected situations.
5.1
Solution
DW-SAAArch, presented in [22], is an architecture for workflow management systems. It provides means of flexibility to adapt processes at the business logic level. Busi-
ness logical adaptations treat structural aspects such as reconfiguring the sequence of the workflow according to some knowledge by adding or removing new activities in order to support foreseen and unforeseen changes or exceptional behaviour. [22] treats workflow adaptation as a knowledgeintensive activity because it is a task that requires a lot of knowledge and experience. Thus, the architecture uses intelligent agents and follows the autonomic MAPE-K loop for making decisions at runtime aiming to solve unexpected behaviour during process execution. DW-SAAArch solution, shown in Figure 5, follows the structure of a self-adaptive system and it is separated in a meta-level and a base-level. Thus, there is no need to modify the structure of a common workflow enactment service because the adaptation is made in the meta-level so it is transparent to the workflow engine located in the base-level.
5.1.1
Meta-Level
The meta-level comprises the Adaptation Layer which is composed of a monitor agent, an adapter agent, and an executor agent. The monitor agent is in charge of monitoring workflow instances and their operational environment checking the enforcement of rules and/or constraints, verifying inputs and outputs of tasks, among other tasks. It has a self-manager and a context manager. The self-manager acquires the current status of the executing instance. The context manager interprets the acquired context information of the executing instance and represents it in a context model interpretable for the monitor. Process mining techniques can be used to discover new context information. The adapter agent is in charge of making the adaptation itself, it makes decisions and reasons to solve problems and achieve goals. It creates an action plan using the knowledge repository to deal with new situations, this action plan is first simulated to check inconsistencies and later it is suggested to a domain expert who will approve the proposal or further adapt it, so the proposed solution can be learned. The adapter agent comprises the analyzer, the planner, and the simulator which are divided according to their capabilities or functions. The executor agent achieves the last stage of the adaptation, it makes the process definition: it creates a computerised representation of the process that will be interpreted by the workflow enactment service in the base level.
5.1.2
Figure 5: DW-SAAArch:An Architecture for Dynamic Self-adaptation in workflows
5.1.3
Knowledge Repository
The core element of the architecture is the knowledge repository. It is a shared repository that centralises updated information and knowledge about a specific domain. It contains the business goals, business rules, case data (updated information about current workflow instances), a process repository (set of activities that can be chosen at runtime), and other external knowledge repositories related to the business domain.
5.2
Contributions
DW-SAAArch allows self-adaptation in workflow instances at the business logic level. It provides means of flexibility to dynamically adapt the workflows during runtime. [21] claims that the usage of knowledge-based approaches and cognitive techniques allow agents to make better decisions in order to adapt workflow instances, in both the self and its context. To validate this solution, a proof of concept was conducted in a nursing domain [21]. A real nursing scenario was selected to show the practical applicability of the proposed architecture. The results have shown that the solution successfully supports business logical adaptations in nursing workflows.
Base-Level
In the base-level are created the new configurations to execute the adaptations in the concrete workflow. The Instance M anager Layer interprets process description, concretizes and executes the adapted workflow instance calling appropriate applications from the Acquisition and Implementation Layer. This layer is composed of a workflow enactment service that creates and controls instances of the process, scheduling tasks and invoking applications and participants of the workflow. The Acquisition and Implementation Layer comprises the acquisition and implementations mechanisms. These mechanisms may be manual, semi or fully automatic. It is composed of heterogeneous applications for interaction with human users and for processing operations within a workflow process.
6.
CONCLUSIONS
We believe that diversity in Computing can produce more creative software solutions that meet the needs of all the population. Bringing experiences, opinions, and judgements of men, women, Black, White, Indian people, and others will enrich the products and produce more innovative products. In the past, the role of women in Computing was much larger than today. We claim that actions such as empowering women to consider careers in technology, creating mentor programs, promoting more opportunities for women and eliminating gender stereotypes can reverse the current situation. In particular, this paper presents three contributions in the software architecture area developed by female graduate students who have recently joined our research group at the Institute of Computing at UNICAMP. The proposed so-
lutions are related to software architectures for developing adaptive systems. The first approach dynamically composes services attending different requirements of fault tolerance techniques. The second approach aims to support the creation of self-adaptive systems using DSPL techniques. The last approach provides means to adapt workflow instances according to new circumstances or unexpected behaviours during their execution.
[13] A. S. Nascimento, C. M. F. Rubira, R. Burrows, and F. Castor. A Model-Driven Infrastructure for Developing Product Line Architectures Using CVL. In Proc. of SBCARS, pages 119–128. IEEE, 2013. [14] A. S. Nascimento, C. M. F. Rubira, R. Burrows, and F. Castor. A systematic review of design diversity-based solutions for fault-tolerant SOAs. In Proc. of EASE, page 107. ACM Press, 2013. [15] A. S. Nascimento, C. M. F. Rubira, and F. Castor. ArCMAPE: A Software Product Line Infrastructure 7. ACKNOWLEDGMENTS to Support Fault-Tolerant Composite Services. In This work has been partially supported by project DEVASSES Proc. of HASE, pages 41–48. IEEE, 2014. (PIRSES-GA-2013-612569), Faepex-Unicamp, Capes, and [16] A. C. Oliveira, M. M. Moro, and R. O. Prates. Perfil CNPQ. feminino em computa¸ca ˜o: An´ alise inicial. In Proc. of CSBC-WEI, pages 1465–1674, 2014. [in Portuguese]. 8. REFERENCES [17] M. P. Papazoglou, P. Traverso, S. Dustdar, and F. Leymann. Service-oriented computing: State of the [1] W. Aalst. Process-Aware Information Systems: art and research challenges. Computer, 40(11):38–45, Design, Enactment and Analysis. Wiley & Sons, 2009. 2007. [2] A. Aviˇzienis, J.-c. C. Laprie, B. Randell, and [18] M. Razavian and P. Lago. Feminine expertise in C. Landwehr. Basic concepts and taxonomy of architecting teams. IEEE Software, 33, 2016. dependable and secure computing. IEEE Trans. Dependable Secure Comput., 1(1):11–33, 2004. [19] P. Sochos, M. Riebisch, and I. Philippow. The Feature-Architecture Mapping (FArM) Method for [3] D. Benavides, S. Segura, and A. Ruiz-Cort´es. Feature-Oriented Development of Software Product Automated analysis of feature models 20 years later: Lines. In Proc. of ECBS, pages 308–318. IEEE, 2006. A literature review. Information Systems, 35(6):615–636, 2010. [20] T. Th¨ um, C. K¨ astner, F. Benduhn, J. Meinicke, G. Saake, and T. Leich. FeatureIDE: An extensible [4] N. Bencomo, S. Hallsteinsen, and E. S. de Almeida. A framework for feature-oriented software development. View of the Dynamic Software Product Line Science of Computer Programming, 79:70–85, 2014. Landscape. Computer, 45(10):36–41, 2012. [21] S. K. Venero. Dw-saaarch: A reference architecture for [5] P. H. S. Brito, C. M. F. Rubira, and R. de Lemos. dynamic self-adaptation in workflows. Master’s thesis, Verifying Architectural Variabilities in Software Fault Institute of Computing, University of Campinas, Tolerance Techniques. In Proc. of WICSA/ECSA, Brazil, November 2015. pages 231–240. IEEE, 2009. [22] S. K. Venero and C. M. F. Rubira. An architecture for [6] J. C. Casquina, J. D. A. S. Eleut´erio, and C. M. F. dynamic self-adaptation in workflows. In Proc. of Rubira. Adaptive Deployment Infrastructure for SERP, pages 35–41, July 2015. Android Applications. In Proc. of EDCC, pages 218–228, 2016. [23] B. Weber, S. Sadiq, and M. Reichert. Beyond rigidity–dynamic process lifecycle support. Computer [7] COMVEST. Estatisticas comvest 2016. [in Science-Research and Development, 23(2):47–65, 2009. Portuguese]. [24] D. Weyns, B. Schmerl, V. Grassi, S. Malek, [8] M. Dumas, W. Aalst, and A. Hofstede. Process-Aware R. Mirandola, C. Prehofer, J. Wuttke, J. Andersson, Information Systems: Bridging People and Software H. Giese, and K. M. G¨ oschka. On Patterns for through Process Technology. Wiley & Sons, 2005. Decentralized Control in Self-Adaptive Systems. [9] J. D. A. S. Eleut´erio, F. N. Gaia, A. Bondavalli, Lecture Notes in Computer Science, 7475:76–107, P. Lollini, G. N. Rodrigues, and C. M. F. Rubira. 2013. Dependable Dynamic Software Product Line – a [25] X. Zhang and B. Møller-Pedersen. Towards correct Systematic Mapping Study. Technical Report product derivation in model-driven product lines. IC-15-04, Institute of Computing, University of Springer, 2012. Campinas, 2015. [10] J. D. A. S. Eleut´erio, F. N. Gaia, A. Bondavalli, P. Lollini, G. N. Rodrigues, and C. M. F. Rubira. On the Dependability for Dynamic Software Product Lines A Comparative Systematic Mapping Study. In Proc. of SEAA, pages 323–330, 2016. [11] J. D. A. S. Eleut´erio and C. M. F. Rubira. An Infrastructure to Support Autonomic Control Loops in Dynamic Software Product Lines. In Proc. of SERP, pages 23–26, 2015. [12] L. A. Gayard, C. M. F. Rubira, and P. A. de Castro Guerra. COSMOS*: a COmponent System MOdel for Software Architectures. Technical Report IC-08-04, Institute of Computing, University of Campinas, February 2008.
