See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/320266346

A Domain-Specific Language for Automatic Generation of UML Models

Article in IET Software · October 2017

DOI: 10.1049/iet-sen.2016.0279

CITATIONS READS

7 117

3 authors:

Márcio Assis Miranda Humberto T. Marques-Neto

Instituto Federal Minas Gerais (IFMG) Pontifícia Universidade Católica de Minas Gerais
5 PUBLICATIONS 10 CITATIONS 86 PUBLICATIONS 501 CITATIONS

SEE PROFILE SEE PROFILE

Mark A. J. Song
Pontifícia Universidade Católica de Minas Gerais
70 PUBLICATIONS 179 CITATIONS

SEE PROFILE

All content following this page was uploaded by Márcio Assis Miranda on 21 October 2023.

The user has requested enhancement of the downloaded file.

 17518814, 2018, 2, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/iet-sen.2016.0279 by CAPES, Wiley Online Library on [09/11/2022]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
IET Software

Research Article

Domain-specific language for automatic ISSN 1751-8806

Received on 4th November 2016
Revised 5th September 2017
generation of UML models Accepted on 4th October 2017
E-First on 14th December 2017
doi: 10.1049/iet-sen.2016.0279
www.ietdl.org

Márcio Assis Miranda1,2 , Marcos Guilherme Ribeiro3, Humberto Torres Marques-Neto1, Mark Alan
Junho Song1
1Department of Computer Science, Pontifical Catholic University of Minas Gerais, Belo Horizonte, MG, Brazil
2Department of Computer Science, Federal Institute of Minas Gerais, Ouro Branco, MG, Brazil
3Department of Computer Engineering, Federal Center of Technological Education of Minas Gerais, Timóteo, MG, Brazil

E-mail: [email protected]

Abstract: The majority of flaws found in software originates in the system requirements specification stage. The use of domain-
specific languages has shown to be a valuable resource in this part of the process, since they help to establish communication
standards, enable automation and bring productivity and quality gains, in spite of their limited vocabulary. This study proposes
the implementation of language of use case to automate models (LUCAM), a domain-specific language that allows specification
of textual use cases and semi-automated generation of use case diagrams, class diagrams and sequence diagrams through
LUCAMTool. To verify the feasibility of the proposed solution, tests were performed in both simulated and real environments so
as to comprise a variety of scenarios observed in systems development. The approach assists in the requirement analysis and
modelling, minimising existing problems in natural language specification, such as the dependence on the knowledge of
specialists, uncertainty, ambiguity and complexity.

1 Introduction manager, a primary actor, is responsible for managing user and

accounts data. The customer, as a secondary actor, is responsible to
Constructing a high-quality software requirements specification is provide personal data to the manager. Through the LUCAM
a key to a project's success. In addition to contributing to the approach, they can be registered in the system to make, among
quality of the software artefacts generated, the software other things, financial transactions such as withdrawals and
specification facilitates effective communication between the client transfers.
and the development team. Therefore, various methods have been Our tests encompass both real and simulated environments,
developed, such as user stories, use case models, diagrams and with the former being a proof of concept trial in projects picked by
formal language. collaborating companies. Our solution has features that contribute
Most textual requirements are written in natural language to the standardisation of important stages in software development,
because it can be easily understood by both the client and the such as use case specification and modelling, bringing productivity
developers. However, redundant, ambiguous, inconsistent, or gains and generating diagrams consistent with a specification and
difficult-to-interpret specifications can compromise the mitigating problems stemming from the use of natural language.
productivity of the developers and the quality of the final product.
To minimise these problems, we need methods and tools that
increase the formality while preserving as much of the 2 Proposed solution
understandability of natural language descriptions as possible. We have proposed a DSL named language of use case to automate
According to [1], there is considerable distance between models (LUCAM), which contemplates textual use case detailing.
requirements specification and software development. Most Also, the use of the LUCAMTool enables the automatic generation
development teams still rely upon manual processes and of unified modelling language (UML) diagrams in requirement-
specialised expertise to generate a system model from the oriented software development processes.
requirements specification. From [2], requirements should be The LUCAMTool was implemented to enable users to specify
presented to project stakeholders in an understandable way, functional software requirements using our LUCAM DSL – a
offering a certain level of automation in part of the process. parser maps relevant features of the textual use cases to UML use
Some advocate domain-specific languages (DSLs) as a viable case, class and sequence diagrams. The LUCAMTool source code
solution to this problem because their use enhances productivity, as well as the language grammar and all conducted tests are
promotes communication between engineers and domain available at https://github.com/assismiranda/LUCAMTool.
specialists, and enables the removal of ambiguities and The transition from use case specifications to models begins
inconsistencies observed in the natural language texts [3]. The need with the requirement analysis and discovery. After that, use cases
for legibility, understandability, and productivity also justifies the are textually specified in the LUCAM language, each sentence is
use of DSLs to describe use cases [4, 5]. mapped by LUCAMTool's parser core and thus the elements
In this paper, we define an external DSL called language of use necessary to generate the models are identified, as demonstrated by
cases to automate models (LUCAM), which defines language the process presented in Fig. 1.
standards to specify textual use cases. We also describe an The elements that compound use case specifications in
implementation of LUCAMTool, a tool that automatically LUCAM, the standards defined for each sentence in the
generates use case diagrams, class diagrams and sequence specification, and the main stages in the mapping and artefact
diagrams from use case specifications. generation processes are presented below.
To demonstrate the LUCAM features and expressive
capabilities, we apply the LUCAM approach to a banking software
system, focusing on the ‘SB_BankAccount’ use case. The bank

