CHAPTER 6 IMPLEMENTATION OF THE EVENT-BASED FRAMEWORK

Transcription

1 CHAPTER 6 IMPLEMENTATION OF THE EVENT-BASED FRAMEWORK 6.1 INTRODUCTION This chapter discusses the implementation of our proposed Event-based Framework for OOA of requirements, computation of complexity metrics and generation of test scenarios and test cases. The entire Event-based Framework is implemented in five parts. First part deals with Event extraction which helps an analyst to extracts events from requirements described in English as natural language. Second part deals with formalization of events which can help to document details of extracted events in Event Templates. Third part deals with class diagram generation by which an analyst can generate class diagram specification from Event Templates. Fourth part deals with computation of system complexity that helps an analyst to automatically construct a matrix-based Event-Flow Model from Event Templates and computes system complexity based on the metric proposed in Chapter 4 and the last part helps to automatically generate Test Scenarios and Test cases from a graph-based Event-Flow Model as discussed in Chapter 5. The automation of the entire Event-based Framework reduces the time and complexity associated with each part. 6.2 TOOL ARCHITECTURE Tool Architecture as shown in Figure 6.1 has four core units - Event Extraction, Event Formalization and Validation, Class Diagram Generation and Metrics & Test Scenario Generation. Input for the tool is textual software requirements. Software requirements are given as input to Event Extraction unit. This unit has an Event Extraction module which extracts n events like Event 1 Event 10 Event n. Each event is then transformed into a subject-verb-object pattern like <E id,s,v,o> 1 <E id,s,v,o> 10 <E id,s,v,o> n. These event patterns are stored in an XML file. Second unit is Event Formalization and Validation which has two modules: Event Template Generator and Template Validator. Event Template Generator module takes an XML file containing event patterns as input and generates event templates for each pattern like ET 1.ET 10...ET n. Template Validator module validates each template using XML schema designed for event template validation. Template Validator module produces validated event templates like VET 1 VET 10..VET n, all of which are stored in one XML file. Third unit is Class Diagram Generation which has a single 133

2 module: Class Diagram Specification Generator that takes mapping rules: R 1.R 4..R 11..R n, an Argo UML Specification and an XML file containing Validated event templates and generates an XMI based Class Diagram specification. Last unit is Metrics and Test Scenario Generation which has three modules: Event-Flow Model Generator, Complexity Metrics Generator and Test Scenario Generator. An XML file containing validated event templates is input to an Event-Flow Model Generator that generates matrix-based and graph-based models. Trigger Vector Matrix and Causative Events Matrix are matrix-based models whereas an Event-Flow Graph is a graph-based model. Complexity Metrics Generator module takes both the matrices as input and generates complexity metrics like to C tv, C ce, C e, C system_abs, C system_rel. Test Scenario Generator module takes an eventflow graph as input and generates event sequence based Test Scenarios and Test Cases. 6.3 A WALKTHROUGH OF THE PROTOTYPE TOOL When the prototype tool is invoked a user gets tabbed window as shown in Figure 6.2 with the following options: a) To extract events from requirements b) To document extracted events in a validated xml file c) To derive specification for an analysis-level class diagram d) To compute complexity of the entire system at an analysis level e) To generate test scenarios and test cases from events Event Extraction Event Extractor module is a domain independent module that automates the process of identification, extraction, analysis and categorization of events. It uses a Subject, Verb and Object (SVO) pattern to extract and formalize events from textual requirements expressed in English as a natural language. Subject-verb-object pattern identifies an event in a sentence. E.g. events in a typical order processing system are, Customer places order, Sales Manager denies credit request, Marketing Department changes prices. It also gives users option to analyze, classify and refine the list of automatically extracted events. Users can further add new events that are not explicit in requirements. The module takes input as natural language textual requirements written in English and gives output in a textual format as shown in Figure

3 Figure 6.1: Tool Architecture of an Event based Framework 135

4 Figure 6.2: First GUI Screen of Prototype Tool Figure 6.3: Event Extractor Module Figure 6.3 shows the GUI window of the module with two frames. Upper frame is to type or copy-paste requirement specifications from which events have to be extracted. There is a Produce Output button which on clicking generates event list in the lower frame. In the event list, word outside parenthesis 136

