Full Chapter Reuse in Emerging Software Engineering Practices 19Th International Conference On Software and Systems Reuse Icsr 2020 Hammamet Tunisia December 2 4 2020 Proceedings Sihem Ben Sassi PDF

Reuse in Emerging Software
Engineering Practices: 19th

International Conference on Software
and Systems Reuse, ICSR 2020,
Hammamet, Tunisia, December 2–4,
2020, Proceedings Sihem Ben Sassi
Visit to download the full and correct content document:
https://textbookfull.com/product/reuse-in-emerging-software-engineering-practices-19t
h-international-conference-on-software-and-systems-reuse-icsr-2020-hammamet-tuni
sia-december-2-4-2020-proceedings-sihem-ben-sassi/
More products digital (pdf, epub, mobi) instant
download maybe you interests ...
Biota Grow 2C gather 2C cook Loucas
https://textbookfull.com/product/biota-grow-2c-gather-2c-cook-
loucas/
Software Reuse Bridging with Social Awareness 15th

International Conference ICSR 2016 Limassol Cyprus June
5 7 2016 Proceedings 1st Edition Georgia M. Kapitsaki
https://textbookfull.com/product/software-reuse-bridging-with-
social-awareness-15th-international-conference-
icsr-2016-limassol-cyprus-june-5-7-2016-proceedings-1st-edition-
georgia-m-kapitsaki/
Software Engineering Perspectives in Intelligent

Systems: Proceedings of 4th Computational Methods in
Systems and Software 2020, Vol.2 Radek Silhavy
https://textbookfull.com/product/software-engineering-
perspectives-in-intelligent-systems-proceedings-of-4th-
computational-methods-in-systems-and-software-2020-vol-2-radek-
silhavy/
New Perspectives in Software Engineering: Proceedings

of the 9th International Conference on Software Process
Improvement (CIMPS 2020) Jezreel Mejia
https://textbookfull.com/product/new-perspectives-in-software-
engineering-proceedings-of-the-9th-international-conference-on-
software-process-improvement-cimps-2020-jezreel-mejia/
Agile Processes in Software Engineering and Extreme
Programming: 21st International Conference on Agile
Software Development, XP 2020, Copenhagen, Denmark,
June 8–12, 2020, Proceedings Viktoria Stray
https://textbookfull.com/product/agile-processes-in-software-
engineering-and-extreme-programming-21st-international-
conference-on-agile-software-development-xp-2020-copenhagen-
denmark-june-8-12-2020-proceedings-viktori/
Testing Software and Systems 32nd IFIP WG 6 1

International Conference ICTSS 2020 Naples Italy
December 9 11 2020 Proceedings Valentina Casola
https://textbookfull.com/product/testing-software-and-
systems-32nd-ifip-wg-6-1-international-conference-
ictss-2020-naples-italy-december-9-11-2020-proceedings-valentina-
casola/
Software Engineering Perspectives in Intelligent

Systems: Proceedings of 4th Computational Methods in
Systems and Software 2020, Vol.1 Radek Silhavy
https://textbookfull.com/product/software-engineering-
perspectives-in-intelligent-systems-proceedings-of-4th-
computational-methods-in-systems-and-software-2020-vol-1-radek-
silhavy/
The Impact of Digital Technologies on Public Health in

Developed and Developing Countries: 18th International
Conference, ICOST 2020, Hammamet, Tunisia, June 24–26,
2020, Proceedings Mohamed Jmaiel
https://textbookfull.com/product/the-impact-of-digital-
technologies-on-public-health-in-developed-and-developing-
countries-18th-international-conference-icost-2020-hammamet-
tunisia-june-24-26-2020-proceedings-mohamed-j/
Advances in Artificial Intelligence, Software and

Systems Engineering: Proceedings of the AHFE 2020
Virtual Conferences on Software and Systems
Engineering, and Artificial Intelligence and Social
Computing, July 16-20, 2020, USA Tareq Ahram
https://textbookfull.com/product/advances-in-artificial-
intelligence-software-and-systems-engineering-proceedings-of-the-
ahfe-2020-virtual-conferences-on-software-and-systems-
Sihem Ben Sassi
Stéphane Ducasse
Hafedh Mili (Eds.)
Reuse in Emerging
LNCS 12541
Software Engineering
Practices
19th International Conference on Software
and Systems Reuse, ICSR 2020
Hammamet, Tunisia, December 2–4, 2020
Proceedings
Lecture Notes in Computer Science 12541
Founding Editors
Gerhard Goos
Karlsruhe Institute of Technology, Karlsruhe, Germany
Juris Hartmanis
Cornell University, Ithaca, NY, USA
Editorial Board Members

Elisa Bertino
Purdue University, West Lafayette, IN, USA
Wen Gao
Peking University, Beijing, China
Bernhard Steffen
TU Dortmund University, Dortmund, Germany
Gerhard Woeginger
RWTH Aachen, Aachen, Germany
Moti Yung
Columbia University, New York, NY, USA
More information about this subseries at http://www.springer.com/series/7408
Sihem Ben Sassi Stéphane Ducasse
• •
Hafedh Mili (Eds.)
Reuse in Emerging
Software Engineering
Practices
19th International Conference on Software
and Systems Reuse, ICSR 2020
Hammamet, Tunisia, December 2–4, 2020
Proceedings
123
Editors
Sihem Ben Sassi Stéphane Ducasse
Manouba University University of Lille, Inria, CNRS
Tunis, Tunisia Lille, France
Taibah University
Medina, Saudi Arabia
Hafedh Mili
Université du Québec à Montréal
Montréal, QC, Canada
ISSN 0302-9743 ISSN 1611-3349 (electronic)

Lecture Notes in Computer Science
ISBN 978-3-030-64693-6 ISBN 978-3-030-64694-3 (eBook)
https://doi.org/10.1007/978-3-030-64694-3
LNCS Sublibrary: SL2 – Programming and Software Engineering
© Springer Nature Switzerland AG 2020