IET Softw., 2018, Vol. 12 Iss. 2, pp. 129-135 129

© The Institution of Engineering and Technology 2017
 17518814, 2018, 2, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/iet-sen.2016.0279 by CAPES, Wiley Online Library on [09/11/2022]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
The control class names are identified from the use case names.
The main goal of this class is to control the sequence of the use
case behaviour. In other words, it represents the dynamics of a
functional requirement. For each flow (main and alternatives), a
control class method is generated, and for each control class
method, a sequence diagram is generated automatically. Initially,
the names of the primary actors, secondary actors and the system
are also indentified.
The most important rules of LUCAM are presented below. Note
that they have the main elements to represent the main flow of the
use case specification

• MainFlowName :: = "Main Flow: " MethodControlClassID

POINT
• MainFlowScope :: = [ActorID " starts Use Case" POINT]
MainFlow [ActorID " finishes Use Case" POINT]
• MainFlow :: = MainFlowElements {MainFlowElements}
Fig. 1 LUCAM general flow • MainFlowElements :: = MainFlowCore | FlowIf | FlowLoop |
FlowConcurrency
2.1 LUCAM specification • MainFlowCore :: = ((ActorID | SystemID)
LUCAM use case specifications have the following attributes: use (MainFlowTabTransVerb | TABINTRANSVERB) POINT) |
case name, brief use case description, system name, actors, basic ReturnMessage | InteractionUseCase POINT
and alternate flows, main scenarios, pre-conditions, post- • MainFlowTabTransVerb :: = TABTRANSVERB
conditions, special requirements and extension points. ["MethodBoundaryID"] (MainFlowAttibutes | "on"
We based the LUCAM templates on the templates in the open MainFlowBoundaryClass)
unified process (OpenUP) [6]. Since OpenUP uses free-form, • MainFlowAttibutes :: = [["the"] TABNOUN ["("
natural language specifications that lack a precise syntax or [AttributeTypeID] AttributeID {, [AttributeTypeID]
semantics, it is difficult to automate the processing of use cases. AttributeID}")"]] (("on" MainFlowBoundaryClass | ("of")
To achieve the purpose of LUCAM, we extend the OpenUP MainFlowEntityClass)) | MainFlowsActorClass)
template in various ways. For example, we make the attributes and • MainFlowBoundaryClass :: = BoundaryClassID
class methods explicit, identify the system with which the primary • MainFlowActorClass :: = ("for" | "to") ["the"] ActorID
and secondary actors interact, define explicit control flow (if, loop • MainFlowEntityClass :: = EntityClassID ["on"
and concurrency) for sequence diagrams and register the nouns and MainFlowBoundaryClass | "by" MainFlowCommunication |
verbs before their use. MainFlowsActorClass) ]
Use case details do not usually contain these elements,
• MainFlowCommunication :: = CommunicationID
therefore, language expressive capabilities are increased by adding
them, making language vocabulary richer and providing a bigger • ReturnMessage :: = (SystemID TABTRANSVERB
variety of written ways to specify the majority of scenarios present SimpleReturnMessage ("to" | "for") ["the"] ActorID | SystemID)
in software development. This formal syntax and semantics is also • FlowIf :: = "If " Condition MainFlow ["Else "
essential for the automatic generation of diagrams; it helps ensure MainFlow ]"EndIf"
consistency among the specification and generated models. • FlowLoop :: = "Loop " Condition MainFlow "EndLoop"
• FlowConcurrency :: = "StartConcurrency " MainFlow
2.2 LUCAM grammar rules "concurrent" MainFlow "EndConcurrency"
• InteractionUseCase :: = ActorID "executes" ("use" "case" |
In the first part of the grammar, we have the rules that compose the "alternate flow") "useCaseID" ("," | " and" | " or")
main structure (skeleton) of the use case detail. The DSL rules "useCaseID"
presented in this paper are in the extended Backus-Naur form
(EBNF) The part of the grammar that contemplates alternate flows is
quite simple, because its main rule (AlternateFlowCore) derives
• LUCAM :: = UseCaseHeader UseCaseFlows UseCaseFooter from the most important main flow rule (MainFlow). This means
• UseCaseHeader :: = UseCaseName UseCaseBriefDescription that the same specification pattern defined for the basic flow is also
SystemName PrimarySecondaryActors accepted for alternate flows
• UseCaseFlows :: = MainFlowName MainFlowScope
[AlternateFlows] • AlternateFlows :: = "Alternate Flows " AlternateFlowscope
• UseCaseFooter :: = Key Scenario {KeyScenario} PreConditions { AlternateFlowscope}
PosConditions SpecialRequirements ExtensionPoints • AlternateFlowscope :: = "Alternate Flow " NUM ": "
MethodControlClassID POINT AlternateFlowCore
Use case specifications in the LUCAM language have the • AlternativeFlowCore :: = MainFlow
following header elements: use case name, brief description,
system name, primary actors and secondary actors, according to In order to increase language expressiveness and fulfil
DSL rules presented below requirements such as clarity, simplicity and interactivity, we
created three tables of reference words previously recorded in the
• UseCaseName :: = "Use Case: " ControlClassID POINT LUCAMTool. The term TABTRANSVERB refers to the set of
• UseCaseBriefDescription :: = "Brief Description" [Text] transitive verbs, while TABINTRANSVERB refers to intransitive
POINT verbs. The third table is TABNOUN, which contains a set of
• SystemName :: = "System: "SystemID POINT preregistered LUCAMTool nouns that make up the vocabulary of
• PrimarySecondaryActors :: = "Primary and Secondary Actors " our proposed language.
PrimaryActorName [SecondaryActorName]
• PrimaryActorName :: = "Primary Actors: " ActorID {"," 2.3 Map operations
ActorID} POINT
The map operations module is responsible for recognising
• SecondaryActorName :: = ‘Secondary Actors: " ActorID {"," sentences in the use case specification and validating them against
ActorID} POINT defined patterns and grammar rules. The module contains the
130 IET Softw., 2018, Vol. 12 Iss. 2, pp. 129-135
© The Institution of Engineering and Technology 2017
 17518814, 2018, 2, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/iet-sen.2016.0279 by CAPES, Wiley Online Library on [09/11/2022]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