5 represents an event while arguments of events are represented inside parenthesis. Arguments of an event represent subject, object and context information of an event. The contextual information can be about the time, place or any other context. The contextual information about the time of an event indicated by the tense of tagged verb is preserved (i.e. not changed) and is given with the output. This makes the extraction result of our module more informative in comparison to other existing event extraction tools. This module uses Stanford s Part of Speech (POS) tagger to generate tagged output. 17 Parsing rules are implemented in [283] and are applied on the output of the POS tagger to extract list of SVO patterns (Events) from the textual requirements in an XML format. All events extracted are automatically given an event id and stored in the XML file as shown in Figure 6.4. Output of the module in XML format shows list of events embedded in Event_list root tag. Inside the root tag a triplet of <Subject, Verb, Object> is specified as child elements. Once the list of Events and their types is finalized, then it is passed on to Event Formalization and Validation module. Figure 6.4: Output of Event Extractor module in XML format In order to evaluate the performance of the module, two coverage metrics are also proposed. Results obtained after applying the module on case studies taken from different domains are shown in Appendix- A. These metrics compare events generated by the module with events extracted manually by experts from case studies. Following variables are used to compute these metrics: NET: Total Number of events extracted by module NEE: Total Number of events extracted by Domain Experts 137

6 NCET: Number of correct events extracted by module (i)coverage metric is defined as the percentage of total number of events extracted by the module over total number of events manually extracted by experts. We assume manual extraction of events by domain experts is the best error free extraction Coverage Metric= (NET / NEE)*.01 All events extracted by the module may be not correct or perfect. Some of them may be rejected by domain experts. The module gives the option to reject or accept events, add new events or refine existing events. So, in order to measure the accuracy of the module, there is a Coverage Accuracy Metric. (ii)coverage Accuracy metric is defined as the percentage of correct events extracted by the module over total number of events extracted by the module. Coverage Accuracy Metric= (NCET / NET)*.01 The algorithm that has implemented parsing rules for event extraction has linear time complexity as it takes one sentence at a time for processing. Its complexity is O (P+S+W), where P = No. of sentences in a paragraph, S = No. of words in a sentence and W = No. of characters in a word Event Formalization and Validation Event patterns in an XML file are documented by Event Template Generator and then all Event templates are validated by Template Validator. This module uses Event Template described in Chapter 2 to document events and store the output in an XML file. It merges all XML files corresponding to different event templates in one single file and passes it to Template Validator. Each event template in an XML file is validated using an XML schema. Complete XML schema is shown in Appendix-B. One of the event template in an XML format is given below. - <et> <Event_ID>EA04</Event_ID> <Event_Name>register customer</event_name> <Event_Description>Customer registers with TA software</event_description> <Causative_Event>EA02</Causative_Event> <Timestamp>TA3</Timestamp> <Initiator_Count>0</Initiator_Count> 138

7 - <facilitator> <name>ta_software</name> <cardinality>cardinality</cardinality> </facilitator> <Facilitator_Count>1</Facilitator_Count> - <affector> <name>customer</name> <cardinality>cardinality</cardinality> </affector> <Affector_Count>1</Affector_Count> <input /> <triggervector /> - <ce> <changeevent>creation event of customer_profile</changeevent> <input>customer_name, ID, , phone_number, password</input> <output>outputs1</output> </ce> <ChangeEvent_Count>1</ChangeEvent_Count> </et> Figure 6.5: Event Template Generator Figure 6.5 shows the screen dump of Event Template Generator. It shows three textboxes where a user can enter an event id, an event name and an event description. A validation is applied on an event id that 139

