An Approach to Achieve DBMS Vendor Independence for Ides AB s Platform

Transcription

1 Linköping University Department of Computer Science Bachelor thesis, 16 ECTS Datateknik 2017 LIU-IDA/LITH-EX-G--17/008--SE An Approach to Achieve DBMS Vendor Independence for Ides AB s Platform Niklas Blomqvist Philip Johansson Examiner : Olaf Hartig External supervisor : Kristian Sjöström Linköpings universitet SE Linköping ,

2 Upphovsrätt Detta dokument hålls tillgängligt på Internet eller dess framtida ersättare under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida Copyright The publishers will keep this document online on the Internet or its possible replacement for a period of 25 years starting from the date of publication barring exceptional circumstances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: c Niklas Blomqvist Philip Johansson

3 Abstract Software that is developed with few integration capabilities to different user interfaces or database vendors might lose market share in the long run. To stay competitive, companies that find themselves in situations like these might need to look at options to increase their alternatives. This thesis aims to present and evaluate how Ides AB could achieve vendor independence as it relates to database integration. The proposed solution is based on pre-existing code from an existing product and thus includes theory about the methods and details how one can read, understand and analyse code. The outcome is presented with code examples to give the reader a clear and concise understanding. In the evaluation phase, we take other related work into consideration as it relates to our thesis focus. The proposed approach presented consists of a class to represent different database vendors. It also consists of abstract functions handling the interaction between different databases. Which database the class interacts with is determined by the connection established. The approach also includes what is possible to make database agnostic verified by an evaluation.

4 Acknowledgments We would like to thank Ides AB for giving us the opportunity to do this thesis. Thanks to everyone at Ides for behind very helpful and inviting. Special thanks go to Kristian Sjöström who has been our supervisor at Ides. Also thanks to Olaf Hartig who has been our examinator and supervisor. Olaf provided us with feedback and guidelines to make this thesis possible. iv

5 Contents Abstract Acknowledgments Contents List of Figures iii iv v vii 1 Introduction Motivation Aim Research questions Background Delimitations Theory Reading, understanding, and analyzing code Software development models Maintainability Refactoring code Database management systems Layer architecture Object-relational mapping Software testing Method Pre-study Implementation Software verification Results Background Implementation Analysis of the layer architecture Evaluation Stored procedure Remote comparison Local comparison Discussion Method Results v

6 6.3 Source criticism Conclusion 44 Bibliography 46

7 List of Figures 2.1 Code example of refactoring with the extract method Code example of refactoring with the inline method Architecture of a database Example of a table in a database Relations in a table Result from query Three-layer architecture ORM architecture List over IDbConnection interface properties and methods Example of parameters in the IDbCommand interface Call to the database using Oracle.DataAccess.Client Enumeration representing database types. Could be extended further The constructor of the implemented class The overwritten CommandText property for the IDbCommand interface The character different DBMSs use for parameters Accessing Oracle s parameter character Snippet from the ConvertStatement function that translate the parameter character Example of writing a standard SQL statement Statement with the unique Oracle functions decode and dbms_lob.get_length Command with separate statements for different DBMSs List over functions to be translated Implementation after implementing parse functions Function header of helper function GetStatement Statement supported by multiple DBMSs Statement expected to execute on all DBMSs Function for adding a parameter to a statement Functions for reading binary data in Oracle and SQL Server Function for reading binary data Function for reading data Call to the database using the new implementation Example of a statement in the user interface Example of application logic in the user interface Snippet from a stored procedure Snippet from a stored procedure written in C# Chart of stored procedure Chart of the memory usage evaluation on a remote server Chart of CPU evaluation on a remote server Chart of the execution time evaluation of the statement 1 on a remote server Chart of the execution time evaluation of the statement 2 on a remote server Chart of the execution time evaluation of the statement 3 on a remote server vii

8 5.9 Chart of the execution time evaluation of the statement 4 on a remote server Chart of the execution time evaluation of the statement 5 on a remote server Chart of the memory usage evaluation on a local server Chart of CPU evaluation on a local server Chart of the execution time evaluation of the statement 1 on a local server Chart of the execution time evaluation of the statement 2 on a local server Chart of the execution time evaluation of the statement 3 on a local server Chart of the execution time evaluation of the statement 4 on a local server Chart of the execution time evaluation of the statement 5 on a local server