LUCAMTool parser core, implemented by a class which contains stored in a data structure and relayed to a class that generates the
two fundamental methods: identifiesSentence() and diagram.
identifiesMessage(Sentence) (see Table 1). From the mapping, the parser stores in an intermediate structure
Before describing these methods, we provide some examples of all the information necessary (actors, methods, attributes, messages
sentences written in LUCAM, which we use to demonstrate how to etc) to create the class and sequence diagrams. To generate the
map and to generate the models. Each sentence follows the patterns diagrams, based on the identified elements, the libraries ‘astah-
presented in Table 2, in the same order. pro.jar and astah-api.jar’, available in the Astah [7] tool, were
used.
1. Customer informs the attributes to the Manager. Suppose we apply the algorithm to the example use case
2. Manager selects "InsertAccount" on MainForm. ‘SB_BankAccount’, where Figs. 3 and 4 give two fragments of the
3. Manager enters attributes (ID, Name, DateBirth, ...) of specification. The first shows the main flow ‘AddAccount’. The
Customer. second shows an alternate flow specification ‘CloseAccount’.
4. System returns "Input mode screen" to Manager. Figs. 5 and 6 show the outputs.
5. System sends the notification by e-mail. Fig. 5 depicts the class diagram generated from the elements of
the textual specification. Note that the class diagram generated by
6. System searches for the Customer.
the LUCAMTool accurately represents the provided specification.
7. System returns the attributes of Customer. This is a very important feature of our proposed approach, because
8. System saves the attributes of Customer. most manually written specifications contain some disparity
9. System validates attributes of Customer. between models and textual specification, thus propagating
10. System verifies the attribute (condition) of the Customer. inconsistencies.
11. System displays the attributes of Customer on MainForm. Fig. 6 depicts the sequence diagram generated from the
12. System cancels the operation. elements of the textual specification and the class diagram. Note
that through existing elements in the sequence diagram, we can
The first method is identifiesSentence(), which analyses every clearly visualise the flow of the process described in the use case
word in the sentences of the textual specification, identifying their details, as well as identify mapped classes and methods, thus
grammatical class (subject, verb, method, noun, attribute, ensuring another level of consistency between the generated
preposition, classes and actors) and returning an object with these models. This diagram shows resources such as self calls, return
terms. Table 1 presents an example of such object for the sentences messages, validations and combined fragments.
presented above. Note that sentences are divided according to their In addition to the features previously described, sequence
terms, and object attributes are filled accordingly. After diagrams generated by the LUCAMTool permit users to validate
identifiesSentence() has mapped the words, the returned object is class diagrams because they have more details and, therefore,
sent as a parameter to the identifiesMessage(Sentence) method. precisely reflecting characteristics and elements present in textual
Based on the rules presented in Table 2, the method maps objects specifications.
in the sequence diagram and returns another object containing a
message label and origin and destination classes. 3 Results and viability study
Rules 6 and 7 are identical, therefore, we have a type of pattern
that generates two operations with two different behaviours. For Tests were conducted in two stages. The first stage was a simulated
example: when the user searches for something (verb searches), the environment, using classic scenarios (academic, banking, E-
message must be relayed from the Boundary class to the Entity Commerce and medical) and the second stage used real software
class. The same process occurs when the system retrieves the data systems in three collaborating companies, as a proof of concept.
being searched: a message is sent from the Entity class and is The files containing our tests and respective results (specifications
replicated until it gets to the Controller class. In some cases, and models) are available at https://github.com/assismiranda/
messages are originated from controller classes, which is why we LUCAMTool/.
defined the last receiver class (LRC) time – it is necessary to To conduct our proof of concept experiment, we selected three
control, during the flow, in which class a method was last invoked. software systems whose original requirements had been specified
Other class types must be identified in addition to the control in natural language and that had diagrams and source code
class. We then need to define rules based on the prepositions that manually written by specialists who have participated in the tests
precede the name of each class in the sentence. Preposition Of with LUCAM.
precedes the names of classes of type Entity, On precedes the The first software is used to manage the concrete production
Boundary class, To/For precede the names of Actors and By and delivery in a mining company. The software has 115 features,
precedes classes of type Communication, like the examples 53 of which are of the type ‘Manage Simple Entity’ (which group
provided in Table 1. subfeatures of type CRUD-Create, Read, Update and Delete
Some verbs only make sense in the context of a phrase if they actions), 25 are of the type ‘Manage Composite Entity’ (each of
are related to the system. Verbs such as validates and verifies them grouping four to nine subfeatures of the type ‘Manage
validate input data restrictions or business rules, and must have self Entity’, not counted on the first group), seven are of the type
call behaviours in sequence diagrams. Conversely, verbs such as ‘Workflow Process’ and 30 are of the type ‘Report Execution’. The
(searches and retrieves) trigger a return message to the control collaborating team was composed of three software developers and
class. one manager.
The second system is used by a large tourism company that
manages events. The software selected for our tests has 57 features,
2.4 Diagram generation
21 of which are of the type ‘Manage Entity’, 16 are of the type
This section uses examples to demonstrate the artefact generation ‘Manage Composite Entity’, five are of the type ‘Workflow
process, taking into consideration the rules and patterns detailed in Process’ and 15 are of the type ‘Report Execution’. The team was
the previous section. composed of a software developer and a manager.
Fig. 2 shows the main steps executed by the LUCAMTool Finally, we picked a system used to control and standardise
parser core to map elements present in the specification. forms generated in a nationwide cellulose company. The software
The algorithm takes a use case specification in LUCAM as has 109 features, 42 of which are of the type ‘Manage Entity’, 33
input and returns the elements mapped into class and sequence are of the type ‘Manage Composite Entity’, six are of the type
diagrams. The IdentifiesSentence() and ‘Workflow Process’ and 28 are of the type ‘Report Execution’. The
IdentifiesMessage(Sentence) methods are responsible for doing the project involved four developers, a business analyst and a manager.
mapping, as mentioned in Section 2.3. Elements are mapped with The group of features covered by our tests is presented in
respect to the terms and behaviour of each sentence. Elements are Table 3.