8 it must begin with EA. An event name and an event description should not be null. The next three labels correspond to an initiator, a facilitator and an affecter. Each of these can be more than one, so a count is maintained corresponding to each of them to facilitate easy implementation of rules described in Chapter 3. The add textbox label generates a new textbox in order to accommodate proper number of initiators, facilitators and affecters. An appropriate type of timestamp can be selected with the help of a radio button. The validation in this case is that if a fixed type is selected, then value FD appears automatically in a dropdown list. If a variable type is selected, then a user is requested to enter value of a timestamp. The next textbox corresponds to causative events where a user is required to enter an expression. A validation is done to make sure that an expression must be composed of events related by one of the following operators and, or, not, xor, fork, or-join and xor-join. Each event must be related to at least one operator and each operator must have proper number of operands. For example and, or, xor should have more than 2 operands while not should have only one operand. The entire expression must be formatted properly with braces. When a user enters an expression all the above conditions are checked using a stack based algorithm. The hyperlink in front of each label generates a text box to read the corresponding input value at runtime. At the bottom of the GUI three buttons are labeled as (a) SUBMIT: On clicking the submit button the module generates an XML file for the event template. (b) RESET: resets all the input fields. (c) GENERATE: On clicking the generate button Class Diagram Generator module will be called to apply mapping rules on an XML file and generates an XMI based specification for an Argo UML tool Class Diagram Generation Class Diagram Specification generator module takes validated Event Templates generated in an XML file by the Event formalization and Validation unit. It applies mapping rules described in Chapter 3 to generate an importable XML class diagram specification in an XMI format for an Argo UML tool. On importing an XMI file containing class diagram model information, Argo UML tool shows the entire model information (class names, associations, generalization, operations and attributes) as a tree like structure as shown in Figure 6.6. One can expand and collapse tree branches to see different classes, their attributes, operations and relationships extracted from event templates by mapping rules Metric Computation An Event-flow model generator automatically generates matrix-based models in the form of Event Interdependency Matrices from validated Event Templates generated in an XML file by the Event 140

9 Figure 6.6: Class diagram Specification in Argo UML Figure 6.7: Loading an XML File of Event Templates 141

10 formalization and Validation module. Complexity metric generator module computes the metric suite to measure the complexity of an entire system. The module enables a user to load an external XML file of Event templates generated by Event Template Generator Module. Loading of an XML file is shown in Figure 6.7. The module then converts an XML file in the form of a Tree View for display and automatically generates both the Event Interdependency Matrices (the Trigger and Causative Matrix ) and computes the event complexity, absolute and relative complexity of an entire system from events present in the corresponding event template file. It uses the Xpath Class (System.Xml.XPath ) and its methods to navigate through a loaded XML event File and displays events data using the Tree View Control component of Microsoft.NET. This Method is called when a user clicks on the Load Events button in Figure 6.8. Figure 6.8: Loading of Events from an XML File of Event Templates in a Tree View This module calls the 'trigger_matrix_compute() ' method when Load Events button is clicked. This method uses the Xpath navigator of the Xpath Class (System.Xml.XPath ) to navigate through a loaded 142

11 XML File. It assigns a numeric value in each cell of a matrix depending on type of relation between different events as specified in Chapter 4. When Display button is clicked, change_matrix_trigger(string rel_type,int cur_event,int teventid)' and 'change_matrix_causative(string rel_type, int cur_event, int teventid)' methods are called to assign numeric values based on the type of dependency i.e. - OR, AND,XOR etc. Depending on the value of the radio button selected either a trigger matrix or a causative matrix is displayed in a Data Grid Control as shown in Figure 6.9 using the Mommo.Data Class. Figure 6.9: Computation of Trigger Vector and Causative Matrix from Event Templates When a compute matrix button is clicked as shown in Figure 6.10, compute_complexity() method is called to compute the complexity (Absolute and relative) of a system. This method also displays the C tv and C cv values for each event using a data grid. These values are calculated by method calls 'calc_ctv(int i) and 'calc_cce(int i)' to compute the complexity of each event as described in Chapter

12 Figure 6.10: Computation of Metric Suite for measuring the System Complexity Test Scenario Generation An Event-flow model generator automatically generates an Event-Flow Graph from validated Event Templates generated in an XML file by the Event formalization and Validation unit. Test Scenario generator module then computes test scenarios for functional testing of a system. Module is also able to incorporate requirement changes in an Event-Flow model and regenerate a modified Event-flow model from which all the changed test scenarios are identified. This module uses Graphviz (short for Graph Visualization Software), a package of open source tools initiated by AT&T Research Labs for drawing graphs specified in DOT language scripts. The module also uses QuickGraph, a library containing generic graph data structures and algorithms. The module enables user to load an external XML file of Event templates generated by Event Template Generator Module. The module generates an Event-Flow Graph of the events, calculates all possible paths between start and end node and gives an option to zoom and rotate the graph for easy viewing as well as save the generated graph as an Image. Figure 6.11 and Figure 6.12 shows the snapshots of this module. As shown in Figure 6.8 above, a user first loads an 144

