SEN4013 LECTURE NOTES, Lecture notes of Software Engineering

Download SEN4013 LECTURE NOTES and more Lecture notes Software Engineering in PDF only on Docsity!

SEN

Software Verification and

Validation

Lecture 5 Finite Models (Part I)

Learning Objectives

• (^) Understand goals and implications of finite state abstraction
• (^) Learn how to model program control flow with graphs
• (^) Learn how to model the software system structure with call graphs

Models

• (^) Models permit us to start analysis earlier and repeat it as a design evolves and allows us to apply analytic methods that cover a much larger class of scenarios than we can explicitly test.
• (^) Many of these analyses may be automated.

Model

• (^) A model is a representation that is simpler than the artifact it represents but preserves (or at least approximates) some important attributes of the actual artifact.
• (^) We will focus and analyze models of program execution. - (^) Models of other (equally important) attributes such as the effort required to develop the software, or its usability will not be analyzed.

Properties of Models

• (^) Predictive : must represent some salient characteristics of the modeled artifact

well enough to distinguish between good

and bad outcomes of analysis

• (^) no single model represents all characteristics well enough to be useful for all kinds of analysis - (^) For example, one would not use the same model to predict airflow over an aircraft fuselage and to design internal layout for efficient passenger loading and safe emergency exit.

Properties of Models

• (^) Semantically meaningful : it is usually necessary to interpret analysis results in a way that permits diagnosis of the causes of failure - (^) If a finite-element model of a building predicts collapse in a category five hurricane, we want to know enough about that collapse to suggest revisions to the design. - (^) If a model of an accounting system predicts a failure when used concurrently by several clients, we need a description of that failure sufficient to suggest possible revisions.

Models

• (^) Since design models are intended partly to aid in making and evaluating design decisions, they should share these characteristics with models constructed primarily for analysis.
• (^) Some kinds of models, notably the widely

used UML design notations, are designed

primarily for human communication, with less attention to semantic meaning and prediction.

Models

• (^) Models are often used indirectly in evaluating an artifact.
• (^) For example, some models are not themselves analyzed, but are used to guide test case selection.
• (^) In such cases, the qualities of being predictive and semantically meaningful apply to the model together with the analysis or testing technique applied to another artifact, typically the actual program or system.

Graph

• (^) In discrete mathematics , a graph is a collection of points, called vertices, and lines between those points, called edges.
• (^) There are many different types of graphs , such as connected and disconnected graphs, bipartite graphs, weighted graphs, directed and undirected graphs, and simple graphs.

Graph Representations:

directed graphs

• (^) A directed graph is composed of a set of nodes N and a relation E on the set (that is, a set of ordered pairs), called the edges.
• (^) It is conventional to draw the nodes as points or shapes and to draw the edges as arrows.

Graph Representations:

directed graphs

• (^) Typically, the nodes represent entities of some kind, such as procedures or classes or regions of source code.
• (^) The edges represent some relation among the entities. - (^) For example, if we represent program control flow using a directed graph model, an edge (a, b) would be interpreted as the statement “program region a can be directly followed by program region b in program execution.”

Graph Representations:

labels and code

• (^) We can label nodes with the names or descriptions of the entities they represent. - (^) If nodes a and b represent program regions containing assignment statements, we might draw the two nodes and an edge (a, b) connecting them in this way: x = y + z; a = f(x);

Graph Representations

• (^) Drawings of graphs can be refined in many ways, for example, depicting some relations as attributes rather than directed edges.
• (^) Important as these presentation choices may be for clear communication, only the underlying sets and relations matter for reasoning about models.

Finite Abstractions of

Behavior

• (^) A single program execution can be viewed as a sequence of states alternating with actions (e.g., machine operations). - (^) We put aside, for the moment, the possibility of parallel or concurrent execution. - (^) Most but not all models of concurrent execution reduce it to an equivalent serial execution in which operation by different procedures are interleaved, but there also exist models for which our treatment here is insufficient.
• (^) The possible behaviors of a program are a set of such sequences.
• (^) If we abstract from the physical limits of a particular machine, for all but the most trivial programs the set of possible execution sequences is infinite.
• (^) That whole set of states and transitions is called the state space of the program.
• (^) Models of program execution are abstractions of that space.