width: 900 height: 900 maxScale: 1.5

**************************# SE-Tutorium 4 | Mittwoch 16 - 18 Uhr: anchored to [[191.00_anchor]]

Lernziele:

• Fragen zu HW7 ?
  • Sind alle Aufgaben verständlich -> kurz durchgehen?
• Interfaces nochmal anschauen (word cloud)
• mutable / immutable Unterschiede
  • wann nutzen wir sie ?
  • welche Vorteile bieten sie?
• Interfaces einen Sinn verleihen -> Design by Contract
• Beispielhaft preconditions / postconditions beschreiben können
  • wie können wir Contracts beschreiben ( wo? )
  • Contracts enforcen? –> Wie stellen wir sicher, dass er erfüllt wird?
• Contracts selbst beschreiben
• anhand eines Contracts eine Implementation schreiben

things to open for tutorial:

• HW 7 tasks : https://github.com/se-tuebingen-exercises-ws23/hw7-tut4-AlexanderPeters86
• sample sol : https://github.com/se-tuebingen-exercises-ws23/se-exercise9/commit/c22ece70fde6d973d1b992cc2796d75c34e205a3
• actual tutorial : https://github.com/se-tuebingen-exercises-ws23/ex9-tut4

| Orga |

• Schaut euch HW7 / 8 an!
• HW7 bis zum Beginn der Vorlesungszeit zu bearbeiten!
• HW8 –> viele Bonus-Aufgaben, gut zum aufholen!
• Korrekturen von HW6 folgen die Woche oder am Wochenende!

|“Memes” im Forum|

Bitte liked mein Meme, danke

(HW8)

| HW7\8| Fragen / Probleme

• gibt es Fragen zu Aufgaben von Hw7 ?
  • Verständlich, wie Find genutzt werden soll?
  • Anforderungen / Ideen für die Review verständlich?
• Fragen zu Hw8 ?

note: open the repository to talk about the tasks –> maybe solve / resolve issues occurring.

<<| Interfaces - Konzept |>>

[!Task] Was war nochmal ein Interface? Was macht es aus?

[!Task] Fallen euch Beispiele für Interfaces ein?

note: draw small word cloud ont chalkboard. Important aspects:

• implementation should ( at best ) not be necessary to know about
• interface allows interaction with some parts of the implementation
  • Interface denotes what to allow for usage / what not
• it defines / declares what we want it to do / provide –> we rely on the information given –> the interface should also give back the aspects requested!

>-<<| Interfaces - Konzept |>>-<

[!Question] Warum brauchen wir Interfaces überhaupt? Ohne sollte man ja auch sinnvoll programmieren können?

note: We may take a look at a program that is developed for multiple systems at once, i.e macOs, Windows, Linux, BSD …

Consider we are not providing an interface to interact with the filesystem. –> we would have to write a new implementation for each possible filesystem and how the system interacts with it ( operating system ) For instance we would have to cover: ZFS,ext3,ext4,NTFS,FAT32, APFS, … Awful! We wouls have to make tremendous changes everytime, especially deep within our codebase. Better: provide interface that does interaction with filesystem. We will have to implement the interaction etc too, However! we are doing it in a separate implementation we don’t have to embed in our whole project (here comes the modularity aspect again!) but just behind the interface that we can then call from everywhere –> Way easier!

<-<| Interfaces - Konzept |>->

• Interfaces sind Schnittstelle zwischen Software-Komponenten ( Modulen / Libraries / Klassen …)
• Interface gibt Requirements << :: >> Implementation dahinter gibt Funktionalität!
  • Interface != Implementation
• daraus folgt –> Implementation ist uns egal
  • beschrieben Funktionalität wird angewandt
  • dass, was durch das Interface beschrieben wird, muss auch gegeben sein!

note: –> aligns to the concept of contracts that we will look at next

<<| Interfaces - Beispiele |>>

• unser Parser hatte ein Interface! –> Warum?
  • jedoch nicht standardisiert! –> Implementation variiert je nach Ansatz etc.
• plump ( eher Verständnis) Webinterface –> GitHub?!
  • stellt uns was bereit, kann was annehmen –> wie es verarbeitet wird ???
• Funktionen und deren Funktionssignaturen! –> Warum?
• Verträge zur Entwicklung von Software?

-> Weitere Beispiele?

