A UML-based proposal for IoT system requirements specification

The paper presents a preliminary version of IotReq, a method for the elicitation and specification of the requirements for an IoT-system. The first task suggested by IotReq is the modelling of the domain, using the UML and following the service-oriented paradigm, then the goals of the IoT-system to build are elicited and specified, again using the UML and extending the domain model, producing a specification of the functional requirements. IotReq also provides preliminary indications for specifying the technological nonfunctional requirements. A case study, the specification of the requirements for a system to support the Genoa\u2019s Science Festival is presented too

A Method for Developing Model to Text Transformations

In the field of business process development, model transformations play a key role, for example for moving from business process models to either code or inputs for simulation systems, as well as to convert models expressed with notation A into equivalent models expressed with notation B. In the literature, many cases of useful transformations of business process models can be found. However, in general each transformation has been developed in an ad-hoc fashion, at a quite low-level, and its quality is often neglected. To ensure the quality of the transformations is important to apply to them all the well-known software engineering principles and practices, from the requirements definition to the testing activities. For this reason, we propose a method, MeDMoT, for developing non-trivial Model to Text Transformations, which prescribes how to: (1) capture and specify the transformation requirements; (2) design the transformation, (3) implement the transformation and (4) test the transformation. The method has been applied in several case studies, including a transformation of UML business processes into inputs for an agent-based simulator

Maturity of Software Modelling and Model Driven Engineering: a Survey in the Italian Industry

Background: The main claimed advantage of Model-driven engineering is improvement in productivity. However, few information is available about its actual adoption during software development and maintenance in the industry. Objective: The main aim of this work is investigating the level of maturity in the adoption of software models and of Model-driven engineering in the Italian industry. The perspective is that of software engineering researchers. Method: First, we conducted an exploratory personal opinion survey with 155 Italian software professionals. The data were collected with the help of a web-based on-line questionnaire. Then, we conducted focused interviews with three software professionals to interpret doubtful results. Results: Software modelling is a very relevant phenomenon in the Italian industry. Model-Driven techniques are used in the industry, even if (i) only for a limited extent, (ii) despite a quite generalized dissatisfaction about available tools and (iii) despite a generally low experience of the IT personnel in such techniques. Limitations: Generalization of results is limited due to the sample size. Moreover, possible self-exclusion from participants not interested in modelling could have biased the results. Conclusion: Results reinforce existing evidence regarding the usage of software modelling and (partially of) Model-driven engineering in the industry but highlight several aspects of immaturity of the Italian industry

Relevance, benefits, and problems of software modelling and model driven techniques—A survey in the Italian industry

Context Claimed benefits of software modelling and model driven techniques are improvements in productivity, portability, maintainability and interoperability. However, little effort has been devoted at collecting evidence to evaluate their actual relevance, benefits and usage complications. Goal The main goals of this paper are: (1) assess the diffusion and relevance of software modelling and MD techniques in the Italian industry, (2) understand the expected and achieved benefits, and (3) identify which problems limit/prevent their diffusion. Method We conducted an exploratory personal opinion survey with a sample of 155 Italian software professionals by means of a Web-based questionnaire on-line from February to April 2011. Results Software modelling and MD techniques are very relevant in the Italian industry. The adoption of simple modelling brings common benefits (better design support, documentation improvement, better maintenance, and higher software quality), while MD techniques make it easier to achieve: improved standardization, higher productivity, and platform independence. We identified problems, some hindering adoption (too much effort required and limited usefulness) others preventing it (lack of competencies and supporting tools). Conclusions The relevance represents an important objective motivation for researchers in this area. The relationship between techniques and attainable benefits represents an instrument for practitioners planning the adoption of such techniques. In addition the findings may provide hints for companies and universitie

An Empirical Investigation to Understand the Difficulties and Challenges of Software Modellers When Using Modelling Tools