IET Softw., 2018, Vol. 12 Iss. 2, pp. 129-135 131

© The Institution of Engineering and Technology 2017
 17518814, 2018, 2, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/iet-sen.2016.0279 by CAPES, Wiley Online Library on [09/11/2022]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
Table 1 Examples of objects returned by identifiesSentence()
No. Subject Verb Method Noun or attributes Prep1 Prep2 Entity class Boundary class Communication class Actor
1 customer informs Attributes to manager
2 manager selects insert Account on mainform
3 manager enters attributes (…) of customer
4 system returns input … screen to manager
5 system sends notification by e-mail
6 system searches for customer
7 system returns Attributes of customer
8 system saves Attributes of customer
9 system validates Attributes of customer
10 system verifies Attributes of customer
11 system displays Attributes of on customer mainform
12 system cancels operation

Table 2 LUCAM sentence patterns

No Syntactic structure Sender Receiver Operation
1 ActorS verb noun preposition ActorR — — —
2 actor verb noun/method preposition boundary actor boundary verb + noun/method
3 actor verb noun preposition entity actor boundary verb + noun + preposition + entity
4 system verb noun/message preposition actor controller boundary verb + noun/message
5 system verb noun preposition communication controller controller verb + noun + preposition + commun.
6 system VerbEntityWithReturn noun preposition entity last receiver class (LRC) entity verb + noun + preposition + entity
7 system VerbEntityWithReturn noun preposition entity entity controller return + noun + preposition + entity
8 system VerbEntityWithoutReturn noun preposition entity controller entity return + noun + preposition + entity
9 system VerbValidation noun preposition entity controller controller verbv. + noun + preposition + entity
10 system VerbProcessing noun preposition entity controller controller verbp. + noun + preposition + entity
11 system VerbReturnInBoundary noun preposition boundary LRC boundary verbreturn + noun
12 actor/system verb noun controller controller verb + noun

