10.3 The Profiles of Software Dynamics

10.3 The Profiles of Software Dynamics

When a system is exercised by a particular user, this person will exhibit a characteristic distribution of activity across the set of operations O. Some of the operations will occur with a greater likelihood than others. The distribution of user activity across the set of operations will constitute the operational profile of that user. The operational profile is a characteristic of the user. Each operation, in turn, will cause the activity of a certain set of functionalities as described by the O × F mapping. Therefore, a particular operational profile will induce a particular distribution of activity on the program functionalities. This distribution of activity across the set of functionalities is called the functional profile. The functional profile is dependent on the operational profile. Each module is exercised by one or more functionalities, as described by the F × M mapping. The functional profile will induce a particular distribution of activity on the set of program modules. This distribution of activity in the module is called the module profile. The module profile is dependent on the functional profile, which is, in turn, dependent on the operational profile. If we simply monitor the distribution of the activity of a program among its program modules for an arbitrary number of module epochs, we can characterize the operation of the system during this interval in an execution profile.

10.3.1 Operational Profile

When a software system is constructed by the software developer, it is designed to fulfill a set of specific business requirements. The user will run the software to perform a set of perceived operations. In this process, the user will typically not use all of the operations with the same probability. The design operational profile of the software system is the set of unconditional probabilities of each of the operations O being executed by the user. Let Z be a random variable defined on the indices of the set of elements of O. Then, ol = Pr[Z = l],l = 1,2,...,||O|| is the probability that the user is executing an operation l as specified in the business requirements of the program and ||O|| is the cardinality of the set of operations. A user can only be executing one operation at a time. The distribution of o, then, is multinomial for programs designed to fulfill more than two distinct operations.

As we will discover, considerable effort should be directed toward understanding just what the software should do for the user (the set of operations) and how the user will select among the operations. The prior knowledge of this distribution of the operational profile should be a principal guide to the software design process. [2], [3] It seems improbable that we would not wish to know how a system will be used before we build it. Imagine, if you will, if the designers of the Golden Gate Bridge had lacked this foresight when they built that bridge. They clearly had to anticipate both the projected traffic for the bridge and the weight of that traffic on the bridge to build the right bridge.

The design operational profile is a single point in an n-dimensional space. It is, in fact, the centroid in a range of possible departures from the design operational profile. That is, each user will use the system in a slightly different manner. This will create a slightly different operational profile represented by a different point. Let Od represent the design operational profile. Each user will have a slightly different behavior represented by an operational profile, say Ou. It is possible to compute the distance between a user's operational profile and the design operation profile as

where n represents the number of operations and 0 d 2.

In that no two users will use the system in exactly the same way, it is necessary to understand the distribution of the distances, d. Let di represent the distance between a particular operational profile for user, i, and the design operational profile. We can then talk about the average distance

for a group of m users and the variance of this distance across all users,

The real problem, from a design perspective, is that we really do not know what the mean and variance of these distances will be when the system is developed. There are two distinct solutions to this dilemma. First, we can conduct a controlled experiment to develop reasonable estimates of what these statistics will be. Second, we can design a robust system. A robust system is one that will work reliably in the face of large values of Var(d) when the system is deployed.

10.3.2 Functional Profile

When a software system is constructed by the software developer, it is designed to fulfill a set of specific functional requirements. The user will run the software to perform a set of perceived operations. In this process, the user will typically not use all of the functionalities with the same probability. The functional profile of the software system is the set of unconditional probabilities of each of the functionalities F being executed by the user. Let Y be a random variable defined on the indices of the set of elements of F. Then, qk = Pr[Y = k],k =1,2,...,||F|| is the probability that the user is executing program functionality k as specified in the functional requirements of the program and ||F|| is the cardinality of the set of functions. A program executing on a serial machine can only be executing one functionality at a time. The distribution of q, then, is multinomial for programs designed to fulfill more than two specific functions.

The qk are dependent on how the user distributes his time across the suite of system operations. We can observe and understand the conditional probability distribution of the functionalities to wit: wkl = Pr[Yn = k|Z = l]. That is, if we know the particular operation being performed, then we can determine the distribution of activity among the various functionalities.

The joint probability that a given operation is being expressed and the system is exercising a particular functionality is given by:

