Designing and Developing a Web application to automate the configuration of «Stream Gateway test tool»

Transcription

1 Tunisian republic Ministry of higher education and scientific research Tunis El Manar university Higher Institute of Computing End-of-studies traineeship report Presented to obtain National Engineering Degree in Applied Science and Technology. Speciality : Software Engineering and Information Systems By Yahya HARRATHI Designing and Developing a Web application to automate the configuration of «Stream Gateway test tool» Professional supervisor: Academic supervisor: Mr. Badis BARBOUCH Mrs. Imen BEN HFAIEDH Engineer Professor Realized within FIS University year

2

3 Tunisian republic Ministry of higher education and scientific research Tunis El Manar university Higher Institute of Computing End-of-studies traineeship report Presented to obtain National Engineering Degree in Applied Science and Technology. Spécialité : Software Engineering and Information Systems By Yahya HARRATHI Designing and Developing a Web application to automate the configuration of «Stream Gateway test tool» Professional supervisor: Academic supervisor: Mr. Badis BARBOUCH Mrs. Imen BEN HFAIEDH Engineer Professor Realized within FIS University year

4 I authorize the student to deposit his traineeship report. Professional supervisor, Mr. Badis BARBOUCH Signature I authorize the student to deposit his traineeship report. Academic supervisor, Mrs. Imen BEN HFAIEDH Signature

5 Dedications I dedicate this work To my mother, as a testimony of my affection and my gratitude for all her sacrifices. She is the one who believes in me and stands on my side whatever the situation is. To my father, whose precious pieces of advice and whose encouragements would always be my sources of guidance and hope. To all my friends, With whom I shared unforgettable moments. Yahya HARRATHI ii

6 Acknowledgement At the end of this traineeship, I would like to express my deepest gratitude to everyone who has contributed, from near or far, with the outcome of this work, in particular: My supervisor at the company Mr. Badis BARBOUCH, for encouraging me to do a correct and efficient work. His infinite help and his great efforts have provided me with the perfect environment to complete my work. My supervisor at the Higher Institute of Computer Mrs. Imane BEN HFAIEDH, for the advice and assistance she provided me in carrying out this work. The jury members, for evaluating my work with their wisdom and knowledge. And I would like to thank everyone who has contributed in one way or another to the smooth conduct of my traineeship. iii

7 Contents General introduction 1 1 General overview Company presentation Company overview FIS Financial Systems Existing applications State of the art Stream Gateway application Stream Gateway test tool Configuring Stream Gateway test tool Criticizing the existing Proposed solution Adopted methodology Project management methodologies Waterfall project management Agile project management Agile vs Waterfall Scrum Scrum roles Scrum artifacts Requirements specification Functional requirements Non functional requirements Product backlog Sprints planning Gant diagram Global use case diagram iv

8 2.7 Global class diagram Release Sprint: Manage scenario template Sprint backlog Use cases description Description of the use case «Create a scenario template» Detailed diagram of the use case «Create a scenario template» Description of the use case «Update a scenario template» Detailed diagram of the use case «Update a scenario template» Design System sequence diagram Design class diagram of sprint : Manage scenario template UI interfaces UI interface of the use case «Create a scenario template» UI interface of the use case «Update a scenario template» Sprint: Generate playlist Sprint backlog Use cases description Description of the use case «Generate a scenario» Detailed diagram of the use case «Generate a playlist» Design System sequence diagram Design class diagram of sprint : Generate playlist UI interfaces UI interface of the use case «Generate a playlist» Release Sprint: Manage Stream Gateway test tool Sprint backlog Use cases description Description of use case «Configure Stream Gateway test tool».. 42 v

9 Detailed diagram of the use case «Configure Stream Gateway test tool» Description of use case «Run Stream Gateway test tool» Detailed diagram of the use case «Run Stream Gateway test tool» Design System sequence diagram Design class diagram of sprint : Manage Stream Gateway test tool UI interfaces UI interface of the use case «Configure Stream Gateway test tool» UI interface of the use case «Run Stream Gateway test tool» Closure phase Environment Material Environment IDE and Programming languages IDE Programming languages Application architecture Navigation schema System architecture Presentation layer Controller Layer service layer Application documentation Users documentation Developers documentation General conclusion 59 Bibliography 60 vi

10 List of Figures 1.1 Enterprise Logo Enterprise Financial Technologies(EFT) Work Teams Stream Gateway messages Actual process for testing Stream Gateway application Model of the proposed solution General Overview of Scrum framework Sprints planning Gant diagram Global use case diagram Global class diagram Detailed diagram of the use case «Create a scenario template» Detailed diagram of the use case «Update a scenario template» Sequence diagram of the use case«create a scenario template» Sequence diagram of the use case «Update a scenario template» Design class diagram of sprint : Manage scenario template UI interface for uploading a log file UI interface for displaying scenario messages UI interface for defining variables of messages UI interface for choosing compliances UI interface of the use case «Edit scenario template» Detailed diagram of the use case «Generate a playlist» UI interface of the use case «Generate a scenario» Design class diagram of sprint: Generate playlist UI interface of the use case «Generate a playlist» Detailed diagram of the use case «Configure Stream Gateway test tool» Detailed diagram of the use case «Run Stream Gateway test tool» System sequence diagram of the use case «Configure Stream Gateway test tool» vii

