An Approach for Generating Class and Sequence Models

Int'l Conf. Software Eng. Research and Practice | SERP'16 | 253

Márcio A. Miranda2,3, Marcos G. Ribeiro4, Renan D. Tavares3, Thiago H. B. Dias3, Humberto T. Marques-Neto3, Mark A. J. Song1,3 1Department of Computer Science / Centro Universitário UNA / Belo Horizonte, MG, Brazil 2Department of Computer Science / Federal Institute of Minas Gerais / Ouro Branco, MG, Brazil 3Department of Computer Science / Pontiﬁcal Catholic University of Minas Gerais / Belo Horizonte, MG, Brazil 4Department of Computer Engineering / Federal Center of Technological Education of Minas Gerais / Timóteo, MG, Brazil [email protected], [email protected], {rdtavares, thdias}@sga.pucminas.br, {humberto, song}@pucminas.br, [email protected]

Abstract— The use of domain-specific languages has been One of the resources that have been generating interest gaining traction in the requirement analysis and discovery are Domain-Specific Languages (DSL). Although limited process due to features such as establishing standardized in scope, they define a communication standard between team communication, allowing the automation of certain engineers and domain specialists. They can also help mini- stages of the process, and bringing productivity gains mize natural language uncertainty and ambiguity. Readabil- without compromising quality. In this paper we proposed ity, understandability and productivity are also fundamental and implemented the Language of Use Cases to SEquence characteristics to justify the use of DSL to describe use cases Diagram (LUCSED), a domain-specific language for the [8], [9], [10]. textual specification of use cases and, through our LUCSED- In this paper we propose and implement an external tool, automatically generate use case, sequence and class DSL called Language of Use Cases to SEquence Diagram diagrams. To assess the viability of our solution, we carried (LUCSED), which defines standards of a language which out several tests aiming to cover a diversity of scenarios allows requirement analysts to specify textual use cases. We found in software development. Our approach can be useful also propose a tool called LUCSEDTool which comprises in requirement analysis and modeling, and seeks to min- automatic generation of use case, class, and sequence di- imize problems present in natural language specifications, agrams from the specification. The tool maps the specifi- such as: uncertainty, ambiguity, complexity and an intense cation following language rules for the Extensible Markup dependence on domain knowledge by specialists. Language Metadata Interchange (XMI) input standard, supported by Unified Modeling Language (UML) modeling Keywords: Automatic Generation, Class Diagram, Domain- software, such as Astah [11] and others. Specific Language, Sequence Diagram, Use Case Specification. The remainder of this article is structured as follows. Section 2 briefly describes some of the relevant related work 1. Introduction developed in the last two decades. Section 3 presents our proposed approach, highlighting the main grammar rules in Currently, there are many different ways to analyze and LUCSED, the sentence patterns supported by the language specify software requirements, such as user stories, mod- and the artifact generation process. We present and discuss els and formal languages. To [1], capturing and mapping our results in Section 4. Finally, we conduct a conclusive requirements is mostly done through textual use case spec- analysis and state our final considerations. ifications, so that even laymen are able to understand them. However, the inherent use of natural language can negatively 2. Related Work affect artifact quality, due to difficulties such as ambiguity, In the beginning of the past decade, [12] proposed a set of redundancy, inconsistency and incompleteness [2], [3]. rules to normalize textual use case specification. Following According to [4], representing requirements in a standard- this standard, analysts can infer which classes, objects, asso- ized way which is easily understood by all participants of a ciations, attributes and operations belong to a use case and project can mitigate the problem, and even bring a certain generate sequence diagrams from this information. However, level of automation to the process [5]. Thus, to reach this this is done manually instead of automatically, since no tool goal, it is necessary to formalize structural and behavioral to test the proposed standard has been implemented, relying aspects of use case specifications [2], [6], [7]. instead on specialist knowledge.

ISBN: 1-60132-446-4, CSREA Press © 254 Int'l Conf. Software Eng. Research and Practice | SERP'16 |

