Metamodel-based model conformance and multiview consistency checking

Model-driven development, using languages such as UML and BON, often makes use of multiple diagrams (e.g., class and sequence diagrams) when modeling systems. These diagrams, presenting different views of a system of interest, may be inconsistent. A metamodel provides a unifying framework in which to ensure and check consistency, while at the same time providing the means to distinguish between valid and invalid models, that is, conformance. Two formal specifications of the metamodel for an object-oriented modeling language are presented, and it is shown how to use these specifications for model conformance and multiview consistency checking. Comparisons are made in terms of completeness and the level of automation each provide for checking multiview consistency and model conformance. The lessons learned from applying formal techniques to the problems of metamodeling, model conformance, and multiview consistency checking are summarized

A practical approach to goal modelling for time-constrained projects

Goal modelling is a well known rigorous method for analysing problem rationale and developing requirements. Under the pressures typical of time-constrained projects its benefits are not accessible. This is because of the effort and time needed to create the graph and because reading the results can be difficult owing to the effects of crosscutting concerns. Here we introduce an adaptation of KAOS to meet the needs of rapid turn around and clarity. The main aim is to help the stakeholders gain an insight into the larger issues that might be overlooked if they make a premature start into implementation. The method emphasises the use of obstacles, accepts under-refined goals and has new methods for managing crosscutting concerns and strategic decision making. It is expected to be of value to agile as well as traditional processes

Living Boundary Objects to Support Agile Inter-Team Coordination at Scale

Context: In the last decades, large-scale agile development has received increasing attention, as also organizations with many stakeholders and large systems aim for higher development speed and focus on customer value. A recognized research challenge in large-scale agile development relates to inter-team coordination. To coordinate effectively, organizations need to identify what knowledge is required across team borders and how it can be managed over time. Knowledge is potentially manifested in boundary objects – artifacts that create a shared understanding between teams (e.g., requirements or architecture descriptions). Traceability between artifacts is a key necessity to manage change in agile contexts. Moreover, agile practitioners aim to reduce the documentation effort to absolutely crucial artifacts and trace links.Objective: This thesis aims to improve how practitioners can manage knowledge for inter-team coordination in large-scale agile development. We focus especially on how knowledge can be made explicit in artifacts and trace links that are evolved over time. Method: We empirically investigated problems and developed solutions using a research approach that was inspired by design science. Case studies, an in-depth design science study, a mixed methods study, and surveys were performed. Using this mix of research methods, we leveraged both qualitative and quantitative data. Results: We coined the concept of living boundary objects to manage knowledge for inter-team coordination. Living boundary objects are boundary objects that are traced to other artifacts, kept up to date, and serve for inter-team coordination. They should be established early in the lifecycle to create a common understanding of the product to be developed. We scrutinized architecture descriptions, interfaces, and requirements and traceability information models as examples of concrete boundary objects. We recommend establishing alignment using a common high-level structure, but also supporting diverse knowledge management practices to fulfill the individual needs of agile teams. Conclusions: Our contributions help to establish knowledge management practices that are considered beneficial by practitioners and focus on the crucial aspects to align agile teams on. We suggest concepts and requirements for knowledge management tools that take the distinct role of living boundary objects into consideration and can be adjusted as organizations\u27 needs evolve

Recovering Grammar Relationships for the Java Language Specification

Grammar convergence is a method that helps discovering relationships between different grammars of the same language or different language versions. The key element of the method is the operational, transformation-based representation of those relationships. Given input grammars for convergence, they are transformed until they are structurally equal. The transformations are composed from primitive operators; properties of these operators and the composed chains provide quantitative and qualitative insight into the relationships between the grammars at hand. We describe a refined method for grammar convergence, and we use it in a major study, where we recover the relationships between all the grammars that occur in the different versions of the Java Language Specification (JLS). The relationships are represented as grammar transformation chains that capture all accidental or intended differences between the JLS grammars. This method is mechanized and driven by nominal and structural differences between pairs of grammars that are subject to asymmetric, binary convergence steps. We present the underlying operator suite for grammar transformation in detail, and we illustrate the suite with many examples of transformations on the JLS grammars. We also describe the extraction effort, which was needed to make the JLS grammars amenable to automated processing. We include substantial metadata about the convergence process for the JLS so that the effort becomes reproducible and transparent