11 4.4 System sequence diagram of the use case «Run Stream Gateway test tool» Design class diagram of sprint : Manage Stream Gateway test tool Configure Stream Gateway test tool UI interface Run Stream Gateway test tool UI interface Spring STS logo Postman logo Visual Studio code logo StarUML logo Java logo JavaScript logo HTML5 logo LESS logo User navigation schema SGW CAT architecture Spring MVC architecture Table of contents for User documentation Table of contents for Developer documentation viii

12 List of Tables 1.1 Agile vs waterfall Product Backlog Backlog of sprint: Manage scenario template Description of the use case «Create a scenario template» Description of the use case «Update a scenario template» Backlog of sprint: Generate playlist Description of the use case «Generate a scenario playlist» Backlog of sprint: Manage Stream Gateway test tool Description of the use case «Configure Stream Gateway test tool» Description of the use case «Run Stream Gateway test tool» Material environment ix

13 List of Abbreviations CAT = Configuration Automation Tool DAO = Data Access Object FIX = Financial Information exchange FIXML = Financial Information exchange extensible Markup Language JEE = Java Entreprise Edition JSON = JavaScript Object Notation QA = Quality Assurance REST = REpresentational State Transfer RUF = Rresponsive UI Framework SGW = Stream GateWay x

14 General introduction The competitive environment that companies face today leads them to use new technologies in order to attract new customers by providing them with fast and efficient services. The effective use of these technologies is strategic. It concerns any organization regardless of its size and area of activity, given that the robustness of the information system is a determining factor in the evaluation of companies. FIS Company is an international provider of financial services technology and outsourcing services which provides innovative and efficient solutions to meet the needs of the banking market. It is within this context that our end-of-study project was done. It consists of designing and developing a Web application to automate the configuration of a test tool used by Quality assurance (QA) teams. The application was developed with Spring Boot and AngularJS Frameworks. This report contains five chapters: The first chapter «preliminary study» Is a general presentation of the project in which we present the organization And introduce the context of the project. The second chapter «requirements Specification» identifies the features of our solution. It contains the definition of all the functional and not functional requirements relative to the functioning of the system. It contains also the product and sprints backlogs, besides to the global use case diagram. The third chapter «Release 1» and the fourth chapter «Release 2» form the core of our report. These two chapters are devoted to the development of the two releases of our system while respecting the fundamental principles of Scrum. The final chapter «Closing phase» details all the tools used for the design and development of our application as well as the system architecture. 1

15 Chapter 1 General overview 1 Company presentation Existing applications Adopted methodology

16 Chapter 1. General overview Introduction Within this chapter we introduce the general context of the project. First, we expose a study of some existing processes to understand the problem and then present the proposed solution. Finally, we argue our choice of the adopted methodology for managing the product development life cycle. 1.1 Company presentation Company overview Figure 1.1: Enterprise Logo. This work is performed within FIS Tunisia (Figure 1.1). It is a multinational company ranked among the world s leading software and technology services companies. The latter has more than 55,000 employees and serves 25,000 customers in 70 countries, including the world s 25 largest financial services companies.[1] This company also provides disaster recovery services, managed IT services, information availability consulting services and business continuity management software. With annual revenue exceeding 5 billion dollars, FIS is ranked 380 on the Fortune 500 and is the largest privately held business software and IT services company. Based on information compiled by Data monitor, it is the third-largest provider of business applications software after Oracle and SAP. FIS is comprised of three businesses that provide IT services, infrastructure, software and processing solutions: financial systems. higher education. public sector. FIS has leading positions and strong customer relationships within all its businesses. It has also used acquisitions to expand its product line, customer base and geographic footprint, which have contributed significantly to its long-term growth. 3

17 Chapter 1. General overview FIS Financial Systems FIS Financial Systems provides mission-critical software and IT services to institutions in virtually every segment of the financial services industry. In fact FIS s systems account and manage more than 25 trillion dollars in investment assets and process more than five million trades a day. FIS also provides consulting services that focus on implementation and integration of these solutions and on software development. One of the most important groups in FIS financial systems is Enterprise Financial Technologies. This group was formed to create and maintain quality system-based solutions for Financial Services. The Enterprise Financial Technology is ventilated into four sub-teams as shown in the Figure 1.2: Figure 1.2: Enterprise Financial Technologies(EFT) Work Teams. Maintenance Group Maintenance team s function is to make minor fixes and enhancements to the system or application and its components. It is responsible for reviewing the Change Requests. The requests involve in general the modification of the software product after delivery to correct faults, to improve performance or other attributes. Quality Assurance Group QA team works to eliminate mistakes through a process of regulation, including measuring the quality of products, services, production and management components. Its mission is to determinate, verify and assure that the product or the company s specific goals and services exceed the customer s expectations. Our project is destined to this group. Support (Help Desk) Group Support Team is responsible for supporting all financial system issues; Investigating Advanced issues and correcting data problems. 4