This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the
material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation,
broadcasting, reproduction on microfilms or in any other physical way, and transmission or information
storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now
known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication
does not imply, even in the absence of a specific statement, that such names are exempt from the relevant
protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this book are
believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors
give a warranty, expressed or implied, with respect to the material contained herein or for any errors or
omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in
published maps and institutional affiliations.
This Springer imprint is published by the registered company Springer Nature Switzerland AG
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
Preface
This volume contains the proceedings of the 19th edition of the International Con-
ference on Software and Systems Reuse (ICSR 2020), initially planned to be held
during November 9–11, 2020, in the beautiful seafront city of Hammamet, Tunisia,
considered by many as the ‘Tunisian Riviera’. Due to the COVID-19 pandemic, ICSR
2020 was delayed by 22 days, and was held as a fully virtual event, during December
2–4, 2020.
ICSR is the premier international event in the software reuse community, and
starting from last year, Systems was added to the name of the conference to emphasise
the role of systems engineering in reuse. It highlights the relevance of reuse to
embedded systems, cyber physical systems, socio-technical systems, and systems of
systems. The main goal of ICSR is to present the most recent advances in the area of
software and systems reuse and to promote an exchange of ideas and best practices
among researchers and practitioners.
The 19th edition’s guiding theme was “Reuse in emerging software engineering
practices”. Recent advances in software engineering include agile software develop-
ment, cloud computing, the IoT, and the increasing reliance on black box AI com-
ponents to implement critical system functionalities. The impact of these technologies
on the theory and practice of software and system reuse is not yet clear, and sometimes
appears to be contradictory. For example, while agile development pleads against
development for reuse, agile teams increasingly rely on ecosystems of reusable soft-
ware components developed by quintessential reuse organizations open source devel-
oper communities. Similarly, cloud computing and container technologies have
revolutionized software architectures reuse at the architectural level now embodied as
reusable services on cloud platforms. We solicited papers that explored these, and more
traditional software reuse themes.
We adopted a two-phase submission process, with abstracts first, and full papers two
weeks later. We received a record of 84 abstracts, which yielded after some pre-review
filtering, 60 full, in-scope submissions, from 19 countries and all continents with the
exception of antarctica. We adopted a double-blind review process, and all papers
received a minimum of 3 reviews; 15 papers received 4 or more reviews, including a
handful with 5 reviews, and 1 with 6 reviews, as we kept seeking fourth, fifth, and sixth
opinions to settle differences between reviewers! Based on the reviews, we accepted 16
submissions as full-length research papers (26% acceptance rate), and 2 papers, where
a consensus was difficult to obtain, as short papers.
We take this opportunity to extend our sincerest thanks, first to the authors who
submitted their great work to the conference, making it a success, despite incredible
circumstances. We also extend our sincerest thanks to the Program Committee mem-
bers, and the external reviewers they recruited, for the quality of their reviews, and for
remaining fully engaged during the discussion period. Last, but not least, we would like
to thank Rafael Capilla, the ICSR Steering Committee chair, who provided us with
vi Preface
much timely and useful guidance as we navigated the various phases of the organi-
zation of the conference, and the pandemic!
Finally, we thank Lamia Labed Jilani (Université de Tunis, Tunisia) the workshops
and tutorials chair, and Chouki Tibermacine (Université de Montpellier, France) the
publicity and doctoral symposium chair, for helping make the conference a logistical
success.
ICSR 2020 benefited from the logistical and financial support of the LATECE
Research Lab (www.latece.uqam.ca) of the Université du Québec a Montréal, Canada,
the RIADI Research Lab (http://www.riadi.rnu.tn) of the École Nationale des Sciences
de l’Informatique, Tunisia, and the Cristal research team (UMR9189) of the University
of Lille, France (https://www.cristal.univ-lille.fr).
R D
Centre de Recherche en Informatique,

Signal et Automatique de Lille
LABORATOIRE
October 2020 Sihem Ben Sassi

Stéphane Ducasse
Hafedh Mili
Organization
General Chair
Hafedh Mili Université du Québec, Canada
Program Committee Chairs

Stéphane Ducasse University of Lille, Inria, CNRS, France
Sihem Ben Sassi Manouba University, Tunisia
Taibah University, Saudi Arabia
Workshops and Tutorials Chair

Lamia Labed Jilani Université de Tunis, Tunisia
Doctoral Symposium and Publicity Chairs

Mohamed Wiem Mkaouer Rochester Institute of Technology, NY, USA
Ali Ouni Higher technology institute, Montréal, Canada
Chouki Tibermacine Université de Montpellier, France
Local Chair
Anja Habacha Manouba University, Tunisia
Steering Committee
Eduardo Almeida Federal University of Bahia, Brazil
Goetz Botterweck Lero, University of Limerick, Ireland
Rafael Capilla Rey Juan Carlos University, Spain
John Favaro Trust-IT, Italy
William B. Frakes IEEE TCSE, USA
George Angelos University of Cyprus, Cyprus
Papadopoulos
Claudia Werner Federal University of Rio de Janeiro, Brazil
Program Committee
Eduardo Almeida Federal University of Bahia, Brazil
Apostolos Ampatzoglou University of Macedonia, Greece
Francesca Arcelli Fontana University of Milano-Bicocca, Italy
Claudia P. Ayala Universitat Politècnica de Catalunya, Spain
viii Organization
Olivier Barais University of Rennes 1, France

Raoudha Beltaifa University of Carthage, Tunisia
Jan Bosch Chalmers University of Technology, Sweden
Alexander Chatzigeorgiou University of Macedonia, Greece
Shigeru Chiba The University of Tokyo, Japan
Coen De Roover Vrije Universiteit Brussel, Belgium
Serge Demeyer Universiteit Antwerpen, Belgium
Christophe Dony Montpellier 2 University, France
Rim Drira Manouba University, Tunisia
Maha Driss Manouba University, Tunisia
Ghizlane El Boussaidi École de technologie supérieure, Canada
Anne Etien University of Lille, France
John Favaro Trust-IT, Italy
Christopher Fuhrman École de Technologie Supérieure, Canada
Mohamed Graiet University of Monastir, Tunisia
Yann-Gaël Guéhéneuc Concordia University, Canada
Shinpei Hayashi Tokyo Institute of Technology, Japan
Oumarou Hayatou University of Maroua, Cameroon
Andre Hora Federal University of Minas Gerais, Brazil
Yassine Jamoussi Sultan Qaboos University, Oman
Ridha Khedri McMaster University, Canada
Naoufel Kraiem University of Manouba, Tunisia
Raula Gaikovina Kula Nara Institute of Science and Technology, Japan
Lamia Labed Jilani University of Tunis, Tunisia
Tommi Mikkonen University of Helsinki, Finland
Gordana Milosavljevic University of Novi Sad, Serbia
Maurizio Morisio Politecnico di Torino, Italy
Nan Niu University of Cincinnati, USA
Xin Peng Fudan University, China
Robert Pergl Czech Technical University in Prague, Czech
Gordana Rakic University of Novi Sad, Serbia
Romain Rouvoy University of Lille, France
Juan Pablo Sandoval Universidad Católica Boliviana, Bolivia
Alcocer
Gustavo Santos Federal University of Technology - Paraná, Brazil
Klaus Schmid University of Hildesheim, Germany
Christoph Seidl IT University of Copenhagen, Denmark
Abdelhak-Djamel Seriai University of Montpellier, France
Davide Taibi Tampere University, Finland
Roberto Tonelli University of Cagliari, Italy
Nacim Yanes University of Manouba, Tunisia
Uwe Zdun University of Vienna, Austria
Wei Zhang Peking University, China
Tewfik Ziadi Sorbonne University, France
Organization ix
Additional Reviewers
Ali Parsai Carolina Hernandez Phillips

Nicolas Anquetil Henrique Rocha
Anis Boubaker Fatima Sabir
John Businge Andrés Paz
Steven Costiou Marco Ortu
Sabrine Edded Andrea Pinna
Diana El-Masri Cristiano Politowski
Zeinab (Azadeh) Kermansaravi
Ilaria Lunesu
Contents
Modelling
Semantic Software Capability Profile Based on Enterprise Architecture

for Software Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Abdelhadi Belfadel, Jannik Laval, Chantal Bonner Cherifi,
and Nejib Moalla
Safety Patterns for SysML: What Does OMG Specify? . . . . . . . . . . . . . . . . 19

Nan Niu, Logan Johnson, and Christopher Diltz
A Hybrid Approach Based on Reuse Techniques for Autonomic Adaptation

of Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Jamila Oukharijane, Mohamed Amine Chaâbane, Imen Ben Said,
Eric Andonoff, and Rafik Bouaziz
Reusable Formal Models for Threat Specification, Detection, and Treatment . . . 52

Quentin Rouland, Brahim Hamid, and Jason Jaskolka
Dynamic Reconfiguration of Cloud Composite Services Using Event-B . . . . . 69

Aida Lahouij, Lazhar Hamel, and Mohamed Graiet
Reuse in Practice
15 Years of Reuse Experience in Evolutionary Prototyping for the

Defense Industry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Pierre Laborde, Steven Costiou, Éric Le Pors, and Alain Plantec
CxDev: A Case Study in Domain Engineering for Customer eXperience

Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Imen Benzarti, Hafedh Mili, and Abderrahmane Leshob
Reengineering
Modular Moose: A New Generation of Software Reverse

Engineering Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Nicolas Anquetil, Anne Etien, Mahugnon H. Houekpetodji,
Benoit Verhaeghe, Stéphane Ducasse, Clotilde Toullec,
Fatiha Djareddir, Jerôme Sudich, and Moustapha Derras
DeepClone: Modeling Clones to Generate Code Predictions . . . . . . . . . . . . . 135

Muhammad Hammad, Önder Babur, Hamid Abdul Basit,
and Mark van den Brand
xii Contents
Analysing Microsoft Access Projects: Building a Model in a Partially

Observable Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Santiago Bragagnolo, Nicolas Anquetil, Stephane Ducasse,
Seriai Abderrahmane, and Mustapha Derras
Recommendation
Automated Reuse Recommendation of Product Line Assets Based

on Natural Language Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Muhammad Abbas, Mehrdad Saadatmand, Eduard Enoiu,
Daniel Sundamark, and Claes Lindskog
Learning to Recommend Trigger-Action Rules for End-User Development:

A Knowledge Graph Based Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Qinyue Wu, Beijun Shen, and Yuting Chen
AndroLib: Third-Party Software Library Recommendation

for Android Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Moataz Chouchen, Ali Ouni, and Mohamed Wiem Mkaouer
Empirical Analysis
Investigating the Impact of Functional Size Measurement on Predicting

Software Enhancement Effort Using Correlation-Based Feature Selection
Algorithm and SVR Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Zaineb Sakhrawi, Asma Sellami, and Nadia Bouassida
How Does Library Migration Impact Software Quality

and Comprehension? An Empirical Study . . . . . . . . . . . . . . . . . . . . . . . . . 245
Hussein Alrubaye, Deema Alshoaibi, Eman Alomar,
Mohamed Wiem Mkaouer, and Ali Ouni
How Do Developers Refactor Code to Improve Code Reusability? . . . . . . . . 261

Eman Abdullah AlOmar, Philip T. Rodriguez, Jordan Bowman, Tianjia
Wang, Benjamin Adepoju, Kevin Lopez, Christian Newman, Ali Ouni,
and Mohamed Wiem Mkaouer
Short Papers
Analyzing the Impact of Refactoring Variants on Feature Location . . . . . . . . 279

Amine Benmerzoug, Lamia Yessad, and Tewfik Ziadi
An Exploratory Study on How Software Reuse is Discussed

in Stack Overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Eman Abdullah AlOmar, Diego Barinas, Jiaqian Liu,
Mohamed Wiem Mkaouer, Ali Ouni, and Christian Newman
Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

Modelling
Semantic Software Capability Profile
Based on Enterprise Architecture
for Software Reuse
Abdelhadi Belfadel(B) , Jannik Laval, Chantal Bonner Cherifi,

and Nejib Moalla
University Lumière Lyon 2, DISP Laboratory, Lyon, France

abdelhadi.belfadel@univ-lyon2.fr
Abstract. Open source and software reuse become more and more chal-
lenging for companies to save time and development cost. Collecting
existing service-oriented solutions and qualifying them helps to reuse
them directly or via orchestration. Our objective in this research work
targets the consolidation of an advanced service repository able to be
directly mapped to end-user requirements for new business application
development. In this perspective, we define a model-based capability pro-
file based on Enterprise Architecture offering a wider view qualification
for service-oriented software. We propose a meta-model to gather archi-
tecture artifacts used to guide the development of existing solutions.
The generated capability profiles help to create a repository of software
capabilities. Furthermore, an ontology is proposed to exploit the resulted
capability profiles to guide the future business needs to reuse the qualified
software in an efficient way. This contribution aims to upgrade research
on dynamic services consumption and orchestration to the level of end-
users’ requirements mapped with advanced service assets as an enabler
for accelerating business application development.
Keywords: Capability profile · Enterprise architecture · Service

reuse · Requirements specification · Service oriented architecture ·
Ontology
1 Introduction
Information systems and technology are revolutionizing and transforming orga-
nization business. They are essential components of implementing any company’s
strategy to achieve its goals. Organisation’s business activities related to business
processes define how specific business tasks are performed and it can be assisted
by software tools and enterprise applications whose objective is the automation
of the exchanges in the business environment. In addition, these business pro-
cesses need to be adapted as a response to evolutions in external or internal
environments that become more and more complex such as variations in stake-
holders’ needs or business domain [1]. However, companies are facing problems to
c Springer Nature Switzerland AG 2020
S. Ben Sassi et al. (Eds.): ICSR 2020, LNCS 12541, pp. 3–18, 2020.
https://doi.org/10.1007/978-3-030-64694-3_1
4 A. Belfadel et al.
implement new ICT solutions, finding challenges both from IT vendors’ expen-
sive integrated digital solutions and from a myriad of disparate highly focused
technological open source solutions for specific functions. Besides the benefits
of open source software reuse such as the independence from vendors, or the
availability of source code, the complexity of the external software ecosystem
leads to difficulties in searching, evaluating and retrieving technical components
to reuse [2]. Factors such as lack of documentation, uncertainty on the quality
of the technical components, and the difficulty in searching and retrieving these
components are the most important factors preventing reuse [2].
Describing capabilities of software as capability profile and share or exchang-
ing the information of software capability through capability profile is an inter-
esting and valuable way to find and select adequate software components which
fit the requirement [3]. Several contributions and research works ([4–6] or [7]) pro-
posed solutions to describe the capability of services by specifying non-functional
attributes as Quality of Service, or adding semantics to functional attributes
enabling to realize ontology matching between requirements and services as in
[4] or [5]. Nevertheless, existing description or qualification works as mentioned
lack a wider view coverage for software capabilities, by taking into consideration
the business, operational and technical views of software and their related ser-
vices. As for example consideration of the constraints specification, technology
platform and execution environment regarding the software exposing the ser-
vices, or the requirements that assisted the realization and development of those
solutions.
To leverage internal and external solutions for companies, several approaches
might be considered. A component view with a concise evaluation model of soft-
ware components allow having a big picture of existing solutions, and facilitate
the discovery, selection and reuse decision. Also, an organization of the differ-
ent artifacts resulting from this qualification model, enables to facilitate deci-
sion making when choosing the suitable solution that fit the requirements. In
addition, focusing on service-oriented solutions, many opportunities for reuse of
functionality will arise, resulting in more efficient use of existing resources.
With regard to this context, we are targeting to (i) define a Capability Profile
for Software that describes components’ capabilities of software from technologi-
cal, technical, functional and organizational viewpoints along with its associated
quality and constraints; (ii) establish a common foundation for managing and
sharing the capability profiles and stakeholder concerns produced during the
evaluation or qualification process.
The expected results from this work are (i) An ISO and TOGAF-based meta-
model for Software Capability Profile that offers higher-level of functional repre-
sentations and covers the qualification of software components from the organi-
zational, business, operational and technical aspects; (ii) An ontology that pro-
vides a standard vocabulary for the produced knowledge preventing semantical
problems, and establish a common foundation for sharing produced capability
profiles among different stakeholders. However, to attend these objectives, some
problems have been identified. The first one is how to capture the architectural
Semantic Software Capability Profile Based on EA for Software Reuse 5
knowledge that guided the development of existing solutions for the evaluation
and reuse of software components? The second problem is how to consume archi-
tectural artifacts to improve software reuse?
To respond to this research problem, this paper is organized as follows: Sect. 2
focuses on the related work. We focus afterward on the principal building blocks
of the proposed solution in Sect. 3 and present the proposed Enterprise Archi-
tecture Capability Profile meta-model and an example of its derived model.
Section 4 presents an implementation of the derived ontology from the proposed
meta-model. Section 5 discusses our work and finally a conclusion is drawn in
Sect. 6.
2 Related Work
Based on the systematic analysis of relevant research works published between
2012 and 2019 regarding component or service description with consideration
of our needs, Table 1 classifies the related software and API description works
according to the following criteria:
– C1) Functional and technical description of the service interfaces, including

the business functions and their related inputs and outputs
– C2) Semantic annotations that defines the concepts
– C3) QoS description and the overall performance of a service
– C4) Description of the combinations of technology needed to achieve a par-
ticular technology stack
– C5) Organizational impact with a description of the business problems, stake-
holders, objectives and goals
– C6) Implementation or architecture specification stating measurable crite-
ria that should be met during the implementation of the architecture. The
typical content of these architectural requirements contains the implemen-
tation guidelines, implementation specifications, implementation standards,
and Interoperability requirements
– C7) Constraints specification that guided the development of the services as
business, technical, standard, technology or interoperability constraints
– C8) Reasoning capabilities to deduce logical consequences from a set of axioms
Out of Table 1, the related work based on OWL-S and WSMO have a wide
coverage for describing services regarding the needed criteria to achieve a wider
view coverage for service capabilities. However, very few works have considered
the constraints specification, technology platform and execution environment
regarding the software exposing the services, nor the organizational impact that
the service has on the organization where it is used.
To maximize and enable the reuse of the exposed features, we should go
beyond current research and service descriptions as depicted in Table 1. A rep-
resentation of a high-level view of IT systems and enterprises business processes
consuming the services is needed to provide a wider view qualification, by tak-
ing into consideration the business, operational and technical views of software
and their related services. This can be realized by considering an Enterprise

