What does Software Engineering need to become an Engineering Discipline?

Transcription

1 What does Software Engineering need to become an Engineering Discipline? Prof. Dr. Ralf Reussner SOFTWARE DESIGN AND QUALITY GROUP INSTITUTE FOR PROGRAM STRUCTURES AND DATA ORGANIZATION, FACULTY OF INFORMATICS KIT University of the State of Baden-Wuerttemberg and National Research Center of the Helmholtz Association

2 Engineering Development [Shaw&Garlan95] Engineering Craft Customer and user often same person Experience and talent Instead of systematic methods Manufacturing division of labor trained specialists use of specialized tools Understanding the impact of design Decisions before implementation Through understanding of products and production processes Theories are needed 2

3 What do we need? Systematic exploration of the design space Understanding of the impact of design decisions Expressing and changing designs (much faster than code) This enables: Truly Agile developmemt less try and error less permanent re-invention of wheels avoidable refactoring efforts Automatisation (optimisation) where possible Better designs Better reuse of design knowledge 3

4 Two projects (actually all my research life) Palladio (Methods and Tools for Predicting Performance and Reliability of Component-Based Software Engineering) Andrea di Piero della Gondola, genannt Palladio ( ) Vitruvius (VIew-cenTRic engineering Using a VIrtual Underlying Single model) Marcus Vitruvius Pollio (80 70b.c. 15b.c.) 4

5 Simulation of Software Architectures Palladio: ( CV: DFG funded project ( Aktionsplan Informatik, Emmy-Noether), EU funded 2010 till today: open source and Industry (ABB, IBM,...) and public funding (KIT, FZI, UPB, TU Chemnitz, Univ. Zürich,...) comprising 1. Architectural Modelling Language 2. Simulator for performance, ressource utilisation, reliability, (energy consumption) and maintainability 3. Design Method 4. Reengineering Tools 5

6 Treatment of Quality Properties Today 1. Specification 2. Ignoring 3. Testing 4. Re-Implementing / Re-Designing / Re-Negotiating 6

7 Why do we want to predict quantitative Properties? Model View Controller vs. View View Controller Model vs. Evaluation of Design Alternatives the quantifiable best of a list of many trade-off decisions cost vs. benefits QA a vs. QA b Dimensioning of Resources ( Sizing ) vs. Changes of usage profile Scalability 7

8 Empirical Case Study: How wrong Intuition can get Übung Experiment 24 Personen 8 Personen 8 Personen 8 Personen Intuitive Bewertung 7 Personen Training SPE (2 Stunden) SPE (2 Stunden) CP (2 Stunden) umlpsi (2 Stunden) Ohne Verfahren SPE-Übungszettel (21 korrekte Abgaben) Erstellung Performance Modell Erstellung Performance Modell Erstellung Performance Modell Training CP (2 Stunden) Modellierung Alternative 1a Modellierung Alternative 1a Modellierung Alternative 1a Bewertung Alternative 1a CP Übungszettel (12 korrekte Abgaben) Modellierung Alternative 1b Modellierung Alternative 1b Modellierung Alternative 1b Bewertung Alternative 1b Training umlpsi (2 Stunden) Modellierung Alternative 2 Modellierung Alternative 2 Modellierung Alternative 2 Bewertung Alternative 2 umlpsi Übungszettel (3 korrekte Abgaben) Modellierung Alternative 3 Modellierung Alternative 3 Modellierung Alternative 3 Bewertung Alternative 3 Besprechung Musterlösung (2 Stunden) Modellierung Alternative 4 Modellierung Alternative 4 Modellierung Alternative 4 Bewertung Alternative 4 Implementierung und Messung 8

9 Web Server Web Server C# implemented Component based HTTP Dispatcher IAcceptRequest Dispatcher Thread IParseRequest Request Analyzer IServeRequest Request Processor IDeliverResponse Static File Provider CGI - Interface IGetResponseStream Exe - Engin HTTP IMonitorWebserver ExtAppInterface ExtApp WebService DB Access DB 9

10 Design Alternatives 1. Cache Static: Memory ó Hard disk access Dynamic: Memory ó Network access 2. Single threaded Server Context switch ó response time 3. Compression Processor time ó Bandwidth 4. Clustering Parallelisation ó Costs of balancing 10

11 Usage Scenario 40% requests for static pages (HTML, JPG) 60% requests for dynamic pages (HTML) file size 5 KByte Client ð Web Server: ISDN (64 KBit/s) Web Server ð DB-Server: Ethernet (10 MBit/s) Computation on DB-Server: 0.5 seconds Continuously one request per second 11

12 Results Durchlaufzeit in Sekunden 3,5 3,0 2,5 2,0 1,5 1,0 0,5 0, Messung Teilnehmer mitt. quad. Abweichung 0: keine Optimierung 1,1928 2,9415 0,9562 1,3168 1,5503 1,8476 2,3094 0,6845 1,5100 0,7009 1a: statischer Cache 1,1883 2,9338 0,9499 1,3108 1,5196 1,8204 2,3030 0,6200 1,5300 0,7055 1b: dynamischer Cache 1,1317 2,8670 0,8981 1,2545 1,4868 1,7826 2,1478 0,5800 1,4400 0,6910 2: single-threaded 0,9546 1,3482 1,5477 1,8428 2,3944 1,5600 0,4874 3: Komprimierung 0,8188 1,6856 0,7096 0,8766 1,2979 1,1221 1,8822 0,6089 0,8100 0,5370 4: Clustering 1,1952 2,9367 0,9588 1,3152 1,5323 1,8421 1,9892 0,6878 1,6500 0,6656 Compared to control group (intuitive approach ): 4 out of 7 failed! 12

13 Model-based Prediction of Quantitative Properties Executable Software UML, ADL, Software Design Model Results Analysis Results Response time Throughput, Utilisation, Transformation (MDD) Estimation Measurement Analysis / Simulation Automated by Tools UML Performance Profile, QML, Annotated Software Design Model Transformation (MDD) Analysis Model Queuing models Stochastic Petri-Nets, Stochastic Process Algebra, 13

14 Scientific Approach to Create Quantitative Models Modell of Software (with Annotations) Prediction Predicted Quality Improvement / Extension Interpretation Abstraction Acceptance / rejection of abstract model Comparison Software Measurement Measured Quality 14

15 Validation of Quantitative Models Type 1: Validation of Prediction Model Type 2: Validation of Applicability Case Studies and Controlled Experiemts with Students Typ 3: Validation of Benefits in comparison to different methods Limitations of the Approach Required prerequisites FZI Industrial Partners 15

16 Stochastic Regular Expr. Analysis Comp.Dev. DSL Instance Palladio Component Model SPA with Scheduling Analysis + Simulation Soft. Arch. DSL Instance Part of Transformation Queueing Network Simulation Sys. Depl. DSL Instance Instance Dom. Exp. DSL Instance Performance Prototype Execution + Measurement Java Code Skeletons Completion + Compilation 16

17 Component Developers Software Architect System Deployer Domain Expert 17

18 18

19 Factors on Quantitative Component Properties Motivation } SW Components } Quality Prediction } Conclusions 19

