TOSE 2016 Theories Theories Everywhere Dewayne E Perry

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

Theories, Theories Everywhere TOSE 2016 Theories D & E v I begin with two simple theories: A theory about design – D A theory about empirical evaluation – E v v 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 > © 2000 -present, Dewayne E Perry 2

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

TOSE 2016 Theories, Theories Everywhere Model of D (simplified – no iteration) v v v v 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 problem M A model that satisfies theory W 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 world Theory T is about behavior and constraints on behavior as we are designing dynamic systems © 2000 -present, Dewayne E Perry 4

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

TOSE 2016 Theories, Theories Everywhere Model of E (basic) v W v T v v v H R W T v T H H R v R*W T v v The world - more specifically, the relevant part of the world The theory initiated by observation and abstraction from the world An hypothesis to test theory An regimen to test the hypothesis Generate a theory: observe and abstract from world (W) to create a theory (T) From theory (T) generate an hypothesis (H) From hypothesis (H) generate an empirical (evaluation) regimen (R) to test it Apply R to W and reconcile T with reality Theory T here is a theory of evaluation (of dynamic systems) © 2000 -present, Dewayne E Perry 6

Theories, Theories Everywhere TOSE 2016 We have two Theories here v D. T and E. T v D. T is about TB - Behavior (functional requirements) TC - Constraints on behavior (some non-functional requirements such as performance, fault tolerance, etc) TD – domain theories that underlie TB and TC The model D. M reifies D. T v 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) © 2000 -present, Dewayne E Perry 7

Theories, Theories Everywhere TOSE 2016 Relation of D. T and E. T v 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 v 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 © 2000 -present, Dewayne E Perry 8

TOSE 2016 Theories, Theories Everywhere Theories about D. M are also needed v 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 TA – a theory about the architectural structure of D. M Ø Includes the inter-element structure of the architecture Ø Includes sub-architectures of architectural elements TS – a theory about the design/implementation structure of D. M Ø Includes the inter-component structure Ø Includes the individual component structures TI – a theory about the (feature) interfaces of D. M Ø Includes the feature inputs Ø Includes the feature results TX – a theory of the external constraints on the model D. M Ø Includes dependent external components/systems Ø Includes dependent external protocols © 2000 -present, Dewayne E Perry 9

TOSE 2016 Theories, Theories Everywhere E. T Theories for Evaluating D. T v TT – 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 theory contains all the needed behaviors and constraints A theory about theory feasibility Ø Whether theory is in fact feasible – ie, that a model can in fact be created to satisfy theory Etc. © 2000 -present, Dewayne E Perry 10

Theories, Theories Everywhere TOSE 2016 E. T Theories for D. M Reifying D. T v These theories are probably the most well-understood Well-used in practice But less well-explicated and defined as evaluation theories v TE - Standard evaluation theories for D. M reifying D. T v Theories Theories Theories of of of prototyping peer reviews program analysis unit testing integration testing regression testing system testing load testing acceptance testing These theories use the various theories mentioned earlier about D. T and D. M as needed © 2000 -present, Dewayne E Perry 11

Theories, Theories Everywhere TOSE 2016 Theories for Evaluating D. M v v The theories also indirectly evaluate D. T TU 1 – theories of useability Used to evaluates the behavior, constraints, and interfaces of model D. M (and indirectly theory D. T) v TU 2 – theories of usefulness These theories are constructs representing users and their expectations, or the actual expectations of the users v TQ – 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. © 2000 -present, Dewayne E Perry 12

Theories, Theories Everywhere TOSE 2016 Theories for Evaluating D. M v TM - 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. © 2000 -present, Dewayne E Perry 13

Theories, Theories Everywhere TOSE 2016 Theories about Evaluating Evaluations v v v 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 theories about evaluating evaluations. TV – additional theories about evaluating evaluations Theories © 2000 -present, Dewayne E Perry about the the construct validity of an evaluation internal validity of an evaluation statistical validity of an evaluation external validity of an evaluation 14

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

Theories, Theories Everywhere TOSE 2016 Summary v 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 v 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 © 2000 -present, Dewayne E Perry 16