No abstract

In this paper, we discuss the results of our survey among 84 practitioners in order to understand practitioners’ perspectives towards requirements engineering. We asked 28 questions to learn the practitioners’ motivations, the techniques and technologies used for different activities, practitioners’ experiences with customer involvement, and any challenges encountered. Some important results are as follows: the practitioners’ top motivations are the precise communication of requirements and analyzing the requirements to detect issues. Most practitioners (i) insist on using natural languages, (ii) specify requirements as the use case and scenario descriptions, (iii) neglect using/transforming requirements for making high-level decisions and reasoning about requirements, (iv) neglect the specifications of quality requirements and their reasoning while considering quality requirements important, and (v) neglect any technologies for facilitating requirements engineering (e.g., meta-modeling technologies, formal verification tools, and advanced tools). Practitioners are challenged by the cost and effort spent in specifying requirements, the omissions of errors, misinterpretations of requirements and their incorrect (manual) transformations, and customers’ lack of technical knowledge. With the survey results, practitioners can gain an awareness on the general perspectives, academics can trigger new research addressing the observed issues, and tool vendors can improve their tools with regard to the weaknesses determined.

Modeling languages have gained ever-increasing importance for the Internet of Things (IoT) domain for improving the productivity and quality of IoT developments. In this study, we analyzed 32 different modeling languages that have been designed for IoT software development in terms of a set of requirements that were categorized into three groups: language definition, language features, and tool support. Some key findings are as follows: (1) performance is the most supported quality property (28%); (2) most languages offer a visual notation set only, while 6% provide both textual and visual notation sets; (3) most languages (88%) lack formally precise semantic definitions; (4) most languages (94%) support the physical, deployment, and logical modeling viewpoints, while the behavior, logical, and information viewpoints are rarely supported; (5) almost none of the languages enable extensibility; (6) Java (34%) and C (21%) are the most preferred programming languages for model transformation; (7) consistency (77%) and completeness (64%) are the most supported properties for the automated checking of models; and (8) most languages (81%) are not supported with any websites for sharing case studies, source code, tools, tutorials, etc. The analysis results can be useful for language engineers, practitioners, and tool vendors for better understanding the existing languages for IoT, their weak and strong points, and IoT industries’ needs in future language and modeling toolset developments.

No abstract

SAWUML is a general-purpose software modeling language that extends UML by unifying component and sequence diagrams for the specifications of software architectures. While component diagram is used for modeling the system structures, sequence diagram is extended with the Design-by-Contract approach for the modeling of system behaviors. In this paper, we aim at enhancing the language usability by providing alternative modeling choices for practitioners. To this end, we extended SAWUML's notation set with UML's activity diagram for the behavior modeling. So, practitioners may now use either sequence or activity diagrams, while the system structures are still modeled with component diagrams. We also extended SAWUML's modeling editor for creating software architecture models together with component and activity diagrams and the code generators for automatically obtaining (i) formal models in SPIN's ProMeLa for formal verification and (ii) Java-based implementation. We illustrate our language extension with the gas station case-study. I.INTRODUCTIONOFTWARE architecture is the structure of a system that comprises components, their behavioral specifications, and interactions with each other [1]-[3]. The software architecture is concerned with which components a system consists of and whether these components are integrated and working together, as well as what kind of interfaces the components will have, what will be the inter-component communication and dependencies. For modelling software architectures an Architecture Description Language (ADL) plays an important role [4]-[6].An ADL is a formal specification language for describing the structures and behaviors of components and connectors at an abstraction level for the software architecture of a system. ADLs are designed for different domains (e.g., embedded, automotive, multi-agent, and distributed) and purposes such as modeling software structures, modeling software architectures from different viewpoints (e.g., structure, behavior, concurrency), non-functional property