Software modelling is a challenging and error-prone task. Existing Model-Driven Engineering (MDE) tools provide modellers with little aid, partly because tool providers have not investigated users' difficulties through empirical investigations such as field studies. This paper presents the results of a two-phase user study to identify the most prominent difficulties that users might face when developing UML Class and State-Machine diagrams using UML modelling tools. In the first phase, we identified the preliminary modelling challenges by analysing 30 Class and State-Machine models that were previously developed by students as a course assignment. The result of the first phase helped us design the second phase of our user study where we empirically investigated different aspects of using modelling tools: the tools' effectiveness, users' efficiency, users' satisfaction, the gap between users' expectation and experience, and users' cognitive difficulties. Our results suggest that users' greatest difficulties are in (1) remembering contextual information and (2) identifying and fixing errors and inconsistencies.NSERC CREATE, 465463-2015 || NSERC Discovery Grant, 155243-1

Entities: An Institution For Dynamic Systems

this paper we introduce the entity framework (entity algebras and entity specifications) and show, also with the help of several examples, how they can be used for formally modelling and specifying dynamic systems

Abstract A UML-Based Approach for Problem Frame Oriented Software Development

We propose a software development approach that combines the use of the structuring concepts provided by problem frames, the use of the UML notation, together with our methodological approach for well-founded methods. Problem frames are used to provide a first idea of the main elements of the problem under study. Then we provide ad hoc UML based development methods for some of the most relevant problem frames together with precise guidelines for the users. The general idea of our method is that, for each frame, several artifacts have to be produced, each one corresponding to a part of the frame. The description level may range from informal and sketchy, to formal and precise, while this approach is drawn from experience in formal specifications. Thus we show how problem frames may be used upstream of a development method to yield an improved and more efficient method equipped with the problem frames structuring concepts

Entities for CFI: CFI Language Design Study Notes

implementation. Sy4) Abstract program A definition of an "executable" formal structure. Possible meanings for "executable formal structure" are: -- is computable, -- can be interpreted (all parts of the formal structure may be executed), -- can be prototyped/animated (some parts of the formal structure may be executed), -- can be compiled into some "programming language". Other suggestions for the name: Abstract implementation. Sy5) Program It is intended as a program in some programming language. Here "programming language" should be intended "truly commonly used/commercially available programming language"; thus a programming language equipped with static, dynamic semantics, a "professional" environment (checker of the static correctness, interpreter and/or compiler), non-academic applications, tested/ used along a consistent time. It may be that the programming language is not based on the same features on which are based the formal structures and the related specifications (e.g...

A Method to Capture Formal Requirements: the INVOICE Case Study

this paper we present only the part of our method concerning requirement specifications of simple (non-structured) systems using a basic specification formalism, because that is what we need for INVOICE; see [9] for a complete presentation. Furthermore in our approach formal specifications have an associated informal presentation, which is not considered here. In Sect. 1 we briefly present the formalism used in our approach; initially the reader can also skip it and came back if she/he needs that when reading Sect. 2 and 3, where we present the two specifications and the followed guidelines. Finally in Sect. 4 we try to evaluate our specifications by showing theirs characteristics. 1 Formal Basi

A formally grounded software specification method

One of the goals of software engineering is to provide what is necessary to write relevant, legible, useful descriptions of the systems to be developed, which will be the basis of successful developments. This goal was addressed both from informal approaches (providing in particular visual notations) and formal ones (providing a formal sound semantic basis). Informal approaches are often driven by a software development method, and, while formal approaches sometimes provide a user method, it is usually aimed at helping to use the proposed formalism when writing a specification. Our goal here is to provide a companion method that helps the user to understand the system to be developed, and to write the corresponding formal specifications. We also aim at supporting visual presentations of formal specifications, so as to “make the best of both formal and informal worlds”. We developed this method for the (logical-algebraic) specification languages Casl (Common Algebraic Specification Language, developed within the joint initiative CoFI) and for an extension for dynamic systems Casl-Ltl, and we believe it is general enough to be adapted to other paradigms. Another challenge is that a method that is too general does not encompass the different kinds of systems to be studied, while too many different specialized methods result in partial views that may be difficult to integrate in a single global one. We deal with this issue by providing a limited number of instances of our method, fitted for three different kinds of software items, while keeping a common “meta”structure and way of thinking. More precisely, we consider here that a software item may be a simple dynamic system, a structured dynamic system, or a data structure, and we show here how to support property-oriented (axiomatic) specifications. We are thus providing support for the “building-bricks ” tasks of specifying software artifacts that in our experience are needed for the development process. Our approach is illustrated with a lift case study