13 XML file containing all event templates. As shown in Figure 6.11, a method to compute paths and graph Image is called, when a user clicks Compute Paths or Graph Image button. This Method creates a dynamic Event Flow Graph in a system s memory using the 'Quickgraph' Library. Figure 6.11: Compute Paths and Image of an Event Flow Graph Vertices and edges are added to the graph depending on the type of dependency between events. Once a graph is created, paths are then calculated by using algorithm described in Chapter 5 between the start and the end node of a graph such that all nodes of a graph are covered at least once. These paths are then displayed. Also a graph made in the memory is converted to a 'graph.dot' file and this 'graph.dot' file is displayed using Graphviz. This method also converts a 'graph.dot' file into a Jpeg image to display the image as shown in Figure

14 Figure 6.12: Converting Event-flow Graph into JPEG Image 6.4 SUMMARY The proposed Event-Based framework for OOA, computation of metrics and generation of Test Scenarios is automated and successfully implemented to address all the issues described in Chapter 1. The architecture of the prototype tool is described and then module wise walkthrough of the entire tool is presented. This implementation is an attempt to reduce the time and effort on the part of a user who will use this prototype tool for analysis, modeling, measuring complexity and testing a system. It reduces time and complexity in the following: a) Extraction of events from requirements. b) Documentation and persistent storage of extracted events. c) Generation of class diagram specification for an analysis-level class diagram from events. d) Computation of metrics to measure analysis level complexity from events. e) Computation of test scenarios from events. In the next chapter, we will discuss the review of main results, contributions of this thesis and scope for further research work. 146

15 CHAPTER 7 CONCLUSION AND SCOPE FOR FUTURE WORK 7.1 CONCLUSION In chapter 1, several reasons were cited that lead to software failures. Amongst those several findings, survey results were shown on three main factors: Requirement Analysis, Complexity and Testing. It is clear from those surveys that inadequate planning and specifications, ill defined requirements, poor process of requirement analysis and testing, lack of metrics and measures to compute project s sheer size and complexity, all together lead to numerous change requests, delays, significant added costs and increase in the possibility of errors. Thus a good requirement analysis method, proper management of software complexity and proper testing techniques play a vital role in avoiding software failures. This has been the motivation of the work carried out in this thesis. In this work, events are not only be used to propose an improvised requirements analysis method over the existing event-based approaches for OOA but they are also used for measuring complexity of a system and generating test scenarios for functional testing of a system. For this, an event-based framework is proposed and implemented for requirement analysis, modeling, testing and support (tool) activities of software development. This thesis work has demonstrated the applicability of improvised event-based approach for OOA of requirements, use of events to generate standardized Class diagram specification based on XMI standard, develop software metrics to measure complexity of a system at the analysis phase of SDLC and generate Test cases and Test Scenarios for testing functional requirements of a system. To develop such a framework, several issues were identified and contributions were made to resolve those issues. The issues and contributions are presented below: a. To address the issue to identify, describe and document events from textual requirements for analysis of requirements and extract information to build conceptual models (class diagram specification) from requirements specifications following contributions were made in this thesis: An Event-based framework is designed to integrate OOA, conceptual modeling, computation of system complexity and testing. An Event-Meta Model was proposed for Object-Oriented analysis. 147

16 A methodology was defined to derive Class diagram specification from requirements and its empirical validation was carried out through a controlled experiment and its replication. b. To address the issue to determine the complexity of systems at an analysis level, a metric is proposed to compute system complexity from requirement specification using event flows and event interdependencies. Based on the results of the proposed metrics necessary changes can be made to reduce cost of developing such systems or avoid software failures, prior to design and implementation,. c. To address the issue to generate test scenarios and test cases for testing functional requirements, to model changes in requirements and perform re-testing of the system after incorporating those changes, a methodology is proposed to (a) generate event sequence-based test scenarios and test cases from an Event-flow model (b) specify and model changes in software requirements either in terms of addition and/or modification of events or event interdependencies (c) apply a safe and efficient regression test selection technique on an event-flow model, so as to select tests from test scenario that are deemed necessary to validate a modified software. d. To address the issue of automation for the entire Event-Based Framework for Object-Oriented Analysis, Computation of Metrics and Identification of Test Scenarios and Test Cases, a prototype tool is developed to implement the entire event-based framework that provides automation support to extract events from requirements, document extracted events, derive specification for an analysis-level class diagram, automatically compute complexity of a system at an analysis level and generate test scenarios and test cases from events. 7.2 APPLICATIONS OF EVENT-BASED FRAMEWORK OOA of requirements, computation of complexity and testing of event-based systems can be carried out using the proposed work. The proposed Event-based OOA approach can also be used for requirements analysis of distributed applications in which events play a major role in co-ordination and integration between applications on the basis of certain preconditions [168, 169]. Some of the examples of Eventdriven systems where the proposed work can be used are as follows: Data ware houses, Batch processes, Hardware products with embedded control software; 148