9 1 Introduction 1.1 Motivation The ability to choose and customize your software has become something that customers take for granted. Companies that have developed software which was originally designed to only have narrow options are now in a critical phase where they are losing potential customers. How the process to store data from the software should be done is often seen as one of the parts that the customer wants to choose. Databases are one way of handling data. Developers of software are facing a choice in where they must choose which database management system (DBMS) to interact with. But every customer has their own individual situation with a unique solution that possibly cannot be adapted to another customer. Keeping up with the market and being able to deliver what the customers demand is an essential key in developing software. One way of extending the flexibility is to make the software database-agnostic Aim The purpose of this thesis project is to investigate and to evaluate the most appropriate way to make Ides AB s software platform database-agnostic without sacrificing performance. 1.3 Research questions 1. In what way, could Ides become independent of database provider without affecting the current functionality? How could this be implemented without affecting the performance of execution time, CPU or memory by more than 10%? 2. How should Ides keep working with their current layer architecture, with respect to multiple database providers? 1 In an information technology context, agnostic refers to something that is generalized so that it is compatible among various systems [3]. 1

10 1.4. Background 1.4 Background Ides AB is developing a platform for version control of engineering data, CAD integrations, applications and Microsoft office documents. The name of the product is MasterConcept and more about it can be read at Today, Ides AB can exclusively offer their platform to run with Oracles database management system. To increase their flexibility to customers, Ides would like to make their software platform functional with different database managers. The reason is that they have lost procurements, and thereby market shares because they cannot offer another DBMS. 1.5 Delimitations Ides is developing their software in a.net environment with the language C#, therefore this thesis will focus on alternatives relevant for the.net Framework. Our part on MasterConcept will be focusing on documents. 2

11 2 Theory This chapter presents theory and related work used writing this thesis. 2.1 Reading, understanding, and analyzing code This section is relevant in the sense that MasterConcept is 30+ years old. Over the years it has grown very large in terms of code base. Understanding is a key factor in contribution. "As the amount of code in a project grows, it gradually surpasses understanding" [5]. There are methods to help get the fundamental understanding that one need to contribute in an effective manner. Feathers [5], explains three methods, Notes/Sketching, Listing markup, and Breakpoints, all presented below. Notes/Sketching When reading code repeatedly it can become confusing. One way to get further understanding could be to write notes and draw sketches. Start by writing down names of the most important thing, classes or functions, continuing with the second most important thing. If there is a relation between the two, draw a line between them. The sketches do not have to be formal, like a full UML diagram. This method could help see things from a different perspective, since drawing things out tend to do that [5]. Listing markup Another method Feathers [5] presents for code understanding is Listing Markup. Mark up a listing to get deeper understanding of its purpose and print out the code. Depending on if you want to further understand dependencies or method structure, apply one of the following techniques: Separating responsibilities Use a marker to group things. If things belong together, mark them with a special symbol next to them so it is possible to identify parts that belong together. 3

12 2.2. Software development models Understanding method structure Line up the code in blocks since bad indentation in long methods can make them very difficult to read. Draw lines from the beginning of the blocks to the end of the blocks. Look over the different blocks and see if there exists complicated logic that could be split up into separate functions using a refactoring method described in section 2.4. Breakpoints This method requires an Integrated Development Environment 1 (IDE). Find the entrance of some logic to deepen knowledge about. Set a breakpoint on the first line and step the code line by line. This technique will traverse every function call made from the point of break and can help to see how the code is interrelated. 2.2 Software development models This section presents different software development models. developing. Models that were considered when When it comes to software development and development models, Patton [18] describes the four most frequently used models. Patton [18] says that each model has its own advantages and disadvantages, and when testing and trying to understand code, one will most likely encounter them all. The models that Patton [18] describes are the following: Big-bang model The big-bang model originates from the theory that the universe was created in a single huge explosion. In software development, this principle is applied in a similar manner. A very large amount of both people and money are put together to develop a software. The development is very fast paced and testing is not considered. This results in a large program that might or might not work perfectly because the way of working was very rushed forward. The resulting structure is in most cases not optimal. Testing and understanding a product that was developed with the big-bang model is very difficult. This is because it is very hard to go back and fix things that are broken since there is no real structure in the code. Code-and-fix model The code-and-fix model is a step up from the big-bang model. The idea is that the development team is starting out with a simple design of what they want. This later proceeds into a long repeating cycle of testing, fixing bugs and developing new features. Finally, at some point the software is released. Testing and understanding a product developed with the code-and-fix model is easier than with the bing-bang model. This is because under the development cycle there is a part for testing and thus the released software is easier to maintain due to improved code quality. Waterfall model The waterfall model builds upon a series of steps starting from an initial idea to a final product. After each step the development team reviews if they are ready or not to move on 1 An IDE is a software application that provides comprehensive facilities to computer programmers for software development. 4

