Hafedh Mili

Imen Benzarti, Ikram Darif, Abderrahmane Leshob et al.

Human-centered Requirements Engineering (HC-RE) integrates user cognition, emotions, and social interactions into the RE process through contributions from disciplines such as psychology, cognitive science, design thinking, and human-computer interaction. Despite growing interest, how these multidisciplinary contributions are structured and why they remain fragmented across the RE lifecycle is not well understood. This systematic mapping study analyzes 56 primary studies across seven dimensions, including RE phases, user involvement techniques, contributing disciplines, and evaluation methods. Results show that 70\% of approaches involve multidisciplinary contributions, yet only 39% have been empirically evaluated and 48% address only the elicitation phase. A cross-study analysis reveals a structural separation between two parallel integration traditions: a Cognitive-Formal (C-F) pathway grounded in goal-based frameworks and formal modeling, and a Participatory-Iterative (P-I) pathway grounded in scenario-based frameworks and iterative design. Each pathway has developed complementary strengths, but their near-total disconnection explains the persistent lifecycle concentration and theory-practice gap observed in the corpus. The findings identify the absence of translation mechanisms between human-centered artifacts and formal RE specifications as the field's primary structural gap, provide a structured research agenda organized into four priority tiers, and establish the empirical foundation for Experience-Centered Requirements Engineering, a direction in which user experience is explicitly operationalized as a first-class concern in requirements specification.

Abir Trabelsi, Imen Benzarti, Hafedh Mili et al.

Translating business problems into well-specified machine learning solutions is a prerequisite for successful AI systems, yet this upstream translation is still one of the least supported steps in existing methodologies. We conduct a structured narrative literature review of 18 approaches spanning requirements engineering (RE), machine learning (ML) project management, and automation. We organize these approaches into a taxonomy of four families and compare them across six input artifact categories, six output artifact categories, and a transformation framework of seven stages, grounded in RE refinement theory and ML lifecycle process. Our study shows that most approaches list ML task or algorithm specification among their expected outputs, yet only four provide partial guidance for deriving it, and none provides systematic guidance. We characterize this gap as the Analytics Translation Problem (ATP) and derive five research recommendations addressing multi-formulation exploration, task derivation guidance, constraint-algorithm filtering, probabilistic traceability, and data-triggered revision.

Barthélémy Dagenais, Hafedh Mili

Aspect-oriented software development builds upon object-oriented development by offering additional abstraction boundaries that help us separate different types of requirements into so-called aspects. Given a legacy OO application, it pays to identify existing aspects to help understand the structure of the application and potentially to extract those aspects into separate software modules that can be maintained and reused individually. We present an approach to extract functional aspects using program slicing. We first characterize what we mean by functional aspect, and explore the extent to which program slicing techniques could improve over existing aspect mining and feature location methods for such aspects. We then describe the results of applying our approach to two medium-sized open source programs. Our preliminary results show that program slicing can yield well-defined functional aspects when the appropriate slicing criteria are used. Finally, we explore the effect of design quality on the candidate functional aspects.

Lokman Saleh, Hafedh Mili, Mounir Boukadoum et al.

Domain experts from all fields are called upon, working with data scientists, to explore the use of ML techniques to solve their problems. Starting from a domain problem/question, ML-based problem-solving typically involves three steps: (1) formulating the business problem (problem domain) as a data analysis problem (solution domain), (2) sketching a high-level ML-based solution pattern, given the domain requirements and the properties of the available data, and (3) designing and refining the different components of the solution pattern. There has to be a substantial body of ML problem solving knowledge that ML researchers agree on, and that ML practitioners routinely apply to solve the most common problems. Our work deals with capturing this body of knowledge, and embodying it in a ML problem solving workbench to helps domain specialists who are not ML experts to explore the ML solution space. This paper focuses on: 1) the representation of domain problems, ML problems, and the main ML solution artefacts, and 2) a heuristic matching function that helps identify the ML algorithm family that is most appropriate for the domain problem at hand, given the domain (expert) requirements, and the characteristics of the training data. We review related work and outline our strategy for validating the workbench

Alvine B. Belle, Ghizlane El Boussaidi, Timothy C. Lethbridge et al.

Architectural reconstruction is a reverse engineering activity aiming at recovering the missing decisions on a system. It can help identify the components, within a legacy software application, according to the application's architectural pattern. It is useful to identify architectural technical debt. We are interested in identifying layers within a layered application since the layered pattern is one of the most used patterns to structure large systems. Earlier component reconstruction work focusing on that pattern relied on generic component identification criteria, such as cohesion and coupling. Recent work has identified architectural-pattern specific criteria to identify components within that pattern. However, the architectural-pattern specific criteria that the layered pattern embodies are loosely defined. In this paper, we present a first systematic literature review (SLR) of the literature aiming at inventorying such criteria for layers within legacy applications and grouping them under four principles that embody the fundamental design principles under-lying the architectural pattern. We identify six such criteria in the form of design rules. We also perform a second systematic literature review to synthesize the literature on software architecture reconstruction in the light of these criteria. We report those principles, the rules they encompass, their representation, and their usage in software architecture reconstruction.

