Unified Model for Testing Object-Oriented Application Development Tools

. The paper presents a unified model for testing tools for object-oriented application development. Based the available papers were identified shortcomings of existing work and identified the following optimal criteria, which shall comply the resulting model:


Introduction
At the moment there are many tools provide object approach to application development. Despite the existence of their own advantages and disadvantages the main goal is provide the advantages of the developer of object-oriented paradigm. The paper are describes in detail the unified model test tools development of objectoriented applications for demonstration, graphical Unified Modeling Language which used. The practical implementation of the model is demonstrated by the use of classical methods (patterns) object-relational mapping (ORM) in the tool, developed the author. The object model is put into a relational database environment. This approach is most justified from the point of view the author, because the RDBMS is the most popular type of database management systems now.

Design of the unified testing model
When designing a unified testing model used the same approach as in the description of the design patterns in [1]. This approach is involves the description of reusable solutions widespread problems in software development without reference to particular domain. The main task of this section -is a description of the model and the structural elements (classes and associations), and not the correctness of the model and the accuracy of its fitness for a particular domain area. Standard graphical language modeling various aspects of object systems is the language UML. This language is namely structural class diagrams will be discussed in this paper. As a result under the unified model test tools development of objectoriented applications we mean a class diagram, consisting of classes and attributes and containing common practice relationship classes. The idea of the article is not new and there are works of similar subjects. In [2] has attempted to construct a unified model testing. However, there were no multiple (nary) associations and association with attributes that are an integral part of any complex information system. In [3] presented test model to study the design of object-oriented databases. But the model is relatively simple, which is justified by its purpose. This article used dignity previously existing works and corrected drawbacks of them. Before designing a unified model testing were nominated optimality criteria (OC) is representing the requirement of a certain structural elements in the class diagram, and which must comply with the finished implementation. Have been put forward the following requirements for the unified model test tools development of objectoriented applications: 1. Must have deep inheritance hierarchies. In realworld applications, very often there are deep hierarchy, is the relational of inheritance and combining transitive least three classes. 2. To presents of multiple inheritance hierarchies. This will show a variety of options and modes available in the development tool. 3. To presents of abstract classes in the hierarchy. Abstract classes cannot have instances in the system and described as a container for attributes and methods used in the inherited (instantiated) classes. 4. To presents of multiple (n-ary) associations. In applications that automate realworld domains, often an association involving three or more classes. Such a relationship is called multiple or n-ary associations. 5. To presents of associations with attributes. Many domains contain attributes that do not belong to certain entities (classes), and their values appear only in the organization of associations between instances of classes. The designing unified model should have associations with attributes. 6. To presents of a composition between classes. Composition -an association between the classes which are Part and Whole. The peculiarity is that the class represents a Part can belong to only one instance of the class that represents the Whole. In this class represents the Whole manages the life cycle is a class represents a Part. When removing the Whole all Parts also deleted. This peculiarity of behavior is very important for many application domains. 7. To presents of recursive associations. Recursive call the association, the ends of which bind the same class. These relationships allow you to implement a hierarchy of subordination. 8. To presents of associations between classes belonging to the same inheritance hierarchy. In terms of implementation is necessary to provide the implementation of the association, the edges of which are associated classes belonging to the same inheritance hierarchy, are represents the base class and the child together. 9. To presents of association classes. Association class -an association which at the same time a class. Especially the use of that class association represents a unique association, i.e. combination of instances of classes in this association is unique. 10. To associationed between the association class and other classes. From a theoretical point of view, the association class is a class, so it can participate in other associations. From the point of view of the implementation of the class association presents a class that contains the attributes (fields or properties of the programming language) that refer to other classes. In turn, for the organization of the association with the class association necessary depending class to create an attribute whose type supports class association.
11. To presents enumerations in model. From a theoretical point of view, enumeration is a set of predefined constants, and the user can not extend this set by adding new values. In accordance with the selected criteria was implemented hierarchy shown in Fig. 1.

