The major drawback of the designed software is that it can only keep track of tasks in a banking system. In addition, it stores same types of information for all subdivisions. But the subdivisions are very in their working areas. However, only usecasediagram, class diagram, entity relationship diagram, and relational model are used to represent data and their relationship. The design does not show data flow diagram between source and storage. It tells nothing about the sequence of the tasks or state of the tasks.
In , a structured-expandable format of a usecase has been proposed which is expressed in Z notation because Z language is a formal specification language. Then it is represented visually using an Entity-relationship diagram. The implemented approach would bridge the gap between a formal language, which is mathematical and UML usecasediagram that is visual and used widely to capture requirements. The main goal is when a tool will developed using this approach it will produce a visual representation of a formalized UML usecasediagram, from which automated traceability and verification of the design phase. The z-notation is a mathematical notation, specification language and a model-based notation. Z-specification can serve as a single, reliable, reference point for those who investigate the customer’s need, test results, type errors in much the same way that a compiler checks code in an executable programming language. It cannot be compiled into a running program. And also another main thing is that Z is a way by which a specification can be decomposed into some small pieces called schemes.
In short, user stories are very slim and high-level requirements artifacts. It is a brief explanation of a software functionality from the user‟s perspective.  A usecase describes a sequence of actions which will provide something of measurable value to an actor.  A UseCase Details or UseCase Narratives describe the process steps inside each usecase. The narratives are needed because while it is great to see the features at a glance, no one really understands these process names mean until designers describe the steps in detail. If we told a developer of a library system to build a feature and all we gave them was the name “Issue Books”, they would have to ask questions and/or make lots of assumptions about how the librarian would interact with the system when he wanted to issue books. Those developers who actually read them love these narratives because they save so much time. Although there is no standard template for UseCase narratives, most templates found have the following details.
In this research, the input of UseCase and Class diagrams are created using Visual Paradigm v. 8, that supports UML2 The diagrams created with Visual Paradigm can be exported in XMI-format files (.uml). Moreover, Visual Paradigm provides the feature that supports the insertion of descriptions into UseCase diagrams. The UseCasediagram with inserted descriptions will then be exported in XMI format (usecaseWithDesc.uml), and transformed to the target model (usecaseDesc.uml) with ATL transformation as shown in Fig. 6. A set of mapping rules is defined, together with the source metamodel of UseCase (Fig. 7) and the target metamodel of UseCase Description (Fig. 8) are created to support the ATL transformation process. Since the metamodel of UseCase Description is not defined as a standard of the OMG, the method how to build the UCD metamodel presented in  is adopted in this work.
Consistency between usecase and activity diagram were proposed by Shinkawa , Sapna et al.  and Chanda et al. . Shinkawa  specify consistency between usecase, activity, sequence and state chart diagram using Colored Petri Net (CPN). He proposes that a usecase may have at least an activity diagram . He also defines usecase, action and execution occurrences as transitions. While Sapna et al.  define elements of usecase, activity and sequence diagrams using schema table. But the definitions just limited to elements of usecase, actor, activity, message and object. A usecase may have an activity diagram , each actor in usecasediagram is matched to a class in activity diagram . They define that each object and its messages in sequence diagram correspond to a class and its method in class diagram. They proposed two (2) consistency rules between usecase and sequence diagram. OCL is used to express the consistency rules. A usecase may have different flows of activities or scenarios . A scenario is described by a sequence diagram. Chanda et al.  express elements of usecase, activity and sequence diagram as CFG. They define an action/ activity in activity diagram as an event of a usecase in usecasediagram. The formal syntax of each diagram is then used to reason the rules using CFG.
Model transformation (MT) has become an important concern in Software Engineering , because it is related to system design. Model transformation can be used in many different application scenarios, for instance, to provide interoperability between models of different size and complexity . Traditionally, model transformations are done for purposes such as code generation, refinement, and refactoring . Currently, there are researches on Model Transformation from Requirement to UseCasediagram, UseCase description to Activity diagram and UseCase to Sequence Diagram and many more. However, the research is based on only one specific output and not comprehensive as it should be because it only converts the requirement into one specific Unified Modeling Language (UML) diagram at a time. Transformation model need one important approach, which is the requirement traceability in order to trace the keywords as input before automatically converted into UML diagram. In this paper, we propose an approach and tool to transform the requirement into UML model that are UseCasediagram and Activity diagram since there are still not exist the transformation which is required from requirement into behavioral UML diagram called RETRANS. It is different from the existing program because this tool will convert the requirement into two different UML diagrams at a time which is not provided by the existing tool.. We have also come out with a framework as the main guidance for developing this project.
In this paper, we introduce a new automated structured approach to acquiring, analyze and then transform natural language descriptions into usecase diagrams. The user writes a few paragraphs in simple English language to describe the system requirements. Our approach uses NLP techniques to extract usecasediagram elements via translating the textual specifications to words, these words are categorized into several Parts Of Speech (POS), and then we apply stemming algorithm and a set of syntactic heuristic rules to identify the actors and use cases of the target software system. After the compound analysis and extraction of associated information, the designed system draws the desired usecasediagram.
D. Kumar describes a domain independent tool, named UML Model Generator from Analysis of Requirements (UMGAR)  which generates UML models like the UseCasediagram, Analysis class model, collaboration diagram and design class model from natural language requirements using efficient NLP tools. This tool implements a set of syntactic reconstruction rules to process complex requirements into simple requirements. It also provides a generic XMI parser to generate XMI files for visualizing the generated models in any UML modeling tool. In the thesis , authors discussed and compared how scenarios, scripts and use cases are used in different methods used to capture the functionality of a system. They developed a tool which serves as an aid in administrating the usecase models and generating the object model in a project. Computer Automated UseCaseDiagram Generator (CAUse)  is a system that allows users to automatically generate usecase diagrams from English document specifications that can be used for requirements management for business applications. In this paper, the concept of NLP is being used through which the input specifications document is processed to derive potential actors, use cases, and relationships, thereby generating a usecasediagram. The UseCase Driven Development Assistant (UCDA) tool  provides automated assistance in developing usecase diagrams, writing usecase specification documents and developing the analysis class models. The paper introduces the UCDA tool and its application in OMCP (Object Model Creation Process). The process of automation is illustrated in a case study of an ATM System. In the paper , authors discussed the proposed methodology which forms the basis of the automated process designed to capture the high level system services and actors from the textual user requirements. The authors illustrated the applicability of methodology on an order invoicing case study and demonstrated it with a prototype tool. In the paper , authors presented an approach supported by a tool for use cases based requirements engineering.
Software development based on models rather than code can raise abstraction level, because it allows analysts or developers to deal with complex problems within the application domain . However, these modelling languages have different use. For example, UseCaseDiagram is used to model user requirements and BPMN diagrams are used to model organization process. Sometimes we need both models to get the required result. Having a transition method which transforms one model to another can benefit a lot to system analyst, designers and requirements elicitation team. Transforming models depending upon particular steps or programs is called transformation. Transformation creates the correspondence between source model elements to the target model elements of a certain model language . Different transformation exists which transform different models into BPMN model -.
Figure 4: UseCaseDiagram for Administrative module Based on usecase in Figure 4, when a mobile user triggers something on the mobile phone app with the intention to report on a landslide incident, the mobile app communicates with the web-based system by sending an alert (report) with information such as geographical coordinates of the mobile user and pictures of the incident. Send report usecase includes determine location and alert agency use cases in that the web-based system will then determine the location of the mobile user and alert the nearest agency. The alert agency includes determine nearest agency usecase as it is needed to determine the nearest agency to the location before alerting the agency. The agency receives the report and dispatch teams to the site, which is beyond the scope of this project. The report is also stored in this web-based system and this function is captured as an inclusion usecase, ‘store report’ in the diagram above, which can be retrieved to be viewed by the admin. The web-based system includes a real-time monitoring board feature which allows the admin to the incoming alerts (reports). The admin can generate system report for analysis, weekly, monthly or quarterly, usually in a table format.
Figure above shows the general process about the agile software development model used for this application. There are seven phases in this methodology. The first phase is planning, whereby plan about what project is going to do. After that, requirement is collected in the second phase. In this phase, interview and questionnaire are done and identify the functional and non-functional requirement. In analysis and design phase, requirements are analysed and are translated into high- level detailed design such as usecasediagram, sequence diagram and class diagram.
Furthermore, UML diagrams contain graphical representations of nodes and paths. As an example, in Figure 2.1, usecasediagram in layer M1 (model) is depicted by the actor, usecase and include graphic nodes. Each graphic node has its notation; for example, notation for the actor is an icon of a stick man with its name. The nodes and paths represent UML elements in the metamodel layer (M1). In the metamodel layer, the UML modelling elements, their attributes, relationships, as well as their rules and constraints are defined in UML standard (Object Management Group (OMG), 2011b) in the form of abstract syntax. In the standard, each of the UML elements in the abstract syntax is also given added descriptions as mention in constraints, semantics and notations sections. The constraints of UML elements as described in abstract syntax and constraints sections are well-formedness rules that apply to the elements (Object Management Group (OMG), 2011b). They are important to be satisfied within a single UML diagram as they impact the completeness of the UML model (Christian F. J. Lange & Chaudron, 2004). However, the constraints in constraint section in the UML standard are specified in natural language and some of them are specified using Object Constraint Language (OCL).
inconsistencies in few UML Models. The work proposed in  attempts to address and detect inconsistencies in UML Models like Class diagram, Usecasediagram, Sequence diagram and so on. A survey exploring the impact of model driven software development is given in . Change in impact analysis, consistency management and uncertainty management, inconsistency detection and resolution rules are dealt in the work.
However, several best practices on how to draw the quality UML usecase effectively are concerned to alleviate the complexity. At the beginning, some templates and well- formedness rules  were formally defined, using set theory and logic, to ensure the syntactical constraints among usecase elements and some guidelines are proposed to be followed. Moreover, the visualization and Aesthetics of the layout of usecasediagram apparently increases the readability and understandability,  proposed the deterministic layout algorithm to support drawing usecasediagram nicely. Whilst,  also suggested how to do the usecase naming convention in order to communicate the proper semantic of the target system.
M. Sarma et al. presented an approach of generating test cases from UML design diagrams. A UML usecase diagrams transformed into a graph called usecasediagram graph (UDG) and sequence diagram into a graph called the sequence diagram graph (SDG) and then integrating UDG and SDG to form the System Testing Graph (STG). The STG is then traversed to generate test cases for system testing. They have used state-based transition path coverage criteria for test case generation. Having stored all essential information for test generation in the STG, they now traverse the STG to generate test cases. The Test Suite Generation algorithm, traverse the STG at 2 levels. The traversal begins with the UDG. This traversal visits all use cases and generate test cases for detecting initialization faults. At level 1, if a usecase initialization faults occur then it was assume faults in its operation and therefore no need to apply test cases corresponding to the operation. At level 2 traversal, starting from a usecase node the corresponding SDG was visited and test cases were generated to detect operational faults . Chen et al. proposed a technique in which they use UML activity diagrams as design specifications, and consider the automatic approach to test case generation. Instead of deriving test cases from the UML activity diagram directly, they presented an indirect approach which selects the test cases from the set of the randomly generated test case according to a given activity diagram. In this method, they first randomly generate abundant random test cases. Then, by running the program with these test cases, they will get the corresponding program execution traces. Last, by comparing these traces with the activity diagram according to the specific coverage criteria, they can prune some redundant test cases and get a reduced test case set which meets the test adequacy criteria.