MATERA: A Systematic Modeling Process

MATERA is our proposed UML-based modeling approach for systematic development of system models for automatic test generation. A system- atic approach ensure that models are created in a step-by-step manner and, therefore, is more structured than an ad-hoc approach. As stated in the introduction, models allow one to focus on the relevant part of a problem and hide away implementation details. The basis for choosing UML as the modeling language for our approach was that is a modeling language wide a very wide user base and known to many. It is also used extensively in the industry. Another reason for choosing UML is that we wanted to show that system design models are not only suitable for design but can also be used for deriving test cases.

Figure 2.1 shows an overview of a typical MBT process and the parts of the process that MATERA addresses. As stated in the introduction, test generation and execution has for the most part already been solved. Hence, the MATERA approach focuses on modeling and how to create system mod- els in a systematic way.


                      

       

   

     
        ! "   
    #$%&'$

Figure 2.1: Overview of the MATERA and the MBT process. In the MATERA approach, system models are created in a systematic fashion. Figure 2.2 depicts the MATERA process. The process is divided into five stages. First, we start by reviewing standards and specification doc- uments and we analyze the stakeholder requirements related to the product. The time required to complete this phase depends on the amount of infor- mation that has to be analyzed. In the second phase, we construct a feature diagram and a requirements diagram based on the information gathered from phase one. The feature diagram (Figure 2.3) depicts different charac- teristics of the system and shoes how they are decomposed into sub-features. The idea is that every feature maps to a high level system functionality re- quested by a customer. For every feature, a requirements diagram (Figure 2.4) is constructed.

Figure 2.2: The MATERA Modeling Process.

The requirements diagram capture all the system level requirements and presents a general overview of the requirements. We start by modeling a single requirement which maps to a system feature. From here, the re- quirements are decomposed into sub-requirements based on the information gathered from the first phase. This process in repeated until we reach re- quirements that are testable or no further sub-requirements are identified. The requirements can also be given a priority value. The priority value indicates the importance of a requirements and is in later stages of the test- ing cycle used to order test cases based on their importance. The priority values are considered to be given from external sources (e.g., system re- quirements or stakeholder recommendations) and known a priori before the first iteration of the testing process. In later cycles, the priority values can be adjusted based on statistics of untested requirements from previous test cycles for targeting the testing process towards a certain part of the SUT.

In the third phase we construct use case diagrams and sequence dia- grams from information contained in the requirements model. The use case diagram (Figure 2.5) specify how system functionality is provided to its environment. It shows how users access different system functionality, rep- resented as a use case. Every use case have a detailed description of pre- and post-conditions, sub-cases, and a tabular format for specifying the necessary message communication between actors and the systems in order to com-

Figure 2.3: Example of a feature Diagram.

Figure 2.4: Example of a requirements diagram.

plete a use case. This process is repeated for every identified use case. Use cases also have a probability value that indicates the chance for a user re- questing that functionality from the system. The probability value together

Figure 2.5: Example of a use case diagram.

with priority values for requirements make up the back bone for ordering test cases based on their importance. For every use case, a sequence dia- gram (2.6) is constructed. The sequence diagrams primarily describe the interactions between system components in a sequential order. They can also show the messages that are sent between actors participating in a use case. The exact order of the message exchange is normally extracted from various protocol specification documents and standards.

Figure 2.7: Example of a domain model.

In the fourth phase, we create a set of models that describe the archi- tectural and behavioral parts of the system. From this we introduce three different models, a domain model, a state machine model, and a data model. The domain model (see figure 2.7) depicts the system and how it is con- nected to other components. The domain model also shows the interfaces used for communication between the components. Every interface have two channels, one for sending and one for receiving messages. The domain model is derived from sequence diagrams and is built iteratively.

Every object found in the sequence diagrams is represented as a class in the domain model. The interfaces are obtained from the messages sent and received by different object in the sequence diagrams. For every class in the domain model we construct a state model (Figure 2.8). The state model describes the behavior of an entity in terms of states and transitions. A transition can be seen as an event where the system is either sending or receiving an input and, thus, resulting in switching from one state to

Figure 2.8: Example of a state machine model.

another. By overlapping the message comminution each sequence diagram a state model is constructed for each system component. The resulting state model may also contain composite states. A composite state is simply a state containing other states and is a way to abstract or reduce the complexity of a state model and make it more readable.

Figure 2.9: Example of a data model.

We also need a description of the data used in the system. For this purpose, we introduce a data model (see Figure 2.9). This model depicts

the messages related to a specific protocol and we use inheritance to model common parameters. Each message is represented by a class and the message parameters are modeled as class attributes. The data model is built via an iterative process in where we gather information from protocol standards and various requirements documents. Every class in the data model is linked to a message in an interface in the domain model. This is done to ensure traceability throughout the whole process.

Figure 2.10: Example of a test configuration diagram.

In the last phase, we employ a test configuration model. This model is an instantiation of the domain model and shows a particular configuration at a particular time of the test environment. For example, Figure 2.10 shows a system under test (SUT) connected to two test components, TC1 and TC2. All of these object are instantiations of different components. At this time, different class attributes or test parameters get their specific values.