Keywords

1 Introduction

Requirements engineering is the process of eliciting, analyzing, specifying, validating, and managing software requirements [1]. It is not an isolated front-end activity to a software lifecycle process; rather, it is an integral part of the larger process connected to other parts through continuous feedback loops [2]. The scenario-based approach to expressing requirements is the approach most used by developers [3, 4]. After eliciting requirements, they are structured in the form of user stories, use cases, sequence diagram, etc. Those forms are not automatically mapped to the object model [5]. object-oriented analysis and design approach for the requirements engineering (OOADARE) approach, which is part of the design approach trend aimed at automating the generation of analysis diagrams [6,7,8], fits to overcome these limits, so it took user stories and constraint story cards (CSC) to automatically generate the objects, their actions, and the rest of the software artifacts (MVC, DAO, Test…) [9].

The purpose of this study is to follow the same approach to ensure its completeness and therefore determine the remaining gaps, which should be filled in order to advance the current research concretely.

2 OOADARE Approach

2.1 Presentation

A sequence of transformations is performed to build a software system, starting from requirements and ending with implementation. However, requirements are mostly in the form of an unstructured text, but not a model that can be easily understood by computers [10]. OOADARE is an approach based on the OOAD approach evolved by Booch [11], which requires, among its constraints, the use of a semi-structured text to extract structured models [12]. OOADARE contributes to the automatic transformation of requirements into a class diagram and offers technical concepts and practices that facilitate the development flow and improve the quality of the software product [5, 9]. It introduced a template that is based on the well-known user story template for solving the disorganization issue [9].

2.2 Overview of the “User Story” Template

After retrieving the requirements, the OOADARE approach requires preparing them in user stories to move on to identifying objects and methods [5].

User stories are a popular method for representing requirements using a simple template [13]. Their adoption is growing [14] and is massive especially in the context of agile software development [15].

The OOADARE approach takes “user stories” as an entry point to automate the identification of objects and actions of the object model, which implies respecting a very precise syntax [9]:

$$ As\,a\,<\,role\,>\,I\,can\,<\,\user2{action}\,>\,<\,\user2{object}\,>\,so\,that\,<\,business\,value\,> $$

 

The diagram thus generated specifies the classes of objects and the methods (Fig. 1).

Fig. 1
figure 1

Using “user stories” to generate an “object model” [9]

Full size image

The “user stories” only allow to generate the classes, and the methods of a class diagram, the “constraint story card” (CSC), are then used to manage the associations.

2.3 Using CSC to Generate Associations

Constraint story card (CSC) is a story card in which we can write the requirement’s constraints in a human-like object constraint language (OCL) [16], that represents a precise text language that provides constraint and object query expressions on any meta-object facility model or meta model with a formal specification language [17].

The OOADARE approach suggests four templates to report the different associations within the UML class diagram.

The four templates use a generic formula as shown below [18]:

$$ \begin{aligned} & \left[ {Role} \right]\, < \,\user2{Source}\,\user2{Object}\, > \, < \,\user2{Association}\,\user2{expression}\,\user2{type}\, > \,\left[ {\user2{Cardinality}} \right]\,\left[ {Role} \right] \\ & < \,\user2{Target}\,\user2{Object}\, > \\ \end{aligned} $$

 

The “Association expression type” argument corresponds to four different values depending on the type of the association [18]:

  • [Has or a verb]: in this case, it is a simple association

  • [Is a] is the proposed model for inheritance

  • [Contains]: to illustrate aggregation between classes

  • [Is composed of]: for the composition model.

The “Cardinality” can be expressed in letters (from zero to ten in English), numbers or by the word “many”. When the minimum and the maximum are not the same, the two sides are separated by the word “or” (Fig. 2) [18].

Fig. 2
figure 2

Class diagram generated from user stories and CSC using the OOADARE approach. Other artifacts (DAO, Controller …) generated were omitted for a clarity purpose. [18]

Full size image

