maxScale: 1.5 width: 900 height: 900

SE-Tutorium 4 | Mittwoch 16 - 18 Uhr:

anchored to [[191.00_anchor]]

| Orga | Aktuelle Abgaben

  • Helpdesk am Freitag besuchen ( letzte Woche nur 2 Personen !?)
  • HW11 bis diesen Sonntag machen!
  • Geschriebenes Feedback (HW7) jetzt im Repo zu finden!

| Orga | Infos

  • bitte keine Plagiate abgeben nicht soo offensichtlich_ –> kamen in HW8 auf !
  • nächstes Tutorium ( letztes ) wird sich Scrum mit Klemmbausteinen widmen!
    • kommt also vorbei!

| Weitere Fragen zu Hausaufgabe | Klausur?

Themen heute |

  • Requirement Analysis durch das Schreiben von User-Stories
  • User Stories sinnig analysieren / Informationen extrahieren
  • SOLID wiederholen
  • Designs auf SOLID prüfen (und verbessern!)
  • Software Design üben!

Anmerkung:

Wir haben im Tutorium zu Beginn dessen nochmal die Code-Smells in der Probeklausur. und wie man sie finden / betrachten kann, angeschaut und darüber gesprochen, bevor wir dann auf die folgenden Themen eingegangen sind. hier link zur Probeklausur :)

Requirement Analysis | Idee

  • Beschreibt den Prozess, um “Nutzer*innen Anforderungen” zu sammeln und im Design des Projektes einfließen zu lassen
  • –> Nutzende von unserer Library / Unserer Oberfläche / unseres vollständigen Projektes (( also verschiedene Stufen von Nutzer*innen möglich obv))
  • Requirements können von vielen Nutzenden ( Beteiligten) kommen
  • sammeln und passendes Design erzeugen / gestalten

Requirement Analysis | Idee

  • Abwägen von Features, die eingebracht werden können oder nicht
  • feature creep verhindern ( weil zuvor festgelegt!)
  • Fehler / Probleme vorzeitig erkennen und abwägen
  • Kommunikation zwischen Nutzenden und Implementierenden!
  • –> Produkt / Projekt muss von beiden richtig verstanden / kommuniziert werden

note: What is important: If those needs are not communicated well / correctly we can run into the issue that a feature might’ve been described or provided however the interpretation of this description varied among the parties involved so they understood a different need / feature! –> However We want everyone to have the same idea / image of our implementation

more information might be found here : https://www.visual-paradigm.com/guide/requirements-gathering/requirement-analysis-techniques/ https://www.lambdatest.com/learning-hub/requirement-analysis https://de.wikipedia.org/wiki/Anforderungsanalyse_(Informatik) ( although it also covers things we don’t require at all here!)

Requirement Analysis | User Stories!

  • User Stories als einfache Möglichkeit solche Erwartungen/ Notwendigkeiten zu beschreiben
  • Aus Sicht der Nutzenden über das Projekt nachdenken –> Was wollen wir können?
  • ( hilft, wenn man anfängt und nicht weiß, was man brauch / womit man anfangen soll!)

Requirement Analysis | User Stories!

  • Gibt 3 Dinge an
  • 1: Person, von der die “Story/Situation” ausgeht -> Wer möchte was machen?
  • 2: Was diese Person machen möchte -> Tätigkeit -> Was möchte sie machen?
  • 3: Gründe / Ziele der Tätigkeit –> was will ich erreichen?

User Stories | Example Context

  • Betrachten wir folgenden Kontext:
  • forum-like system for students ( profs, tutors, users …)
  • (Uns interessiert nicht, wie spezifisch es aufgebaut ist!) ( Also ob Webapp, reine CLI, o.ä. …)

User Stories | Example Context

[!Task] Consider the following example:

  1. As a professor,
  2. I want to post announcements
  3. so that they appear on my students’ feed where they can read them.

Welche Klassen werden wir wahrscheinlich in unserer Implementation benötigen? -> Können wir erfahren, wie sie zusammenhängen?

note: Well the solution can be found in the Repo too!

Professor, Announcement, and Student, Feed can be possible model classes.

User Stories | Analysieren

  • Struktur des Satzes / der Sätze anschauen und daraus die Infos ziehen:
  • Klassen/Datentypen –> entsprechen den Substantiven ( Professor announcement, students)
  • Methoden –> entsprechen den Verben ( want to post… , appear on students…)
  • Relation von Datentype und Methoden –> Kontext dazwischen x)
  • geht bisschen in die Richtung von DDD - Domain Driven Design -

note: more can be read from here -> https://en.wikipedia.org/wiki/Domain-driven_design

Software Design | SOLID Prinzipien

  • mit SOLID definieren wir 5 Design-Prinzipien für Struktur von Software ( Codebases )
  • Pattern, nach denen man Software designen kann
  • Idee: –> durch einhalten dieser Prinzipien System entwerfen, die:
    • extendable
    • leicht testbar –> kleine Module !
    • einfacher zu nutzen –> weniger Smells / komische Dependencies and such
  • dienen auch als heuristik für Designs!

Software Design | SOLID

  • Single Responsibility Principle: A component (class, function, module, …) should only have one reason to change.
  • Open–Closed Principle: A component should be open for extension, but closed for modifications.
  • Liskov Substitution Principle: Subtypes must be behaviorally substitutable for their base types.

Software Design | SOLID

  • Interface Segregation Principle: Clients should not be forced to depend upon interfaces that they do not use.
  • Dependency Inversion Principle: High-level modules should not depend on low-level modules. Both should depend upon abstractions (not concretions).

Design auf SOLID prüfen

  • wir möchten uns die Designs im REPO here anschauen und evaluieren, ob diese gut / schlecht sind ( und warum! )
  • Also Fragen stellen und lösen, die auf folgendes eingehen:
    • was könnte problematisch sein, warum?
    • welches Prinzip verletzt es?

Software Design üben

[!Task] Im REPO hier Markdown1

  1. ( Part1 ) anschauen –> und die Aufgabe verstehen
  2. mögliches Design entwerfen und dokumentieren / aufschreiben
  3. ( Part2 ) Gruppen bilden ( 3+ Personen pls ) und das Design vorstellen und vergleichen
  4. Design erweitern, um neue Spezifikationen
  5. weitere Aufgaben verfolgen ( Part 3 )

note: Diese Aufgabe ähnelt in der Struktur / Aufgabe schon etwa der HW11, weil wir da auch genau eine solche Betrachtung / Analyse und Ausarbeitung vornehmen sollen / müssen!