Fig. 1. Unified model for testing object-oriented applications development tools
Consider the appointment of the main classes of diagrams are presented. As mentioned earlier this class diagram is a fictional and is not intended to describe a particular domain therefore contains some illogical (fictional) classes and associations. For representation of employees and organizations assigned to the base abstract class Contragent. Inherited Company class is present organizations and the class Worker is the base for the employee of organization. Inherited Employee class is an employee and an attribute EID, representing the employee unique number. Class Manager is the staff who are heads of other workers. Post an abstract class is a position that can be occupied by staff. Inherited class ExperiencePost is a position that requires a minimum amount of experience of the applicant, expressed as number of months (attribute MinExperMonth). The second class is implemented ScientificRank describes the position of the applicant, which requires the presence of a scientific degree, whose name is value in the attribute AcademicRank. For presentation departments of organizations and entering into an n-ary association a class of Department was introduced. Salary class is paid wages, accrued to employees occupying positions represented by a complex association which called Position. Class Telephone allows saving the number of phone of company. Phone type (like Home, Personal, Work) represented by enumeration TelephoneKind. For presentation address used by the base abstract class Address. Two derived class CompanyAddress and EmployeeAddress used to represent the address of the organization and address of the employee, respectively.
Check the conformity of the model presented previously selected criteria of optimality. The need for a deep class hierarchy, represented by at least three transitive inherited classes, described OC1 and implement a class Contragent, Worker, Employee, Manager. In addition to this, there are two hierarchies: 1) Post, ExperiencePost (ScientificPost); 2) Address, CompanyAddress (EmployeeAddress). I.e. the model contains multiple inheritance hierarchies, therefore, the condition OC2. The presence of abstract classes in the hierarchy due OC3 and holds classes Post, Contragent and Address. OC4 requirements are also performed as there are n-ary association Position, combining classes Post, Department, Worker, Company. Described association has an attribute Rate, which implemented class association and binary association between Employee and EmployeeAddress classes also contains an attribute (IsRegistered) it can be argued that the requirement OC5 fulfilled. Each contractor represented derived from Contragent classes, a list of telephone numbers represented instances of Telephone, and both classes related with composition, OC6 requirement is satisfied. Unified model allows you to store information about a group of companies, organize the tree structure using a recursive association connects Company class with a same. The presence of recursive association dictated OC7. In OC8 written requirement for associations between classes belonging to the same inheritance hierarchy. Figure 1 between classes Employee and Manager provides this association satisfying OC8. As previously noted, the models have a association class Position, which corresponds OC9. Described association class is linked with addition association with Salary class. This is a consequence of the implementation OC10. The presence of the models listed due to the implementation of OC11. Of the present disclosure can be seen that the unified model is fully consistent with all previously selected criteria of optimality. Therefore we can move on to the implementation of the unified model.

The classical object-relational mapping patterns
To implement of this model development environment software systems based on the organization of the metamodel object system presented in [4][5] was used. This development environment is called SharpArchitect RAD Studio and as storage of information uses a relational DBMS. Because information system is designed in terms of object-oriented paradigm, and implemented in a relational database environment, there is a so-called "object-relational impedance mismatch" to overcome the consequences of which object-relational mapping patterns are used. The most commonly used patterns for represent the class hierarchy. In SharpArchitect RAD Studio implemented three classic patterns for implementing object-oriented inheritance relationships of classes in a relational structure (relational tables), presented in Fig. 2  Consider the basic patterns is presented in more detail. Single Table Inheritance pattern physically represents an inheritance hierarchy of classes in a single relational database table whose columns correspond to the attributes of all classes within the hierarchy and allows you to display the structure of inheritance and to minimize the number of joins that must be performed to extract information. In this pattern each instance of the class represented by one row of the way to optimize the query (to reduce the execution time) is created a covering index. However, the index set and a large number of queries to a single table can lead to frequent blockages that will have a negative impact on the performance of software applications. An alternative pattern is called Class Table Inheritance, representing a hierarchy of classes for one table for each class (as an abstract and concrete). Class attributes are mapped directly on the columns of the corresponding table. With this method, the key is the task of joins the respective rows of several database tables that represent a single object of domain. The pattern has the following advantages: • Each table contains a field, the corresponding attribute of a certain class.
The therefore tables are easy to understand and take up little space on your hard drive. • The relationship between the object model and relational database schema is simple and clear.
Single Table Inheritance pattern   Class Table Inheritance Concrete However, there are disadvantages: • When you are create an instance of a particular class you want to upload data from several tables, which requires either their natural joins or a plurality of database calls followed by join results in memory. • Move the fields in the derived class or base class requires changes in the structure of several relational tables. • Base class table can become weaknesses in performance, since access to such tables will be carried out too often, leading to a variety of locks. • High degree of normalization can be an obstacle to the implementation of unplanned advance queries. The Concrete Table Inheritance pattern present is an inheritance hierarchy of classes using one table for each concrete (non-abstract) class of the hierarchy. From a practical perspective, this pattern assumes that each instance of the class (object), which is in memory, will be shown on a separate row in the table. In addition, each table in our case contains columns corresponding to attributes as a particular class, so all of his ancestors. The advantages are that: • Each table not contains extra fields, so that it is convenient to use in other applications that do not use object-relational mapping tools. • When creating objects of a certain class in the application memory and retrieve data from a relational database sample is made of a single table, i.e. is not required to perform relational joins. • Access to the table is carried out only in the case of access to a particular class, thus reducing the number of locks imposed on the table and spread the load on the system. There are disadvantages: • Primary keys can be inconvenient by handling.
• There is no ability to model relationships (association) between abstract classes. • If the class attributes are moved between base classes and derived classes needed to change the structure of several tables. These changes are not as often as in the case of Class Table Inheritance pattern, but they cannot be ignored (as opposed Single Table Inheritance pattern in which these changes are absent). • If in base class to change the definition of at least one attribute (for example, change the data type), it will require to change the structure of each table representing a derived class because a superclass fields are duplicated in all tables of its derived classes. • In implementing the method of searching for data in the abstract class is required to view all the tables represents an instance of the derived classes. This requires a large number of database calls.
Selection of an required ORM-pattern depends on the initial logical model, i.e. from the class hierarchy of the domain. At the same time can be used two or more ORMpatterns, which is associated with the need to optimize the structure of a relational database and reduce the number of tables used, which will increase the speed of data retrieval queries. After describing SharpArchitect RAD Studio object-relational mapping patterns which are available to the developer we can start implementing the unified model for testing tools.