20 Execution Time of a()? a(list, count): a()? ms ComponentA b() c() 2m s 3m s ComponentB d() 5m s ComponentC Service Effect Specification (SEFF) Motivation } SW Components } Quality Prediction } Conclusions 20

21 Tool Support 21 (Quelle: Fraunhofer-ISST)

22 Results 0,08 0,07 0,06 Probability 0,05 0,04 0,03 0,02 0,01 0, Response Time (Seconds) 22

23 Results 1,0 0,9 Cumulative Probability 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0, Motivation } SW Components } Quality Prediction } Conclusions Response Time (Seconds) 23

24 Two projects (actually all my research life) Palladio (Methods and Tools for Perdicting Perforamce and Raliability of Component-Based Software Engineering) Vitruvius (VIew-cenTRic engineering Using a VIrtual Underlying Single model ) Marcus Vitruvius Pollio (80 70b.c. 15b.c.) 24

25 Why are views important? We need several views Different roles, different expertise, sheer size Consequently, all engineering disciplines have various different views (in form of plans, charts, lists, etc describing one system) Only in software engineering people wrongly think, code is the sole artifact ( code-centric development ). Reasons: Avoidance of high costs of manual modelling and consistency keeping Historic understanding of software: code contains all information Quelle: wikipedia 25

