Implementing a Debugger for Dresden OCL

Although originally designed as an extension for the Unifi ed Modeling Language (UML), today, the Object Constraint Language (OCL) has been broadly adopted in the context of both UML and other modeling and domain-specifi c languages. However, appropriate tooling, supporting modelers and software developers on using OCL is still scarce and lacks important features such as debugging support. As OCL constraints are likely to become rather complex for real world examples, it is hard to comprehend the in uence of single OCL expressions and subexpressions on the result of a completely evaluated OCL constraint in the context of speci fic constrained objects. Therefore, debugging is of topmost importance for both constraint comprehension and maintenance. Thus, the major task of this work is to develop a graphical debugger integrated into Dresden OCL and the Eclipse Integrated Development Environment (IDE) to fill this gap.:1 Introduction 2 The Dresden OCL Toolkit 2.1 The Dresden OCL Toolkit 2.2 The Dresden OCL2 Toolkit 2.3 Dresden OCL2 for Eclipse 2.4 Dresden OCL 3 The Eclipse Debugging Framework 3.1 The Debug Model 3.2 Interacting with the Debug Model 3.3 The Execution Control Commands 4 Requirements Analysis and Related Work 4.1 Requirements Analysis 4.2 Related Work 5 Design and Structure 5.1 Architecture 5.1.1 Package Structure 5.1.2 Class Structure 5.2 The OCL Debug Model 5.3 The Mapping from ASM to AST 5.4 The OCL Debugger 5.4.1 The Implementation of the Debugger 5.4.2 Testing the Debugger 6 Graphical User Interface Implementation 6.1 The Dresden OCL Debug Perspective 6.2 Using the Debugger 6.2.1 Selecting a Model 6.2.2 Selecting a Model Instance 6.2.3 Debugging 6.3 Summary 7 Evaluation and Future Work 33 7.1 Evaluation 7.2 Future Work 8 Summary and Conclusio

Efficient Late Binding of Dynamic Function Compositions

Adaptive software becomes more and more important as computing is increasingly context-dependent. Runtime adaptability can be achieved by dynamically selecting and applying context-specific code. Role-oriented programming has been proposed as a paradigm to enable runtime adaptive software by design. Roles change the objects’ behavior at runtime and thus allow adapting the software to a given context. However, this increased variability and expressiveness has a direct impact on performance and memory consumption. We found a high overhead in the steady-state performance of executing compositions of adaptations. This paper presents a new approach to use run-time information to construct a dispatch plan that can be executed efficiently by the JVM. The concept of late binding is extended to dynamic function compositions. We evaluated the implementation with a benchmark for role-oriented programming languages leveraging context-dependent role semantics achieving a mean speedup of 2.79× over the regular implementation

A CONTEXT-AWARE ROLE-PLAYING AUTOMATON FOR SELF-ADAPTIVE SYSTEMS

