Michał Śmiałek

Comprehensive System for Systematic Case-Driven Software Reuse

Reuse of software artifacts (blueprints and code) is normally associated with organising a systematic reuse framework most often constructed for a specific problem domain. In this paper we present a system (language, tool, reuse process) where software reuse is based on building and retrieving of so-called software cases (large compound artifacts) that can be reused between domains. The system is opportunistic in that software cases result from usual (non-reuse oriented) activities where also semantic information is added. This information is used to support regular development but may serve later to retrieve software cases. Having this common semantic basis, we can organise a systematic cross-domain reuse process where application logic of one system can be reused for systems within different domains.

Application logic patterns reusable elements of user-system interaction

Patterns of various kind are commonly used to reduce costs and improve quality in software development. This paper introduces the concept of patterns at the level of detailed descriptions of the user-system dialogue. Application Logic Patterns define generalised sequences of interactions performed by the system and its users in the context of an abstract problem domain. The patterns are organised into a library. They are precisely described by a language which is defined through a strict meta-model. It extends the notation and semantics of the UML activities and use cases. Each of the patterns describing the visible system dynamics is linked to an abstract domain model central to all the patterns. The patterns can be easily instantiated by substituting abstract domain notions with the notions specific to a given domain. This ease of use and reduction in effort is validated in a controlled experiment using an open-source tool.

Scenario construction tool based on extended UML metamodel

Scenario based notations are becoming more and more popular as means for user requirements elicitation. They can be used in more formal specifications as part of detailed use case templates or in agile processes to capture informal user stories. Despite their significance in software engineering, scenarios seem not to be properly supported by appropriate tools. This paper describes a scenario construction tool that offers clear separation of the actual story from notions used therein. The tool is constructed as an extension to visual notation of UMLs use cases. It is based on an extended UML metamodel in the area of activities and classifiers. This formal basis makes the tool capable of supplying the existing UML tools with an additional layer of requirements models based on scenarios and notions. This layer makes it possible to transform requirements directly into design-level models. The tool offers such transformation capabilities based on a simple model mapping. This transformation supports human efforts to keep the systems design consistent with the users needs expressed through scenarios.

From Requirements to Java in a Snap