Architecture-based methodology for describing and classifying different artifacts
produced during previous projects to be available as building blocks for reuse in
future projects.
Table 1. Software and service description works
Software/service capability C1 C2 C3 C4 C5 C6 C7 C8
description
Haniewicz et al. 2012 [8], + +
Verborgh et al. 2013 [9],
Bravo et al. 2014 [10],
Alarcon et al. 2015 [11]
Barros et al. 2012 [12], + +
Ghazouani et al. 2017 [13]
Mezni et al. 2012 [14], + +
Keppeler et al. 2014 [15]
Matsuda et al. 2012 [3] + + +
Pedrinaci et al. 2014 [16] + + +
Narock et al. 2014 [7] + + + + +
Wei et al. 2014 [17], Roman + + + +
et al. 2015 [18], Chhun et al.
2016 [19], Ghazouani et al.
2017 [20], Ben Sassi 2016
[21], Yanes et al. 2017 [22],
De et al. 2017 [23], Khodadadi +
et al. 2015 [24]
Benfenatki et al. 2017 [25] + + + +

Khanfir et al. 2015 [6] + + + + +
3 Enterprise Architecture Capability Profile for Software

Reuse
Our goal is to maximize the reuse of an organization’s internal and external
software by improving the capability description of existing solutions, and by
describing the functional and non-functional properties of existing solutions with
their related constraints. For this purpose, we propose the Enterprise Architec-
ture Capability Profile (EACP) which is based on TOGAF Framework [26] and
its Architecture Development Method (ADM). This proposed meta-model offers
high-level of functional representations and covers the qualification of software
from the organizational, business, operational and technical aspects.
3.1 EACP Meta-Model

The proposed EACP Capability Profile is depicted in Fig. 1 and is inspired mainly
from TOGAF [26], ISO 16100 [27], ISO 25010 [28] and MicrosoftApplication
R
Architecture Guide [29]. It gathers functional and non-functional specifications;
organizational impact and connects business services to their associated physi-
cal components to offer a broader view qualification. The proposed meta-model
is composed of 6 packages:
1. Organization package outlines the organizational unit with its associated busi-
ness goals and objectives that led to the development of the software.
2. Architecture Building Blocks (ABBs) package is built based on the construc-
tion life-cycle of the architecture building blocks of the ADM method. This
package outlines the business problem for what this component was developed
for, the chosen standards, stakeholders concerns and implementation specifi-
cation. It gathers other details for instance the operational vision of the com-
ponent, the business function, its attributes and constraints, application and
data interoperability requirements and design time quality attributes based on
best practices and guidelines from ISO 25010 [28] and MicrosoftApplication
R
Architecture Guide [29]. An example of the derived ABB model is depicted
in Fig. 2.
3. Solution Building Blocks package (SBB) represent the physical counterpart
of ABBs. The SBB is related to the exposed service or API (e.g. REST-based
API). It is described by the URI, the HTTP method needed to reach the
resource, the related parameters and the serialisation used in communication
(e.g. JSON). Moreover, it defines run time quality metrics and transversal
attributes (e.g. security setup such as authentication or authorization param-
eters).
4. Application package gathers technical requirements of the service-oriented
software in general with its exposed components. It gathers also the execution
environments on which the application is running (e.g. Platform class).
5. Business Process package is composed of the activities that compose the tar-
geted business application, the actors, roles, and the event that triggers the
process. This package will be used in the exploitation phase and represents
the “to-be” business application to realize.
6. Requirements package gathers requirements produced during an elicitation
process, helping to guide the developer or the architect during the engineering
lifecycle. This package will be used during the exploitation phase.
In case of services or Web APIs, QoS parameters such as availability, response

time and reliability are among the most important ones [30]. However, the design
of services is influenced by the environment, the context and other decisions
made by service designers [31], and this may lead to violations of quality prin-
ciples known as antipatterns [31]. Thus, to guide an organization in a future
exploitation and reuse of any solution, whether it’s an internal or external com-
pany’s solution, we aligned different metrics from ISO 25010 [28] recommended
technical indicators, extended with best practices from MicrosoftApplication
R
Fig. 1. EACP proposed meta-model
Architecture Guide [29] and TOGAF Technical Reference Model [26] which is
universally applicable used to build any system architecture. Obviously, the pro-
posed meta-model may be enhanced with new indicators if necessary.
To facilitate the discovery and reuse of the qualified solutions based on the
proposed EACP Capability Profile, we present in the next Sect. 4 the implemen-
tation work to design an Enterprise Architecture Knowledge Repository (EAKR)
that will gather the defined capability profiles. This latter is based on a specific
ontology that offers a standard vocabulary, and a formal language to reason
about software semantic annotation tags and infer new knowledge to answer to
future business needs.
4 Implementation and Validation of the EACP
We present in this subsection the different steps that we followed to design the
Enterprise Architecture Capability Profile Ontology. We considered the Uschold
and King’s methodology presented in [32] for two main reasons: based on the
literature review this methodology is one of the most cited methodologies and
Fig. 2. Proposed model for ABBs
it explains in details all the steps required in the ontology development process.
Here, we present the different steps that we followed.
First, we define the scope of the targeted ontology by exposing some com-
petency questions (CQs). We analyze the relevant entities such as individuals,
classes, and their relationships, and we examine their important characteristics,
for instance, the transitivity of a relation or subsumption between two entities to
document the domain knowledge. We note that the competency questions cited
below are not representative of all expected or intended usages of this ontology.
– CQ1: Retrieve Business Objectives related to business goals