A few years later, [13] proposed a solution to explore and software engineers are already used to programming the most common problems in use case modeling, showing language formality, and this reduces language learning time inconsistencies between use case models and their textual and optimizes resource reuse [5], [21]. specifications. Later, [14] presented a meta-model to describe textual use cases. It defines a textual representation 3. Proposed Solution of use case behavior, easily understood by readers who do Our proposed DSL (LUCSED) contemplates use case not have full command the subject. To model use cases nar- detailing and along with LUCSEDtool enables the automatic ratives, they developed the Narrative Use Case Description generation of UML diagrams in requirement-oriented soft- Toolkit for Evaluation and Simulation (NaUTiluS) tool. ware processes, following object orientation principles and The work [15] proposed and implemented a tool called the Model-View-Controller (MVC) architectural model. Procasor to automatically generate executable code from use LUCSEDtool is a support tool used to map relevant case specifications. Similarly to our work, they defined a information in use case detailing into an XMI input stan- standard to specify textual use cases in a format recognized dard, recognized by UML modeling software. It is also by their tool, but they did not generate UML models, able to generate artifacts directly in the .astah format, and and LUCSEDTool does not generate executable code. In if users already have Astah installed in their computers, [4], authors present a language for use case specification they can choose to open the diagram in Astah in the based on Xtext and called SilabReq. From use cases, the correct format. LUCSEDtool is available for download at tool generates domain models, a list of system operations, https://github.com/assismiranda/LUCSEDTool. a UML use case model, and state, activity and sequence The conversion of use case specifications into UML diagrams. In the following year, the same author proposed diagrams follows the process shown in Figure 1. The process dividing specifications into different abstraction levels, since consists in mapping textual use cases written in the LUCSED use cases are used by people in different roles with different language into object oriented models, specifically use case, needs during software development, from end users, require- classes and sequence diagrams. Note that a possible sub- ment engineers and business analysts, to project engineers, sequent stage is the automatic generation of model source developers and testers. codes, since most modeling tools are capable of generating In the papers [16], authors proposed and implemented source code from UML models. a tool to automatically generate sequence diagrams from use case specifications written in the English language. The solution uses the natural language parser Stanford Parser [The Stanford Natural Language Processing Group] [17] to identify objects and interactions among them from use case specifications. The parser analyzes sentences and classify words into adjectives, adverbs, articles, pronouns, nouns, verbs, etc. Therefore, the solution ignores situations in se- Fig. 1: LUCSED-to-UML transition quence diagrams such as combined fragments and messages to self, and does not generate other UML models. When designing the DSL, we sought to follow a set of In the following year, the work [18] proposed an approach relevant requirements, to achieve features like simplicity and called aToucan, based on existing solutions, to automatically objectivity, in order to offer a clear and self-explanatory generate UML analysis models comprising class, sequence syntax which would help reduce language learning time. and activity diagrams from a use case model. They also used LUCSED use case detailing was based on the tem- natural language specifications (English) and used Stanford plate proposed by the unified software development process Parser [17] to map specifications. OpenUP (Open Unified Process) [22]. Thus, the specification However, natural language is free, ambiguous and defines is composed by the following attributes: use case name, brief no team communication standard, making automatically description, actors, basic and alternate flows, main scenarios, generating artifacts, and consequentially traceability between pre-conditions, post-conditions, and special requirements specification, model and source code, very difficult. and extension points, as shown in Figure 2. The highlighted Conversely, properly designed domain-specific languages, words are reserved words in the proposed DSL. unlike natural languages, establish a common language to be used by all team members, and their formality standardized The original template was focused on natural languages, communication between stakeholders [19], [20]. which do not require any standardization and usually are Additionally, DSL allows solutions to be expressed at not bound by any restrictions. They also present syntactic application domain level, enabling business analysts to un- phenomena which would culminate in semantic imprecision, derstand, validate, change, and even develop features using making use case process automation more difficult. So, to the language. We can also highlight that domain specialists correctly map detailed use cases into class and sequence

ISBN: 1-60132-446-4, CSREA Press © Int'l Conf. Software Eng. Research and Practice | SERP'16 | 255

