Personal tools
You are here: Home Knowledge Model REPOSITORY of Terms S Static Analysis

Static Analysis

by Benedikt Liegener last modified Apr 26, 2012 11:26
— filed under:


Static Analysis
Domain: Cross-cutting issues
Engineering and Design
Adaptation and Monitoring
Quality Definition, Negotiation and Assurance
(domain independent)

Business Process Management

Service Composition and Coordination
Examples of static analysis of service compositions include: data flow analysis, model checking, execution in abstract domains, symbolic execution, type checking, and correctness proofs, which are all usually characterized because they compute properties that are in many cases approximations of the more concrete properties, but which, in this case, are safe, in the sense that the lack of accuracy must not lead to an error for the intended use of the analysis. Static analysis can be used to identify opportunities for service adaptation depending on, e.g. complexity of computation and intensity of message exchange between components of a service composition.  The complexity measures can be used for predictive monitoring.  Another use of static analysis is to drive service fragmentation, merging and migration, as well as to ensure compliance with communication protocols between components in a composition. The use of resource analysis can be used to statically derive safe bounds on complexity of a service composition, in terms of usage of logical or user-defined resources.  These indicators can be related to QoS attributes of the composition, by taking into account relevant properties of the infrastructure layer.  Complexity of different participants in the composition needs to be aggregated to express the overall composition complexity.
Service Infrastructure

(domain independent)
The aim of Static Analysis is to systematically examine a software artifact in order to determine certain properties (synthesis) or to ascertain whether some predefined properties are met (verification). Analysis can be applied at several stages in the development cycle, and therefore examples for artifacts which can be subject to analysis include requirement documents, design specifications, interface descriptions, and code.  In order to achieve these more universal statements, static analysis – unlike testing or monitoring – does not execute the artifacts which are being examined, since termination (which is theoretically ensured when the system has a finite state space) is usually a necessary condition for a successful analysis. However, systems may have a state space so large (or infinite) as to make traversing it unfeasible. In contrast to testing (or monitoring), where individual executions of the services or service-based applications are examined, static analysis can examine classes of executions. Thus, analysis can lead to more universal statements about the properties of the artifacts than testing (or monitoring), which, in a broad sense, may reflect quality attributes of a service application. 
Static analysis uses safe approximations of the actual system semantics, which makes the system actually under analysis effectively finite, but different from the initial one. Those approximations can be very sophisticated and take the form of, e.g., relations between inputs and outputs which approximate the system behavior in the domain of the analysis. When these approximations capture the properties of interest faithfully enough, then the results, even if not as accurate as they could be, are useful – and correct. Yet, as approximations might abstract away from some relevant concrete details, aspects might be overlooked or simply not be captured faithfully enough. Thus static analysis can complement the other classes of quality assurance techniques and methods but typically will not be enough, if used in isolation, in order to give a complete picture of the whereabouts of the execution of a computational system. [PO-JRA-1.3.1]






Document Actions
  • Send this
  • Print this
  • Bookmarks

The Plone® CMS — Open Source Content Management System is © 2000-2017 by the Plone Foundation et al.