Towards a framework for making applications provenance aware: UML2PROV

Editor's Notes

• #5: Provenance from experiments  Reproducibility
• #6: Diferentes contextos: Storage system  PASS Database  PERM workflow systems  Vistrails
• #10: Las contribuciones de esta tesis son tres, como explicaré en el resto de la intervención. El primero es un systematic review que ha sido publicado en una revista indexada en el journal citation reports. Luego la concept e implemet UML2PROV, que fueron presentadas y publicadas en los congresos.. Y además ha dado lugar aun articulo que ha sido mandado para publicación a la revista TSE, also indexed in JCR
• #11: Used for understanding the rest of this presentation,
• #14: As I said previously, provenance refers to the information explaining the existence piece of data. Concretely, we are interested in the information about the internal structure of a system, the evolution of the objects'’ states, and also how objects collaborate in order to execute operations. Taking this into account we decided to address class diagrams, state machine diagrams, and sequence diagrams
• #15: SEQ: They are used to model the interaction among collaborating objects and the exchange of information between them.  STM: They specify the discrete behaviour of individual elements of a system.  CD: They model the static structure of a system, therefore describing the elements of the system and the relationships between them.  Decir para que sirve cada tipo de diagram, -estados por los que va pasando un objeto -flujo de información -status de un objeto El nexo comun de todos estos es la operacion 1) SqDs reflects how collaborating objects interact for executing operations, and the exchange of information between them 2) CD shows the objects’ characteristics, and (2) the operations 3) SMD shows information about the evolution of the objects’ state as a consequence of operations executions taken place
• #18: This figure shows the organization of the family of documents which conforms the PROV standard.  We can see that the main document is called PROV-DM. This document is the conceptual data model, which defines the vocabulary used to represent the provenance information.  In this picture, we can see that the provenance defined using the vocabulary stated in the PROV-DM documents can be serialized in RDF (following the specification of PROV-O), XML (based on PROV-XML), and PROV-N.  Concretely, PROV-N is a readable text notation focused on human consumption.  In this thesis, we have used PROV in order to represent the provenance information, and concretely, PROV-N when we wanted to show readers concrete documents. 
• #20: Comentar alguna relacion Decir que hay mas
• #24: Taxonomy. Which could be used to analyse any provenance system Analysis. Open research problems that motivated this thesis.
• #25: 6 dimensions 25 categories
• #26: In bold are those aspects that do not appear in the original taxonomy. It is made up of 6 dimensions, each one containing different categories. 
• #27: Subject, which refers to the different subjects or levels of detail in which provenance data can be represented, also considering interoperability aspects.  
• #28: Storage, which describes the different approaches used by provenance systems to register provenance information. 
• #29: Data capture, which deals with the way in which provenance data can be captured on the existing provenance system. 
• #30: In bold are those aspects that do not appear in the original taxonomy.
• #31: In bold are those aspects that do not appear in the original taxonomy.
• #32: This analysis
• #34: Granularity: the amount and cost of provenance information can be inversely proportional to the granularity. In fact, the provenance information can grow larger than the data it describes if the data is fine-grained. Tracing: if we compute provenance immediately as the application is running, we need additional storage. If we compute provenance when necessary, it is not required additional space, but it is not applicable in all scenarios. Level: workflow-level and process-level depends on the amount of data per operation and the number of recorded operations. Technique: annotation: when we annotate existing data. It is required additional time and space. inversion: when we leverage a property by which some derivations can be inverted to find the input data. It does not need additional time and space.
• #37: <
• #40: These toold do not help us decide what information should be in the provenance. Cuanto antes se decida, major. Cuanto antes obtenga el diseño del provenance, mejor. Los toolkits no me ayudan a decidir la info que se va a añadir en el provenance. Y qu3e esta información, cuanto antes se tenga major.
• #41: En base a estos open problems, hemos visto la necesidad de definir UML2PROV, which will address these problems from the design phase of the application.
• #43: Stackeholders y roles Elementos
• #45: Qué es el BGM y para qué sirve
• #46: Podria decir que la integración es de forma no intrusive.
• #50: 1) SqDs reflects how collaborating objects interact for executing operations, and the exchange of information between them 2) CD shows the objects’ characteristics at some point, i.e. the object’s status, and (2) the operations that have led the objects’ status to be as they are. 3) SMD shows information about the evolution of the objects’ state as a consequence of operations executions taken place
• #52: Taking into account the previous principles, we have structured the definition of each pattern according to 4 items.
• #60: SeqP2 y que modela el enrolment…..
• #62: Para que son lor requisitos
• #63: R4 disappear
• #65: Hemos dado una definición conceptual, y ahora nos centramos en la implementación, que se basa en ella.
• #67: Hemos dado una definición conceptual, y ahora nos centramos en la implementación, que se basa en ella.
• #68: All our conceptual definition is based on models, concretely, we want to use the UML diagram models to obtain both prov template files and the code of the bgm. Thus, we have used tools from the context of Model driven development in order to implement our proposal. Explicar las dos transformations. It is worth noting that we could have implemented an only transformation from UML to templates. However we decided to implement an intermediate transformation in order to facilitate further implementation of PROV templates in diferent serialization formats. This implementation is a generic proposal that can be used by
• #69: It is worth noting that we could have implemented an only transformation from UML to templates. However we decided to implement an intermediate transformation in order to facilitate further implementation of PROV templates in diferent serialization formats. It is remarkable that our reference implementation for generating templates could be seen as a generic solution suitable for being used by any final user of UML2PROV, who has the UML design of its application. Such a reference implementation provides a complete automatic translation from any UML design to PROV templates as established by our patterns.
• #70: Hemos dado una definición conceptual, y ahora nos centramos en la implementación, que se basa en ella.
• #74: BGMEventListener It is a Java interface that defines four operations for managing each type of event (operationStart, operationEnd, newBinding, and newValueBinding). Such operations have an input parameter of type BGMEvent that contains the provenance data to be processed. The implementation of these operations constitutes the mechanism used by a class (implementing this interface) to generate, manage and store bindings. BGMEvent This component is used to carry information about the occurrence of an event. This information is the provenance data necessary for constructing the bindings. BGMEventManager. In some circumstances, having only one listener for managing bindings could not be enough, and the same happens with the mechanisms for generating and storing provenance.
• #75: BGMEventListener It is a Java interface that defines four operations for managing each type of event (operationStart, operationEnd, newBinding, and newValueBinding). Such operations have an input parameter of type BGMEvent that contains the provenance data to be processed. The implementation of these operations constitutes the mechanism used by a class (implementing this interface) to generate, manage and store bindings. BGMEvent This component is used to carry information about the occurrence of an event. This information is the provenance data necessary for constructing the bindings. BGMEventManager. In some circumstances, having only one listener for managing bindings could not be enough, and the same happens with the mechanisms for generating and storing provenance.
• #76: Hemos utilizado AOP porque nos permite capturar diferentes situaciones durante la ejecucion de un programa, invocaciones operaciones y ante esas capturas, coger provenance antes y despues. De forma no intrusiva Concretamente nos permite la captura…
• #77: Es un element muy importante porque la implementación de este componente define la estrategia de gestión y almacenamiento del provenance.
• #78: BGMEventListener It is a Java interface that defines four operations for managing each type of event (operationStart, operationEnd, newBinding, and newValueBinding). Such operations have an input parameter of type BGMEvent that contains the provenance data to be processed. The implementation of these operations constitutes the mechanism used by a class (implementing this interface) to generate, manage and store bindings. BGMEvent This component is used to carry information about the occurrence of an event. This information is the provenance data necessary for constructing the bindings. BGMEventManager. In some circumstances, having only one listener for managing bindings could not be enough, and the same happens with the mechanisms for generating and storing provenance.
• #79: BGMEventListener It is a Java interface that defines four operations for managing each type of event (operationStart, operationEnd, newBinding, and newValueBinding). Such operations have an input parameter of type BGMEvent that contains the provenance data to be processed. The implementation of these operations constitutes the mechanism used by a class (implementing this interface) to generate, manage and store bindings. BGMEvent This component is used to carry information about the occurrence of an event. This information is the provenance data necessary for constructing the bindings. BGMEventManager. In some circumstances, having only one listener for managing bindings could not be enough, and the same happens with the mechanisms for generating and storing provenance.
• #80: BGMEventListener It is a Java interface that defines four operations for managing each type of event (operationStart, operationEnd, newBinding, and newValueBinding). Such operations have an input parameter of type BGMEvent that contains the provenance data to be processed. The implementation of these operations constitutes the mechanism used by a class (implementing this interface) to generate, manage and store bindings. BGMEvent This component is used to carry information about the occurrence of an event. This information is the provenance data necessary for constructing the bindings. BGMEventManager. In some circumstances, having only one listener for managing bindings could not be enough, and the same happens with the mechanisms for generating and storing provenance.
• #81: BGMEventListener It is a Java interface that defines four operations for managing each type of event (operationStart, operationEnd, newBinding, and newValueBinding). Such operations have an input parameter of type BGMEvent that contains the provenance data to be processed. The implementation of these operations constitutes the mechanism used by a class (implementing this interface) to generate, manage and store bindings. BGMEvent This component is used to carry information about the occurrence of an event. This information is the provenance data necessary for constructing the bindings. BGMEventManager. In some circumstances, having only one listener for managing bindings could not be enough, and the same happens with the mechanisms for generating and storing provenance.
• #82: BGMEventListener It is a Java interface that defines four operations for managing each type of event (operationStart, operationEnd, newBinding, and newValueBinding). Such operations have an input parameter of type BGMEvent that contains the provenance data to be processed. The implementation of these operations constitutes the mechanism used by a class (implementing this interface) to generate, manage and store bindings. BGMEvent This component is used to carry information about the occurrence of an event. This information is the provenance data necessary for constructing the bindings. BGMEventManager. In some circumstances, having only one listener for managing bindings could not be enough, and the same happens with the mechanisms for generating and storing provenance.
• #83: BGMEventListener It is a Java interface that defines four operations for managing each type of event (operationStart, operationEnd, newBinding, and newValueBinding). Such operations have an input parameter of type BGMEvent that contains the provenance data to be processed. The implementation of these operations constitutes the mechanism used by a class (implementing this interface) to generate, manage and store bindings. BGMEvent This component is used to carry information about the occurrence of an event. This information is the provenance data necessary for constructing the bindings. BGMEventManager. In some circumstances, having only one listener for managing bindings could not be enough, and the same happens with the mechanisms for generating and storing provenance.
• #87: Aqui decir lo de que los usuarios se suelen preguntar como se hizo determinado experiment…
• #88: Referencia de GelJ
• #90: A mas tal mas cual
• #91: A mas tal mas cual
• #92: A mas tal mas cual
• #93: A mas tal mas cual
• #98: An alternative could be to examine how to adapt the transformation patterns, by selectively discarding some PROV elements or relations, and consequently to obtain coarser-grained data provenance. We could manage the amount of provenance information to be generated. For example, a UML designer may selectively discard provenance regarding specific input parameters of an operation. A fact that cannot by avoided with the current approach. Althoug our approach addresses three of the most widely used UML diagrams, an interesting line of further research is to explore how the information exposed by other types of UML diagrams could enrich the provenance to be generated.