17 Computationally intensive applications driven by interaction of highly complex business rules like calculating fare for a specific flight itinerary; Real Time and Embedded Systems [170] that involve both hardware and software components like complex highway intersection system that includes sensors in a road to detect cars, traffic signals; A time triggered function in a public library information system that automatically sends an e- mail to remind borrower when an item borrowed is due back soon; A race car simulators in shopping malls where a customer is a driver in a computer controlled simulated race. Events flow across networks between these systems. These systems react to events they receive and issue new events that are sent to other components. All such systems respond to events depending on the state of a system at the time when events are detected. Events could be signals received from sensors, time-based triggers (such as scheduled program executions), or user actions that cause a system to respond in some way. For instance, in case of car simulators, pressing an accelerator and a break pedal, turning a steering wheel and shifting gears, are events. In the same way, a highway intersection system has to ideal with various events like a sensor detects a car approaching in one of the through lanes, a sensor detects a car approaching in a left turn lane, a pedestrian presses a button to request to cross a street, or one of many timers counts down to zero. In response to these events, a highway intersection system might intimate a timer to prepare to change light from green to amber and then to red. The system might activate a walk sign for a pedestrian (if the sign currently reads Don t Walk), or change it to a flashing Don t Walk (if sign currently says Walk), or change it to a solid Don t Walk (if it is currently flashing). Unlike typical business applications where long descriptive and narrative text is needed to understand behavior of a system, functionality of these event driven systems is understood on the basis of events, their flows and interdependencies. The proposed approach can also be used at undergraduate and post-graduate level, as a new approach of OO modeling for students as well as teachers / instructors. 7.3 FUTURE WORK Research work presented in this thesis can be extended along the following lines: 149

18 1. Events described in chapter 2 are not modeled in UML as entity. So work can be done in future to provide UML extension to (a) incorporate the Event Meta model and Event Template and give event-based perspective to system analysis and design (b) provide a plug-in for various commercial tools to support Event based modeling with UML. 2. The empirical study conducted in chapter 3 has focused on users perceptions on usefulness and ease of use and not on model quality in terms of structural complexity or efforts needed to develop a conceptual model. In future, controlled experiment can be replicated for measuring the quality of class diagram and efforts needed in generating class diagram using the proposed eventbased technique vis-à-vis other conventional techniques. 3. In chapter 3, class diagram specification is generated from event templates; work can be extended to (a) derive other UML diagrams from Event templates. Dynamic behaviour of a system is extracted from event templates based on Trigger Vector and Causative events. In future, temporal relationship among events, extracted from timestamp field of an event template, can be used for the same purpose. 4. In chapter 3, class diagram specification is generated specifically for Argo UML tool and it can be extended to generate class diagrams for other commercial tools like Rational Rose, Visual Paradigm and Enterprise Architecture. 5. Work described in chapter 4 can be extended to explore Numerical Design Structured Matrices to frame design rules in order to analyze and evaluate the architecture of event based systems on the basis of event interdependencies. These design rules can then be applied to identify acceptable event interdependencies. 6. Metric suite developed in chapter 4 for analysis level complexity can be extended to include metrics that can measure a system complexity at other stages of a project life cycle. The proposed Event-flow complexity metric can be integrated with other existing metrics in order to 150

19 increase the correctness of complexity measured. The actual complexity of implementing individual events can also be calculated and used in conjunction with the Event-Flow Complexity metric. 7. Work presented in chapter 5 can be extended to generate test cases for testing individual events present in test scenarios. For this, an event template proposed in this thesis can be annotated with the necessary data needed for testing execution of individual events. 8. Algorithm described in chapter 5 to generate Test Scenarios can be optimized using genetic and evolutionary algorithms to handle very large set of events and event interdependencies. 9. The prototype tool described in chapter 6 to implement the entire Event-based framework can be made web-enabled to work in multi-user environment. 10. Work can also be done to develop domain independent event specification language for OOA that can itself describe requirements of different domains in terms of events and event templates. 151