Schulisches/TI-Studium-Mitschriften
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
ba91b30b7a002875fcdfcac9231ea029d3216ac6
TI-Studium-Mitschriften/Semester 3/SWTECH/Vorlesung.md
fzzinchemical 269b8a31ba update to local git repo
2025-07-02 13:08:03 +02:00

12 KiB
Executable File
Raw Blame History

Klausurtermine Mi: 07.02.2024, 28.03.2024, 9 Uhr, Raum 032a-c "Ich möchte nicht sehen was Sie nicht können, Ich möchte sehen was Sie können." Vorlesung des 15. 16. fällt aus.

Inhaltsverzeichnis

Vorlesungseinführung

Discord Channel , Aulis bleibt klassische Platform Labor ist verpflichetend und wird bewertet (Raum 236 als Diskussionsraum) Folien, die in den Vorlesungen nicht behandelt wurden müssen privat bearbeitet werden.

Klausur

  • Klausur ist bei mind. 50% bestanden, allerdings wird Zeitdruck in der Klausur simuliert ("Klausur ist sportlich"')
  • 1 bei 90% "Ich gehe aber sowieso davon aus, dass Sie die 10% nicht bekommen.".(Big OOOF)
  • DIN A4 doppelseitig beschrieben (Handschriftlich) als Formelsammlung kann mitgenommen werden.
  • Strategie + Konzentration sind Schlüssel
  • 20% Theorie, Kompetenzstufe 6

Labor

  • Laborraum: I233
  • Laboraufgaben am Labortag bis 23:55
  • Laboraufgaben sind skalierbar (wenn jemand austeigen sollte, werden die Aufgaben geringer)
  • vergabe von Teamnoten und Kennzeichnung von Eigenleistung, bei bedarf kann die Benotung als Einzelperson erfolgen

Inhalt

  • Paradigmenvergleiche bei Programmiersprachen für unterschiedliche Kontexte.
  • UML macht einen Comeback und muss gründlich durchegenommen werden anhand der UML Folien und von Beispielsweise bearbeitung von UML Glasklar
  • Literatur von vor 5 Jahren schon teilweise obsolet und daher nur als Grundlagen verwenden
  • IEEE, ACM, GI, INCOSE, GfSE

Vorlesung 01 (Einführung)

Software

  • Software altert teilweise schneller als Hardware
  • "Wir machen etwas, was an den Rest passen muss"
  • Wohin gehen die Wissensschnittstellen, welche Grenzen haben diese?

Softwaresystem

  • Software+ Hardware
  • Software defakto überall
  • Immer Architektur, durch bewusstes Design oder ausversehen entstanden
  • Sinnvolle Architektur ist wichtig

Keine Ahnung wohin damit

  • UML ist nicht Mittel zum Zweck, sondern ein Tool um strukturellen Kontext

Vorlesung 02 (Entwicklungsprozess)

  • Wenn die Techniken der Softwareentwicklung nicht beherscht sind, dann ist jegliche Bewertung von Zeitaufwand, Personal etc nicht möglich.
  • Abschluss der 1. Vorlesungsfolien

Entwicklungsprozess

Begriffe und Grundlegendes

  • Prozess: Vorgehensweise zur Erstellung des Produkts
  • Produkt: Resultat des Prozesses
  • Projekt: Das gesamte Vorhaben als (Phasen-) Abfolge zum Erstellen des Produkts

Projektphasen

  • Studien- und Planungsabschnitt (Vorstudie, Konzeption, Definition & Planung)
  • Realisierungsabschnitt (Entwicklung, HW Fertigung)
  • Betriebsabschnitt (Betrieb & Wartung, Entsorgung)

Aktivitäten / Phasen

Überblick

Entwurf

  • erstellen eines Systems, welches die Anforderungsanalyse entspricht
  • Entwurf Abhängig von dem was gebraucht wird und welche Qualitätsmerkmale gefragt werden
Grobentwurf
  • Lines & Boxes
  • Kapselung notw. DIesnte
  • Testen auf Anforderungen
Feinentwurf
  • Wie wird konkret realisiert?
  • Unit-test ist teil der Implementierung

Implementierung

  • Entwurf dient als Grundlage
  • Programming in the small vs. Programming in the large (Ground up und Top down)
  • Integrations und Systemtest

Phasenübergreifende Aspekte

Projektmanagement
Projekt und Konfigurationsmanagement
  • urspr. Lösen der steigenden Produktkomplexität

Vorlesung 03 (Vorgehensmodelle)

Vorgehensmodell

  • Ziel: Geplant zu qual.hochw. Produkt
  • Arbeits- aufteilung und vorgang
  • 4Ws machen ihren come-back bei der Aufbereitung

Wasserfallmodell / Phasen und Ergebnisse

  • früher: stagewise model
    • weiterentwicklung u.a. durch Royce
  • Für das Verständnis des zusammenhangs und der Funktion von bspw. SCRUM ist das Verstehen von dem Modell wichtig
  • Pflichtenheft vorhanden
  • Wenn sauber bearbeitet wurde entstehen zwei Dokumente (Pflichtenheft und Anf.Spez.)
  • sukzessive Entwicklung von Software, praktisch aber nicht wirklich umsetzbar
    • Kunde kann Lastenheft innerhalb der Bearbeitungszeit überarbeiten etc.
  • "Wartungsdefinition nicht so gut definiert"
  • vollst. Durchführung der Phasen nicht immer sinnvoll

Wasserfall-Verbesserung

  • verbesserung durch interativ, inkrementelle Wiederholungen

Iterativ / Inkrementell / Evolutionär

  • Iterativ: Wiederholen
  • Inkrement: Vergrößern
  • Evolutionär:
  • Kosten können nach jeder Iteration überprüft werden
  • Agile hat nicht iterativ, inkrementelles Vorgehen nicht erfunden
Probleme:
  • Prozess nicht wirklcih sichtbar
  • schlechte Strukturierung kann enstehen
  • Vertraglich gebunden
  • "Safe ist grausam (zu komplex und nicht unbedingt agil)"
  • Für reine Softwaresysteme

Spiral-Modell

  1. Analyse
  2. Evaluierung
  3. Realisierung
  4. Planung
  • Entwickeln mehrerer Prototypen \rightarrow treibung durch Prototypentwicklung

Prototyping zur Unterstützung der Iteration

  • keine ad-hoc Vorgehensweise
Experimentelle Prototypen
  • Nachweis der Machbarkeit
Horizontal- vs. Vertikale Prototypen

Horizontal: real. nur einer spez. Ebene Vertikal:

Rational Unified Process (RUP)

  • Initial 1998 von Kruchten vorgestellt
  • basiert auf UML
  • "Zu kompliziert für reale Welt"
  • RUP wird nicht abgefragt, trotzdem interessant

Agile Vorgehensmodelle

  • inkr. Ansatz aus vielen kleinen Iterationen
  • neu: Am Ende jeder Iteration folgt ein Reviews und ggf. Re-Evaluation von Projektprioritäten
  • "Agile kann man sich nicht nennen, Agile muss man sein" (cringe)

Agiles entwickeln mit Scrum

!Pasted image 20231102101622.png

Das V-Modell

  • defakto aus Militär

  • Absolut viele unterschiedlichen Modelle (wie auf wiki. zu lesen)

  • entgegensetzen von Implementation und Testens !Pasted image 20231102105704.png

  • Benutzen eines Hybridmodelles hier sinnvoll, weil Anforderungsänderungen hier teilweise sehr teuer werden können.

Vorlesung 04 (Anforderungsanalyse)

Definition

Definiert nach IEE als die dok. Darstellung einer Beschaffenheit oder Fähigkeit, die von einem Benutzer oder Lösung eines Problems oder Erreichung eines Ziels benötigt wird oder die ein System oder Systemteil erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente zu erfüllen.

Anforderungsanalyse - Grundlagen

  • Pflichtenheft ist ein Vertragsdokument

Lasten-/Pflichtenheft

  • Lastenheft besch. Anf. aus Kundensicht
  • Pflichtenheft besch. Anf. aus Lieferantensicht
    • Vertragsgrundlage
    • von allen am Projekt Beteiligten akzeptiert

Arten von Anforderungen

!Pasted image 20231102115045.png

Eigenschaft einer Anforderung

Inhalt

!Pasted image 20231102115639.png

Behandlung

!Pasted image 20231102115326.png

Schritte

3. Schritt

  • Benutzer des Systems
  • Rollen der Benutzer

Akteure in UML

  • Rolle, welche ein Benutzer im System spielt
  • Beeinflusst Sys.

4. Schritt

  • Fortschrittsequenz der Geschäftsprozesse

5. Schritt

  • Anwendungsfälle deklarieren (Use-Cases)
  • Anwendung von UML2 als gängige Notation

6. Schritt

  • Anwendungsfälle zerlegen Geschäftsprozesse in Portionen, welche aus Sicht des Anwenders sinnvoll ist.
  • Reihenfolge kann sich später ändern, daher ist eine Festlegung der Reihenfolge am Anfang unwichtig

7. Schritt

  • Ausarbeitung der Anwendungsfälle (ins Detail gehend)
  • Die Analyse kann als UML-, Text-, Diagrammentwurf beispielsweise erstellt werden (Schablonen ebenfalls) Präsentiert wird dann Folie 44,45 und 46, welche eine Beispielschablone für die Bearbeitung des 7. Schrittes ist.klk

Vorlesung 05 (Entwurf)

  • festl. Architektur des Sys.

Allgemeines

Entwurfskriterien

  • Kopplung:
    • Maß für ene interne Beschaffenheit eines Entwurfs
    • Koplung über eine Schnittstelle
    • Ziel: lose/geringe Kopplung
      • Fehlerbehebung ohne größeren Aufwand
  • Kohäsion:
    • Maß für die (funktionale) Bindung der Elemente innerhalb eines Bausteins
    • Kohäsion bewertet den inneren Zusammenhalt
    • Ziel: starke/hohe Kohäsion
      • benötigte Infos und Ops zur Lösung in einem Baustei vorhanden
  • Zulänglichkeit:
    • Maß für Erfüllung der Anforderungen
    • Ziel: überschaubare, einsichtige Zulänglichkeit
  • Vollständigkeit
    • Maß für vollständige Umsetzung der Anforderungen
    • Ziel: Vollständigkeit in Bezug zur Aufgabe
  • EInfachheit
    • Maß für die Umsetzung von hinreichender Funktionalität mit angemessener Schnittstelle des Bausteins
    • Ziel: KIS - keep it simple

Entwurfsprinzipien

  • Grundsatz, dem man seinem Handeln zugrunde legt
  • Noch unabhängig von konkreten Methoden und Techniken
  • Modelltypen
    • deskriptiv
    • präskriptiv

Sichtweisen/Vorgehensweisen zum Entwurf

  • Orientierung ist egal

Heuristiken

  • Aus Projektumfeld
    • Anforderungen Hinterfragen
    • Betrachtung Use-Cases
    • Nach Feedback suchen
  • Für den Entwurf
    • KIS
    • auf "richtige" Detailebene bleiben
    • nicht übergeneralisieren
    • so lokal wie möglich entwickeln Off Topic stuff:
  • Basiswissen-Softwaretest-Modul laut Matevska ein gutes Modul
  • Informatik ist Denglisch at its peak

Vorlesung 8

  • Paper-Reviews können blind betrachtet werden um vorurteile etc beiseite zu schieben

  • Review-sitzung soll zieloreintiert durchgezogen werden

  • Nachbearbeitung kann zu wiederholung des Reviews führen

  • Je komplexer die thematik, umso besser muss man in der Materie sein

  • systematisches Vorgehen und kein ad hoc (spezifizierter Test und nicht über den Tellerrand schauend)

  • Eigang von Unit lvl. aber auch komplex lvl.

Testfälle:

  • Bei Tests Versionen etc. mit angeben (der Stubs beispielsweise)
  • Reproduzierbarkeit des Tests ist eine grundlage für das gute Testen
  • Womit wurde getestet?
    • Beispiel Compilereinstellungen sind wichtig anzugeben weil unterschiedliche Ergebnisse rauskommen können
  • Auf Testfälle kommt man anhand der Anforderungsdefinitionen, Systemspez. und allg. Richtlinien Äquivalenzklassenbildung
  • Auswahl an Eingabeparameter, bei denen eine keine unterschiedlichen Ausgaben herauskommen

Vorlesung 9

Whitebox Test Folie 48-50 Prüfungsrelevant

Vorlesung 10 Implementierung

  • Dokumentation um zu Wissen was innerhalb geschieht

Compiler, Interpreter, Precompiler und Linker Imperativ => Herrschen, Beherschen

OOP: Vererbung segen und Fluch

Reference in New Issue View Git Blame Copy Permalink