Monitoring-Oriented Programming: A Tool-Supported Methodology for Higher Quality Object-Oriented Software

This paper presents a tool-supported methodological paradigm for object-oriented software development, called monitoring-oriented programming and abbreviated MOP, in which runtime monitoring is a basic software design principle. The general idea underlying MOP is that software developers insert specifications in their code via annotations. Actual monitoring code is automatically synthesized from these annotations before compilation and integrated at appropriate places in the program, according to user-defined configuration attributes. This way, the specification is checked at runtime against the implementation. Moreover, violations and/or validations of specifications can trigger user-defined code at any points in the program, in particular recovery code, outputting or sending messages, or raising exceptions. The MOP paradigm does not promote or enforce any specific formalism to specify requirements: it allows the users to plug-in their favorite or domain-specific specification formalisms via logic plug-in modules. There are two major technical challenges that MOP supporting tools unavoidably face: monitor synthesis and monitor integration. The former is heavily dependent on the specification formalism and comes as part of the corresponding logic plug-in, while the latter is uniform for all specification formalisms and depends only on the target programming language. An experimental prototype tool, called Java-MOP, is also discussed, which currently supports most but not all of the desired MOP features. MOP aims at reducing the gap between formal specification and implementation, by integrating the two and allowing them together to form a system

Implementation of an XML-based user interface with applications in ice sheet modeling

The scientific domain presents unique challenges to software developers. This thesis describes the application of design patterns to the problem of dynamically changing interfaces to scientific application software (GLIMMER, which performs ice sheet modeling). In its present form, GLIMMER uses a text configuration file to define model behavior, set parameters, and structure model input/output (I/O). The creation of the configuration file presents a significant problem to users due to its format and complexity. GLIMMER is still under development, and the number of changes to configuration parameters, parameter types, and parameter dependencies makes devel-opment of any single interface of use only for a short term. The application of design patterns described here resulted in an interface specification tool that then generates multiple versions of a user interface usable across a wide variety of configuration pa-rameter types, values, and dependencies. The resulting products have leveraged de-sign patterns and solved problems associated with design pattern usage not found in the specialized software engineering literature

Optimal and Automated Deployment for Microservices

Microservices are highly modular and scalable Service Oriented Architectures. They underpin automated deployment practices like Continuous Deployment and Autoscaling. In this paper, we formalize these practices and show that automated deployment - proven undecidable in the general case - is algorithmically treatable for microservices. Our key assumption is that the configuration life-cycle of a microservice is split into two phases: (i) creation, which entails establishing initial connections with already available microservices, and (ii) subsequent binding/unbinding with other microservices. To illustrate the applicability of our approach, we implement an automatic optimal deployment tool and compute deployment plans for a realistic microservice architecture, modeled in the Abstract Behavioral Specification (ABS) language

Configuring a machining operation as a Constraint Satisfaction Problem

International audienceThe problem of configuring a machining operation is complex (many parameters and many interactions between parameters) and is generally achieved thanks to expert heuristic knowledge. Indeed, the configuration of a machining operation is often carried out according to a specific procedure: choice of a kind of operation and of a kind of machine, then choice of a set of tools and at the end selection of cutting conditions. We propose in this paper a general framework for the configuration of a machining operation based on a constraint representation and manipulation. We first present a model of the decision variables (such as the machine, the tool, the insert or the feed rate), the non-decision variable and the constraints between variables. An overview of the 32 identified constraints is given in the paper. Even though it is not exhaustive, the basic constraints of the domain are represented. A typology of the constraints to be manipulated is then given leading order to a specification of algorithms for search and consistency checking that may allow to manage these kinds of constraints

A tool for test automation with support for remote tests

This paper presents an interactive MS-Windows ®-based tool for high-level specification and analysis of tests on printed circuit boards, using the IEEE 1149.1 standard, and also on integrated circuits using scan design like the LSSD testing methodology. As novel contributions we provide an object-oriented tool for Boundary Scan and LSSD test automation with support for remote tests, including interfaces to circuit description, chip interconnection, test vector analysis and test vector generation. The system is a reasona'.Jly complete CAE test system that includes features like remote testing (using client- server technology), project management computer-aided learning support, menu-based command entry, user-defined configuration and a comprehensive set of commands. Thus, by using this system, a test engineer or a circuit designer are able to specify and verify tests for printed circuit boards or for integrated circuits, either ocally or remotely