13 2.3. Maintainability to the next step in the model. If not, the team stays at their current level until they are ready to move on. This model requires well-done product definition and design specification. The coding phase is usually only a single block and when moved from one block to another there is no turning back in the waterfall model. Testing and understanding a product developed with the waterfall model is easy because every single step in the development cycle is very well and thoroughly specified. Spiral model The spiral model addresses many of the problems with the previous models described while contributing with additional features. The general idea behind the spiral model is to start small with defining the most important features. Try them out and get feedback from customers and then move on to the next level. This is repeated until the final product is achieved. Every cycle in the spiral model involves: 1. Determine objectives, alternatives, and constraints. 2. Identify and resolve risks. 3. Evaluate alternatives. 4. Develop and test the current level. 5. Plan the next level. 6. Decide on the approach for the next level. The overall view of the spiral model is seen as a bit of both waterfall and code-and-fix. Waterfall because of the phases of analyzing, designing, developing, and testing. Code-andfix because of each cycle around the spiral working model is very similar. Strictly following the spiral model ends up with a code base with high quality and allows for easier understanding by future developers [18]. 2.3 Maintainability This section contains information to be applied both when writing code and understanding existing code and design decisions. Maintainability is the ease of which a system could undergo changes. Changes could impact components, services, features, and interfaces by fixing errors or to meet new requirements from customers [13]. Maintainability is a function of the overall quality. The most common things that affect maintainability include the following [13]: Excessive dependencies between layers. The different layers, classes, or functions in the applications are very dependent on each other, they are tightly coupled to each other. This makes it very hard to swap one class with another without having to change a lot of other code. Affects: Prevents easy replacements, updates, and changes. Possible solution: A typical approach to prevent this is to design systems as welldefined layers with clear layout, as mentioned in

14 2.4. Refactoring code Direct communication. This applies to components and layers located on different physical servers. In general, when designing for communication between such components, there is a choice between direct communication and message-based communication. Affects: Prevents changes to physical deployment of components and layers. Possible solution: Choosing an appropriate communication model and designing a pluggable architecture that allows for easy maintenance could avoid this. Relying on custom implementations. Writing and relying on custom implementations for things such as authentication. Affects: Prevents reuse and hinders maintenance. Possible solution: Instead use the built-in platform functions and features where possible. Code logic of components is not cohesive. Cohesion refers to the degree to which the elements inside a component belong together. If components are not cohesive there exists code that do not belong to the component. Affects: Prevents the ease to maintain and replace. Also causes unnecessary dependencies. Possible solution: Design components with high cohesion and low coupling. Code base is large and complex. Large amounts of code written without a proper structure. Affects: Makes changes very unmanageable, fragile and burdensome. Possible solution: Again, having clear and structured layers and perhaps using a business workflow could avoid these situations. Lack of documentation. There is a lack of documentation regarding either comments in code or manuals over how to use the program and its features. Affects: Hinders usage, management, and future upgrades. Possible solution: Make sure to document each function with comments and to use explanatory variable names. 2.4 Refactoring code This section contains information about how to refactor code. We used refactoring to get better understanding of how the code worked. Software that consists of a lot of code that is constantly changed by different developers can be difficult to keep clean and uniform. Usually in software development, there is a code design to maintain a standard, but development of both code language and development technology is ongoing. It may therefore be useful to maintain the existing code with new technologies so that the whole software is coherent [14]. Refactoring code is a technique for developers to improve the code. It is also a technique to improve the understanding of how the code is interrelated. The main goal of refactoring is to improve the code after being developed, as both new features get added to the programming 6

