Theories, Theories Everywhere - PowerPoint Presentation

Slide1

Theories, Theories Everywhere

Dewayne E Perry

ARiSE

, ECE, UT Austin

perry@ece.utexas.edu

Theories D & E

I begin with two simple theories:

A theory about design – D

A theory about empirical evaluation – E

And a theory about how to model theories

My theory of software engineering:

Software engineering is composed of two things

A design D

And an evaluation of that design E:D

SE = < D, E:D >

Theory D (simplified: no iteration)

W

T

M

Model of D (simplified – no iteration)

W

The world - more specifically, the relevant part of the world –

ie

, the problem space

T

The theory initiated by observation and abstraction about the problemM A model that satisfies the theoryWT Generate a theory: observe and abstract from the world (W) to create a theory (T)TM From theory (T) create a model (M)M*WW Inject the model (M) into the world (W) - Thereby changing the worldTheory T is about behavior and constraints on behavior as we are designing dynamic systems

Theory E (basic)

W

T

R

H

Model of E (basic)

W

The world - more specifically, the relevant part of the world

T

The theory initiated by observation and

abstraction from the worldH An hypothesis to test the theoryR An regimen to test the hypothesisWT Generate a theory: observe and abstract from world (W) to create a theory (T)TH From theory (T) generate an hypothesis (H)HR From hypothesis (H) generate an empirical (evaluation) regimen (R) to test itR*WT Apply R to W and reconcile T with realityTheory T here is a theory of evaluation (of dynamic systems)

We have two Theories here

D.

T

and E.

T

D.

T is aboutTB - Behavior (functional requirements)TC - Constraints on behavior (some non-functional requirements such as performance, fault tolerance, etc)TD – domain theories that underlie TB and TCThe model D.M reifies D.TE.T is about the criteria for evaluating various aspects of theory D and its elementsEvaluating the elements: W, T, MEvaluating the mappings (processes)

Relation of D.T and E.T

The two theories have completely different

intents

D.T is about

Behavior (functional requirements)

Constraints on behavior (some non-functional requirements, such as performance, fault tolerance, etc)

E.T is about evaluation ofThe world W as the source of theory T and the recipient of model MThe theory T, and Its reification in model MThe mappings (processes) of DThere is one form of evaluation in which D.T is included in E.T:Evaluating how well model D.M reifies theory D.TVerifying that the behavior and constraints in D.T are satisfied in model D.MIE, that D.M is indeed a model of D.T

Theories about D.M are also needed

In reifying theory

D.T in D.M,

we create several new theories about the model

D.M that are useful to include in E.T for a variety of evaluations of D

T

A – a theory about the architectural structure of D.MIncludes the inter-element structure of the architectureIncludes sub-architectures of architectural elementsTS – a theory about the design/implementation structure of D.MIncludes the inter-component structureIncludes the individual component structuresTI – a theory about the (feature) interfaces of D.MIncludes the feature inputsIncludes the feature resultsTX – a theory of the external constraints on the model D.MIncludes dependent external components/systemsIncludes dependent external protocols

E.T Theories for Evaluating D.T

T

T

– evaluation theories about theory D.T

A theory about theory sufficiency

Whether D.T is sufficient to create a model D.M

A theory about theory consistencyWhether D.T is internally consistentParticularly important in the context of multiple viewpointsA theory about theory completenessWhether the theory contains all the needed behaviors and constraintsA theory about theory feasibilityWhether the theory is in fact feasible – ie, that a model can in fact be created to satisfy the theoryEtc.

E.T Theories for D.M Reifying D.T

These theories are probably the most well-understood

Well-used in practice

But less well-explicated and defined as evaluation theories

T

E

- Standard evaluation theories for D.M reifying D.TTheories of prototypingTheories of peer reviewsTheories of program analysisTheories of unit testingTheories of integration testingTheories of regression testingTheories of system testingTheories of load testingTheories of acceptance testingThese theories use the various theories mentioned earlier about D.T and D.M as needed

Theories for Evaluating D.M

The theories also indirectly evaluate D.T

T

U1

– theories of

useability

Used to evaluates the behavior, constraints, and interfaces of model D.M (and indirectly theory D.T)TU2 – theories of usefulnessThese theories are constructs representing users and their expectations, or the actual expectations of the usersTQ – theories about model qualitiesoften referred to as non-functional requirements alsoTheories of style conformanceTheories of understandabilityTheories of maintainabilityTheories of changeabilityEtc.

Theories for Evaluating D.M

T

M

- theories of model metrics

Often used in evaluating the various model qualities mentioned above as well as support various forms of analysis

Fault metrics

Complexity metrics Cohesion metricsCoupling metricsCloned code metricsCode coverage metricsEtc.

Theories about Evaluating Evaluations

We also want to know how good our evaluations are –

eg

, apply evaluations E to E:D - giving us E

:(E:D)

T

he evaluations mentioned above in evaluating theories apply also to the theories about evaluating evaluations.TV – additional theories about evaluating evaluationsTheories about the construct validity of an evaluationTheories about the internal validity of an evaluationTheories about the statistical validity of an evaluationTheories about the external validity of an evaluation

Conclusions

Not only is the devil in the details in software engineering, the devil is also in the plethora and types of theories required:

To

describe the behaviors, constraints, and domains of D.T that are to be reified in the models

D.M

To describe the structure and character of the models

D.MTo describe the structure and character of mappings (transformations or processes) in both D and ETo describe the theories about the aspects of evaluating evaluationsImagine the additional complexity of the software engineering research enterprise of designing design and evaluations and evaluating the designs of design and evaluations.D:D, D:E, E:(D:D), E:(D:E), E(E:D), etc

Summary

Simple elegance

:

two

basic elements can be used recursively to expand the full space of software

engineering

The compositions of these two basic theories expose the inherent complexity of the technical aspects of software engineeringCentrality of Theory:In the two elements of software engineering: design and evaluationThe plethora of theories neededThe fundamental importance and complexity of the empirical evaluation of both elements