note: show them repo from Twelveparsecs –> Where the interface is used!

]]+> mutable / immutable <+[[

• großer Grundunterschied:
• mutable –> Veränderbar nach Instanzierung var fillLater = "" ... fillLater = "now filled!"
• immutable –> nicht veränderbar nach Instanzierung val fillNow = "filled now" ... fillNow = "maybe?" -> crash

]]+> mutable / immutable <+[[

Warum nutzen wir immutable DataTypes?:

• wird sich nicht ändern –> wenn es von einer Funktion genutzt wird ( außer Funktion beschreibt es…)
• Status von Variable ist immer bekannt –> kann nicht random verändert werden!
• Wichtig bei Multi-Threading –> also Parallelisieren von Code
  • –> zwei Threads könnten davon abhängen, das Datum an bestimmter Stelle steht ( wie validieren wir, dass der eine Thread nicht schneller war? –> Immutable ändert sich nicht!)

note: example for the first part could be: Consider a function that will take an integer, and multiply it with 14. Now it will create a new variable containing the result and return it as result. We could then catch this result and proceed from there. Fine! Now consider we are implementing the same function but we add a new twist!: –> it will not just do the multiplication but also modify the given variable by adding $+1$ ( for whatever reason idk). What we result with: Once leaving the function we have acquired a result (nice!) but it also changed our given value, which we didnt thought would happen. –> we changed / alternated the state we had before :(.

further resources to read about ( beside lecture slides ^^)

• https://en.wikipedia.org/wiki/Immutable_object
• https://www.tiny.cloud/blog/mutable-vs-immutable-javascript/
• https://stackoverflow.com/questions/622664/what-is-immutability-and-why-should-i-worry-about-it

$-=\equiv$>| Design By Contract |<$\equiv =-$

Brauchen Rahmenbedingungen, um Software schreiben zu können:

• Was ist erlaubt, welche Eingaben sind erlaubt, was wird zurückgegeben? was repräsentiert es eigentlich? ( Spezifisch für eine Implementation, i.e. Methode…)

• Beschreibt also eine Beziehung zwischen: Developer <<–>> User

  • User gibt Input –> nutzt es
  • Developer “gibt Output” –> definiert, was ausgegeben wird

note: if you like you can take a look at my notes about Design by contract from last year –> https://cloud.scattered-lenity.space/index.php/s/GQt4zaKQZkqctkr

$-=\equiv$>| Design By Contract |<$\equiv =-$

• Diese Abhängigkeiten / Bedingungen beschreiben wir mit:
• Preconditions -> Voraussetzungen ( $a=int,a<=0,a\in \mathbb{P}\dots$)
  • State of the world before usage
• Postconditions -> Nachbedingungen ( result is $a\ge 9\to \sqrt{a}\cdot \sqrt{2}\le a\dots$ )
  • State of the world after usage
• Invarianten –> Zustände, die sich nicht ändern werden -> $aint,a$ unchanged … ?

$-=\equiv$>| Design By Contract |<$\equiv =-$

[!Task] Zusammenhang von Preconditions / Postconditions bei User / Dev ? Betrachte Beispiel:

1. wer profitiert von den pre-conditions, wer muss diese einhalten?
2. was entspricht hier der postcondition?
3. wer profitiert von den Postconditions? -> warum?

note: sketching the following table to board to interactively solve it:

Pre-Condition: Client wants to travel from Germany to Taiwan by airline X –> what are the

what can be observed here: -> the client benefits are more or less equal to the supplier obligation ?? and vice versa

the client is responsible for the parts where the supplier benefits from it ! ( beide Bedingen sich also!)?

$-=\equiv$>| Design By Contract |<$\equiv =-$

[!Task] wie präzise sollte ein Contract sein?

[!Task] Wie können wir sie aufschreiben?

[!Task] Inwiefern hängen Contracts mit Test(ing) zusammen? Wozu brauchen wir sie?

note:

we require contracts for several reasons: -> legal requirements ( specific testing for autonomous automotive ) -> assurance regarding our codebase:

• on compile time / runtime the system can notify us if a contract was not met ( i.e. requirement is not met that we’ve set before)
• runtime errors can be somewhat observed now because we see when they may have arose now
• runtime exceptions are also observable –> we did before but now we have a good representation

$-=\equiv$>| Design By Contract |<$\equiv =-$

• Contracts treffen bei allen möglichen Sprachen auf!
  • manchmal mehr / weniger enforced tho!
• -> Coding braucht oft Visualisierung von Problemen / Fehlern etc !
  • Warning werden ignoriert
  • Errors müssen behandelt werden –> muss man also abdecken / lösen!
• (HW8 beschäftigt sich damit) –> Static analysis from google ( good read :>! )

$-=\equiv$>| DbC in action! |<$\equiv =-$

[!Task] IM REPO ( ex9-tut4)

1. schau dir In Contracts.scala die Aufgaben für PART1 und PART2 an
2. bearbeite sie entsprechend –> schreib Kommentare für die Lösungen
3. Bei Fragen gerne melden :)
4. <<Gemeinsam bespreche>> ??

note: this can take like the rest of the whole course this time!