InstanceCollage: a tool for the particularization of collaborative IMS-LD scripts

Current research work in e-learning and more specifically in the field of CSCL (Computer Supported Collaborative Learning) deals with design of collaborative activities, according to computer-interpretable specifications, such as IMS Learning Design, and their posterior enactment using LMSs (Learning Management Systems). A script that describes such collaborative activities is typically designed beforehand in order to structure collaboration, and defines the features that determine the behavior of the LMS, for instance, the sequence of activities or the groups/role distribution. In CSCL settings, group management and composition are especially relevant and affect the chances of achieving the expected learning outcomes. This paper presents a software tool, named InstanceCollage, which aims at facilitating the configuration and population of groups for IMS-LD scripts created with the authoring tool Collage, and discusses the implications of the IMS-LD specification with respect to this task. InstanceCollage is designed to process collaboration scripts based on CLFPs (Collaborative Learning Flow Patterns). Using this type of patterns, InstanceCollage focuses on the importance of understanding the function of groups within the learning strategy of the script. This paper describes the approach taken in InstanceCollage to facilitate this understanding for non-expert users. Additionally, two case studies are presented, which represent complex authentic collaborative learning scenarios, as a proof of concept of the functionality of this tool. The case studies are also used to illustrate the requirements of group configuration tools and to show that InstanceCollage complies to such requirements

Usability requirements for architectural analysis tool to support CBD

Component-based development is an architecture-centric process that relies on the integration of pre-fabricated software components. These are often blackbox components whose functionality and configuration may not match the “ideal” system architecture. Systematic architectural analysis can help ensure that risks resulting from architectural adaptations and trade-offs do not adversely affect critical system qualities (e.g. performance, security and modifiability). However, architectural analysis is a complex activity that involves planning, analysis, negotiation and assessment of large amounts of interrelated, often conflicting information. Good tool support is therefore essential for effective architectural analysis. However, the success of a tool depended not only on powerful analysis methods but also on the quality of the toolset's usability. This paper presents functional and non-functional requirements of the tool’s user interface, and discusses the HCI design principles and guidelines in designing a high-quality user interface that would allow developers to parse, analyse and modify architecture specification easily and effectively

Engineering the Hardware/Software Interface for Robotic Platforms - A Comparison of Applied Model Checking with Prolog and Alloy

Robotic platforms serve different use cases ranging from experiments for prototyping assistive applications up to embedded systems for realizing cyber-physical systems in various domains. We are using 1:10 scale miniature vehicles as a robotic platform to conduct research in the domain of self-driving cars and collaborative vehicle fleets. Thus, experiments with different sensors like e.g.~ultra-sonic, infrared, and rotary encoders need to be prepared and realized using our vehicle platform. For each setup, we need to configure the hardware/software interface board to handle all sensors and actors. Therefore, we need to find a specific configuration setting for each pin of the interface board that can handle our current hardware setup but which is also flexible enough to support further sensors or actors for future use cases. In this paper, we show how to model the domain of the configuration space for a hardware/software interface board to enable model checking for solving the tasks of finding any, all, and the best possible pin configuration. We present results from a formal experiment applying the declarative languages Alloy and Prolog to guide the process of engineering the hardware/software interface for robotic platforms on the example of a configuration complexity up to ten pins resulting in a configuration space greater than 14.5 million possibilities. Our results show that our domain model in Alloy performs better compared to Prolog to find feasible solutions for larger configurations with an average time of 0.58s. To find the best solution, our model for Prolog performs better taking only 1.38s for the largest desired configuration; however, this important use case is currently not covered by the existing tools for the hardware used as an example in this article.Comment: Presented at DSLRob 2013 (arXiv:cs/1312.5952