While static program analyzers based on abstract interpretation implement precision-improving techniques to reduce false alarms, such as loop unrolling, their computational cost requires carefully devised heuristics for selective application. Manually designing such heuristics is non-trivial and error-prone, possibly leading to state explosion.This paper presents LOUPE, a novel end-to-end approach for automatically learning loop unrolling heuristics for static program analysis. Unlike previous data-driven methods, LOUPE leverages Graph Neural Networks (GNNs) to learn directly from graph-based program representations. To enable supervised learning, we use the static analyzer itself to automatically label training data. We implement LOUPE on top of FRAMA-C/EVA, an open source C static analyzer, and demonstrate that the best performing heuristic (GINE) outperforms the FRAMA-C/EVA built-in heuristic on real-world programs, reducing false alarms by 1.5x while improving analysis performance by 56%. Remarkably, GINE accurately predicts loop unrolling decisions made by expert FRAMA-C/EVA engineers, while maintaining acceptable false-positive rates. Finally, we show that LOUPE can effectively learn heuristics for other static analyzers such as MOPSA.

Due to the increasing complexity of modern systems, the level of responsibility dedicated to the human operator has grown, particularly in Socio-Technical Systems (STS) where humans are considered as subsystems. Like every system, the human operator can fail by behaving in undesired ways, and consequently have a negative impact on the system. Thus, to improve the resilience of the overall system, it is necessary to manage the vulnerability of humans. In this paper we present an approach to assess human vulnerabilities in an STS through its architecture. We propose a model that describes the STS, based on human characteristics having a significant impact on human vulnerabilities. We define an assessment metric for each characteristic. We propose an approach allowing not only to assess the vulnerability of a specific human in the system, but also to understand how a vulnerability propagates through the system. We implemented this approach with a dedicated architecture description language, called Hos-ML, allowing the architect to deal with STS vulnerabilities.

Metamodels are subject to evolution over their lifetime. UML metamodel for instance evolved through different versions, ranging from 0.8 to 2.5 minors. These metamodels are sometimes accompanied with constraints defined using OCL (Object Constraint Language). Many works in the literature developed methods for managing and assisting the co-evolution of metamodels and their constraints. These methods enable a developer to update, in an automated (or semi-automated) way, the constraints associated to a metamodel starting from the deltas identified between versions of this metamodel. In this work we complement this assistance by notifying the developer with potential inaccurate structures in the metamodel that may be introduced during evolution. We introduce in this paper an original evolution assistance method which focuses rather on the problem (notifying metamodel inaccurate structures) than on the solution (generating OCL constraints using patterns of them). The ultimate goal of this assistance is not only to enable the developer to complete existing/updated constraints with new ones, but also to accompany her/him to further check existing constraints and to test whether they still hold. A case study is presented to show the relevance of the method.

With the growing numbers of security attacks causing more and more serious damages in software systems, security cannot be added as an afterthought in software development. It has to be built in from the early development phases such as requirement and design. The role responsible for designing a software system is termed an “architect”, knowledgeable about the system architecture design, but not always well-trained in security. Moreover, involving other security experts into the system design is not always possible due to time-to-market and budget constraints. To address these challenges, we propose to define an asset-based security assistance in this paper, to help architects design secure systems even if these architects have limited knowledge in security. This assistance helps alert threats, and integrate the security controls over vulnerable parts of system into the architecture model. The central concept enabling this assistance is that of asset. We apply our proposal on a telemonitoring case study to show that automating such an assistance is feasible.

Threat modeling is recognized as one of the most important activities in software security. It helps to address security issues in software development. Several threat modeling processes are widely used in the industry such as the one of Microsoft SDL. In threat modeling, it is essential to first identify assets before enumerating threats, in order to diagnose the threat targets and spot the protection mechanisms. Asset identification and threat enumeration are collaborative activities involving many actors such as security experts and software architects. These activities are traditionally carried out in brainstorming sessions. Due to the lack of guidance, the lack of a sufficiently formalized process, the high dependence on actors' knowledge, and the variety of actors' background, these actors often have difficulties collaborating with each other. Brainstorming sessions are thus often conducted sub-optimally and require significant effort. To address this problem, we aim at structuring the asset identification phase by proposing a systematic asset identification process, which is based on a reference model. This process structures and identifies relevant assets, facilitating the threat enumeration during brainstorming. We illustrate the proposed process with a case study and show the usefulness of our process in supporting threat enumeration and improving existing threat modeling processes such as the Microsoft SDL one.

Summary Modeling and simulation play a major role in complex system engineering. In Systems of Systems (SoS) engineering, a special case of complex systems engineering, they help to better understand and identify the side effects associated with the integration of autonomous constituent systems. Simulation is also a way of apprehending the emerging behaviors from this integration. The dynamic and evolving nature of the SoS environment has led us to rely on their most stable part to define them, namely their mission. In this paper, we propose a simulation framework for SoS based on a mission conceptual model. Mission is defined as a set of situations that require reactions. Situations are defined by rules on facts related to the SoS environment. Reactions are defined as orchestrations of services from constituent systems (subsystems) that must be triggered when a situation is identified. We present this simulation approach through a case study on a Telediabet SoS.

