Wiktor Nowakowski

Complementary use case scenario representations based on domain vocabularies

Use cases are commonly used as notation for capturing functional requirements through scenarios. The problem is that there is no universal notation for use case contents which is capable of accommodating all the needs of software project participants. Business analysts and stakeholders need understandability and informality, while for architects and designers, precision and unambiguity are the most crucial features. In this paper we propose a metamodel and concrete syntax for three complementary representations of use case scenarios. These representations present the same information, but put emphasis on different aspects of it thus accommodating for different readers. This metamodel utilises the idea of separation of requirements as such from their representations as well as the idea of clear distinction between description of the systems behaviour and of the problem domain.

Case-based Reuse with Partial Requirements Specifications

A case-based approach allows reuse without the usual and significant effort for making software explicitly reusable. We even support such reuse for only partially developed requirements, since it allows reuse already without the need to develop a “complete” specification first. The solution information (models and code) of (one of) the most similar problems can then be taken for reuse and adapted to the newly specified requirements. And even the specification of these new requirements can be facilitated, since the retrieved software case contains related requirements, which may be reused as well.

Translation of use case scenarios to Java code

Use cases are usually treated as second class citizens in the software development chain based on models. Their textual descriptions (scenarios) are treated as informal input to more formal design models that can then be (semi- )automatically transformed down to code. In this paper we will show that use case scenarios can gain precise metamodel-based notation and semantics enabling automatic processing. What is more, we will show transformation algorithms that can transform use case scenarios directly to dynamic code in Java. The presented transformation can generate the full structure of the system following the MVP architectural pattern, including complete method contents for the application logic (Presenter) and presentation (View) layers. It also provides a code skeleton for the domain logic (Model) layer. The use case notation and the transformation were implemented within a sophisticated tool suite. Based on this, the paper discusses the evaluation efforts based on a case study.

From use cases and their relationships to code

Use cases are used in many methodologies to drive the software engineering process. Though, their transition to code was usually a mostly manual process. In the context of MDD, use cases gain attention as first-class artifacts with representation notations allowing for automatic transformations to analysis and design models. The paper concentrates on an important problem of constructing transformations that cater for use case relationships. It presents a notation that unifies the ambiguous “include” and “extend”, and allows for representing them within textual use case scenarios. This notation, equipped with runtime semantics, is used to construct a direct transformation into working code. The code is placed within method bodies of the Controller/Presenter and View layers within the MVC/MVP framework. Based on this transformation, an agile use-case-driven development process is possible.

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.

Runtime semantics of use case stories

Direct end-user participation in software system construction necessitates bringing general-purpose programming activities to the level understandable by “laymen”. This paper introduces a new software development approach where stories written in commonly understood structured natural language gain runtime semantics. Stories are precisely linked to domain concepts and actions, thus forming the application logic of the system. These constructs are written at a high level of abstraction, very close to detailed software requirements specifications. In fact, they are structured into familiar use case models that include special “invocation” relationships between use cases. At the same time, the paper proposes precise translational semantics for such defined stories. For each story element, equivalent Java code is derived. This semantics has been implemented within a tool containing a story editor and a code generator producing fully dynamic application logic code with Swing-based user interface. Ease of use of the new story language and usefulness of the generated Java code has been evaluated through student assignment projects.

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

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.

RECOVERY AND MIGRATION OF APPLICATION LOGIC FROM LEGACY SYSTEMS

Future Internet technologies necessitate dramatic changes in system design, delivery and usage patterns. For many legacy applications it means that their further development and transition to the Internet becomes problematic or even impossible due to the obsolescence of technologies they use. Replacement of the old system with the new one, built from scratch, is usually economically unacceptable. Therefore, there is a call for methods and tools supporting the automated migration of legacy systems into a new paradigm. This paper proposes a tool supported method for recovery and migration of application logic information from legacy systems. The information extracted from a legacy application is stored in the form of precise requirement-level models enabling automated transformation into a new system structure in a model-driven way. Evaluation of the approach is based on a case study legacy system.

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.