– CQ2: Retrieve the list of ABBs from end-users’ requirements based on busi-
ness function definition and related data entities
– CQ3: Retrieve SBBs related to selected ABBs
Second, we identified from state-of-the-art solutions some existing ontologies

that enable to cover some of our needs such as Basic Formal Ontology (BFO)
which is a top-level ontology and four domain ontologies, namely Ontology Web
Language for Services (OWL-S) [33], The Open Group Architecture Framework
ontology (TOGAF-Ontology) [34] and Information Artifact Ontology (IAO).
These ontologies are well-defined, consistent and reused in other projects. We
have followed a modular architecture, that consist of the main ontology import-
ing several modules. The main motivation for this design choice was the possi-
bility to easily extract entities from already existing ontologies. [35].
Third, we managed the selected foundational and domain ontologies, by inte-
grating and extending in a coherent way the different ontologies into the targeted
EACP ontology using the Protégé Ontology Editor.
Finally, we evaluated the consistency and inferences of the resulted model
using the Fact++ reasoner.
In the following subsections, the “Italic” form is used to designate semantic
classes and ontology relationships. Regarding the latter, labels such as BFO,
OWL-S or TOGAF are used instead of the Internationalized Resource Identifier
(IRI) for the stake of legibility.
4.1 Construction Steps of the EACP Ontology
We depict in this section the construction steps of the EACP ontology from the
meta-model presented in Sect. 3.1 with regards to the main steps of our ontology
building approach.
Step 1: identification of existing ontologies In the proposed semantic

model, we have described all entities of the meta-model. The resulted ontology
contains 230 classes, 78 object properties, and 30 data properties.
The targeted modular EACP ontology defines its entities and relations under
the BFO framework. This latter is designed to support information analysis,
retrieval and integration from different semantic resources [36]. To map EACP
entities to BFO, we realized the alignment based on the methodology described
in [36].
We choose to reuse the BFO based ontology, namely IAO ontology, to model
information artifacts of the meta-model (e.g., conditional specification, objective
specification, and goal specification). In terms of implementation, IAO is easy
to integrate given that it is already based on the foundational ontology BFO.
Moreover, we chose to reuse TOGAF 9 ontology for three main reasons: first,
TOGAF 9 ontology, developed in Knowledge-Projects1 , is the most suitable
terminological model that represents meta-data of TOGAF 9 artifacts. Second,
it has been used in other research works in [37] and [38], to semantically manage
and share enterprise architecture information and third, TOGAF 9 ontology
meets some of main modeling needs that are expressed in the meta-model as
the description of entities that describe Business Architecture Component (e.g.,
actor, organizational unit, objective, goal, and event). In this work, we used the
OWL formal language in the specification of the Terminological Box (TBox) and
in the generation of Resource Description Framework (RDF) [39] triples.
1
https://sites.google.com/site/ontologyprojects/home.
Step 2: Integration of Existing Ontologies into the BFO Ontology

(classes and Relations) To achieve semantic compatibility within our resulted
domain ontology, we link candidate domain ontologies to the BFO ontology. The
basic pattern of the main classes in the EACP ontology is illustrated in Fig. 3
and the followed steps of the alignment task are detailed below.
Fig. 3. Alignment of top-level domain classes (IAO, TOGAF, EACP, OWL-S and
BPMN) under the BFO ontology
To build this OWL ontology, we first analyzed the class hierarchy of our
semantic modules (namely, TOGAF, BPMN, IAO and OWL-S). Then, we
aligned existing ontologies’ classes to the BFO class hierarchy according to
the BFO principles. By doing this alignment work, we improved the defini-
tion of key concepts of the TOGAF ontology by making them explicit. For
example the class “TOGAF:core content” regroups heterogeneous sub-classes as
“TOGAF:function”, “TOGAF:process”, “TOGAF:capability”, “TOGAF:role”
and “TOGAF:organization unit”. As we can notice, the meaning of the
“TOGAF:core content” class as it is defined within the TOGAF ontology is
confusing and ambiguous regarding the description of the kind of data that it
covers. In order to remove this confusion and inconsistency, we first defined the
class “TOGAF:content classification” as a “BFO:entity”, and then we defined
the classes like “TOGAF:function”, “TOGAF:role”, “TOGAF:capability” as sub
classes of “TOGAF:core content” and “BFO:specifically dependent continuant”
given that they describe a continuant that inheres in or is borne by other entities.
As consequence, the meanings of theses sub-classes are more explicit and clear
under the BFO framework. An overview of top-level domain classes mapping

into the BFO ontology is shown in Fig. 3.
After describing classes, we aligned the object properties of existing ontolo-
gies to the BFO relationship hierarchy in order to ensure the integrity of our
ontology. Table 2 summarizes the BFO object properties that we used in the
resulted ontology in order to semantically describe the relationships of the meta-
model. We introduced data properties in the ontology as the data property
“EACP:hasDescription” to specify a textual description of artifacts. This data
property can be use for example to link a “TOGAF:goal ” to its value, for instance
“efficiency in business operation to increase productivity”.
Table 2. Top-level relationship mappings to cover the upper-level relations of the

meta-model
Meta-model relation Direct relation in EACP Parent relation in EACP

ontology ontology
Has (between BFO:hasContinuantPart BFO:topObjectProperty
continuant entities)
BFO:hasFunction RO:bearerOf
BFO:hasSpecifiedInput BFO:hasParticipant
Has (between occurrent BFO:hasOccurrentPart BFO:topObjectProperty
entities)
Represents, describes IAO:isQualityMeasurementOf IAO:isAbout
IAO:denotes IAO:isAbout
Step 3: Extension of Existing Ontologies New 30 additional classes are

inserted in the EACP ontology based on the proposed meta-model. For exam-
ple, we introduced the “EACP:ABB service category” class as a direct sub-
class of “IAO:data item” and an indirect subclass of “BFO:generically depen-
dent continuant”. Therefore, “EACP:ABB service category” is assumed to
be a superconcept of the classes “EACP:maintainability”, “EACP:security”,
“EACP:capability” and “EACP:interoperability”. We adopted the follow-
ing naming convention: for classes borrowed from existing ontologies in
general, we kept existing IRIs, as well as existing annotations (e.g.
“RDFS:label ”,“RDFS:prefLabel ”). For new EACP classes, we assigned new IRIs
(based on English labels) as well as “RDFS:prefLabel ” in English.
The ontology is enriched with semantic axioms in order to define in a concise
way classes and relations and to improve the ontology with reasoning capabilities.
In what follows, we explain how we semantically describe the ABB class and
link this entity to others EA associated entities (e.g., SBB, business activity,
and business objectives).
We defined the class “EACP:architecture building blocks” as a subclass of

the “TOGAF:business service” class, and by using the necessary conditions (i.e.,
existential restrictions) listed below:
– “BFO:hasContinuantPart” some “EACP:solution building blocks”,
– “BFO:hasContinuantPart” some “TOGAF:parameter ”,
– “BFO:hasContinuantPart” some “OWL-S:service category”,
– “IAO:isAbout” some “EACP:software function”,
– “BFO:realizedBy” some “TOGAF:process”.
To complete the definition of the class “EACP:architecture building blocks”
we directly state that this class is disjoint with the class “EACP:solution
Building Blocks”. And given that, “EACP:architecture building blocks” isA
“TOGAF:business service” as consequence it is disjoint with all the subclasses of
the class “TOGAF:business architecture component” (i.e., actor, service quality,
event, process, or organizational unit).
In TOGAF ontology the concept “TOGAF:business service” is A
subconcept of the concept “TOGAF:business architecture component”.
The class “TOGAF:business architecture” is defined using an equivalent
class property: [equivalentClass] “TOGAF:architecture” and (“BFO:continuant
PartAtSomeTime” only “TOGAF:business architecture component”). We note
that a necessary and sufficient condition are called Equivalent classes in OWL.
We made some modeling decisions about the description of some unclear
TOGAF aspects: we interrelate classes using a min number of relationships than
those proposed in TOGAF ontology. This will improve the reasoning perfor-
mance of the EACP ontology. In TOAGF, there is a mix between class hier-
archy and necessary conditions for example, the “TOGAF:business architec-
ture” is defined as “TOGAF:architecture” and (“BFO:hasContinuantPart” some
“TOGAF:business architecture component). We modified the some OWL restric-
tion with a some necessary condition as explained above. This correction is valid
for all the kind of business architecture component of the TOGAF ontology.
Finally, we completed the definition of the EACP ontology with textual anno-
tations that aim to give the users more details about our ontology components;
in this annotation task we based our textual definitions on the documentation
of TOGAF 9.
Step 4: Evaluation of the Consistency To check the validity and the cor-
rectness of the designed ontology, we first populated the ontology manually, then
used the Fact++ reasoner. The classification result is presented in the left side
of Fig. 4. Inferred assertions are presented based on the axioms described in step
3 of Sect. 4.1. No errors are found and all classes and relations are correctly
classified.
Step 5: EACP-Onto Based Qualification Example We illustrate in Fig. 5

an excerpt in RDF format of an Architecture Building Block which is the piv-
otal instance in this graph, and annotated with “Abb 3DScan 3Dobject”. It
represents a REST API which is titled “Get 3D Object”.
Fig. 4. Data validation, reasoning and querying result on the EAKR repository using
the FACT++ reasoner, Protégé Ontology Editor
Fig. 5. An excerpt in RDF format of an architecture building block. Gray boxes refer
to classes of the ECAP-Onto. Instance level relations are modeled with arcs.
The value of this ABB is included in the capability profile of the

exposed API. We leveraged the object property “BFO:hasContinuantPart” to
describe the composition between two instances. Regarding the data property
“RDFS:label”, it enables to define the textual content of an instance, for exam-

