Annex to: Bridging Models and Practice: Action Rules in a DEMO-Based Low-Code Platform

Bridging Models and Practice: Action Rules in a DEMO-Based Low-Code Platform ANNEX TO PAPER SUBMITTED TO THE POEM 2025 CONFERENCE Vítor Freitas1,3 [0009−0002−0667−5749], David Aveiro1,2,3[0000−0001−6453−3648], Duarte Pinto1,2 [0000-0002-8451-5727] 1 ARDITI - Regional Agency for the Development of Research, Technology and Innovation, 9020-105 Funchal, Portugal 2 NOVA-LINCS, Universidade NOVA de Lisboa, Campus da Caparica, 2829-516 Caparica, Portugal 3 Faculty of Exact Sciences and Engineering, University of Madeira, Caminho da Penteada 9020-105 Funchal, Portugal vitor[email protected], [email protected], [email protected] Introduction This annex provides additional technical details and diagrams that complement the main body of the paper submitted to PoEM 2025. It includes a more detailed explanation of the new representations of the Process Model and the Fact Model along with examples. New Process Model Representation The alternative Process Structure Diagram (PSD) representation for DEMO's PM which integrates some contents of the CM, in order to improve the clarity, reduce the redundancies and complexity and increase the transparency in the representations allowing for a more comprehensive representation of the operational flow of the organizational processes. These goals are achieved by: 1) simplifying the nomenclature, to make it more accessible for non-specialists, like for instance renaming “transactions” to “tasks” to align with the common language used within organizations, 2) enhancing the process model diagram by offering an alternative notation with more visual queues and taking advantage of colours and 3) moving the fine details of the process model to a transaction description table removing the clutter from the overall picture in the diagram representation but allowing it all to still be easily accessible and manageable when the need arises, using the process model diagram. In Figure 2 we can find the PSD for the MHP. This new approach offers a clear separation of concerns regarding process composition, task causation, and task waiting. The full legend for this approach can be seen in Figure 1. Regarding connectors, diamonds represent the compositional perspective, arrows depict causal relationships between tasks, and double-crossed lines indicate waiting dependencies. The colour gradients on border transactions facilitate rapid comprehension of task initiation and execution. These gradients distinguish between tasks initiated by internal actors and those executed by external actors (and vice versa). The solid lines represent the mandatory tasks, whereas the dashed lines indicate the optional tasks. The cardinality (frequency), is represented using number indicators at the endings of connectors, such as 1..*. For the most common case, where the cardinality is 1..1, its representation is omitted as to not clutter the representation. Figure 1. Process Model Diagram Legend Figure 2. Process Model Diagram The Municipality Hearing Process (MHP) involves several steps to ensure efficient citizen engagement. Before a hearing takes place, each Hearing Officer (an individual or group of individuals with a position of responsibility in specific domains inside the municipality, for example, construction licensing or water distribution) needs to have their schedule defined. Traditionally, each Hearing Officer has a specific day in the week when they provide a certain number of hearings to the Citizen for them to expose their claims. Once the scheduling is settled, the Hearing Officer can be subject to a Hearing Request by the Citizens. The traditional way for this to happen is for the Citizen to go to the municipality’s service desk and request a hearing. The clerk will then ascertain the need for said hearing and collect all the relevant information such as citizen identification, the process, the subject or relevant observations. These clerks are trained and follow a set of guidelines allowing them to determine if a hearing should take place, or not, at a given time for multiple reasons. For example, if a previous hearing with the same citizen/theme took place a short time before, or that the process it pertains to is too recent. If a hearing request reason is deemed justifiable to happen, the clerk fills the request form and then proceeds to print a PDF file of the accepted request to give as proof to the citizen. The next step is to define who (Hearing Officer) is the most relevant to attend the citizen’s claim in a hearing. In some cases, the claim may involve multiple departments of the municipality and the clerk may not be able to ascertain the correct individual on the spot, so they can ask the Hearing Officers themselves or their assistants if they are indeed the most qualified for that hearing before proceeding to its scheduling. Once the correct Hearing Officer has been identified and selected, a hearing can be scheduled, traditionally by the clerks, that will then proceed to print another PDF file with the Hearing details and send it to the Citizen by email or postal mail. Between this time and the time of the hearing both the Citizen and the Hearing Officers can request the cancellation or rescheduling of the hearing for multiple reasons, like that their schedule has changed, and they cannot be present at the defined time slot or simply that the reason for the hearing itself is no longer valid. Because the Hearings might take some time to happen, it is often the case that the claim from the citizen has already been resolved and as such, it is normal for the Hearing Officers to check their future scheduled hearings and identify those that no longer are needed. If that is not the case, the hearing meeting eventually takes place on the defined or rescheduled date. After the meeting, the conclusions and observations are added to the process, and it’s concluded by the Hearing Official. Besides the main process, there are additional tasks that need to be performed, like being able to print the Hearing Officials schedule each day as well as access the history of all hearings from a specific citizen. New Fact Model Representation In the older version of the official DEMO's FM some issues were identified, namely the complexity and poor usability caused by the over-cluttering of shapes that are hard to understand by those not specialized in DEMO, the lack of flexibility to accommodate changes and updates, and the inadequate visual representations with multiple symbols that are not intuitive and can lead to misinterpretation and errors. To address these problems, an alternative notation has been proposed, with what are considered simpler and more intuitive diagrams and tables, readable by any stakeholders that have no knowledge of DEMO, just business know-how. These new representations also address dynamic changes to the models, thus increasing their flexibility and allow for a more detailed representation of facts including their origins and relationships that help to more accurately document and track the process being modelled. The main artifact of this new Fact Model is the Concepts and Relationships Diagram (CRD), a generic, global, and synthetic view of an entire domain’s concepts while abstracting from their attributes. In the CDR, a concept is represented by a collapsible box whose expansion discloses its attributes, one per line. The value type of the attribute is specified to the left of the line, while to the right is the attribute's name. The value type can be any of the following options: category, reference, document, text, doc & text, number, date, or boolean. Arrows express relationships, which will always consist of an attribute in one concept whose instances will reference instances of the other concept. Cardinalities are represented with arrows pointing to relationships’ “one side”. A dark-filled circle attached to a concept in one connector means that an instance of this concept, in order to exist, depends on an instance of the concept at the other end of the connector. The specialization/generalization relationship is depicted using a connector with a pointed line. In Figure 3, we can find the CRD of the MHP case study. A detailed explanation of each concept in the model follows. The Citizen concept represents the person (or group of people, like, for example, a condominium) who initiates a Hearing Request. An Employee is a worker of the Municipality. Both of these concept's data are managed by specific systems of the municipality and a copy of them is kept in the low-code system, synchronized. There are multiple roles involved in the hearing process, such as municipality clerks, assistants, and the hearing officers of multiple sections of the Municipality. The Hearing Officers are the Municipality councilors/directors or task forces created for specific subjects such as large construction developments who can assist the Citizen(s) through hearings. The Hearing Officers require more attributes than regular employees, and as such warrant a concept of their own. These attributes include their area of expertise, their role in the section they are part of (that might not be the same as in the municipality Active Directory) and address information (that is also the hearing location). The Schedule Block concept, which is associated to each of the Hearing Officers and represents a time frame when a Hearing Officer is available to hold Hearings, which are traditionally a few hours at a specific day in a week and apply during a long period of time, allowing the creation of Hearing Slots in batch for each of those days, based on the input information like, start and end time and dates, the recurring day of the week and the duration for each slot. The Hearing Slot concept is an automatically generated time slot based on a Schedule Block that can hold a hearing. These slots are open by default when created and become occupied when a hearing is associated with them. Each one references the day, start time and end time and the order in the hearings of that given day. On events of a rescheduling, a flag is used to mark the necessity to check the rescheduling concept for the new allocated slot for the hearing. Figure 3. Concepts and Relationships Diagram A Hearing Request concept precedes a concrete hearing, citizens can make hearing requests at the municipalities front desk and these are handled by their front desk clerks. They detail the necessary information for the hearing to take place, but also include pertinent observations as well as hidden observations that may influence the outcome of the request. For example, if a citizen already had a hearing for the same subject a short time ago, a new hearing traditionally won’t be scheduled as it is unlikely to have been any relevant progress or that the outcome from the previous hearing would change. The Hearing concept represents the hearing itself and contains all the information related to it, the scheduled date, the observations, and outcomes of the hearing. As mentioned before, each hearing derives from a hearing request, although not all requests end up in a hearing, and all hearings take place in a hearing slot from the hearing officer that is selected as the most qualified to deal with the subject at hand. Finally, the rescheduling concept happens when a hearing that was scheduled to happen in a certain Hearing Slot, but has to be rescheduled and set to another Hearing Slot. This can happen for multiple impediments, both by the citizen or the hearing officer. The concept itself saves the information related to that change, referencing the original (old) and the new Hearing Slot, the employee that made that change, the reason(s) to that change, the new date for the hearing as well as some information about notifying the citizen(s) of this change when the change was generated internally (by or on behalf of the hearing officer).