Role-based modeling and programming will become more and more important to realize big, complex, and adaptive software systems [Zhu and Alkins, 2006]. Therefore, the Object-Oriented Programming (OOP) paradigm is extended with roles, where objects can begin to play roles and drop roles dynamically at runtime. Playing a role is changing the object’s type which can add or change behavior. Roles are a dynamic view of the state and behavior of objects at runtime at a point of time highlighting their relations to other objects. Self-adaptive systems (SAS) are naturally context-aware systems. Thus, adaption is always seen in a context e.g., because a sensor value passes a specified limit, or because the reason could be derived from the knowledge about the past and presence. However, there is currently no common concept describing the situation (e.g., the context or other conditions that lead to a specific adaption) in which objects begin to play and stop playing roles. Current role programming languages therefore suffer from the problem of tangling of different aspects i.e., the context logic, the role adaption logic, and the business logic. This leads to less understandable and unmaintainable code [Antinyan et al., 2014]. Thomas Kühn has drafted in his major thesis [Kühn, 2011] a behavioral model to describe role binding with storyboards. This allows to model concisely role reconfigurations, but the concept lacks the ability to specify context-dependent behavior which is crucial for self-adaptive systems, and is built on top of an outdated understanding of the role concept which lacks compartments. The concept of storyboards will be extended with the ability to address context-dependent conditions. Compartments will be added in order to adapt the current wider understanding of the concept of roles. This will result in a concept for context-aware storyboards with roles which provide a separation of concerns approach w.r.t. the above named concerns. The concept will be implemented as automaton and will be evaluated on a use case. The use case is a robotic co-working scenario based on the idea of [Haddadin et al., 2009].:1. Introduction 1.1. Motivation 1.2. Outline 2. Background and Concepts 2.1. Role-Based Design 2.1.1. Roles and Role Models 2.1.2. Role Binding 2.1.3. Role Runtime Systems 2.2. Modeling Concepts for a Role-Playing Automaton 2.2.1. Models and Meta-models 2.2.2. Behavioral Diagrams and Automata 2.2.3. Storyboards 2.3. Relevant Software Architectures 2.3.1. Context-Aware Computing 2.3.2. Self-Adaptive Systems 2.3.3. Event-Based Systems 2.4. Summary 3. Requirements Analysis 3.1. Problem Analysis 3.2. Goals and Requirements 3.3. Technology Analysis and Selection 3.3.1. Pattern Matching 3.3.2. Model Execution 3.4. Summary 4. Concept for a Role-Playing Automaton for Self-Adaptive Systems 4.1. Context-Aware Storyboards with Roles 4.2. Syntax and Semantics 4.2.1. Overview 4.2.2. Story Pattern 4.2.3. Transitions, Events, and Guards 4.2.4. Control Nodes 4.2.5. Variable Binding 4.3. Meta-Model 4.4. Differences to Related Concepts 4.4.1. Relation to UML Activity Diagrams 4.4.2. Differences to Story Diagrams 4.4.3. Differences to Storyboards with Roles 4.5. Summary 5. Implementation 5.1. Architecture 5.2. Implementation 5.2.1. Grammar and Meta-model 5.2.2. Model Transformation 5.2.3. Graph Transformation 5.2.4. The Role Model 5.2.5. Context and Events 5.2.6. Model Execution and Validation 5.3. Summary 6. Related Work 6.1. Context-Aware Middleware for URC System 6.2. Context Petri Nets 6.3. Agent-Based and Context-Oriented Approach for Web Services Composition 6.4. Model Driven Design of Service-Based Context-Aware Applications 6.5. Summary 7. Evaluation 7.1. Use Case Robotic Co-Worker 7.2.Results 7.3.Summary 8. Conclusion and FutureWork 8.1.Conclusion 8.2.FutureWork A. Appendices A.1. Grammar for Storyboards with Roles A.2. Exemplary of a StoryDiagram A.3. Meta-Model of Context-Aware Storyboards With Role

Search for new particles in events with energetic jets and large missing transverse momentum in proton-proton collisions at root s=13 TeV

A search is presented for new particles produced at the LHC in proton-proton collisions at root s = 13 TeV, using events with energetic jets and large missing transverse momentum. The analysis is based on a data sample corresponding to an integrated luminosity of 101 fb(-1), collected in 2017-2018 with the CMS detector. Machine learning techniques are used to define separate categories for events with narrow jets from initial-state radiation and events with large-radius jets consistent with a hadronic decay of a W or Z boson. A statistical combination is made with an earlier search based on a data sample of 36 fb(-1), collected in 2016. No significant excess of events is observed with respect to the standard model background expectation determined from control samples in data. The results are interpreted in terms of limits on the branching fraction of an invisible decay of the Higgs boson, as well as constraints on simplified models of dark matter, on first-generation scalar leptoquarks decaying to quarks and neutrinos, and on models with large extra dimensions. Several of the new limits, specifically for spin-1 dark matter mediators, pseudoscalar mediators, colored mediators, and leptoquarks, are the most restrictive to date.Peer reviewe

Probing effective field theory operators in the associated production of top quarks with a Z boson in multilepton final states at root s=13 TeV

Peer reviewe

A SELF-DEPLOYING AND SELF-STABILIZING HELICAL ANTENNA FOR SMALL SATELLITES