18 Chapter 1. General overview R & D Team It is responsible for both search and development, the Search fits the results of basic research needs of EFT or its customers and Development produces prototypes of marketable products or processes. 1.2 Existing applications State of the art In this part, we put the project in its frame and define some basic concepts. Scenario : it is a set of messages, named sample, written in FIXML or FIX format. Each message stored in a file which used by Stream Gateway test tool. A message is identified by its name and a market name. Playlist : it is a set of scenarios. Each playlist is associated with an excel file that describes its scenarios. A playlist is identified by its name and a market name. Compliance : compliance is a set of rules that valid an XML document. It is used by the Stream Gateway test tool to determine if a generated message is valid or not Stream Gateway application The Stream Gateway is an essential component in the FIS post-trade derivatives solution. It is the gateway that is in charge of interfacing all of FIS s post-trade derivatives applications, ClearVision, UBIX and GMI, with the exchange via the exchange provided API. As shown in the Figure 1.3 Stream Gateway application is the middle-ware between client (clearvision) and the market (CCP), and its main inputs and outputs are messages in XML and FIX formats. 5

19 Chapter 1. General overview There are four types of messages which Stream Gateway application uses to communicate with markets and clients: ccp out ccp in downstream out downstream in Figure 1.3: Stream Gateway messages Stream Gateway test tool Stream Gateway test tool is a desktop application used to automate tests for Stream Gateway applications. It is used by many quality engineer teams in Tunisia, India and many other countries to automate running tests for each step of developing and deploying a new feature Configuring Stream Gateway test tool The Figure 1.4 describes the inputs and outputs of Stream Gateway application. In fact, QA engineer configure and prepare inputs for the test tool manually. Figure 1.4: Actual process for testing Stream Gateway application. 6

20 Chapter 1. General overview In order to run a test case in the test tool, the QA needs to: 1. extract scenario from log file which has been generated by the Stream gateway application. 2. extract messages from the scenario and create their files. 3. create an excel file for each scenario and put data into it manually. 4. read excel file to get compliances from it. 5. edit test tool configuration file manually. 6. run the test tool Criticizing the existing After studying various activities related to running tests with test automation tool, we were able to identify the following issues: manual configuration of the test tool. waste of time when creating files and inserting data into them. executing the same configuration by each QA team. The issue here is that QA members configure the automation test tool manually by creating many text files and excel files which leads to a lot of errors while running tests. In fact they spend a lot of time repeating tasks that could be automated and assure that no error will be made while preparing files. Besides, QA teams of FIS in many countries can t share configurations, there is no communication between them Proposed solution Based on the existing criticisms, we are led to propose a solution that meets the expectations of the QA staff. It consists in developing a Web application that: automate the process of creating scenarios. automate the process of creating playlists of scenarios. automate the process of configuring Stream Gateway test tool. 7

21 Chapter 1. General overview automate the process of running Stream Gateway test tool. ensure a better distribution of tasks among the QA members. minimize the error rate by eliminating manual editing. The Figure 1.5 is a model of the proposed solution. Figure 1.5: Model of the proposed solution. 8

22 Chapter 1. General overview 1.3 Adopted methodology After presenting our project and identifying the limits to deduce the solution adopted, it is crucial to select an adequate Methodology in order to ensure the proper conduct of our project and to guarantee the best results Project management methodologies Waterfall project management Waterfall methodology follows a sequential, linear process and is the most popular version of the systems development life cycle (SDLC) for software engineering and IT projects. It is sometimes planned using a Gantt chart, a type of bar chart that shows the start and end dates for each task. Waterfall is best used for simple, unchanging projects. Its linear, rigid nature makes it easy to use and allows for in-depth documentation. Advantages of Waterfall: The advantages of Waterfall include: Easy to use and manage: Because the Waterfall model follows the same sequential pattern for each project, it is easy to use and understand. The team doesn t need any prior knowledge or training before working on a Waterfall project. Waterfall is also a rigid model; each phase has specific deliverables and review, so it s easy to manage and control. Requires a well documented approach: Waterfall requires documentation for every phase, resulting in better understanding of the logic behind the code and tests. It also leaves a paper trail for any future projects or if stakeholders need to see more detail about a certain phase. Disadvantages of Waterfall : The biggest drawback of Waterfall is how it handles change. Because Waterfall is a linear, sequential model, you can t bounce between phases, even if unexpected changes occur. Once you re done with a phase, that s it. The disadvantages of Waterfall are: Changes can t be easily accommodated: Once the team completes a phase, they can t go back. If they reach the testing phase and realize that a feature was missing from the requirements phase, it is very difficult and expensive to go back and fix it. 9

23 Chapter 1. General overview Gathering accurate requirements can be challenging: One of the first phases in a Waterfall project is to talk to customers and stakeholders and identify their requirements. However, it can be difficult to pinpoint exactly what they want this early in the project. Often times, customers don t know what they want early on and instead, learn and identify requirements as the project progresses Agile project management Agile software development is based on an incremental, iterative approach. Instead of in-depth planning at the beginning of the project, Agile methodologies are open to changing requirements over time and encourages constant feedback from the end users. Advantages of Agile : Change is embraced: With shorter planning cycles, it s easy to accommodate and accept changes at any time during the project. There is always an opportunity to refine and re-prioritize the backlog, letting teams introduce changes to the project in a matter of weeks. Customers are heard: Customers have many opportunities to see the work being delivered, share their input, and have a real impact on the end product. They can gain a sense of ownership by working so closely with the project team. Disadvantages of Agile : Team must be knowledgeable: Agile teams are usually small, so team members must be highly skilled in a variety of areas. They also must understand and feel comfortable with the chosen Agile methodology. Final product can be very different: The initial Agile project might not have a definitive plan, so the final product can look much different than what was initially intended. Because Agile is so flexible, new iterations may be added based on evolving customer feedback, which can lead to a very different final deliverable. 10

