SOFTENG 2015 : The First International Conference on Advances and Trends in Software Engineering Automatic Generation of Sequence Diagrams and Updating Domain Model from Use Cases Fabio Cardoso de Souza, Fernando Antonio de Castro Giorno Master’s Program in Software Engineering Institute for Technological Research (IPT) São Paulo, Brazil e-mail: [email protected], [email protected] Abstract —Software modeling allows for problem utilization of markups in Use Cases can allow for the decomposition in a way that facilitates analysis and automatic partial generation of the Analysis Model, as communication of the solution to developers and other demonstrated in the Mason and Supsrisupachai [20] work, interested parties. Models are widely used in engineering in where marked up Use Cases are automatic transformed into general, but in Software Engineering modeling has often been Sequence Diagrams. left out due to the pressures to improve deadlines. A method The automatic partial generation could reduce the and a tool that reduce the duration of this phase could help duration of the modeling phase, thus stimulating the adoption furthering the modeling phase. Use Cases are commonly of this phase in Object-Oriented development projects, as utilized for functional specifications in Object-Oriented suggested by a qualitative research [23] carried out with paradigm and the use of markups in Use Cases allow an requirements analysts, system analysts and project managers. automatic partial generation of Analysis Models, reducing the time of the modeling phase in this paradigm. This paper In this qualitative research, the majority of the interviewees proposes a combination of rules for marking up Use Cases and agreed that software modeling improves the quality of the one procedure for generating partial Sequence Diagrams with final product and most of them believe that the automatic analysis classes (one Sequence Diagram for each Use Case) and generation of the partial Analysis Model can help the the updating of the Domain Model with operations. A tool was adoption of the modeling phase in software development built to prove the concept and two experiments were carried projects. Due to space limitation, details of this research are out. omitted. This paper presents a set of rules for marking up Use Keywords-Analysis Model; Use Case; Sequence Diagram; Cases and a transformation procedure that permits deriving Model Driven Architecture. Sequence Diagrams with analysis classes from the marked- up Use Cases. It also permits the updating of the Domain I. INTRODUCTION Model with operations identified in the Sequence Diagrams, Software modeling permits the analyst to break the leading to the Class Diagram. Class Diagram and Sequence problem to be solved into parts which can be better analyzed. Diagrams are the main diagrams in an Object-Oriented It also allows the formal communication of a functional and analysis model. The diagrams generated do not take into technical solution based on the demanded requirements. consideration details of a possible implementation, which Model is a formal specification of the structure or function of must be done during the design phase. According to Booch a system [1]. A graphic representation can be used to provide et al. [4], the analysis must yield a statement of what the a visual body for the model. system does, not how. This research also presents a tool Despite being widely used in many areas of engineering, which implements the proposed procedure and with which modeling has been left out in Software Engineering. the experiments were realized. According Rosenberg and Stephens [2], in practice, there The rest of this paper is organized as follows. Section 2 never seems to be enough time to do modeling, analysis and presents concepts on which this research is based. This design and there is always pressure from management to section also presents the State of the Art in the topics Model jump to code prematurely because progress on software Driven Architecture and transformation of Use Cases into projects tends to get measured by how much code exists, Sequence Diagrams. Section 3 presents a proposal for leading to problems in the quality of software. marking up Use Cases and a transformation procedure. Use Cases are commonly used for functional Section 4 presents the tool and two experiments. The fifth specification in Object-Oriented developments. According to and final section presents the conclusion and suggestions for Sommerville [3], Use Cases are an effective technique for future researches. eliciting requirements and they are increasingly used since the Unified Modeling Language (UML) became a standard for Object-Oriented modeling. Yet according to Rosenberg and Stephens [2], the Use Cases are created over a Domain Model since this offers the use of a common vocabulary. The Copyright (c) IARIA, 2015. ISBN: 978-1-61208-449-7 85 SOFTENG 2015 : The First International Conference on Advances and Trends in Software Engineering II. CONCEPTS AND STATE OF THE ART control and entity. According to him, boundary classes respond to information and behaviors related to system This section starts presenting concepts related with Use boundary; entity classes respond to information that are Cases, Software Modeling and transforming requirements stored in the system and to behaviors surrounding these into software models approaches, and ends with state of the information; and control classes respond to behaviors which art on transformation subject. are not naturally incorporated into entities. These definitions A. Requirements Specification with Use Cases are complemented by Bruegge and Dutoit [9], for whom, boundary classes represents interfaces between systems and Requirements Engineering provides appropriate actors, and control classes are in charge of realizing Use mechanisms for [5]: understanding what the client wants; Cases. analysis of her/his needs; evaluation of feasibility; The boundary and control classes, as well as their negotiation of a reasonable solution; specification of behaviors (their operations) are evident during analysis, in requirements in a unambiguous manner; validation of the Analysis Model. specification and management of the requirements to be In this paper, these three types of objects are adopted in a implemented. way through which the Sequence Diagram can represent the Use Cases serves as functional specifications of software model with these three layers (boundary, control requirements in Object-Oriented paradigm and the Analysis and entities). Model is created based on them. Use Cases provide the Sequence Diagram is the second most important diagram external behavior expected by the system with respect to the of an Analysis Model and it is used to illustrate how objects vocabulary in a Domain Model. Rosenberg [2] states that interact with one another through messages, demonstrating Use Cases describes a way by which the users interacts with the internal behavior of one system functionality (one Use the system and how the system responds. Pressman [5] notes Case). that Use Cases does not tell how a system should realize the The sequence of messages in a Sequence Diagram can functionality. This emphasizes the importance of modeling. use a pattern of communication between the objects, how, According to Larman [6], Use Cases can be essential or for example, the pattern presented by Heinemann and concrete. Essential Use Cases do not consider mechanism Denham [10], where messages should follow the flow details (like User Interfaces), while Concrete Use Cases “boundary control entity”. This pattern is adopted consider them. In this paper, only Concrete Use Cases are in this work. contemplated. Yet, according to Rosenberg [2], Use Cases should be C. MDD and MDA written in the objects model context, referencing domain Model Driven Development (MDD) refers to the classes and boundary classes by their names. This approaches based on models as the main products of a recommendation is the base for this work as the objects development [11]. According to Milicev [12], MDD raises constituents of the Analysis Model are the objects referenced the level of abstraction in a development. in the Use Cases and existing in the Domain Model. Model Driven Architecture (MDA) is a MDD approach Use Cases makes explicit not only the objects involved in proposed by the Object Management Group (OMG) whose the system boundary but also the actors participating in the objective is to alleviate the problem of ruptures between functionality and their actions. An actor is any entity that design and code due to system migration from one platform communicates with the system and is external to it, and may to another [11]. be a device, a system or a person. A main actor is that which MDA advocates four layers of model: Computation interacts with the system in order to produce the result while Independent Model (CIM), Platform Independent Model secondary actors only support the system [5]. (PIM), Platform Specific Model (PSM) and Implementation B. Analysis Model Specific Model (ISM) as shown in Figure 1. In the CIM layer there lies the process models and Modeling is generally done in two levels of abstraction: requirements that are independent of computing. In the PIM Analysis Model and Design. layer there lies the Analysis Model which is in the The Analysis Model - or Software Architectural Design - computing field, therefore totally independent of platform. In is used to identify, in a high level of abstraction, the the PSM layer there lies the lower level models, which takes components of the software, describing how the software is into consideration the platform where the system would be decomposed and organized into components [7]. In the case introduced. Finally, the ISM layer is the layer where the code of Object-Oriented software, these components are Analysis is generated. The development focuses, on the MDA Classes with their attributes and operations. In this paper, a approach, is at a high level of abstraction, that is, in the CIM partial Analysis Model is the expected result of the and PIM layers.