Describing Software Components with Parametric Contracts
|
|
|
- Dorcas Lizbeth Fitzgerald
- 6 years ago
- Views:
Transcription
1 Universität Karlsruhe (TH) Research University founded 1825 Describing Software Components with Parametric Contracts Ralf Reussner Chair Software Design and Quality Institute for Program Structures and Data Organization (IPD) Fakultät für Informatik, Universität Karlsruhe (TH), Karlsruhe Institute of Technology
2 Parametric Component Properties Parametric Contract 28ms 33ms? a a: b b 20ms 10ms c c 5ms Design-by-Contract for Software-Components Specification of the relation between provides and requires-interface(s) (and the usage profile and execution environment) Ingenieurdisziplin Vorgehen Komponenten Modelle - Ausblick Ralf Reussner, FLACOS, Oslo /10/2007 2
3 Overview Contracts and Parametric Contracts Protocol Adaptation with Parametric Contracts Prediction of Non-Functional Properties with Parametric Contracts Reliability Performance Conclusions Ralf Reussner, FLACOS, Oslo /10/2007 3
4 What is a component? A component is a contractually specified building unit of software which can be readily composed or deployed. readily composed or deployed : without having to understand the interna as a human these are the two main things to be done with components not necessarily black-box : Information on interna can be available to tools. Components are for composition, much beyond is unclear (Clemens Szyperski) Ralf Reussner, FLACOS, Oslo /10/2007 4
5 Different Abstraction of Components Type CT Type QoS (i, es, up, d) FP (es) 1 1 «implements» Implementation * * IID Implementation Instance Description 1 QoS (es, up, d) FP (es) «deploys» Deployment * DID Deployment Instance Description QoS (up) FP () Not considered within the Palladio ComponentModel Runtime RID Runtime Instance Description i: implementation es: external services up: usage profile d: deployment Ralf Reussner, FLACOS, Oslo /10/2007 5
6 Contractual Use of Methods Design-by-contract (B. Meyer, 1992) Supplier guarantees post-condition if pre-condition is fulfilled by client. [Bertrand Meyer, Object Oriented Software Construction, Prentice-Hall, nd ed.] CustomerRecord getcustomerrecord (String ID) Post-condition Pre-condition Ralf Reussner, FLACOS, Oslo /10/2007 6
7 Design-by-Contract (Bertrand Meyer, 1992) Client Obligations Satisfy precondition: (attached database) Benefits From postcondition: Get customer returned or null Supplier Satisfy postcondition: Get right customer or return null. From Precondition: Handle queries only if database is attached. Ralf Reussner, FLACOS, Oslo /10/2007 7
8 Benefits of Contracts Developing less error-prone software through: Better documentation Reduced error-handling code Clear responsibilities Results of run-time checking as a debugging aid Ralf Reussner, FLACOS, Oslo /10/2007 8
9 Contractual Use of Components Component Component Required Interface Provided Interface Ralf Reussner, FLACOS, Oslo /10/2007 9
10 Use of Components There are two different times of component usage: 1. At system run-time (== component runtime): call of component services 2. At system design-time or system configuration time: plugging in of components Ralf Reussner, FLACOS, Oslo /10/
11 Contractual Use of Components Design-by-contract (B. Meyer, 1992) Supplier guarantees post-condition if precondition is fulfilled by client. Contractual Use of Components (at system design- / configuration-time) Component guarantees provided services (as described in the provides-interface) if the environment offers all required services (as described in the requires-interface). Ralf Reussner, FLACOS, Oslo /10/
12 Pre-condition Contractual Use of Components Required services Information concerning required services (sequences, QoS) Post-condition Offered services Information concerning offered services (sequences, QoS) Invariant Relation between provided and required services (as this is independent from the usage context) Ralf Reussner, FLACOS, Oslo /10/
13 Contractual use of Components Design-by-contract (B. Meyer, 1992) The service supplier guarantees the post-condition, if the client guarantees the precondition of the service. Contractual Use of Components (at system-(re-) configuration time) The component offers the provided services (as specified in the provides interfaces), if the environment guarantees the required services (as specified in the requires interfaces). {Pre} {Post} {Pre} {Post} {Pre} {Post} Ralf Reussner, FLACOS, Oslo /10/
14 Contractual Use of Components Contractual use corresponds to interoperability checks: R C P C Static checks of practical relevance Component Component Required Interface Provided Interface Ralf Reussner, FLACOS, Oslo /10/
15 Consequences (1) Interoperability checks during design- or reconfiguration time are possible by checking the pre-condition against the post-condition of the environment Ralf Reussner, FLACOS, Oslo /10/
16 Problem: Three external Influences on Quality (Performance / Reliability) Performance / Reliability? if (a>b) c = a; Usage Model External Services Execution Evnironment Ralf Reussner, FLACOS, Oslo /10/
17 Consequences (2) But: Fixed pre- and post-condition hinder adaptation Pre- and post-condition are hard to fix at design-time In particular, if non-functional properties are to be specified in interfaces. Components and their contracts need to be adapted to context at deployment, which is after development! Ralf Reussner, FLACOS, Oslo /10/
18 Need for Parametric Contracts One single pair of pre- and postcondition insufficient: restriction of reuse need for transparent component adaptation QoS-properties depend on component context and are not fixed. Ralf Reussner, FLACOS, Oslo /10/
19 Parametric Contracts for Components Parametric Contract Ralf Reussner, FLACOS, Oslo /10/
20 Parametric Contracts Link provides- and requires interface of the same component by bijective function p: {P} {R} Pre-condition computed out of postcondition (and vice versa) Mechanism of automatic component adaptation (besides adaptor generation) Ralf Reussner, FLACOS, Oslo /10/
21 Parametric Contracts for Components Computation of environment-dependent provides-interface Computation of use-dependent requiresinterface ( wp-calculus ) Fine-grain adaptation of large-grain components Ralf Reussner, FLACOS, Oslo /10/
22 Computation of Parametric Contracts Computation of context-dependent provides-interface: 1. (R A = p A (P A )) 2. R A := R A P B 3. P A = p -1 A (R A ) Computation of context-dependent requires-interface: 1. P B := R A P B 2. R B = p B (P B ) P A A p A R A P B B R B p B Ralf Reussner, FLACOS, Oslo /10/
23 Parametric Contracts Parametric Contract 28ms 33ms? a a: b b 20ms 10ms c c 5ms Lifting the Design-by-Contract Principle to Software Components Linking the provided and required services of the same component Ralf Reussner, FLACOS, Oslo /10/
24 Hierarchie of Interface Models... Quality of Service Protocols Signature-Lists Ralf Reussner, FLACOS, Oslo /10/
25 Parametric Contracts for Signature-list based Interfaces Service-Effect-Specifications Service Effect Specification: List of required services for each provided service Provides-Interface provides-interface { void foo (); int bar (); } void foo () requires externalmethod1 externalmethod2 { } P R Component Ralf Reussner, FLACOS, Oslo /10/
26 Parametric Contracts for Signature-list based Interfaces A method n is then and only then required, if there exists (at least) one method m with n se(m). + Service-Effect-Specification = Provides-Interface Requires-Interface = Service-Effect-Specification + A method n is then and only then provided, if all its required methods se(n) are available. Ralf Reussner, FLACOS, Oslo /10/
27 Parametric Contracts for Protocol-modeling Interfaces Service-Effect-Specifications external- Method1 Service Effect Specification: List of required call sequences of services for each provided service Provides-Interface provides-interface { void foo (); int bar (); } foo bar P external- Method2 external- Method3 Component R Ralf Reussner, FLACOS, Oslo /10/
28 Protocol-Adaptation with Parametric Contracts Requires protocol foo_start external_method1 external_method3 return Provides protocol external_method2 return return bar_ start foo bar external_method3 Ralf Reussner, FLACOS, Oslo /10/
29 Parametric Contracts for Protocol-modelling Interfaces A call sequence s is then and only then required, if there exists (at least) one method m with s se(m). + Service-Effect-Specification = Provides-Interface Requires-Interface = Service-Effect-Specification + A method n is then and only then provided, if all its required call sequences se(n) are available. Ralf Reussner, FLACOS, Oslo /10/
30 Service Effect Specification <<Interface>> interface1 service1(x : Integer, Y : Collection) : Collection <<provides>> <<BasicComponent>> Component1 Z.BYTESIZE = 2000 Ralf Reussner, FLACOS, Oslo /10/
31 Service Effect Specification <<Interface>> interface1 service1(x : Integer, Y : Collection) : Collection public void handle(externalcallaction call) { Signature servicetobecalled = call.getcalledservice_externalservice(); Interface requiredinterface = (Interface) servicetobecalled.econtainer(); EList<VariableUsage> parametricparameterusages = call.getparameterusage_externalcallaction(); AssemblyConnector foundassemblyconnector = findassemblyconnector(requiredinterface); <<provides>> <<BasicComponent>> Component1 } if (foundassemblyconnector == null) { logger.info("found System External Call"); String timespecification = gettimespecification(servicetobecalled); createinternalaction(timespecification, call); } else { logger.info("found Assembly Connector"); SeffVisitor nextvisitor = visitnextseff(servicetobecalled, parametricparameterusages, foundassemblyconnector); storeoutputparameterstousagecontext(call, nextvisitor); } private void createinternalaction(string timespecification, ExternalCallAction call) { ParametricResourceDemand demand = sefffactory.createparametricresourcedemand(); demand.setspecification(timespecification); demand.setunit(""); demand.setrequiredresource_parametricresourcedemand(getprocessingresourcetype()); Z.BYTESIZE = 2000 InternalAction action = sefffactory.createinternalaction(); action.getresourcedemand_action().add(demand); // Add new internal action into control flow after external action action.setsuccessor_abstractaction(call.getsuccessor_abstractaction()); action.setpredecessor_abstractaction(call); } ResourceDemandingBehaviour rdb = (ResourceDemandingBehaviour)call.eContainer(); rdb.getsteps_behaviour().add(action); Ralf Reussner, FLACOS, Oslo /10/
32 Service Effect Specification <<Interface>> interface1 service1(x : Integer, Y : Collection) : Collection <<provides>> <<BranchAction>> specification = X.VALUE<0" specification = Z.BYTESIZE * 10" <<BasicComponent>> Component1 specification = X.VALUE>=0" specification = Z.BYTESIZE * 2" Z.BYTESIZE = 2000 Ralf Reussner, FLACOS, Oslo /10/
33 Service Effect Specification <<Interface>> interface1 service1(x : Integer, Y : Collection) : Collection <<provides>> <<BranchAction>> specification = X.VALUE<0" specification = Z.BYTESIZE * 10" <<BasicComponent>> Component1 <<CollectionIteratorAction>> specification = X.VALUE>=0" specification = Z.BYTESIZE * 2" Z.BYTESIZE = 2000 <<Parameter>> parametername = Y <<ExternalCallAction>> extcallpar.value = Y.INNER.VALUE Ralf Reussner, FLACOS, Oslo /10/
34 Service Effect Specification <<Interface>> interface1 service1(x : Integer, Y : Collection) : Collection <<provides>> <<BranchAction>> specification = X.VALUE<0" specification = Z.BYTESIZE * 10" <<BasicComponent>> Component1 <<CollectionIteratorAction>> specification = X.VALUE>=0" specification = Z.BYTESIZE * 2" Z.BYTESIZE = 2000 <<Parameter>> parametername = Y <<SetVariableAction>> <<ExternalCallAction>> service1.return.number_of_elements = Y.NUMBER_OF_ELEMENTS / 3 extcallpar.value = Y.INNER.VALUE Ralf Reussner, FLACOS, Oslo /10/
35 Service Effect Specification <<Interface>> interface1 service1(x : Integer, Y : Collection) : Collection <<UsageContext>> P(X.VALUE = -5) = 0.8 <<BranchAction>> <<CollectionIteratorAction>> specification = X.VALUE<0" specification = X.VALUE>=0" specification = Z.BYTESIZE * 10" specification = Z.BYTESIZE * 2" <<Parameter>> parametername = Y <<ExternalCallAction>> extcallpar.value = Y.INNER.VALUE <<SetVariableAction>> service1.return.number_of_elements = Y.NUMBER_OF_ELEMENTS / 3 Ralf Reussner, FLACOS, Oslo /10/
36 Service Effect Specification <<Interface>> interface1 service1(x : Integer, Y : Collection) : Collection <<UsageContext>> P(X.VALUE = -5) = 0.8 <<BranchAction>> <<CollectionIteratorAction>> specification = 0.8 specification = X.VALUE>=0" specification = Z.BYTESIZE * 10" specification = Z.BYTESIZE * 2" <<Parameter>> parametername = Y <<ExternalCallAction>> extcallpar.value = Y.INNER.VALUE <<SetVariableAction>> service1.return.number_of_elements = Y.NUMBER_OF_ELEMENTS / 3 Ralf Reussner, FLACOS, Oslo /10/
37 Service Effect Specification <<Interface>> interface1 service1(x : Integer, Y : Collection) : Collection <<UsageContext>> P(X.VALUE = -5) = 0.8 P(X.VALUE = 7) = 0.2 <<BranchAction>> <<CollectionIteratorAction>> specification = 0.8 specification = X.VALUE>=0" specification = Z.BYTESIZE * 10" specification = Z.BYTESIZE * 2" <<Parameter>> parametername = Y <<ExternalCallAction>> extcallpar.value = Y.INNER.VALUE <<SetVariableAction>> service1.return.number_of_elements = Y.NUMBER_OF_ELEMENTS / 3 Ralf Reussner, FLACOS, Oslo /10/
38 Service Effect Specification specification = 0.8 specification = Z.BYTESIZE * 10" <<BranchAction>> <<CollectionIteratorAction>> specification = 0.2 specification = Z.BYTESIZE * 2" <<Parameter>> parametername = Y <<ExternalCallAction>> extcallpar.value = Y.INNER.VALUE <<SetVariableAction>> service1.return.number_of_elements = Y.NUMBER_OF_ELEMENTS / 3 Ralf Reussner, FLACOS, Oslo /10/
39 Service Effect Specification specification = 0.8 specification = Z.BYTESIZE * 10" <<BranchAction>> <<CollectionIteratorAction>> specification = 0.2 specification = Z.BYTESIZE * 2" <<Parameter>> parametername = Y <<ExternalCallAction>> extcallpar.value = Y.INNER.VALUE <<SetVariableAction>> service1.return.number_of_elements = Y.NUMBER_OF_ELEMENTS / 3 Ralf Reussner, FLACOS, Oslo /10/
40 Service Effect Specification <<Interface>> interface1 service1(x : Integer, Y : Collection) : Collection <<UsageContext>> P(X.VALUE = -5) = 0.8 P(X.VALUE = 7) = 0.2 <<BranchAction>> <<CollectionIteratorAction>> specification = 0.8 specification = 0.2 specification = specification = Z.BYTESIZE * 2" P(Z.BYTESIZE = 2000) = 1.0 <<Parameter>> parametername = Y <<ExternalCallAction>> extcallpar.value = Y.INNER.VALUE <<SetVariableAction>> service1.return.number_of_elements = Y.NUMBER_OF_ELEMENTS / 3 Ralf Reussner, FLACOS, Oslo /10/
41 Service Effect Specification specification = 0.8 specification = <<BranchAction>> <<CollectionIteratorAction>> specification = 0.2 specification = 4000 <<Parameter>> parametername = Y <<ExternalCallAction>> extcallpar.value = Y.INNER.VALUE <<SetVariableAction>> service1.return.number_of_elements = Y.NUMBER_OF_ELEMENTS / 3 Ralf Reussner, FLACOS, Oslo /10/
42 Service Effect Specification specification = 0.8 specification = <<BranchAction>> <<CollectionIteratorAction>> specification = 0.2 specification = 4000 <<Parameter>> parametername = Y <<ExternalCallAction>> extcallpar.value = Y.INNER.VALUE <<SetVariableAction>> service1.return.number_of_elements = Y.NUMBER_OF_ELEMENTS / 3 Ralf Reussner, FLACOS, Oslo /10/
43 Service Effect Specification <<Interface>> interface1 service1(x : Integer, Y : Collection) : Collection <<UsageContext>> P(X.VALUE = -5) = 0.8 P(X.VALUE = 7) = 0.2 <<BranchAction>> <<CollectionIteratorAction>> specification = 0.8 specification = 0.2 specification = specification = 4000 P(Y.INNER.VALUE = foo ) = 1.0 P(Z.BYTESIZE = 2000) = 1.0 <<Parameter>> parametername = Y <<ExternalCallAction>> extcallpar.value = foo <<SetVariableAction>> service1.return.number_of_elements = Y.NUMBER_OF_ELEMENTS / 3 Ralf Reussner, FLACOS, Oslo /10/
44 Service Effect Specification specification = 0.8 specification = <<BranchAction>> <<CollectionIteratorAction>> specification = 0.2 specification = 4000 <<Parameter>> parametername = Y <<ExternalCallAction>> extcallpar.value = foo <<SetVariableAction>> service1.return.number_of_elements = Y.NUMBER_OF_ELEMENTS / 3 Ralf Reussner, FLACOS, Oslo /10/
45 Service Effect Specification <<Interface>> interface1 service1(x : Integer, Y : Collection) : Collection <<UsageContext>> P(X.VALUE = -5) = 0.8 P(X.VALUE = 7) = 0.2 P(Y.NoE = 30) = 0.1 P(Y.NoE = 60) = 0.9 P(Y.INNER.VALUE = foo ) = 1.0 P(Z.BYTESIZE = 2000) = 1.0 <<BranchAction>> <<CollectionIteratorAction>> <<Parameter>> parametername = Y <<SetVariableAction>> specification = 0.8 specification = 0.2 <<ExternalCallAction>> specification = specification = 4000 service1.return.number_of_elements = INT_PMF[(10; 0.1)(20;0.9)] extcallpar.value = foo Ralf Reussner, FLACOS, Oslo /10/
46 Service Effect Specification <<Interface>> interface1 service1(x : Integer, Y : Collection) : Collection <<UsageContext>> P(X.VALUE = -5) = 0.8 <<UsageContext>> P(X.VALUE = 7) = 0.2 P(X.VALUE = -2) = 0.3 P(X.VALUE = 9) = 0.7 P(Y.NoE = 30) 0.1 P(Y.NoE = 60) = 0.9 P(Y.NoE = 15) = 0.2 P(Y.NoE = 18) = 0.8 P(Y.INNER.VALUE = foo ) = 1.0 P(Y.INNER.VALUE = bar ) = 1.0 P(Z.BYTESIZE = 2000) = 1.0 P(Z.BYTESIZE = 300) = 1.0 <<BranchAction>> <<CollectionIteratorAction>> <<Parameter>> parametername = Y <<SetVariableAction>> specification = 0.8 specification = 0.2 <<ExternalCallAction>> specification = specification = 4000 service1.return.number_of_elements = INT_PMF[(10; 0.1)(20;0.9)] extcallpar.value = foo Ralf Reussner, FLACOS, Oslo /10/
47 Service Effect Specification <<Interface>> interface1 service1(x : Integer, Y : Collection) : Collection <<UsageContext>> P(X.VALUE = -5) = 0.8 <<UsageContext>> P(X.VALUE = 7) = 0.2 P(X.VALUE = -2) = 0.3 P(X.VALUE = 9) = 0.7 P(Y.NoE = 30) 0.1 P(Y.NoE = 60) = 0.9 P(Y.NoE = 15) = 0.2 P(Y.NoE = 18) = 0.8 P(Y.INNER.VALUE = foo ) = 1.0 P(Y.INNER.VALUE = bar ) = 1.0 P(Z.BYTESIZE = 2000) = 1.0 P(Z.BYTESIZE = 300) = 1.0 <<BranchAction>> <<CollectionIteratorAction>> <<Parameter>> parametername = Y <<SetVariableAction>> specification = 0.3 specification = 0.7 <<ExternalCallAction>> specification = 3000 specification = 600 service1.return.number_of_elements = INT_PMF[(5; 0.2)(6;0.8)] extcallpar.value = bar Ralf Reussner, FLACOS, Oslo /10/
48 Palladio Component Model Ralf Reussner, FLACOS, Oslo /10/
49 Stochastic Regular Expression Sequence Loop Iterations (l) Symbol Alternative Probability π, 1-π Ralf Reussner, FLACOS, Oslo /10/
50 Transformation Ralf Reussner, FLACOS, Oslo /10/
51 Palladio Component Model Ralf Reussner, FLACOS, Oslo /10/
52 Model Solution Ralf Reussner, FLACOS, Oslo /10/
53 Model Solution [Trivedi1982/Firus2005] Ralf Reussner, FLACOS, Oslo /10/
![Model Solution [Trivedi1982/Firus2005] Ralf](/docs-images/71/66176233/images/54-3.jpg "Reussner, FLACOS, Oslo 2007 14/10/2007 14.10.2007 54")
54 Model Solution [Trivedi1982/Firus2005] Ralf Reussner, FLACOS, Oslo /10/
![Model Solution [Koziolek2006a] Ralf](/docs-images/71/66176233/images/55-2.jpg "Reussner, FLACOS, Oslo 2007 14/10/2007 14.")
55 Model Solution [Koziolek2006a] Ralf Reussner, FLACOS, Oslo /10/
56 MediaStore - Architecture Ralf Reussner, FLACOS, Oslo /10/
57 Download - Use Case Ralf Reussner, FLACOS, Oslo /10/
58 Case Study: Usage Profiles Ralf Reussner, FLACOS, Oslo /10/
59 Results Ralf Reussner, FLACOS, Oslo /10/
60 Results Ralf Reussner, FLACOS, Oslo /10/
61 Model-based Prediction of Quality Executable Software UML, ADL, Software Design Model Results Analysis Results Response time Throughput, Utilisation, Transformation (MDD) Estimation Measurement Analyse / Simulation Automated by Tools UML Performance Profile, QML, Annotated Software Design Model Transformation (MDD) Analysis Modell Queueing models Stochastic Petri-Nets, Stochastic Process Algebra, Ralf Reussner, FLACOS, Oslo /10/
62 Scientific Approach Modell of Software (mit Annotationen) Prediction Predicted Quality Improvement / Extension Interpretation Abstraction Acceptance / rejection of abstract model Comparison Software Measurement Measured Quality Engineering? Components Ralf Reussner, FLACOS, Oslo /10/
63 Summary Contractual Use of Components Requires-interfaces as pre-conditions Provides-interfaces as post-conditions Enabling (static) interoperability checks Parametric Contracts Compute pre-condition in dependency of postcondition and vice versa Prediction of properties in non-cyclic architectures by propagating interface information Formal models of parametric contracts for predicting quality properties are created in a process oriented toward natural sciences. Ralf Reussner, FLACOS, Oslo /10/
The Palladio Component Model. Ralf Reussner, Steffen Becker, Jens Happe, Heiko Koziolek, Klaus Krogmann, Michael Kuperberg. Interner Bericht
Universität Karlsruhe - Fakultät für Informatik - Bibliothek - Postfach 6980-7628 Karlsruhe The Palladio Component Model Ralf Reussner, Steffen Becker, Jens Happe, Heiko Koziolek, Klaus Krogmann, Michael
Praktikum Ingenieurmäßige Software-Entwicklung
Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Praktikum Ingenieurmäßige Software-Entwicklung Palladio Component Model Part V (PCM) Prof. Dr. R. H. Reussner (reussner@ipd.uka.de) Lehrstuhl
Praktikum Ingenieurmäßige Software-Entwicklung
Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Praktikum Ingenieurmäßige Software-Entwicklung Palladio Component Model Part IV (PCM) Prof. Dr. R. H. Reussner (reussner@ipd.uka.de) Lehrstuhl
Performance Certification of Software Components
FESCA 2011 Performance Certification of Software Components Erik Burger 1 Ralf Reussner 2 Software Design and Quality Institute for Program Structures and Data Organization, Faculty of Informatics Karlsruhe
Predicting the Performance of Component-Based Software Architectures with different Usage Profiles
Predicting the Performance of Component-Based Software Architectures with different Usage Profiles Heiko Koziolek, Steffen Becker, Jens Happe Graduate School Trustsoft University of Oldenburg, Germany
ICSA 2017 Tutorial Runtime Modeling and Visualization -- Introduction to Palladio
DFG Priority Programme 1593 Design For Future - Managed Software Evolution ICSA 2017 Tutorial Runtime Modeling and Visualization -- Introduction to Palladio R. Heinrich ICSA 2017 Tutorial Introduction
Model-Based Performance Prediction with the Palladio Component Model
Model-Based Performance Prediction with the Palladio Component Model Steffen Becker IPD, University of Karlsruhe 763 Karlsruhe, Germany sbecker@ipd.uka.de Heiko Koziolek Graduate School TrustSoft University
Distributed Information System as a System of Asynchronous Concurrent Processes
Distributed Information System as a System of Asynchronous Concurrent Processes Marek Rychlý Jaroslav Zendulka Department of Information Systems Faculty of Information Technology Brno University of Technology
Lecture 9 / Tutorial 8 Software Contracts
Lecture 9 / Tutorial 8 Software Contracts Design by contracts Programming by contracts Today 1. Sign a contract 2. Design by contract 3. Programming by contract 4. Summary 5. Questions and Answers Having
Evaluating Performance of Software Architecture Models with the Palladio Component Model
Evaluating Performance of Software Architecture Models with the Palladio Component Model Heiko Koziolek, Jens Happe Uhlhornsweg, D-26111 Oldenburg, Germany, heiko.koziolek@informatik.uni-oldenburg.de jens.happe@informatik.uni-oldenburg.de
DRAFT. The Descartes Meta-Model. Samuel Kounev, Fabian Brosig, Nikolaus Huber
escartes The Descartes Meta-Model Samuel Kounev, Fabian Brosig, Nikolaus Huber Descartes Research Group Institute for Program Structures and Data Organization Karlsruhe Institute of Technology (KIT), Germany
Using Stochastic Petri Nets to Predict Quality of Service Attributes of Component-Based Software Architectures
Using Stochastic Petri Nets to Predict Quality of Service Attributes of Component-Based Software Architectures Jens Happe, Viktoria Firus Software Engineering Group University of Oldenburg [jens.happe
Lecture 10 Design by Contract
CS 5959 Writing Solid Code Fall 2015 Nov-23 Lecture 10 Design by Contract Zvonimir Rakamarić University of Utah Design by Contract Also called assume-guarantee reasoning Developers annotate software components
Object-Oriented Design
Object-Oriented Design Lecturer: Raman Ramsin Lecture 15: Object-Oriented Principles 1 Open Closed Principle (OCP) Classes should be open for extension but closed for modification. OCP states that we should
UC Santa Barbara. CS189A - Capstone. Christopher Kruegel Department of Computer Science UC Santa Barbara
CS189A - Capstone Christopher Kruegel Department of Computer Science http://www.cs.ucsb.edu/~chris/ Design by Contract Design by Contract and the language that implements the Design by Contract principles
CSC Advanced Object Oriented Programming, Spring Specification
CSC 520 - Advanced Object Oriented Programming, Spring 2018 Specification Specification A specification is an unambiguous description of the way the components of the software system should be used and
The Contract Pattern. Design by contract
The Contract Pattern Copyright 1997, Michel de Champlain Permission granted to copy for PLoP 97 Conference. All other rights reserved. Michel de Champlain Department of Computer Science University of Canterbury,
Life-Cycle Aware Modelling of Software Components
Life-Cycle Aware Modelling of Software Components Heiko Koziolek, Steffen Becker 2, Jens Happe, Ralf Reussner Chair for Software Design and Quality Am Fasanengarten 5, University of Karlsruhe (TH), 763
Object Oriented Program Correctness with OOSimL
Kennesaw State University DigitalCommons@Kennesaw State University Faculty Publications 12-2009 Object Oriented Program Correctness with OOSimL José M. Garrido Kennesaw State University, jgarrido@kennesaw.edu
ARTICLE IN PRESS Performance Evaluation ( )
Performance Evaluation ( ) Contents lists available at ScienceDirect Performance Evaluation journal homepage: www.elsevier.com/locate/peva Parametric performance completions for model-driven performance
Lecture Notes: Hoare Logic
Lecture Notes: Hoare Logic 17-654/17-754: Analysis of Software Artifacts Jonathan Aldrich (jonathan.aldrich@cs.cmu.edu) Lecture 3 1 Hoare Logic The goal of Hoare logic is to provide a formal system for
A Practical Approach to Programming With Assertions
A Practical Approach to Programming With Assertions Ken Bell Christian-Albrechts Universität Kiel Department of Computer Science and Applied Mathematics Real-Time Systems and Embedded Systems Group July
The Descartes Modeling Language: Status Quo
The Descartes Modeling : Status Quo Samuel Kounev University of Würzburg http://se.informatik.uni-wuerzburg.de/ Symposium on Software Performance, Stuttgart, Nov 27, 2014 Credits Fabian Brosig Nikolaus
CONTRACTUAL SPECIFICATION OF COMPONENT USING VIRTUAL INTERFACE
CONTRACTUAL SPECIFICATION OF COMPONENT USING VIRTUAL INTERFACE Eustache MUTEBA Ayumba Researcher/Lecturer Correspondent of IMIA, NEM and EASST in Democratic Republic of Congo Email: emuteba@hotmail.fr
Assertions. Assertions - Example
References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 11/13/2003 1 Assertions Statements about input to a routine or state of a class Have two primary roles As documentation,
Synthesizing Communication Middleware from Explicit Connectors in Component Based Distributed Architectures
Synthesizing Communication Middleware from Explicit Connectors in Component Based Distributed Architectures Dietmar Schreiner 1,2 and Karl M. Göschka 1 1 Vienna University of Technology Institute of Information
Component-based software engineering. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 1
Component-based software engineering Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 1 Objectives To explain that CBSE is concerned with developing standardised components and
Static program checking and verification
Chair of Software Engineering Software Engineering Prof. Dr. Bertrand Meyer March 2007 June 2007 Slides: Based on KSE06 With kind permission of Peter Müller Static program checking and verification Correctness
Part II. Hoare Logic and Program Verification. Why specify programs? Specification and Verification. Code Verification. Why verify programs?
Part II. Hoare Logic and Program Verification Part II. Hoare Logic and Program Verification Dilian Gurov Props: Models: Specs: Method: Tool: safety of data manipulation source code logic assertions Hoare
Software Components and Distributed Systems
Software Components and Distributed Systems INF5040/9040 Autumn 2017 Lecturer: Eli Gjørven (ifi/uio) September 12, 2017 Outline Recap distributed objects and RMI Introduction to Components Basic Design
ΗΜΥ 317 Τεχνολογία Υπολογισμού
ΗΜΥ 317 Τεχνολογία Υπολογισμού Εαρινό Εξάμηνο 2008 ΙΑΛΕΞΕΙΣ 16-17: Component-Based Software Engineering ΧΑΡΗΣ ΘΕΟΧΑΡΙ ΗΣ Λέκτορας ΗΜΜΥ (ttheocharides@ucy.ac.cy) [Προσαρμογή από Ian Sommerville, Software
A Class-Level Unit Testing Tool for Java
A Class-Level Unit Testing Tool for Java Tz-Fan Hu and Nai-Wei Lin Department of Computer Science and Information Engineering National Chung Cheng University Chiayi 621, Taiwan, R.O.C. Email: {htf97m,naiwei}@cs.ccu.edu.tw
Softwaretechnik. Lecture 08: Testing and Debugging Overview. Peter Thiemann SS University of Freiburg, Germany
Softwaretechnik Lecture 08: Testing and Debugging Overview Peter Thiemann University of Freiburg, Germany SS 2012 Literature Essential Reading Why Programs Fail: A Guide to Systematic Debugging, A Zeller
Axiomatic Specification. Al-Said, Apcar, Jerejian
Axiomatic Specification Al-Said, Apcar, Jerejian 1 Axioms: Wffs that can be written down without any reference to any other Wffs. Wffs that are stipulated as unproved premises for the proof of other wffs
Softwaretechnik. Lecture 08: Testing and Debugging Overview. Peter Thiemann SS University of Freiburg, Germany
Softwaretechnik Lecture 08: Testing and Debugging Overview Peter Thiemann University of Freiburg, Germany SS 2012 Literature Essential Reading Why Programs Fail: A Guide to Systematic Debugging, A Zeller
Chapter 1: Principles of Programming and Software Engineering
Chapter 1: Principles of Programming and Software Engineering Data Abstraction & Problem Solving with C++ Fifth Edition by Frank M. Carrano Software Engineering and Object-Oriented Design Coding without
EINDHOVEN UNIVERSITY OF TECHNOLOGY
EINDHOVEN UNIVERSITY OF TECHNOLOGY Department of Mathematics & Computer Science Exam Programming Methods, 2IP15, Wednesday 17 April 2013, 09:00 12:00 TU/e THIS IS THE EXAMINER S COPY WITH (POSSIBLY INCOMPLETE)
Object-Oriented Design
Object-Oriented Design Department of Computer Engineering Lecture 12: Object-Oriented Principles Sharif University of Technology 1 Open Closed Principle (OCP) Classes should be open for extension but closed
OO Technology: Properties and Limitations for Component-Based Design
TDDD05 Component-Based Software OO Technology: Properties and Limitations for Component-Based Design Interfaces Design by by Contract Syntactic Substitutability Inheritance Considered Harmful Fragile Base
JAVA BASICS II. Example: FIFO
JAVA BASICS II Example: FIFO To show how simple data structures are built without pointers, we ll build a doubly-linked list ListItem class has some user data first refers to that ListItem object at the
Design by Contract in Java a roadmap to excellence in trusted components
Design by Contract in Java a roadmap to excellence in trusted components Abstract Reuse is one of the main targets in future software engineering. This article outlines a new concept in software development,
Automatic Black-Box Method-Level Test Case Generation Based on Constraint Logic Programming
Automatic Black-Box Method-Level Test Case Generation Based on Constraint Logic Programming i-tin Hu and ai-wei Lin Department of Computer Science and Information Engineering ational Chung Cheng University
Reverse Engineering of Parametric Behavioural Service Performance Models from Black-Box Components
Reverse Engineering of Parametric Behavioural Service Performance Models from Black-Box Components Klaus Krogmann, Michael Kuperberg, and Ralf Reussner Institute for Program Structures and Data Organisation
Formale Entwicklung objektorientierter Software
Formale Entwicklung objektorientierter Software Praktikum im Wintersemester 2008/2009 Prof. P. H. Schmitt Christian Engel, Benjamin Weiß Institut für Theoretische Informatik Universität Karlsruhe 5. November
Software Architectures
Software Architectures 2 SWS Lecture 1 SWS Lab Classes Hans-Werner Sehring Miguel Garcia Arbeitsbereich Softwaresysteme (STS) TU Hamburg-Harburg HW.Sehring@tuhh.de Miguel.Garcia@tuhh.de http://www.sts.tu-harburg.de/teaching/ss-05/swarch/entry.html
Runtime Checking and Test Case Generation for Python
Runtime Checking and Test Case Generation for Python Anna Durrer Master Thesis Chair of Programming Methodology D-INFK ETH Supervisor: Marco Eilers, Prof. Peter Müller 24. Mai 2017 1 Introduction This
Ambientes de Desenvolvimento Avançados
Ambientes de Desenvolvimento Avançados http://www.dei.isep.ipp.pt/~jtavares/adav/adav.htm Aula 6 Engenharia Informática 2006/2007 José António Tavares jrt@isep.ipp.pt 1 Components and Interfaces Part 2
CASE tool-based system development using UML/OCL
CASE tool-based system development using UML/OCL Achim D. Brucker Institut für Informatik Albert-Ludwigs-Universität F brucker@informatik.uni-f.de http://www.informatik.uni-f.de/~brucker April 12, 2002
Guiding Transaction Design through Architecture-Level Performance and Data Consistency Prediction
Guiding Transaction Design through Architecture-Level Performance and Data Consistency Prediction Philipp Merkle Software Design and Quality Group Karlsruhe Institute of Technology (KIT) 76131 Karlsruhe,
a correct statement? You need to know what the statement is supposed to do.
Using assertions for correctness How can we know that software is correct? It is only correct if it does what it is supposed to do. But how do we know what it is supposed to do? We need a specification.
Assertions & Design-by-Contract using JML Erik Poll University of Nijmegen
Assertions & Design-by-Contract using JML Erik Poll University of Nijmegen Erik Poll - JML p.1/39 Overview Assertions Design-by-Contract for Java using JML Contracts and Inheritance Tools for JML Demo
References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 10/14/2004 1
References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 10/14/2004 1 Assertions Statements about input to a routine or state of a class Have two primary roles As documentation,
Chapter 1: Programming Principles
Chapter 1: Programming Principles Object Oriented Analysis and Design Abstraction and information hiding Object oriented programming principles Unified Modeling Language Software life-cycle models Key
Software Architecture 4. July 2005
Chair of Software Engineering Bertrand Meyer Software Architecture 4. July 2005 Name, First name:... I confirm with my signature, that I was able to take this exam under regular conditions and that I have
3. Design by Contract
3. Design by Contract Oscar Nierstrasz Design by Contract Bertrand Meyer, Touch of Class Learning to Program Well with Objects and Contracts, Springer, 2009. 2 Roadmap > Contracts > Stacks > Design by
Compositional Model Based Software Development
Compositional Model Based Software Development Prof. Dr. Bernhard Rumpe http://www.se-rwth.de/ Seite 2 Our Working Groups and Topics Automotive / Robotics Autonomous driving Functional architecture Variability
Assertions, pre/postconditions
Programming as a contract Assertions, pre/postconditions Assertions: Section 4.2 in Savitch (p. 239) Specifying what each method does q Specify it in a comment before method's header Precondition q What
Using the TrustME Tool Suite for Automatic Component Protocol Adaptation
Using the TrustME Tool Suite for Automatic Component Protocol Adaptation Ralf Reussner 1, Iman Poernomo 1, and Heinz W. Schmidt 2 1 Distributed Systems Technology Center (DSTC) Pty Ltd Monash University,
PROCESS DEVELOPMENT METHODOLOGY The development process of an API fits the most fundamental iterative code development
INTRODUCING API DESIGN PRINCIPLES IN CS2 Jaime Niño Computer Science, University of New Orleans New Orleans, LA 70148 504-280-7362 jaime@cs.uno.edu ABSTRACT CS2 provides a great opportunity to teach an
Index. Index. More information. block statements 66 y 107 Boolean 107 break 55, 68 built-in types 107
A abbreviations 17 abstract class 105 abstract data types 105 abstract method 105 abstract types 105 abstraction 92, 105 access level 37 package 114 private 115 protected 115 public 115 accessors 24, 105
Hierarchical vs. Flat Component Models
Hierarchical vs. Flat Component Models František Plášil, Petr Hnětynka DISTRIBUTED SYSTEMS RESEARCH GROUP http://nenya.ms.mff.cuni.cz Outline Component models (CM) Desired Features Flat vers. hierarchical
Java Modelling Language (JML) References
Java Modelling Language (JML) References G. T. Leavens and Y. Cheon. Design by Contract with JML, August 2005. L. Burdy, Y. Cheon, D. Cok, M. Ernst, J. Kiniry, G. T. Leavens, K. R. M. Leino, and E. Poll.
Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of
Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of Computer Science Technische Universität Darmstadt Dr.
Code Contracts. Pavel Parízek. CHARLES UNIVERSITY IN PRAGUE faculty of mathematics and physics
Code Contracts http://d3s.mff.cuni.cz Pavel Parízek CHARLES UNIVERSITY IN PRAGUE faculty of mathematics and physics Pavel Parízek Code Contracts 2 Assertions Typically used as internal checks in the program
Fortgeschrittene objektorientierte Programmierung (Advanced Object-Oriented Programming)
2014-03-07 Preface Fortgeschrittene objektorientierte Programmierung (Advanced Object-Oriented Programming) Coordinates: Lecturer: Web: Studies: Requirements: No. 185.211, VU, 3 ECTS Franz Puntigam http://www.complang.tuwien.ac.at/franz/foop.html
TOWARDS PERFORMANCE PREDICTION FOR CLOUD COMPUTING ENVIRONMENTS BASED ON GOAL-ORIENTED MEASUREMENTS
TOWARDS PERFORMANCE PREDICTION FOR CLOUD COMPUTING ENVIRONMENTS BASED ON GOAL-ORIENTED MEASUREMENTS Michael Hauck FZI Research Center for Information Technology, Karlsruhe, Germany hauck@fzi.de Jens Happe
Service-Oriented Programming
Service-Oriented Programming by Guy Bieber, Lead Architect, ISD C4I, Motorola ABSTRACT - The Service-Oriented Programming (SOP) model is the most exciting revolution in programming since Object Oriented
Symbolic Execution and Proof of Properties
Chapter 7 Symbolic Execution and Proof of Properties Symbolic execution builds predicates that characterize the conditions under which execution paths can be taken and the effect of the execution on program
An Assertion Checking Wrapper Design for Java
An Assertion Checking Wrapper Design for Java Roy Patrick Tan Department of Computer Science Virginia Tech 660 McBryde Hall, Mail Stop 0106 Blacksburg, VA 24061, USA rtan@vt.edu Stephen H. Edwards Department
Eiffel: Analysis, Design and Programming. ETH Zurich, September-December Exception handling
Eiffel: Analysis, Design and Programming ETH Zurich, September-December 2008-6- Exception handling What is an exception? An abnormal event Not a very precise definition Informally: something that you don
C# 6.0 in a nutshell / Joseph Albahari & Ben Albahari. 6th ed. Beijin [etc.], cop Spis treści
![C# 6.0 in a nutshell / Joseph Albahari & Ben Albahari. 6th ed. Beijin [etc.], cop Spis treści](/thumbs/91/107183011.jpg "C# 6.0 in a nutshell / Joseph Albahari & Ben Albahari. 6th ed. Beijin [etc.], cop Spis treści")
C# 6.0 in a nutshell / Joseph Albahari & Ben Albahari. 6th ed. Beijin [etc.], cop. 2016 Spis treści Preface xi 1. Introducing C# and the.net Framework 1 Object Orientation 1 Type Safety 2 Memory Management
Interoperability: Advantages, Problems and Solutions
Fakultät Informatik Institut für Angewandte Informatik, Professur Technische Informationssysteme Interoperability: Advantages, Problems and Solutions Prof. Dr.-Ing. habil. Klaus Kabitzsch Dresden, 2018-05-29
Oracle-based Mode-change Propagation in Hierarchical Components.
Oracle-based Mode-change Propagation in Hierarchical Components. http://d3s.mff.cuni.cz Tomas Pop, Frantisek Plasil, Matej Outly, Michal Malohlava, Tomas Bures Tomas.Pop@d3s.mff.cuni.cz CHARLES UNIVERSITY
From MDD back to basic: Building DRE systems
From MDD back to basic: Building DRE systems, ENST MDx in software engineering Models are everywhere in engineering, and now in software engineering MD[A, D, E] aims at easing the construction of systems
Contract Programming For C++0x
Contract Programming For C++0x WG21/N1800 and J16/05-0060 Lawrence Crowl and Thorsten Ottosen lawrence.crowl@sun.com and nesotto@cs.aau.dk 2005-04-27 Overview This is an annotated version of the presentation
MSO Lecture Design by Contract"
1 MSO Lecture Design by Contract" Wouter Swierstra (adapted by HP, AL) October 8, 2018 2 MSO SO FAR Recap Abstract Classes UP & Requirements Analysis & UML OO & GRASP principles Design Patterns (Facade,
Software Engineering I (02161)
Software Engineering I (02161) Week 10 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2017 Last Week Layered Architecture: Persistent Layer Software Development Processes
Object-Oriented Software Construction
1 Object-Oriented Software Construction Bertrand Meyer Contact 2 Chair of Software Engineering: http://se.inf.ethz.ch Course assistant: Joseph N. Ruskiewicz http://se.inf.ethz.ch/people/ruskiewicz 3 Lecture
Rapid Performance Modeling by Transforming Use Case Maps to Palladio Component Models
Rapid Performance Modeling by Transforming Use Case Maps to Palladio Component Models Christian Vogel, Heiko Koziolek, Thomas Goldschmidt, Erik Burger Software Design & Quality, Karlsruhe Institute of
Guilt-based Handling of Software Performance Antipatterns in Palladio Architectural Models
Guilt-based Handling of Software Performance Antipatterns in Palladio Architectural Models Catia Trubiani a, Anne Koziolek c, Vittorio Cortellessa b, Ralf Reussner c a Gran Sasso Science Institute, L Aquila,
CS246 Software Abstraction and Specification Final Examination
CS246 Software Abstraction and Specification ination Spring 2007 Date: 04-Aug-2007 Time: 4.00 6.30pm Permitted Aids: None 14 pages Student Name: UW Student ID: Instructions: (Read carefully before the
Design by Contract: An Overview
: An Overview CSCI 5828 Michael M. Vitousek University of Colorado at Boulder michael.vitousek@colorado.edu March 21, 2012 1 / 35 Outline 1 Introduction Motivation and Introduction Simple Example Contract
Introduction to Linked Lists. Introduction to Recursion Search Algorithms CS 311 Data Structures and Algorithms
Introduction to Linked Lists Introduction to Recursion Search Algorithms CS 311 Data Structures and Algorithms Lecture Slides Friday, September 25, 2009 Glenn G. Chappell Department of Computer Science
Proseminar. (with Eclipse) Jun.-Prof. Dr.-Ing. Steffen Becker. Model-Driven Software Engineering. Software Engineering Group
Proseminar Model-Driven Software Engineering (with Eclipse) Jun.-Prof. Dr.-Ing. Steffen Becker Model-Driven Software Engineering Software Engineering Group 1 Outline Basic Requirements Preliminary Dates
In-Class Exercises. ETH Zurich. November
In-Class Exercises ETH Zurich November 28 2012 1 Contracts ETH students recently designed a special kind of oven for cooking potatoes. Here are some facts about such an oven: each oven is equipped with
European Component Oriented Architecture (ECOA ) Collaboration Programme: Architecture Specification Part 2: Definitions
European Component Oriented Architecture (ECOA ) Collaboration Programme: Part 2: Definitions BAE Ref No: IAWG-ECOA-TR-012 Dassault Ref No: DGT 144487-D Issue: 4 Prepared by BAE Systems (Operations) Limited
Heuristics-based Parameter Generation for Java Methods
Universität Karlsruhe (TH) Research University founded 1825 Heuristics-based Parameter Generation for Java Methods Michael Kuperberg (mkuper@ipd.uka.de) Fouad Omri (fouad.omri@stud.uni-karlsruhe.de) Chair
Testing, Debugging, and Verification
Testing, Debugging, and Verification Formal Specification, Part II Srinivas Pinisetty 23 November 2017 Introduction Today: Introduction to Dafny: An imperative language with integrated support for formal
Functional Programming in Java. CSE 219 Department of Computer Science, Stony Brook University
Functional Programming in Java CSE 219, Stony Brook University What is functional programming? There is no single precise definition of functional programming (FP) We should think of it as a programming
Trust-By-Contract: Modelling, Analysing and Predicting Behaviour of Software Architectures
Trust-By-Contract: Modelling, Analysing and Predicting Behaviour of Software Architectures Heinz Schmidt (hws@monash.edu.au) School of Computer Science and Software Engineering Monash University Australia
Part II Black-Box Composition Systems 20. Finding UML Business Components in a Component-Based Development Process
Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie Prof. Aßmann - CBSE Part II Black-Box Composition Systems 20. Finding UML Business Components in a Component-Based Development
Analysis of Enterprise Architecture Models Using Performance Quantitative Analysis Technique Murnawan a, Ros Sumiati b
Analysis of Enterprise Architecture Models Using Performance Quantitative Analysis Technique Murnawan a, Ros Sumiati b a Faculty of Engineering, Widyatama University, Indonesia E-mail : murnawan@widyatama.ac.id,
FAKULTÄT FÜR INFORMATIK
FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Master-Seminar Software Verification Author: Lukas Erlacher Advisor: Prof. Andrey Rybalchenko, Dr. Corneliu Popeea Submission: April, 2013 Contents
Characterising Resource Management Performance in Kubernetes. Appendices.
Characterising Resource Management Performance in Kubernetes. Appendices. Víctor Medel a, Rafael Tolosana-Calasanz a, José Ángel Bañaresa, Unai Arronategui a, Omer Rana b a Aragon Institute of Engineering
Use the scantron sheet to enter the answer to questions (pages 1-6)
Use the scantron sheet to enter the answer to questions 1-100 (pages 1-6) Part I. Mark A for True, B for false. (1 point each) 1. Abstraction allow us to specify an object regardless of how the object
21) Functional and Modular Design
Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie Prof. Aßmann - 21) Functional and Modular Design Prof. Dr. U. Aßmann Technische Universität Dresden Institut für Software-
Formal Systems II: Applications
Formal Systems II: Applications Functional Verification of Java Programs: Java Dynamic Logic Bernhard Beckert Mattias Ulbrich SS 2017 KIT INSTITUT FÜR THEORETISCHE INFORMATIK KIT University of the State
Einführung in die Programmierung Introduction to Programming
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 5 Today Attributes, formal arguments, and local variables Control structures
Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of
Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of Computer Science Technische Universität Darmstadt What
COMPLEX SYSTEMS. Today. Complex Systems. Kinds of Systems. Embedded Systems. Software Engineering. Lectures 20: Engineering Complex Systems
Chair of Software Engineering Today Software Engineering Prof. Dr. Bertrand Meyer Dr. Manuel Oriol Dr. Bernd Schoeller Lectures 20: Engineering Complex Systems Complex Systems What is it? Examples Technologies