• PrimarySecondaryActors ::= “Primary and Secondary Actors ” PrimaryActorName [SecondaryActorName] • PrimaryActorName ::= “Primary Actors: ” ActorID {“,” ActorID} POINT • SecondaryActorName ::= “Secondary Actors: ” ActorID { “,” ActorID} POINT

The most important LUCSED rules, the rules that make up the main ﬂow of the use case speciﬁcation, are presented below.

Fig. 2: LUCSED template • MainFlowName ::= “Main Flow: ” MethodControlClas- sID POINT • MainFlowScope ::= [ActorID “ starts Use Case” POINT] MainFlow [ActorID “ finishes Use Case” POINT] diagrams, it was necessary to adapt the base template • MainFlow ::= MainFlowElements {MainFlowElements} to accommodate necessary and sufficient DSL information • MainFlowElements ::= MainFlowCore | FlowIf | required to automate the generation of software artifacts FlowLoop | FlowConcurrency supported by LUCSED. • FlowIf ::= “If ” Condition MainFlow [“Else ” MainFlow Some of the necessary adaptations were: making class ]“EndIf” • FlowLoop ::= “Loop ” Condition MainFlow “EndLoop” attributes and methods explicit; in addition to primary and • FlowConcurrency ::= “StartConcurrency ” MainFlow secondary actors, it is necessary to inform the name of the “concurrent” MainFlow “EndConcurrency” system actors will interact with; for sequence diagrams, it • MainFlowCore ::= ((ActorID | SystemID) (Main- is also necessary to state the combined decision, repetition FlowTabTransVerb | TABINTRANSVERB) POINT) | and concurrency fragments (if, loop and concurrency respec- ReturnMessage • MainFlowTabTransVerb ::= TABTRANSVERB tively), according to the DSL syntax. [“MethodBoundaryID”] ( MainFlowAttibutes | “on” LUCSED has mechanisms to describe several situations in MainFlowBoundaryClass) which an actor interacts with a system in order to perform a • MainFlowAttibutes ::= [[“the”] TABNOUN [“(” [At- certain action. The standardization proposed by the language tributeTypeID] AttributeID {, [AttributeTypeID] At- | makes it easier to map information present in a use case tributeID}“)”]] ((“on” MainFlowBoundaryClass (“of”) MainFlowEntityClass)) | MainFlowsActorClass) detailing into the appropriate classes, such as relationships, • MainFlowBoundaryClass ::= BoundaryClassID attributes and methods. • MainFlowActorClass ::= ("for" | "to") ["the"] ActorID The main LUCSED grammar rules in Extended Backus- • MainFlowEntityClass ::= EntityClassID [“on” Main- Naur Form (EBNF) notation are presented and explained FlowBoundaryClass | “by” MainFlowCommunication | below, organized in 5 parts. MainFlowsActorClass) ] In the first part of the grammar we have the rules that • MainFlowCommunication ::= CommunicationID compose the main structure (skeleton) of use case detailing. • ReturnMessage ::= (SystemID TABTRANSVERB SimpleReturnMessage (“to” | “for”) ["the"] ActorID | SystemID ) • LUCSED ::= UseCaseHeader UseCaseFlows UseCase- Footer • UseCaseHeader ::= UseCaseName UseCaseBriefDe- The part of the grammar that contemplates alternate flows scription SystemName PrimarySecondaryActors is quite simple, because its main rule (AlternateFlowCore) • UseCaseFlows ::= MainFlowName MainFlowScope [Al- derives to the most important main flow rule (MainFlow). ternateFlows] • UseCaseFooter ::= Key Scenario {KeyScenario} This means that the same specification pattern defined for PreConditions PosConditions SpecialRequirements the basic flow is also accepted for alternate flows. ExtensionPoints • AlternateFlows ::= “Alternate Flows ” AlternateFlowS- In the second part, we have rules responsible for cope { AlternateFlowScope} generating specification headers. We can highlight rules • AlternateFlowScope ::= “Alternate Flow ” NUM “: ” UseCaseName, SystemName, PrimaryActorName and MethodControlClassID POINT AlternateFlowCore • AlternateFlowCore ::= MainFlow SecondaryActorName, since the name of the control class, system name, and primary and secondary actor names are Through these rules, it is possible to map boundary and respectively mapped through these rules. entity classes, their attributes and methods. In order for class attributes and their types to be mapped, the analyst must • UseCaseName ::= “Use Case: ” ControlClassID POINT • UseCaseBriefDescription ::= “Brief Description” [Text] explicitly state them in the specification, otherwise they will POINT not appear on the diagram. The rules that represent class • SystemName ::= “System: ” SystemID POINT attributes and their types are AttributeID and AttributeTypeID

