Sufficient Criteria for Applicability and Non-Applicability of Rule Sequences

In several rule-based applications using graph transformation as underlying modeling technique the following questions arise: How can one be sure that a specific sequence of rules is applicable (resp. not applicable) on a given graph? Of course, it is possible to use a trial and error strategy to find out the answer to these questions. In this paper however, we will formulate suitable sufficient criteria for applicability and other ones for non-applicability. These criteria can be checked in a static way i.e. without trying to apply the whole rule sequence explicitly. Moreover if a certain criterion is not satisfied, then this is an indication for reasons why rule sequences may or may not be applicable. Consequently it is easier to rephrase critical rule sequences. The results are formulated within the framework of double pushout (DPO) graph transformations with negative application conditions (NACs)

Object Flow Definition for Refined Activity Diagrams: Long Version

Activity diagrams are a well-known means to model the control flow of system behavior. Their expressiveness can be enhanced by using their object flow notation. In addition, we refine activities by pairs of pre- and post-conditions formulated by interrelated object diagrams. To define a clear semantics for refined activity diagrams with object flow, we use a graph transformation approach. Control flow is formalized by sets of transformation rule sequences, while object flow is described by partial dependencies between transformation rules. The theory of algebraic graph transformation can be used to validate the consistency of control and object flows in refined activity diagrams. This approach is illustrated by a simple service-based on-line university calendar

Sufficient Criteria for Consistent Behavior Modeling with Refined Activity Diagrams: Long Version

In use case-driven approaches to requirements modeling, UML activity diagrams are a wide-spread means for refining the functional view of use cases. Early consistency validation of activity diagrams is therefore desirable but difficult due to the semi-formal nature of activity diagrams. In this paper, we specify well-structured activity diagrams and define activities more precisely by pre- and post- conditions. They can be modeled by interrelated pairs of object diagrams based on a domain class diagram. This activity refinement is based on the theory of graph transformation and paves the ground for a consistency analysis of the required system behavior. A formal semantics for activity diagrams refined by pre- and post-conditions allows us to establish sufficient criteria for consistency. The semi-automatic checking of these criteria is supported by a tool for graph transformation

Proceso marco orientado a aspectos en las etapas tempranas del ciclo de vida del desarrollo de software para una transición en la industria

Por una parte, se halló evidencia de la escasa presencia del paradigma de aspectos en la industria, pero, por otro lado, también se observó que sus beneficios, largamente mencionados en la literatura, sí se pudieron alcanzar en aquellos casos en los que se utilizó la orientación a aspectos en el mundo real, más allá de los ámbitos académicos. Al mismo tiempo, esa evidencia también mostró que las propuestas existentes son incompletas y muy pocas llegan a cubrir tan solo dos fases del ciclo de vida del desarrollo de software (en adelante, SDLC). Por esto es que surgió la motivación de elaborar una alternativa metodológica que permitiera su aplicación de inmediato en proyectos e iniciativas en el mundo real. Así, el objetivo de nuestro trabajo consistió en definir un proceso marco para las etapas tempranas del ciclo de vida del desarrollo de software, desde el modelo de negocios hasta la especificación completa de requisitos de software y empleando el paradigma de la orientación a aspectos. A la vez, se buscó propiciar el empleo en la industria de este paradigma para obtener sus beneficios, al aprovechar las herramientas y técnicas estándares disponibles actualmente en el mercado, mientras se siguen desarrollando otras específicas y alcanzan la madurez suficiente. Por tal razón, se decidió llamar a esta propuesta AOP4ST, sigla derivada de Aspect-Oriented Process for a Smooth Transition. Se trata de un proceso marco, no específico, de modo de permitir su empleo con diferentes modelos del ciclo de vida del desarrollo de software a lo largo de sus etapas tempranas y hasta obtener una especificación de requisitos completa y coherente, incluyendo tres vistas: funcional, estática y de estados. Este proceso emplea herramientas y técnicas estándares, de amplia difusión en la industria, para facilitar su adopción inmediata y, también, utiliza notaciones estándares, para permitir elaborar modelos y especificaciones comprensibles y no ambiguas, que puedan contar con el soporte de las herramientas de software actualmente disponibles en el mercado. Se procura que esta alternativa sea completamente orientada a aspectos, que facilite la obtención de las incumbencias en forma progresiva a lo largo de todos los modelos y, al mismo tiempo, las mantenga siempre separadas y asegurando la trazabilidad bidireccional entre ellas. Estas incumbencias deben obtenerse en forma natural a lo largo de todos los modelos, de manera de no afectar los objetivos propios de cada uno de ellos y, de este modo, potenciar los beneficios que se esperan en cada modelo mediante el empleo del paradigma de aspectos. En la sección 2 se presenta la motivación de este trabajo, incluyendo el estado de la cuestión y la problemática que se pretende resolver, en la sección 3 se describe la solución diseñada para dar solución a los inconvenientes mencionados y los aportes a la disciplina y, finalmente, la sección 4 presenta las líneas de investigación que quedan abiertas a partir de este trabajo.Eje: Tesis de Doctorado.Red de Universidades con Carreras en Informátic