26 Motivation scenario: Software Engeneering «describes performance» simulation results WebGUI MediaStore component model «shows elements from» «implements» WebGUI MediaStore component model implements WebGUIImpl WebGUIImpl WebGUI implements UiInfo UiInfo GUILayout class diagram component-class implementation view «refines» public class WebGUIImpl implements IHTTP { public File HTTPDownload (Request request) { //Handle request } } source code 26

27 Motivation scenario: Engeneering scenario «refines» «similar concepts» «refines» 27

28 Problem in the Scenario Fragmentation information is spread over heterogeneous models mappings are not made explicit Redundancy same piece of information is represented in multiple elements Inconsistency arises from redundancy and fragmentation violation of semantic relations Complexity Users/developers cannot understand entire models navigation is difficult 28

29 Projective vs. Synthetic approach view 2 view 1 view 3 view 7 view 4 view 5 view 6 29

30 Backup Orthographic Software Modeling (OSM) Definition: Single Underlying Model (SUM) (after: Atkinson, Stoll, and Bostan 2010) complete definition of a system contains all information that can be expressed using well-defined description formalisms displayed or manipulated exclusively by specific views described by a SUM metamodel the SUM metamodel is method- or project-specific Views and View-types Views are normal models that have been generated dynamically contain only transient information which is generated from the SUM View Types are the metamodels of which the views are instances Motivation State of the art Vitruvius approach Synchronization Views Conclusion

31 A modular SUM metamodel VT 3 VT 2 implements C 1 comp 2 comp 1 component diagram view VT 4 Sensor PCM MIR UML comp 1 implements C 2 component-class implementation view VT MIR 1 C 1 simulation results view VT 5 Java VT 6 C 2 C comp_1) public class C2 extends C1 { public static void main (String[] args) { } } annotated Java source view VT VT MIR projectional view type combining view type mapping/invariant/response UML class diagram view 31

32 Benefits of the modular SUM metamodel Modularity semantic relations btw. sub-models made explicit in MIR elements re-useof sub-metamodels and MIR definitions Compatibility existing sub-metamodels need not be modified compatibility to existing tools and transformations Evolution sub-metamodels can evolve independently view types serve as a stable interface definition 32

33 Development process VT VT methodologist VT MM2 defines MIR MM3 MIR MM1 VT SUM metamodel MM4 uses VT VT defines VT view flexible view developer 33

34 Development Process 34

35 Backup Vitruvius: Synchronization Process metamodels 1. adds specifies methodologist methodologist map 2. mappings invariants responses based on constrain view type instantiates view 7. uses restore developer developer 5. executes input correspondence mm generator 6. produces 8. triggers maintain instances incremental sync transformations

36 Research Goals & Questions Research Goals ease consistent synchronization of heterogeneous models support views on heterogeneous models using sync information Research questions I Can we synchronize heterogeneous models automatically? Can we specify synchronization with a precise & expressive MIR DSL? Can we define mapping equivalence classes & normal forms with maximal coverage? Can we generate sync. transform. from these mapping normal forms? Can we sync models by triggering these transform. on atomic changes? 36

37 A DSL for Abstract Consistency declarative synchronization rules normative invariants imperative response actions 37

38 Views in Vitruvius Views a view can represent several (possible heterogeneous) elements the is represented by-relation is surjective, but in general not bijective thus, it is in general not automatically reversible 38

39 Editability in views v 1 original view triggers v 0 1 saved view edit v 1 dirty view save consistency conservation operation SUM consistent consistency check SUM not consistent 39

40 Ad-hoc definition of flexible views: ModelJoin ModelJoin = definition language for flexible views 40

41 ModelJoin I Backup Views: ModelJoin I ModelJoin: a textual description language for flexible views a textual description language for Inspired by SQL flexible views Declarative description of projectional and selectional scope Inspired by SQL Example: Flexible view for PCM and sensor metamodel: Declarative description of projectional and selectional AssemblyContext { scope theta join Entities.TimeSpanSensor with pcm.core.composition.assemblycontext where "TimeSpanSensor.sensorName.indexOf(AssemblyContext.id) > 0" as jointarget. keep attributes pcm.core.entity.namedelement.entityname, Entities.Sensor. Example: sensorname Flexible view for PCM and sensor keep outgoing pcm.core.composition.assemblycontext. metamodel: encapsulatedcomponent AssemblyContext as type jointarget.component { keep attributes pcm.core.entity.namedelement.entityname keep subtype pcm.repository.basiccomponent as type jointarget. BasicComponent keep subtype pcm.repository.compositecomponent as type jointarget. CompositeComponent } keep incoming Entities.Experiment.sensors as type jointarget.experiment {

42 Backup Views: ModelJoin II ModelJoin II } } keep attributes Entities.Experiment.experimentName, Entities.Experiment. experimentid keep outgoing Entities.Experiment.experimentRuns as type jointarget.run { keep attributes Entities.ExperimentRun.experimentRunID, Entities. ExperimentRun.experimentDateTime keep aggregate size(entities.experimentrun.measurements) as jointarget.run.measurementcount, avg(entities.timespanmeasurement.timespan) over Entities. ExperimentRun.measurements as jointarget.run.avgtime, min(entities.timespanmeasurement.timespan) over Entities. ExperimentRun.measurements as jointarget.run.mintime, max(entities.timespanmeasurement.timespan) over Entities. ExperimentRun.measurements as jointarget.run.maxtime }

43 Conclusion Vitruvius view-based, model-driven engineering approach Based on OSM [Atkinson, Stoll, and Bostan 2010] Views Views defined by methodologist Flexible views for ad-hoc definition of views by user Development process methodologist and user as roles Planned Contributions declarative definition of view types and views incremental synchronization generated from declarative mappings 43

44 Conclusions Prediction and Understanding of the Consequences of Design Decisions is THE central characteristic of an engineering discipline. Palladio is a first step in this direction Creativity shifts to the design-model level Code is also only a view (and not the full the truth!) Support for view consistency is needed. 44

45 Motivation } SW Components } Quality Prediction } Conclusions 45