15 2.4. Refactoring code language and philosophies for software development change [6]. The Extract method is one useful technique, the core of the extract method is to break methods into smaller methods [6]. Extract method The extract method has seven steps to follow to achieve the desired effect: 1. Find the code you want to refactor and comment it out. 2. Come up with a name that describe what it does it is important to distinguish between what it does and how it does it, the name should be related to the first. 3. Place a call to the new method inside the old method. 4. Copy the code that you want to refactor into the new method. 5. Adjust the method declaration to accommodate the parameters and return value (if any). 6. Run tests to validate that it works. 7. Remove the commented code from the first step. Figure 2.1 shows an example of the extract method. public void printowing(customer Customer, List<Order> Orders) double outstanding = 0.0; //Print banner Console.WriteLine(" "); Console.WriteLine("-- Customer Owes --"); Console.WriteLine(" "); //Calculate outstanding foreach( Order order in Orders ) outstanding += order.getamount(); //Print details Console.WriteLine(String.Format("Name: 0", Customer.GetName())); Console.WriteLine(String.Format("Amount: 0", outstanding)); ŕ ő 7

16 2.4. Refactoring code public void printowing(customer Customer, List<Order> Orders) double outstanding = 0.0; printbanner(); //Calculate outstanding foreach( Order order in Orders ) outstanding += order.getamount(); //Print details Console.WriteLine(String.Format("Name: 0", Customer.GetName())); Console.WriteLine(String.Format("Amount: 0", outstanding)); private void printbanner() //Print banner Console.WriteLine(" "); Console.WriteLine("-- Customer Owes --"); Console.WriteLine(" "); Figure 2.1: Code example of refactoring with the extract method. When using the extract method, local variables may become a problem. There are guidelines to follow both to avoid and to handle local variables. The first thing is if the variable is read but not changed, then it is just to pass them as a parameter. The real problem occurs when a local variable is to be assigned. If it is only one variable that is assigned, the method can return that value. If there are several values that is to be assigned, it is possible to encapsulate it into a wrapper class. This may not be optimal considering that the initial purpose was, clear and easy code. If the latter would happen, Fowler et al. [6] state that the refactoring may be avoided or written in another way [6, 14]. Inline method The inline method is the opposite of the extract method. When there is no longer easy to understand the code or if it is badly factored, the inline method is used. The inline method has five steps to follow to achieve the desired effect: 1. Check that the method is not polymorphic. If so, do not inline if subclasses override the method; they cannot override a method that is not there. 2. Find all calls to the method. 3. Replace each call with the method body. 4. Compile and test. 5. Remove the method definition. Figure 2.2 shows an example of the inline method. 8

17 2.5. Database management systems public int getrating() return (morethanfivelatedeliveries())? 2 : 1; private bool morethanfivelatedeliveries() return _numberoflatedeliveries > 5; public int getrating() return (_numberoflatedeliveries > 5)? 2 : 1; ŕ ő Figure 2.2: Code example of refactoring with the inline method. 2.5 Database management systems MasterConcept is using a DBMS for storing and retrieving data. This section gives relevant information about DBMSs. A database is a structured collection of data, usually very large. Relational databases structure data in tables consisting of rows and columns. Each column has a column name, which is used access that particular column [4]. Databases are structured using database schemas. A database schema represents the logical view of the entire database. It defines how the data is organized within the database as well as the relation between the data. A database schema can be divided into two categories, both listed below. Logical database schema Defines the logical constraints that need to be applied when data is stored. A constraint could be column data type such as numbers (integers) or text (strings). Physical database schema The actual storage of data and its form of storage, like files. It defines how the data will be stored in a secondary storage device. Figure 2.3: Architecture of a database. 9

18 2.5. Database management systems Database systems contain a lot of data in addition to the actual data to be saved. This data is known as metadata, data about data, which helps to locate and retrieve data in an easy way. Similar to the database schema, data independence follows a layered architecture, listed below. Logical data independence If changes occur to the format of a table, the data on disk should not be affected. Physical data independence If changes occur to the physical data the schema or logical data should not be affected. To keep data independence, efficient access, and to allow for administration, databases are managed by a database management system (DBMS) [19]. A database management system is a software application that interacts with both the user and the database itself to capture and analyze data [4]. Persons ID Firstname Lastname 1 Niklas Blomqvist 2 Philip Johansson Figure 2.4: Example of a table in a database. Figure 2.4 shows an example of a possible table in a database. This is a table about persons and consists of three columns. The first column, ID, is only there to uniquely identify each person. This is because two people could have the same name. The second and third column name is Firstname/Lastname and stores the name of each person. Relations in databases A relation is a set of tuples 2 (d 1, d 2,..., d n ) where each element d i is a member of a data domain D i 3 [2]. Each element is termed an attribute value [2]. An attribute is a name paired with a data type [2]. An attribute value is an attribute paired together with an element of that attributes domain [2]. A tuple is a set of attribute values in which no two distinct elements have the same attribute name [2]. Figure 2.5 shows relation, tuple and attribute represented as table, row and column respectively. SQL Term Relational database term Description Row Tuple (or record) A dataset representing a single item. Column Attribute (or field) A labeled element of a tuple (ex. Firstname) Table Relation A set of tuples sharing the same attributes; a set of columns and rows. Figure 2.5: Relations in a table. 2 A tuple is a finite ordered list of elements. 3 A data domain refers to all the values which a data element may contain. 10