A large component and service-based software system exists in different forms, as different variants targeting different business needs and users. This kind of systems is provided as a set of "independent" products and not as a "single whole". Developers use ad hoc mechanisms to manage variability. However, for deriving new product variants that are built upon existing ones, the presence of a single model describing the architecture of the whole system with an explicit specification of commonality and variability is of great interest. Indeed, this enables them to see the invariant part of the whole, on top of which new functionality can be built, in addition to the different options they can use. We investigate in this work the use of software product line reverse engineering approaches, and in particular the framework named But4Reuse, for recovering an architecture model that enables us to build a Software Architecture Product Line (SAPL), from a set of software variants. We propose a generic process for recovering an architecture model of such a product line. We have instantiated this process for the OSGi Java framework and experimented it for building the architecture model of Eclipse IDE SPL. The results of this experimentation showed that this process can effectively reconstruct such an architecture model.

Coping with unpredictable behavior in complex systems is a very hard task. This becomes more difficult when the system itself is composed of preexisting systems, which is the case of systems of systems (SoS). Often Engineers rely on simulation as the best way to understand and manage the complexity of such a system. In the case of SoS, managing emergent behavior is needed to avoid misbehaviors raised from the composition of the constituent systems. This paper is based on the assumption that an emergent misbehavior leads the SoS to an undesired or inconsistent state. So, we propose to explore simulation results to detect these undesirable SoS states and therefore helping the designer in identifying the corresponding misbehavior and its origin. We use the invariant paradigm to define the acceptable states for the SoS. The violation of the invariants implies that there is undesirable states, and therefore the existence of some emergent misbehaviors. We experimented our approach on a realistic case study concerning the glycemia control, and the results were very promising.

Modeling and simulation play a major role in complex system engineering. In Systems of Systems (SoS) engineering, a special case of complex systems, they help to better understand and identify the side effects associated with the integration of autonomous constituent systems. Simulation is also a way of apprehending the emerging behaviors from this integration. The dynamic and evolving nature of the SoS environment has led us to rely on the most stable part to define them, namely their mission. In this paper we propose a simulation framework for SoS based on a conceptual model defining the mission. Mission is defined as a set of situations that require reactions. Situations are defined by rules on facts related to the SoS environment. Reactions are defined as orchestrations of services from constituent systems (subsystems) that must be triggered when a situation is identified.We present this simulation approach through an SoS case study on health assistance.

Although there are contributions on component-oriented languages, components are mostly implemented using object-oriented (OO) languages. In this perspective, a component corresponds to a set of classes that work together to provide one or more services. Services are grouped together in interfaces that are each implemented by a class. Thus, dependencies between components are defined using the semantic of the enclosed classes, which is mostly structural. This makes it difficult to understand an architecture described with such links. Indeed, at an architectural level dependencies between components must represent functional aspects. This problem is worse, when the components are obtained by re-engineering of legacy OO systems. Indeed, in this case the obtained components are mainly based on the consistency of the grouping logic. So, in this paper we propose an approach to identify the interfaces of a component according to its interactions with the other components. To this end, we use formal concept analysis. The evaluation of the proposed approach via an empirical study showed that the identified interfaces overall correspond to the different functional aspects of the components.

Object-oriented applications of significant size are often complex and therefore, costly to maintain. Indeed, they rely on the concept of class which has low granularity with many implicit dependencies not always explicit. The component paradigm provides a projection space well-structured and of highest level for a better understanding through abstract architectural views. But it is possible to go further. It may also be the ultimate target of a complete process of re engineering. The end-to-end automation of this process is a subject on which literature has made very little attention. In this paper, we propose such a method to automatically transform an object-oriented application in an operational component-oriented application. We illustrate this method on a real Java application which is transformed in an operational OSGi application.

During software maintenance, some non-functional properties may be lost. This is due to the lack of an explicit definition of their links with the corresponding architectural choices. In this paper, we present a solution that automates the checking of non-functional properties after the evolution of a component-based software. Our approach emphasizes the interest of formally documenting the links binding non-functional requirements to architectural choices. The proposed formalism is based on the Object Constraint Language (OCL) applied to a software component metamodel. We also present a prototype tool which uses this documentation to warn the developer of possible effects of an architectural change on non-functional requirements.

It is argued that architecture comprehension and regression testing of a software system are the most expensive maintenance activities. This is mainly due to the fact that architectural choices are either not explicit, at every stage of the software development process, or not preserved from one stage to another. In this paper, we present an Architectural Constraint Language (ACL) as a means to formally describe architectural choices at all the stages. This language is based on the UML’s Object Constraint Language and on a set of MOF-compliant metamodels. We also present a prototype which validates the proposed approach. It allows the evaluation of ACL expressions at two stages and ensures, by using a transformation mechanism, that the constraints stated at one stage are subsequently preserved.

We propose a model for building object oriented applications based on the composition of application slices or fragments that provide their own overlapping definitions or expectations of the same domain objects. Different slices may implement different functional or implementation concerns, or embody different access rights and privileges to the same domain objects. We call such slices views and we recognize that the behavior embodied in views may be abstracted into generic class-like algebraic structures called viewpoints, from which views for specific domain classes may be generated. We are interested in the problem of distributing view based applications when different sites access different slices of the same domain objects. Specifically, we are interested in the problem of offering different views of the same domain objects to different client programs in a CORBA-like environment. We first discuss the principles behind view programming, and then explore ways in which objects with views may be distributed in a way that support's different sets of functionalities to different client programs. An interesting application of view programming in a distributed context is the selective duplication of object slices.