Hafedh Mili, Ghizlane El-Boussaidi, Anas Shatnawi et al.

Service-orientation views applications as orchestrations of independent software services that (1) implement functions that are reusable across many applications, (2) can be invoked remotely, and (3) are packaged to decouple potential callers from their implementation technology. As such, it enables organizations to develop quality applications faster than without services. Legacy applications are not service-oriented. Yet, they implement many reusable functions that could be exposed as \emph{services}. Organizations face three main issues when re-engineering legacy application to (re)use services: (1) to mine their existing applications for reusable functions that can become services, (2) to package those functions into services, and (3) to refactor legacy applications to invoke those services to ease future maintenance. In this paper, we explore these three issues and propose research directions to address them. We choose to focus on the service-oriented re-engineering of recent legacy object-oriented applications, and more specifically, on JEE applications, for several reasons. First, we wanted to focus on architectural challenges, and thus we choose to \textit{not} have to deal with programming language difference between source and target system. We chose JEE applications, in particular, because they embody the range of complexities that one can encounter in recent legacy applications, namely, multi-language systems, multi-tier applications, the reliance on external configuration files, and the reliance on frameworks and container services during runtime. These characteristics pose unique challenges for the three issues mentioned above.

Anas Shatnawi, Hafedh Mili, Manel Abdellatif et al.

Identifying dependency call graphs of multilanguage software systems using static code analysis is challenging. The different languages used in developing today's systems often have different lexical, syntactical, and semantic rules that make thorough analysis difficult. Also, they offer different modularization and dependency mechanisms, both within and between components. Finally, they promote and--or require varieties of frameworks offering different sets of services, which introduce hidden dependencies, invisible with current static code analysis approaches. In this paper, we identify five important challenges that static code analysis must overcome with multilanguage systems and we propose requirements to handle them. Then, we present solutions of these requirements to handle JEE applications, which combine server-side Java source code with a number of client-side Web dialects (e.g., JSP, JSF) while relying on frameworks (e.g., Web and EJB containers) that create hidden dependencies. Finally, we evaluate our implementations of the solutions by developing a set of tools to analyze JEE applications to build a dependency call graph and by applying these tools on two sample JEE applications. Our evaluation shows that our tools can solve the identified challenges and improve the recall in the identification of multilanguage dependencies compared to standard JEE static code analysis and, thus, indirectly that the proposed requirements are useful to build multilanguage static code analysis.

Anas Shatnawi, Hafedh Mili, Manel Abdellatif et al.

In this paper, we answer a set of research questions that are required to develop service identification approach based on the analysis of object- oriented software. Such research questions are: (1) what is a service, (2) how are services different from software components, (3) what are types of services, (4) what are existing service identification approaches that consider service types into account, and (5) how to identify services based on the object-oriented source code with respect to their types. Our methodology is based on performing a literature review to identify the answers of these research questions. Also, we propose a taxonomy of service types.

Anas Shatnawi, Hafedh Mili, Manel Abdellatif et al.

In this report, we propose our approach that identifies a KDM model of JSP pages. Our approach is based on two main steps. The first one aims to reduce the problem space by translating JSP pages into Java Servlets where we can use existing tools to identify a KDM model. The second step aims to complete the resulting KDM model by identifying dependencies of JSP tags that are not codified by the translation step.

Anas Shatnawi, Hafedh Mili, Manel Abdellatif et al.

In this paper, we propose a program slicing approach for the output stream object in JEE applications. Our approach is based on extracting a dependency call graph from KDM models of JEE applications. Then, it applies breath-first search algorithm to identify the program slice as a graph reachability problem. The proposed approach is implemented as an extension of our DeJEE tool.

Anas Shatnawi, Hafedh Mili, Manel Abdellatif et al.

Java Enterprise Edition (JEE) applications are implemented in terms of a set of components developed based on several JEE technologies includ- ing, but not limited to, Servlet, JSP, JSF, EJB, JavaBeans. These JEE technologies rely on a varied set of communication mechanisms to commu- nicate between each others. Examples of these communication mechanisms are HTTP requests, Remote Method Invocation (RMI), Java DateBase Connectivity (JDBC), etc. These communication mechanisms represent program dependencies between JEE components. However, one communi- cation mechanism can be implemented following different implementation ways by different JEE technologies. Therefore, to be able to detect related dependencies, we identify these implementation ways used by a set of JEE technologies. In this technical report, we focus on the Web tier technologies that are Servlets, JSPs and JSFs. Also, we present how these technologies access the JavaBeans and Manage Beans components.