Nevertheless, the mapping model proposed by OOADARE, in compliance with the constraints and templates, remains incomplete since it does not take into consideration all the elements that can be found in specifications and which are essential for software development.

3 Filling the Gap in the OOADARE Approach

As mentioned above, important elements are missing in the class diagram generated using OOADARE, which take their place in the center of the requirements and without which we cannot speak of a complete class diagram. It lacks, first, attributes that represent the variables storing state information characterizing the object. Secondly, we notice the absence of association classes in which “attributes” are directly dependent on two other classes and could not be placed in either one or the other. We propose in the following part solutions to fill this gap and ensure the completeness of the method with indispensable features.

3.1 Generating Attributes in a Class Diagram

In domain modeling class diagrams, an attribute represents a data definition for an instance of a classifier. An attribute describes a range of values for that data definition. A classifier can have any number of attributes or none at all. Attributes describe the structure and value of an instance of a class [19].

As a part of CSC, and taking into account textual expressions often used to present the different properties related to an object, we consider the following model to extract the different attributes of a class:

[Each] < Object > has| is identified by| is represented with| is described by < Attribute 1 > , < Attribute 2 > , …and < Attribute n > 

where

  • Object represents the entity for which the properties are identified

  • Attribute n: the nth single, named fragment of the persistent state.

3.2 Consider Association Classes in Class Diagram Generation

In UML diagrams, an association class is a class that is part of an association relationship between two other classes. It is identical to other classes and can contain operations, attributes, as well as other associations [20]. We can attach an association class to an association relationship to provide additional information about the relationship [17].

This case occurs in a “many to many” association, so we must take into account this type of association before looking for the association attribute(s) through the template that we propose as CSC (Table 1):

Table 1 Formula parts description
Full size table

[Each] < Source Object > has| have < Attribute > (for| in) each < Target Object > 

3.3 Example of Application to a Case Study

Consider the following set of requirements for a university information system that is used to keep track of student’s transcripts: “…Each department is described by a name, a code, an office number, an office phone and a college. Each course has a course name, description, course number, credit hours, level, and offering department. Each student is identified by a number, a name, a birthdate, a gender, a social security number, current address and phone number. To ensure that the system generates a transcript for students, each student must have a grade for each course.…”.

To perform the extraction task of UML class diagram concepts, each sentence in the input text will be matched against the different lists of patterns that have been defined by the above models.

If we analyze the sentence “Each department is described by a name, a code, an office number, an office phone and a college.’, we notice that it matches very well with the attributes pattern (Fig. 3); it begins with a “number of characters” that mentions the concerned “object,” followed by the key words “is identified by,” then followed by “a number of characters” that list the specified attributes, which gives us the resulting class “Department” with its correspondent attributes.

Fig. 3
figure 3

Diagram class illustrating an entity with attributes as mapped from a CSC template

Full size image

Then, considering the case of the last sentence presented by the example: ‘To ensure that the system generates a transcript for students, each student must have a grade for each course.’, we note its correspondence to the second pattern proposed for the generation of association classes (Fig. 4).

Fig. 4
figure 4

Class association extraction pattern example

Full size image

It should be noted that in this case, the association between the two classes (student and course) has on both sides a maximum multiplicity equal to “many” represented by the symbol “*”, which means that a “student” studies one or more “courses” and that a “course” is taught for one or more “students”.

4 Conclusion

More efficient and more flexible technologies are accelerating the growth of fully automated production facilities. This is the context of our study which aims to improve the OOADARE, an approach targeting the automatic generation of class diagrams from requirements presented as semi-structured text templates.

In this paper, we started by presenting the general context of the study, then explaining the approach used by OOADARE which offers an intermediate representation of the requirements in the form of user stories and CSC, thus allowing an automatic generation of class diagrams. Although we discussed the failures of the approach to finally propose solutions that follow the same rules and constraints.

With the aim of eliminating ambiguity and redundancy, the templates proposed by OOADARE in addition to the models proposed in this document are relatively simple to build and to deduce from the requirements expressed either in textual or oral form.