Implementation of the unified testing model
In order to simplify the implementation of the three existing class hierarchies in Fig.  1 will separate in available ORM-patterns. The result is shown in Fig. 3.

Fig. 3. The using of the classical ORM-patterns for the implementation of the unified model for testing object-oriented applications development tools
The Single Table Inheritance for the class hierarchy Post, ExperiencePost (ScientificPost) was used. As a result, it is assumed that in the RDB will create one single table (relational table), which will be retained instances of all listed nonabstract classes. For the class hierarchy with classes Contragent, Worker (Company), Employee, Manager uses the Class Table Inheritance pattern. I.e. for all classes regardless of whether he or abstract concrete will create a separate table in RDB. Address class is abstract and has no association with other classes in model, so it will not create a separate table in the RDB. And for child classes will be created two tables (one for each heir). I.e. in hierarchy Address, CompanyAddress (EmployeeAddress) was used Concrete Table Inheritance. For other classes outside the hierarchy described, will be created on a separate relation table.
One of the main features of SharpArchitect RAD Studio support multiple inheritance is implemented by means of interfaces C# language construction, as described in detail in [4]. Used C# language does not support this syntax as an association. To represent the binary associations, regardless of the multiplicity was 110 used properties (property construction), containing a single value or collection of values. Multiple n-ary association are represents a separate class, the attributes of these associations (as well as the attributes of binary associations) are converted into property of classes. To simplify information searching and extraction of all the associations are bidirectional both ends of the relevant classes there are properties whose type corresponds to the opposite end of the class association. All of the above arguments are presented graphically in Fig. 4.
In implementing the interfaces used language C#, so it is impossible italics abstract classes. Bidirectional associations are shown corresponding arrows connecting classes. In implementing the association used the following approach. From the "one" was declared property, which is a type of list (C# type IList<>), containing the elements, which is a type of class, located on the side "to-many". From the "tomany" is declared in the class property whose type is a class, located on the side "one". Association of the "many-to-many" (without attributes) can be represented by two lists is declared in class antagonisms. In a SharpArchitect RAD Studio development environment has a number of base classes that implement the most common functionality. For example, the class IBaseRunTimeDomainClass is the root of all domain classes. To implement the tree structure will enough inherited from IBaseRunTimeTreeNodeDomainClass. At the time code generation will automatically generate additional attributes Nodes and Owner, allow you to save a reference to the parent and subnodes, respectively. It is implemented in such a way recursive association. For submission to the transfers and sets used syntax construction "enum". Applying the classical ORM-patterns was obtained relational database schema of the unified model now. Fig. 5 is depicts the result.   Table Inheritance pattern have been created for the table  Contragent for abstract class and table Worker

Conclusion
Further development of the unified model is to test the feasibility of a variety of application development environments. In this alternative implementation is planned and using the approach presented by other authors dealing with similar scientific problems.