@demo {2025:apiace:vissoft,
	title = {EVOSCAT: Exploring Software Change Dynamics in Large-Scale Historical Datasets},
	year = {2025},
	month = {September},
	publisher = {IEEE},
	address = {Auckland, New Zealand},
	abstract = {Long lived software projects encompass a large number of artifacts, which undergo many revisions throughout their history. Empirical software engineering researchers studying software evolution gather and collect datasets with millions of events, representing changes introduced to specific artifacts. In this paper, we propose EVOSCAT, a tool that attempts addressing temporal scalability through the usage of interactive density scatterplot to provide a global overview of large historical datasets mined from open source repositories in a single visualization.  EVOSCAT intends to provide researchers with a mean to produce scalable visualizations that can help them explore and characterize evolutions datasets, as well as comparing the histories of individual artifacts, both in terms of 1) observing how rapidly different artifacts age over multiple-year-long time spans 2) how often metrics associated with each artifacts tend towards an improvement or worsening. The paper shows how the tool can be tailored to specific analysis needs (pace of change comparison, clone detection, freshness assessment) thanks to its support for flexible configuration of history scaling and alignment along the time axis, artifacts sorting and interactive color mapping, enabling the analysis of millions of events obtained by mining the histories of tens of thousands of software artifacts. We include in this paper a gallery showcasing datasets gathering specific artifacts (OpenAPI descriptions, GitHub workflow definitions) across multiple repositories, as well as diving into the history of specific popular open source projects.},
	keywords = {Interactive Scatterplot, Large-Scale Historical Data, Software Evolution Visualization},
	doi = {10.1109/VISSOFT67405.2025.00021},
	url = {https://arxiv.org/abs/2508.10852},
	author = {Souhaila Serbout and Diana Carolina Mu{\~n}oz Hurtado and Hassan Atwi and Edoardo Riggio and Cesare Pautasso}
}
@conference {apiace:2025:icsa,
	title = {Mining Security Documentation Practices in OpenAPI Descriptions},
	booktitle = {22nd IEEE International Conference on Software Architecture (ICSA)},
	year = {2025},
	month = {March},
	address = {Odense, Denmark},
	abstract = {Security is an integral requirement of any trustworthy software architecture, particularly critical for application programming interfaces (APIs). In this paper, we survey security documentation practices, specifically API security schemes related to authentication and authorization, by mining a large collection of OpenAPI descriptions retrieved from open-source GitHub repositories. Our study focuses on detecting existing security schemes and evaluating their prevalence and positioning within API descriptions. We distinguish whether security schemes are introduced locally (at the path or operation level) or globally (for the entire API). Our analysis highlights scenarios where security schemes are featured in APIs in different proportions over time, thus tracking whether the API documentation tends to include more (or less) security details as the API evolves.},
	keywords = {API Analytics, OpenAPI, Security},
	author = {Diana Carolina Mu{\~n}oz Hurtado and Souhaila Serbout and Cesare Pautasso}
}
@article {apiace:2025:ese,
	title = {Understanding Security Tactics in Microservice APIs using Annotated Software Architecture Decomposition Models {\textendash} A Controlled Experiment},
	journal = {Empirical Software Engineering},
	volume = {30},
	year = {2025},
	month = {February},
	chapter = {66},
	abstract = {While microservice architectures have become a widespread option for designing distributed applications, designing secure microservice systems remains challenging. Although various security-related guidelines and practices exist, these systems{\textquoteright} sheer size, complex communication structures, and polyglot tech stacks make it difficult to manually validate whether adequate security tactics are applied throughout their architecture.
To address these challenges, we have devised a novel solution that involves the automatic generation of security-annotated software decomposition models and the utilization of security-based metrics to guide software architectures through the assessment of security tactics employed within microservice systems. To evaluate the effectiveness of our artifacts, we conducted a controlled experiment where we asked 60 students from two universities and ten experts from the industry to identify and assess the security features of two microservice reference systems. During the experiment, we tracked the correctness of their answers and the time they needed to solve the given tasks to measure how well they could understand the security tactics applied in the reference systems.
Our results indicate that the supplemental material significantly improved the correctness of the participants{\textquoteright} answers without requiring them to consult the documentation more. Most participants also stated in a self-assessment that their understanding of the security tactics used in the systems improved significantly because of the provided material, with the additional diagrams considered very helpful. In contrast, the perception of architectural metrics varied widely. We could also show that novice developers benefited most from the supplementary diagrams. In contrast, senior developers could rely on their experience to compensate for the lack of additional help. Contrary to our expectations, we found no significant correlation between the time spent solving the tasks and the overall correctness score achieved, meaning that participants who took more time to read the documentation did not automatically achieve better results. As far as we know, this empirical study is the first analysis that explores the influence of security annotations in component diagrams to guide software developers when assessing microservice system security.},
	keywords = {Component Diagrams, Controlled Experiment, Empirical Software Engineering, Microservice Architecture, Microservice Security, Software Architecture Metrics, Understandability},
	doi = {10.1007/s10664-024-10601-1},
	author = {Patric Genfer and Souhaila Serbout and Georg Simhandl and Uwe Zdun and Cesare Pautasso}
}
@phdthesis {2025:phd:souhaila-serbout,
	title = {Web API Design and Evolution},
	year = {2025},
	month = {February},
	school = {USI},
	type = {PhD},
	address = {Lugano},
	abstract = {Web APIs (Application Programming Interfaces) are a cornerstone of modern software development, enabling interoperability and integration across diverse systems. Despite their importance, there is a lack of large-scale empirical studies on the design, evolution, and versioning of APIs. This research addresses this gap by leveraging a comprehensive dataset of OpenAPI Specifications (OAS) from public repositories such as GitHub and SwaggerHub. The thesis provides empirical results describing the Web API landscape, focusing on structural patterns, design smells, changes, and versioning practices.

Through mining commit histories and metadata, the study identifies trends in API evolution and assesses their adherence to versioning principles. Clustering techniques and natural language processing are employed to detect common structural patterns and understand the semantic context of API elements. The research adopts a language-agnostic, automated approach to analyze API design and evolution at scale. The goal is to answer questions on Web API design and evolution without being tied to a specific programming ecosystem. 

We empirically identified four recurring structural patterns in Web API designs to provide access to enumerable, dependable, and mutable collections, which serve as modular and reusable building blocks. Additionally, the analysis uncovers design smells that hinder usability, maintainability, and security, providing actionable insights to improve API quality.

Web API structures are inherently tied to the operations they provide for handling resources derived from specific data models. As such, studying APIs requires a dual focus on their structural design and the underlying data models to ensure coherence. We examined the relationship between API structures and their data models, highlighting frequent misalignments with design principles such as logical structuring and consistent naming conventions. 

Regarding API evolution, the study categorizes over 200 types of changes and reveals that breaking changes occur 2.44 times more often than non-breaking ones. While many breaking changes appear minor, their cumulative impact on client applications can be significant.

When it comes to Web API versioning, we detected a high level of diversity in the adopted versioning schemes. In addition, APIs that claimed to use Semantic Versioning often failed to adhere to its basic rules. 

The findings reveal that while Web APIs have been part of the software landscape since more than 20 years, they still do not meet the theoretical design principles when it comes to their practical implementation and management. This is explained by the lack of straightforward tools that can guide developers in adhering to best practices, identifying design flaws, and ensuring consistent versioning and evolution management throughout the API lifecycle.

In light of this empirical evidence, we propose supporting both API developers and users through language-agnostic visualization tools that can be integrated into development environments (IDE-based) or easily accessible for users who only want to learn about the API (web-based). The proposed tools are initial research prototypes built based on our findings. OAS2tree enhances API feature navigation and integrates functionality to identify and flag potential design flaws. APIcture offers a picture of API histories, providing an intuitive way to track their evolution. 
Although effective in their initial form, these tools have the potential to be further refined through user feedback and studies involving the target audience, ultimately improving their features, usability, and impact. },
	keywords = {API Analytics},
	author = {Souhaila Serbout}
}
@conference {apiace:2024:msr,
	title = {APIstic: A Large Collection of OpenAPI Metrics},
	booktitle = {21st IEEE/ACM International Conference on Mining Software Repositories (MSR)},
	year = {2024},
	month = {April},
	pages = {265 - 277},
	address = {Lisbon, Portugal},
	abstract = {In the rapidly evolving landscape of web services, the significance of efficiently designed and well-documented APIs is paramount. In this paper, we present APIstic an API analytics dataset and exploration tool to navigate and segment APIs based on an extensive set of precomputed metrics extracted from OpenAPI specifications, sourced from GitHub, SwaggerHub, BigQuery and APIs.guru.
These pre-computed metrics are categorized into structure, data model, natural language description, and security metrics.
The extensive dataset of varied API metrics provides crucial insights into API design and documentation for both researchers and practitioners. Researchers can use APIstic as an empirical resource to extract refined samples, analyze API design trends, best practices, smells, and patterns. For API designers, it serves as a benchmarking tool to assess, compare, and improve API structures, data models, and documentation using metrics to select points of references among 1,275,568 valid OpenAPI specifications.
The paper discusses potential use cases of the collected data and presents a descriptive analysis of selected API analytics metrics. },
	keywords = {dataset, metrics, OpenAPI},
	doi = {10.1145/3643991.3644932},
	url = {https://dl.acm.org/doi/10.1145/3643991.3644932},
	author = {Souhaila Serbout and Cesare Pautasso}
}
@article {apiace:2024:jwe,
	title = {How Are Web APIs Versioned in Practice? A Large-Scale Empirical Study},
	journal = {Journal of Web Engineering},
	volume = {23},
	year = {2024},
	month = {August},
	pages = {465-506 },
	abstract = {Web APIs form the cornerstone of modern software ecosystems, facilitating seamless data exchange and service integration. Ensuring the compatibility and longevity of these APIs is paramount. This study delves into the intricate realm of API versioning practices, a crucial mechanism for managing API evolution. Exploring an expanded and diverse dataset of 603 293 APIs specifications created during the 2015{\textendash}2023 timeframe and gathered from four different sources, we examined the adoption of the following versioning practices: Metadata-based, URL-based, Header-based and Dynamic versioning, with one or more versions in production. API developers use more than 50 different version identifier formats to encode information about the changes introduced with respect to the previous version (i.e., semantic versioning), about when the version was released (i.e., age versioning) and about which phase of the API development lifecycle the version belongs (i.e., stable vs. preview releases).},
	keywords = {API Analytics; API Versioning},
	doi = {10.13052/jwe1540-9589.2341},
	url = {https://journals.riverpublishers.com/index.php/JWE/article/view/26595/20349},
	author = {Souhaila Serbout and Cesare Pautasso}
}
@conference {apiace:2024:icwe,
	title = {How Many Web APIs Evolve Following Semantic Versioning?},
	booktitle = {24th International Conference on Web Engineering (ICWE)},
	year = {2024},
	month = {June},
	publisher = {Springer},
	organization = {Springer},
	address = {Tampere, Finland},
	abstract = {More and more Web APIs use semantic versioning to represent the impact of changes on clients depending on previous versions. Our goal is to provide insights about the extent to which evolving Web APIs align with semantic versioning rules. In this paper we present the results of an empirical study on the descriptions of 3 075 Web APIs, which released at least one new version throughout their history. The APIs descriptions were mined by retrieving 132 909 commits from 2 028 different open source GitHub repositories. We systematically collected and examined 506 273 changes of 195 different types released within 16 053 new API versions. We classified whether each change is likely to break clients or not, and checked whether the corresponding version identifier has been updated following semantic versioning rules. The results indicate that in the best case, only 517 APIs consistently release major upgrades when introducing breaking changes, while 1 970 APIs will not always correctly inform their clients about breaking changes released as part of minor or patch-level upgrades. We also detected 927 APIs which use a backwards-compatible evolution strategy, as they never introduce any breaking change throughout their history.},
	keywords = {API Analytics, API Evolution, Semantic Versioning, Web API},
	doi = {10.1007/978-3-031-62362-2_25},
	url = {https://link.springer.com/chapter/10.1007/978-3-031-62362-2_25},
	author = {Souhaila Serbout and Cesare Pautasso}
}
@demo {apiace:2024:ecsa,
	title = {OAS2Tree: Visual API-First Design},
	year = {2024},
	month = {September},
	publisher = {Springer},
	address = {Luxembourg},
	abstract = {OAS2Tree is a tool designed to transform OpenAPI Specification (OAS) documents into tree-like visualizations, aiding in the understanding and navigation of the structure of REST APIs. By converting the detailed, verbose, and often complex OAS files into a visual tree structure, OAS2tree simplifies the comprehension of a Web API, highlighting the hierarchical relationships between endpoints, operations, and parameters. This visual representation is particularly useful for developers and stakeholders who need a quick overview of an API without delving into the intricate details of its technical specifications. OAS2tree can be integrated into the IDE through a Visual Studio code extension or used as a standalone web application. The tool currently has about 400 users and has been used on teaching, research, and development projects. In this paper, we present the design and implementation of OAS2tree, highlighting its features and use cases. We also highlight the limitations of the current version and discuss future improvements and potential extensions.},
	keywords = {API Analytics, demo, visualization},
	author = {Souhaila Serbout and Cesare Pautasso}
}
@conference {apiace:2023:europlop,
	title = {API Rate Limit Adoption - A Pattern Collection},
	booktitle = {28th European Conference on Pattern Languages of Programs (EuroPLoP 2023)},
	year = {2023},
	month = {July},
	publisher = {ACM},
	organization = {ACM},
	address = {Kloster Irsee, Germany},
	keywords = {API Design Patterns},
	doi = {10.1145/3628034.3628039},
	url = {https://dl.acm.org/doi/10.1145/3628034.3628039},
	author = {Souhaila Serbout and Amine El Malki and Cesare Pautasso and Uwe Zdun}
}
@conference {apiace:2023:icwe,
	title = {An empirical study of Web API versioning practices},
	booktitle = {23rd International Conference on Web Engineering (ICWE)},
	year = {2023},
	month = {June},
	publisher = {Springer},
	organization = {Springer},
	address = {Alicante, Spain},
	abstract = {As Web APIs evolve, developers assign them version identifiers to reflect the amount and the nature of changes that the API clients should expect. In this work we focus on identifying versioning practices adopted by Web API developers by extracting and classifying version identifiers found in a large collection of OpenAPI descriptions.
In particular, we observe how frequently different versioning schemes have been adopted for identifying both stable and preview releases (e.g., simple version counters, semantic versioning, or release timestamps). We further study the stability of versioning schemes during APIs evolution. We also detect APIs which offer dynamic access to versioning metadata through dedicated endpoints as well as APIs which support clients expecting to reach up to 14 different versions of the same API at the same time.
Overall the results offer a detailed view over current Web API versioning practices and can serve as the basis for future discussions on how to standardize critical API versioning metadata.},
	keywords = {API Analytics, Versioning},
	author = {Souhaila Serbout and Cesare Pautasso}
}
@conference {apiace:2023:vissoft,
	title = {Interactively exploring API changes and versioning consistency},
	booktitle = {11th IEEE Working Conference on Software Visualization (VISSOFT 2023)},
	year = {2023},
	month = {October},
	pages = {28-39},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Bogota, Colombia},
	abstract = {Application Programming Interfaces (APIs) evolve
over time. As they change, they are expected to be versioned
based on how changes might affect their clients. In this paper, we
present two novel visualizations specifically designed to represent
all structural changes and the level of adherence to semantic
versioning practices over time. They can also serve for characterizing and comparing the evolution history of different Web
APIs. The API VERSION CLOCK helps to visualize the sequence
of API changes over time and highlight inconsistencies between
major, minor, or patch version changes and the corresponding
introduced breaking or non-breaking changes applied to the
API. The API CHANGES overview aggregates all changes to
an OpenAPI (OAS) description, highlighting the unstable vs.
the stable elements of the API over its entire history. Both
visualizations can be automatically created using the APICTURE,
a command-line and web-based tool that analyzes the histories
of git code repositories containing OAS descriptions, extracting
the necessary data for generating visualizations and computing
metrics related to API evolution and versioning. The visualizations have been successfully applied to classify, compare, and
interactively explore the multi-year evolution history of APIs with
up to hundreds of individual commits.},
	keywords = {API Versioning; Software Visualization, visualization},
	doi = {10.1109/VISSOFT60811.2023.00013},
	url = {https://ieeexplore.ieee.org/document/10350155},
	author = {Souhaila Serbout and Diana Carolina Mu{\~n}oz Hurtado and Cesare Pautasso}
}
@demo {2022:ecsa:expresso,
	title = {ExpressO: From Express.js implementation code to OpenAPI interface descriptions},
	year = {2022},
	month = {September},
	pages = {29{\textendash}44},
	publisher = {Springer},
	abstract = {This tool demo paper brings forward a new CLI tool called ExpressO for developers who need to analyze a Web API implemented using the Express.js framework and automatically extract a specification written in the standard OpenAPI interface description language. The specification includes all of the implemented endpoints along with their response status codes and path and query parameters. Developers can use it to automatically determine whether the interface of a Web API matches its implementation based on the Express.js framework. The tool has been released on the npm component registry as {\textquoteleft}expresso-api{\textquoteright}.

},
	keywords = {API, express.js, OpenAPI},
	doi = {10.1007/978-3-031-36889-9_4},
	author = {Souhaila Serbout and Alessandro Romanelli and Cesare Pautasso}
}
@conference {apiace:2022:icws,
	title = {How Composable is the Web? An Empirical Study on OpenAPI Data model Compatibility},
	booktitle = {IEEE World Congress on Services (ICWS Symposium on Services for Machine Learning)},
	year = {2022},
	month = {July},
	pages = {415-424},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Barcelona, Spain},
	abstract = {Composing Web APIs is a widely adopted practice by developers to speed up the development process of complex Web applications, mashups, and data processing pipelines. However, since most publicly available APIs are built independently of each other, developers often need to invest their efforts in solving incompatibility issues by writing ad-hoc glue code, adapters and message translation mappings. How likely are Web APIs to be directly composable?

The paper presents an empirical study to determine the potential composability of a large collection of 20,587 public Web APIs by verifying their schemas{\textquoteright} compatibility. We define three levels of data model elements compatibility -- considering matches between property names and/or data types -- which can be determined statically based on API descriptions conforming to the OpenAPI specification. The study research questions address: to which extent are Web APIs compatible; the average number of compatible endpoints within each API; the likelihood of finding two APIs with at least one pair of compatible endpoints. 

To perform the analysis we developed a compatibility checker tool which can statically determine API schema compatibility on the three levels and find matching pairs of API responses which can be directly forwarded as requests to the same or other APIs. We run the tool on a dataset of 751,390 request and response message schemas extracted from publicly available OpenAPI descriptions.

The results indicate a relatively high number of compatible APIs when matching their data models only on the level of their elements{\textquoteright} data type. However, this number gets lower narrowing the scope to only the ones handling data objects having identical properties name. The average likelihood of finding two compatible APIs with both matching property names and data types reaches 21\%. Also, the number of compatible endpoints within the same API is very low.},
	keywords = {API Analytics, empirical study, mashups, OpenAPI, Web APIs},
	doi = {10.1109/ICWS55610.2022.00068},
	author = {Souhaila Serbout and Cesare Pautasso and Uwe Zdun}
}
@article {2022:jwe,
	title = {A Large-scale Empirical Assessment of Web API Size Evolution},
	journal = {Journal of Web Engineering},
	volume = {21},
	year = {2022},
	month = {November},
	pages = {1937{\textendash}1980},
	abstract = {Like any other type of software, also Web Application Programming Interfaces (APIs) evolve over time. In the case of widely used API, introducing changes is never a trivial task, because of the risk of breaking thousands of clients relying on the API. In this paper we conduct an empirical study over a large collection of OpenAPI descriptions obtained by mining open source repositories. We measure the speed at which Web APIs change and how changes affect their size, simply defined as the number of operations. The dataset of API descriptions was collected over a period of one year and includes APIs with histories spanning across up to 7 years of commits. The main finding is that APIs tend to grow, although some do reduce their size, as shown in the case study examples included in the appendix.},
	keywords = {API Evolution},
	doi = {10.13052/jwe1540-9589.2167},
	url = {https://ieeexplore.ieee.org/document/10246943},
	author = {Fabio Di Lauro and Souhaila Serbout and Cesare Pautasso}
}
@article {2022:sosym:bpmn,
	title = {Live process modeling with the BPMN Sketch Miner},
	journal = {Software and Systems Modeling},
	volume = {21},
	year = {2022},
	month = {October},
	pages = {1877{\textendash}1906},
	abstract = {BPMN Sketch Miner is a modeling environment for generating visual business process models starting from constrained natural language textual input. Its purpose is to support business process modelers who need to rapidly sketch visual BPMN models during interviews and design workshops, where participants should not only provide input but also give feedback on whether the sketched visual model represents accurately what has been described during the discussion. In this article, we present a detailed description of the BPMN Sketch Miner design decisions and list the different control flow patterns supported by the current version of its textual DSL. We also summarize the user study and survey results originally published in MODELS 2020 concerning the tool usability and learnability and present a new performance evaluation regarding the visual model generation pipeline under actual usage conditions. The goal is to determine whether it can support a rapid model editing cycle, with live synchronization between the textual description and the visual model. This study is based on a benchmark including a large number of models (1350 models) exported by users of the tool during the year 2020. The main results indicate that the performance is sufficient for a smooth live modeling user experience and that the end-to-end execution time of the text-to-model-to-visual pipeline grows linearly with the model size, up to the largest models (with 195 lines of textual description) found in the benchmark workload.},
	keywords = {BPMN, text to visual, Textual Modelling DSL},
	issn = {1619-1366},
	doi = {10.1007/s10270-022-01009-w},
	url = {https://link.springer.com/article/10.1007/s10270-022-01009-w$\#$citeas},
	author = {Ana Ivanchikj and Souhaila Serbout and Cesare Pautasso}
}
@conference {apiace:2022:ecsa,
	title = {To deprecate or to simply drop operations? An empirical study on the evolution of a large OpenAPI collection},
	booktitle = {16th European Conference on Software Architecture (ECSA)},
	volume = {13444},
	year = {2022},
	month = {September},
	pages = {38-46},
	publisher = {Springer},
	organization = {Springer},
	address = {Prague, Czech Republic},
	keywords = {API Analytics, API Evolution},
	doi = {doi.org/10.1007/978-3-031-16697-6_3},
	author = {Fabio Di Lauro and Souhaila Serbout and Cesare Pautasso}
}
@conference {2022:icsa,
	title = {Web APIs Structures and Data Models Analysis},
	booktitle = {19th IEEE International Conference on Software Architecture (ICSA 2022)},
	year = {2022},
	month = {March},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Honululu, Hawaii},
	abstract = {Microservice architectures emphasize keeping components small, to foster autonomy, low coupling, and independent evolution. In this large-scale empirical study, we measure the size of Web API specifications mined from open source repositories. These APIs are modeled using the OpenAPI Specification (OAS), which, in addition to documenting the offered operations, also contain schemas definitions for the data exchanged with the API request and response message payloads.  This study has as a goal to build empirical knowledge about:  (1) How big and diverse are real-world web APIs both in terms of their operations and data, (2) How different API structures use and reuse schema definitions. By mining public software repositories on Github, we gathered 42,194 valid OAS specifications published between 2014-2021. },
	keywords = {API Analytics, API Size, OpenAPI},
	author = {Souhaila Serbout and Fabio Di Lauro and Cesare Pautasso}
}
@conference {2021:europlop:api-fragments,
	title = {From OpenAPI Fragments to API Pattern Primitives and Design Smells},
	booktitle = {European Conference on Pattern Languages of Programs (EuroPLoP{\textquoteright}21)},
	year = {2021},
	month = {July},
	publisher = {ACM},
	organization = {ACM},
	address = {Virtual Kloster Irsee, Germany},
	abstract = {In the past few years, the OpenAPI Specification (OAS) has emerged as a standard description language for accurately modeling Web APIs.
Today, thousands of OpenAPI descriptions can be found by mining open source repositories. In this paper, we attempt to exploit these artifacts to extract commonly occurring building blocks used in Web API structures, in order to assist Web API designers in their modelling task. Our work is based on a fragmentation mechanism, that starts from  OpenAPI descriptions of Web APIs to extract their structures, then fragment these structures into smaller blocks. This approach enabled us to extract a large dataset of reoccurring fragments from a collection of 6619 API specifications.  
Such fragments have been found multiple times in the same or across different APIs. We have classified the most reoccurring fragments into four pattern primitives used to expose in the API access to collections of items.  We distinguish for each primitive variants from design smells. This classification is based on the specific combinations of operations associated with the collection items and on an in-depth analysis of their natural language labels and descriptions. The resulting pattern primitives are intended to support designers who would like to introduce one or more collections for a specific class of items in their HTTP-based API.},
	keywords = {API, API fragments, design smells, OpenAPI, patterns},
	doi = {10.1145/3489449.3489998},
	url = {https://zenodo.org/record/5727094$\#$.YZ97mFMo-0o},
	author = {Souhaila Serbout and Cesare Pautasso and Uwe Zdun and Olaf Zimmermann}
}
@conference {2021:icwe:api-evolution,
	title = {Towards Large-scale Empirical Assessment of Web APIs Evolution},
	booktitle = {21st International Conference on Web Engineering (ICWE2021)},
	year = {2021},
	month = {May},
	pages = {124-138},
	publisher = {Springer},
	organization = {Springer},
	address = {Biarritz, France},
	abstract = {Web Application Programming Interfaces (APIs) decouple the internal implementation of a service from its consumers which can reuse and compose them to rapidly build new applications.
Many Web APIs are described with the OpenAPI Specification (OAS). The goal of our research is to check the feasibility of using API descriptions found in public open source repositories to study how APIs evolve over time. To do so, we collected a large dataset of OAS documents by crawling open source repositories, we parsed the corresponding metadata and measured the API size in order to extract a simple model to track the lifecycle of API artifacts and observe common evolution behaviors. Our preliminary results indicate that only a subset of the APIs changes, but as opposed to the expectation that APIs should only grow to maintain backward compatibility we also detected a number of APIs with a more variable history. We also study the stability of API artifacts over time and whether APIs are more or less likely to change as they age.},
	keywords = {API Evolution, OpenAPI, Web API},
	doi = {10.1007/978-3-030-74296-6_10},
	author = {Fabio Di Lauro and Souhaila Serbout and Cesare Pautasso}
}
@conference {2020:bpmn-sketch-miner:models,
	title = {From Text to Visual BPMN Process Models: Design and Evaluation},
	booktitle = {23rd International Conference on Model Driven Engineering Languages and Systems (MODELS)},
	year = {2020},
	month = {October},
	pages = {229{\textendash}239},
	publisher = {ACM/IEEE},
	organization = {ACM/IEEE},
	address = {Montreal, Canada},
	abstract = {Most existing Business Process Model and Notation (BPMN) editing tools are graphical, and as such based on explicit modeling, requiring good knowledge of the notation and its semantics, as well as the ability to analyze and abstract business requirements and capture them by correctly using the notation. As a consequence, their use can be cumbersome for live modeling during interviews and design workshops, where participants should not only provide input but also give feedback on how it has been represented in a model. To overcome this, in this paper we present the design and evaluation of BPMN Sketch Miner, a tool which combines notes taking in constrained natural language with process mining to automatically produce BPMN diagrams in real time as interview participants describe them with stories. In this work we discuss the design decisions regarding the trade-off between using mining vs. modelling in order to: 1) support a larger number of BPMN constructs in the textual language; 2) target both BPMN beginners and business analysts, in addition to the process participants themselves. The evaluation of the new version of the tool in terms of how it balances the expressiveness and learnability of its DSL with the usability of the text-to-visual sketching environment shows encouraging results. Namely while BPMN beginners could model a non-trivial process with the tool in a relatively short time and with good accuracy, business analysts appreciated the usability of the tool and the expressiveness of the language in terms of supported BPMN constructs.},
	keywords = {BPMN, domain specific languages, live modeling, text to visual},
	doi = {10.1145/3365438.3410990},
	author = {Ana Ivanchikj and Souhaila Serbout and Cesare Pautasso}
}