ple “EACP:3DScan Get 3D Object” has as label the following value “Reduce
the manufacturing production cost”.
This kind of annotation work enables to formalize and classify service capa-
bility profiles through several requests, for example the selection or retrieval of
ABBs from user requirements that is based on business objectives or goals.
5 Discussion
In this work, we proposed a semantic Enterprise Architecture Capability Profile
specifically designed to describe the properties, design constraints, and capabil-
ities of service-oriented software. This helps to offer a wider view qualification
process that deals with business and technical perspectives of software services.
The business perspective brings value-in-use of the qualified feature for an orga-
nization that is interested into reuse, and the technical perspective along with a
quality of service describe the feature encapsulated by the software service.
The use of a semantic approach helped us in the formalization of the content
of the proposed meta-model through the use of OWL language that explicitly
specifies the meaning of EA meta-model entities and relations. Added to this,
the proposed semantic model called EACP ontology supports advanced reason-
ing and querying requests on the Enterprise Architecture Knowledge Repository
that facilitates the discovery, comprehension and reuse of service-oriented soft-
ware meta-data (capabilities, parameters, requirements, etc.). We note that the
automatic content-based data management cannot be achieved in existing EA
meta-models that do not use semantic markup. We adopted a semantic approach
to describe EA information and we presented the different steps that we followed
to design the EACP ontology.
Unlike existing EA ontologies mainly TOGAF first, the developed ontology
is based on a foundational ontology namely BFO. Second, it is based on exist-
ing well-defined ontologies to cover all the meta-model components (functional,
operational and technical). Third, the EACP ontology is modular, thus it can
be easily extended by future users. Finally, the EACP ontology defines a data
properties hierarchy to specify concrete values of concepts use cases.
The use of BFO has facilitated the integration of heterogeneous knowledge
from different ontologies into a unique coherent semantic model. In most cases
the alignment was not a trivial task for us for two main reasons: the complexity
of the meta-model on one hand, and on another hand the ambiguity of TOGAF
OWL concepts and object relations.
The usage of an ontology for designing the model-based capability profile
enables to achieve the targeted objectives and address the major challenges,
namely create a software capability profile that is modular, flexible, and exten-
sible with a standard vocabulary to qualify existing solutions with semantic
annotations. This helps either to capitalize on existing knowledge produced dur-
ing a software development lifecycle and infer new knowledge to answer future
business needs.
As future work, we intend to exploit this model-based semantic repository