ISBN: 1-60132-446-4, CSREA Press © 256 Int'l Conf. Software Eng. Research and Practice | SERP'16 |

respectively. The name of the control class is generated from Table 2: Class interaction rules the use case name, through rule ControlClassID. Conversely, Nº Syntactic Structure Sender Receiver Operation the names of boundary and entity classes are generated 1 ActorS Verb Noun ActorS ActorR Verb+Noun Preposition ActorR through rules BoundaryClassID and EntityClassID respec- 2 Actor Verb Actor Boundary Verb+Noun/Method tively. Control class methods are generated from the names Noun/Method Prep. Boundary of each flow (main and alternate), through rule MethodCon- 3 Actor Verb Noun Actor Boundary Verb+Noun+Prep.+Entity trolClassID. Boundary class methods are identified by rule Preposition Entity 4 System Verb Controller Boundary Verb+Noun/Message MethodBoundaryID. Noun/Message Prep. A key point in the process is the ability to identify a cer- Actor 5 System Verb Noun Controller Controller Verb+Noun+Prep.+Commun. tain class and its type. Note that in addition to the adaptations Preposition Commu- made to the base template and the aforementioned rules, we nication 6 System VerbEntity- Last Entity Verb+Noun+Prep.+Entity defined another set of rules based on the prepositions that WithReturn Noun Receiver precede the names of each class in the sentence. Such rules Prep. Entity Class (LRC) are specified in Table 1. 7 System VerbEntity- Entity Controller Return+Noun+Prep.+Entity WithReturn Noun Prep. Entity Table 1: Rules with prepositions 8 System VerbEnti- Controller Entity Return+Noun+Prep.+Entity Previous Preposition Type Class tyWithoutReturn Of Entity Noun Prep. Entity 9 System VerbValida- LRC LRC VerbV.+Noun+Prep.+Entity On Boundary tion Noun Prep. En- To/For Actor tity By Communication 10 System VerbProcess- Controller Controller VerbP.+Noun+Prep.+Entity ing Noun Prep. Entity 11 System VerbReturn- Controller Boundary VerbReturn+Noun In addition to mapping classes and their attributes and InBoundary Noun methods, LUCSEDTool also stores action execution flows Prep. Boundary and consequentially messages exchanged between objects, thus enabling the automatic generation of sequence diagrams. Rules FlowIf, FlowLoop, FlowConcurrency and Rules 6 and 7 are identical, therefore we have a type of Condition, defined in the grammar, were specifically created pattern that generates two operations, namely having two to map combined fragments present in these diagrams, as different behaviors. For example: When the user searches per Figure 7. for something (verb searches), the message must be relayed To identify interactions between classes in the sequence from the Boundary class to the Entity class. The same thing diagram, we defined a syntactic structure for each sentence happens when the system retrieves the data being searched: pattern supported by LUCSED. Thus, it is possible to a message is sent from the Entity class and is replicated identify who is the sender, who is the receiver, and what until it gets to the Controller class. In some cases, messages is the message to be sent. The main rules are defined in originate from Controller classes, which is why we defined table 2. the Last Receiver Class (LRC) time, because during the The sentences contained in the specifications written in flow it is necessary to control in which class a method was the LUCSED language must conform to the patterns defined last invoked. Such a situation can be seen in the sequence in the aforementioned rules, so the parser can correctly diagram presented in Figure 8. map interactions for the automatic generation of sequence Still pertaining to the generation of sequence diagrams, diagrams without compromising quality. it is important to highlight that the core of the parser Following the same order as the rules presented in Table 2, (LUCSEDTool) contains two fundamental methods, namely we provide a sample sentence conforming to each of these identifySentence() and identifyMessage(). The first method patterns: analyzes each word in a sentence and assigns it a grammat- 1) Patient tells the attributes to the Clerk. ical class, such as verb, preposition, noun or other terms in 2) Clerk selects "MaintainPatient" on MainForm. the specification. After classifying the words in all sentences, 3) Clerk enters attributes (...) of Patient. the identifyMessage() method is called, identifying message 4) System returns "Input mode screen" to Clerk.. description, and origin and destination class of a message, 5) System sends the notification by e-mail. based on the grammatical class of words from the sentence 6) System searches for the Patient. passed as parameter. 7) System retrieves the attributes of Patient. Some verbs are rule exceptions due to needing special 8) System saves the attributes of Patient. treatment going beyond a direct message between two 9) System validates attributes of Patient. sentence elements, that is, these verbs behave differently 10) System verifies the attribute (condition) of the Patient. than the others. Verbs such as validates and verifies, which 11) System displays the attributes of Patient on MainForm. validate input restrictions or business rules having a message