Space antennas with a helical geometry are an advantageous choice for many applications, for instance if the transmission of electromagnetic waves with a circular polarization is intended, or if signals from terrestrial objects shall be received with a high angular resolution. In all these cases the desired electromagnetic properties of a helical geometry can be combined with the mechanical advantage that the antenna acts as a compression spring, provided that its core structure has the necessary high spring stiffness but can nevertheless easily be compressed. Such an antenna has been developed by DLR Institutes in Bremen and Braunschweig together with some industrial partners for a small satellite named AISat which shall be able to pursue the position of individual ships in critical sea areas in order to improve the security of seafare trade. The development was very challenging since the antenna must expand from a stowed stack length of only 10 centimeters to a total length of 4 meters. Only a special carbonfiber core under the conductive coating and a system of stabilizing cords led to a satisfying solution. Both the self-deployment and the self-stabilization function of this innovative antenna concept have been successfully tested and verified under zero-g-conditions in the course of a parabolic flight campaign. It could be convincingly demonstrated that the helical antenna can really achieve its desired contour in weightlessness within some seconds and maintain the required stability. Beyond the current application for the AISat satellite it is therefore a quite promising concept for future satellites

Implementing a Debugger for Dresden OCL

Although originally designed as an extension for the Unifi ed Modeling Language (UML), today, the Object Constraint Language (OCL) has been broadly adopted in the context of both UML and other modeling and domain-specifi c languages. However, appropriate tooling, supporting modelers and software developers on using OCL is still scarce and lacks important features such as debugging support. As OCL constraints are likely to become rather complex for real world examples, it is hard to comprehend the in uence of single OCL expressions and subexpressions on the result of a completely evaluated OCL constraint in the context of speci fic constrained objects. Therefore, debugging is of topmost importance for both constraint comprehension and maintenance. Thus, the major task of this work is to develop a graphical debugger integrated into Dresden OCL and the Eclipse Integrated Development Environment (IDE) to fill this gap.:1 Introduction 2 The Dresden OCL Toolkit 2.1 The Dresden OCL Toolkit 2.2 The Dresden OCL2 Toolkit 2.3 Dresden OCL2 for Eclipse 2.4 Dresden OCL 3 The Eclipse Debugging Framework 3.1 The Debug Model 3.2 Interacting with the Debug Model 3.3 The Execution Control Commands 4 Requirements Analysis and Related Work 4.1 Requirements Analysis 4.2 Related Work 5 Design and Structure 5.1 Architecture 5.1.1 Package Structure 5.1.2 Class Structure 5.2 The OCL Debug Model 5.3 The Mapping from ASM to AST 5.4 The OCL Debugger 5.4.1 The Implementation of the Debugger 5.4.2 Testing the Debugger 6 Graphical User Interface Implementation 6.1 The Dresden OCL Debug Perspective 6.2 Using the Debugger 6.2.1 Selecting a Model 6.2.2 Selecting a Model Instance 6.2.3 Debugging 6.3 Summary 7 Evaluation and Future Work 33 7.1 Evaluation 7.2 Future Work 8 Summary and Conclusio

A CONTEXT-AWARE ROLE-PLAYING AUTOMATON FOR SELF-ADAPTIVE SYSTEMS