19 2.5. Database management systems Structured Query Language A database management system allows users to create, read, update and delete (CRUD) data in a database [4]. This is achieved by interacting with the DBMS through the Structured Query Language (SQL) [4]. SQL allows users to manage databases by deleting/creating tables and inserting/updating/deleting of data within the tables [19]. Communication between the DBMS and users is done via a Statement. The fundamental statements are the following [4]: SELECT INSERT UPDATE DELETE For retrieving data from a table. For inserting data in a table. For updating existing data in a table. For deleting data in a table. A statement that retrieves data is called a query and is built upon a SELECT-FROM- WHERE structure [4]. SELECT < a t t r i b u t e l i s t > FROM < t a b l e l i s t > WHERE <condition > <attribute list> - names of columns whose values are to be retrieved by the query. <table list> - relation names required to process the query. <condition> - conditional expression that identifies the data to be retrieved. By using figure 2.4 as an example, a query for retrieving persons whose first name is Niklas would look like: SELECT Firstname, Lastname FROM Persons WHERE Firstname =" Niklas " This query would produce the following result: Firstname Niklas Lastname Blomqvist Figure 2.6: Result from query. Similar expressions can be used with UPDATE/INSERT/DELETE to modify data in tables. 11

20 2.6. Layer architecture Stored procedures Most DBMSs (including Oracle and SQL Server) support stored procedures. A stored procedure is a subroutine which can consolidate and centralize logic which originally was implemented in applications. Very extensive or complex processing which would require the execution of multiple SQL statements could instead be implemented as a stored procedure to save both time and memory [4]. Different DBMSs utilize different dialects of SQL. This means a procedure written for Oracle s DBMS would possibly not be functional in SQL Server [16, 17]. Stored procedures are registered in the DBMS and not in the application code. Triggers A trigger is a procedural code in a DBMS that automatically executes at certain events. Possible events differs from DBMS to DBMS but the following are sort of standard for the most well-known ones (including Oracle and SQL Server) [4]: BEFORE UPDATE/DELETE/INSERT Execute code before updating/deleting/inserting data into a table. AFTER UPDATE/DELETE/INSERT Execute code after updating/deleting/inserting data into a table. Triggers are bound to specific tables and are automatically executed when any of the bound events occur. Oracle For stored procedures and triggers, Oracle utilizes Procedural Language/SQL (PL/SQL) [17] which is an extension of SQL. One of the main differences between PL/SQL and other SQL dialects, for expressing stored procedures, is the ability to group procedures into packages. Packages declare the types, variables, constants, exceptions, cursors, and subprograms that can be referenced from outside the package. It contains information about the content of the package but excludes the code for the subprograms. PL/SQL also has a lot of unique built-in functions. SQL Server For stored procedures and triggers, SQL Server utilizes Transact-SQL (T-SQL)[16] which also is an extension of SQL. The main difference between PL/SQL and T-SQL is how they handle variables, stored procedures, and built-in functions [16, 17]. 2.6 Layer architecture This section contains information to understand how code is structured and to understand our result of how Ides should keep working with their layer architecture in the future. Like any other complex structure, software should be structured in some way. There are different approaches when it comes to structuring the software, but the primary goal is the same, keep the software alive and updatable. Without some structure, it would be hard to debug and expand the software. Software should be structured in a way that the user, system, software and business goals are being considered [13]. Questions that come up when designing a system might be: How will the user interact with the system? 12

