JOURNÉE DE TRAVAIL DES GROUPES GLE ET RIMEL ET DE L'ACTION SPÉCIFIQUE LOUISE DU GDR GPL BORDEAUX, LE 12 AVRIL 2019 - CENTRE LGI2P
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Journée de travail des groupes GLE et RIMEL et de l’action spécifique
LOUISE du GdR GPL
Bordeaux, le 12 Avril 2019
Image recadrée - Auteur : Xellery - License Creative Commons
Organisation : Nicolas Anquetil, Anne Etien, Jean-Rémy Falleri,
Nicole Levy, Raul Mazo, Christelle Urtado, Tewfiq Ziadi
Journée organisée avec le soutien du GdR GPL du CNRS et du LaBRI.
Sommaire
Session 1 : Domaines et outils spécifiques
Mohamed Oumaziz
Dockerfile Duplicate Instructions in the Wild: an Empirical Study
Théo Zimmermann
L'impact d'un changement de bug tracker : une étude de cas sur un projet open source de taille moyenne
Olivier Le Goaer
GREEN Pauware: For a power-thrifty mobile and IoT app marketplace
Session 2 : Configuration et variabilité
Raùl Mazo
Recherches du CRI: vers les lignes de produits de systèmes auto-adaptables
Quentin Perez
An Empirical Study about Software Architecture Configuration Practices
Gilles Perrouin
Uniform Sampling of SAT Solutions for Configurable Systems: Are We There Yet?
Tewfik Ziadi
Software product line extraction from variability-rich systems: the robocode case study
Paul Temple
SPLs et Adversarial Machine Learning
Session 3a : Réunion de travail entre permanents
GLE / LOUISE / RIMEL : quelles actions collectives ?
Session 3b : Réunion de travail entre doctorants
GLE / LOUISE / RIMEL : cartographie des sujets de thèse
Page iSession 4 : Processus de développement
Roland Groz
Projet ANR PHILAE : maintenance des tests et rétro-ingénierie de workflows
Nicolas Herbaut
Gamification Ingénierie des exigences pour améliorer les pratiques
Elyes Cherfa
Bad smells dans les métamodèles
Stéphanie Challita
Inferring Precise Models from Cloud APIs Textual Documentations
Nan Messe
Development of Secure Systems of Systems Needing a Rapid Deployment
Page iiDockerfile Duplicate Instructions in the Wild:
an Empirical Study
Mohamed A. Oumaziz1 , Jean-Rémy Falleri1 , Xavier Blanc1 ,
Tegawendé F. Bissyandé2 , and Jacques Klein2
1
University of Bordeaux, LaBRI, UMR 5800, F-33400, Talence, France
{moumaziz, falleri, xblanc}@labri.fr
2
University of Luxembourg, SnT Interdisciplinary Center, L-1855, Luxembourg
{tegawende.bissyande, jacques.klein}@uni.lu
Docker is becoming very popular in open source projects as it allows devel-
opers to package in a single binary image all the artefacts that are required to
run an application. Therefore, many open source projects now provide several
images to meet their users’ needs. They consequently have to maintain several
Dockerfiles (used to build images) which could lead to maintenance issues.
In this work, our objective is to give a big picture of Dockerfile duplicates in
practice. We aim at answering questions regarding their existence, what main-
tainers think of them and how they handle them. Our goal is to provide to
practitioners a clear explanation for why duplicates arise in projects and what
are the di↵erent means to handle them.
To do so, we perform a mixed methods research (quantitative and quali-
tative) study on official Docker projects (138 projects) with an online survey
targeting 25 official maintainers, we show that most projects maintain several
Dockerfiles and determine the underlying reasons (several versions, base images
and variants). We also show that most of Dockefiles in our corpus do contain
duplicates. We determine that duplicates can be large and span across several
Dockerfiles and find the underlying reasons for their existence (software instal-
lation and configuration, dependency management, runtime configuration). We
also show that maintainers are aware of duplicates in their Dockerfiles and often
face them. However, some say that these duplicates can be error-prone, while
others state that they are easy to solve with the right tooling.
We then show that several official projects use external tools to remove du-
plicates. We classify these tools in three categories: find and replace, template
processors and generators. However, the most commonly used tool (template
processors) when applied naively doesn’t remove all duplicates, while Generators
are very efficient at removing duplicates but their scripts are very cumbersome
to understand. Maintainers also stated that they don’t like to use external tools
because of their complexity and would rather use reuse mechanisms directly
implemented in the Dockerfile DSL.
Finally, we show that the Dockerfile DSL faces duplicates issues just as any
other programming language. We pinpoint through our survey that reuse mech-
anisms should let maintainers reuse single, blocs and sub-parts of instructions
across Dockerfiles. We then confirm that maintainers prefer to have reuse mech-
anisms in the Dockerfile DSL even if it leads to a more complex DSL.Impact of switching bug trackers: a case study
on a medium-sized open source project
Théo Zimmermann1,2 and Annalı́ Casanueva Artı́s3
1
⇧R2 , Inria Paris, France
2
IRIF, Paris-Diderot University, France
3
Paris School of Economics, France
theo@irif.fr
For most software projects, the bug tracker is an essential tool. In open source
development, this tool plays an even more central role as it is generally open to
all users, who are encouraged to test the software and report bugs. Previous
studies have highlighted the act of reporting a bug as a first step leading a user
to become an active contributor.
The impact of the bug reporting environment on the bug tracking activity is
difficult to assess because of the lack of comparison points. In this work, we take
advantage of the switch, from Bugzilla to GitHub, of the bug tracker of Coq, a
medium-sized open source project, to evaluate the impact that such a change
can have.
We first report on the switch itself, in particular the migration of 4900 pre-
existing bug reports using the GitHub issue import API. Then we analyze data
from before and after the switch using a Regression on Discontinuity analysis,
a novel methodology in the context of empirical software engineering. We show
that the switch induces an increase in bug reporting, particularly from princi-
pal developers themselves, and more generally an increased engagement with
the bug tracking platform, with more comments by developers and also more
external commentators.
Fig. 1. Number of bug reports per day before and after the switchGREEN PAUWARE
For a power-thrifty mobile and IoT app marketplace
Olivier Le Goaër
Université de Pau, 64000 Pau, France
olivier.legoaer@univ-pau.fr
Abstract. Energy-intensive mobile applications are a burden for both end users
and developers, and ultimately are harmful to the planet. The objective of the
GREEN PAUWARE project is to break these bad habits by creating an energy
label for applications (ranging from A to G), as exists in other areas. Many au-
thors agree on the necessity of an eco-score or ranking [1,2,3,4] within the mo-
bile apps market, but research is hampered by the complexity and lack of avail-
able tools [4].
This presentation proposes milestones to achieve this objective. In particular, it
introduces an ecological bonus-malus system applied to Android development
projects to try to give a score to applications. Then, it shows how to use a static
code analysis tool like Android Lint [5] to implement such a system. Finally, it
features a distributed software architecture to collect scores and push labels to-
wards end users so they can make informed decisions when installing applica-
tions on their Android-powered devices.
Keywords: GreenIT, energy, environment, Android, Lint.
1. Wilke, C., Richly, S., & Püschel, G. (2012). Energy Labels for Mobile Applications. In-
formatik 2012, 42. Jahrestagung der Gesellschaft. 412–426
2. Meier, J., Ostendorp, M.-C., Jelschen, J., & Winter, A. (2014). Certifying Energy Efficien-
cy of Android Applications. 28th International Conference on Informatics for Environmen-
tal Protection: {ICT} for Energy Efficiency, EnviroInfo 2014, Oldenburg, Germany, Sep-
tember 10-12, 2014., 765–770
3. Jabbarvand, R., Sadeghi, A., Garcia, J., Malek, S., & Ammann, P. (2015). EcoDroid: An
Approach for Energy-Based Ranking of Android Apps. Proceedings - 4th International
Workshop on Green and Sustainable Software, GREENS 2015, 8–14.
4. Hindle, A. (2016). Green Software Engineering: The Curse of Methodology. 2016 IEEE
23rd International Conference on Software Analysis, Evolution, and Reengineering
(SANER), 46–55.
5. https://developer.android.com/studio/write/lintAn Empirical Study about Software Architecture
Configuration Practices
with the Java Spring Framework
Quentin Perez, Alexandre Le Borgne, Christelle Urtado, and Sylvain
Vauttier
LGI2P, IMT Mines Ales, Univ Montpellier, Ales, France
{Quentin.Perez, Alexandre.Le-Borgne, Christelle.Urtado, Sylvain.Vauttier}
@mines-ales.fr
Structuring and organizing components in software modeling architecture are key
roles in software development. Furthermore this organization has an impact on the
software quality. Having noted a a growth of industrial use of Spring framework to
deploy software, our work attempts to assess whether Spring provides architecture
management capabilities that foster good practices and quality. It describes the re-
sults of an empirical study, based on a corpus of open-source Spring projects extracted
from Github. Our analysis highlights that a majority (70%) of projects are a mix be-
tween all Spring architecture definition features. This can be viewed as a pragmatic
use of flexibility o↵ered by Spring. Nevertheless, few good practice documentation
and tool assistance exist to prevent hazardous architecture constructions. Our work
shows these situations and concludes on recommendations to assist developers.
1Uniform Sampling of SAT Solutions for
?
Configurable Systems: Are We There Yet?
Quentin Plazar1 , Mathieu Acher1[0000 0003 1483 3858] , Gilles
Perrouin2[0000 0002 8431 0377] , Xavier Devroey3[0000 0002 0831 7606] , and
Maxime Cordy4[0000 0001 8312 1358]
1
Univ Rennes, Inria, CNRS, IRISA, Rennes, France. quentin.plazar@gmail.com,
mathieu.acher@irisa.fr
2
PReCISE/NaDI, Faculty of Computer Science, University of Namur, Namur,
Belgium. gilles.perrouin@unamur.be
3
Delft University of Technology, Delft, The Netherlands.
x.d.m.devroey@tudelft.nl
4
SnT, University of Luxembourg, Luxembourg, Luxembourg. maxime.cordy@uni.lu
Abstract. Uniform or near-uniform generation of solutions for large sat-
isfiability formulas is a problem of theoretical and practical interest for
the testing community. Recent works proposed two algorithms (namely
UniGen and QuickSampler) for reaching a good compromise between
execution time and uniformity guarantees, with empirical evidence on
SAT benchmarks. In the context of highly-configurable software systems
(e.g., Linux), it is unclear whether UniGen and QuickSampler can scale
and sample uniform software configurations. In this paper, we perform
a thorough experiment on 128 real-world feature models. We find that
UniGen is unable to produce SAT solutions out of such feature mod-
els. Furthermore, we show that QuickSampler does not generate uniform
samples and that some features are either never part of the sample or
too frequently present. Finally, using a case study, we characterize the
impacts of these results on the ability to find bugs in a configurable sys-
tem. Overall, our results suggest that we are not there: more research is
needed to explore the cost-e↵ectiveness of uniform sampling when testing
large configurable systems.
Keywords: configurable systems · software testing · uniform sampling · SAT ·
variability modeling · software product lines
?
This contribution will appear as a full paper in the proceedings of the 12th IEEE
international Conference Software Testing, Verfication and Validation (ICST 2019),
Xi’an, China. Gilles Perrouin is a research associate at the FNRS. This research
was partially funded by the EU Project STAMP ICT-16-10 No.731529, the NIRICT
3TU.BSR (Big Software on the Run) project, the FNRS Grant O05518F-RG03, and
the ANR-17-CE25-0010-01 VaryVary project. This work was done when Maxime
Cordy worked at the University of Namur.On the possible interactions between SPL
and adversarial Machine Learning ?
Paul Temple, Gilles Perrouin, Benoît Frénay, Pierre-Yves
Schobbens, and Patrick Heymans
NaDI, PReCISE, Faculty of Computer Science, University of Namur
paul.temple@unamur.be
Abstract. Machine Learning techniques are evermore popular nowa-
days and are used for various tasks. For instance, to help medical diag-
nosis, in so-called autonomous vehicles, to detect infractions in computer
networks or spams emails or even fake news. Over the past few years, Ma-
chine Learning has been used to help finding near-optimal configurations
of configurable systems. They have shown to be very successful in their
tasks. In parallel of the development of Machine Learning techniques, re-
searchers began to investigate how and how easily these algorithms can
be fooled. Today, this field is known as adversarial Machine Learning
and it has been very dynamic as multiple adversarial techniques have
been developed. I will present possible interactions between these two
fields that are Software Product Lines and configurable systems on one
part and adversarial Machine Learning on the other. In particular, the
fact that adversarial Machine Learning could benefit from the Software
Product Line framework and how adversarial Machine Learning may
help testing Software Product Lines and configurable systems.
This presentation has been accepted at the 1st workshop on Testing for
Deep Learning and Deep Learning for Testing (ICSE’19).
Keywords: Software Product Lines · Machine Learning · Software Test-
ing · Validation & Verification · adversarial Machine Learning
?
Gilles Perrouin is a FNRS research associate. This research was partially funded by
the FNRS Grant O05518F-RG03.DEXTORM
Dynamic Execution-To-Requirement Mapping for
Gamified Specification-Based Testing
Mohammed El Amin Tebib1 , Nicolas Herbaut1 , and Camille Salinesi1
Centre de Recherche en Informatique (CRI)
Université Paris 1 Panthéon-Sorbonne, Paris, France
nicolas.herbaut@univ-paris1.fr
Abstract. [Context] Manual requirements verification is of paramount
importance to assure good quality of software products. It usually in-
volves executing boring repetitive test plans derived from the specific
feature set applicable to the particular flavor of system under test. Test
engineers are unable to dynamically associate product execution to the
verification of a particular requirement for a particular product. They
loose track of the applicable underlying requirements and may su↵er from
test-fatigue and demotivation. [Background] Gamification aims at ap-
plying game elements to non-game context [3]. In Software Engineering,
gamification has been used for increasing the engagement of the software
production team, and improve their performance by making tools and
activities more attractive, efficient and easy to use. Yet, gamification is
seldom used for requirements validation or verification and is often lim-
ited to a small subset of game elements such as points and leaderboards
[2] [Proposal] We aim at making specification-based testing more ap-
pealing and put back requirements at the center of requirements veri-
fication. For that, we created an unobtrusive agent, DEXTORM, that
dynamically maps requirements to system execution through code in-
strumentation. Code-to-requirements mapping is obtained by analyzing
historical version control commit messages, which are linked to User
stories/Requirements through the issue tracking and project manage-
ment application. Requirements are displayed dynamically while testing
the system, to create a gamified Requirement Verification tool, where
testers can track their progress, collaborate with other testers to avoid
overwhelming repetitive tasks [Progress] Today, we demonstrate an ini-
tial proof of concept of the gamified system on a toy project using Github
as the requirement management tool. We plan to apply this system to a
real opensource project and compare its performance with classical test
plan-based approaches. We also want to further extend the DEXTORM
agent to distributed systems and assure that the most relevant require-
ments are prioritized. Possible extensions of this work may also leverage
advanced techniques such as mutation testing for Test-plan validation
[4], and application to requirement tracing[1] to better understand which
requirements are impacted by code change.
Keywords: Gamification · Requirement Engineering · Verification ·
Version Control · Issue Management · Requirement ManagementReferences
[1] Jane Cleland-Huang et al. “Goal-centric traceability for managing non-
functional requirements”. In: Proceedings. 27th International Conference
on Software Engineering, 2005. ICSE 2005. IEEE. 2005, pp. 362–371.
[2] R. Cursino et al. “Gamification in Requirements Engineering: A Systematic
Review”. In: 2018 11th International Conference on the Quality of Informa-
tion and Communications Technology (QUATIC). Sept. 2018, pp. 119–125.
doi: 10.1109/QUATIC.2018.00025.
[3] Sebastian Deterding et al. “Gamification. using game-design elements in
non-gaming contexts”. In: CHI’11 extended abstracts on human factors in
computing systems. ACM. 2011, pp. 2425–2428.
[4] Yue Jia and Mark Harman. “An analysis and survey of the development
of mutation testing”. In: IEEE transactions on software engineering 37.5
(2011), pp. 649–678.Bad Smells dans les méta-modèles
Elyes Cherfa1-2 and Salah Sadou2
1
Segula Engineering France, BP 50256 – 56602 Lanester Cedex
2
IRISA, UBS, Rue André Lwoff, 56000 Vannes
elyes.cherfa@univ-ubs.fr
Abstract. Un méta-modèle capture les concepts essentiels d’un domaine d’ingénierie, four-
nissant ainsi les bases d’un langage de modélisation spécifique au domaine. Un méta-modèle
est perçu comme la combinaison d’une structure du domaine qui englobe les concepts et les in-
teractions entre ces concepts, celle-ci souvent exprimée avec MOF, et d’une partie textuelle qui
décrit la sémantique exprimée souvent sous forme de contraintes OCL. L’absence des con -
traintes OCL entraine la création de modèles syntaxiquement correct, mais incompatibles au
domaine. Certaines contraintes OCL sont jointes à la majorité des contraintes OCL, quel que
soit le domaine applicatif, et d’autres sont purement liées au domaine. L’objectif de notre tra -
vail est d’étudier les contraintes OCL et les méta-modèle pour identifier les structures qui sont à
l’origine des contraintes indépendantes du domaine, celles-ci sont appelées des bad smells de
méta-modèles.
Keywords: Méta-modélisation, MOF, OCL.
1 Introduction
Dans les processus de l’ingénierie dirigée par des modèles (IDM), les concepteurs
sont souvent amenés à créer des langages propres à leur domaine applicatif. La créa-
tion de tels langages passe par la définition de méta-modèles ou de profiles de méta-
modèles. Sur la base de ces derniers, des modèles qui leur sont conformes sont ensuite
instanciés. Ainsi, un méta-modèle représente la syntaxe abstraite du Langage de Mod-
élisation Spécifique au Domaine (DSML1). Il se compose d’une partie structurelle qui
détient les concepts de base du domaine et leurs relations, et d’une partie contraintes
(OCL) qui s’applique sur la partie structurelle pour préciser la sémantique du do-
maine.
Malheureusement, beaucoup de concepteurs de méta-modèles ne se focalisent que
sur la partie structurelle, à savoir les méta-classes et les relations entre elles (Faunes
et al., 2013). Ceci est dû au fait que l’étape de formalisation de la sémantique du do -
maine sous forme de contraintes OCL est souvent une tâche très complexe. Par con -
séquent, à partir d’un méta-modèle comprenant seulement la partie structurelle, des
modèles qui sont syntaxiquement corrects peuvent être instanciés. Cependant, ces
modèles peuvent être sémantiquement incorrects.
Les contraintes OCL ajoutées à un méta-modèle sont de deux types : 1) celles qui
sont liées au domaine (elles diffèrent d’un domaine à un autre) et qui sont exprimées
1 MOF : Meta-Object Facility
2 OCL : Object Constraint Languageen s’appuyant sur les connaissances des experts ; et 2) celles qui sont ajoutées à la majorité des méta-modèles afin d’éviter certains problèmes lors de l’instanciation des modèles. Effectivement, il existe des structures du méta-modèle qui sont susceptibles de poser des problèmes lors de l’instanciation et qui ne peuvent pas être résolues structurellement ; des contraintes OCL sont alors ajoutées pour éviter ces problèmes. Nous appelons ces structures nécessitant des contraintes OCL pour éviter des er- reurs sémantiques, des bad smells. Tout comme les bad smells de code ou bien d’ar- chitecture, les bad smells au niveau du méta-modèle ne sont pas des erreurs. Le méta- modèle qui contient des bad smells est structurellement correct. Toutefois, il permet éventuellement la génération de certains modèles sémantiquement incorrects. Étant donné que les contraintes liées aux bad smells sont indépendantes du do- maine d’application, leur génération automatique en utilisant juste le méta-modèle est alors possible. Nous proposons ainsi une solution permettant la génération automa- tique de ces contraintes OCL liées au bad smells en utilisant seulement le méta-mod- èle. Nous sommes persuadés que le meilleur moyen de trouver ces bad smells est d’étudier des méta-modèles ayant déjà des contraintes OCL, et de trouver le lien entre les contraintes et les structures ciblées. L’objectif de notre travail, dans un premier temps, consiste à étudier les contraintes OCL de plusieurs méta-modèles pour identi- fier les structures nécessitant des contraintes. Ensuite, un outil de recherche automa- tique de bad smells devra être développé. Enfin, un outil qui permet la recherche au - tomatique, et la correction de bad smells avec des contraintes OCL devra être mis en place. References 1. [1] M. Faunes, J. Cadavid, B. Baudry, H. Sahraoui, et B. Combemale, « Automat- ically Searching for Metamodel Well-Formedness Rules in Examples and Counter-Examples », in Model-Driven Engineering Languages and Systems: 16th International Conference, MODELS 2013, Miami, FL, USA, September 29 – Oc- tober 4, 2013. Proceedings, A. Moreira, B. Schätz, J. Gray, A. Vallecillo, et P. Clarke, Éd. Berlin, Heidelberg: Springer Berlin Heidelberg, 2013, p. 187–202.
Inferring Precise Models from Cloud APIs:
A Google Cloud Platform Use Case
Stéphanie Challita1 and Philippe Merle2,3
1
Inria Sophia Antipolis - Méditérranée
2
Inria Lille - Nord Europe
3
University of Lille
firstname.lastname@inria.fr
Cloud models play an important role to capture the expectations of a cloud API and to a priori validate the
correctness of its cloud configurations. These models are manually designed so far, which is prohibitively labor
intensive, time consuming and error-prone. To address this issue, we propose a novel approach to infer model-driven
specifications from natural language text of cloud API documentations. Our approach is applied on a concrete cloud
provider, Google Cloud Platform (GCP), which is today one of the most important and growing provider in the
cloud market.
By going through the GCP documentation, we realize that it contains wealthy information about GCP services
and operations, such as the semantics of each attribute and the behaviour of each operation. However, GCP
documentation is described through HTML pages at its website4 and is written in natural language, a.k.a. English
prose, which results in human errors and/or semantic confusions. To avoid confusion and misunderstandings, the
cloud developers obviously need a precise specification of the knowledge and activities in GCP.
After presenting the general approach we promote to obtain formal cloud models, this contribution [1] also
presents a precise model for GCP. It describes GCP resources and operations, reasons about this API and provides
corrections to its current drawbacks. This is a work of reverse engineering [2], which is the process of extracting
knowledge from a man-made documentation and re-producing it based on the extracted information. In order to
formally encode the GCP API without ambiguity, we choose to automatically infer a GCP Model as the target
documentation format. In fact, our approach leverages the use of Model-Driven Engineering (MDE) to provide a
precise and homogeneous specification, and reduce the cost of developing complex systems. MDE allows to rise
in abstraction from the implementation level to the model level, and to provide a graphical output and a formal
verification of GCP structure and operations. Our GCP Model conforms to the OCCIware Metamodel [3].
Our contributions can be summarized in four categories:
1. an automated approach to infer models from textual documentations,
2. a concrete use case of our approach: a precise GCP Model that consists in a formal specification of GCP. This
model, automatically built, also provides corrections for the drawbacks that we identified in GCP documentation,
3. an analysis of GCP documentation because it is as important as analyzing the API itself. This is done thanks
to our model which is a clearer representation of GCP compared to the original one and hence easier to reason
over it, and,
4. a validation of the preciseness of our GCP model.
Keywords: Cloud computing · Model-driven engineering · API mining · Reverse engineering · Natural language
processing.
References
1. Stéphanie Challita, Faiez Zalila, Christophe Gourdin, and Philippe Merle. A Precise Model for Google Cloud Platform.
In 6th IEEE International Conference on Cloud Engineering (IC2E), pages 177–183. IEEE, 2018.
2. Spencer Rugaber and Kurt Stirewalt. Model-Driven Reverse Engineering. IEEE software, 21(4):45–53, 2004.
3. Faiez Zalila, Stéphanie Challita, and Philippe Merle. A Model-Driven Tool Chain for OCCI. In OTM Confederated
International Conferences” On the Move to Meaningful Internet Systems”, pages 389–409. Springer, 2017.
4
https://cloud.google.comDevelopment of Secure Systems of Systems Needing a Rapid
Deployment
Nan ZHANG MESSE)
University of south Brittany, IRISA, France
March 22, 2019
Thesis Supervisor : Régis FLEURQUIN However, the design of an SoSnRD is often the re-
Nicolas BELLOIR sponsibility of a single person: a domain expert.
Such experts have significant experiences in setting
up such SoS in their fields of intervention. Thus,
Abstract they are often able to imagine a preliminary de-
sign solution very quickly: essentially adapting a
In certain cases, such as secure humanitarian cor- ”generic” solution to a particular context.
ridors in a conflict zone, a special type of SoS, As an SoSnRD can be deployed in a hostile en-
needing rapid development, has to be developed. vironment, it is essential to take into account the
Because of the tight time constraints, usually only security aspect. Unfortunately, the domain experts
a domain expert is responsible with this develop- generally do not have any security skills. They
ment. However, many such SoS also have to take cannot rely on existing SoS security methodolo-
into account the security aspect. How to do to gies such as SoSSec. Indeed, such methods require
help a domain expert integrate the security aspect a long time and interaction with security experts,
in the rapid development of an SoS? In our work, which is not always possible when in an emergency.
we present an approach and a tool suite that help Accordingly, these experts can propose a solution
the domain expert tag business assets with security that meets functional requirements, but not one
properties, which are then used to identify vulner- that integrates any security aspect.
abilities and to propose possible security control In our work, we propose a prospective vision on
mechanisms. the development of SoSnRD integrating the secu-
rity aspect. We propose an assistance that will en-
able a domain expert who is not a security specialist
1 Description to document and integrate security in his/her de-
sign throughout all the architecture design process.
In our work, we deal with a special type of The core of this assistance promotes the concept of
Systems-of-systems (SoS): SoS needing Rapid De- ’asset’. We will show that assets can help bridge
ployment (SoSnRD) such as a secure rescue op- the gap between domain expert’s knowledge and
eration after an earthquake or a military opera- security concerns.
tion. This kind of system has to be implemented
as quickly as possible (within a few hours or days)
to respond to an emergency. To build SoSnRD, Acknowledgment
we cannot rely on traditional SoS development
methodologies, such as MODAF, DODAF, NAF, This work is funded by the DGA1 and the Pole
2
COMPASS or DANSE. These usually assume that: d’Excellence Cyber
i) there is a significant amount of time to perform 1 DGA:https://www.defense.gouv.fr/dga
the development (months, years) and ii) a poten- 2 Pole d’Excellence Cyber : https://www.pole-excellence-
tially large number of stakeholders can be involved. cyber.org/You can also read