24 Chapter 1. General overview Agile vs Waterfall Tableau 1.1: Agile vs waterfall. Waterfall Agile Sequential x Flexible Accommodates change x x Defined requirements x Deliver quality products x x Continually evolving x Rigid process x The differences between Waterfall methodology versus Agile can be summed up in two words: rigid vs flexible. Waterfall is a much stricter, rigid process whereas Agile is flexible and continuously evolving. In our project, we choose to use Agile methodology base on many arguments explained in the next Section Scrum The Agile movement proposes alternatives to traditional project management. It includes Crystal Clear, Extreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), Scrum, and others. We choose to use agile as a methodology to manage project development life cycle, and scrum as an implementation of agile. This choice is based in the following needs: the project requirements will change and evolve. continuous feedback is required. the need to deliver software on a regular basis. 11

25 Chapter 1. General overview The Figure 1.6 gives an overview for the use of Scrum methodology. Figure 1.6: General Overview of Scrum framework. There are a specific, unchanging set of steps in the Scrum flow. They include: product backlog: The Product Owner and Scrum Team meet to prioritize the items on the product backlog (the work on the product backlog comes from user stories and requirements). The product backlog is not a list of things to be completed, but rather it is a list of all the desired features for the product. The development team then pulls work from the product backlog to complete during each sprint. sprint planning: Before each sprint, the Product Owner presents the top items on the backlog to the team in a sprint planning meeting. The team then chooses which work they can complete during the sprint and moves the work from the product backlog to the sprint backlog (which is a list of tasks to complete in the sprint). daily Scrum meetings: The Daily Scrum is a 15-minute stand-up meeting where each team member talks about their goals and any issues that have come up. The Daily Scrum happens every day during the sprint and helps keep the team on track. sprint review meeting: At the end of each sprint, the team presents the work they have completed at a sprint review meeting. This meeting should feature a live demonstration, not a report or a Power Point presentation. 12

26 Chapter 1. General overview Scrum roles There are three specific roles in Scrum. They are [2]: product owner : QA team of Stream Gateway; The Scrum Product Owner has the vision of what he or she wants to build and conveys that vision to the team. The Product Owner focuses on business and market requirements, prioritizing all the work that needs to be done. He or she builds and manages the backlog, provides guidance on which features to ship next, and interacts with the team and other stakeholders to make sure everyone understands the items in the product backlog. The Product Owner is not a project manager. Instead of managing the status and progress, his or her job is to motivate the team with a goal and vision. Scrum master : Professional supervisor ; Often considered the coach for the team, the Scrum Master helps the team do their best possible work. This means organizing meetings, dealing with roadblocks and challenges, and working with the Product Owner to ensure the product backlog is ready for the next sprint. The Scrum Master also makes sure the team follows the Scrum process. He or she doesn t have authority over the team members, but he or she does have authority over the process. For example, the Scrum Master can t tell someone what to do, but could propose a new sprint cadence. Scrum team : Trainee engineer: The Scrum Team is comprised of five to seven members. Everyone on the project works together, helps each other, and shares a deep sense of camaraderie. Unlike traditional development teams, there are not distinct roles like programmer, designer, or tester. Everyone completes the set of work together. The Scrum Team owns the plan for each sprint; they anticipate how much work they can complete in each iteration Scrum artifacts User stories : User stories [3] are user requirements in the plain customer s language without including too many details. Usually User stories are written in following format : As a <User> I want to <Perform a function> to <achieve something>. 13

27 Chapter 1. General overview Sprint : The sprint is the core of Scrum. This is a time block during which an increment of the product will be made. All sprints in a release have a constant duration and never overlap, that is, a sprint can not start until the previous one is finished. User stories priority : There are many techniques for prioritizing our sprints. We choose once that consists of giving each sprint a number in a scale of 1 to 10. Number 1 is given to the sprint which has the high priority. User stories complexity : There are a couple of famous techniques used to prioritize the user stories. One of them named planning poker technique. It consists of using cards which contains points called story points; it rates the relative effort of work in a Fibonacci format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20.. Conclusion This chapter has permitted us to analyze the existing processes used by Stream-Gateway team, to highlight the limits of the current situation, and to propose a solution for that. In the next chapter, we are going to specify the functional and non-functional requirements of the solution. 14

28 Chapter 2 Requirements specification 1 Functional requirements Non functional requirements Product backlog Sprints planning Gant diagram Global use case diagram Global class diagram