21 2.6. Layer architecture How can the software be designed so it can flexibly be updated? What is that next phase of the software? (i.e. features, platform etc.) At the highest level, software can be decomposed into 3 layers. These three levels are presented below. Presentation This layer takes care of the interaction with the user. It receives what to render and might also take input and pass it to the business layer. This layer is normally the traditional application or the Web-based application [22]. Business This layer takes care of the business logic of the application, it is working like a bridge between the presentation and data layers. Data This layer takes care of the data access and the persistent data store. Figure 2.7: Three-layer architecture. Layers are taking care of the logical representation and do not care about the location of the physical hardware. There can be different tiers of layers, but layers can also reside on the same tier. The primary goal of having individual layers is to make each of the layers independent of each other. By doing that, the developer can replace and update one layer without having to make a lot of changes to the others [10, 20, 21]. When designing an application, the first thing to focus on is the highest level of abstraction. Start by collecting functionality into different layers. There is a granularity between too few or too many layers. This balance is important to keep in mind to avoid unnecessary complexity. When grouping functionality into layers, the interaction between the layers must be taken into concern. Meier et al. [13] are specifying three rules, top-down interaction, strict interaction and loose interaction, for the layers to interact with each other. Interacting in this context is the same as to communicate with each other. These three rules are to be followed in the whole code to avoid circular dependency. Circular dependency is a relation with two or more components being directly or indirectly dependent on each other to function properly. Top-down interaction. Higher level layers can interact with layers below. This accompanies that lower layer never can interact with the ones above. It is possible to use events to make components in the higher layers aware of changes in the lower layers [13]. 13

22 2.7. Object-relational mapping Strict interaction. Each layer must interact with only the layer directly below. This rule will enforce strict separation where each layer only knows about the layer directly above. If the software is to be modified over time, this is the approach to choose. The reason behind that is that modifications will only affect the layer directly above [13]. Loose interaction. Higher level layers can bypass layers to interact with lower layers directly. This may improve the performance, but can also affect the dependencies negatively, meaning that the code can get effects that was not sought. This is the approach to choose if the application is not to be distributed across physical tiers [13]. The benefit of this rule is that modifications to the interface of the layer will only affect the layer directly above. 2.7 Object-relational mapping ORM was a first thought of a solution to our problem and is discussed in later chapters. Object-Relational Mapping (ORM), is an existing technique for converting data between object-oriented programming languages and relational databases. Typically, an objectoriented program uses an API that in turn calls a driver to communicate commands to the database [9]. In a result set, this means the programmer manually must set each attribute of the object in question to the corresponding returned data. "This code differs little from class to class and is largely the same even from application to application and is often tedious to write" [9]. An object-relational mapper functions in between the Data Access Layer and the Relational Database as seen in figure 2.8. Figure 2.8: ORM architecture Using an ORM is one way of creating abstraction in code as you would write statements to the ORM of choice instead of the database. The ORM is configured to talk with a specific DBMS, but multiple of these configurations could extend the functionality to be used with multiple different ones. ORMs work by using drivers for different DBMS and they implement an open database connection where the targeted database is irrelevant for the ORM itself [11]. Typically, you initialize an ORM with a connection string which tells the ORM which driver you would like to use. The mappers have their own style of writing statements and then utilizes the drivers to translate these into something appropriate depending on the targeted DBMS. 14

23 2.8. Software testing 2.8 Software testing This section presents what testing means and contains related work when it comes to evaluate solutions with DBMSs. When developing software, there is usually a product specification that works like an agreement among the software team. It specifies what and how the product will be and act, and what it will not do. Problems with the software code is often referred to as bugs. Ron Patton [18] define five different bugs: 1. The software does not do something that the product specification says it should do. 2. The software does something that the product specification says it should not do. 3. The software does something that the product specification does not mention. 4. The software does not do something that the product specification does not mention but should. 5. The software is difficult to understand, hard to use, slow or - in the software testers eyes - will be viewed by the end user as just plain not right. Verification and Validation When developing software, there are at minimum two stakeholders, the customer and the specified requirements. There are different ways to check that the software meets the specified requirements. The Verification and the Validation are two terms that relate the specification and the customer. "Verification is the process confirming that something software meets its specification. Validation is the process of confirming that it meets the user s requirements." [18] Black-box and White-box testing In black-box testing, the tester only knows what the software is supposed to do and is not able to see how it operates. The tester writes some input and gets some output, and cannot explain how it happened. In White-box testing, the tester has access to the software code and can examine the code for clues that will help with constructing the testing. The tester can also evaluate what went wrong when tests fail. Comparative study on databases Youssef Bassil [1] does a comparative study where he evaluates the performance of the top DBMSs. The DBMSs that are being evaluated are MS SQL Server 2008, Oracle 10g, IBM DB2, MySQL 5.5, and MS Access He evaluates the DBMSs on how they perform on CPU utilization, memory usage, virtual memory usage, and threads count. The databases are populated with records each. He executes five different statements with different complexity and compares the results. Eventually he comes to the conclusion of how SQL Server has a lower execution time executing queries compared to Oracle. Oracle however showed a slight advantage performing UPDATE statements compared to SQL Server. On an average of the ten statements he executed, Oracle had a higher CPU utilization as well as memory usage compared to SQL Server. 15