ISBN: 1-60132-446-4, CSREA Press © Int'l Conf. Software Eng. Research and Practice | SERP'16 | 257

to self behavior in the sequence diagram are treated by a The following is the header in LUCSED language for the class called ClassVerbsValidation. Other verbs that signal a use case CRUDPatient. return to the control class, like searches and retrieves are identified by class ClassVerbsEntityReturn. In an effort to achieve simplicity and more user in- teractivity, we created three special terms that reference sets of words previously registered in LUCSEDTool. Term TABTRANSVERB refers to a set of transitive verbs and term TABINTRANSVERB refers to a set of intransitive verbs. These terms are implemented in LUCSEDTool in the form Fig. 3: Header - UC CRUDPatient of tables, with a list of pre-registered verbs that are used to semantically verify sentences used in use case detailing, according to rules presented in Table 2. This verification The AddPatient main flow of the use case is shown in is done through validating some grammatical rules, for Figure 4. This flow occurs when there are no detours in the example, some verbs only make sense in the context of a basic flow, because if there are any detours, alternate flows phrase if they are related to an actor. Conversely, other verbs or exceptions will be executed. The main flow describes the only make sense if they are related to the system. Nouns included in the LUCSED dictionary are also ex- tremely important. We therefore created the term TABNOUN, representing a list of nouns pre-registered in LUCSEDTool, in order to increase the possible number of sentences users can write in the proposed DSL. The list can easily be edited using the tool, just like pre-existing verbs in the transitive and intransitive verb tables. Finally, we have the rules responsible for specification footers.

• KeyScenario ::= “Key Scenario ” NUM “: ” MethodCon- trolClassID POINT • PreConditions ::= “Pre Conditions ” [Text] POINT • PosConditions ::= “Post Conditions ” [Text] POINT • SpecialRequirements ::= “Special Requirements ” [Text] POINT • ExtensionPoints ::= “Extension Points ” [Text] POINT Fig. 4: Main Flow - UC CRUDPatient

4. Results process of registering a new client in the system, where the user selects the desired option and the system shows In this section, we present some of the results we obtained the client registration screen. After getting patient data as when using LUCSEDTool in tests carried out in software input, the system will validate the required fields until all of from different fields, such as e-commerce, cellulose, mining, them are filled. Then, it will check the database for duplicate school management and medical software. We gathered doc- records and notify the user. Finally, it will save the record umentation developed by specialists from several companies, and send the user a positive feedback. which had detailed use cases and UML diagrams generated As mentioned in the previous section, the Alternate flow from them. The original specifications had to undergo some structure is similar to the main flow. The specification of al- changes to adequately satisfy LUCSED grammar rules. ternate flows ModifyPatient, DisablePatient and ReadPatient The tests presented here were done in the software system is presented below, as seen in Figure 5. The clerk can modify, of a medical company which has subsidiaries in several disable and search for patients registered in the clinic. cities. The use case presented as a result is CRUDPatient, Based on the presented specification, we generated the which has the clerk as primary actor. For this requirement, class diagram, containing the relationships between classes the cited actor has the privileges of inserting a new client, and their attributes and methods, as seen in Figure 6. In the editing existing information, disabling a client’s subscription, diagram, we identified a boundary class (MainForm), a con- and searching for existing clients. To have access to these trol class (CRUDPatient) and an entity class (Patient). The features, users must be logged into the system, as stated in name of each class, as well as the names of attributes and the pre-conditions of the use case detailing. methods, depends directly on what the analyst specification