29 Chapter 2. Requirements specification Introduction In this second chapter, we identify the features of our application. This is made by the definition of all the functional and not functional requirements relative to the functioning of the system. We also identify product and sprints backlogs. At the end we present the global use case diagram. 2.1 Functional requirements Functional requirements have to answer the precise points of the specifications which presents the requirements of the future application in terms of features. They are a kind of contract or of promise between the user and the developer. The features which have to be supplies by my application are the following ones: Create a template of a scenario QA can create a template for a scenario of a specific market from a log file. Generate a scenario from a template When QA wants to run test, he can generate automatically all needed files from a template. Create a template for a playlist A playlist is a set of scenarios, it is used for test-regression case. the QA can create a template for future re-use case. Generate a playlist QA can generate automatically all needed files of a playlist from a template. edit a scenario template After creating a template for a scenario, QA engineer can modify it by adding variables or changing compliances. Configure Stream Gateway test tool QA can edit the configuration file of stream Gateway test tool from an UI interface instead of configuring it manually from w text editor. 16

30 Chapter 2. Requirements specification Run Stream Gateway test tool QA can run the automation test tool from an UI interface instead of running it manually from the command line. update compliances QA engineers can edit, from an UI interface, compliances. Add new compliances QA engineers can add a new compliance for new markets. Generate a report for Stream Gateway test tool QA can generate and print a report after running the Stream Gateway test tool. 2.2 Non functional requirements Besides functional needs, it is necessary to take into consideration certain necessary not functional needs for a simple use of the various offered features: Access and Identification Application must treats authentication and authorization. Every user has a unique interface. Speed of treatment : Optimize response time to approach as much as possible the real time. Ergonomics of user interfaces (UI) : Our application must be both useful (meets user needs) and usable (easy to use). For this fact, we must respect the quality criteria of the interfaces. The application must be a high-performance computing solution for the smooth flow of information and work. 17

31 Chapter 2. Requirements specification 2.3 Product backlog The table 2.1 summarizes the product backlog of our application. It should be noted that we did not mention the technical stories like the preparation of mock-ups and test sets. Priority and complexity technique are explained in the section scrum artifacts Tableau 2.1: Product Backlog ID Name As a I want to Priority Complexity 1 Authentication QA engineer Connect to the application by an id and a password Scenarios template QA engineer Extract a scenario from a log file Scenarios template QA engineer Display message s attributes Scenarios template QA engineer Define variables of messages Scenarios template QA engineer Choose messages compliance Scenarios template QA engineer Create templates in order to use them when generating scenarios Scenarios template QA engineer Be able of displaying a scenario template in order to modify it Scenarios template QA engineer Delete a scenario template Scenarios template QA engineer Extract a scenario from files text Scenarios QA engineer Generate a scenario from a template playlist QA engineer Generate a playlist from scenario templates playlist QA engineer Generate an excel file for each generated playlist playlist QA engineer Create a playlist template playlist QA engineer Modify playlist s template Test tool QA engineer Run Stream Gateway test tool Compliance QA engineer Add a new compliance Compliance QA engineer Edit an existing compliance Test tool QA engineer Configure Stream Gateway test tool Test tool QA engineer Generate a report after running Stream Gateway test tool Profile QA engineer Edit my profile Profile QA engineer Log out

32 Chapter 2. Requirements specification 2.4 Sprints planning Sprints planning is schematically shown in the following Figure 2.1: Figure 2.1: Sprints planning 2.5 Gant diagram The Figure 2.2 shows the chronogram of our progress in the preparation of this project. It describes the division of tasks over a period of four months. Figure 2.2: Gant diagram. 19

33 Chapter 2. Requirements specification 2.6 Global use case diagram Figure 2.3: Global use case diagram. 20

34 Chapter 2. Requirements specification 2.7 Global class diagram Figure 2.4: Global class diagram. The input for Stream Gateway test tool is a test case, it contains a playlist and an excel file. The latter describes all the messages of each scenario and defines their compliances. A playlist can contains one or many scenarios which are generated from a template. This template contains variables to automate the updating of messages attributes when generating a playlist. Conclusion The objective of this report s part is to bound the reach of the system by determining functional, non functional requirements, and the global use case diagram. This allows us to start the first release in the next chapter. 21

35 Chapter 3 Release 1 1 Sprint: Manage scenario template Sprint: Generate playlist

36 Chapter 3. Release 1 Introduction Throughout this chapter, we treat the user stories of two sprints named: Manage scenario template, and generating playlist. We describe its use cases by presenting their use case, sequence and class diagrams. Finally, we present some UI interfaces of the deliverable release. 3.1 Sprint: Manage scenario template Before starting a sprint, the Scrum team must define the goal of the sprint. This is to answer a fundamental question; why do we do this sprint?. Following a study on the division of the project, we decided the following goal: Prepare the features that are related to creating scenario templates Sprint backlog Once we have defined the purpose of our sprint, it s time to decide what features and their degrees of importance include in it. Specifically, what names in our product backlog will be included in the sprint backlog. That is what is has been summarized in the table 3.1 below; the backlog of our first sprint: Priority and complexity technique are explained in the section scrum artifacts Tableau 3.1: Backlog of sprint: Manage scenario template. ID User story Priority Complexity 2 Extract scenario from a log file Display message s attributes Define variables of messages Choose message s compliance Create scenario template Use cases description After making our backlog, we can now explain it in the form of tables: Each table provides a detailed description of a use case. 23

37 Chapter 3. Release Description of the use case «Create a scenario template» Tableau 3.2: Description of the use case «Create a scenario template» Use case Actor Precondition post-condition Create a scenario template. QA engineer. There is no template with same name. User is authenticated. Scenario template is created. Our Web application Stream Gateway CAT automates the generation of playlist files from scenarios template. In fact QA engineer must create a template for each scenario, and then he can use it whenever he wants to generate files Detailed diagram of the use case «Create a scenario template» Figure 3.1: Detailed diagram of the use case «Create a scenario template» 24