The first chart in Fig. 7 represents the time (in minutes) needed
to create specifications for 30 features classified as ‘Simple Entity’.

Analysing the overall results and considering all use cases,

there was a productivity increase of about 30%. From the 15th
functional requirement (FR15) onwards, we started to see a more
stable behaviour, and result analysis from this point on revealed
that productivity gains reached up to 50% in comparison with the
manually crafted specification.
In the second chart, presented in Fig. 8, we can see how long
analysts took to complete the specification of 30 ‘Composite
Entity’ use cases.
For use cases classified as ‘Composite Entity’, an overall result
analysis, including language learning time, tells us that the
effective productivity was ∼20%. Beginning with the 20th
functional requirement (FR20), the productivity increased for the
remaining requirements by nearly 40%.
Fig. 2 Algorithm 1: Main steps executed by the parser Even though the results presented in the chart were obtained in
tests with a single team, we can already perceive significant
The identities of collaborating companies and the original productivity gains. We observe that initially analysts take a
documents provided by them will be kept private, following significantly longer time to complete a specification due to their
compliance rules agreed between the parties. unfamiliarity with the LUCAM features. The fact that LUCAM is a
It was noticeable in our tests that both class and sequence DSL with limited scope makes learning it very fast, especially in
diagrams remained in accordance with what was specified in comparison with a general-purpose language. When users acquire a
LUCAM language. This is a very important factor in stimulating certain level of familiarity with the language, productivity gains
the use of formal methods, because in practice we observed that ensue.
most models that are handcrafted by specialists partially diverge We also surveyed with the teams working in the collaborating
from textual specifications, failing to accurately portray what was companies. Below we detailed a few key points assessed from the
specified. answers gathered in the survey.
The cellulose company provided us with their TimeSheets Note that in the biggest of our three collaborators, software
records, from which we selected a set of 60 functional developed was appropriately documented. The company
requirements (FR) for analysis, 30 of the type ‘Simple Entity’ and mentioned, however, that quite often documentation becomes
30 of the type ‘Composite Entity’. Our analysis stored the time outdated with time, no longer accurately reflecting what was
each analyst took to specify (both textually and graphically) each implemented.
use case, manually and using the LUCAMTool. However, the smaller companies do not have a culture of
documenting the software they develop. When asked why they do
not document the software, they told us: ‘[…] documentation is too