24 3 Method 3.1 Pre-study MasterConcept [12] contain lines of code. To get an understanding of how the program works and how it was interrelated, we searched for methods that would help us. We found three useful methods, notes/sketching, listing markup and breakpoints that are presented in section 2.1. Ides software development team uses Visual Studio [23] as developing environment. It is an Integrated Development Environment (IDE). This is what we used during development. Visual Studio enabled us to set up breakpoints in the code to follow the flow. To further improve our understanding, we sketched down the important classes and functions. To fully understand these classes and functions we applied the method about refactoring. Some functions contained over 400 lines of code. To further understand what the functions did and how the classes worked we applied the extract method presented in section 2.4. When gathering knowledge about the code, we got an insight of how the layered architecture is structured. We later used breakpoints and notes/sketching to get a full insight in how the program is structured. This was later used to answer our second research question: How should Ides keep working with their current layer architecture, with respect to multiple database providers? To structure our work, we decided to have a software developing model. Since the product already existed and was constantly developed, we looked for a model that would work for us. It was also important that we could submit the code in an easy way. With these reasons, we evaluated the development models and eventually decided to use the spiral model. 3.2 Implementation To answer our research question; In what way, could Ides become independent of database provider without affecting the current functionality? We looked for previous work and found that ORM might be a possible solution. In validation meetings with the software developer chief, we were informed that they had already tried implementing an ORM solution. But the perfor- 16

25 3.3. Software verification mance was not good enough, and therefore they were not interested in a solution based on ORM. During our research, we did not find any method that was directly applicable to our problem. Therefore, we needed to combine methods to achieve the desired result. We focused on a solution that could work for our sub-research question: How could this be implemented without affecting the performance of execution time, CPU or memory by more than 10%? By doing that we found that our solution needed to include theory and related work from: Maintainability When analyzing the code as mentioned in section 3.1, we found three direct quality aspects that we needed to include in our solution. Excessive dependencies between layers We needed a structured layer architecture to prevent the affects that might be caused. Direct communication We needed the solution to have an appropriate communication model to allow for easy maintenance. Code base is large and complex The code base that we worked with contained a large amount of code, and we needed to have clear and structured layers. Layer architecture Meier et al. [13] stated three rules presented in section 2.6. When we were developing our solution we based the interaction between the layers on strict interaction. Strict interaction was the interaction type that best fit our requirements. This is because the code will be modified over time and according to Meier et al [13], this is the interaction type to choose. Database management systems When investigating the Oracle DBMS further, we realized that it contained a lot of stored procedures and logic that we somehow needed to implement for use with other DBMSs. Because of this we figured if there was a way to write this code only once. Eventually we thought we could try to translate a stored procedure from PL/SQL code to C# code. 3.3 Software verification To fully answer our research question How could this be implemented without affecting the performance of execution time, CPU or memory by more than 10%? we needed to verify how our solution was performing. We decided to do a white-box testing based on Youssef Bassil [1] study. We chose white-box testing because we had the code and could in discussion with the developers at the company discuss which parts of the software that were interesting to test. The reason why we built the test on Youssef Bassils test is to compare our results with his. The testing we performed, contained three different parts: Old Oracle solution vs New Oracle solution This comparison was done in a network with a server-client communication. Old Oracle solution vs New Oracle solution This comparison was done on a local machine. 17