38 Chapter 3. Release Description of the use case «Update a scenario template» Tableau 3.3: Description of the use case «Update a scenario template» Use case Actor Precondition post-condition Update a scenario template. QA engineer. QA engineer created a template. User is authenticated. Template is modified. QA engineers can update a template of a scenario to define new variables, change attributes value, or change compliances Detailed diagram of the use case «Update a scenario template» Figure 3.2: Detailed diagram of the use case «Update a scenario template» 25

39 Chapter 3. Release Design System sequence diagram a ) Sequence diagram of the use case «Create a scenario template» Figure 3.3: Sequence diagram of the use case«create a scenario template» Textual description Nominal Scenario: 1. The user clicks on "create scenario" menu. 26

40 Chapter 3. Release 1 2. The system displays the interface of creating a scenario. 3. The user uploads a log file and clicks on extract button. 4. The system extracts messages from log file and extracts attributes from messages. 5. The system displays messages and attributes for the user. 6. The user defines which attributes are variables. 7. The user clicks on choose compliance button 8. The system loads compliances from an excel file. 9. The user chooses a compliance for scenario messages. 10. The user clicks on Create template button. 11. The system creates the scenario template. Exception: QA engineer cancels his creation. QA engineer closes the Web application. 27

41 Chapter 3. Release 1 b ) Sequence diagram of the use case «Update a scenario template» Figure 3.4: Sequence diagram of the use case «Update a scenario template» Textual description Nominal Scenario: 1. The user clicks on "update scenario" menu. 2. The system loads all existing templates. 3. The user chooses a template to update. 4. The system loads the template and displays its messages and attributes. 5. The user updates messages and attributes. 6. The user clicks on choose compliance button 7. The system display messages compiances. 8. The user updates compliances. 9. The user clicks on Update template button. 10. The system updates the scenario template. Exception: QA engineer cancels his update. QA engineer closes the Web application. 28

42 Chapter 3. Release Design class diagram of sprint : Manage scenario template Figure 3.5: Design class diagram of sprint : Manage scenario template. 29

43 Chapter 3. Release UI interfaces UI interface of the use case «Create a scenario template» Figure 3.6: UI interface for uploading a log file. When the QA engineer clicks on Create scenario button, The Figure 3.6 will be displayed. The scenario will be created from a log file, it can be uploaded as a file or the user can copy and paste its contents. A scenario is identified by its market and its name. 30

44 Chapter 3. Release 1 Figure 3.7: UI interface for displaying scenario messages. After uploading the log file, The system extracts messages and theirs attributes and display them as the Figure 3.7 and 3.8 show. The user can modify messages names and their order, and for each messages it can see all its attributes and modify their values. 31

45 Chapter 3. Release 1 Figure 3.8: UI interface for defining variables of messages. The system extracts attributes from each message (FIXML or FIX) of a scenario and displays them in a table (Figure 3.8) to let the user modify their attributes and defines variables. To define a variable, the user searches for the attributes, then clicks on the edit button in the right of each row. Then he chooses the scope of the variable ( Global column), the message types scope ( Path column), and finally the variable type which can be a current date, a date, an auto-increment field, or an input text. 32

46 Chapter 3. Release 1 Figure 3.9: UI interface for choosing compliances. Stream Gateway to client messages have compliance which the test tool use in order to validate messages. The QA engineer must choose those compliances when creating the scenario template. (Figure 3.9) 33

47 Chapter 3. Release UI interface of the use case «Update a scenario template» Figure 3.10: UI interface of the use case «Edit scenario template». After creating a scenario template, the user can update it from the interface of Figure The system loads the selected scenario and display its messages as shown in the Figure 3.8. When the user click on Get template button, he will repeat the steps of creating a scenario template of the Section

48 Chapter 3. Release Sprint: Generate playlist Before starting a sprint, the Scrum team must define the goal of the sprint. This is to answer a fundamental question; why do we do this sprint?. Following a study on the division of the project, we decided the following goal: Prepare the features that are related to generating scenario playlists Sprint backlog Once we have defined the purpose of our sprint, it s time to decide what features and their degrees of importance include in it. Specifically, what names in our product backlog will be included in the sprint backlog. That is what is has been summarized in the table 3.4 below; the backlog of this sprint: Priority and complexity technique are explained in the section scrum artifacts Tableau 3.4: Backlog of sprint: Generate playlist. ID User story Priority Complexity 7 Update scenario template Delete scenario template Extract a scenario from files text Generate a scenario from a template Use cases description After making our backlog, we can now explain it in the form of tables: Each table provides a detailed description of a use case. In this Sprint, we will be interested in the following use case: 35

49 Chapter 3. Release Description of the use case «Generate a scenario» Tableau 3.5: Description of the use case «Generate a scenario playlist». Use case Actor Precondition post-condition Generate a playlist. QA engineer. There at least one template of a scenario. User is authenticated. Messages files are created. Excel file is created Detailed diagram of the use case «Generate a playlist» Figure 3.11: Detailed diagram of the use case «Generate a playlist» 36