fragments. The diagram shown in Figure 8 refers to the alternate ﬂow

Fig. 7: Sequence Diagram AddPatient

DisablePatient. It is a simpler diagram representing the flow Fig. 5: Alternate Flow - UC CRUDPatient of disabling a patient in the company’s system. The flow basically consists of the user providing the system with the identification of the patient to be disabled, the system searching for the data, checking if there are any pendencies and providing adequate feedback to each situation.

Fig. 6: Class Diagram UC CRUDPatient Fig. 8: Sequence Diagram DisablePatient

was. Note that when comparing the presented specification We deemed the results produced by LUCSEDTool to and diagrams, the names defined in both specification and be satisfactory, because they came very close to what was diagrams are the same. produced by specialists. In some cases, the diagrams auto- The first sequence diagram presented pertains to the main matically generated by the tool were richer in detail than flow AddPatient, as seen in Figure 7. We can observe that the original documentation, making it evident that diagrams this diagram contains the main features present in a sequence created by specialists do not always contemplate everything diagram, such as calls to self, return messages and combined that is in the specification, or the other way around.

5. Conclusions References The LUCSED DSL, along with LUCSEDTool, has fea- [1] C. Alistair, Writing Effective Use Cases. Addison-Wesley, 2001. tures that contribute to the standardization of important [2] P. Jayaraman and J. Whittle, “Ucsim: A tool for simulating use case scenarios,” in Software Engineering - Companion, 2007. ICSE 2007 stages in software development, such as the requirement Companion. 29th International Conference on, May 2007, pp. 43–44. specification and use case modeling stages. Standardization [3] S. Tiwari and A. Gupta, “A systematic literature review of use would open the doors for clear and precise communication case specifications research,” Information and Software Technology, vol. 67, pp. 128 – 158, 2015. among the entire team, mitigating inherent natural language [4] D. Savic, I. Antovic, S. Vlajic, V. Stanojevic, and M. Milic, “Language problems such as ambiguity, uncertainty and complexity. for use case specification,” in Software Engineering Workshop (SEW), The tool is also able to automatically generate software 2011 34th IEEE, June 2011, pp. 19–26. [5] M. Fowler and R. Parsons, DSL - Linguagens Específicas de Domínio. artifacts such as use case, class and sequence diagrams. Porto Alegre: Bookman, 2013. These artifacts can be used to automatically generate source [6] M. G. Georgiades and A. S. Andreou, “Formalizing and automating code. Our solution offers additional benefits like: improved use case model development,” The Open Software Engineering Jour- nal, vol. 6, pp. 21–40, 2012. previously developed artifact reusability; increase in quality [7] T. Yue, L. C. Briand, and Y. Labiche, “Facilitating the transition from and productivity; more control over each stage of the pro- use case models to analysis models: Approach and experiments,” ACM cess; mitigation of several errors that can arise from the lack Trans. Softw. Eng. Methodol., vol. 22, no. 1, pp. 5:1–5:38, Mar. 2013. [8] P. J. Clemente, J. M. Conejero, J. Hernández, and L. Sánchez, of standards; and offering a common language to analysts “Haais-dsl: Dsl to develop home automation and ambient intelligence and users. systems,” in Proceedings of the Second Workshop on Isolation and One of the challenges in using such as resource is the Integration in Embedded Systems, ser. IIES ’09. New York, NY, USA: ACM, 2009, pp. 13–18. effort required by the whole team to learn the language, [9] D. Ghosh, DSLs in action. Manning Publications Co., 2010. since every DSL has syntactic and semantic rules that may [10] M. Freudenthal, “Using dsls for developing enterprise systems,” in require some training to master. However, the initial efforts Proceedings of the Tenth Workshop on Language Descriptions, Tools and Applications, ser. LDTA ’10. New York, NY, USA: ACM, 2010, are paid off once the entire team has a good command of pp. 11:1–11:7. the chosen language and tool [5], [21]. We also conclude [11] ASTAH, “Astah professional,” Agosto 2015, acesso em: 10 ago. that, when designing a DSL, we must always have users 2015. [Online]. Available: http://astah.net/editions/professional [12] L. Li, “Translating use cases to sequence diagrams,” 2011 26th and their needs in mind, and it is crucial to define simple IEEE/ACM International Conference on Automated Software Engi- grammar rules, be guided by relevant requirements and strive neering (ASE 2011), vol. 0, p. 293, 2000. to achieve premises such as simplicity and objectivity, to [13] C. Williams, M. Kaplan, T. Klinger, and A. M. Paradkar, “Toward engineered, useful use cases.” Journal of Object Technology, vol. 4, offer a clear, self-explanatory syntax culminating in a more no. 6, pp. 45–57, 2005. gentle learning curve and less ignored features. [14] V. Hoffmann, H. Lichter, A. Nyßen, and A. Walter, “Towards the Our tests led us to find some drawbacks in our tool, integration of uml-and textual use case modeling.” Journal of Object Technology, vol. 8, no. 3, pp. 85–100, 2009. which will consequently inspire future work, such as im- [15] V. Šimko, P. Hnetynka,ˇ and T. Bureš, “From textual use-cases to proving DSL and LUCSED features and incorporating new component-based applications,” in Software Engineering, Artificial features: improving usability (“folding”, “autocomplete”, Intelligence, Networking and Parallel/Distributed Computing 2010, ser. Studies in Computational Intelligence, R. Lee, J. Ma, L. Bacon, “syntax highlighting” and “outline”); implementing version W. Du, and M. Petridis, Eds. Springer Berlin Heidelberg, 2010, vol. control for generated artifacts; expanding the DSL to support 295, pp. 23–37. additional languages other than English; include support to [16] J. S. Thakur and A. Gupta, “Automatic generation of sequence diagram from use case specification,” in Proceedings of the 7th India generate additional UML diagrams; generate screen proto- Software Engineering Conference, ser. ISEC ’14. New York, NY, types; and allow users to import specifications generated by USA: ACM, 2014, pp. 20:1–20:6. other tools. [17] S. N. Group, “Stanford parser,” 2015, acesso em: 03 ago. 2015. [Online]. Available: http://nlp.stanford.edu/ To improve automatic consistency between a UML use [18] T. Yue, L. C. Briand, and Y. Labiche, “atoucan: An automated case model and its corresponding textual specification set, framework to derive uml analysis models from use case models,” textual representations of use case relationships present in ACM Trans. Softw. Eng. Methodol., vol. 24, no. 3, pp. 13:1–13:52, May 2015. the UML diagram must be created from effective identi- [19] W. Heijstek and M. Chaudron, “The impact of model driven develop- fications, which is not a trivial task. Enforcing coherence ment on the software architecture process,” in Software Engineering between a UML model and textual descriptions requires a and Advanced Applications (SEAA), 2010 36th EUROMICRO Con- ference on, Sept 2010, pp. 333–341. certain degree of formality in specifications. Conversely, it [20] D. Ghosh, “Dsl for the uninitiated,” Commun. ACM, vol. 54, no. 7, became clear to us that there are many benefits to formal- pp. 44–50, July 2011. ize use case specifications, even considering the inevitable [21] G. Gupta, “Language-based software engineering,” Science of Com- puter Programming, vol. 97, Part 1, pp. 37 – 40, 2015, special Issue learning curve [14]. on New Ideas and Emerging Results in Understanding Software. [22] ECLIPSE, “Openup,” 2015, acesso em: 02 ago. 2015. [Online]. Acknowledgment Available: http://epf.eclipse.org/wikis/openup/index.htm The authors acknowledge the financial support received from FAPEMIG, PUCMinas and Centro Universitário UNA, Brazil.