26 3.3. Software verification New Oracle solution vs New SQL Server solution 1. The statements that was tested were the following: Statements ID Statement S1_insert INSERT INTO epc_vault_data (id, version, data, data_length) VALUES (:id, :version, :data, :data_length) S2_delete DELETE FROM epc_vault_data WHERE id = :id AND version = :version AND data = :data AND data_length = :data_length S3a_select SELECT dbms_lob.getlength(utl_compress.lz_uncompress(data) FROM epc_vault_data WHERE id = :id AND version = :version S3b_select SELECT DATALENGTH(DECOMPRESS(data)) FROM epc_vault_data WHERE id = :id AND version = :version S4_update UPDATE epc_vault_data SET data = :data, data_length = :length WHERE id = :id AND version = :version S5_select SELECT sytuser_sytitems.sytitem_id id, sytuser_sytitems.sytitem_rev rev, sytuser_sytitems.cotstd_stdid stdid FROM epc_activities left JOIN epc_activities_doc ON ((epc_activities.id = epc_activities_doc.activities_id OR epc_activities.parallel_sign = epc_activities_doc.activities_id) AND epc_activities.levelseq = epc_activities_doc.activities_lvl_seq AND epc_activities.activityseq = epc_activities_doc.activities_activity_seq) LEFT JOIN epc_activities_item ON (epc_activities.id = epc_activities_item.activities_id AND epc_activities.levelseq = epc_activities_item.activities_lvl_seq AND epc_activities.activityseq = epc_activities_item.activities_activity_seq) LEFT JOIN epc_activities_task ON (epc_activities.id = epc_activities_task.activities_id AND epc_activities.levelseq = epc_activities_task.activities_lvl_seq AND epc_activities.activityseq = epc_activities_task.activities_activity_seq) JOIN sytuser_sytitems ON (epc_activities.sign_user = sytuser_sytitems.shortname AND sytuser_sytitems.cotstd_stdid = (select cotstd_stdid FROM cotprojs WHERE projid = nvl(nvl(epc_activities_doc.dotdoc_projid, epc_activities_item.item_projid), epc_activities_task.taskrequest_projid))) WHERE id = :id and levelseq = :levelseq and activityseq = :activityseq The statements were chosen with a diversity in mind. The statements are a representation of the most executed statements in MasterConcept. In addition to that, they are also based upon the statements Youssef Bassil [1] executed in his comparative study, to best be able to compare the outcome of the tests to his outcome. The statements are chosen with respect that different DBMSs utilizes CPU and memory differently. To evaluate the differences of the DBMSs a variation of commands are chosen with different complexity. In addition to the tests above, we decided to evaluate the performance between the stored procedure and the corresponding C# code we wrote. This was done both over network and on a local database. Testing environment All the statements were executed on the same computer running Windows 10 Pro. The computer s hardware consisted of an Intel Core i7-3720qm 2.60 GHz (8 cores), 16.0 GB RAM, and a 500 GB Samsung 850 EVO SSD. There were three different databases set up. One local SQL Server database, running SQL Server One local Oracle database running Oracle 11g and one remote Oracle database also running Oracle 11g. The remote Oracle database had an average latency of 16 ms during the tests. To execute the statement a small application was written. It was written in C#, using the.net Framework namespace System.Diagnostics to retrieve information about the hardware. The application runs a statement times and records the execution time, the memory usage and the CPU utilization. This is done four times calculating the average execution time, memory and CPU from all the tests. The test application is executed on a local machine, measuring its performance. The values retrieved was compared with each other. The results are presented in chapter Evaluation. 1 There exists no old version using SQL Server 18

27 4 Results The thesis has two main research questions: 1. In what way, could Ides become independent of database provider without affecting the current functionality? 2. How should Ides keep working with their current layer architecture, with respect to multiple database providers? To simplify the understanding of the result, this section has been divided into two parts each covering one of the questions. The performance evaluation of the implementation is presented in the chapter Evaluation. 4.1 Background The proposed implementation utilizes IDbConnection, IDbCommand, and IDbReader interfaces. These interfaces are a part of the.net Framework. They represent an open connection, implemented by.net Framework data providers for accessing relational databases. Below is a list consisting of four drivers used to connect to various data sources. Oracle.DataAccess.Client Driver for accessing data from a Oracle Database. System.Data.SqlClient Driver for accessing data from a SQL Server Database. System.Data.OleDb Driver for accessing data from a variety of sources in a uniform manner. MySql.Data.MySqlClient Driver for accessing data from a MySql Database. In C#, an interface contains the signatures of methods, properties, events or indexers. The IDbConnection interface contains the following properties and methods, listed below in figure 19