1. TOSE 2016 Theories, Theories Everywhere © 2000-present, Dewayne E Perry 1 Theories, Theories Everywhere Dewayne E Perry ARiSE, ECE, UT Austin perry@ece.utexas.edu

2. TOSE 2016 Theories, Theories Everywhere © 2000-present, Dewayne E Perry 2 2 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 =

3. TOSE 2016 Theories, Theories Everywhere © 2000-present, Dewayne E Perry 3 3 Theory D (simplified: no iteration) W T M

4. TOSE 2016 Theories, Theories Everywhere © 2000-present, Dewayne E Perry 4 4 Model of D (simplified – no iteration)  WThe world - more specifically, the relevant part of the world – ie, the problem space  TThe theory initiated by observation and abstraction about the problem  MA model that satisfies the theory  W  TGenerate a theory: observe and abstract from the world (W) to create a theory (T)  T  MFrom theory (T) create a model (M)  M*W  WInject the model (M) into the world (W) - Thereby changing the world  Theory T is about behavior and constraints on behavior as we are designing dynamic systems

5. TOSE 2016 Theories, Theories Everywhere © 2000-present, Dewayne E Perry 5 5 Theory E (basic) W T R H

6. TOSE 2016 Theories, Theories Everywhere © 2000-present, Dewayne E Perry 6 6 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 world  H An hypothesis to test the theory  R An regimen to test the hypothesis  W  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 it  R*W  T Apply R to W and reconcile T with reality  Theory T here is a theory of evaluation (of dynamic systems)

7. TOSE 2016 Theories, Theories Everywhere © 2000-present, Dewayne E Perry 7 7 We have two Theories here  D.T and E.T  D.T is about  T B - Behavior (functional requirements)  T C - Constraints on behavior (some non-functional requirements such as performance, fault tolerance, etc)  T D – domain theories that underlie T B and T C  The model D.M reifies D.T  E.T is about the criteria for evaluating various aspects of theory D and its elements  Evaluating the elements: W, T, M  Evaluating the mappings (processes)

8. TOSE 2016 Theories, Theories Everywhere © 2000-present, Dewayne E Perry 8 8 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 of  The world W as the source of theory T and the recipient of model M  The theory T, and  Its reification in model M  The mappings (processes) of D  There is one form of evaluation in which D.T is included in E.T:  Evaluating how well model D.M reifies theory D.T  Verifying that the behavior and constraints in D.T are satisfied in model D.M  IE, that D.M is indeed a model of D.T

9. TOSE 2016 Theories, Theories Everywhere © 2000-present, Dewayne E Perry 9 9 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.M  Includes the inter-element structure of the architecture  Includes sub-architectures of architectural elements  T S – a theory about the design/implementation structure of D.M  Includes the inter-component structure  Includes the individual component structures  T I – a theory about the (feature) interfaces of D.M  Includes the feature inputs  Includes the feature results  T X – a theory of the external constraints on the model D.M  Includes dependent external components/systems  Includes dependent external protocols

10. TOSE 2016 Theories, Theories Everywhere © 2000-present, Dewayne E Perry 10 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 consistency  Whether D.T is internally consistent  Particularly important in the context of multiple viewpoints  A theory about theory completeness  Whether the theory contains all the needed behaviors and constraints  A theory about theory feasibility  Whether the theory is in fact feasible – ie, that a model can in fact be created to satisfy the theory  Etc.

11. TOSE 2016 Theories, Theories Everywhere © 2000-present, Dewayne E Perry 11 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.T  Theories of prototyping  Theories of peer reviews  Theories of program analysis  Theories of unit testing  Theories of integration testing  Theories of regression testing  Theories of system testing  Theories of load testing  Theories of acceptance testing  These theories use the various theories mentioned earlier about D.T and D.M as needed

12. TOSE 2016 Theories, Theories Everywhere © 2000-present, Dewayne E Perry 12 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)  T U2 – theories of usefulness  These theories are constructs representing users and their expectations, or the actual expectations of the users  T Q – theories about model qualities  often referred to as non-functional requirements also  Theories of style conformance  Theories of understandability  Theories of maintainability  Theories of changeability  Etc.

13. TOSE 2016 Theories, Theories Everywhere © 2000-present, Dewayne E Perry 13 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 metrics  Coupling metrics  Cloned code metrics  Code coverage metrics  Etc.

14. TOSE 2016 Theories, Theories Everywhere © 2000-present, Dewayne E Perry 14 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)  The evaluations mentioned above in evaluating theories apply also to the theories about evaluating evaluations.  T V – additional theories about evaluating evaluations  Theories about the construct validity of an evaluation  Theories about the internal validity of an evaluation  Theories about the statistical validity of an evaluation  Theories about the external validity of an evaluation

15. TOSE 2016 Theories, Theories Everywhere © 2000-present, Dewayne E Perry 15 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.M  To describe the structure and character of mappings (transformations or processes) in both D and E  To describe the theories about the aspects of evaluating evaluations  Imagine 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

16. TOSE 2016 Theories, Theories Everywhere © 2000-present, Dewayne E Perry 16 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 engineering  Centrality of Theory:  In the two elements of software engineering: design and evaluation  The plethora of theories needed  The fundamental importance and complexity of the empirical evaluation of both elements