50 Chapter 3. Release Design System sequence diagram a ) Sequence diagram of the use case «Generate a playlist» Figure 3.12: UI interface of the use case «Generate a scenario». Textual description Nominal Scenario: 1. The user clicks on "Generate playlist" menu. 2. The system loads all existing templates. 3. The user chooses a market and templates which will be included in the playlist. 4. The system displays variables of each scenario template. 5. The QA engineer gives values for the variables. 6. The system generates the playlist. 37

51 Chapter 3. Release 1 Exception: QA engineer cancels his demand. QA engineer closes the Web application Design class diagram of sprint : Generate playlist Figure 3.13: Design class diagram of sprint: Generate playlist. 38

52 Chapter 3. Release UI interfaces UI interface of the use case «Generate a playlist» Figure 3.14: UI interface of the use case «Generate a playlist». The QA engineer must generate a playlist (Figure 3.14) before running a test. He enters a market name and chooses scenarios templates which will be included in the playlist. When clicking on the button Get playlist, the system loads variables from templates and shows them to the user in order to edit their values. After clicking on generate playlist button, the system creates files for each scenario and generates an excel file that s used by the Stream Gateway test tool. Conclusion At the end of this chapter, we succeeded in producing an increment with sufficient value for the customer. In the next chapter, our effort will be devoted to producing a new release covering the management of the Stream Gateway test tool. 39

53 Chapter 4 Release 2 1 Sprint: Manage Stream Gateway test tool

54 Chapter 4. Release 2 Introduction This release contains only one sprint named Managing Stream Gateway test tool. We describe its use cases, create its sequence diagrams, and show its UI interfaces. 4.1 Sprint: Manage Stream Gateway test tool Before starting a sprint, the Scrum team must define the goal of the sprint. This is to answer a fundamental question; why do we do this sprint?. Following a study on the division of the project, we decided the following goal: Prepare the features that are related to configuring and running Stream Gateway test tool Sprint backlog Once we have defined the purpose of our sprint, it s time to decide what features and their degrees of importance include in it. Specifically, what names in our product backlog will be included in the sprint backlog. That is what is has been summarized in the table 4.1 below; the backlog of our this sprint: Priority and complexity technique are explained in the section scrum artifacts Tableau 4.1: Backlog of sprint: Manage Stream Gateway test tool. ID User story Priority Complexity 11 Generate a playlist from scenario templates Generate an excel file for each generated playlist Create a playlist template Run Stream Gateway test tool Configure Stream Gateway test tool Use cases description After making our backlog, we can now explain it in the form of tables: Each table provides a detailed description of a use case. In this Sprint, we will be interested in the two following use cases: 41

55 Chapter 4. Release Description of use case «Configure Stream Gateway test tool» Tableau 4.2: Description of the use case «Configure Stream Gateway test tool» Use case Actor Precondition post-condition Configure Stream Gateway test tool. QA engineer. Generate playlist. Stream gateway test tool is configured and ready to be run. Before running Stream Gateway test tool, QA engineer must configure it by editing properties in a file. Most properties are now automated such as Rules. xlsx path, playlist s excel path, sheets names Detailed diagram of the use case «Configure Stream Gateway test tool» Figure 4.1: Detailed diagram of the use case «Configure Stream Gateway test tool» 42

56 Chapter 4. Release Description of use case «Run Stream Gateway test tool» Tableau 4.3: Description of the use case «Run Stream Gateway test tool» Use case Actor Precondition post-condition Run Stream Gateway test tool. QA engineer. Configure Stream Gateway. Test case file is updated. After generating a playlist, configuring Stream Gateway test tool, the QA can run Stream Gateway test tool by just entering a command Detailed diagram of the use case «Run Stream Gateway test tool» Figure 4.2: Detailed diagram of the use case «Run Stream Gateway test tool» 43

57 Chapter 4. Release Design System sequence diagram a ) System sequence diagram of the use case «Configure Stream Gateway test tool» Figure 4.3: System sequence diagram of the use case «Configure Stream Gateway test tool». Textual description Nominal Scenario: 1. QA engineer clicks on "configure" button. 2. The system shows parameters. 3. QA engineer updates parameters. 4. QA engineer submits changes. 5. The system updates Stream Gateway test tool parameters file. Exception: QA engineer cancels his configuration. QA engineer closes the Web application. 44

58 Chapter 4. Release 2 b ) System sequence diagram of the use case «Run Stream Gateway test tool» Figure 4.4: System sequence diagram of the use case «Run Stream Gateway test tool». Textual description Nominal Scenario: 1. QA engineer clicks on "Run" button. 2. The system shows of runnui. ing Streaym Gatewa 3. QA engineer enters a command. 4. QA engineer clicks on "Run" button. 5. The system runs Stream Gateway test tool. Exception: QA engineer enters a non valid command. 45

59 Chapter 4. Release Design class diagram of sprint : Manage Stream Gateway test tool Figure 4.5: Design class diagram of sprint : Manage Stream Gateway test tool UI interfaces UI interface of the use case «Configure Stream Gateway test tool» Figure 4.6: Configure Stream Gateway test tool UI interface. 46