132 IET Softw., 2018, Vol. 12 Iss. 2, pp. 129-135

© The Institution of Engineering and Technology 2017
 17518814, 2018, 2, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/iet-sen.2016.0279 by CAPES, Wiley Online Library on [09/11/2022]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
could use some improvements in its code editor and include a
feature to view generated diagrams’.

4 Related work
Early last decade, Li [8] proposed a set of rules to formalise the
specification of textual use cases, enabling the analyst to infer what
classes, objects, associations, attributes and operations compose a
particular use case. However, it is a case of purely mechanical and
non-automated activity, since a testing tool for the proposed
standard was not developed.
Williams et al. [9] proposed an approach that allowed users to
explore the most common problems observed in use case
modelling, unveiling inconsistencies and misalignment between
models and their textual specifications. Hoffmann et al. [10] later
presented a meta model for textual use case description that defines
a representation of use case behaviour, being easily understandable
for readers that do not master the subject. For modelling narrative
use cases, the authors developed the NaUTiluS tool.
In [2], a language for use case specification named SilabReq is
Fig. 3 Main flow – AddAccount proposed. From use cases, it generates domain models, the system
operations list, the use case model and activity and state diagrams.
In the following year, the same author proposed the separation of
use case specifications into different layers of abstraction, since use
cases are used by people with different roles and needs during
software development, from end-users, requirement engineers and
business analysts, to designers, developers and testers. Differently
from the aforementioned approach, and in addition to use case and
sequence diagrams, the LUCAMTool is also able to generate class
diagrams, one of the most important diagrams in UML. The tests
conducted with the LUCAMTool in real software development
environments and the results derived from them also set LUCAM
apart from SilabReq.
Thakur and Gupta [11] presented a tool that enables automatic
generation of sequence diagrams from use case specifications
written in natural language (English). In this approach, the natural
language analyser developed by Stanford NLP Group [12] was
used to identify the objects and interactions among them from the
specification. The parser analyses sentences and classifies each
word of the text as an adjective, adverb, article, pronoun, noun,
verb etc. Therefore, the approach does not consider situations in
the sequence diagram such as combined fragments, self calls and it
does not generate other Unified Modelling Language (UML)
models.
In the next year, Yue et al. [13] presented a tool denominated
Fig. 4 Alternate flow – CloseAccount
aToucan. The tool is able to perform automatic generation of a
UML analysis model contemplating class, sequence and activity
time-consuming, and it is not worth it to our team to write it. […] diagrams, from a previously defined use case model. Researchers
UML diagrams are too complex and require too much effort from also adopted a specification in natural language (English) and
our analysts’. similarly to the previously cited work, Stanford Parser was used to
Most of the interviewed staffs are versed in one or more classify words in sentences written in natural language.
programming languages and were interested in a solution to help Despite the evolution in automatic model generation
automate some of the stages in software development. They are techniques, we observed that adopting natural language implies
also willing to learn a new language to write software embracing the risk of recurring problems, since natural language is
specifications. inherently non-structured, ambiguous and does not establish a
Regarding results obtained from the use of the LUCAMTool, communication standard for the team. This hinders the automation
most of the respondents consider its application in a real scenario of artefact generation and, consequently, the traceability among
viable, according to a few answers: ‘[…] the language used by the specifications, model and source code.
tool is very intuitive and easy to learn. […] using the proposed On the other hand, domain-specific languages (DSLs) establish
language gives us more precision when building the generated a common language to be used by all team members. Its formality
diagrams and partly removes the reliance on specific software to standardises communication among those involved in the project,
generate diagrams …’. paving the way towards more productivity, increased reliability and
When asked whether diagrams generated by the LUCAMTool enhanced generated artefact quality [14, 15]. DSLs also permit
accurately reflect what was specified, and whether specifications solutions in the application domain level, enabling the analysts to
translated to LUCAM remain authentic to the natural language understand, validate, modify and develop features utilising the
models provided, the majority of respondents confirmed that they defined language. Domain specialists and software engineers are
do, validating the conducted tests. already familiar with the formality of programming languages,
After receiving training on the LUCAM language and the which reduces the time for learning the DSL and optimises
LUCAMTool, and when presented with the results obtained during resource utilisation [3, 15, 16].
testing, the teams identified some positive points: ‘[…] the
language is objective, clear, and easy to learn. […] the models
accurately reflect the specification. […] artefact generation in XMI 5 Conclusion
format’; and a few negative ones: ‘[…] specifications of more Features present in the LUCAM standardise important stages in
specific processes, such as SAP, are not supported. […] the IDE system development, such as use case specification and modelling.
IET Softw., 2018, Vol. 12 Iss. 2, pp. 129-135 133
© The Institution of Engineering and Technology 2017
17518814, 2018, 2, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/iet-sen.2016.0279 by CAPES, Wiley Online Library on [09/11/2022]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License