Pr[Yn = j Z = l] = Pr[z = l]Pr[Yn = j|Z = l] = olwjl

where k is the index for the set of functionalities and l is the index for the set of operations. Thus, the unconditional probability qi of executing functionality i under a particular operational profile is:

As was the case for the functional profile and the execution profile, only one module can be executing at any one time. Hence, the distribution of q is also multinomial for a system consisting of more than two modules.

10.3.3 Module Profiles

The manner in which a program will exercise its many modules as the user chooses to execute the functionalities of the program is determined directly by the design of the program. Indeed, this mapping of functionality onto program modules is the overall objective of the design process. The module profile p is the unconditional probability that a particular module will be executed based on the design of the program. Let X be a random variable defined on the indices of the set of elements of M, the set of program modules. Then, pk = Pr[X = j], y = 1, 2,...||M|| is the unconditional probability that the user is executing program module k as specified in the functional requirements of the program and ||M|| is the cardinality of the set of functionalities. The problem is that the module profile is not known. We can, however, determine the conditional probability of execution of a module, ujk = Pr[Xn = j|Y = k]. It can be observed by causing each of the functionalities to execute.

The joint probability that a given module is executing and the program is exercising a particular function is given by:

Pr[Xn = j Y = k] = Pr[Y = k]Pr[Xn = j|Y = k] = qkujk

where j is the index of the module and k is the index of the functionality. Thus, the unconditional probability pi of executing module j under a particular design is:

As was the case for the functional profile and the operational profile, only one event, in this case a module, can be executing at any one time. Hence, the distribution of q is also multinomial for a system consisting of more than two modules.

It is clear that pi is dependent on the functional profile. The functional profile is, in turn, dependent on the operational profile. Remember that and that . It then follows that:

10.3.4 Test Profiles

It often happens that software test activity is not based on the operational view of the system. Indeed, specific functionalities are exercised during these test activities quite independent of the distribution of the operational profile. The objective of this test activity is to verify or certify a functional aspect of the system as opposed to an operational aspect. During this test activity several functionalities may be exercised as a unit as a specific test case in a test plan. The specific module activity during this test activity will be described by a test profile.

When a program is executing a given functionality, say fk, it will distribute its activity across the set of modules, Mfk. At any arbitrary module epoch n, the program will be executing a module with a probability uik = Pr[Xn = i|Y = k]. The set of conditional probabilities where k = 1,2,...,#{F} constitute the test profile for function fk. As was the case with the functional profile, the distribution of the test profile is also multinomial for a software system consisting of more than two modules.

Both the module profile and the test profile describe the activity of the system in terms of module granularity. The module profile represents the steady-state behavior of the system under a given operational profile. This is very different from the test profile. The test activity is driven by functional test objectives and not the operational profile. A test profile, then, is an artifact of a particular test and not an artifact of the software architecture and use.

Remember that as a function of the design of a program, there may be a nonempty set of modules that may or may not be executed when a particular functionality is exercised. This will, of course, cause the cardinality of the set Mf to vary. Some test activity, for example, may cause a particular module in the set to execute while other test activity exercising the same functionality will not cause this module to be expressed. In one extreme case, the test activity may not invoke any of the modules of . On the other hand, all of the modules in may participate in the execution of a test scenario. Among other things, this variation in the cardinality of Mf within the execution of a single functionality will contribute significantly to the amount of test effort that will be necessary to test such a functionality.

The test profiles will map the activity of a system when it has been tested in a particular way. It will show us what modules have executed and the relative proportion of test activity attributed to each. This is part of the picture for the evaluation of a test. Static measurement is the other part of the test picture. Dynamic measurements will tell us where we executed; static measurements will tell us where the faults are likely to be. By combining these two measurements we will be able to evaluate the effectiveness of a particular test.

[2]Munson, J.C. and Ravenel, R.H., Designing Reliable Software, Proceedings of the 1993 IEEE International Symposium of Software Reliability Engineering, IEEE Computer Society Press, Los Alamitos, CA, 1993, pp. 45–54.

[3]Wilks, S.S., Mathematical Statistics, John Wiley & Sons, New York, 1962.



Software Engineering Measurement
Software Engineering Measurement
ISBN: 0849315034
EAN: 2147483647
Year: 2003
Pages: 139

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net