domain with references to a specific one. This definition contains an important characteristic of SBPs.We prefer them to be associated with an abstract problem domain, easily substitutable by a concrete one. This can be implemented within the ReDSeeDS tool wherein the developers are able to quickly change the names in the domainmodel, and thus instantly “switching” from one domain to another. In this way, patterns can be quickly created or instantiated. Creation of a pattern consists in changing a concrete domain into an abstract one (e.g. “Add book” –> “Add whatever”), where instantiation is changing in the opposite direction (e.g. “Add whatever” –> “Add sales item”). Based on this mechanism we can create a library of patterns, reusable in many contexts.14 Here we present one example pattern which can serve as a starting point. This is a classical pattern that uses the well-known CRUD (Create, Read, Update, Delete) approach, presented also in the pattern book by Overgaard and Palmquist. Fig. 7.27 Structure of Software Behaviour Patterns 14 Similarly, a library of anti-patterns can be built [43] and used as guidance to avoid certain commonly made mistakes in use case modelling. 252 7 Applying MDRE in Practice Fig. 7.28 “Manage resources” pattern: use case model We call our version of the pattern “Manage resources”. After Cockburn we could also call it “Manage whatever” but we prefer the more formal name. The pattern is based on the use case model presented in Fig. 7.28. It involves an abstract “(user)” and five abstract use cases with “(resource)” being the recurring parameter in each of them. The central use case is “Show (resource) list”, which invokes the four other use cases which provide the actual CRUD functionality. Note that the “Create” use case is also accessible directly, and not only through an invocation. This is due to creating a “(resource)” that does not necessitate the context needed by the other three invoked use cases. To read, update or delete a “(resource)” we first need to select that resource which is provided by the central use case. The five use cases are further detailed with appropriate scenarios. Some of them are illustrated in Fig. 7.29. These scenarios are similar to the scenarios found in the examples in the previous chapters, and especially in Sect. 4.5. In fact, we can treat the current “Manage resource” pattern as a generalisation and extension of the presented use case models of the library domain (see e.g. Fig. 4.44). In Fig. 7.29, the functionality is quite basic.We can think ofmore complex scenarios with, e.g. the resource list being filtered or sorted. This can be subject to creating more elaborated patterns and later selecting the ones that are most suitable for the current problem at hand. Nevertheless, the scenarios are complete and coherent, with the necessary four invocation sentences in “Show (resource) list” consistent with the four invocation relationships. The scenarios are attached to the abstract domain model presented in fragment in Fig. 7.30. This is an important part of the overall pattern and defines all the abstract Screens, Triggers and Data Views that need to be involved. It contains all the relationships that determine the semantics of the individual domain elements within the whole model. For instance, note that “update (resource) button” is related with the “(resource) list” while “create (resource) button” is not. This is because the event associated with the first Trigger does not need any context (a resource selected from the list), while the second one does. The model also 7.3 Reuse Approaches with Requirements Models 253 Fig. 7.29 “Manage resources” pattern: selected scenarios Fig. 7.30 “Manage resources” pattern: domain model fragment contains all the verb phrases (“validate (resource)” etc.) that provide placeholders for the domain logic to be defined after instantiation. Note that the abstract domain model does not contain any Attributes because they can be determined only for a concrete domain. 254 7 Applying MDRE in Practice 7.4 Summary: Is MDRE for Me? In order to answer the title question, we should go back to the introduction and Sect. 1.1 which present the ideal dream of a software project manager. To judge if it is worthwhile to apply MDRE in our projects, we need to assess how close it brings us to fulfilling this dream. In making this judgment we should consider two major factors: quality of the resulting software and productivity in delivering software to the clients. In practice, this means answering the following two questions: (1) “How close is my working code to the real user needs?”, and “How much more productive are the development teams?” To answer these questions we can consider the current state of practice. The recent comprehensive market survey RE-Kompass [1] shows that 58% of companies were able to improve the quality of their software products by approaching more systematically to requirements. Thus, advancement in Requirements Engineering practices alone, leads to advancement in the quality of working code. Here we can identify two main areas of concern: • Understanding the user’s needs and capturing them correctly in adequately precise and complete descriptions of the intended capabilities of the system; • Translating these (evolving) descriptions accurately into technical artefacts, and finally to the executable code in a way that leads to software with consistently high quality. Unfortunately as the RE-Kompass survey shows, at least 70% of companies still use ambiguous natural language requirements with little template support. At the same time, according to another survey by El Emam andGünȩs Koru [45], “toomany requirements and scope changes” is seen as one of the two main causes (at 33%) of project failures. This is especially visible in case of long-term projects, aiming at large, complex and data intensive systems. It is thus evident that the software engineering industry struggles with poor quality of requirements. Note that the current process is largely manual especially in the area of user and software requirements. RE concentrates on managing largely textual paragraphs text and linking them manually to design. This is why—as the RE-Kompass survey shows—only 35% companies have experienced productivity increase through applying systematic RE. This causes a lack of stakeholder acceptance for making requirements formally precise—it adds effort but does not result in shorter development and evolution cycles. To change this we need to turn software requirements into first-class citizens in the software lifecycle. We need to seek ways to make them formally precise (but still comprehensible to business domain experts) and to automate their conversion into working code. MDRE assists us greatly in this quest through its techniques, tools and methodology, as presented in this book. By introducing automation right at the beginning of the software development process, MDRE promises significant gains in productivity. Of course, this has its limits and MDRE cannot be seen as the universal “silver bullet” from the famous 7.4 Summary: Is MDRE for Me? 255 Fred Brook’s paper [26]. There are always cases where high levels of automation are not possible or difficult. However, a high degree of automatic requirementsto-code generation for typical business systems seems perfectly achievable in the wider practice. This includes mainly systems with intensive user-system interaction and relatively standard structures of data processing and storage. For other types of systems, certain aspects of code need to be left for semi-automatic generation and manual completion. The key to mitigating the problems of software development seems to be shifting our efforts towards the essential complexity (cf. requirements), abstracting away the “accidents”, i.e. the technological details. In MDRE, all these details are captured within transformation programs capable of generating various target technological environments (web/mobile/desktop interfaces, databasemanagement systems, architectural frameworks, etc.). With a library of such transformations at hand, the various software project stakeholders can concentrate on providing semantically precise functional requirements specifications. As a result, the level of complexity at which developers need to operate decreases dramatically. This has two very significant impacts especially for large and complex systems: • Complex problems and their solutions have to be handled only at the conceptual level (the essence). This allows for buildingmuchmore complex systems at amuch lower cost associated with their unambiguous specification and implementation. • The quality of complex systems rises significantly through applying automation in generating code of repeatable high quality, from high-level requirements models. What is important is that the amount of effort to achieve these impacts in a given organisation might not be very significant. This mostly depends on the current practice in requirements specification. If the development teams have experience with writing good quality use cases and domain models, the effort would mainly consist in shifting to more semantically precise notations of RSL. In other cases, the effort would be obviously higher because it would involve acquiring knowledge on the fundamentals of use case and domain modelling. Of course, when implementing MDRE in our organisation, we should follow the best practices of software process improvement [125]. Generally, this should be a gradual process which improves our practices and raises maturity. This process can go through several levels. 1. Level 1. No systematic practices in requirements modelling. At this level, the organisation practices mainly textual requirements with perhaps some elements of modelling like use case diagrams and class diagrams for domain models. 2. Level 2. Practicing precise requirements models. At this level, t

