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.

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.

The software engineering teaching is a true challenge. Indeed software engineering technology is only justified for large projects or long-term applications maintenance ; aspects impossible to show at the time of introductory course.In order to circumvent these difficulties, we propose a new approach of software development teaching which we called "Docware". It is a documentation centered process: the software product is no longer regarded as a source file that is documented afterwards, but as a set of documents whose source file is one product among others.After having specified our teaching objectives, we describe this approach which uses new tools that we developed and used for several years. A report of the use of this approach concludes this paper.