A tour into my Research

Welcome to my Research page.

I do research on Software Architecture. An architecture represents the backbone of any software system. You may use an iterative development process or adopt an agile software development production process, still, you will have to define (more or less explicitly) an architecture for your system.

I have been spending my past twenty years in (re)searching for new methods and tools for Architecting Complex Software Systems.

My research has initially looked into new methods for software architecture-based testing and analysis. During my PhD, I have been investigating on how to use software architecture for code testing and regression testing. Then, I expanded my interests to the design and verification of architectural specifications using model-checking, as well as combining architecture-based testing and model-checking. But what if a system evolves at run-time? My next research on run-time failure prediction for dynamically evolving systems has coped with this challenge by using proactive monitoring techniques. On how to use software architecture for fault tolerance has been also investigated in our book.

I then moved my focus on the role plaid by architecture descriptions. How to make (different) architectural languages interoperable has been investigated by my team in a number of papers, the most significant being titled “Providing Architectural Languages and Tools Interoperability through Model Transformation Technologies“. We also investigated on how to extend architectural languages so to make them expanding according to stakeholder concerns.

But assuming that we know how to describe our architecture, how a team can make architecture design decisions collaboratively? This line of investigation is being conducted in collaboration with the Amrita Vishwa Vidyapeetham University. Our focus is to map Group Decision Making techniques to architecture design decisions practices. Collaboration has been investigated also from another perspective, that is, on tools and approaches for collaborative Modeling. This research line has brought us to write a classification framework and a research map on collaborative Model-Driven Software Engineering.

Since we are currently running a number of Smart City projects, another current focus is on how to architect IoT and Cyber-Physical Systems. In this line of (industrial) research, we are investigating new domain-specific architectural languages for the modeling and the simulation of Situational-Aware Cyber-Physical Systems. This work is being automated inside the CAPS tool.

Research Interests

  • Architecting Cyber Physical Spaces
  • Data traffic simulation of Cyber-Physical Systems' Architectures
  • Crowd Evacuation Handling through the IoT
  • Collaborative Model Driven Engineering
  • Group Decision Making in Software Architecture Design
  • Architecture Descriptions
  • Architecutural Models Interoperability
  • Architecting Fault Tolerant Systems
  • Architecture-based Model-Checking
  • Architecture-based Analysis and Testing