The Impact of Requirements on Systems Development Speed: A Multiple-Case Study in Automotive

Automotive\ua0manufacturers have historically adopted rigid\ua0requirements\ua0engineering processes. This allowed them to meet safety-critical\ua0requirements\ua0when producing\ua0a\ua0highly complex and differentiated product out of the integration of thousands of physical and software components. Nowadays, few software-related domains are as rapidly changing as the\ua0automotive\ua0industry.\ua0In\ua0particular, the needs of improving\ua0development\ua0speed\ua0are increasingly pushing companies\ua0in\ua0this domain toward new ways of developing software.\ua0In\ua0this paper, we investigate how the goal to increase\ua0development\ua0speed\ua0impacts how\ua0requirements\ua0are managed\ua0in\ua0the\ua0automotive\ua0domain. We start from\ua0a\ua0manager perspective, which we then complement with\ua0a\ua0more general perspective. We used\ua0a\ua0qualitative\ua0multiple-case\ua0study, organized\ua0in\ua0two steps.\ua0In\ua0the first step, we had 20 semi-structured interviews, at two\ua0automotive\ua0manufacturers. Our sampling strategy focuses on manager roles, complemented with technical specialists.\ua0In\ua0the second step, we validated our results with 12 more interviews, covering nine additional respondents and three recurring from the first step.\ua0In\ua0addition to validating our qualitative model, the second step of interviews broadens our perspective with technical experts and change managers. Our respondents indicate and rank six aspects of the current\ua0requirements\ua0engineering approach that\ua0impact\ua0development\ua0speed. These aspects include the negative\ua0impact\ua0of\ua0a\ua0requirements\ua0style dominated by safety concerns as well as decomposition of\ua0requirements\ua0over many levels of abstraction. Furthermore, the use of\ua0requirements\ua0as part of legal contracts with suppliers is seen as hindering fast collaboration. Six additional suggestions for potential improvements include domain-specific tooling, model-based\ua0requirements, test automation, and\ua0a\ua0combination of lightweight upfront\ua0requirements\ua0engineering preceding\ua0development\ua0with precise specifications post-development. Out of these 12 aspects, seven can likely be addressed as part of an ongoing agile transformation. We offer an empirical account of expectations and needs for new\ua0requirements\ua0engineering approaches\ua0in\ua0the\ua0automotive\ua0domain, necessary to coordinate hundreds of collaborating organizations developing software-intensive and potentially safety-critical\ua0systems

Ontology in software engineering

© 2018 authors. During the past years, ontological thinking and design have become more and more popular in the field of Artificial Intelligence (AI). More recently, Software Engineering (SE) has evolved towards more conceptual approaches based on the extensive adoption of models and meta-models. This paper briefly discusses the role of ontologies in SE according to a perspective that closely matches the theoretical life-cycle. These roles vary considerably across the development lifecycle. The use of ontologies to improve SE development activities is still relatively new (2000 onward), but it is definitely no more a novelty. Indeed, the role of such structures is well consolidated in certain SE aspects, such as requirement engineering. On the other hand, despite their well-known potential as knowledge representation mechanisms, ontologies are not completely exploited in the area of SE. We first (i) proposes a brief overview of ontologies and their current understanding within the Semantic Web with a focus on the benefits provided; then, the role that ontologies play in the more specific context of SE is addressed (ii); finally, we deal with (iii) some brief considerations looking at specific types of software architecture, such as Multi-Agent Systems (MAS) and Service-Oriented Architecture (SOA). The main limitation of our research is that we are focusing on traditional developments, where phases occur mostly sequentially. However, industry has fully embraced agile developments. It is unclear that agile practitioners are willing to adopt ontologies as a tool, unless we ensure that they can provide a clear benefit and they be used in a lean way, without introducing significant overhead to the agile development process