Use Case Diagram

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 use case diagram, 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 [7], a structured-expandable format of a use case 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 use case diagram 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 use case diagram, 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. [5] A use case describes a sequence of actions which will provide something of measurable value to an actor. [5] A Use Case Details or Use Case Narratives describe the process steps inside each use case. 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 Use Case narratives, most templates found have the following details.

There arc several tlpes of commtrnication that may appear on a use case diagraal ThcI ar€ an association between an actor and a use case, a generalization between two actsrs aad a gencnl[r]

In this research, the input of Use Case 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 Use Case diagrams. The Use Case diagram 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 Use Case (Fig. 7) and the target metamodel of Use Case Description (Fig. 8) are created to support the ATL transformation process. Since the metamodel of Use Case Description is not defined as a standard of the OMG, the method how to build the UCD metamodel presented in [9] is adopted in this work.

Consistency between use case and activity diagram were proposed by Shinkawa [10], Sapna et al. [12] and Chanda et al. [13]. Shinkawa [10] specify consistency between use case, activity, sequence and state chart diagram using Colored Petri Net (CPN). He proposes that a use case may have at least an activity diagram [10]. He also defines use case, action and execution occurrences as transitions. While Sapna et al. [12] define elements of use case, activity and sequence diagrams using schema table. But the definitions just limited to elements of use case, actor, activity, message and object. A use case may have an activity diagram [12], each actor in use case diagram is matched to a class in activity diagram [12]. 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 use case and sequence diagram. OCL is used to express the consistency rules. A use case may have different flows of activities or scenarios [8]. A scenario is described by a sequence diagram. Chanda et al. [13] express elements of use case, activity and sequence diagram as CFG. They define an action/ activity in activity diagram as an event of a use case in use case diagram. 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 [1], 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 [2]. Traditionally, model transformations are done for purposes such as code generation, refinement, and refactoring [3]. Currently, there are researches on Model Transformation from Requirement to Use Case diagram, Use Case description to Activity diagram and Use Case 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 Use Case diagram 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 use case diagrams. The user writes a few paragraphs in simple English language to describe the system requirements. Our approach uses NLP techniques to extract use case diagram 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 use case diagram.

D. Kumar describes a domain independent tool, named UML Model Generator from Analysis of Requirements (UMGAR) [14] which generates UML models like the Use Case diagram, 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 [15], 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 use case models and generating the object model in a project. Computer Automated Use Case Diagram Generator (CAUse) [16] is a system that allows users to automatically generate use case 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 use case diagram. The Use Case Driven Development Assistant (UCDA) tool [17] provides automated assistance in developing use case diagrams, writing use case specification documents and developing the analysis class models. The paper[17] 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 [18], 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 [19], authors presented an approach supported by a tool for use cases based requirements engineering.

Xll LIST OF FIGURES FIGURE TITLE Figure 1: Use case diagram of the current system Figure 2: Activity diagram of acquisition and cataloging Figure 3: Activity diagram of loaning library m[r]

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 [11]. However, these modelling languages have different use. For example, Use Case Diagram 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 [11]. Different transformation exists which transform different models into BPMN model [12]-[14].

Figure 4: Use Case Diagram for Administrative module Based on use case 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 use case 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 use case 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 use case, ‘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.

XIII Figure 3.1 Progress Flow of Waterfall Model 17 Figure 4.1 Use case diagram for Cartoon Avenger 20 Mobile Application Figure 4.2 Diagram for Cartoon Avenger Mobile 23 Application Fig[r]

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 use case diagram, sequence diagram and class diagram.

Furthermore, UML diagrams contain graphical representations of nodes and paths. As an example, in Figure 2.1, use case diagram in layer M1 (model) is depicted by the actor, use case 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 [11] attempts to address and detect inconsistencies in UML Models like Class diagram, Use case diagram, Sequence diagram and so on. A survey exploring the impact of model driven software development is given in [12]. 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 use case effectively are concerned to alleviate the complexity. At the beginning, some templates and well- formedness rules [8] were formally defined, using set theory and logic, to ensure the syntactical constraints among use case elements and some guidelines are proposed to be followed. Moreover, the visualization and Aesthetics of the layout of use case diagram apparently increases the readability and understandability, [9] proposed the deterministic layout algorithm to support drawing use case diagram nicely. Whilst, [5] also suggested how to do the use case naming convention in order to communicate the proper semantic of the target system.

LIST OF FINGURE FIGURE TITLE PAGE 2.1 Gantt chart 16 Activity Diagram of for proposed system 22 Use Case diagram for proposed system Use case diagram for employee check status Use case d[r]

xiii LIST OF FIGURES DIAGRAM TITLE 2.1 Track and Trace solution chart 2.2 System Development of Life Cycle of PAGE 8 Agile Methodology 17 3.1 Use case diagram of PMSS 33 3.2 Primary Flow[r]

M. Sarma et al. presented an approach of generating test cases from UML design diagrams. A UML use case diagrams transformed into a graph called use case diagram 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 use case 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 use case node the corresponding SDG was visited and test cases were generated to detect operational faults [10]. 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[11].