Teaching software modeling in a simulated project environment

Teaching software engineering in the academia always faces the problem of inability to show problems of real life development projects. The courses seem to be unable to properly show the need of using software modeling as important means of coping with complexity and handling communication within the project. The paper presents format of a course that tries to overcome this. It focuses on application of modeling tools in a realistic software engineering environment. The objective is to teach best practices of software design and implementation with the use of UML. The students can practice design and communication techniques based around CASE tools in teams of 12 to 14 people. The paper summarizes 5 years of experience in teaching modeling with CASE tools. Authors present a concept of how to simulate the roles of architects, designers and programmers as close to reality as possible. The paper also discusses the problems of organizing laboratory work for a large group of students. Authors present the tasks and their arrangement during the course.

Use cases in model-driven software engineering

Use cases have achieved wide use as specification tools for systems observable behavior, but there still remains a large gap between specifying behavior and determining the software components to build or procure. WUsCaM 05 – “Workshop on Use Cases in Model-Driven Software Engineering” – brought together use case and MDSE experts from industry and academia to identify and characterize problem areas and promising approaches.

Writing coherent user stories with tool support

Writing good user stories for software systems seems to be a hard task. Story writers often tend to mix real stories (sequences of events) with descriptions of the domain (notion definitions). This often leads to inconsistencies and confusion in communication between the users and the developers. This paper proposes a tool that could support writing coherent user stories. The tool clearly separates the domain notion definitions from the actual stories. This leads to a consistent requirements model that is more readable by the users and also easier to implement by the developers.

Profile suite for model transformations on the computation independent level

Transformations of models on the Computation Independent level of the MDA framework seem to have little focus in the current research. This is despite their great significance for ensuring traceability of business requirements into system design and implementation. Hence, this paper proposes a suite of profiles that define appropriate models and transformations between them. There is briefly described a set of well-formedness rules for the models, and a set of mappings and rules that allow for model transformations. These mappings and rules are presented in the context of UML 2.0 Profiles.

From user stories to code in one day

User stories in software engineering serve the purpose of discovering requirements and are used as units of system development. When applying stories in a project, two elements seem to be crucial: the ability to write coherent sequences of events and the ability to transform these sequences into code quickly and resourcefully. In this paper, these qualities are reflected in a notation that can be described as “stories with notions”. This notation separates the storys sequence of events from the description of terms used in this sequence. Such a formal separation does not limit and rather enhances invention, at the same time rising the level of consistence, and facilitating translation into models of code. This translation maps domain notions into static code constructs (classes, interfaces) and also maps stories into dynamic sequences of messages. With such a mapping, programming becomes equivalent to skilled transformation of user stories, thus giving shorter development cycles.

Introducing Requirements-Driven Modelling

Requirements play a pivotal role in software development because they express the needs of the customer. A quality software system can emerge only when the real needs of the client are discovered. However, this is not enough. A typical software development project faces the problem of translating the user needs into a working system. These problems are dealt with by hundreds of books on various aspects of software design and pertaining to the plethora of software development technologies we can choose from. Related activities produce important artefacts that are treated as primary in software development: design models and code. Software design and coding directly contributes to the final system, and thus their results are treated as first-class citizens in the world of software development.