for the discovery and reuse of the qualified solutions based on a requirements
engineering and an entreprise architecture approach. This to support developers
or architects for requirements elicitation during the engineering life-cycle. Fur-
thermore, we intend to capitalize on artifacts produced during the engineering
cycle of the projects to offer more visibility and sustainability to software for
accelerating future business application development.
6 Conclusion
The objective of this work is to create a profile for describing software capabili-
ties. This will allow us to discover and reuse suitable software and related services
for the design and implementation of new business applications. A meta-model is
proposed and based on an Enterprise Architecture Framework (TOGAF). This
later is combined with dynamic quality metrics needed for services selection.
This meta-model offers a wider view qualification for software and its related ser-
vices covering business, technical and organizational aspects. A detailed model is
proposed for every aspect in order to design the repository gathering the qualifi-
cations. This helps to support software discovery during the engineering lifecycle
of new business needs.
Acknowledgment. This paper presents work developed in the scope of the project
vf-OS. This project has received funding from the European Union’s Horizon 2020
research and innovation programme under grant agreement no. 723710. The content of
this paper does not reflect the official opinion of the European Union. Responsibility
for the information and views expressed in this paper lies entirely with the authors.
References
1. Valenca, G., Alves, C., Alves, V., Niu, N.: A systematic mapping study on business
process variability. Int. J. Comput. Sci. Inf. Technol. 5(1), 1 (2013)
2. Kakarontzas, G., Katsaros, P., Stamelos, I.: Component certification as a prerequi-
site for widespread OSS reuse. In: Electronic Communications of the EASST, vol.
33 (2010)
3. Matsuda, M.: Manufacturing software interoperability services which ISO 16100
brings about. In: van Sinderen, M., Johnson, P., Xu, X., Doumeingts, G. (eds.)
IWEI 2012. LNBIP, vol. 122, pp. 60–70. Springer, Heidelberg (2012). https://doi.
org/10.1007/978-3-642-33068-1 7
4. Chhun, S., Cherifi, C., Moalla, N., Ouzrout, Y.: A multi-criteria service selection
algorithm for business process requirements. CoRR, vol. abs/1505.03998 (2015)
5. Boissel-Dallier, N., Benaben, F., Lorré, J.-P., Pingaud, H.: Mediation information
system engineering based on hybrid service composition mechanism. J. Syst. Softw.
108, 39–59 (2015)
6. Khanfir, E., Djmeaa, R.B., Amous, I.: Quality and context awareness intention web
service ontology. In: 2015 IEEE World Congress on Services, pp. 121–125. IEEE
(2015)
7. Narock, T., Yoon, V., March, S.: A provenance-based approach to semantic web
service description and discovery. Decis. Support Syst. 64, 90–99 (2014)
8. Haniewicz, K.: Local controlled vocabulary for modern web service description.
In: Rutkowski, L., Korytkowski, M., Scherer, R., Tadeusiewicz, R., Zadeh, L.A.,
Zurada, J.M. (eds.) ICAISC 2012. LNCS (LNAI), vol. 7267, pp. 639–646. Springer,
Heidelberg (2012). https://doi.org/10.1007/978-3-642-29347-4 74
9. Verborgh, R., Steiner, T., Van Deursen, D., De Roo, J., Van de Walle, R., Vallés,
J.G.: Capturing the functionality of web services with functional descriptions. Mul-
timedia Tools Appl. 64(2), 365–387 (2013)
10. Oliveira, B.C., Huf, A., Salvadori, I.L., Siqueira, F.: Ontogenesis: an architecture
for automatic semantic enhancement of data services. Int. J. Web Inf. Syst. 15(1),
2–27 (2019)
11. Alarcon, R., Saffie, R., Bravo, N., Cabello, J.: REST web service description
for graph-based service discovery. In: Cimiano, P., Frasincar, F., Houben, G.-J.,
Schwabe, D. (eds.) ICWE 2015. LNCS, vol. 9114, pp. 461–478. Springer, Cham
(2015). https://doi.org/10.1007/978-3-319-19890-3 30
12. Birkmeier, D.Q., Overhage, S., Schlauderer, S., Turowski, K.: How complete is the
USDL? In: Barros, A., Oberle, D. (eds.) Handbook of Service Description, pp.
521–538. Springer, Boston, MA (2012). https://doi.org/10.1007/978-1-4614-1864-
1 21
13. Ghazouani, S., Slimani, Y.: A survey on cloud service description. J. Network
Comput. Appl. 91, 61–74 (2017)
14. Mezni, H., Chainbi, W., Ghedira, K.: Aws-policy: an extension for autonomic web
service description. Procedia Comput. Sci. 10, 915–920 (2012)
15. Jonas, P.B., Gewald, H.: A description and retrieval model for web services includ-
ing extended semantic and commercial attributes. In: 2014 IEEE 8th International
Symposium on Service Oriented System Engineering, pp. 258–265. IEEE (2014)
16. Pedrinaci, C., Cardoso, J., Leidig, T.: Linked USDL: a vocabulary for web-scale
service trading. In: Presutti, V., d’Amato, C., Gandon, F., d’Aquin, M., Staab, S.,
Tordai, A. (eds.) ESWC 2014. LNCS, vol. 8465, pp. 68–82. Springer, Cham (2014).
https://doi.org/10.1007/978-3-319-07443-6 6
17. Wei-bing, M., Wen-guang, W., Yi-fan, Z., Fa-yi, Y.: Semantic web services descrip-
tion based on command and control interaction user context. In: 2014 IEEE 7th
Joint International Information Technology and Artificial Intelligence Conference,
pp. 541–544. IEEE (2014)
18. Roman, D., Kopeckỳ, J., Vitvar, T., Domingue, J., Fensel, D.: WSMO-lite and
hRESTS: lightweight semantic annotations for web services and restful APIs. J.
Web Semant. 31, 39–58 (2015)
19. Chhun, S., Moalla, N., Ouzrout, Y.: QoS ontology for service selection and reuse.
J. Intell. Manuf. 27(1), 187–199 (2016)
20. Ghazouani, S., Slimani, Y.: Towards a standardized cloud service description based
on USDL. J. Syst. Softw. 132, 1–20 (2017)
21. Ben Sassi, S.: Towards a semantic search engine for open source software. In:
Kapitsaki, G.M., Santana de Almeida, E. (eds.) ICSR 2016. LNCS, vol. 9679, pp.
300–314. Springer, Cham (2016). https://doi.org/10.1007/978-3-319-35122-3 20
22. Yanes, N., Sassi, S.B., Ghezala, H.H.B.: Ontology-based recommender system for
cots components. J. Syst. Softw. 132, 283–297 (2017)
23. De, B.: API management. API Management, pp. 15–28. Apress, Berkeley, CA
(2017). https://doi.org/10.1007/978-1-4842-1305-6 2
24. Khodadadi, F., Dastjerdi, A.V., Buyya, R.: Simurgh: a framework for effective
discovery, programming, and integration of services exposed in IoT. In: 2015 Inter-
national Conference on Recent Advances in Internet of Things (RIoT), pp. 1–6.
IEEE (2015)
25. Benfenatki, H., Da Silva, C.F., Benharkat, A.-N., Ghodous, P., Maamar, Z.: Linked
USDL extension for describing business services and users’ requirements in a cloud
context. Int. J. Syst. Serv.-Orient. Eng. (IJSSOE) 7(3), 15–31 (2017)
26. T. O. Group: The Open Group Architecture Framework TOGAFT M Version 9.
Basharat Hussain (2009)
27. ISO 16100–1:2009 industrial automation systems and integration - manufacturing
software capability profiling for interoperability - part 1: Framework (2009)
28. ISO/IEC 25010:2011 systems and software engineering - systems and software qual-
ity requirements and evaluation (square) - system and software quality models
(2011)
29. Patterns, M., P. Team: Microsoft R Application Architecture Guide, 2nd Edition
(Patterns and Practices). Microsoft Press (2009)
30. Al-Masri, E., Mahmoud, Q.H.: QoS-based discovery and ranking of web services. In:
2007 16th International Conference on Computer Communications and Networks,
pp. 529–534. IEEE (2007)
31. Ouni, A., Kessentini, M., Inoue, K., Cinnéide, M.O.: Search-based web service
antipatterns detection. IEEE Trans. Serv. Comput. 10(4), 603–617 (2015)
32. Uschold, M., King, M.: Towards a methodology for building ontologies (1995)
33. Martin, D., et al.: Bringing semantics to web services: the OWL-S approach. In:
Cardoso, J., Sheth, A. (eds.) SWSWPC 2004. LNCS, vol. 3387, pp. 26–42. Springer,
Heidelberg (2005). https://doi.org/10.1007/978-3-540-30581-1 4
34. Gerber, A., Kotzé, P., Van der Merwe, A.: Towards the formalisation of the TOGAF
content metamodel using ontologies (2010)
35. Ceusters, W.: An information artifact ontology perspective on data collections and
associated representational artifacts. In: MIE, pp. 68–72 (2012)
36. Arp, R., Smith, B., Spear, A.D.: Building Ontologies with Basic Formal Ontology.
MIT Press, Cambridge (2015)
37. Czarnecki, A., Orlowski, C.: Ontology as a tool for the it management standards
support. In: Jedrzejowicz,
P., Nguyen, N.T., Howlet, R.J., Jain, L.C. (eds.) KES-
AMSTA 2010. LNCS (LNAI), vol. 6071, pp. 330–339. Springer, Heidelberg (2010).
https://doi.org/10.1007/978-3-642-13541-5 34
38. Chen, W., Hess, C., Langermeier, M., von Stülpnagel, J., Diefenthaler, P.: Semantic
enterprise architecture management. ICEIS 3, 318–325 (2013)
39. Lassila, O., Swick, R.R., et al.: Resource description framework (RDF) model and
syntax specification (1998)
Another random document with
no related content on Scribd:
CHAPTER III.
Suitable Breeds. Group Three—Medium-Sized
Dogs.
As with the terrier varieties, there is a wide field for selection among
the medium-sized dogs, both sporting and non-sporting;
consequently much depends upon what the dog is intended for. If
any of the members of the household are inclined to sports afield,
then one of the many varieties of spaniels would make a suitable
house companion, for aside from being an alert watch dog, he is a
natural all round hunter and is equally good on upland game as on
water fowl. Spaniels make excellent retrievers, very good grouse and
quail dogs where the mere questing for and finding of game is
desired, but naturally the dog should be educated for the purpose.
Unlike the pointer, the setter, or the griffon, the spaniel does not
point, but finds the game and flushes it in front of the sportsman; in
view of this fact he must be trained to quest within gun range. This,
however, is easily taught the spaniel, for all of the many varieties are
intelligent animals and therefore easily educated. A spaniel makes
an excellent dog for ladies who enjoy field shooting, for the reason
that he is so much more easily handled than any of the bird dog
varieties, and peculiarly amenable to the gentler sex.
As a guardian of the home the spaniel might not strike terror to the
hearts of unwelcome intruders, like some of the terrier or other
breeds, but they are good watch dogs, quick to give the alarm upon
the approach of strangers, and besides, they are very docile and
cleanly about the premises. There may be some objection to the
long coat, on the ground that if the animal is shedding, he is prone to
leave stray hairs on rugs and furniture, but in this connection it might
be said that daily grooming will ameliorate this evil to a great extent,
for after all is said, a dog that is allowed to frequent the house even
during only a small part of the day, must be kept clean whether he is
a long or a short-haired one.
THE COCKER SPANIEL, CHAMPION OBO II.
Of the many varieties of spaniel, the Cocker is the most popular.
They come in all colors; solid blacks, reds, creams, orange and
browns, but if of the latter color, it should be of a rich liver and not the
washed out shades which sometimes crop out in a litter. These off-
color ones should be eschewed if one wishes to conform to the
standard. Neither should the whole-colored dogs have white on
them, but a strip of this color on the chest, while objectionable,
should not disqualify. The parti-colors are also very handsome
animals. These are white and black, liver and white, orange and
white, cream and white, and roans; either blue or red.
The standard weight calls for cockers ranging from eighteen to
twenty-four pounds. Here of late it has become fashionable to breed
them down to the minimum weight, but this is almost making toys of
what was once considered one of the principal sporting breeds. If the
prospective purchaser intends to use his dog for sporting purposes
he is advised to select one from stock that will come nearer reaching
the maximum rather than the minimum weight, for the eighteen
pound cocker is entirely too small for utility purposes. As a matter of
fact, some years ago twenty-eight pounds was the standard
maximum weight of working cockers which is really more logical in a
dog that is intended for field work. At all events, it is better to have a
cocker over, than under the weight allowed by the standard, if one
expects to make use of him afield.
The cocker should be a neat-headed, wide-awake, serviceable
looking little dog, with rather large dark eyes and an intelligent
expression. He should stand on strong, well-boned, but short legs
absolutely straight in front, with well bent stifles behind. His quarters
should be muscular and powerful, especially when viewed from
behind; short in body when viewed from above, yet standing over
considerable ground. He should, in short, give one the impression of
a massive little dog, yet at the same time, he must have
considerable speed and endurance. The coat is flat or slightly wavy,
silky and very dense, with ample feather on legs and his feet should
also be well supplied with hair, but the coat should never be curly.
The stern is usually docked to a length of about two or three inches.
This should be carried just below the level of the back and when the
dog is working or animated, its action should be merry, but never
carried gaily.
The Field Spaniel may be described as a larger edition of the cocker;
longer and lower in body in proportion to his general make-up, but a
well-knit, massive dog, the males weighing from thirty-seven to forty-
five pounds, the bitches about five pounds less. The true field
spaniel is always black, though his near kin is the springer which
comes in parti-colors also. There are various strains of the springer
spaniel, as for instance the Welsh and the English, but in all
essentials they are identical. The difference between the springer
and the field spaniel is that the former is usually shorter in body and
higher on the leg. In the matter of intelligence he is fully the equal of
the cocker or the field spaniel and for field work he is probably the
most practical of the three, especially when it comes to retrieving
waterfowl.
The Clumber Spaniel is the largest of the land spaniels, the weight in
males ranging from fifty-five to sixty-five pounds, the females from
thirty-five to fifty pounds. He is a strong, sturdy, compact dog, with
profuse coat, but a smaller ear of the V-shaped variety. In color he
must always be white and lemon or white and orange, ticks on the
head or fore legs add to his beauty. He should have few, if any
markings on his body. This variety is not very numerous in this
country, though in many parts of England he is used quite regularly
as a sporting dog.
The Sussex is another variety of the large land spaniels, smaller,
however, than the Clumber, weighing from thirty-five to forty-five
pounds. In color he is a rich golden liver. In this country he is
practically unknown, but he is numbered as among the oldest of
breeds in England.
The Irish Water Spaniel scarcely comes within the province of this
book. He is a large dog, standing well up on the leg. It is said that he
is a cross between the Irish setter and the large poodle, but this may
be all conjecture. At all events he stands as high at the shoulder as
an Irish setter. In color he is liver; any white except on chest or toes,
disqualifies. His coat is a mass of short curls back to his tail which
should be entirely free from feather. On his skull he has a well-
defined top-knot; indeed, this is one of the distinguishing marks of
the breed. As a house dog he is almost too large though for wild fowl
retrieving under any and all weather conditions, he is par excellence.
THE CHOW, LORD CHUMLEY.
Among the non-sporting medium-sized breeds, the Chow Chow
stands preeminently to the forefront. He is a Chinese breed, like the
Pekingese, and considering that he breeds very true to type, it is
possible that he is of more ancient origin than many of our much
lauded “pure breeds” of England. The chow is given credit for being
a very intelligent animal; he is a good house dog and a faithful
companion. In size he is about like the old-fashioned Spitz dog from
which the Pomeranian is descended. In color he should be either
black, red, yellow, blue, or white, but the shade should run uniform
except that the underpart of the tail and inside of thighs are
frequently of a lighter shade. He carries his tail curled over his back;
his coat should be abundant, dense, straight and somewhat coarse
in texture, with a soft, wooly undercoat. His ears are carried erect.
He has a rather peculiar sour expression and his eyes are dark and
small in all but the blues, in which a light color is permissible. One of
the distinguishing features of a chow is his tongue, which in pure
specimens is blue-black. His nose should also be black, large and
wide.
The chow became popular about a quarter of a century ago, then for
a time the interest lagged, but of late years his popularity seems to
be increasing once more. The dog is perhaps among what one might
call the high-priced varieties, but it is always possible to buy a
“waster” which will answer the same purpose for a companion as the
perfect show dog. A breeder of chows once said to me: “This breed
has all the oriental mysticism about it that one finds in everything that
comes from the Far East; they seem to know what you are thinking
about and at times, as they lie there on the rug, one imagines they
are actually going to speak and tell you what they have on their
minds. But once your friend, a chow is always your friend.”
THE FRENCH BULLDOG, CH. GUGUSSE, JR.
The French Bulldog is another breed that has come into great
popularity during the past fifteen years, especially among the ladies.
As far as his actual usefulness is concerned, we cannot say much,
although his admirers might probably take one to task if this
statement were made in their presence. He makes a delightful
companion, smooth of coat and clean in his habits. For the house he
is probably one of the most desirable breeds among the many, even
though his real utility might be questioned. However that may be, the
dog is popular and good specimens command high prices.
In appearance the French bulldog resembles the Boston in many
respects—that is, a Boston of the heavier type and with uncut ears,
but he is more muscular and substantial in appearance. His ears
must be of the pronounced “bat” variety; his head, large, square and
broad; skull almost flat; the underjaw, like the English bulldog, is
large, powerful, and undershot, with the muzzle well laid back and
the muscles of the cheeks fully developed. The tail should be either
straight or screwed (but not curly) short, and hung low. The eyes are
wide apart set low down in the skull, as far away from the ears as
possible. Back must be short, the chest broad, the forelegs straight
and muscular and wide apart, while the hind legs should correspond
in the matter indicating strength. The French bulldog standard calls
for two weights; dogs under twenty-two pounds and those of twenty-
two pounds and not exceeding twenty-eight. The colors are any
shade of brindle, though the darker the better. The novice looking for
a good specimen, however, should be careful about the absolute
disqualifying points as for instance, other than bat ears, any
mutilation, solid black, black and white, black and tan, liver and
mouse color, eyes of different color (as they will come sometimes),
nose other than black and hare lip, which is also a fault that
frequently crops up and many unscrupulous breeders are apt to foist
such undesirable specimens upon the unsuspecting novice who
might be none the wiser.
The English Bulldog is another of the “manufactured breeds” so
grotesquely ugly that he is beautiful in the eyes of some. The bulldog
will attract attention anywhere, but as to his sphere of usefulness in
these days of his grotesque appearance, there is always room for
doubt. There was once a time when the bulldog was a shifty and
useful animal, but as he is at present bred, this quality has, to a great
extent disappeared with his “improvement,” although his admirers
will claim stoutly that he is a good watch dog and quite intelligent.
His very artificiality makes him a dog which is difficult to rear, being
susceptible to various diseases to a much greater degree than most
of the more normal breeds.
THE BADGER BITCH BERTHA VON STROMBERG.
This breed was formerly known as the dachshund.
Everyone, even he who is only remotely interested in dogs, knows
the Badger Dog, if not under this name, at least under his old
appellation of dachshund, by which he was known up to the time of
the World War when his Teutonic origin was expediently disguised
under the name that he now bears. Owing to his length of body and
his abbreviated legs he has always been known as the original
“sausage” dog, for his length of body is several times his inches in
height, which should be, at shoulder, only from 7 1/8 to 8 1/5 inches.
The weight is divided at bench shows, as for instance, dogs under
sixteen and one-half pounds, bitches under fifteen and one-half
pounds. Middleweights from the maximum lightweight division to
twenty-two pounds. Heavyweights, dogs and bitches over twenty-two
pounds.
The badger dog, while not classified among the terriers, has the
characteristics of that family, for he goes to ground for his quarry,
and in every other way shows his terrier characteristics. On the other
hand, he is also a fairly good trailer and, like the beagle, will hunt
rabbits. As a house companion he is intelligent and cleanly; his
short, satiny coat fitting him eminently for a ladies’ dog. The breed
comes in a variety of colors: black and tan, all tan, all red, yellowish
red and spotted in various shades.
THE BEAGLE HOUND CH. IMPORTED CRUISER.