Combining SOA and BPM Technologies for Cross-System Process Automation

This paper summarizes the results of an industry case study that introduced a cross-system business process automation solution based on a combination of SOA and BPM standard technologies (i.e., BPMN, BPEL, WSDL). Besides discussing major weaknesses of the existing, custom-built, solution and comparing them against experiences with the developed prototype, the paper presents a course of action for transforming the current solution into the proposed solution. This includes a general approach, consisting of four distinct steps, as well as specific action items that are to be performed for every step. The discussion also covers language and tool support and challenges arising from the transformation

Addressing aspect interactions in an industrial setting: experiences, problems and solutions

Aspect oriented programming (AOP) introduces new and powerful modularization constructs. The aspect module is used to encapsulate crosscutting concerns, which otherwise would remain tangled and scattered. The idea of encapsulating crosscutting concerns rapidly expanded to earlier phases in the development cycle, including requirement analysis (aspect oriented requirement engineering, AORE) and design (aspect oriented modeling, AOM). The overall application of aspect orientation concepts is known as aspect oriented software development (AOSD). AOP is not yet a mainstream practice. Particularly AOSD is still in its early stages. This is reflected in the lack of reports of full development cycles using aspect oriented approaches, especially using industrial case studies. Furthermore, the power of aspects comes at the price of new challenges, one of them is that systems built using aspects are more difficult to understand. The crosscutting nature of aspects allows them to alter the behavior of many other modules. As a result, aspects may interact in unintended and unanticipated ways. This problem is known as aspect interactions. In this work we deal with the aspect interaction problem in the context of an industrial domain: slots machines. We perform a complete development cycle of the slot machine software. This is, to the best of our knowledge, the first complete industrial case of study of aspect orientation. Through this experience we discovered the limitations with regard to aspect interactions, of some emblematic aspect oriented approaches for requirement engineering, design and implementation. The contribution of this work is threefold. Firstly, we contribute with the evaluation and extensions to some of AORE and AOM approaches, in order to provide explicit support for aspect interactions in requirement analysis and design phases. We also evaluate the implementation of interactions using a static and a dynamic AOP language, and propose an AspectJ extension that copes with aspect interactions. Secondly, this work is the first report of a complete aspect oriented development cycle of an industrial case study. Thirdly, this work provides a complex case study that presents several business logic crosscutting concerns, which in turn exhibit numerous aspect interactions, that serves as a challenging test bed for upcoming AOSD approaches.Facultad de Informátic

XXIII Edición del Workshop de Investigadores en Ciencias de la Computación : Libro de actas

Compilación de las ponencias presentadas en el XXIII Workshop de Investigadores en Ciencias de la Computación (WICC), llevado a cabo en Chilecito (La Rioja) en abril de 2021.Red de Universidades con Carreras en Informátic

Interaction analysis in aspect-oriented models

Aspect-oriented concepts are currently introduced in all phases of the software development life cycle. However, the complexity of interactions among different aspects and between aspects and base entities may reduce the value of aspect-oriented separation of cross-cutting concerns. Some interactions may be intended or may be emerging behavior, while others are the source of unexpected inconsistencies. It is therefore desirable to detect inconsistencies as early as possible, preferably at the modeling level. We propose an approach for analyzing interactions and potential inconsistencies at the level of requirements modeling. We use a variant of UML to model requirements in a use case driven approach. Activities that are used to refine use cases are the join points to compose crosscutting concerns. The activities and their composition are formalized using the theory of graph transformation systems, which provides analysis support for detecting potential conflicts and dependencies between rule-based transformations. This theory is used to effectively reason about potential interactions and inconsistencies caused by aspect-oriented composition. The analysis is performed with the graph transformation tool AGG. The automatically analyzed conflicts and dependencies also serve as an additional view that helps in better understanding the potential behavior of the composed syste