IET Softw., 2018, Vol. 12 Iss. 2, pp. 129-135

© The Institution of Engineering and Technology 2017
Total

109
115
57
Reports
30
15
28
Workflow
7
5
6
Composite entity
25
16
33
Single entity
53
21
42
Table 3 Feature list for the tested systems
Fig. 6 Sequence diagram

concrete management
Fig. 5 Class diagram

event management
form management
Systems

134
 17518814, 2018, 2, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/iet-sen.2016.0279 by CAPES, Wiley Online Library on [09/11/2022]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
• support for multiple natural languages, not just English;
• version control for the generated artefacts;
• generation of additional software artefacts such as other UML
diagrams, screen prototypes, automated test cases and source
code;
• import and export of specifications to enable interoperation with
other tools;
• specification and management of non-functional requirements;
• support the user story format;
• automatic propagation of changes in any of the formats (DSL,
diagrams and source code) to all the others to better support
iterative refinement and validation of software.
Fig. 7 Time specification and modelling – single entity
The LUCAMTool has been tested in selected environments, but
testing of the tool and its extensions should be expanded to a larger
range of corporate environments.

6 Acknowledgment
The authors acknowledge the financial support received from
IFMG, FAPEMIG and PUCMinas Brazil.

7 References
[1] El-Attar, M.: ‘A systematic approach to assemble sequence diagrams from use
case scenarios’. 2011 3rd Int. Conf. Computer Research and Development
(ICCRD), March 2011, vol. 4, pp. 171–175
[2] Savic, D., Antovic, I., Vlajic, S., et al.: ‘Language for use case specification’.
Fig. 8 Time specification and modelling – composite entity 2011 34th IEEE Software Engineering Workshop (SEW), June 2011, pp. 19–
26
This standardisation increases productivity and establishes a clear [3] Fowler, M., Parsons, R.: ‘Domain-specific languages’ ‘(The Addison-Wesley
Signature Series) (Addison-Wesley, Upper Saddle River (NJ), Boston, Paris,
and precise team communication standard. It alleviates frequent 2011)
problems arising from natural language use, such as ambiguity, [4] Heering, J., Mernik, M.: ‘Domain-specific languages for software
uncertainty and complexity. The LUCAMTool also enables the engineering’. Proc. 35th Annual Hawaii Int. Conf. System Sciences, 2002,
automatic and consistent generation of use case, class and sequence HICSS, January 2002, pp. 3649–3650
[5] Tiwari, S., Gupta, A.: ‘A systematic literature review of use case
diagrams, which can be used to generate source code prototypes. specifications research’, Inf. Softw. Technol., 2015, 67, pp. 128–158
Every DSL is defined by syntactic and semantic rules, which [6] ‘Openup’. Available at http://epf.eclipse.org/wikis/openup/index.htm,
makes user training sessions an essential activity. As a result of our accessed 2 August 2 2015
tests, we realised that we can mitigate productivity losses resulting [7] ‘Astah’. Available at http://astah.net/editions/professional, accessed 30
August 2015
from the use of an unfamiliar language by training users in the use [8] Li, L.: ‘Translating use cases to sequence diagrams’. Proc. 15th IEEE Int.
of the tools [3, 16]. We learned that DSL designers must clearly Conf. Automated Software Engineering, ser. ASE ‘00, Washington, DC,
understand the DSL's purpose and how its potential users work. USA, 2000, p. 293
The DSL's syntax and semantics should be simple and built [9] Williams, C., Kaplan, M., Klinger, T., et al.: ‘Toward engineered, useful use
cases’, J. Object Technol., 2005, 4, (6), pp. 45–57
straightforwardly on the concepts and vocabulary that users already [10] Hoffmann, V., Lichter, H., Nyßen, A., et al.: ‘Towards the integration of
understand. This makes the DSL easier to learn. UML-and textual use case modeling’, J. Object Technol., 2009, 8, (3), pp. 85–
We concluded that it is possible to automatically generate 100
software artefacts from a DSL. This has some advantages: It [11] Thakur, J.S., Gupta, A.: ‘Automatic generation of sequence diagram from use
case specification’. Proc. 7th India Software Engineering Conf., ser.
enables the reuse of existing software artefacts. It also produces ISEC ’14, New York, NY, USA, 2014, pp. 20:1–20:6
standardised artefacts based on consistent models, thus potentially [12] ‘Stanford parser’. Available at http://nlp.stanford.edu/, accessed 5 August
increasing productivity, decreasing errors and improving quality. 2015
By providing a consistent set of representations, it facilitates [13] Yue, T., Briand, L.C., Labiche, Y.: ‘Atoucan: an automated framework to
derive UML analysis models from use case models’, ACM Trans. Softw. Eng.
communication among analysts, software developers and others. Methodol., May 2015, 24, (3), pp. 13:1–13:52
Although simulated environments are quite useful in debugging [14] Heijstek, W., Chaudron, M.: ‘The impact of model driven development on the
software tools, they often do not capture all the relevant software architecture process’. 2010 36th EUROMICRO Conf. Software
characteristics of real-world software development environments. Engineering and Advanced Applications (SEAA), September 2010, pp. 333–
341
Some situations only arise on large projects in production [15] Ghosh, D.: ‘DSL for the uninitiated’, Commun. ACM, 2011, 54, (7), pp. 44–
environments. Thus, the opportunity to conduct tests in real-world 50
environments was invaluable. It enabled us to identify potential [16] Gupta, G.: ‘Language-based software engineering’, Sci. Comput. Program.,
features of the LUCAMTool and helped us plan future steps of the 2015, 97, (Part 1), pp. 37–40, special issue on new ideas and emerging results
in understanding software
project.
What are the possible future steps? Possible extensions to
LUCAMTool include:

IET Softw., 2018, Vol. 12 Iss. 2, pp. 129-135 135

© The Institution of Engineering and Technology 2017

View publication stats