The Beagle, while not to be considered a house dog, is small and
may be kept very nicely in a small place, provided he is allowed to
run and exercise in the open every day and is given the opportunity
to hunt his favorite game—rabbits—frequently. As a keen-nosed dog
for his own sphere he has no equal, and having been bred for years
with this sole purpose in view, his intelligence is concentrated along
these lines and not toward making him an allround home companion,
but given the opportunity and the human companionship, his
intelligence may be improved to a wonderful degree. The beagle is in
every sense of the word a miniature foxhound, ranging in height from
nine to fifteen inches which is the maximum; dogs over this height
are disqualified at bench shows and beagle trials. The classification
in vogue at the present time is dogs thirteen inches and under, and
dogs over thirteen and not over fifteen inches.
The Whippet, which is a miniature English greyhound, is a neat,
cleanly dog, not perhaps a desirable companion when all essentials
of an intelligent dog are taken into consideration, but he is a trim
animal, very distinguished in appearance, and short of coat, hence
he is worth considering on this account, if for no other. At the present
time the whippet is coming into greater popularity, mainly because of
the fact that bench show clubs are giving him ample classification
and further, because as a racing dog he has gained quite a vogue in
some parts of the country.
THE CURLY POODLE, CH. ORCHARD MINSTREL
Among the many intelligent non-sporting dogs is the Large Poodle, a
dog somewhat larger than the chow. He is in every sense of the
word a larger edition of the toy poodle, but a much more useful dog
because of his size and superior intelligence. The poodle is one of
the most readily trained dogs in existence today. As a trick dog he
has no equals and he may be broken to retrieve from land and water
with the same facility as any of the sporting retrievers or spaniels.
There are two varieties of the poodle; the corded and the curly. The
latter is the more common and also the more practical, for the
corded poodle’s coat is the most difficult of any among the canine
race, to care for. The hair on the latter hangs from the dog in long
rope-like strands, almost touching the ground and unless it is given
daily attention it is likely to become matted and soiled. The corded
poodle is covered with short curls all over his body. It is customary to
clip them about one-third; that is, the coat is left on head, neck and
front, extending well back of the shoulders while the loin, hips and
back legs are closely clipped, leaving a tuft here and there and on
the end of the docked tail. A well cared for poodle makes a unique
appearance. The breed comes in all black, all white, all blue and all
red. The colors should be solid—that is, on blacks there should be
no white and vice versa.
A breed that promised to come into popularity some years ago is the
foreign born Samoyede. Although it is not so many years ago that
this breed lived in a semi-wild state in Siberia where reclaimed
specimens were used for hunting bear, and by the natives of
Lapland, he was used for rounding up tame elk. The samoyede is
peculiarly amenable to civilization and the companionship of human
beings. Fifteen or twenty years ago the breed was seen in fairly large
numbers on the show benches of this country and England. After
that there came a lull, but of late he seems to be gaining in
popularity. In the far north he was used as a sledge dog like the
husky and other arctic breeds. The dog is long-coated and in many
respects resembles the Spitz, though he is larger than the average
of those specimens. He may not be the ideal dog to have about in
the home where there are children as he is of uncertain
temperament, but he is a rather unusual looking animal for which
reason he has gained a certain amount of notoriety.
THE DOBERMAN PINSCHER CH. BETEL DOBERMAN.
The Doberman Pinscher, which is really a terrier possessing
characteristics of the Airedale, is another dog which, when he once
becomes fully known and appreciated for his sterling qualities, will
become a more general home favorite. He is smooth coated, prick-
eared and black and tan in color, weighing in the neighborhood of
thirty-five to forty pounds. He is very intelligent and is as easily
taught to perform the duties of an allround “varmint dog” as any
breed in existence. As a police dog he is said to be even more
readily trained than the breed which is supposed to be a specialist in
that sphere—namely the shepherd dog—until lately known as the
German or Belgian shepherd dog.
While on the subject of the latter breed, it might be said in passing,
that this dog is gaining in popularity each year. He is said to be
intelligent, in fact he is easily trained, but here also is a breed which
is somewhat uncertain in temper despite the stories to the contrary.
As a watch dog he cannot be surpassed. For those having country
estates or large enough out-door space, this dog is a very desirable
one, but it is scarcely possible to keep one of these in limited
quarters.
The same may be said of any of the larger breeds, and as this book
is devoted to the dogs that are suitable for the large towns and cities
we shall refer the aspiring fancier who is bent upon going in for the
large dogs to procure a copy of “Dogcraft,” a former work of mine
which gives the standards of all breeds, large and small.
CHAPTER IV.
Housing Problems.
The proper housing of a dog is one of the important, if not the most
important questions in dog keeping. We are assuming that the
budding dog fancier has decided upon what breed he wants to own
and has found an individual to his liking. Perhaps the purchase has
been made and he has brought his canine acquisition home to find
that he has never given the question of housing him any thought.
Under such circumstances he is in a dilemma. His new charge is like
a white elephant on his hands. Naturally, if the dog is still a young
puppy some make-shift arrangement may be made, perhaps in
some odd corner of the house, but it must be remembered that all
puppies, aside from the fact that they are not house-broken are also
a nuisance in many other ways, for they have a special predilection
for the master’s slippers or some article of wearing apparel
belonging to the mistress of the house, and they take special delight
in tearing such things to pieces for the mere amusement of the thing
and because they must have an outlet for their excess of energy.
Another chapter will be devoted to the early training lessons, so let
us, therefore, in this chapter, take up the question of sleeping
quarters and a playground for the youngster.
Where the dog is a medium-sized one, or a toy, perhaps, it will not
be necessary to provide out-door quarters except for exercising, and
therefore, an arrangement may be made for the new dog to occupy a
place in the kitchen or basement, but it must be a place where he will
learn to go either for the night or during the day time when he wishes
a quiet nap all to himself. Personally, I am no advocate for keeping a
dog in the house night and day. It is true, many dog lovers do this
and when the breed is no larger than say, a fox terrier or even a
chow, the arrangement may be satisfactory enough, but never, under
any circumstance, allow a dog to have the run of the house at all
hours of the day or night. If you have decided to allow him to sleep in
the house, provide a box or basket large enough for the purpose. Put
this in some corner in the kitchen or even in the basement, though
unless this latter place is absolutely dry and subject to ventilation, it
is not a desirable place for sleeping quarters. In providing a sleeping
place, whether it be basket, box or bench, it should be raised several
inches above the floor. This is to obviate draughts which are sure to
prevail in cold weather, for no matter how tight a door may fit there is
always a certain amount of cold air blowing in through the crevice at
the bottom, and incidentally, this is one of the most frequent causes
for colds, catarrh or even pneumonia. If you have your doubts about
it, try sleeping upon the floor on a cold night yourself. If the dog be a
toy breed, a shallow basket provided with a pillow filled with pine of
cedar shavings, or pine needles is a most suitable bed. The pillow
should be covered with some coarse, heavy material that will not
tear easily and should be a covering that goes over the pillow proper;
the material inside whether shavings or pine needles should be
encased in another cover. The idea being that the outer covering can
be removed and washed frequently, for no matter how clean a dog
may be, the canine smell will in time permeate the cover and it must
be changed and washed at least once every two weeks if absolute
cleanliness is desired. For most of the larger breeds, a carpet or rug
will be sufficient bedding. Loose bedding, such as shavings or straw
is not to be thought of in the house.
The box or basket provided for the bed should be large enough to
permit the dog to lie at his ease. If a box is used, the better plan is to
remove one side with the exception of a small strip at the bottom to
hold the bedding in and of course, the top should also be removed.
These sleeping boxes or baskets should be put out in the sun and air
every week or so and when necessity demands, they should be
scrubbed with warm soap water, to which a few drops of Creolin-
Pierson may be added. This will keep the sleeping box clean and
obviate any possibility of vermin, for once fleas infest a place where
a dog frequents, then all thought of housing indoors must be
abandoned.
Far the better plan, however, is to provide sleeping quarters in the
garage or stable, especially for the larger breeds; in fact, all breeds
except toys. In cold weather these boxes may be closed on top and
on all sides, leaving only a small opening for entrance or exit. The
advantage of this being that such boxes can be filled with good,
clean straw in cold weather and there are very few dogs who cannot
sleep comfortably and warmly in such a bed, even when the mercury
is down close to the zero mark. Terriers, as a matter of fact, are very
hardy and will really do better in an out-building of this kind than in
the house or basement. Naturally, one must be governed according
to circumstances and if the owner of a dog has no building on the
premises, part of which may be used for his pet’s quarters he can
build a small house out of doors and provide a runway in connection.
Nearly all of the wire, or long-haired breeds will do well in these out-
door kennels the year round, provided the bedding is warm, the box
free from draughts, and a piece of carpet or burlap is tacked over the
opening in the coldest of weather. This should be arranged in such a
way that it is loose on the sides and bottom, so as to permit of easy
entrance and exit.
In building an out-door house for the dog it is well to adopt more
modern plans than the old-time “dog house” closed on top and all
sides with the exception of the door in front. This style has been in
vogue and has answered the purpose for many a high-bred dog, but
if the owner wishes to have something more elaborate he might build
a small house having a hallway or vestibule before reaching the
sleeping quarters proper. Such a house must be built double the size
of the ordinary one to allow for the extra “room.” It should also be so
constructed that it may be opened from the top, either by supplying
hinges to the roof which make it possible to raise either side, or the
roof may be so constructed that the entire top of the house can be
lifted off. This will permit of easy cleaning of the interior. It is well to
keep the interior whitewashed. A coating of this every few months
will aid very materially in keeping the place free from vermin.
When it is possible to provide a runway or small enclosure where the
dog may exercise in at any time he desires, it is far better than to
chain him. These runways can be constructed cheaply, of heavy
mesh wire. In constructing this it must be with a view of making them
high enough to prevent the dog from leaping or climbing over. A
good plan to adopt is to build the fence and then put another strip of
wire mesh a foot or eighteen inches wide horizontally from the top of
the posts, allowing this to go on the inside, thus even though the dog
is inclined to jump or climb, when he reaches the top of the fence,
this extra width of wire will prevent him from going over. Another
precaution must be taken against burrowing out. This is easily done
by digging a trench and allowing the wire to go into the ground a foot
or more, then filling this trench up with stones or brick and covering
with earth. No dog will be able to dig under such a fence.
If a dog must be chained to his kennel, as sometimes is the case, he
should be given at least two hours of freedom every day. Far the
better way is to extend a wire close to the ground, from the kennel to
a post thirty or forty feet (more if possible) from this. The post at the
far end should be driven or planted in the ground, allowing only
enough above the surface to attach the wire to, for dogs have a
faculty of getting their chains twisted about a post that might be
dangerous or even fatal to them. A ring should be put on this wire to
which the swivel of the chain may be attached. This gives the animal
a certain amount of freedom and exercise, and it will soon become
noticeable how he takes advantage of it. It is needless to say that all
kennels out of doors should be built of matched boards dove-tailed
together so as to admit no draughts, furthermore, the kennel should
be placed on a foundation or on piles several inches from the
ground. For more elaborate plans of kennels when more dogs are
kept, the reader is referred to an earlier work of mine entitled
“Practical Dog Keeping for the Amateur.”
CHAPTER V.
Becoming Acquainted—Early Lessons.
While most any breed of dog under one year old will soon learn to
adapt himself to new friends and environment, and therefore no
stipulated time is imperative as to what age he should be, at the time
of his purchase, there is something about the wee youngsters of
eight or ten weeks old that appeals to all, and the general thing is to
obtain your puppy shortly after he is weaned.
It is true, there are some objections to this plan, principally because
a puppy of this tender age is still unbroken to the house and is also
more susceptible to the ordinary ills that beset the young life of
practically all canines, but on the other hand, there is something
particularly interesting in a wee puppy and he will, as a rule, soon
become the pet of the entire household. As for the ills, with ordinary
care, one can tide the youngster over these much more easily than
the novice may imagine. As a matter of fact, I would rather begin
with a twelve weeks old puppy and break him to cleanliness about
the house than I would a dog of one year old, for in a majority of
cases, when purchasing a puppy of the latter age, you will be told
that he is house-broken, when as a matter of fact he is not,
consequently this education must begin at a rather late age. Another
reason why the very young puppy is more satisfactory is because
there is a greater interest in watching him develop physically as well
as mentally; therefore, all things considered, I would advise selecting
your dog when he is still a mere baby; which means under three
months of age.
As for breed, that is a matter to decide according to your own
inclinations. The young of all animals are interesting, but this is
particularly so of dogs, irrespective of the breed. Even the veriest
mongrel, as a small puppy, is a most engaging creature.
Assuming that you have purchased your puppy and taken him home
and he is one of those innocent-looking balls of fluffy hair from which

