Result Representation Sample Clauses
Result Representation. The result of the Level 1 analysis will be available in textual and graphical form. The tex- tual form will present the collected information to the user in detail. It can be viewed at application, component, class or method level. For example at method level the result will show every method with a reference to its unique source and the connected set of permissions. On the other hand the graphical result representation of the SUMMARY and the COMPARISON mode will be limited to application and component level, because the graphical representation should be used to get an overview while all the details are provided in the textual representation. In case of the COMPARISON mode there are two possibilities:
1. Two different Applications are compared: In this case components, classes and methods of both Applications mostly have nothing in common and it will be sufficient to provide an application level representation.
2. Two versions of the same App are compared: In this case the components should be more or less the same. Therefore, the tool will provide the component and application level result representation. The tool might not be able to decide which case is investigated. This question will be answered in the Architecture Document. Depending on the availability of this information, the tool will show a warning message to the user if Case 1 is investigated. Nevertheless, the application and the component level representation will always be available. The saved result will provide information on statement level, too. This is needed to be able to reuse the result in the Level 2b analysis (see Section 3.4). Further the tool will have options to filter the analysis result in order to have a closer look at a subset of the detected permissions. There will be possibilities to filter the result accordingly to the five groups (REQUIRED, MAYBE REQUIRED, UNUSED, MAYBE MISSING, MISSING) and to filter out a single permission.
Result Representation. In SUMMARY mode the tool will show the flow from sources to sinks. In the final result, the user can filter the flow from a specific source to a specific sink. The tool supports both textual and graphical result representation. The provided result of the COMPARISON mode is based on comparing the previous result with the latest analysis result. Similar to the SUMMARY mode, users can filter the flow details from the specific sources to specific destinations. Provision is available for the user to save the 5As mentioned by Arzt, ▇▇▇▇▇▇▇▇▇, ▇▇▇▇▇, ▇▇▇▇▇▇, ▇▇▇▇▇▇, ▇▇▇▇▇, le Traon, ▇▇▇▇▇▇ and ▇▇▇▇▇▇▇▇ in FlowDroid: Precise Context, Flow, Field, Object-sensitive and Lifecycle-aware Taint Analysis for Android Apps; Proceed- ings of the 35th ACM SIGPLAN Conference on Programming Language Design and Implementation, ACM, 2014 provided result, too. The user can also load an existing file for reviewing the previous analysis result saved in that file.
Result Representation. Like in Level 1 the resource usages will be assigned to five groups REQUIRED, MAYBE RE- QUIRED, UNUSED, MAYBE MISSING and MISSING. In addition, for Level 2b we will distinguish between the direct and indirect usage of resources. Therefore, we will also subdivide each group into this two categories and end up with ten groups overall. The filtering options will be the same as in Level 1. It will be possible to filter by groups and to filter out a single permission. But filtering by groups will consider all 10 groups now. Since all warning and error messages noticed in the Requirement Specification Document will be supported, the tool will give an error message if the group MISSING appears in the result. Equally the tool will give a warning message if the group UNUSED or MAYBE MISSING appears in the result. This holds for both direct and indirect resource usages. The results will be presented to the user in textual and graphical form as for previous levels depending on the chosen mode and detail level. Since this analysis is restricted to the detail levels app and component, the result representation will be restricted in the same way. The output (textual and graphical) will be equal to those shown in Figure 17 in the Requirement Specification with the option of improvements for a even better user experience. Another graphical result representation could be a visualization of the usage graph extended with edges for indirect resource usage equal to Figure 13 in the Requirement Specification Document. Both representations will be computed for all results. But the visualization of the extended usage graph is a pending feature and might not be implemented. An example for such an edge would be one between Component II of Application 2 and Permission B in Figure 4. All in all, the results can be interpreted by the user as in Level 1 but here they additionally show indirect resource usages for an App through other non-native Apps.