Current Research Interests

  • Architecting Cyber-Physical Spaces

    Architecting Cyber-Physical Spaces

    Research Goal: to engineer cyber-physical spaces through domain specific languages. Our Research: this research line investigates on a modeling framework for the domain-specific modeling and reasoning of situational-aware cyber-physical Systems...

    In the age of the Internet of Things (IoT) the architecting of a software system requires to both engineer its software, its hardware and the space where both will be deployed. This research line investigates on a modeling framework for the domain-specific modeling and reasoning of situational-aware cyber-physical Systems.

    For this purpose, my research team introduces the CAPS, a framework aimed at supporting the architecture description, reasoning, and design decision process for situational aware IoT systems. The CAPS is based on a multi-view architectural approach based on three (plus two) modeling languages to describe a SiACPS from different viewpoints, and namely: (i) software components and their interactions, (ii) the hardware specification of situational awareness equipment, (iii) the physical environment where hardware equipment is deployed.


     

    The Software Architecture View

    The software architecture view supports architects in the definition of the software architecture of the SiA-CPS application through the SAML modeling language. This view looks exclusively to software elements, with a specific focus on the architecture structure and its behavior. Briefly, the SAML view describes how components and
    connections exchange messages through message ports. Each component in SAML model can declare a set of modes, and each mode can contain a list of events, conditions, and actions, that altogether represent the behavior of the component. Moreover, application data manipulated by actions are defined inside the component.

     

     


     

     

    The Hardware View 

    The hardware view describes the hardware characteristics of each hardware element to be used within a SiA-CPS. A model in the hardware modeling language (HWML) encompasses specific low-level, node-specific information, like its memory, energy
    source, processor, installed sensing units and actuating units. A description of the HWML metamodel is reported in our publications.

     

     

     

     


    The Physical Space View

    The physical space view describes the physical site, in the real world, where the IoT equipment will be deployed. The space modeling language (SPML) provides support for developing 3D model editors. The CAPS modeling framework enables engineers to specify 3D syntaxes for SPML in a declarative way which will reduce the amount of effort and need for low-level expertise. It aims to support the standardization of a language for declarative specification of 3D concrete syntaxes for SiA-CPS. This view is especially useful for developers and system engineers when they have to
    consider the network topology, the presence of possible physical obstacles (e.g., walls, trees) within the network deployment area, and so on.


    Main Articles:

    Henry Muccini, Mohammad Sharaf: CAPS: Architecture Description of Situational Aware Cyber Physical Systems. ICSA 2017: 211-220

    Henry Muccini, Mohammad Sharaf: CAPS: A Tool for Architecting Situational-Aware Cyber-Physical Systems. ICSA Workshops2017: 286-289

    Angelika Musil, Juergen Musil, Danny Weyns, Tomás Bures, Henry Muccini, Mohammad Sharaf: Patterns for Self-Adaptation in Cyber-Physical Systems. Multi-Disciplinary Engineering for Cyber-Physical Production Systems 2017: 331-368

  • Analysis and Simulation of Situational-Aware Cyber-Physical Systems

    Analysis and Simulation of Situational-Aware Cyber-Physical Systems

    Research Goal: to analyze and simulate cyber-physical systems for data traffic and load and battery consumptions. Our Research: we propose a code generation framework that, by transforming CAPS models into the CupCarbon simulator input, supports the CAPS architecture simulation in terms of data traffic and load and battery consumptions.

    Situational aware cyber-physical systems (SiA-CPS) are cyber-physical systems that, by transforming sensed data into actionable intelligence, has the ability to observe the (user’s) surroundings and make detailed assessments of his environment. This work proposes a code generation framework that, by transforming CAPS models into the CupCarbon simulator input, supports the CAPS architecture simulation in terms of data traffic and load and battery consumptions.


    The objective

    The framework, through a group of code generators, transform SAML model (and then, HWML and SPML) into a completely functional code in different target languages platforms, like Java and Arduino. This paper will focus on the CupCarbon simulator languaged named Senscript. The CAPS simulation framework is realized by
    exploiting advanced Model-Driven Engineering (MDE) techniques , such as metamodelling, model weaving and model transformation.


    The to CupCarbon Transformation Process

    The transformation process

    The CAPS to CupCarbon transformation process four activities: parsing, analyzing, generating script and generating project. These activities are detailed in the following sections.

     


    Main Articles

    Mohammad SharafMoamin AbughazalaHenry MucciniMai AbusairAn Architecture Framework for Modelling and Simulation of Situational-Aware Cyber-Physical Systems. ECSA 2017: 95-111

    Mohammad SharafMoamin AbughazalaHenry MucciniMai AbusairCAPSim: simulation and code generation based on the CAPS. ECSA (Companion) 2017: 56-60

    Mohammad SharafMoamin AbughazalaHenry MucciniMai AbusairSimulating architectures of situational-aware cyber-physical space. ECSA (Companion) 2017: 66-67

  • A Cyber-Physical Space Operational Approach for Crowd Evacuation Handling

    A Cyber-Physical Space Operational Approach for Crowd Evacuation Handling

    Research Goal: to engineer crowd evacuation IoT applications. Our Research: i) to define an evacuation algorithm that takes in input run-time data collected through IoT devices and returns a recommender system to support operators to evacuate people, ii) an engineering framework to architect IoT systems to make Cyber-Physical Spaces supporting evacuation.

    Crowded public venues are significantly under risks and uncertainties caused by fire and overcrowding hazards. For this purpose, Situational Awareness (SiA) -that is a mechanism to know what is going on around- can facilitate the automatic (or human involved) critical decision making and executing processes. Considering the dynamic and uncertain essence of crowd and hazard behavior in an emergency, executing the optimum evacuation plan is highly complex and needs strong models. In this research, taking in input a model of the Cyber-Physical Space under SiA monitoring, we define an architectural-map-based Dynamic Bayesian Network (DBN) to describe and predict crowd and hazard behavior. Then, in order to minimize the total evacuation time, the authors present a quickest flow model for consecutive time intervals. Overall, the paper shows the importance of hazard quiddity, and crowd behavior on the evacuation efficiency in emergency situations. The approach is demonstrated through a small (but concrete) running example.


    Main articles:

    Henry MucciniMahyar Tourchi MoghaddamA Cyber-Physical Space Operational Approach for Crowd Evacuation Handling. SERENE 2017: 81-95

  • Architecture Design Decisions and Group Decision Making

    Architecture Design Decisions and Group Decision Making

    Research Goal: to understand the impact of group decision making practices into architecture design decisions. Our Research is devoted to: i) understand the state-of-the practice in architecture group decision making (GDM), ii) propose new architecture-specific GDM approaches to minimize conflict resolution time.

    Designing a good architecture involves making the right architecture design decisions (ADDs). Therefore, design decisions can be looked at as first class entities. Substantial amount of research has been carried out, in the last decade, to document and record ADDs in the form of Architectural Knowledge and the design of tools and methods to support the decision making process. While most of these tools and methods put an individual at the centre of the design decision process, the industrial studies on ADDs show that decisions are taken by groups of stakeholders. With several stakeholders interacting with each other to make key ADDs, it may be useful to view SA decision-making as a Group Decision Making (GDM) process. Therefore,
    “Architecting = Group Decision Making” is the way we would like to re-phrase and expand Hans Van Vliet’s statement. The “group” dimension adds another layer of complexity and opportunities to the current decision making processes and methods.
    Existing SA decision making tools and methods provide very little support for the group decision making processes followed in organizations while architecting software. The vast amount of knowledge and insights available in GDM literature is yet to be harnessed by the SA community.

    The research questions that guide our study are: RQ1: What are the existing Group Decision Making practices in real world SA groups? RQ2: Are the group decision-making techniques currently being practiced in line with techniques in GDM literature? RQ3. What are the challenges that SA groups face while making architecture-related group decisions? RQ4: How satisfied are SA group members with various aspects of GDM?


    Main articles

    Henry MucciniDamian Andrew TamburriV. Smrithi RekhaOn the Social Dimensions of Architectural Decisions. ECSA 2015: 137-145

    V. Smrithi RekhaHenry MucciniSuitability of Software Architecture Decision Making Methods for Group Decisions. ECSA 2014: 17-32

    V. Smrithi RekhaHenry MucciniA Study on Group Decision-Making in Software Architecture. WICSA 2014: 185-194

  • Collaborative Model Driven Software Engineering

    Collaborative Model Driven Software Engineering

    Research Goal: to design and develop novel tools for supporting collaborative work on modeling artifacts. Our Research: it comprises two main stepts: The first layer of the taxonomy is composed of three elements: target stakeholders, workspace awareness, and communication support.

    Collaborative Model-Driven Software Engineering (MDSE) consists of methods and techniques where multiple stakeholders manage, collaborate, and are aware of each others’ work on shared models. Collaborative MDSE is attracting research efforts from different areas, resulting in a variegated scientific body of knowledge. Our research is composed of two steps:  i) identifying, classifying, and understanding existing collaborative MDSE approaches, ii) propose new frameworks for supporting MDSE.

    In relation to our first step, we run a study to depict a research map on “Collaborative Model-Driven Software Engineering“. Based on this study, we defined three complementary dimensions of collaborative MDSE: a model management infrastructure for managing the life cycle of the models, a set of collaboration means
    for allowing involved stakeholders to work on the modelling artifacts collaboratively, and a set of communication means for allowing involved stakeholders to be aware of the activities of the other stakeholders, exchange messages and information within the team, sharing (design) decisions, reducing potential ambiguities, and more.


    Communication

    This dimension describes the characteristics of collaborative MDSE approaches with respect to the stakeholders’ communication aspect. The first layer of the taxonomy is composed of three elements: target stakeholders, workspace awareness, and communication support.

     

     

     


     

    Collaboration

    This dimension describes the characteristics of collaborative MDSE approaches with respect to the stakeholders’ collaboration aspect. By analyzing the primary studies under such a dimension, specific concepts have been identified
    as shown in the figure on the right. According to the elicited CollaborationType concept, stakeholders can work on
    the same modeling artifacts in different manners as shown in the “Collaborative Model-Driven Software Engineering” article. Two are the main collaboration means: synchronous and asynchronous.

     


     

    Model Management

    The model management dimension includes a set of representative concepts. The first layer of the taxonomy is composed of five elements: supported artifact, modeling language, editor, application domain, and multi-view support. They are all discussed in the “Collaborative Model-Driven Software Engineering” article.

Research Collaborators

Mohammad Sharaf

Mohammad Sharaf

Postdoctoral fellow

Smrithi Rekha V.

Smrithi Rekha V.

Phd Student

Mahyar Tourchi Moghaddam

Mahyar Tourchi Moghaddam

PhD student

Mirco Franzago

Mirco Franzago

Postdoctoral fellow

 Karthik Vaidyanathan

Karthik Vaidyanathan

PhD Student

Ivano Malavolta

Ivano Malavolta

Assistant Professor, VU University Amsterdam

Follow

Many thank to my Team!

I wish to thank all my present and past collaborators for the continuous enrichment they provide to my knowledge and person. Most of my research would not be possible without them.