Full Chapter Reuse in Emerging Software Engineering Practices 19Th International Conference On Software and Systems Reuse Icsr 2020 Hammamet Tunisia December 2 4 2020 Proceedings Sihem Ben Sassi PDF

Uploaded by

Copyright:

Available Formats

You might also like

Full Chapter Reuse in Emerging Software Engineering Practices 19Th International Conference On Software and Systems Reuse Icsr 2020 Hammamet Tunisia December 2 4 2020 Proceedings Sihem Ben Sassi PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Full Chapter Reuse in Emerging Software Engineering Practices 19Th International Conference On Software and Systems Reuse Icsr 2020 Hammamet Tunisia December 2 4 2020 Proceedings Sihem Ben Sassi PDF

Uploaded by

Copyright:

Available Formats

Reuse in Emerging Software

Engineering Practices: 19th

Biota Grow 2C gather 2C cook Loucas

Software Reuse Bridging with Social Awareness 15th

Software Engineering Perspectives in Intelligent

New Perspectives in Software Engineering: Proceedings

Testing Software and Systems 32nd IFIP WG 6 1

Software Engineering Perspectives in Intelligent

The Impact of Digital Technologies on Public Health in

Advances in Artificial Intelligence, Software and

Editorial Board Members

Hafedh Mili (Eds.)

ISSN 0302-9743 ISSN 1611-3349 (electronic)

© Springer Nature Switzerland AG 2020

Centre de Recherche en Informatique,

October 2020 Sihem Ben Sassi

Program Committee Chairs

Workshops and Tutorials Chair

Doctoral Symposium and Publicity Chairs

Olivier Barais University of Rennes 1, France

Ali Parsai Carolina Hernandez Phillips

Semantic Software Capability Profile Based on Enterprise Architecture

Safety Patterns for SysML: What Does OMG Specify? . . . . . . . . . . . . . . . . 19

A Hybrid Approach Based on Reuse Techniques for Autonomic Adaptation

Reusable Formal Models for Threat Specification, Detection, and Treatment . . . 52

Dynamic Reconfiguration of Cloud Composite Services Using Event-B . . . . . 69

15 Years of Reuse Experience in Evolutionary Prototyping for the

CxDev: A Case Study in Domain Engineering for Customer eXperience

Modular Moose: A New Generation of Software Reverse

DeepClone: Modeling Clones to Generate Code Predictions . . . . . . . . . . . . . 135

Analysing Microsoft Access Projects: Building a Model in a Partially

Automated Reuse Recommendation of Product Line Assets Based

Learning to Recommend Trigger-Action Rules for End-User Development:

AndroLib: Third-Party Software Library Recommendation

Investigating the Impact of Functional Size Measurement on Predicting

How Does Library Migration Impact Software Quality

How Do Developers Refactor Code to Improve Code Reusability? . . . . . . . . 261

Analyzing the Impact of Refactoring Variants on Feature Location . . . . . . . . 279

An Exploratory Study on How Software Reuse is Discussed

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

Abdelhadi Belfadel(B) , Jannik Laval, Chantal Bonner Cheriﬁ,

University Lumière Lyon 2, DISP Laboratory, Lyon, France

Keywords: Capability proﬁle · Enterprise architecture · Service

– C1) Functional and technical description of the service interfaces, including

and their related services. This can be realized by considering an Enterprise

Table 1. Software and service description works

Benfenatki et al. 2017 [25] + + + +

3 Enterprise Architecture Capability Profile for Software

3.1 EACP Meta-Model

In case of services or Web APIs, QoS parameters such as availability, response

Fig. 1. EACP proposed meta-model

4 Implementation and Validation of the EACP

Fig. 2. Proposed model for ABBs

– CQ1: Retrieve Business Objectives related to business goals

Second, we identiﬁed from state-of-the-art solutions some existing ontologies

4.1 Construction Steps of the EACP Ontology

Step 1: identification of existing ontologies In the proposed semantic

Step 2: Integration of Existing Ontologies into the BFO Ontology