Role-based modeling and programming will become more and more important to realize big, complex, and adaptive software systems [Zhu and Alkins, 2006]. Therefore, the Object-Oriented Programming (OOP) paradigm is extended with roles, where objects can begin to play roles and drop roles dynamically at runtime. Playing a role is changing the object’s type which can add or change behavior. Roles are a dynamic view of the state and behavior of objects at runtime at a point of time highlighting their relations to other objects. Self-adaptive systems (SAS) are naturally context-aware systems. Thus, adaption is always seen in a context e.g., because a sensor value passes a specified limit, or because the reason could be derived from the knowledge about the past and presence. However, there is currently no common concept describing the situation (e.g., the context or other conditions that lead to a specific adaption) in which objects begin to play and stop playing roles. Current role programming languages therefore suffer from the problem of tangling of different aspects i.e., the context logic, the role adaption logic, and the business logic. This leads to less understandable and unmaintainable code [Antinyan et al., 2014]. Thomas Kühn has drafted in his major thesis [Kühn, 2011] a behavioral model to describe role binding with storyboards. This allows to model concisely role reconfigurations, but the concept lacks the ability to specify context-dependent behavior which is crucial for self-adaptive systems, and is built on top of an outdated understanding of the role concept which lacks compartments. The concept of storyboards will be extended with the ability to address context-dependent conditions. Compartments will be added in order to adapt the current wider understanding of the concept of roles. This will result in a concept for context-aware storyboards with roles which provide a separation of concerns approach w.r.t. the above named concerns. The concept will be implemented as automaton and will be evaluated on a use case. The use case is a robotic co-working scenario based on the idea of [Haddadin et al., 2009].:1. Introduction 1.1. Motivation 1.2. Outline 2. Background and Concepts 2.1. Role-Based Design 2.1.1. Roles and Role Models 2.1.2. Role Binding 2.1.3. Role Runtime Systems 2.2. Modeling Concepts for a Role-Playing Automaton 2.2.1. Models and Meta-models 2.2.2. Behavioral Diagrams and Automata 2.2.3. Storyboards 2.3. Relevant Software Architectures 2.3.1. Context-Aware Computing 2.3.2. Self-Adaptive Systems 2.3.3. Event-Based Systems 2.4. Summary 3. Requirements Analysis 3.1. Problem Analysis 3.2. Goals and Requirements 3.3. Technology Analysis and Selection 3.3.1. Pattern Matching 3.3.2. Model Execution 3.4. Summary 4. Concept for a Role-Playing Automaton for Self-Adaptive Systems 4.1. Context-Aware Storyboards with Roles 4.2. Syntax and Semantics 4.2.1. Overview 4.2.2. Story Pattern 4.2.3. Transitions, Events, and Guards 4.2.4. Control Nodes 4.2.5. Variable Binding 4.3. Meta-Model 4.4. Differences to Related Concepts 4.4.1. Relation to UML Activity Diagrams 4.4.2. Differences to Story Diagrams 4.4.3. Differences to Storyboards with Roles 4.5. Summary 5. Implementation 5.1. Architecture 5.2. Implementation 5.2.1. Grammar and Meta-model 5.2.2. Model Transformation 5.2.3. Graph Transformation 5.2.4. The Role Model 5.2.5. Context and Events 5.2.6. Model Execution and Validation 5.3. Summary 6. Related Work 6.1. Context-Aware Middleware for URC System 6.2. Context Petri Nets 6.3. Agent-Based and Context-Oriented Approach for Web Services Composition 6.4. Model Driven Design of Service-Based Context-Aware Applications 6.5. Summary 7. Evaluation 7.1. Use Case Robotic Co-Worker 7.2.Results 7.3.Summary 8. Conclusion and FutureWork 8.1.Conclusion 8.2.FutureWork A. Appendices A.1. Grammar for Storyboards with Roles A.2. Exemplary of a StoryDiagram A.3. Meta-Model of Context-Aware Storyboards With Role

Implementing a Debugger for Dresden OCL

Although originally designed as an extension for the Unifi ed Modeling Language (UML), today, the Object Constraint Language (OCL) has been broadly adopted in the context of both UML and other modeling and domain-specifi c languages. However, appropriate tooling, supporting modelers and software developers on using OCL is still scarce and lacks important features such as debugging support. As OCL constraints are likely to become rather complex for real world examples, it is hard to comprehend the in uence of single OCL expressions and subexpressions on the result of a completely evaluated OCL constraint in the context of speci fic constrained objects. Therefore, debugging is of topmost importance for both constraint comprehension and maintenance. Thus, the major task of this work is to develop a graphical debugger integrated into Dresden OCL and the Eclipse Integrated Development Environment (IDE) to fill this gap.:1 Introduction 2 The Dresden OCL Toolkit 2.1 The Dresden OCL Toolkit 2.2 The Dresden OCL2 Toolkit 2.3 Dresden OCL2 for Eclipse 2.4 Dresden OCL 3 The Eclipse Debugging Framework 3.1 The Debug Model 3.2 Interacting with the Debug Model 3.3 The Execution Control Commands 4 Requirements Analysis and Related Work 4.1 Requirements Analysis 4.2 Related Work 5 Design and Structure 5.1 Architecture 5.1.1 Package Structure 5.1.2 Class Structure 5.2 The OCL Debug Model 5.3 The Mapping from ASM to AST 5.4 The OCL Debugger 5.4.1 The Implementation of the Debugger 5.4.2 Testing the Debugger 6 Graphical User Interface Implementation 6.1 The Dresden OCL Debug Perspective 6.2 Using the Debugger 6.2.1 Selecting a Model 6.2.2 Selecting a Model Instance 6.2.3 Debugging 6.3 Summary 7 Evaluation and Future Work 33 7.1 Evaluation 7.2 Future Work 8 Summary and Conclusio