60 Chapter 4. Release 2 This UI interface of our solution ( Figure 4.6 ) lets the QA engineer configuring the file property of Stream Gateway test tool. In fact, some properties are automated like "sg.auto.testcasesuite" UI interface of the use case «Run Stream Gateway test tool» Figure 4.7: Run Stream Gateway test tool UI interface. Stream Gateway test tool can be run through a UI interface (Figure 4.7). QA engineer still needs to write the command and its options, but it doesn t need to write the path to the run.bat file. Conclusion At the end of this chapter, we succeeded in producing another increment that will automate the managing of Stream Gateway test tool. In the next chapter, we will describe the environment that allowed us to implement the design discussed in the previous chapter. 47

61 Chapter 5 Closure phase 1 Environment Application architecture Application documentation

62 Chapter 5. Closure phase Introduction In this last phase, we describe the environment that allowed us to implement the design discussed in the previous chapters. Then we talk about the user and developers documentation which are included in the product handover. 5.1 Environment Material Environment To realize the project, we worked on a computer which has the following characteristics : Tableau 5.1: Material environment Brand Processor Memory Operating system DELL Intel dual 4,00 Go Windows 7 64 bits IDE and Programming languages In order to facilitate the development of our solution we use many IDE and frameworks. We will talk about that in the following Section IDE Spring STS Figure 5.1: Spring STS logo. The Figure 5.1 is the logo of Spring Tool Suite [4]. It is an Eclipse-based development 49

63 Chapter 5. Closure phase environment that is customized for developing Spring applications. It provides a ready-to-use environment to implement, debug, run, and deploy your Spring applications, including integrations for Git, Maven, and comes on top of the latest Eclipse releases. Postman Figure 5.2: Postman logo. Postman [5] is a complete graphical environment to handle all interactions with Web APIs, as well as Http query. We use it to test our APIs. Visual studio code Figure 5.3: Visual Studio code logo. Visual studio code [6] is a free and open-source IDE developed by Microsoft for Windows, Linux and macos. It includes support for debugging, embedded Git control, syntax highlighting, intelligent code completion, snippets, and code refactoring. We use Visual Studio code to edit AngularJS code besides to css, less, JavaScript, and html code. 50

64 Chapter 5. Closure phase StarUML Figure 5.4: StarUML logo. To design our application, we need to adopt a modeling language to clarify the features of the project. To overcome this need, we decided to adopt the UML (Unified Modeling Language) as an object-oriented analysis and design methodology. We choose to work with StarUml [7]. It is easy to use, offers several code generators and handles most of the diagrams specified in the UML 2.0 standard Programming languages Java Java [8] is a computer programming language that is class-based and object-oriented. It is intended to let application developers write once, and run anywhere (WORA), meaning that compiled Java code can run on all platforms (windows, Linux, etc.) that support Java without the need for recompilation. Figure 5.5: Java logo. 51

65 Chapter 5. Closure phase JavaScript Figure 5.6: JavaScript logo. JavaScript [9] is an interpreted run-time language and one of the three (HTML, css, JavaScript) core technologies of World Wide Web content production. It is used to develop dynamic Web applications. The majority of websites employ it, and all modern Web browsers support it without the need for plug-ins. HTML5 Figure 5.7: HTML5 logo. Hypertext Markup Language (HTML) [10] is a markup language used to represent Web pages. It is used generally with JavaScript and CSS to forms a powerful tool of creating Web applications. In our project we used the version 5 (the current version of the HTML standard) of HTML which includes many new syntactic features such as handling natively multimedia and graphical content. 52

66 Chapter 5. Closure phase LESS Figure 5.8: LESS logo. Less [11] is a CSS pre-processor that extends the CSS language, adding features that allow variables, functions and many other techniques that allow you to make CSS that is more maintainable, themeable and extendable. 5.2 Application architecture Navigation schema The Figure 5.9 present the user navigation schema. Figure 5.9: User navigation schema System architecture In software engineering, a Web application is an application delivered to users from a Web server through a network such as the Internet or intra-net. In order to ensure the maintainability and the scalability of our application, the architecture put in place must offer a low coupling and high cohesion between the different components of the application. In this context, a layered architecture is the most appropriate (Figure 5.10). The principle of a layered architecture is relatively simple: it aims to separate application parts (presentation, application logic and data storage). 53

67 Chapter 5. Closure phase Figure 5.10: SGW CAT architecture. This architecture guarantees: less code per layer. reduce complexity. easier to maintain code. easier to add new functionality. easier to test. allows reusing code across the application Presentation layer The presentation layer is the top level of the application. The main function of this layer is to translate tasks and results to something the user can understand. It is implemented using FIS framework called responsive UI Framework (RUF) which is written with angularjs 1.x. AngularJS [12] is a JavaScript open-source front-end web application framework mainly maintained by Google. It aims to simplify both the development and the testing of applications by providing a framework for client-side model view controller (MVC) and model view viewmodel (MVVM) architectures. 54

68 Chapter 5. Closure phase Controller Layer This layer contains RESTful Web services of our application. It is created using spring Web model-view-controller (MVC) framework(figure 5.11). IT is designed around a Dispatcher Servlet that dispatches requests to handlers. Figure 5.11: Spring MVC architecture service layer This layer [13] coordinates the application, processes commands, makes logical decisions and evaluations, and performs calculations. It also moves and processes data between the two surrounding layers. 55